[U-Boot] [PATCH 1/2] mips: mt76xx: Implement new d-cache fix in last_stage_init()

[Daniel Schwierzeck]

Am 20.05.19 um 17:22 schrieb Stefan Roese:
> With commit 06985289d452 ("watchdog: Implement generic watchdog_reset()
> version") the init sequence has changed in arch_misc_init(), resulting
> in a re-appearance of the d-cache issue on MT7688 boards (e.g. gardena).
> When this happens, the first (or sometimes later ones as well) TFTP
> command hangs and does not complete correctly. This leads to the
> assumption that the d-cache is not in a clean state once the ethernet
> driver is called (d-cache is used here for the buffers). The old work-
> around with the cache flush somehow does not work any more now with
> the new code change.
> 
> Testing has shown, that copying a 64KiB area in DDR at a very late
> bootup time, directly before calling into the prompt, fixes this issue.
> Flushing of the complete d-cache does not seem to necessary, as this
> copy alone seems to fix this problem.
> 
> Signed-off-by: Stefan Roese <sr at denx.de>
> Cc: Daniel Schwierzeck <daniel.schwierzeck at gmail.com>
> ---
>  arch/mips/Kconfig           |  2 +-
>  arch/mips/mach-mtmips/cpu.c | 21 ++++++++++++++++-----
>  2 files changed, 17 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
> index 9cf8e9800d..e3e7945567 100644
> --- a/arch/mips/Kconfig
> +++ b/arch/mips/Kconfig
> @@ -84,7 +84,7 @@ config ARCH_MTMIPS
>  	select DM_SERIAL
>  	imply DM_SPI
>  	imply DM_SPI_FLASH
> -	select ARCH_MISC_INIT
> +	select LAST_STAGE_INIT
>  	select MIPS_TUNE_24KC
>  	select OF_CONTROL
>  	select ROM_EXCEPTION_VECTORS
> diff --git a/arch/mips/mach-mtmips/cpu.c b/arch/mips/mach-mtmips/cpu.c
> index fcd0484a6d..7afc2c5940 100644
> --- a/arch/mips/mach-mtmips/cpu.c
> +++ b/arch/mips/mach-mtmips/cpu.c
> @@ -69,17 +69,28 @@ int print_cpuinfo(void)
>  	return 0;
>  }
>  
> -int arch_misc_init(void)
> +int last_stage_init(void)
>  {
> +	void *src, *dst;
> +
> +	src = malloc(SZ_64K);
> +	dst = malloc(SZ_64K);
> +	if (!src || !dst) {
> +		printf("Can't allocate buffer for cache cleanup copy!\n");
> +		return 0;
> +	}
> +
>  	/*
>  	 * It has been noticed, that sometimes the d-cache is not in a
>  	 * "clean-state" when U-Boot is running on MT7688. This was
>  	 * detected when using the ethernet driver (which uses d-cache)
> -	 * and a TFTP command does not complete. Flushing the complete
> -	 * d-cache (again?) here seems to fix this issue.
> +	 * and a TFTP command does not complete. Copying an area of 64KiB
> +	 * in DDR at a very late bootup time in U-Boot, directly before
> +	 * calling into the prompt, seems to fix this issue.
>  	 */
> -	flush_dcache_range(gd->bd->bi_memstart,
> -			   gd->bd->bi_memstart + gd->ram_size - 1);
> +	memcpy(dst, src, SZ_64K);
> +	free(src);
> +	free(dst);
>  
>  	return 0;
>  }
> 

have you also tried with CONFIG_SYS_MALLOC_CLEAR_ON_INIT? This will run
a memset on the whole malloc area in mem_malloc_init(). This would also
cause a cache line update for all heap memory. May this helps too and
this ugly workaround can go away ;)

-- 
- Daniel