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

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

[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@denx.de>
Cc: Daniel Schwierzeck <daniel.schwierzeck@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;
 }
-- 
2.21.0

[U-Boot] [PATCH 2/2] mips: mt76xx: gardena-smart-gateway: Enable CONFIG_USE_PREBOOT

[Stefan Roese]

Enable CONFIG_USE_PREBOOT on for the gardena mt7688 platforms, so that
this feature can be used here.

Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
---
 configs/gardena-smart-gateway-mt7688-ram_defconfig | 1 +
 configs/gardena-smart-gateway-mt7688_defconfig     | 1 +
 2 files changed, 2 insertions(+)

diff --git a/configs/gardena-smart-gateway-mt7688-ram_defconfig b/configs/gardena-smart-gateway-mt7688-ram_defconfig
index e09950637f..ec47beaf1d 100644
--- a/configs/gardena-smart-gateway-mt7688-ram_defconfig
+++ b/configs/gardena-smart-gateway-mt7688-ram_defconfig
@@ -12,6 +12,7 @@ CONFIG_IMAGE_FORMAT_LEGACY=y
 CONFIG_OF_STDOUT_VIA_ALIAS=y
 CONFIG_USE_BOOTCOMMAND=y
 CONFIG_BOOTCOMMAND="cp.b 83000000 84000000 10000 && dhcp uEnv.txt && env import -t ${fileaddr} ${filesize} && run do_u_boot_init; reset"
+CONFIG_USE_PREBOOT=y
 CONFIG_SYS_CONSOLE_INFO_QUIET=y
 CONFIG_VERSION_VARIABLE=y
 CONFIG_BOARD_EARLY_INIT_F=y
diff --git a/configs/gardena-smart-gateway-mt7688_defconfig b/configs/gardena-smart-gateway-mt7688_defconfig
index ad0db2e723..cdc5221d6a 100644
--- a/configs/gardena-smart-gateway-mt7688_defconfig
+++ b/configs/gardena-smart-gateway-mt7688_defconfig
@@ -15,6 +15,7 @@ CONFIG_IMAGE_FORMAT_LEGACY=y
 CONFIG_OF_STDOUT_VIA_ALIAS=y
 CONFIG_USE_BOOTCOMMAND=y
 CONFIG_BOOTCOMMAND="cp.b 83000000 84000000 10000 && dhcp uEnv.txt && env import -t ${fileaddr} ${filesize} && run do_u_boot_init; reset"
+CONFIG_USE_PREBOOT=y
 CONFIG_SYS_CONSOLE_INFO_QUIET=y
 CONFIG_VERSION_VARIABLE=y
 CONFIG_BOARD_EARLY_INIT_F=y
-- 
2.21.0

[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@denx.de>
> Cc: Daniel Schwierzeck <daniel.schwierzeck@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

[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@denx.de>
>> Cc: Daniel Schwierzeck <daniel.schwierzeck@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