[U-Boot] Need Help in bulding U-boot-2010-06 for OpenRD client
Hello,
I'm trying to build uboot.bin for Marvell OpenRD client from uboot-2010-06 source file. I noticed that there is no config file for OpenRD_client. So I compiled openrd_base and sent the binary to the board using OpenOCD. But the board doesn't even boot. Can you please let me know if there is another board config specific to OpenRD_Client or am I missing something ??
Thanks for you help,
Best Regards, Kalyan.
Le 01/07/2010 15:44, kalyan karnati a écrit :
Hello,
I'm trying to build uboot.bin for Marvell OpenRD client from uboot-2010-06 source file. I noticed that there is no config file for OpenRD_client. So I compiled openrd_base and sent the binary to the board using OpenOCD. But the board doesn't even boot. Can you please let me know if there is another board config specific to OpenRD_Client or am I missing something ??
Thanks for you help,
Best Regards, Kalyan.
Hi Kalyan,
I've successfully used the base config for a client board, as well as used a patch recently sent to this list that adds client and ultimate support. You can search the list for 'ultimate' for instance:
http://lists.denx.de/mailman/listinfo/u-boot
Re: your issue, can you detail exactly how you load and run u-boot via openocd? What operations do you perform on the board, and what commands do you issue on your debugging host to launch openocd?
Amicalement,
Hi Albert, Thanks for your reply.
I compiled U-boot with the patch that enables support for OpenRD_client and OpenRD_ultimate given by Tanmay. OpenRD Client is connected to PC/Host with FTDI programmed for Channel A as CPU FIFO.
I'm using the binary for OpenOCD that I got from Marvell to tranfer uboot.bin into board's NAND. I copied the 'u-boot-2010.06.bin' in to ~\openocd\openocd.binaries.libftdi/bin as 'uboot.bin'. Then executed the command ' ./openocd –f target/board/openrd.cfg –c init -c openrd_reflash_uboot'
Logs show: wrote file uboot.bin to NAND flash 0 up to offset 0x0004e800 in 50.190395s Info : JTAG tap: feroceon.cpu tap/device found: 0x20a023d3 (Manufacturer: 0x1e9, Part: 0x0a02, Version: 0x2) Info : JTAG Tap/device matched
But then the board doesn't boot and the console is all blank :( Please let me know if I'm doing something wrong..
Thanks, Kalyan.
Hi Kalyan,
I've successfully used the base config for a client board, as well as used a patch recently sent to this list that adds client and ultimate support. You can search the list for 'ultimate' for instance:
http://lists.denx.de/mailman/listinfo/u-boot
Re: your issue, can you detail exactly how you load and run u-boot via openocd? What operations do you perform on the board, and what commands do you issue on your debugging host to launch openocd?
Amicalement,
Le 06/07/2010 17:47, kalyan karnati a écrit :
Hi Albert, Thanks for your reply.
I compiled U-boot with the patch that enables support for OpenRD_client and OpenRD_ultimate given by Tanmay. OpenRD Client is connected to PC/Host with FTDI programmed for Channel A as CPU FIFO.
I'm using the binary for OpenOCD that I got from Marvell to tranfer uboot.bin into board's NAND. I copied the 'u-boot-2010.06.bin' in to ~\openocd\openocd.binaries.libftdi/bin as 'uboot.bin'. Then executed the command ' ./openocd –f target/board/openrd.cfg –c init -c openrd_reflash_uboot'
Logs show: wrote file uboot.bin to NAND flash 0 up to offset 0x0004e800 in 50.190395s Info : JTAG tap: feroceon.cpu tap/device found: 0x20a023d3 (Manufacturer: 0x1e9, Part: 0x0a02, Version: 0x2) Info : JTAG Tap/device matched
But then the board doesn't boot and the console is all blank :( Please let me know if I'm doing something wrong..
Thanks, Kalyan.
Hi Kalyan,
At the moment the openrd image will only run if loaded into RAM through openocd.
I'd discussed with Tanmay about running the openrd binary: I'd tried to load it into RAM from the resident u-boot via TFTP, and that fails too.
In your case it will also certainly fail because the board config file contains #define CONFIG_SKIP_LOWLEVEL_INIT, which as the name implies skips very early and critical initialization code -- and without this code u-boot won't start from Flash (this config option is used precisely when running u-boot from RAM).
Can you try removing the #define and let us know if that fixes things up?
I'm not sure it will, though, because it fails when run in RAM from u-boot with the #define, which means it probably does not do some critical init --one that openocd does when it runs u-voot from RAM, since in that case it works.
Amicalement,
-----Original Message----- From: u-boot-bounces@lists.denx.de [mailto:u-boot-bounces@lists.denx.de] On Behalf Of Albert ARIBAUD Sent: Tuesday, July 06, 2010 10:03 PM To: u-boot@lists.denx.de; kalyan karnati Subject: Re: [U-Boot] Need Help in bulding U-boot-2010-06 for OpenRD client
Le 06/07/2010 17:47, kalyan karnati a écrit :
Hi Albert, Thanks for your reply.
I compiled U-boot with the patch that enables support for OpenRD_client and OpenRD_ultimate given by Tanmay. OpenRD Client is connected to PC/Host with FTDI programmed
for Channel
A as CPU FIFO.
I'm using the binary for OpenOCD that I got from Marvell to tranfer uboot.bin into board's NAND. I copied the 'u-boot-2010.06.bin' in to ~\openocd\openocd.binaries.libftdi/bin as 'uboot.bin'. Then executed the command ' ./openocd –f target/board/openrd.cfg –c init -c openrd_reflash_uboot'
Logs show: wrote file uboot.bin to NAND flash 0 up to offset
0x0004e800 in 50.190395s
Info : JTAG tap: feroceon.cpu tap/device found: 0x20a023d3 (Manufacturer: 0x1e9, Part: 0x0a02, Version: 0x2) Info : JTAG Tap/device matched
But then the board doesn't boot and the console is all blank :( Please let me know if I'm doing something wrong..
Thanks, Kalyan.
Hi Kalyan,
At the moment the openrd image will only run if loaded into RAM through openocd.
I'd discussed with Tanmay about running the openrd binary: I'd tried to load it into RAM from the resident u-boot via TFTP, and that fails too.
In your case it will also certainly fail because the board config file contains #define CONFIG_SKIP_LOWLEVEL_INIT, which as the name implies skips very early and critical initialization code -- and without this code u-boot won't start from Flash (this config option is used precisely when running u-boot from RAM).
On Kirkwood boards, best way is to create kwb target (i.e. u-boot.kwb) for details refer doc/README.kwbimage
Regards.. Prafulla . .
Le 07/07/2010 10:09, Prafulla Wadaskar a écrit :
-----Original Message----- From: u-boot-bounces@lists.denx.de [mailto:u-boot-bounces@lists.denx.de] On Behalf Of Albert ARIBAUD Sent: Tuesday, July 06, 2010 10:03 PM To: u-boot@lists.denx.de; kalyan karnati Subject: Re: [U-Boot] Need Help in bulding U-boot-2010-06 for OpenRD client
Le 06/07/2010 17:47, kalyan karnati a écrit :
Hi Albert, Thanks for your reply.
I compiled U-boot with the patch that enables support for OpenRD_client and OpenRD_ultimate given by Tanmay. OpenRD Client is connected to PC/Host with FTDI programmed
for Channel
A as CPU FIFO.
I'm using the binary for OpenOCD that I got from Marvell to tranfer uboot.bin into board's NAND. I copied the 'u-boot-2010.06.bin' in to ~\openocd\openocd.binaries.libftdi/bin as 'uboot.bin'. Then executed the command ' ./openocd –f target/board/openrd.cfg –c init -c openrd_reflash_uboot'
Logs show: wrote file uboot.bin to NAND flash 0 up to offset
0x0004e800 in 50.190395s
Info : JTAG tap: feroceon.cpu tap/device found: 0x20a023d3 (Manufacturer: 0x1e9, Part: 0x0a02, Version: 0x2) Info : JTAG Tap/device matched
But then the board doesn't boot and the console is all blank :( Please let me know if I'm doing something wrong..
Thanks, Kalyan.
Hi Kalyan,
At the moment the openrd image will only run if loaded into RAM through openocd.
I'd discussed with Tanmay about running the openrd binary: I'd tried to load it into RAM from the resident u-boot via TFTP, and that fails too.
In your case it will also certainly fail because the board config file contains #define CONFIG_SKIP_LOWLEVEL_INIT, which as the name implies skips very early and critical initialization code -- and without this code u-boot won't start from Flash (this config option is used precisely when running u-boot from RAM).
On Kirkwood boards, best way is to create kwb target (i.e. u-boot.kwb) for details refer doc/README.kwbimage
Regards.. Prafulla . .
Thanks Prafulla, this explains why flashing the u-boot file won't work.
This also leads me to asking a question.
Apparently, some low-level inits are performed by the kirkwood rom boot code based on the DATA lines in the kwbimage.cfg file rather than by the u-boot low level inits (this explains why the board config files have CONFIG_SKIP_LOWLEVEL_INIT yet would boot from NAND).
But I have another problem that may be caused by this kwbimage.cfg approach: the u-boot image does not run in RAM when launched from the current (NAND-loaded) u-boot with tftp and go. Judging from the README you pointed to, the kirkwood u-boot code probably misses some critical inits, which the kwbimage.cfg adds to it.
Could it be that the low level init code for the kirkwood always assumes that all critical inits have already been performed when u-boot starts, and thus u-boot does not do them at all?
Problem is, kwbimage.cfg has boot options for sata, spi and nand but not -- of course -- RAM, so I can't fix this 'running from RAM' issue using kwbimage.
Amicalement,
-----Original Message----- From: Albert ARIBAUD [mailto:albert.aribaud@free.fr] Sent: Wednesday, July 07, 2010 4:38 PM To: Prafulla Wadaskar Cc: u-boot@lists.denx.de; kalyan karnati Subject: Re: [U-Boot] Need Help in bulding U-boot-2010-06 for OpenRD client
...snip...
skips very early and critical initialization code -- and
without this
code u-boot won't start from Flash (this config option is used precisely when running u-boot from RAM).
On Kirkwood boards, best way is to create kwb target (i.e.
u-boot.kwb)
for details refer doc/README.kwbimage
Regards.. Prafulla . .
Thanks Prafulla, this explains why flashing the u-boot file won't work.
This also leads me to asking a question.
Apparently, some low-level inits are performed by the kirkwood rom boot code based on the DATA lines in the kwbimage.cfg file rather than by the u-boot low level inits (this explains why the board config files have CONFIG_SKIP_LOWLEVEL_INIT yet would boot from NAND).
But I have another problem that may be caused by this kwbimage.cfg approach: the u-boot image does not run in RAM when launched from the
you should use u-boot.bin to load in RAM @ 0x600000 (TEXT_BASE)
current (NAND-loaded) u-boot with tftp and go. Judging from the README you pointed to, the kirkwood u-boot code probably misses some critical inits, which the kwbimage.cfg adds to it.
Could it be that the low level init code for the kirkwood always assumes that all critical inits have already been performed when u-boot starts, and thus u-boot does not do them at all?
YES
Problem is, kwbimage.cfg has boot options for sata, spi and nand but not -- of course -- RAM, so I can't fix this 'running from RAM' issue using kwbimage.
This is not objective of kwbimage, kwbimage appends header to u-boot.bin which directly read by internal bootROM to achieve boot from supported medias on Kirkwood.
for boot from RAM, you must need at least SDRAM configured, so JTAG is the way
Regards.. Prafulla . .
Le 07/07/2010 13:44, Prafulla Wadaskar a écrit :
you should use u-boot.bin to load in RAM @ 0x600000 (TEXT_BASE)
That's what I do, either through JTAG or by tftp/go in resident u-boot.
for boot from RAM, you must need at least SDRAM configured, so JTAG is the way
JTAG does work indeed. Howvever, when:
- I power up the board; - ROM boot loads u-boot from NAND and starts it; - I stop u-boot and get to the prompt; - I 'tftp' an u-boot.bin image into RAM at 1000000; - I 'go' to 1000000
... the tftp'ed image fails to boot although SDRAM is obviously already configured.
OTOH, openOCD boots the RAM image fine, so I guess OpenOCD does some inits that the boot rom plus resident u-boot don't.
Amicalement,
Hi Prafulla/Albert,
Thanks alot for your help. Finally using kwbimage.cfg solved the problem and my openRD_client came up :)
Now, I want to boot Uimage and Filesystem from an MMC card. But the MMC support was not enabled, I added the configurations for MMC support to openrd_cleint.h. --------------------------------- /* MMC support flags */ #define CONFIG_CMD_EXT2 1 #define CONFIG_CMD_FAT 1 #define CONFIG_MMC 1 #define CONFIG_GENERIC_MMC 1 #define CONFIG_CMD_MMC 1 -----------------------------------------------
But the U-boot doesn't detect the card. From the startup messages, I observed that the driver for Kirkwood openrd_client is not found from u-boot. Is there any patch or work around available to enable the boot from MMC ?
--------------------------------------- U-Boot 2010.06 (Jul 07 2010 - 11:49:16) OpenRD-Client
U-Boot code: 00600000 -> 00654810 BSS: -> 0069B060 SoC: Kirkwood 88F6281_A0 RAM Configuration: Bank #0: 00000000 256 MiB Bank #1: 10000000 256 MiB Bank #2: 00000000 0 Bytes Bank #3: 00000000 0 Bytes NAND: 512 MiB In: serial Out: serial Err: serial *MMC:* Net: egiga0, egiga1 Reset Ethernet PHY smi_reg_read:(adr 8, off 21) value= 1070 smi_reg_read:(adr 8, off 0) value= 1140 smi_reg_read:(adr 8, off 0) value= 1140 88E1116 Initialized on egiga0 smi_reg_read:(adr 24, off 21) value= 1070 smi_reg_read:(adr 24, off 0) value= 1140 smi_reg_read:(adr 24, off 0) value= 1140 88E1116 Initialized on egiga1 -----------------------------------------
Then I tried using USB. But when I use the commands to load uImage into RAM, some messages are shown and it never stops. I had to power cycle to go u-boot prompt again. So loading any file/image into the RAM is not working :( can you please help me on this ??
Please find the logs:
Marvell: setenv mainlineLinux yes setenv arcNumber 2361 saveenv reset
Marvell>> usb start (Re)start USB... USB: Kirkwood-ehci: init hccr f1050100 and hcor f1050140 hc_length 64 Register 10011 NbrPorts 1 USB EHCI 1.00 scanning bus for devices... req=6 (0x6), type=128 (0x80), value=256, index=0 USB_DT_DEVICE request req=5 (0x5), type=0 (0x0), value=1, index=0 USB_REQ_SET_ADDRESS Len is 0 req=6 (0x6), type=128 (0x80), value=256, index=0 USB_DT_DEVICE request req=6 (0x6), type=128 (0x80), value=512, index=0 USB_DT_CONFIG config req=6 (0x6), type=128 (0x80), value=512, index=0 USB_DT_CONFIG config req=9 (0x9), type=0 (0x0), value=1, index=0 USB_REQ_SET_CONFIGURATION Len is 0 req=6 (0x6), type=128 (0x80), value=768, index=0 USB_DT_STRING config req=6 (0x6), type=128 (0x80), value=769, index=1 USB_DT_STRING config req=6 (0x6), type=128 (0x80), value=770, index=1 USB_DT_STRING config req=6 (0x6), type=160 (0xa0), value=10496, index=0 USB_DT_HUB config req=6 (0x6), type=160 (0xa0), value=10496, index=0 USB_DT_HUB config req=0 (0x0), type=160 (0xa0), value=0, index=0 req=3 (0x3), type=35 (0x23), value=8, index=1 Len is 0 req=0 (0x0), type=163 (0xa3), value=0, index=1 req=0 (0x0), type=163 (0xa3), value=0, index=1 req=1 (0x1), type=35 (0x23), value=16, index=1 Len is 0 ......................... ......................... dev=0065e9cc, pipe=c8010303, buffer=004fe994, length=31, req=(null) TOKEN=0x80008c01 dev=0065e9cc, pipe=c8008383, buffer=004fea50, length=512, req=(null) TOKEN=0x8d00 dev=0065e9cc, pipe=c8008383, buffer=004fe9e0, length=13, req=(null) TOKEN=0x80008d00 1 Storage Device(s) found * **Marvell>> ext2load usb 0:1 0x00800000 /uImage * TOKEN=0x8c01 dev=0065e9cc, pipe=c8008383, buffer=004fd408, length=13, req=(null) TOKEN=0x80008d00 dev=0065e9cc, pipe=c8010303, buffer=004fd3d4, length=31, req=(null) TOKEN=0x80008c00 dev=0065e9cc, pipe=c8008383, buffer=0114f000, length=1024, req=(null) TOKEN=0x80008d00 dev=0065e9cc, pipe=c8008383, buffer=004fd420, length=13, req=(null) TOKEN=0x8d00 <46178, 0, 1024> dev=0065e9cc, pipe=c8010303, buffer=004fd3bc, length=31, req=(null) TOKEN=0x8c00 dev=0065e9cc, pipe=c8008383, buffer=004fd408, length=13, req=(null) TOKEN=0x80008d00 dev=0065e9cc, pipe=c8010303, buffer=004fd3d4, length=31, req=(null) TOKEN=0x80008c01 dev=0065e9cc, pipe=c8008383, buffer=00525c50, length=1024, req=(null) TOKEN=0x80009d00 dev=0065e9cc, pipe=c8008383, buffer=004fd420, length=13, req=(null) TOKEN=0x8d00 ext2fs_read_block 00005a63 <46278, 0, 1024> dev=0065e9cc, pipe=c8010303, buffer=004fd3bc, length=31, req=(null) TOKEN=0x8c01
Thanks, Kalyan Karnati.
On Wed, Jul 7, 2010 at 10:05 AM, Albert ARIBAUD albert.aribaud@free.frwrote:
Le 07/07/2010 13:44, Prafulla Wadaskar a écrit :
you should use u-boot.bin to load in RAM @ 0x600000 (TEXT_BASE)
That's what I do, either through JTAG or by tftp/go in resident u-boot.
for boot from RAM, you must need at least SDRAM configured, so JTAG is the
way
JTAG does work indeed. Howvever, when:
- I power up the board;
- ROM boot loads u-boot from NAND and starts it;
- I stop u-boot and get to the prompt;
- I 'tftp' an u-boot.bin image into RAM at 1000000;
- I 'go' to 1000000
... the tftp'ed image fails to boot although SDRAM is obviously already configured.
OTOH, openOCD boots the RAM image fine, so I guess OpenOCD does some inits that the boot rom plus resident u-boot don't.
Amicalement,
Albert.
-----Original Message----- From: kalyan karnati [mailto:kriskalyan21@gmail.com] Sent: Wednesday, July 07, 2010 11:40 PM To: Albert ARIBAUD Cc: Prafulla Wadaskar; u-boot@lists.denx.de Subject: Re: [U-Boot] Need Help in bulding U-boot-2010-06 for OpenRD client
Hi Prafulla/Albert,
...snip...
......................... ......................... dev=0065e9cc, pipe=c8010303, buffer=004fe994, length=31, req=(null) TOKEN=0x80008c01 dev=0065e9cc, pipe=c8008383, buffer=004fea50, length=512, req=(null) TOKEN=0x8d00 dev=0065e9cc, pipe=c8008383, buffer=004fe9e0, length=13, req=(null) TOKEN=0x80008d00 1 Storage Device(s) found
Marvell>> ext2load usb 0:1 0x00800000 /uImage
Does your USB storage has ext2fs? Generally USB disk has FAT Hope this link will help you http://www.openplug.org/plugwiki/index.php/Das_U-boot_plug_support#How_to_bo...
Regards.. Prafulla . .
-----Original Message----- From: Albert ARIBAUD [mailto:albert.aribaud@free.fr] Sent: Wednesday, July 07, 2010 7:36 PM To: Prafulla Wadaskar Cc: u-boot@lists.denx.de; kalyan karnati Subject: Re: [U-Boot] Need Help in bulding U-boot-2010-06 for OpenRD client
Le 07/07/2010 13:44, Prafulla Wadaskar a écrit :
you should use u-boot.bin to load in RAM @ 0x600000 (TEXT_BASE)
That's what I do, either through JTAG or by tftp/go in resident u-boot.
for boot from RAM, you must need at least SDRAM configured,
so JTAG is the way
JTAG does work indeed. Howvever, when:
- I power up the board;
- ROM boot loads u-boot from NAND and starts it;
- I stop u-boot and get to the prompt;
- I 'tftp' an u-boot.bin image into RAM at 1000000;
- I 'go' to 1000000
... the tftp'ed image fails to boot although SDRAM is obviously already configured.
This is obvious, since u-boot being copied is not created with TEXT BASE=0x100000, is it? And I don’t know how "go TEXT BASE" responds to u-boot binary itself, I have never tested this use case.
OTOH, openOCD boots the RAM image fine, so I guess OpenOCD does some inits that the boot rom plus resident u-boot don't.
Openocd configures RAM before loading u-boot.bin U-boot.kwb does the same but internal bootROM does this instead of openOCD in case of boot from NAND U-boot.bin anyway needs SDRAM configurations to be done by someone else before starting execution.
Regards.. Prafulla . .
Le 08/07/2010 08:09, Prafulla Wadaskar a écrit :
-----Original Message----- From: Albert ARIBAUD [mailto:albert.aribaud@free.fr] Sent: Wednesday, July 07, 2010 7:36 PM To: Prafulla Wadaskar Cc: u-boot@lists.denx.de; kalyan karnati Subject: Re: [U-Boot] Need Help in bulding U-boot-2010-06 for OpenRD client
Le 07/07/2010 13:44, Prafulla Wadaskar a écrit :
you should use u-boot.bin to load in RAM @ 0x600000 (TEXT_BASE)
That's what I do, either through JTAG or by tftp/go in resident u-boot.
for boot from RAM, you must need at least SDRAM configured,
so JTAG is the way
JTAG does work indeed. Howvever, when:
- I power up the board;
- ROM boot loads u-boot from NAND and starts it;
- I stop u-boot and get to the prompt;
- I 'tftp' an u-boot.bin image into RAM at 1000000;
- I 'go' to 1000000
... the tftp'ed image fails to boot although SDRAM is obviously already configured.
This is obvious, since u-boot being copied is not created with TEXT BASE=0x100000, is it? And I don’t know how "go TEXT BASE" responds to u-boot binary itself, I have never tested this use case.
Well, it isn't so obvious, as normally one should be able to start u-boot from any address, as the first thing u-boot does is relocate itself back to its TEXT_BASE (see arch/arm/cpu/arm926ejs/start.S). This feature is precisely there to allow chaining one u-boot in RAM from another one. This relocation feature is compiled in by default; one must define CONFIG_SKIP_RELOCATE_UBOOT, to explicitely forbid u-boot from doing so.
OTOH, openOCD boots the RAM image fine, so I guess OpenOCD does some inits that the boot rom plus resident u-boot don't.
Openocd configures RAM before loading u-boot.bin U-boot.kwb does the same but internal bootROM does this instead of openOCD in case of boot from NAND U-boot.bin anyway needs SDRAM configurations to be done by someone else before starting execution.
I don't mean SDRAM is not initialized; obviously it is. However, something else prevents the kirkwood u-boot to chain from itself. I'd thought an initialization is missing, but actually it could be something about the relocation.
Regards.. Prafulla . .
Amicalement,
participants (3)
-
Albert ARIBAUD -
kalyan karnati -
Prafulla Wadaskar