So, I couldn't help myself and had Gemini CLI do some more work. The idea it came up with is to mark the PHY->PSE dependency optional so we can get to the point where modules are loaded and then it all works out fine.
I haven't traced out the reset line but I suspect the watchdog is implemented in the other, 8-pin STC8 next to the weird crypto chip, and not the PoE STC8. They all sit on the same I2C bus though.
I think this is the place where I find PoE experts
I have a series of devices from Zyxel where one variant is PoE capable. Of course I do not really have an idea what's going on there PoE-wise. So far, I opened the device and saw some RTL8239 ICs connected to a GigaDevice MCU. I assume work has to concentrate on finding out how the communcation with the MCU is happening to be able to use PoE.
Any suggestions on how to get started with this? Or should I just throw the vendor binary at Claude to find the PoE stuff?
Love it! More progress on that side: Currently one blocker is this that we can't build pse drivers as module and attach them later to the phy. Hopefully we get here to agreements soon...
-> But this seems to be a bigger topic.
For this hs104 we need another patch, to get triggers working
...
I hope they approve it soon.... finishing line.
But I don't know how your devices works..
I would do the following:
take a LLM and reverse engineer your stock driver - what you basically did... what is the communication interface...i2c? my learning is: ghidra in combination with a agent works best.
the pse backports on 6.12 are working proper and 6.18 should have it anyway.
let us know how it goes
When @bevanweiss and my project here is finally done, I want to create a driver for the realtek stuff, that was built by Sven back then.
It does look like Sven has done some work around the RTL8239, unsure if that includes creation of a Linux PSE driver though.
Although perhaps he has a datasheet for the chip that would help greatly.
Is the RTL8239 definitely not accessible from the RTL SoC?
If it's like the Hasivo switches, they have an STC8 and the PoE chips on the same I2C bus.
Perhaps the Zyxel uses the GigaDevice MCU (which I believe are typically STM32 compatible) in place of the STC8, and the RTL8239 instead of the Hasivo HS104 chips..
In which case the GigaDevice would be responsible for things like case fan control, maybe some upstream power control for PoE, and potentially some PoE LEDs (if these aren't in the SoC itself).
Throwing the vendor binary to Claude may indeed help to work out how the communication flows go.
Don't know yet actually. At first I would need to find out to which I2C bus something might be attached here, either just the MCU or together with the RTL8239s. That the MCU does more might not be that far off, it's quite close to the fan plugs.
Probably not for any LED stuff, it seems all the PoE LEDs are in the same serial "line" as the normal PoE. (yay ...)
Do you need a driver for the GigaDevice MCU or the RTL8239? Regarding the later one I expect them to work similar to an RTL8238B (for which we have the programming guide).
Depends on how these are connected to each other, I still need to find that out. My guess was just that the GigaDevice MCU is responsible for controlling the RTL8239, and the SoC just talks to that MCU. Like e.g. seen on several GS19xx devices.
On one of the I2C hardware channels there as weird device at address 0x20. i2cdump reads all 0x00. Not sure if this might be the MCU. According to Claude's firmware binary analysis it fits. I would assume the RTL8239 are not available at the SoC then.
Interesting additional finding: If I toggle a specific GPIO pin, the device disappears from/reappears on the bus. If that is really the PoE MCU, this might be a global PoE enable/disable GPIO.
The MCU (GD32E230G8) which controls the RTL8239 POE++ PSE chips can sometimes hang. In this case, it is necessary to to reset the chip using the nRESET pin which is connected to the GPIO1 of the RTL8231 GPIO expander.
Yep ... saw that too some minutes ago. Looking briefly at the poemgr code even the I2C address is the same. I think I will just try the PSX28 profile and see, how it goes. Maybe I'm lucky and it's more or less the same.
