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 <ag...@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.
York
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
