Support POE on hasivo devices (s1100wp-8gt_se)

Hardware Questions and Recommendations
1

I've researched what I found in the different topics and thought it makes sense to open another topic, as the others are cluttered and covering other things as well.

Main source is: kernel-6.15-poe-se & hasivo-switches

thx to @bevanweiss @andrewjlamarche @Valdem @Luca91 for the ground work!

Wiring:

SOC <-[gpio, custom I2C]-> STC8 <-[I2C]-> HS104 POE
			                            > FAN

Stock firmware does the following :

  1. checks if POE board is available in board_config.ko:
    1.1 reads env variables from u-boot with:
    rt_util_flashEnv_get
    1.2 reads a gpio pin to check if the poe hardware is available:
    drv_generalCtrlGPIO_dataBit_get
  1. Communication with STC8 e.g. HS104 via I2C in ski.ko. While checking the assembly, it looks pretty simple what I2C data is transferred.

My educated guess:

  1. The soc communicates via custom I2C (using 2 gpios) with the STC8
  2. The i2c logic (what is sent to STC8) - so what I see from looking into the stock firmware - is rather simple
  3. Thinking much about the HS104 is not the solution as the stock firmware has not much logic included for that when I compare to the datasheet hasivo_8port_pse_application_description-re.docx ...
  4. I would start patching the stock firmware to get more logs...

My questions before I go deeper:

  1. Am I on the right path here? Anything misunderstood or overseen?
  2. When you talk about "8bit 8051-clone chip", you mean the STC8 @bevanweiss ?
  3. Did anyone figure out, how the Soc (which ports, details for I2C) communicates with the STC8 ...
  • When I scan all i2c_mst1 and i2c_mst2 addresses (configured in dts), I only detect some SFP related stuff via the switch. So I assume this is not the right I2C port. Did anyone figure out which how to communicate with the chip? @bevanweiss @andrewjlamarche
  • I read that @Valdem captured via Logic analyzer the communication? Did you upload it somewhere?
3 Likes
Hasivo switches
OpenWrt support for Cudy C200P (MT7621AT + IP804AR)
Hasivo switches
2
  1. Yes, that STC8 is an 8051 clone https://www.stcmicro.com/stc/stc8g1k08.html
  2. I’m not so convinced it’s I2C. It looked more like UART. Hasivo switches - #67 by bevanweiss
    Although that comment in the boot logs init the pse led controlled iic interface does indeed suggest I2C…

A few links back to the other thread for information that might be relevant…

  1. Photo of the PoE daughter board
    New Linux Kernel 6.15 PoE (PSE) features - #15 by bevanweiss
  2. Logic analyzer traces of both RxD P3.0 / TxD P3.1 pins of the STC8
    Hasivo switches - #103 by bevanweiss
1 Like
3
  1. I mean all the methods in the stock firmware are something with I2C read & write.... So if this is a false friend I would be pretty confused. Still who knows.
    Do you know anything about the SOC ports that go to the STC8 (TX,RX)?
4

Tiniest bit extra…

image
image619×557 29.7 KB

The PoE Watchdog does ‘something’ based on either GPIO7 (RTL930X) or GPIO30 (RTL931X). It mostly looks like this is to just write an error if that pin stops toggling, Case1:no linkup reset. port %d\r\n or Case2:no flow reset. port %d\r\ndepending on the state of the port link / in octet counter.

And the decompiled code definitely has a lot of i2c reads and writes in it around the PoE.

What is a bit confusing is that there’s a combination of raw i2c_byte_get and i2c_byte_set calls, as well as some to helper functions board_poe_msg_get and board_poe_msg_set. I would have expected it to entirely use the board_poe_msg… variants, but I guess this might be some compiler optimisations occuring in certain situations of the board_poe_msg_… methods.

5

I will soon try to test the gpio pins. Regarding your second point. It looks to me that the msg_set and msg_get functions are only calling the i2c_byte_... ones. So basically there are used as a wrapper from my understanding or?

6

some updates :slight_smile:

Patching:
I could patch the methods i2c_byte_get and i2c_byte_set in the stock firmware and log what is read and written. It's not that easy, because you need injection some trampoline function in a correct way. Funny side not: First I did rather manuell and it took ages. The second one was speed up with LLMs heavily and the result looks better...

  1. i2c_byte_get
    Screenshot from 2026-01-04 20-17-10
    Screenshot from 2026-01-04 20-17-10624×439 20.5 KB

and the injected one:

Screenshot from 2026-01-04 20-17-31
Screenshot from 2026-01-04 20-17-31624×439 8.75 KB

  1. i2c_byte_set
    Screenshot from 2026-01-04 20-18-29
    Screenshot from 2026-01-04 20-18-29624×439 19.4 KB

and the injected one:

image
image714×194 9.93 KB

The de-compilation screenshots can be a little wrong but they give a indication how it looks. As you can see the second one was LLM based and exceeded my manuell skills - a better string was found :wink:

Will upload the patches later, so everyone can use it.

Logging
As you can see my patch was not generating the nicest logs.

I tried to structure a little and decode the dec to hex:

I know that are still some mistakes in my regexp, so take it with grain of salt. But it gives some first ideas.

Some findings from the logs

  1. The initialization process looks super simple:
I2C_Read: 0x0.0x6.0xc.0xe
I2C_Read: 0x32.0x6.0x1.0x40
I2C_Read: 0x0.0x8.0x1.0x40

