[U-Boot] [PATCH] mips: mt76xx: Implement new d-cache fix in last_stage_init()
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.
Unfortunately adding CONFIG_SYS_MALLOC_CLEAR_ON_INIT also did not fix this issue. With v2019.07-rc3 it shows again. The time of accessing the data seems to be very important here. It needs to be "very late" in the boot process.
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 | 26 ++++++++++++++++++++++++++ 2 files changed, 27 insertions(+), 1 deletion(-)
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index 5cb9bdf2ee..e3e7945567 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -84,13 +84,13 @@ config ARCH_MTMIPS select DM_SERIAL imply DM_SPI imply DM_SPI_FLASH + select LAST_STAGE_INIT select MIPS_TUNE_24KC select OF_CONTROL select ROM_EXCEPTION_VECTORS select SUPPORTS_CPU_MIPS32_R1 select SUPPORTS_CPU_MIPS32_R2 select SUPPORTS_LITTLE_ENDIAN - select SYS_MALLOC_CLEAR_ON_INIT select SYSRESET
config ARCH_JZ47XX diff --git a/arch/mips/mach-mtmips/cpu.c b/arch/mips/mach-mtmips/cpu.c index b0a6397d68..7afc2c5940 100644 --- a/arch/mips/mach-mtmips/cpu.c +++ b/arch/mips/mach-mtmips/cpu.c @@ -68,3 +68,29 @@ int print_cpuinfo(void)
return 0; } + +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. 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. + */ + memcpy(dst, src, SZ_64K); + free(src); + free(dst); + + return 0; +}
Hi Daniel,
On 28.05.19 08:11, Stefan Roese wrote:
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.
Unfortunately adding CONFIG_SYS_MALLOC_CLEAR_ON_INIT also did not fix this issue. With v2019.07-rc3 it shows again. The time of accessing the data seems to be very important here. It needs to be "very late" in the boot process.
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
Could you please review this patch and if possible push it for the upcoming release? Without it, we experience the ugly hickups in the tftp tranfers again.
Many thanks, Stefan
arch/mips/Kconfig | 2 +- arch/mips/mach-mtmips/cpu.c | 26 ++++++++++++++++++++++++++ 2 files changed, 27 insertions(+), 1 deletion(-)
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index 5cb9bdf2ee..e3e7945567 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -84,13 +84,13 @@ config ARCH_MTMIPS select DM_SERIAL imply DM_SPI imply DM_SPI_FLASH
- select LAST_STAGE_INIT select MIPS_TUNE_24KC select OF_CONTROL select ROM_EXCEPTION_VECTORS select SUPPORTS_CPU_MIPS32_R1 select SUPPORTS_CPU_MIPS32_R2 select SUPPORTS_LITTLE_ENDIAN
select SYS_MALLOC_CLEAR_ON_INIT select SYSRESET
config ARCH_JZ47XX
diff --git a/arch/mips/mach-mtmips/cpu.c b/arch/mips/mach-mtmips/cpu.c index b0a6397d68..7afc2c5940 100644 --- a/arch/mips/mach-mtmips/cpu.c +++ b/arch/mips/mach-mtmips/cpu.c @@ -68,3 +68,29 @@ int print_cpuinfo(void)
return 0; }
+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. 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.*/- memcpy(dst, src, SZ_64K);
- free(src);
- free(dst);
- return 0;
+}
Viele Grüße, Stefan
Hi Stefan,
Am 05.07.19 um 16:42 schrieb Stefan Roese:
Hi Daniel,
On 28.05.19 08:11, Stefan Roese wrote:
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.
Unfortunately adding CONFIG_SYS_MALLOC_CLEAR_ON_INIT also did not fix this issue. With v2019.07-rc3 it shows again. The time of accessing the data seems to be very important here. It needs to be "very late" in the boot process.
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
Could you please review this patch and if possible push it for the upcoming release? Without it, we experience the ugly hickups in the tftp tranfers again.
Many thanks, Stefan
sorry, I forgot about that one ;)
I'll send a PR shortly.
arch/mips/Kconfig | 2 +- arch/mips/mach-mtmips/cpu.c | 26 ++++++++++++++++++++++++++ 2 files changed, 27 insertions(+), 1 deletion(-)
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index 5cb9bdf2ee..e3e7945567 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -84,13 +84,13 @@ config ARCH_MTMIPS select DM_SERIAL imply DM_SPI imply DM_SPI_FLASH + select LAST_STAGE_INIT select MIPS_TUNE_24KC select OF_CONTROL select ROM_EXCEPTION_VECTORS select SUPPORTS_CPU_MIPS32_R1 select SUPPORTS_CPU_MIPS32_R2 select SUPPORTS_LITTLE_ENDIAN - select SYS_MALLOC_CLEAR_ON_INIT select SYSRESET config ARCH_JZ47XX diff --git a/arch/mips/mach-mtmips/cpu.c b/arch/mips/mach-mtmips/cpu.c index b0a6397d68..7afc2c5940 100644 --- a/arch/mips/mach-mtmips/cpu.c +++ b/arch/mips/mach-mtmips/cpu.c @@ -68,3 +68,29 @@ int print_cpuinfo(void) return 0; }
+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. 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. + */ + memcpy(dst, src, SZ_64K); + free(src); + free(dst);
+ return 0; +}
Viele Grüße, Stefan
participants (2)
-
Daniel Schwierzeck -
Stefan Roese