Yep, I started on it yesterday evening. But I also played some more with my GS110EMX which has an 88E6390X switch were so far I also could not get them SERDES to play nice. There, I even get them PHYs all detected but so far I could not convince them to actually transfer any data. There are also further patches available which as far as I can tell haven't even made it into -next as of yet. Let's see...
Hm, it should work just fine in with 5.15 as they backported the errata and 2500Base-X fixes so 88E6393X and the related Amethyst should work just fine.
88E6390X on the other hand is a completely different family (Peridot)
Do you have a datasheet for the 88E6393X? I tried googling it but couldn't find anything.
Yeah, it's a pity Marvell also keeps those under tight wraps. My company even has NDAs in place but you only get access to very project specific stuff.
Nice work digging into the hardware.
I remember ius telling me that RouterBoot (fwf, and on NOR), used UCL NRV2B for compression. You may be able to see what RouterBoot is doing (with NAND boot) to the switch through decompiling it after decompressing it. Otherwise, maybe the ELF netboot file that netinstall pushes for this device?
I considered replacing the primary RouterBoot with u-boot. Not sure if worth the trouble, but that way RouterBoot might still be there for the softcfg setting force-backup-routerboot, or hold reset button before poweron.
1 Like
RoS dmesg:
[ 23.928051] switch0: open @3
[ 23.930920] amethyst_reset mac:(____ptrval____)
[ 23.952338] switch0: amethyst init serdes0 mode:d
[ 23.952533] switch0: amethyst init serdes9 mode:a
[ 23.952727] switch0: amethyst init serdes10 mode:d
[ 23.975414] eth0: phy reg access: 166400ns
[ 24.052011] IPv6: ADDRCONF(NETDEV_CHANGE): switch0: link becomes ready
[ 24.127848] eth0: Caught tx_queue_len zero misconfig
[ 24.127999] eth1: Caught tx_queue_len zero misconfig
[ 24.128129] eth2: Caught tx_queue_len zero misconfig
[ 24.128257] eth3: Caught tx_queue_len zero misconfig
[ 24.128383] eth4: Caught tx_queue_len zero misconfig
[ 24.128509] eth5: Caught tx_queue_len zero misconfig
[ 24.128634] eth6: Caught tx_queue_len zero misconfig
[ 24.128759] eth7: Caught tx_queue_len zero misconfig
[ 24.128883] eth8: Caught tx_queue_len zero misconfig
The line of particular interest is: eth0: phy reg access: 166400ns
This line is contained only in file /lib/modules/5.6.3/drivers/net/phy_helper.ko
That is, it is in this file the magical functionality of access to 8081 is implemented!
Like @sumo said, its not public.
You need to have an NDA as well as request acess to it, I have it by accident due to previous projects.
@adron Yes, the PHY helper kernel module has the 8081 ops that the amethyst module then calls
Can you share it with me? Or did you personally sign the NDA?
Unfortunately, I cant share it.
The company I work for has an NDA with Marvell so I have Extranet acess through them
@johnth Are you sure it's compressed?
Cause, I don't think that ATF supports anything like that, it should be just a binary (machine code) FWF
Yes, I understand.
I managed to google datasheet for the MV88E609 switch. It is also from MV88E6XX series. I will try to figure out with it help. Today I began to study the work of the DSA subsystem for Marvell switches. I want to extract the necessary sequences of commands(registers and its values) for 88E6393X switch that are needed for it basic initialization and, on their basis, make the switch init for u-boot.
1 Like
I seem to have found how to communicate with 8081. It is connected to the MDIO bus of the switch chip (external!). Here's a little hack print result - for test. PHY addresses are read from 0 to 7 for MII_PHYSID1 && MII_PHYSID2 registers.
AND! QCA8081_PHY_ID == 0x004DD101 is QCA8081 PHY ID !!!
[ 732.944432] OWL: read_data_c22 external: 0, addr: 0, rv: 0000:0000, ret: 184
[ 732.958474] OWL: read_data_c22 external: 0, addr: 1, rv: 002b:0808, ret: 312
[ 732.974896] OWL: read_data_c22 external: 0, addr: 2, rv: 002b:0808, ret: 808
[ 732.991207] OWL: read_data_c22 external: 0, addr: 3, rv: 002b:0808, ret: 88
[ 733.007197] OWL: read_data_c22 external: 0, addr: 4, rv: 002b:0808, ret: 8
[ 733.023527] OWL: read_data_c22 external: 0, addr: 5, rv: 002b:0808, ret: 160
[ 733.039442] OWL: read_data_c22 external: 0, addr: 6, rv: 002b:0808, ret: 192
[ 733.053446] OWL: read_data_c22 external: 0, addr: 7, rv: 002b:0808, ret: 368
[ 733.067198] OWL: read_data_c22 external: 1, addr: 0, rv: 004d:d101, ret: 512
[ 733.081220] OWL: read_data_c22 external: 1, addr: 1, rv: 8aa2:1ac8, ret: 920
[ 733.098331] OWL: read_data_c22 external: 1, addr: 2, rv: ffff:ffff, ret: 840
[ 733.114645] OWL: read_data_c22 external: 1, addr: 3, rv: ffff:ffff, ret: 912
[ 733.130959] OWL: read_data_c22 external: 1, addr: 4, rv: ffff:ffff, ret: 584
[ 733.147197] OWL: read_data_c22 external: 1, addr: 5, rv: ffff:ffff, ret: 232
[ 733.163502] OWL: read_data_c22 external: 1, addr: 6, rv: ffff:ffff, ret: 160
[ 733.177197] OWL: read_data_c22 external: 1, addr: 7, rv: ffff:ffff, ret: 104
Especially interesting are these answers with the armed external flag!
[ 733.067198] OWL: read_data_c22 external: 1, addr: 0, rv: 004d:d101, ret: 512
[ 733.081220] OWL: read_data_c22 external: 1, addr: 1, rv: 8aa2:1ac8, ret: 920
Yes, and the names of the functions c22 and c45 are also present in Mikrotik's phy_helper.ko !
1 Like
Well, with such a DTS config, it rises and works. The link goes out when the port is set to down!
And another question, does we need a specified PHY driver for QCA8081 or generic is enough?
[ 25.601779] mv88e6085 f212a200.mdio-mii:00 p1 (uninitialized): PHY [!cp0!config-space@f2000000!mdio@12a200!switch@0!mdio1:00] driver [Generic PHY] (irq=POLL)
[ 25.741386] mv88e6085 f212a200.mdio-mii:00 p1: configuring for inband/sgmii link mode
[ 29.010227] mv88e6085 f212a200.mdio-mii:00 p1: Link is Up - 1Gbps/Full - flow control rx/tx
[ 29.018645] IPv6: ADDRCONF(NETDEV_CHANGE): p1: link becomes ready
But I had to hack the switch driver. It looks like Mikrotik screwed up something with its EEPROM. I will investigate further!
&cp0_mdio {
...
switch@0 {
...
ports {
...
port@9 {
reg = <9>;
label = "p1";
phy-mode = "sgmii";
phy-handle = <&switch0phy9>;
managed = "in-band-status";
};
};
mdio {
...
};
mdio1 {
compatible = "marvell,mv88e6xxx-mdio-external";
#address-cells = <1>;
#size-cells = <0>;
switch0phy9: switch0phy9@0 {
reg = <0>;
};
};
};
};
3 Likes
@adron That is awesome, I have suspected that they did this from the start but when manually reading registers 2 and 3 (This is where the PHY ID is) on all addresses from 0-31 are and found nothing.
So, I probably messed up the indirect bits in Global2.
I will try backporting the QCA8081 as they have fixups there.
What did you have to change in the DSA driver?
Just trying to figure out why it doesn't work without this dirty hack!
Otherwise, it fails with -EBUSY error. As if this function should reconfigure the gpio to work as SMI(MDIO). But in fact, on the contrary, it breaks its work! In my datasheet for 88e6096 there is no description of working with scratch registers. Maybe you, with having access to the right datasheet, can clarify the situation.
Ok, I have glimpsed at that one before, it's just setting the pinctrl for SMI.
The scratch registers are described in the datasheet and so far the code looks correct.
Let me give it a go and will see whats wrong.
Yes, but it is reads something from config_data2 and this something(p0_mode) is equal to 0x1 and this code doesn't like 0x1. So it returns the -EBUSY error.
So the question is, why 0x1(p0_mode) is written in config_data2 ? Is this some kind of eeprom?
I think we have a bit of different naming, is config_data2 at MDIO addr 0x1c?
No, the switch doesn't have any kind of EEPROM, it just uses various MDIO addresses for different register sets.
So you have 0x0-0xa are per port registers, then at 0x1b you have the Global1 registers and at 0x1c Global2.
P0_MODE are configurations pins that are set by pulling up/down.
And on P0_MODE it depends which pins do you have available as GPIO-s and many other things.
Oh, then I realized what it was! So Mikrotik screwed up with switch pull resistors and we still have to hack the driver!
That would explain why it doesn't work without a fixup.
Now, we kind of need to somehow see what mode does RouterBoot set.
That should be easy, I will just dump it from bootloader run from flash by RouterBoot