I2C_Write: 0x0 0x8 0x1 0x40
I2C_Read: 0x0.0x6.0xc.0xe
I2C_Read: 0x32.0x6.0x1.0x40
I2C_Read: 0x0.0x8.0x1.0x40

I2C_Write: 0x0 0x8 0x1 0x40
I2C_Read: 0x0.0x6.0xc.0xe
I2C_Read: 0x32.0x6.0x1.0x40
I2C_Read: 0x0.0x8.0x1.0x40

I2C_Write: 0x0 0x8 0x1 0x40
I2C_Read: 0x0.0x6.0xc.0xe
I2C_Read: 0x32.0x6.0x1.0x40
I2C_Read: 0x0.0x8.0x1.0x40

I2C_Write: 0x0 0x8 0x1 0x40
I2C_Read: 0x0.0x7.0xc.0xe
I2C_Read: 0x32.0x7.0x1.0x40
I2C_Read: 0x0.0x8.0x2.0x48

I2C_Write: 0x0 0x8 0x2 0x40
I2C_Read: 0x0.0x7.0xc.0xe
I2C_Read: 0x32.0x7.0x1.0x40
I2C_Read: 0x0.0x8.0x2.0x40

I2C_Write: 0x0 0x8 0x2 0x40
Init Board Vendor Module....OK
  1. If you plugin a POE device, not much happens. So everything is handled by STC8 that speaks to the HS104... Just some random stuff every second, but nothing special when you plugin a POE cable.
I2C_Write: 0x0 0x8 0x1 0x40
I2C_Read: 0x0.0x6.0xc.0xe
I2C_Read: 0x32.0x6.0x1.0x40
I2C_Read: 0x0.0x8.0x1.0x40

I2C_Write: 0x0 0x8 0x1 0x40
I2C_Read: 0x0.0x7.0xc.0xe
I2C_Read: 0x32.0x7.0x1.0x40
I2C_Read: 0x0.0x8.0x2.0x40

I2C_Write: 0x0 0x8 0x2 0x40
I2C_Read: 0x0.0x7.0xc.0xe
I2C_Read: 0x32.0x7.0x1.0x40
I2C_Read: 0x0.0x8.0x2.0x40

I2C_Write: 0x0 0x8 0x2 0x40
I2C_Read: 0x0.0x7.0xc.0xe
I2C_Read: 0x32.0x7.0x1.0x40
I2C_Read: 0x0.0x8.0x2.0x40

I2C_Write: 0x0 0x8 0x2 0x40
I2C_Read: 0x0.0x7.0xc.0xe
I2C_Read: 0x32.0x7.0x1.0x40
I2C_Read: 0x0.0x8.0x2.0x40

I2C_Write: 0x0 0x8 0x2 0x40
I2C_Read: 0x0.0x6.0xc.0xe
I2C_Read: 0x32.0x6.0x1.0x40
I2C_Read: 0x0.0x8.0x1.0x40

I2C_Write: 0x0 0x8 0x1 0x40
I2C_Read: 0x0.0x6.0xc.0xe
I2C_Read: 0x32.0x6.0x1.0x40
I2C_Read: 0x0.0x8.0x1.0x40

I2C_Write: 0x0 0x8 0x1 0x40
I2C_Read: 0x0.0x6.0xc.0xe
I2C_Read: 0x32.0x6.0x1.0x40
I2C_Read: 0x0.0x8.0x1.0x40

I2C_Write: 0x0 0x8 0x1 0x40
I2C_Read: 0x0.0x6.0xc.0xe
I2C_Read: 0x32.0x6.0x1.0x40
I2C_Read: 0x0.0x8.0x1.0x40

I2C_Write: 0x0 0x8 0x1 0x40
I2C_Read: 0x0.0x7.0xc.0xe
I2C_Read: 0x32.0x7.0x1.0x40
I2C_Read: 0x0.0x8.0x2.0x40

I2C_Write: 0x0 0x8 0x2 0x40
I2C_Read: 0x0.0x7.0xc.0xe
I2C_Read: 0x32.0x7.0x1.0x40
I2C_Read: 0x0.0x8.0x2.0x40
  1. The pse LEDs are controlled somewhere else. This requires more investigation, as there are no logs generated by the patch. I guess they are controlled by the soc (gpio) in a different way? any Ideas?
Init Board Module-->POE....init the pse led controlled iic interface
init the pse led controlled iic interface
init the pse led controlled iic interface
init the pse led controlled iic interface
init the pse led controlled iic interface
init the pse led controlled iic interface
init the pse led controlled iic interface
init the pse led controlled iic interface
init the pse led controlled iic interface

  1. Poe survives reboot, so there is just once something happening and then not again. The port stays active (orange led) even if the port is unplugged and plugged in again (in u-boot after reboot) . After loading the stock firmware (re init of POE board) the ports reset.

  2. I was wondering, when the device pulls actual data from the POE board. And it it only happens when you request it. I was loading the web interface, and then it happens...

Screenshot from 2026-01-04 19-14-54
Screenshot from 2026-01-04 19-14-541060×555 50.4 KB

Which result in this:


I2C_Write: 0x0 0x8 0x1 0x40
I2C_Read: 0x0.0x6.0xc.0xe
I2C_Read: 0x32.0x6.0x1.0x40
I2C_Read: 0x0.0x8.0x1.0x40

