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

[Stefan Roese]

On 22.05.19 17:58, Daniel Schwierzeck wrote:
> 
> 
> 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?

Not yet (AFAIR).

> 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 ;)

Very nice idea. Testing has shown that this also fixes the cache
startup issue on my MT7688 GARDENA board. So please drop this patch.
I'll send a v2 of this series with the appropriate Kconfig change.

Many thanks for your review and input. :)

Thanks,
Stefan