@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 
1 Like
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?
1 Like
@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.
1 Like
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..
1 Like
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 ...
1 Like
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.
1 Like