I2C_Write: 0x0 0x8 0x1 0x40
I2C_Read: 0x0.0x7.0xc.0xe
I2C_Read: 0x32.0x7.0x1.0x44
I2C_Read: 0x0.0x8.0x2.0x44

I2C_Write: 0x0 0x8 0x2 0x44
I2C_Read: 0x0.0x7.0xc.0xe
I2C_Read: 0x32.0x7.0x1.0x44
I2C_Read: 0x0.0x8.0x2.0x44

I2C_Write: 0x0 0x8 0x2 0x44
I2C_Read: 0x0.0x7.0xc.0xe
I2C_Read: 0x32.0x7.0x1.0x44
I2C_Read: 0x0.0x8.0x2.0x44

I2C_Write: 0x0 0x8 0x2 0x44
I2C_Read: 0x0.0x7.0xc.0xe
I2C_Read: 0x32.0x7.0x1.0x44
I2C_Read: 0x0.0x8.0x2.0x44

I2C_Write: 0x0 0x8 0x2 0x44
I2C_Read: 0x0.0x6.0x1.0x40
I2C_Read: 0x0.0x6.0x2.0x14
I2C_Read: 0x0.0x6.0x3.0x45
I2C_Read: 0x0.0x6.0x4.0x0
.I2C_Read: 0x6.0x5.0x0.0x6
.I2C_Read: 0x21.0x0.0x6.0x22
.I2C_Read: 0x0.0x6.0xd.0x14
I2C_Read: 0x0.0x6.0x1.0x40
I2C_Read: 0x0.0x6.0x2.0x14
I2C_Read: 0x0.0x6.0x3.0x45
I2C_Read: 0x0.0x6.0x6.0x0
.I2C_Read: 0x6.0x7.0x0.0x6
.I2C_Read: 0x23.0x0.0x6.0x24
.I2C_Read: 0x0.0x6.0xe.0x14
I2C_Read: 0x0.0x6.0x1.0x40
I2C_Read: 0x0.0x6.0x2.0x14
I2C_Read: 0x0.0x6.0x3.0x47
I2C_Read: 0x0.0x6.0x8.0x0
.I2C_Read: 0x6.0x9.0x0.0x6
.I2C_Read: 0x25.0x0.0x6.0x26
.I2C_Read: 0x0.0x6.0xf.0x14
I2C_Read: 0x0.0x6.0x1.0x40
I2C_Read: 0x0.0x6.0x2.0x14
I2C_Read: 0x0.0x6.0x3.0x45
I2C_Read: 0x0.0x6.0xa.0x0
.I2C_Read: 0x6.0xb.0x0.0x6
.I2C_Read: 0x27.0x0.0x6.0x28
.I2C_Read: 0x0.0x6.0x10.0x14
I2C_Read: 0x0.0x7.0x1.0x44
I2C_Read: 0x0.0x7.0x2.0x14
I2C_Read: 0x0.0x7.0x3.0x21
I2C_Read: 0x0.0x7.0x4.0x0
.I2C_Read: 0x7.0x5.0x0.0x7
.I2C_Read: 0x21.0x0.0x7.0x22
.I2C_Read: 0x0.0x7.0xd.0x14
I2C_Read: 0x0.0x7.0x1.0x44
I2C_Read: 0x0.0x7.0x2.0x14
I2C_Read: 0x0.0x7.0x3.0x23
I2C_Read: 0x0.0x7.0x6.0x0
.I2C_Read: 0x7.0x7.0x46a.0x7
.I2C_Read: 0x23.0x14.0x7.0x24
.I2C_Read: 0x3f2.0x7.0xe.0x28
.I2C_Read: 0x7.0x1.0x2a8.0x7
.I2C_Read: 0x2.0xc8.0x7.0x3
.I2C_Read: 0x15e.0x7.0x8.0x0
.I2C_Read: 0x7.0x9.0x0.0x7
.I2C_Read: 0x25.0x0.0x7.0x26
.I2C_Read: 0x0.0x7.0xf.0x14
I2C_Read: 0x0.0x7.0x1.0x44
I2C_Read: 0x0.0x7.0x2.0x14
I2C_Read: 0x0.0x7.0x3.0x21
I2C_Read: 0x0.0x7.0xa.0x0
.I2C_Read: 0x7.0xb.0x0.0x7
.I2C_Read: 0x27.0x0.0x7.0x28
.I2C_Read: 0x0.0x7.0x10.0x14
I2C_Read: 0x0.0x6.0x1d.0x0
.I2C_Read: 0x6.0x1e.0x0.0x7
.I2C_Read: 0x1d.0x14.0x7.0x1e
.101
I2C_Read: 0x0.0x6.0xc.0xe
I2C_Read: 0x32.0x6.0x1.0x40
I2C_Read: 0x0.0x8.0x1.0x40

I2C_Write: 0x0 0x8 0x1 0x40
I2C_Read: 0x0.0x6.0xc.0xe
I2C_Read: 0x32.0x6.0x1.0x40
I2C_Read: 0x0.0x8.0x1.0x40

I2C_Write: 0x0 0x8 0x1 0x40
I2C_Read: 0x0.0x6.0xc.0xe
I2C_Read: 0x32.0x6.0x1.0x40
I2C_Read: 0x0.0x8.0x1.0x40
  1. Switching the max power output of the device to 1000 (web interface), was producing a write log as well, but I don't know exactly which line it was.

