[U-Boot] Need Help in bulding U-boot-2010-06 for OpenRD client

[Albert ARIBAUD]

Le 07/07/2010 10:09, Prafulla Wadaskar a écrit :
>
>
>> -----Original Message-----
>> From: u-boot-bounces at lists.denx.de
>> [mailto:u-boot-bounces at lists.denx.de] On Behalf Of Albert ARIBAUD
>> Sent: Tuesday, July 06, 2010 10:03 PM
>> To: u-boot at 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,
-- 
Albert.