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

[Marek Vasut]

On Wednesday, August 17, 2011 12:01:02 PM Stefan Herbrechtsmeier wrote:
> Am 10.08.2011 12:47, schrieb 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.
> 
> I looks like the main fault was the missing flush during cache disable
> because
> flush_cache() is empty for the pxa architecture.

Check Hong Xu's efforts on ARM926EJS caches ... maybe you can implement the 
flushing for pxa :)

> 
> I have add a define CONFIG_SYS_INIT_RAM_ADDR for the initial RAM in cache.
> Additional I have fix the define of CONFIG_SYS_INIT_SP_ADDR.
> I have move the dcache und mmu disable to the start.S at the end of the
> relocation
> and add a flush. This prevent people to enable the dcache by removing the
> dcache_disable() without setup the MMU correct.
> 
> >>> 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?
> 
> I am now using 0xc0000000 as it is above the SDRAM range,
> but 0xa0000000 now works as well.

Ack
> 
> >>> 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.
> 
> I leave it as it is, because I move the initial RAM address.
> 
> I will commit patches for this and some USB host and device fixes,
> when I have some time to port my change to the git HEAD and
> change all pxa boards accordingly.

Thanks!
> 
> Regards,
>      Stefan