How to proceed

As this init is rather simple and the init survives boot, I tried to communicate with the board. But for now no success, maybe @bevanweiss or other have ideas how to setup the I2C? Best would be to know how to bruteforce the right GPIO port... but all tryouts were not successfully.

DTS config:

/ {
    i2c-gpio-custom {
        compatible = "i2c-gpio";
 /*       sda-gpios = <&gpio0 29 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>; */
   /*     scl-gpios = <&gpio0 7 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;*/

   		sda-gpios = <&gpio0 7 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
		scl-gpios = <&gpio0 30 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
        i2c-gpio,delay-us = <10>; /* ~100kHz */
        #address-cells = <1>;
        #size-cells = <0>;
        status = "okay";
    };
};

I tried different variations with (7,8); (8,7); (7,29);(29,7);(7,30);(30,7), but no real success. But my knowledge here is pretty limited.

I tried i2cdetect for all variations ...


root@OpenWrt:~# i2cdetect -l
i2c-0   i2c             i2c-gpio-custom                         I2C

root@OpenWrt:~# i2cdetect -y 0
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 

root@OpenWrt:~# gpioinfo 

gpiochip0 - 32 lines:
        line   0:       unnamed                 output consumer=green:system
        line   1:       unnamed                 input
        line   2:       unnamed                 input
        line   3:       unnamed                 input
        line   4:       unnamed                 input
        line   5:       unnamed                 input active-low consumer=reset
        line   6:       unnamed                 input
        line   7:       unnamed                 output drive=open-drain consumer=scl
        line   8:       unnamed                 input
        line   9:       unnamed                 input
        line  10:       unnamed                 input
        line  11:       unnamed                 input
        line  12:       unnamed                 input
        line  13:       unnamed                 input
        line  14:       unnamed                 input
        line  15:       unnamed                 input
        line  16:       unnamed                 input
        line  17:       unnamed                 input
        line  18:       unnamed                 input
        line  19:       unnamed                 input
        line  20:       unnamed                 input
        line  21:       unnamed                 input
        line  22:       unnamed                 input
        line  23:       unnamed                 input
        line  24:       unnamed                 input
        line  25:       unnamed                 input
        line  26:       unnamed                 input
        line  27:       unnamed                 input
        line  28:       unnamed                 input
        line  29:       unnamed                 output drive=open-drain consumer=sda
        line  30:       unnamed                 input
        line  31:       unnamed                 input

What is the best approach to figure out how to communicate with the I2C port?

I guess we are on the right path :slight_smile:

7

Ahh.. you missunderstood me on GPIO 7. It’s not I2C, it’s just GPIO. Like a watchdog or similar from the PoE chip.

The i2c setup comes from elsewhere.

The I2C init is from this, one of the i2c_dev_init calls, which are called 8 times (one for each port.. which I think is a bug.. since the argument to the i2c_dev_init is the same each time, and it should only be init’ed once).

image
image707×478 49.7 KB

If you could patch in a dump of each i2c_dev→scl_pin_id and i2c_dev→sda_pin_id for these calls it would point to which i2c pins are being used. not required. I mapped the data structure over in Ghidra, and it looked nice enough..

image
image1770×599 139 KB

I should have read the #defines for the I2C interface before marking up the image... interface 2 = Software... not Master 2... which makes more sense... software I2C, SDA=22, SCL=23...

image
image435×508 24.9 KB

image
image1461×311 49.3 KB

It’d be good if you could annotate the I2C transfers with what the switch state was (which ports were active, what power config each port had) for each set of data.

I think the I2C Reads with 0x32 aren’t related to us.. everything through i2c_byte_get starts with 0

image
image569×346 19.3 KB

i’ll look into it more tonight after work.

1 Like
Hasivo switches
8

You wouldn’t have a reference guide to ‘how to’ do the firmware patching would you?
I think there’s some similar info that is desirable around the RTL8221B PHY interaction (and the RTL93xx SDS stuff)…

I can get to the point where I’m navigating around Ghidra of the binwalk -e extracted image. But I’m unsure how to make the changes, and pack it all back together into a .bin to re-download (successfully).

What are the limitations with the patching? Does the whole size and checksum of the image need to stay identical?

9

Ok... I've got something...

	i2c_scl23_sda22 {
		compatible = "i2c-gpio";
		#address-cells = <1>;
		#size-cells = <0>;

		scl-gpios = <&gpio0 23 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
		sda-gpios = <&gpio0 22 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
		status = "okay";

		clock-frequency = <100000>;
	};

Which then gives this:

root@OpenWrt:~# i2cdetect -l
i2c-0   i2c             i2c_scl23_sda22                         I2C adapter
root@OpenWrt:~# i2cdetect -y 0
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- 0d -- --
10: -- -- -- -- -- 15 -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- 4d -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
root@OpenWrt:~#

None of which match the 0x1A..0x8A (increments of 0x10) that the HS104 chip datasheet mentions.
None of these (0x0d, 0x15, 0x4d) appear to match the addresses that are in your logging (0x06, 0x07, 0x08) either though.. but your logging does have reads and writes that align.. so i'm not sure about the discrepency.

Perhaps you can try with the DTS mod that I'm proposing, and see if you get the same exposed addresses from it...

A bit more digging..
I've then used this command line...

