Move this out of the common header and include it only where needed. In
a number of cases this requires adding "struct udevice;" to avoid adding
another large header or in other cases replacing / adding missing header
files that had been pulled in, very indirectly. Finally, we have a few
cases where we did not need to include <asm/global_data.h> at all, so
remove that include.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
CONFIG_SYS_SDRAM_BASE points to cached memory, i.e. KSEG0, which is not
suitable for detecting memory size.
Replace CONFIG_SYS_SDRAM_BASE with KSEG1, and make dram_init() always do
memory size detection in any stage.
Reviewed-by: Stefan Roese <sr@denx.de>
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
This patch rewrites the mtmips architecture with the following changes:
1. Move MT7628 soc parts into a subfolder.
2. Lock parts of D-Cache as temporary stack.
3. Reimplement DDR initialization in C language.
4. Reimplement DDR calibration in a clear logic.
5. Add full support for auto size detection for DDR1 and DDR2.
6. Use accurate CPU clock depending on the input xtal frequency for timer
and delay functions.
Note:
print_cpuinfo() has incompatible parts with MT7620 so it's moved into
mt7628 subfolder.
Reviewed-by: Stefan Roese <sr@denx.de>
Reviewed-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
At present dm/device.h includes the linux-compatible features. This
requires including linux/compat.h which in turn includes a lot of headers.
One of these is malloc.h which we thus end up including in every file in
U-Boot. Apart from the inefficiency of this, it is problematic for sandbox
which needs to use the system malloc() in some files.
Move the compatibility features into a separate header file.
Signed-off-by: Simon Glass <sjg@chromium.org>
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>
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.
To fix this issue, this patch now removes the old workaround and selects
CONFIG_SYS_MALLOC_CLEAR_ON_INIT for ARCH_MTMIPS. With this option the
complete malloc area is initialized with zeros (cache lines are touched).
Testing has shown that this also fixes the issue on the MT7688 boards.
Signed-off-by: Stefan Roese <sr@denx.de>
Suggested-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Cc: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Currently mach-mt7620 contains only support for mt7628. To avoid confusion,
rename mach-mt7620 to mach-mtmips, which means MediaTek MIPS platforms.
MT7620 and MT7628 should be distinguished by SOC_MT7620 and SOC_MT7628
because they do not share the same lowlevel codes.
Dependencies of four drivers are changed to SOC_MT7628 as these drivers
are only used by MT7628.
Cc: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
