Yep, that DM2016N is like an encryption / decryption chip. I think just used so that people don't just clone the board design and copy the FLASH. Although with how rapidly these vendors create new board designs, I'd be surprised if there is really that much IP investment in the board / software.
It looked like the operation of this chip was that the RTL chip sent some data to it... and when it was read back again it should have been encrypted / decrypted to have a given value, which was compared to a constant in the RTL chip, before it would continue booting.
On the Hasivo boards I've seen the DS18B20 one-wire temperature sensor is just connected to one pin of the STC8 MCU... Ditto with some of the fans (whether they are PWM control or not is still unknown to us, along with how to control them). It's just a 3 pin TO92, on the current board I've been looking at, it's got a genuine DS18B20 (or at least a clone with the same labelling).
The LED pads might be visible without taking the PCB out. Depending on how the chassis is put together. If the edge of the PCB is visible at the front. Then you could just hold a multimeter probe to the pads and see if there's continuity to the STC8 pins..
I'm just not sure where the i2c the stc8 is living, the firmware seems to imply on 3/4 but I can't scan anything with a bus declared on there. (the three IDs I mentioned before were all SFP related on that bus at it turns out).
I wouldn't have expected more than one SFP per I2C bus.. and I wouldn't have really expected anything else on any of the SFP I2C buses.
Although bad design / cutting corners is possible...
Since on the SFP addresses A0h and A2h are the default EEPROM and DIAGNOSTICS addresses, it would make it tough to have multiple connected to one I2C bus (unless a bus multiplexer was used..)
That scl=3, sda=4 bus is definitely labelled there as being for the PoE and Encryption module. Which is the same bus I'd expect the STC8 on. For the likes of the low end S1100WP-8GT-SE there are 2x HS104 chips and the STC8 on that bus. For the higher end switches, I'm expecting 1x/2x HS104 chips, 1x/2x STC8, 1x PCF8563 RTC, 1x DM2016 Encryption chip all on that same bus.
And then SFPs on other buses..
With the lack of PoE I wonder if they bothered to even connect it. Might have to do some connectivity tracing to find it. But with the 3/4 pin I2C, I just get a very slow scan that never shows a result. Maybe there's a flag I'm missing (open collector, etc). I'll keep poking at it.... mostly because I went forward with the OG firmware for an application, and gawd is it ancient and awful. (IE: route-maps can take prefix-lists, but they took away the command to define prefix lists lol)
I'd say if there's an STC8 on the board, it'll be connected to the I2C.
The PoE chips sit on a daughter board, so they won't be present.
But the header pinouts are normally still on the board (they're like a 2x5 for I2C and power, and then two 2x8 for the RJ45 wiring). There might be a smaller option for a 4port PoE solution (likely still the 2x5, but with a single 2x8 for the RJ45 wiring), I've only seen the 8port so far.
I tried the 22/23 gpio for the i2c but got the same result as on 3/4. I'll have to keep exploring, maybe the screenshot I showed earlier isn't the right entrypoint (as again no POE).
FWIW I can confirm this for the S1300WP-8GT-2S+, the SFP I2C busses are on i2c_mst1, reg 6 and 7 for the respective SDA pins. Also, for that switch, the "PoE" I2C where all the magic hasivo stuff is on is a software I2C on 3/4, NOT a hardware one. So you have to use something like this:
Not just thinking, it is the SDA number. RTL93xx usually just refers to that number and has the GPIO as a side note. The corresponding pins can either have the I2C or GPIO functionality.
Do you have an RTL8231 chip on your board, or are there HC164 / HC595 chips?
Some boards (like the S1100WP-8GT-SE) have HC595 chips which require a 'latch' signal to load the LED values from the shift registers to the output drivers.
Here's the 16x16 for the 3 devices I do find, which I think is supposed to be enc, rtc, and maybe the STC8 on mine? The second device's values change starting at 0x60, but not sure what it is, most RTCs have their time in lower reg numbers?
Yeah, assuming your board has similar RTC devices, it should be an NXP PCF8563, which indeed has the date/time in the lower registers (everything is < reg 0x10).
Ahh.. I2C does have an annoying 7bit / 8bit addressing situation.
So that 0xA0 and 0xA2 that I gave for the SFP, does indeed drop down to 0x50 and 0x51 if only the 7 bit address is considered.
Unfortunately 0xA2 (0x51 7bit) also corresponds to the PCF8563. (but 0x50 doesn't.. nor does 0x56).
Do you have SFP modules in both SFP ports when you did your 6/7, 22/23 testing?
0x56 is commonly the SFP PHY I2C address. So, I think these are indeed just the SFP buses.
So this might be the master i2c on SDA=6 and SDA=7 (with SCL=8) .
With your I2C bus for gpio3/gpio4...
On my s1100wp-8gt-se this bus needed the PoE board installed for the bus pullups unless the IO was configured to actively drive the pullup state. I think the devicetree properties for that are i2c-gpio,sda-has-no-pullup and i2c-gpio,scl-has-no-pullup.
I see references to PCF8563 in the decompile. Your explanation of 7 vs. 8 bits make s a lot of sense here.
There is actually only one SFP port on this device, though they seem to have re-used something that had two, as much of the hw profile seems to reference a second port.
Nice. So you have a 10G SFP which lets you access the phy "directly" through an i2c bridge. I want one of those. Do you have a pointer to where you got it?
A little trial and error should get this part resolved
They're almost always just a big shift register. 3x595 chips = 24 LEDs. Which was the same number as on the S1100WP-8GT-SE.. so it's possible they just have the same number of ports defined (8) with 3 LEDs per port... and then have only wired up the ones that actually mean anything.
Also it's not quite just an off-by-two, but every port shows up on at least one other's LED except one, which I guess is on the "ghost" port.
I just kind of rolled with the mdio/phy section you suggested. Maybe I need to look there? Would misaligned serdes mappings explain it? No, because it matches hwp_macID2SerdesID.
It's all there port wise, just a bit confused. Note: OpenWRT sees ports in the right order.
You could always start with just a single LED defined per port. When you plug into Port 1 you should get a single LED on Port 1. When you plug into Port 2.. expectation is that you'd get a single LED on Port 1 AGAIN... Plug into Port 3, and then Port 4... you now know how many LEDs to define for the RJ45s... that should work for all 6 (?) of the RJ45s.
LEDs are a per port thing. But that's RTL93xx port (0..27 for RTL930x, 0..56 for RTL931x).. not necessarily physical port.
Your hwp all dump does actually have some LED info, such as number of LEDs, and the LED configuration... but I didn't look at that, most of the Hasivo switches have been pretty consistent on LEDs thus far..
)