On 13.05.16 18:28, York Sun wrote:
On 05/13/2016 05:21 AM, Alexander Graf wrote:
While trying something completely different I saw the DDR probe hang on boot reliably depending on how big my code ended up. Adding simple "nop" instructions in my code (completely unrelated) flow made the DDR probe work again.
So we're accessing some RAM - probably the page table - and rely on the cache to give us a correct view of the world while DRAM gets initialized.
This patch just disables dcache while we're initializing the memory controller, resolving all system hangs for me so far.
Signed-off-by: Alexander Graf agraf@suse.de
I guess the "real" solution would be to find out what exactly gets accessed in such a case and then just map whatever it is into SRAM. Or maybe qixis_reset doesn't fully reset something in the cache tolopogy and that wants to get flushed out when we don't have ram yet? I don't know...
board/freescale/ls2080a/ddr.c | 2 ++ board/freescale/ls2080aqds/ddr.c | 2 ++ board/freescale/ls2080ardb/ddr.c | 2 ++ 3 files changed, 6 insertions(+)
diff --git a/board/freescale/ls2080a/ddr.c b/board/freescale/ls2080a/ddr.c index 1827ddc..a02aa64 100644 --- a/board/freescale/ls2080a/ddr.c +++ b/board/freescale/ls2080a/ddr.c @@ -165,7 +165,9 @@ phys_size_t initdram(int board_type) puts("Initializing DDR....");
puts("using SPD\n");
- dcache_disable(); dram_size = fsl_ddr_sdram();
- set_sctlr(get_sctlr() | (CR_C|CR_M));
Alex,
I can't agree with the proposed change. Having dcache has major speed boost during initializing, especially when we run it on an emulator. As you suggested in the note, the root cause needs to be identified. Qixis_reset has nothing to do with cache. It is a board-level FPGA control.
Yes, this patch is mostly FYI. I'm more than happy to not have it applied - FWIW it's sheer luck that my compiler happened to emit the instructions in the right place for things to work without any of the other patches ;). So we might as well rely on luck with the others applied.
Alex