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

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

[Stefan Herbrechtsmeier]

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.

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?

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.

Regards,
     Stefan

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

[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 ?
> 
> 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.
> 
> 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.
> 
> Regards,
>      Stefan

[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

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

[Stefan Herbrechtsmeier]

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.

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.
>>> 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.

Regards,
     Stefan

[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