[U-Boot] pxa: Passing ATAGs to kernel don't work

[Stefan Herbrechtsmeier]

Am 09.08.2011 21:46, schrieb Marek Vasut:
> On Tuesday, August 09, 2011 03:14:38 PM Stefan Herbrechtsmeier wrote:
>> Hi,
>>
>> after porting my board support from u-boot 2009.11 to 2011.06
>> together with adding the relocation support
>> the ATAGs passing don't work any more.
>>
>> I have add icache_disable() and dcache_disable()
>> to my board_init() like on other pxa boards.
>>
>> It looks like the mapping of the Dcache as RAM is not cleared
>> and will be re-enabled by the kernel.
> Thanks for tracing this, can you submit a patch ?
I have only avoid the problem and don't really fix the problem,
as I am not familiar with the MMU configuration and the relocation.

I think the right solution will be to clean up the MMU at the end of the 
relocation
and maybe disable it, instead of doing this at board_init().

Should it be functional to add the following MMU initialisation from an 
other start.S
after the clear_bss in start.S or should it be enough to flush the TLB
and disable the D-cache?

clear_mmu:
     /*
      * flush v4 I/D caches
      */
     mov    r0, #0
     mcr    p15, 0, r0, c7, c7, 0    /* flush v3/v4 cache */
     mcr    p15, 0, r0, c8, c7, 0    /* flush v4 TLB */

     /*
      * disable MMU stuff and caches
      */
     mrc    p15, 0, r0, c1, c0, 0
     bic    r0, r0, #0x00002300    @ clear bits 13, 9:8 (--V- --RS)
     bic    r0, r0, #0x00000087    @ clear bits 7, 2:0 (B--- -CAM)
     orr    r0, r0, #0x00000002    @ set bit 2 (A) Align
     orr    r0, r0, #0x00001000    @ set bit 12 (I) I-Cache
     mcr    p15, 0, r0, c1, c0, 0

If I understand the code correct, the command is wrong, as the I-Cache 
is enabled.
>> If I change the initial RAM mapping from first SDRAM partition start
>> address to second unused SDRAM partition start address the ATAGs passing
>> works.
>>
>> Can somebody confirm that the ATAGs passing works on u-boot 2011.06 for
>> a pxa board.
>>
>> Is there any reason, that the initial RAM is mapped to SDRAM start
>> address range?
> I think now it can be changed. Maybe there was something about OneNAND IPL, I'm
> not really sure anymore.
What is the best value to use for the initial RAM address mapping?
>> Addition there is a bug in pxa_dram_init as it is called before relocation
>> and want to trigger some refresh cycles by write some values to the SDRAM
>> start address range but instead writes to the mapped initial RAM.
> Patch is welcome please.
Or should I keep the initial RAM mapping to SDRAM  start address
and move the SDRAM refresh cycles trigger address behind the mapped area.

Regards,
     Stefan