@bevanweiss Would you mind sharing what state you have achieved with POE ?
cheers:)
Love that applied intelligence.
First time I've seen the I in AI 
I am now one step further 
10mbit, 1G and 2.5G are working on openwrt.
The interesting part is that the findings from the bruteforce attempt were misleading, after I removed step by step the different register changes, I figured out that 1G worked still also without applying the registers from the original firmware. The reason why 1G worked was the early return, so the rest of "rtl822x_set_serdes_option_mode" was never executed. I added step by step more lines and pin pointed the problem to:
SERDES Control 6 Register (MMD 30. 0x7587)
-> Restore analog SERDES register default value after reset...
ret = phy_write_mmd(phydev, MDIO_MMD_VEND1, 0x7587, 0x3);
After removing this step, I can transfer data with all speeds.
Any idea, if this causes other issues later?
I made a branch with the changes:
Some problems I still encounter:
- The LED colors for speed identification are still wrong (For example orange is for 2.5G on the stock firmware)
- One LED (Green left) stays active, if I disconnect 1G ... On 2.5G it works correctly and if I connect 1G first, 2.5G after the LEDs are reset.
Happy to get your feedback.
best,
This makes only partially sense. Register 0x7587 has only one known field. Bit 2 aka SERDES Reg Setting Lock
- 1: Restore analog SERDES register default value when doing a SERDES reset
- 0: Keep SERDES register value even after SERDES reset
So currently I assume that the write clears that bit. Can you check
- the default of that register
- the value of the register after the write
- check what bits of this register are really changeable.
Thanks.
P.S. that write comes from 720-02-net-phy-realtek-disable-SGMII-in-band-AN-for-2-5G-PHYs.patch in generic patches.
P.P.S. Looking at the code this gets strange. It looks like someone tried to program some kind of reset there.
ret = phy_write_mmd(phydev, MDIO_MMD_VEND1, 0x7587, 0x3);
if (ret < 0)
return ret;
ret = phy_read_mmd_poll_timeout(phydev, MDIO_MMD_VEND1, 0x7587,
val, !(val & BIT(0)), 500, 100000, false);
Here you go:
val = phy_read_mmd(phydev, MDIO_MMD_VEND1, 0x7587);
if (val < 0)
return val;
pr_info("before write 0x7587 : 0x%04x\n", val);
/* Fixes no data transfer on 1gbps speed */
// if (!of_machine_is_compatible("hasivo,s1100wp-8gt-se")) {
ret = phy_write_mmd(phydev, MDIO_MMD_VEND1, 0x7587, 0x3);
if (ret < 0)
return ret;
// }
val = phy_read_mmd(phydev, MDIO_MMD_VEND1, 0x7587);
if (val < 0)
return val;
pr_info("after write 0x7587 : 0x%04x\n", val);
ret = phy_read_mmd_poll_timeout(phydev, MDIO_MMD_VEND1, 0x7587,
val, !(val & BIT(0)), 500, 100000, false);
if (ret < 0)
return ret;
val = phy_read_mmd(phydev, MDIO_MMD_VEND1, 0x7587);
if (val < 0)
return val;
pr_info("after poll read 0x7587 : 0x%04x\n", val);
output:
[ 4.398944] before write 0x7587 : 0x0002
[ 4.412106] after write 0x7587 : 0x0002
[ 4.425000] after poll read 0x7587 : 0x0002
edit: corrected!
That behaviour is somehow expected. if BIT(0) is some kind of "reset" you set it to 1and wait for the hardware to pull it down to 0 again. Most often this is faster as two subsequent pr_info commands.
Nevertheless the datasheet does not mention anything about those two bits.
P.S. You really wrote 0x3 to that register, didn't you?
@plappermaul my bet... NYE hangover 
I was writing bullshit. As early said, and as you see in the Commit - the line is removed for the working version...
So the !of_machine_is_compatible does not execute it. Damn;-) I do another run and edit the old post! ...
@plappermaul now the bit is written and the read result is still the same...
No problem. Now there are two options from here:
- assumption 1: this is some kind of reset and we lose other register setting elsewhere
- assumption 2: This is some kind of bug introduced during its initial PR with https://github.com/openwrt/openwrt/pull/12317
As I have no other information about that register so I advise to create an github issue for that and ping dangowrt over there.
Warning AI fuzz ahead.
After tons of misleading answers I got the attached info. Maybe you can write 0xffff to that register and verify if it makes somehow sense.
In the RTL8221B-VB specific register map, MMD 30.0x7587 is the SDS_CFG_UPD (SerDes Configuration Update) register. As you've noted, it isn't a simple mode-selection or FIFO-status register—it is a functional trigger used to apply changes to the SerDes hardware.
Here are the specific bit-field definitions for this register as found in the VB-revision technical guides:
MMD 30.0x7587: SDS_CFG_UPD (SerDes Configuration Update)
| Bit(s) | Field Name | R/W | Functional Description |
|---|---|---|---|
| 15:9 | Reserved | R | Reserved. |
| 8 | SDS_CFG_EN | R/W | SerDes Configuration Enable: 1: Enable the writing/updating of SerDes digital and analog parameters. 0: Ignore updates (Lock). |
| 7:3 | Reserved | R | Reserved. |
| 2 | SDS_RST_MODE | R/W | Reset Mode Selection: 1: Hard Reset (PLL re-locks, full analog calibration). 0: Warm Reset (Digital PCS reset only). |
| 1 | SDS_UPD_TRIG | R/W | Update Trigger: Setting this to 1 triggers the internal logic to read the "shadow" configuration registers and apply them to the active SerDes circuits. |
| 0 | SDS_RST_TRIG | R/W | Reset Trigger (Self-Clearing): Setting this to 1 initiates the reset sequence. The hardware will clear this bit to 0 when the reset/re-calibration is complete. |
But don't invest too much here. This can be totally wrong.
root@OpenWrt:~# mdio 1b000000.switchcore:mdio-controller-mii mmd 02:30 raw 0x7587
0x0002
root@OpenWrt:~# mdio 1b000000.switchcore:mdio-controller-mii mmd 02:30 raw 0x7587 0xffff
root@OpenWrt:~# mdio 1b000000.switchcore:mdio-controller-mii mmd 02:30 raw 0x7587
0x0006
same in the function:
[ 3.898402] before write 0x7587 : 0x0002
[ 3.913008] after write 0x7587 : 0x0006
[ 3.925850] after poll read 0x7587 : 0x0006
btw now other logs are generated. Network is not working on 1G. AI is taking over tonight;-)
The Hasivo switches we have don’t talk directly to the HS104 chips. So the driver itself isn’t much use to us currently.
There’s an 8bit 8051-clone chip that appears to do the ‘control’ of the PSE system, including PoE LED indications. On other switches (with fans) it is also responsible for aspects of the fan control.
I think even the s1100wp-8gt-se has the footprints for this… I think QT1 beside the CPU is for something like a DS18B20 (one wire temperature sensor). With Q2 being for an N-FET, which might be used for PWM of the fan (or just on/off hysteresis control).
So ultimately, I haven’t made much progress. I did try to work out the protocol between the RTL host and the 8051 chip… but it didn’t seem to be anything standard. There’s a few posts in this thread (from me) with some oscilliscope plots / logic analyzer plots for it..
The LEDs are likely my doing. The original DTS values came from the Realtek SDK 8x8226 logic. But I think at some stage I changed it around because having orange for 2.5gbps felt ‘wrong’.. 1gbps and 2.5gbps should be ‘good’, with 10/100mbps ‘less good’ (i.e. orange)…
They should be pretty straight forward to ‘fix-up’ in the DTS though…
The LED sticking is probably not worth looking into too much right now, since I think it relates to issues that still exist with the serdes / link setting around the PHY (and how this is communicated back to the MAC, where the LEDs are hardware controlled).
I think I have found an issue in one of the pending patches from upstream.
This ALDPS changing, I think should be pointing towards MMD 31.0xA430 (i.e. MDIO_MMD_VEND2), instead it’s pointing to 30.0xA430 (i.e. MDIO_MMD_VEND1).
@daniel Am I reading this wrong?
From 9155098547fb1172d4fa536f3f6bc9d42f59d08c Mon Sep 17 00:00:00 2001
From: Daniel Golle <daniel@makrotopia.org>
Date: Sat, 22 Apr 2023 03:26:01 +0100
Subject: [PATCH] net: phy: realtek: setup ALDPS on RTL822x
Setup Link Down Power Saving Mode according the DTS property
just like for RTL821x 1GE PHYs.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
---
...
+ if (of_property_read_bool(phydev->mdio.dev.of_node, "realtek,aldps-enable"))
+ ret = phy_set_bits_mmd(phydev, MDIO_MMD_VEND1, RTL8221B_PHYCR1,
+ RTL8221B_PHYCR1_ALDPS_EN | RTL8221B_PHYCR1_ALDPS_XTAL_OFF_EN);
+ else
+ ret = phy_clear_bits_mmd(phydev, MDIO_MMD_VEND1, RTL8221B_PHYCR1,
+ RTL8221B_PHYCR1_ALDPS_EN | RTL8221B_PHYCR1_ALDPS_XTAL_OFF_EN);
+ if (ret < 0)
+ return ret;
(2) -> you find here https://github.com/openwrt/openwrt/issues/21359 ...
I created a summary and moved the topic to another thread...
@bevanweiss, as promised here the scripts and some basic tutorial for patching the firmware.
It includes patches for more logging, i2c stuff for the poe and for the hal,sds,serdes,phy pieces...
Maybe it helps some other folks for other hasivo switches...
I added now the logs for the serdes, sds stuff as well.
I haven't analysed yet what they mean, but maybe some others are faster.
Tomorrow back to i2c and poe
cheers.
@hazza64 Do you have any more details for your S600WP-5GT-2S_SE switch that could allow it to be added to OpenWRT? We just got the S1100WP-8GT-SE added (without PoE support right now.. but it's coming 'soon'..). If your board just had less ports, it should be easy to adapt the S1100WP-8GT-SE device tree etc to match.
@blunden @YumingChang02 I'd expect similar should be true for the F1100WP-4XS-4XGT, I suspect it would be very similar to the S1100W-8XGT-SE that @andrewjlamarche has already added support for. Just with the 8XGT split into 4 SFP+ ports, and 4 10GbE ports.
@TKtheDEV and likewise the S1300WP-8XGT-4S+ is likely almost identical to the S1100W-8XGT-SE but with an additional 4 SFP+ ports.
It would be great to get these switches running OpenWRT.
I own a S600WP-5GT-2S+_SE (also known as S600WP-5GT-2X-SE on the box label) as well as a F1100WP-4XS-4XGT. 
S600WP-5GT-2S+_SE:
This switch is based on the RTL9301. I've previously posted the output of the support command that people usually use as a basis to create a device tree on here somewhere, I believe. PCB pictures are also available. Other than using a slightly cut down SoC in the same generation, it's probably fairly similar.
Unfortunately, the L2 managed version (i.e. the _SE model) doesn't have the console port populated (but it's apparently functional if you solder a port to it). That's only populated on the L3 managed version, which is otherwise identical in terms of hardware as far as I know.
F1100WP-4XS-4XGT:
This switch is based on the RTL9303, just like the model discussed here recently. Unfortunately, the L3 firmware my unit is running doesn't have the support command in question. It does have the console RJ45 port populated though.
What particular information are you looking for?
Are you able to get to a uboot menu on either of them (or have another way to flash test images)?
Without a physical device in my hands, I'm not able to test anything specific to the device (including how to get images loaded onto it).
With the info you've provided, it should be possible to get an initial attempt at the S600WP-5GT-2X-SE. I'll look into it tonight if I get some time.
Do you have an OpenWRT build environment, and can you build test images yourself?
If you can get the OEM boot logs for the F1100WP-4XS-4XGT that might reveal something also.
And if you have vendor firmware images for these, that would be useful as long as we can match your particular board to the various board models supported by that firmware.