[U-Boot] [PATCH] at91rm9200: fix lowlevel_init() SMRDATA size

[Albert ARIBAUD <albert.aribaud@free.fr>]

Le 04/12/2010 12:37, Jens Scharsig a ?crit :
> Dear Andreas,
>
>> 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.
>>
> I don't think that this will be fix the nor boot problems.
> In my opinion, we have some SOC specific problems:
>
> 1. In start.s the vector table is relocated from _start to 0x00. But at this time 0x00 is remaped to nor flash.

Hmm... This copy (not a relocation) should be done after cpu_init_crit / 
lowlevel_init, which should have at least configured some RAM; but you 
are right that mapping to 0 is somewhat arbitrary, since the reset 
vectors could be some other places (0xffff0000, for instance).

> 2. On NOR boot we have no RAM at 0x00, until SRAM is remaped whit Remap Control Register. Nowhere fount in source.

Should be done in cpu_init_crit/lowlevel_init.

> 3. On start NOR is mapped to address 0x0. So if we use 0x1000000 as textbase the board hangs after relocation.

Hmm... Is the board forced to boot with NOR at 0? If it is then maybe 
you should consider mapping RAM at the top of the address space (I'm 
assuming that the exception vectors can map there). If it's not (e.g. 
boot pins allow a top/bottom placement of the NOR flash and the reset 
vector), you have the choice and can start with NOR at top and RAM at 
bottom.

> 4. I can't found any code to setup CS0 timings (use (slow) defaults only)
>
> But, I can not check my thesis, until I get back my JTAG debugger end of next week.
>
>  regard

Amicalement,
-- 
Albert.