Are we looking at the right place for the LM63-I2C? (SCL/SDA either GPIO1 Pins 31/30 or Pins 31/32)
what magic does the original FW apply to pull-up GPIO31?
@svanheule: can you shed light into what you have done? what can be done to pull-up the GPIO31? according to the pdf, the GPIO does not support pull-down/up, doesn't it?
The pull-up is just there. You can't change it, you can't disable it. It is very weak, so one could still use a stronger external pull-down (e.g. 4.7kΩ) if a design would require that.
lets see if i have a chance to disassemble the switch over the weekend and find some solution to the the fans blowing... (i am ready to accept hacks as well)
Usually, i find ways to make HW quieter, its the first time I put significant effort into getting something being louder
If you can find a place to insert a pull-up between the SCL and VCC, that would probably be the 'easiest' hack to permanently fix this issue. If you don't mind registering on the wiki, https://svanheule.net/switches/dgs-1210-24p is empty and waiting for device info and pictures
The expected wiring is FAN-Ports -> LM63
LM63-Pin 8 (SMBClock) -> to RTL8231 Pin 9 (GPIO31)
LM63-Pin 7 (SMBData) -> to RTL8231 Pin 8 (GPIO30) or Pin 10 (GPIO32)
right?
my soldering skills are unfortunately more on the low-end, i doubt that i am brave enough to solder something on the switch (to tiny)..
having said this, I am still wondering how the original FW is able to pull-up the SCL, at least i didn't saw any resistor jumping out of the Switch when i flashed openwrt
For sure, I will take pictures,
but honestly i didn't plan to rip off the heat-spreaders... when looking at the dgs-1210-28p pictures, i would say, that its the same device as I have. and before i bought it, i didnt manage to fully understand the difference between the 24p and 28p... both have 28 ports + 4 SFPs..
You can buzz the pinout with a multimeter, that's how I did it ages ago.
LM63 has a public datasheet so its pins are known and that's all that's required.
Internal pull-upp/dn is most often a pretty high resistance since a pull-up/dn only are a fixed potential reference.
But back in the days when I was designing I2C circuits the SDA/SDC pull up are a function of the rc time based on the capacitance of the PCB track and IC pins to get rise times of the square wave within specs so it will be impossible to use internal pull-up/dn resistors since they are a function of the PCB. Usually they would probably be around 400ohms for I2C databus if I remember right.
R between LM63 Pin7 and Pin1 = 4.6k
R between LM63 Pin8 and Pin1 = inf.
This is pointing indeed the floating Pin, but..... I still believe i am missing something, because:
a) the orig. FW is able to communicate with the LM63
b) if there was a real big design flaw in the Revision F* i would have expected that they would have fixed it with the Revision G2 that I have... (eventually non-working fans result in warranty-issues...)
@svanheule: will postprocess the pictures on later/tomorrow and upload to your wiki. Anything specific i should shoot?
You can have a look at some of the other pages. I normally to device and board overviews, and then more detailed shots where package labels are (more or less) readable. That usually helps against having to open up a device again and again.
Having an overview of hardware info from the original device FW is also good to have, if that's available somewhere (IIRC the firmware on these switches doesn't allow for dumping this debug info).
I was wondering if it could be possible to upload openwrt images to DGS-1210 switches directly from vendor web UI. Looking inside the images it looks as if a small 64 byte header is created. I digged in the GPL sources and found the imghdr binary (works on x86).
/home/user/gpl/DGS-1210-16/host/tools/imghdr openwrt.bin openwrt.hex DGS-1210-16 SS 2 2 1
hdr_len is 64
model name: DGS-1210-16
signatue: SS
partition is 2
customer signature is 512
board version is 16777216
test.hex len is 6029216
checksum = 305f9ded
If you compare the header of the generated image and an official firmware afterwards this looks very promising.
It's possible to add the header as well as the required checksum, but note that trying to flash the OpenWrt image would fail most likely.
This is because the kernel partition is ridiculously small and the stock FW flashes kernel and rootfs separately.
I tried using those tools to utilize the whole rootfs, but they are checking for the header and checksum in the kernel and rootfs partition range only, so in the end I had to modify the bootloader to utilize the whole NOR.
BTW, pretty much whole DGS series userspace is in the ISS.exe binary, its huge and it took me like 45minutes for Ghidra to fully decompile it (On a Ryzen 5950x), but it looks like they left the debug symbols so almost all functions are readable.
I am looking at how they interface with the LM63, but so far in the init they are just using an IOCTL in drv_smi_read against /dev/rtcore which is the core kmod.
I'm of the opinion its a regional marketing thing. The DGS-1210-28 F series are available in North America while it sounds like the G series are available in Europe.
If that's the case, we can just keep the info on both devices on the same page. No need to duplicate information (and the forget to update one of the pages later on). However, the datasheets linked on the wiki for both revisions have an 'eu' suffix, so perhaps there are some (small) differences.
The other side of the ioctl of the drv_smi_read is in the GPL released package of the DLink Firmware. It is doing bit-banging on GPIOs... But this would still not explain how it can work without a pull-up, wouldn't ?
@RaylynnKnight thanks for confirming. Is it possibly that they just have renamed it? Because the 24p does not have a "F" revision, vice versa the 28p doesnt have a "G" revision.
@svanheule i am happy to share my pictures with you and you can double check/judge if you can spot any difference between the two... I do not find any