Support for RTL838x based managed switches

This is now becoming a bit spooky...

Doesn't all this basically nail down to:

  • 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.

thanks for clarifying..

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 :slight_smile:

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 :upside_down_face:

1 Like

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 :wink:

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.

did the measurements.(Device turned off and detached from power supply)

LM63 Pin 8 = SMBClock goes to RTL8231 Pin 9 = GPIO 31
LM63 Pin 7 = SMBDat goes to RTL8231 Pin10 = GPIO 32

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).

Hi,

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.

[user@fedora x]$ hexdump -C DGS-1210-16_A1_2-03-001.hex | head -4
00000000  09 70 c6 a3 44 47 53 2d  31 32 31 30 2d 31 36 00  |.p..DGS-1210-16.|
00000010  00 00 00 00 00 00 00 00  6f 73 00 00 00 00 00 00  |........os......|
00000020  00 00 00 00 00 00 00 00  02 40 00 02 00 00 00 01  |.........@......|
00000030  00 11 ff 50 30 78 63 30  30 30 38 30 30 30 00 00  |...P0xc0008000..|
[user@fedora x]$ hexdump -C openwrt.hex | head -4
00000000  30 5f 9d ed 44 47 53 2d  31 32 31 30 2d 31 36 00  |0_..DGS-1210-16.|
00000010  00 00 00 00 00 00 00 00  53 53 00 00 00 00 00 00  |........SS......|
00000020  00 00 00 00 00 00 00 00  02 40 00 02 00 00 00 01  |.........@......|
00000030  00 5b ff a0 00 00 00 00  00 00 00 00 00 00 00 00  |.[..............|

As I just noticed I have only a DGS-1210-16 rev. A1 and I cannot test. Hopefully this info might be useful to someone else.

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.

The DGS-1210-28MP also has 2 fans driven by an LM63. Photos are already on the wiki.

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

I have the F version of DGS-1210-28, DGS-1210-28P and DGS-1210-28MP. The photos on https://svanheule.net/ and https://wikidevi.wi-cat.ru/ are from my devices.

I have bought the F2 in EU, so its not a regional thing

Yeah, it really makes no sense to me

I have now studied the 28P, 28MP and mine 24P pictures intensively.

interesting difference are visible when comparing the 28P and 28MP, some expected some not.

  • the 28P and MP have different power-supplies (this is expected)
  • the MP chassis was prepared for 4 fan-mounts, but only same 2 are equipped as the P
  • both share the same heat-spreaders around the eth-plugs
  • the 28P uses 3x12V, 3xGnd on the connector to mainboard, the 28MP only uses 2x12 and 2xGnd

In contrast i could not spot any difference between the 28P and 24P. So i would sort-of-guess that these are the same devices.

But i will add some closeups and further infos onto the wiki page