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,