I now "hacked" a solution by entirely bypassing the lm63 dance.
With some left-over plugs from Noctura PC fans, I directly attached 12V to the fans
(see picture below)
I took +12V from one of the original 3PIn-Connector for the fans
and GND i added a cable to one of the 3 gnd wires (black colored) that came from the power supply board to the mainboard.
The generated noise is okay-ish.. (switch will end up in basement, so it doesnt matter sooo much for me)
At least now i can mount the switch and start using it...
next step is for me to extend the poe.lua script to support more than 8 ports and add some further infos into it. (like temperatures) or is there already something similar available?
The "more power" version uses a smaller total cross section than the "power" version?
If you hadn't already planned to do so, I would suggest to just create a new subsection on the existing 28(M)P page, since these devices are so similar.
Have a look at the realtek-poe thread to join forces:
IIUC, only the clock line is floating, right? Isn't it possible to force the clock line, ignoring the spec? That's what I read from i2c-gpio.c is the meaning of "i2c-gpio,scl-output-only". So don't configure the clock gpio as open drain. Make it an output.
I really don't know what I'm talking about here, but that has never stopped me...
this results in the i2c is "fully populated" but any read results in 0x0.. so i guess, there is slightly more to that.... possibly the truth lies in how the orig driver does the GPIO setup (before drv_smi_read etc)
Yes, I guess it is. I thought i2c-gpio,scl-open-drain had the opposite meaning, but I see now that this is the correct way to try to configured a forced clock line.
Except... The i2c-gpio driver defaults to 5 µs delay which is increased to 50 µs when i2c-gpio,scl-output-only is set. Why are you setting it as low as 2 µs? Did you try using a higher value?
Thanks for the helpful insights. Nevertheless it would be nice to flash D-Links without serial. Looking around my DGS-1210-16 appDemo.exe (A1 predecessor of ISS.exe) I found some helpful information. Maybe something like this works on later firmware too:
DGS-1210-16 login: guest
Password: guest123 (hard coded ...)
DGS-1210-16> show privilege
Current privilege level is 1
DGS-1210-16> enable 15
Password: ilovecameo (hard coded ...)
DGS-1210-16# show privilege
Current privilege level is 15
DGS-1210-16# system call "sleep 10" --> comes back after 10 seconds
DGS-1210-16# system call "/usr/sbin/telnetd -p 10023 /bin/sh" --> not working, tbd ...
I dont think that removing GPIO_OPEN_DRAIN from the GPIO properties works as:
[ 8.442319] gpio-482 (scl): enforced open drain please flag it properly in DT/ACPI DSDT/board file
[ 8.452529] i2c-gpio i2c-gpio: Slow GPIO pins might wreak havoc into I2C/SMBus bus timing
[ 8.462349] i2c i2c-0: Not I2C compliant: can't read SCL
[ 8.468435] i2c i2c-0: Bus may be unreliable
[ 8.473234] i2c-gpio i2c-gpio: using lines 483 (SDA) and 482 (SCL, no clock stretching)
I checked with a logic analyzer and SCL is always digital 0 while SDA is fine.
Yeah, there is no way such aggressive timing was achievable with bit-banging here.
I was missing the property as its description is really stupid, and with it being marked deprecated as well it makes it look like setting GPIO_OPEN_DRAIN replaced it
Yes, it's hard to understand what it does without reading the driver. Which you shouldn't have to do to create a device tree, since that's really supposed to be a hardware description and not a driver configuration description.
DT bindings are getting better, but the older ones are really hit and miss.
This time googling the open-drain enforcement message led me to the part of the driver which had the check for i2c-gpio,scl-open-drain in which case it sets the SCL GPIO as output or otherwise it enforces open-drain regardless.
Which is contradictory to me, but I am also glad that there isnt some black magic being done in the stock FW (But WTF they decided not to add the pull-up only for this I have no idea)
Apparently this is due to the behaviour of for_each_cpu(cpu, mask) on uniprocessor systems (like RTL838x). Somewhat counterintuitively, the provided mask is ignored entirely. So while cpumask_empty() returns true, for_each_cpu will still loop over exactly one CPU
Ughh, why do I have a feeling that this is one of the wonderful legacy leftovers.
BTW, no idea what are the pins for the second and last SFP, none of the RTL nor CPU GPIO-s appear to be used for it.
Ughh, scratch that, It seems that Vcc is missing on the SFP connector somehow
The way routers implement this is to not allow L2 MAC learning on a port and discarding all traffic from unknown source addresses. They then trap all 802.1x EAPOL messages to the CPU port or wherever the authenticator sits, alternatively you can flood all traffic with unknown source address to that port (careful with denial of service here, the CPU-port is not overly powerful). When the device is authenticated, a static L2 entry is inserted and traffic can start to flow. There is already an API function for this:
which is called by the DSA API functions port_pre_bridge_flags()/port_bridge_flags(). They also control flooding. Target ports are set up via void rtl838x_enable_flood(int port, bool enable) The learning is set up via the port_fdb_add() DSA functions.
Now you need an authenticator which can issue bridge calls. I believe that @blogic and brainslayer have written a modified wpad for this, brainslayer also wrote the RTL83xx functionality necessary.