By the way, for my experiments, I use the switch driver as a kernel module, and noticed that when the system just starts and this module is not running at all, the network (eth0) is works! That is, the switch is not to blame for the fact that the network in U-Boot does not work. By default, it simply passes all traffic and that's it! So, the problem occurs by one of the incorrectly configured network adapter registers!
Yes, that was my experience as well that it worked without a driver as well.
P0_MODE that I dumped is 1101 or 0xd which makes sense as that puts it in 10G mode.
Now let's see what comes when it's booted from the network, and we get the same 0xd but networking doesn't work.
The one thing that would kind of make sense is Errata 5.2:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/net/dsa/mv88e6xxx?h=v5.16&id=93fd8207bed80ce19aaf59932cbe1c03d418a37d
Well, the switch has nothing to do with it. The network adapter that is inside the SoC is to blame.
0xd & MV88E6352_G2_SCRATCH_CONFIG_DATA2_P0_MODE_MASK == 0x1
val = 0xd;
p0_mode = val & MV88E6352_G2_SCRATCH_CONFIG_DATA2_P0_MODE_MASK;
if (p0_mode == 0x01 || p0_mode == 0x02)
return -EBUSY;
Hm, that P0_MODE check doesn't make sense to me at all.
All its doing is checking for 0 or larger and they are rejecting any mode other than 0 as invalid?
Which is stupid on MV88E6393X as it says that GPIO 9 and 10 (SMI pins) are dependant only on CPU_MGD Configuration
Apparently this check makes some sense, but Mikrotik was not aware of the fact that this is how resistors should be installed? Or is it still a bug in the driver itself?
This maybe makes sense for the older switches for which they added it.
But on MV88E6393X it says that GPIO 9 and 10 (SMI pins) are dependant only on CPU_MGD Configuration which is another config pin
Ah, well, it means that you just need to put a check on the version of the switch! There, further in this function, there is still an interesting code about no_cpu!
This means that you don't actually need to touch it at all, cause the switch already sets the MDIO/MDC pins based on the CPU_MGD which controls whether the switch is connected to a CPU for management or if its standalone with an EEPROM that contains the config.
I checked at the register 0x2 scratch which tells allows configuring the SMI PHY pins (MDIO) is set to 0 which means use them as MDIO.
So, calling the mv88e6xxx_g2_scratch_gpio_set_smi is not valid at all for Amethyst
It is clear that in this case this is just a bug in the switch driver and there it is necessary to check for a new version of the switch chip and not call this function for it at all.
Yes, or just make it part of the driver OPS like they already do GPIO ops:
.gpio_ops = &mv88e6352_gpio_ops,
Okay, that's sorted out. What do you think about the second PHY(addr: 0x1, physid: 8aa2:1ac8) on the switch's SMI bus? Is it PHY for SFP ?
Its the SERDES of the QCA8081 PHY, QCA just exposes it on a different adress
2 Likes
Okay, thanks, I didn't know that. Well, then with QCA8081 it looks like everything. It works correctly at 1000M and 100M with a generic PHY driver. Tomorrow I'll try to find out what exactly in registers of the network adapter (not the switch chip) breaks the network in u-boot.
Awesome, I will backport the proper PHY driver and dig out my Octeon TX2 reference board as it has 2.5G port to see whether that works (As if 2500Base-X is set it doesn't work currently with the generic driver).
I will also start refining the U-boot and patching the DSA to add the SMI pinctrl OP to the DSA driver.
2 Likes
I have backported the QCA8081 driver, but with it, it doesn't work at all.
SGMII or 2500Base-X modes don't have RX at all and if in-band is used then Phylink PCS MAC state will fail.
This is another weird thing, too tired now to actually further debug.
Yesterday I didn't work on it, I was going to an EHF EURO match so I did a lot of traveling, tomorrow will be the same.
Today I will work some more on it in the evening.
Folks, my RB5009 arrived at the start of this week and I've successfully used @adron's jailbreak (using dnsmasq on a Pi, had to use bootp rather than dhcp but other than that it worked) to get root access. Have hooked a serial console up and managed to get u-boot to load over the network, but I'm failing to boot via UART. I'm using the download-serial.sh script, starting it up before powering up the router but it never gets as far as trying to xmodem the u-boot image. What am I missing? Want to make sure I have a guaranteed way back in before I explore further!
You cant just boot the U-boot directly, you must boot the ATF+U-boot flash-image.bin that gets produced when building ATF.
Right, I have a flash-image.bin with the ATF / DDR / BL2 bits compiled up, but the script never even gets as far as trying to xmodem it across so I think I'm missing something more fundamental about the sending process?
I would suggest using the following script:
That's what I have been using and it worked really well for me, obviously you can go even simpler, make a pattern file and using minicom spam BootROM with it and then use xmodem but this makes it way simpler.
It will even open up the serial terminal after it loads the image.
But make sure that you dont have serial terminal that is using the serial device that you want to upload through, that will break xmodem completely.
Many thanks. That script seems better - I think part of my issue was timing the power on of the device with the BootROM spam. Now successfully booting a self-compiled u-boot image via UART.