Dear Jens,

Am 03.12.2010 um 18:09 schrieb Jens Scharsig:

> Am 2010-12-03 08:26, schrieb Andreas Bießmann:
>> SMRDATA in a/a/c/arm920t/at91/lowlevel_init.c has wrong size. This patch
>> reduces it to correct size of 40 byte.
>> 
>> Signed-off-by: Andreas Bießmann <biessm...@corscience.de>
>> ---
>> Dear all,
>> 
>> I thougt about a problem in lowlevel_init() cause of errornous booting from
>> NOR flash on at91rm9200ek last night . This morning I detected this, but the
>> patch is untested!
>> 
>> I can not test it til sunday, if one can test it before please send a mail
>> (Jens?).
> 
> Can you describe the symptoms?

at91rm9200ek booting from NOR flash does not work with v2010.12-rc2 plus 
patchset 'get at91rm9200ek working with ARM relocation'. I can boot the 
at91rm9200ek_ram_config build with JTAG and confirm that no BSS values get 
written from beginning of board_init_f() til calling of relocate_code() cause 
of a modified version of the test-patch 'arm:board_init_f(): mirror BSS and 
check after each init_fnc()'.
Cause of the fact that NOR booting and 'SDRAM booting' via JTAG only differ in 
TEXT_BASE and SKIP_LOWLEVEL_INIT I thought there might be an error in 
lowlevel_init(). I did not find any statement in  
a/a/c/arm920t/at91/lowlevel_init.c which may fail the boot, but I found out the 
SMRDATA section is wrongly handled.

The SMRDATA is a list of <ADDRESS>:<VALUE> which is handled in pllloop() to 
initially setup PMC and SMC. However the register setup just before pllloop() 
is wrong (SMRDATA is not 80 byte big, it is 40 byte!) and therefore we take 
some data from SMRDATA1 section (again address:value list for SDRAM setup). 
Cause of that we write some SDRAM configuration registers twice. I assume the 
wrong parameter does not break the setup (maybe it does ... thats to find out). 
Nevertheless the setup is wrong. Beside that the whole lowlevel_init() for 
arm920t/at91 is not really well coded, this could be done better ...

> I will test tomorrow?

It would be great if you can test that pllloop thing to indicate the wrong 
counter (80 instead of 40) did (or not) break anything. So the question is do 
we need that specific patch in v2010.12 to get arm920t/at91 boards working or 
is it a 'nice to have' for future releases, e.g. when we do a complete rework 
of the lowlevel_init() for arm920t/at91.

regards

Andreas Bießmann

_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Reply via email to