bcm63xx/u-boot/arch/mips, branch master

mips: mt76xx: Implement new d-cache fix in last_stage_init()

2019-07-05T15:12:27Z

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 Cc: Daniel Schwierzeck

mips: mt76xx: Remove cache workaround and select SYS_MALLOC_CLEAR_ON_INIT

2019-05-24T13:55:17Z

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. 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 Suggested-by: Daniel Schwierzeck Cc: Daniel Schwierzeck

net: mscc: ocelot: Update DTS for Luton pcb90

2019-05-03T14:46:36Z

Update device tree for luton to add support for luton pcb90. This pcb has 24 ports from which 12 ports are connected to SerDes6G. Signed-off-by: Horatiu Vultur

mips: rename mach-mt7620 to mach-mtmips

2019-05-03T14:43:11Z

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 Reviewed-by: Stefan Roese Signed-off-by: Weijie Gao

net: mscc: ocelot: Update DTS for Ocelot pcb120.

2019-05-03T14:42:24Z

Update device tree for ocelot to add support for ocelot pcb120. Signed-off-by: Horatiu Vultur

net: mscc: ocelot: Update network driver for pcb120

2019-05-03T14:42:23Z

Update Ocelot network driver to have support also for pcb120. Signed-off-by: Horatiu Vultur

arch: mips: Update initrd_start and initrd_end

2019-05-03T14:42:23Z

Microsemi SoC defines CONFIG_SYS_SDRAM_BASE to be 0x80000000, which represents the start of kseg0 and represents a virtual address. Meaning that the initrd_start and initrd_end point somewhere kseg0. When these parameters are passed to linux kernel through DT they are pointing somewhere in kseg0 which is a virtual address but linux kernel expects the addresses to be physical addresses(in kuseg) because it is converting the physical address to a virtual one. Therefore update the uboot to pass the physical address of initrd_start and initrd_end by converting them using the function virt_to_phys before setting up the DT. Signed-off-by: Horatiu Vultur Reviewed-by: Daniel Schwierzeck

MSCC: delete obsolete reference to MSCC_BITBANG_SPI_GPIO

2019-05-03T14:42:23Z

Remove "select MSCC_BITBANG_SPI_GPIO" since Kbuild option was deleted back in commit ace9c103df2875d2b435dbd7b36618020edfd1c0: commit ace9c103df2875d2b435dbd7b36618020edfd1c0 Author: Lars Povlsen Date: Tue Jan 8 10:38:35 2019 +0100 mips: gpio: mscc: Obsoleted gpio-mscc-bitbang-spi.c

net: mscc: serval: Add ethernet nodes for Serval

2019-05-03T14:42:23Z

Add ethernet nodes for Serval SoCs family. There are 2 pcb in this family: pcb105 and pcb106. Signed-off-by: Horatiu Vultur

mips: mscc: serval: Fix reset

2019-05-03T14:42:23Z

In case the ddr training was failing, it couldn't reset, it was just hanging. Therefore reimplement it, so when ddr training is failing it would call _machine_restart, which power downs the DDR and does a force reset. Signed-off-by: Horatiu Vultur