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

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

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

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

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

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
participants (2)
-
Marek Vasut
-
Stefan Herbrechtsmeier