On Mon, Jul 12, 2021 at 07:27:11PM +0200, Marek Behun wrote: > Hi Vladimir, > > On Mon, 12 Jul 2021 17:01:21 +0000 > Vladimir Oltean <vladimir.olt...@nxp.com> wrote: > > > Hi Marek, > > > > On Mon, Jul 12, 2021 at 05:40:59PM +0200, Marek Behun wrote: > > > Vladimir, on what mv88e6xxx devices are you developing this stuff? > > > Do you use Turris MOX for this? > > > > I didn't develop the Marvell stuff nor did I come up with the idea > > there, Tobias did. I also am not particularly interested in supporting > > this for Marvell beyond making sure that the patches look simple and > > okay, and pave the way for other drivers to do the same thing. > > > > I did my testing using a different DSA driver and extra patches which > > I did not post here yet. I just reposted/adapted Tobias' work because > > mv88e6xxx needs less work to support the TX data plane offload, and this > > framework does need a first user to get accepted, so why delay it any > > further if mv88e6xxx needs 2 patches whereas other drivers need 30. > > > > I did use the MOX for some minimal testing however, at least as far as > > I could - there is this COMPHY SERDES bug in the bootloader which makes > > the board fail to boot, and now the device tree workaround you gave me > > does not appear to bypass the issue any longer or I didn't reaply it > > properly. > > Sorry about that. Current upstream U-Boot solves this issue, but we did > not release official update yet because there are still some things that > need to be done. We have some RCs, though. > > If you are interested, it is pretty easy to upgrade: > - MTD partition "secure-firmware" needs to be flashed with > > https://gitlab.nic.cz/turris/mox-boot-builder/uploads/8d5a17fae8f6e14ca11968ee5174c7ca/trusted-secure-firmware.bin > (this file needs to be signed by CZ.NIC) > - MTD partition "a53-firmware" (or "u-boot" in older DTS) needs to be > flashed with > https://secure.nic.cz/files/mbehun/a53-firmware.bin > (this file can be built by users themselves)
Thanks. This worked in the sense that I could flash the trust zone firmware and U-Boot, and net-next will boot without hanging, but now the board is in a boot loop, due to what appears to be watchdog timer expiration. This happens regardless of whether CONFIG_ARMADA_37XX_WATCHDOG is set to y or n in the booted kernel.
