Stefan Roese 9814fb272f mips: mt76xx: Implement new d-cache fix in last_stage_init() ... With commit 06985289d4 ("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>		2019-07-05 17:12:27 +02:00
..
cpu.c	mips: mt76xx: Implement new d-cache fix in last_stage_init()	2019-07-05 17:12:27 +02:00
ddr_calibrate.c	mips: rename mach-mt7620 to mach-mtmips	2019-05-03 16:43:11 +02:00
Kconfig	mips: rename mach-mt7620 to mach-mtmips	2019-05-03 16:43:11 +02:00
lowlevel_init.S	mips: rename mach-mt7620 to mach-mtmips	2019-05-03 16:43:11 +02:00
Makefile	mips: rename mach-mt7620 to mach-mtmips	2019-05-03 16:43:11 +02:00
mt76xx.h	mips: rename mach-mt7620 to mach-mtmips	2019-05-03 16:43:11 +02:00