Awesome, I was able to finally figure out a way to get the MDIO bus.
It requires a really rarely used last_stage_init() which does it right before the cmdline is live and then it doesn't panic.
Can I add your patch to my U-boot fork or you want to make a PR?
Yes, sure - you can add it.
Ahh, I have wasted most of the day on U-boot and got nowhere.
For whatever reason, if you try and get/probe/do whatever with the MDIO driver before the ethernet one is registered it will crap out with abort handler and reset.
I was trying to add a mini DSA driver for the Amethyst and finally figured out how to make the MDIO uclass also probe the child nodes for drivers but its unusable, its like it returns an invalid pointer for the MVMDIO and craps out.
Ahh, it was stupid DM model logic, dm_scan_fdt_dev must happen post probe and not post bind like in other buses, then it doesn't panic.
But now I gotta make it probe the driver somehow.
I started work on back-porting the switch chip driver to 5.10 kernel. So far, on 5.10, the driver code builds without errors - but it doesn't work 
Now I'm trying to figure out where exactly it broke.
Awesome, I am still pulling my hair with the U-boot MDIO related crashes.
I really want to avoid just hardcoding everything in the board file, but it looks like that will be the way as I just cannot figure out why it crashes and debug tools are pretty much non-existent for U-boot.
It's just insane, like even if you call dm_mdio_probe_devices() to intentionally just probe MDIO devices it will actually probe the MVMDIO and then crash.
Ok, so its crashing because its trying to access a list that was not initialized here:
And this is because that only gets initialized along with the networking which happens after the late_init call.
Ok, so after initializing the list in MDIO post bind then dm_scan_fdt_dev() works, I can see that DSA binds the CPU port but I still need to somehow probe the DSA driver.
The switch chip driver finally worked on the 5.10 kernel. I'm going to rest - been working on it since 5:00AM. Tomorrow I'll check the code again and share it here.
Great, I will continue on U-boot since its finally moving along somewhat.
Finally got the switch driver probed but I need to implement an MDIO driver for the internal bus as well, and as soon as that finishes probing it panics again.
This is just getting crazier and crazier
And finally it probes the MDIO driver as well.
I've managed to boot a 5.16 kernel with robimarko's mv88e6xxx SMI GPIO patch, but I don't seem to be able to get traffic over port 1 / the qca8081 - I can get a link and traffic over port 8, for example, but while I've managed to see a successful link indication from the qca8081 I don't then see any packets. Is there an additional patch necessary?
(l'm booting u-boot via tftp and then using that to boot the kernel from USB, in case that make a difference.)
It was the same for me with the at803x driver, they broke the in-band in it.
Wont be looking at it until U-boot works
Thanks, then I'm not missing something. I'll have a poke to see if there's anything obvious.
Ok, some progress finally.
Managed to expose the switch internal and external MDIO buses, now we can actually do some DSA finally (I expect more random crashes due to probe ordering)
And I finally figured out why the switch chip driver on the 5.10 kernel did not work correctly.
Its incorrect operation was expressed in the flood of all traffic(destined to the CPU port) to the other switch ports. The reason turned out to be the absence of static FDB records about the local MAC addresses of the CPU port. Further checking and debugging the switch driver led me to the conclusion that the reason is not in it. Events about adding local MAC addresses simply do not reach switch driver! In general, the fault was a partially applied patch in which the line was missing:
- if (test_bit(BR_FDB_LOCAL, &fdb->flags))
- return;
-
and because of this the DSA_NOTOFIER_FDB_ADD events did not work for local FDBs. And regardless of whether assisted_learning_on_cpu_port was enabled or not, assisted learning didn't work!
At now moment this BUG is affects all switch chip drivers that are use assisted cpu port learning !!!
And only in 5.13 kernel it was fixed!
Great work, was this introduced by the Topaz roaming patches?
net: bridge: switchdev: Include local flag in FDB notifications. It refers to the DSA subsystem and switch drivers.
Oh, I remember seeing that.
Vladimir did a lot of cleanups/improvements in the last 5 or 6 kernel releases.
DSA driver for switch chip Marvell 88E6393X(Amethyst), kernel 5.10 is ready.
Here is the list of patches You need for the latest version of OpenWRT.
I decided to check the version about packing the RouterBoot with the UCL NRV2B algorithm - without much hope for success!
But oddly enough, the first unpacking utility that I found: nrv2b was able to unpack it!
I took the RouterBoot file from RouterOS at /etc/70x0-7.2rc1.fwf and then do:
dd if=./70x0-7.2rc1.fwf of=./routerboot-7.2rc1.enc bs=4 skip=9
./nrv2b/nrv2b d routerboot-7.2rc1.enc ./routerboot-7.2rc1.dec
It remains to understand how this can be translated into assembly code ...
Awesome, I can tell you that it looks like Ghidra is able to decompile it into assembly just fine.
I tried it before the extraction a while ago and it failed miserably, but not decompiles fine.
We can actually see where their UART setting is broken in the bootargs function
Yes, the Ghidra with the indicated ARMv8 parses it quite well! Happy hacking for us!