cat <<'EOF' >> i2c_dump_16x16.sh
#!/bin/sh

if [ $# -lt 1 ]; then
    echo "Usage: $0 <i2c-device-address> [bus]"
    echo "Example: $0 0x50 1"
    exit 1
fi

DEV="$1"
BUS="${2:-0}"

# Print column header
printf "     "
col=0
while [ $col -lt 16 ]; do
    printf " %02X" $col
    col=$((col + 1))
done
printf "\n"

row=0
while [ $row -lt 16 ]; do
    printf "%02X:  " $((row << 4))

    col=0
    while [ $col -lt 16 ]; do
        reg=$(( (row << 4) + col ))

        val=$(i2cget -y "$BUS" "$DEV" "$reg" b 2>/dev/null)

        if [ $? -ne 0 ]; then
            printf " --"
        else
            printf " %02X" $((val))
        fi

        col=$((col + 1))
    done

    printf "\n"
    row=$((row + 1))
done
EOF
chmod +x i2c_dump_16x16.sh

to create a script to look through all the naive data registers in the devices...

I got as below...

root@OpenWrt:~# sh ./i2c_dump_16x16.sh 0x0d
      00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00:   00 40 14 58 00 00 00 00 00 00 14 00 3C 40 4F 1E
10:   1E 1E 1E AA 4F 00 00 00 00 00 00 00 00 00 00 00
20:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60:   00 00 00 00 -- -- -- -- -- -- -- -- -- -- -- --
70:   -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
80:   -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
90:   -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
A0:   -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
B0:   -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
C0:   -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
D0:   -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
E0:   -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
F0:   -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

root@OpenWrt:~# sh ./i2c_dump_16x16.sh 0x15
      00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00:   00 40 14 27 00 00 00 00 00 00 14 00 3C 40 4F 1E
10:   1E 1E 1E AA 4F 00 00 00 00 00 00 00 00 00 00 00
20:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60:   00 00 00 00 -- -- -- -- -- -- -- -- -- -- -- --
70:   -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
80:   -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
90:   -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
A0:   -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
B0:   -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
C0:   -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
D0:   -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
E0:   -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
F0:   -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

root@OpenWrt:~# sh ./i2c_dump_16x16.sh 0x4d
      00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00:   00 00 00 01 00 00 00 40 40 91 00 00 00 00 00 00
10:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20:   E7 75 30 9F 44 1C FB 74 EF 71 AD B7 CC 3E 49 1D
30:   91 38 97 B4 69 7A 1B C5 9D 91 3E 34 0F 98 29 78
40:   E9 81 8F 97 C7 54 AF 34 22 2C 8D 49 67 F1 9D D5
50:   5C 93 2B 22 4F 84 6F AC EF F3 3B 9A 8F 4C EB D9
60:   F4 B0 07 84 -- -- -- -- -- -- -- -- -- -- -- --
70:   -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
80:   -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
90:   -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
A0:   -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
B0:   -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
C0:   -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
D0:   -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
E0:   -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
F0:   -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

What do those values mean... no idea. I can't recall what I left the PoE config set as when I last ran the stock firmware.
The first two look 'similar', so I'd like to think that they are possibly just some kind of I2C passthrough of the HS104 chips... I'll pull the board off and try again shortly (but that will be all my testing for tonight.. it's getting late).

I've removed the PoE module, and alas, no more I2C devices visible on the network

root@OpenWrt:~# i2cdetect -y 0
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

Tomorrow night I'll hopefully find some leaded resistors to put some pullups on the SDA/SCL pins at the PoE header.

1 Like
Hasivo RTL93XX switches with internal fans
10

amazing! good job @bevanweiss :slight_smile: The script also helps, nice!
I figured out what is wrong...

Removing GPIO_OPEN_DRAIN does the trick, because I assume this disables the internal pull ups...
The ms delay you can ignore... It was just for testing :slight_smile:

DTS


/ {
	i2c_scl23_sda22 {
			compatible = "i2c-gpio";
			#address-cells = <1>;
			#size-cells = <0>;

			scl-gpios = <&gpio0 23 GPIO_ACTIVE_HIGH>;
			sda-gpios = <&gpio0 22 GPIO_ACTIVE_HIGH>;
			status = "okay";

			clock-frequency = <100000>;
			i2c-gpio,delay-us = <50>; // 50us delay ~= 10kHz
	};
};

So we have:

root@OpenWrt:~# sh ./i2c_dump_16x16.sh 0x4d
      00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00:   00 00 00 01 00 00 00 40 40 91 00 00 00 00 00 00
10:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30:   00 00 07 7A 57 45 B0 FC AF 32 54 C9 DC A4 8F 90
40:   87 14 15 7A 46 81 BA DF B3 32 02 E1 02 2A 37 E8
50:   96 22 11 F5 94 11 AA 79 9F 7A E0 E9 A0 21 28 80
60:   19 FE BF E8 9D F2 AB A0 87 8D 12 54 04 B6 AB 90
70:   2E E3 DF E3 06 DC 73 8B C5 5A B9 5C 66 FD 87 75
80:   CB F2 5B E5 12 F8 35 AF 93 86 44 90 0F B0 5D 70
90:   8C A4 4E DC 97 B1 23 C9 BE FE 5F 1A AB 7A 8C D1
A0:   98 A7 45 FC 8C D3 5B D9 DD 47 22 3C 5D A1 5D C3
B0:   7E 10 16 95 0E DE 75 91 0E DE 48 C5 16 F1 5D EB
C0:   8F 7C 90 2A 84 26 A4 61 23 00 01 01 00 00 00 00
D0:   00 00 00 11 2A 00 00 00 00 00 00 00 00 00 00 FF
E0:   FF 00 00 00 00 00 04 00 00 32 00 00 ED 00 00 01
F0:   BF FF 0C 1B 00 00 0B 52 62 C0 5A BC 15 D4 A1 78

root@OpenWrt:~# sh ./i2c_dump_16x16.sh 0x15
      00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00:   00 40 14 30 00 00 00 00 00 00 00 00 91 14 14 14
10:   14 00 3C 40 4F 1E 1E 1E 1E AA 40 00 00 00 00 40
20:   4F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30:   00 00 00 00 00 00 00 00 00 00 40 00 00 00 00 00
40:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
A0:   00 00 00 00 00 00 00 00 40 13 05 08 13 24 2B 3C
B0:   53 6A 00 00 00 00 00 00 00 00 00 00 00 00 00 00
C0:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
D0:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
E0:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
F0:   00 00 00 00 00 00 00 00 05 78 4F 4F 4F 40 40 00

root@OpenWrt:~# sh ./i2c_dump_16x16.sh 0x0d
      00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00:   00 40 14 52 00 00 00 00 00 00 00 00 91 14 14 14
10:   14 00 3C 40 4F 1E 1E 1E 1E AA 40 00 00 00 00 40
20:   4F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30:   00 00 00 00 00 00 00 00 00 00 40 00 00 00 00 00
40:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
A0:   00 00 00 00 00 00 00 00 40 13 05 08 13 24 2B 3C
B0:   53 6A 00 00 00 00 00 00 00 00 00 00 00 00 00 00
C0:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
D0:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
E0:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
F0:   00 00 00 00 00 00 00 00 05 78 4F 4F 4F 40 40 00
root@OpenWrt:~#

POE
I got also poe online on openwrt, but it was random try outs and I don't know which one it was:D

I got different values : 0x05 for Lan1 if I connect a POE client:

root@OpenWrt:~# i2cget   -y 0 0x0d 0x05
0x59
root@OpenWrt:~# i2cget   -y 0 0x0d 0x05
0x5b
root@OpenWrt:~# i2cget   -y 0 0x0d 0x05
0x5e
root@OpenWrt:~# i2cget   -y 0 0x0d 0x05
0x5b
root@OpenWrt:~# i2cget   -y 0 0x0d 0x05
0x6c
root@OpenWrt:~# i2cget   -y 0 0x0d 0x05
0x6f
root@OpenWrt:~# i2cget   -y 0 0x0d 0x05
0x6f
root@OpenWrt:~# i2cget   -y 0 0x0d 0x05
0x71
root@OpenWrt:~# i2cget   -y 0 0x0d 0x05
0x6f
root@OpenWrt:~# i2cget   -y 0 0x0d 0x05
0xad
root@OpenWrt:~# i2cget   -y 0 0x0d 0x05
0xa3
root@OpenWrt:~# i2cget   -y 0 0x0d 0x05
0xa3
root@OpenWrt:~# i2cget   -y 0 0x0d 0x05
0xa3
root@OpenWrt:~# i2cget   -y 0 0x0d 0x05
0xa3
root@OpenWrt:~# i2cget   -y 0 0x0d 0x05
0xa3
root@OpenWrt:~# i2cget   -y 0 0x0d 0x05
0xa3

#disconnect
root@OpenWrt:~# i2cget   -y 0 0x0d 0x05
0x0

EDIT: You find later in this post the solution that is provided from the docs.

Some light;-)

2.1 Left 4 Leds (simple registers)

# all 4 on
i2cset  -y 0 0x4d 0x01 0x4F
# all 4 off
i2cset  -y 0 0x4d 0x01 0x40
# first one
i2cset  -y 0 0x4d 0x01 0x48
# 0100[1]000
# first off
i2cset  -y 0 0x4d 0x01 0x40
# 0100[1]000

# second on
i2cset  -y 0 0x4d 0x01 0x44
# 01000[1]00

# second+third on
i2cset  -y 0 0x4d 0x01 0x46
# 01000[1][1]0

2.1 Right 4 Leds (simple registers, same idea)

# all 4 on
i2cset  -y 0 0x4d 0x02 0x4F
# all 4 off
i2cset  -y 0 0x4d 0x02 0x40

# ......

Reading the docs, I remembered we got some from hasivo :wink:
hasivo_8port_pse_application_description

Judge whether the PSE chip is online，
Address：0X0C
If the readout result = 0x91, it indicates that the chip is online, otherwise it is offline

root@OpenWrt:~# i2cget   -y 0 0x0d 0x0C
0x91

Port status
Address：0X01
0X01=4F=0100 1111
The last 4 bits of the fixed value of the first 0100 correspond to
1-4 ports, 1 = on, 0 = off
4F= 4 ports all on

# all offline
root@OpenWrt:~# i2cget   -y 0 0x0d 0x01
0x40

# 1 connected
root@OpenWrt:~# i2cget   -y 0 0x0d 0x01
0x48
# 0100 [1]000

# 4 connected
root@OpenWrt:~# i2cget   -y 0 0x0d 0x01
0x41
# 0100 000[1]

Port Switch
Write address: 0X14 , Control port on or off
0X0F=48=0100 1000
The last 4 bits of the front 0100 fixed value correspond to 1-4 ports
1=on， 0=off
48= 1 Port 1 is allowed to open and other ports are closed，

# port 1 on
root@OpenWrt:~# i2cset  -y 0 0x0d 0x14 0x48
# off
root@OpenWrt:~# i2cset  -y 0 0x0d 0x14 0x40

So we have a working poe device :slight_smile: Nice

@bevanweiss as I have not done that before: How would you approach the next steps? I am exciting to work on it next weekend.

Writing a kernel module? Doing it with simple bash script? How does the communication with openwrt works then in a best way? Control via config file, some user space application? Also we need to figure out how to listen on the "link is up notification".

Thx for the collaboration, that was fun!

2 Likes
11

I think we have basically everything for logging the SDS stuff as well... So I think you can use that stuff.
I will push my scripts and repo next weekend + write a simple tutorial. This does the packing and repacking...
I am back from vacation and have very little time this week. Sorry...

The limitations are only that you can't change the size of functions of the binaries, not easy to introduce new variables (just using existing ones or changing them) - also its important not to mess up any other instructions. The hasivo linux does not have any signature checks, so basically no prevention against patching the assembler instructions.

12

I’ll need to check mine again tonight, I didn’t get 0x91 for 0x0C register reads.. but it should be possible to enable the pull ups on those pins also.
I think if you use the software I2C and don’t have GPIO_OPEN_DRAIN you end up with a warning in the boot logs. So it’d be nicest if we could have these.
It should be possible to use the pin-mux to enable the pull up resistors on the chip (again I’ll look tonight).

I’ve got something of a test driver for the Hasivo chips (bevanweiss/openwrt at hasivo-pse-hs104), but it hasn’t been checked against any hardware yet. I thought I’d compiled it, but looking at it there’s declared variables that are unused, which I think would throw a compile error.
It possibly needs some additional ‘connectivity’ stuff added to, to allow the four channels (per PSE device) to be associated with an RJ45 port (lan1..8 for our example)

As for the STC8… I’m not sure that it’s going to be a stable enough ‘API’ to warrant a proper linux driver just for that.. so that is probably best done as just some scripting… although I guess it could possibly just be an I2C gpio LED controller for those bits… and if we can work out how the fan control works, that could just be an I2C pwm controller (if it is indeed PWM that it does and not just straight gpio. Unsure if it’s possible to have multiple drivers accessing the same i2c device… it’s obviously possible with i2c muxes (where there could be two 0xNN devices on the one master I2C), but if the mux isnothing (i.e. no control switch, no I2C addressing change… just time multiplexing) I’m not sure…

In regards how do we bring PoE support into OpenWRT. I think a combination of the linux PSE driver framework, and finding a way to support interaction with the user-space side of this from luci.
I’m unsure if the existing Realtek PoE stuff in OpenWRT has any luci support, but it’d be nice to align things.

1 Like
13

It’d be great if you could put up some of your new learnings about the STC8 I2C LED bits here: s1100wp-8gt_se [Switches]

Just be careful using terms like ‘left’/’right’ unqualified… since they are easily confused.
Reference against the port # on the case where possible (which hopefully aligns with the lan# designation in our configs… looking into the ports port # is on the left).

I think the PoE light shouldn’t care about link is up. It should really only be about whether there is power being delivered.. So the PSE interface probably needs to register some kernel events in some fashion, that the LED driver for the STC8 could use as triggers (so when power is delivered then the PoE light is on..).

1 Like
14

With the LEDs on the STC8, does it need the 0x40 part?
i.e. to set an LED, could it just be a write of 0x02 to register 0x01 (or 0x02)?

Requiring that 0x40 'execute' type of bit is trickier with the gpio led driver..

ChatGPT says the below might work... it's something of a starting point anyway..

i2c0: i2c@... {

  hse104_0@0d {
    compatible = "hasivo,hs104";
    reg = <0x0d>;
  }

  hse104_1@15 {
    compatible = "hasivo,hs104";
    reg = <0x15>;
  }

  stc8@4d {
    compatible = "hasivo,stc8";
    reg = <0x4d>;
    reg-names = "stc8-regs";
    hasivo,execute-bit-regs = <0x01 0x02>;

    port1_poe {
            compatible = "register-bit-led";
            reg = <0x01>;
            mask = <0x08>;
            linux,default-trigger = "hse104_0:port0_enabled";
        };
    port2_poe {
            compatible = "register-bit-led";
            reg = <0x01>;
            mask = <0x04>;
            linux,default-trigger = "hse104_0:port1_delivering";
        };
    port3_poe {
            compatible = "register-bit-led";
            reg = <0x01>;
            mask = <0x02>;
        };
    port4_poe {
            compatible = "register-bit-led";
            reg = <0x01>;
            mask = <0x01>;
        };
    port5_poe {
            compatible = "register-bit-led";
            reg = <0x02>;
            mask = <0x08>;
        };
    port6_poe {
            compatible = "register-bit-led";
            reg = <0x02>;
            mask = <0x04>;
        };
    port7_poe {
            compatible = "register-bit-led";
            reg = <0x02>;
            mask = <0x02>;
        };
    port8_poe {
            compatible = "register-bit-led";
            reg = <0x02>;
            mask = <0x01>;
        };

    fan: pwm-fan {
            compatible = "pwm-gen";
            regmap = <&stc8-regs>;
            #pwm-cells = <3>;
            pwm-enable-reg = <??>;
            pwm-duty-reg = <??>;
            pwm-period-reg = <??>;
        };
    };
};
15

Nice work here! Well done all involved. Seconding my favor of using the PSE framework.

1 Like
16

That DTS excerpt is the current goal, not real world just yet. But there's no show stopper that I've seen yet, I just need to wrangle the build environment a bit better to shorten my code change->compile issue->test->code change cycle.

Any pointers towards Luci development 'how-to's would be much appreciated :slight_smile:

17

S1100WP-8XGT-SE:

root@OpenWrt:~# sh ./i2c_dump_16x16.sh 0x4d                                     
      00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F                           
00:   00 00 00 00 2A 00 00 40 40 91 00 00 00 00 00 00                           
10:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00                           
20:   7E 91 ED 15 06 60 E9 96 12 AA 70 C5 1F B6 3E 02                           
30:   0D 73 FD 43 07 43 8B F9 5E AE 6F 09 FB B3 3D FA                           
40:   E3 4B 23 4D 71 08 5B 63 2C 77 AE 75 7B 50 E0 C8                           
50:   AF 5B FE 72 14 A1 80 94 E0 9C 13 95 7E 39 D3 0B                           
60:   A2 46 F7 FC -- -- -- -- -- -- -- -- -- -- -- --                           
70:   -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --                           
80:   -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --                           
90:   -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --                           
A0:   -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --                           
B0:   -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --                           
C0:   -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --                           
D0:   -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --                           
E0:   -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --                           
F0:   -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --                           
root@OpenWrt:~# sh ./i2c_dump_16x16.sh 0x15                                     
      00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F                           
00:   00 48 14 83 00 6C 00 00 00 00 14 00 3C 40 4F 1E                           
10:   1E 1E 1E AA 4F 02 56 00 00 00 00 00 00 00 00 00                           
20:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00                           
30:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00                           
40:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00                           
50:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00                           
60:   00 00 00 00 -- -- -- -- -- -- -- -- -- -- -- --                           
70:   -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --                           
80:   -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --                           
90:   -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --                           
A0:   -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --                           
B0:   -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --                           
C0:   -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --                           
D0:   -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --                           
E0:   -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --                           
F0:   -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --                           
root@OpenWrt:~# sh ./i2c_dump_16x16.sh 0x0d                                     
      00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F                           
00:   00 45 14 61 00 00 00 63 00 00 04 00 3C 40 4F 1E                           
10:   1E 1E 1E AA 4F 00 00 02 44 00 00 01 5E 00 00 00                           
20:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00                           
30:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00                           
40:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00                           
50:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00                           
60:   00 00 00 00 -- -- -- -- -- -- -- -- -- -- -- --                           
70:   -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --                           
80:   -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --                           
90:   -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --                           
A0:   -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --                           
B0:   -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --                           
C0:   -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --                           
D0:   -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --                           
E0:   -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --                           
F0:   -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
18

Awesome, so the 0x1d and 0x15 are the Hasivo HS104 chips.
The 0x4d is the STC8. And it looks like you've got some different value in register 0x03 and 0x04 than us.

Register Non Fan Model Fan Model Meaning
0x01 .. .. Port 1-4 PoE LEDs (0x08=Port1, 0x01=Port4)
0x02 .. .. Port 5-8 PoE LEDs (0x08=Port5, 0x01=Port8)
0x03 0x01 0x00 Possibly fan speed? or temperature fault
0x04 0x00 0x2A Possibly temperature?
0x05 0x00 0x00 Possibly fan speed?
0x06 0x00 0x00 ?
0x07 0x40 0x40 ? Probably not interesting
0x08 0x40 0x40 ? Probably not interesting
0x09 0x91 0x91 ? Probably not interesting
0x20+ ? ? No correlation, maybe just random RAM values / uninit flash

So what would be useful is to check these registers at different ambient temperatures. Even perhaps blowing a hairdryer / hot air gun (staying below 70degC though) and seeing if the values change in a deterministic way.

So maybe like three register dumps for 0x4d. One at ambient temperature (if you can report the temp ideally), one at like 40degC or so, and one up towards 60degC (heating can be directed towards the little TO92 sensor).

I'll have a look through the firmware to see if there's any more I2C reads/writes that might have thermal management associated with them..

19

I won’t be able to get very granular control over the temps… these switches live in a tiny networking closet. However, if I leave the door open over night, ambient will be ~20C. I’ll test a few times in the morning (if I remember) and then close the door and see if anything goes up a few hours later as temps rise.

1 Like
20

I’m fairly confident register 0x04 on the STC8 is the temperature. I ran an iperf3 test to heat up the phy and somewhat stress the CPU. As the CPU temps went up, register 0x04 fluctuated between 0x2a and 0x2d (42 to 45C). The CPU temps were 46-50C, so it reasonably lines up that the sensor in between the PHYs and CPU would be a little cooler. Stopping the tests pretty quickly dropped it back to 0x2a as the CPU temp went back to 46C.

None of the other registers changed value. I was keeping note of when the fans turned on/off but I didn’t see any changes.

1 Like