Biggest problem at least on dgs-1210-10p is that mode button function isn’t supported or even defined in the dts file. And not the reset button either (well that button is there behind comment marks but non working if tried).
And even less background software to do anything with the buttons.
So it isn’t possible to shift to poe lights without mode shift.
A bit off-topic for this thread, but the reset button on the DGS-1210-28 was added recently. The DSG-1210 devices seem to have some details in common, so maybe that helps to figure out the button(s) for the -10P? The commented out entry will certainly not work, because that was still for the all-in-one GPIO driver.
I wouldn't be surprised if the button is the same for the whole DGS-1210 series
It is exactly the same dts code now in -28 that -10 always had in it’s dts file from the beginning, that is why I was surprised when the commit said it now works on the -28!?
Is it even tested on -28 or did someone only add the dts button code and assumed it works?
Its tested on -28
I stand corrected, the code isn’t the same. Maybe the -28 code would work on -10p?
The button is probably connected to the same pin on the whole series, but without others testing the current supported models, there isn't much that can be done.
I did some tries in the beginning on my own -10mp to map the GPIO when pushing the two buttons. But it never was “only one GPIO” that changed when pushing a button multiple times?
So I moved on with the poe and left the buttons for time to find any solution.
But I did find the GPIO for the system LEDs (link/act, poe and max poe) and tested them by running them as “boot led” one at a time.
You can buzz the button with a multimeter on the RTL8231, that is how I found the LM63 pins
led_poe_max: poe_max {
label = "yellow:poe_max";
gpios = <&gpio1 27 GPIO_ACTIVE_LOW>;
};
led_link_act: link_act {
label = "green:link_act";
gpios = <&gpio1 28 GPIO_ACTIVE_LOW>;
};
led_poe: poe {
label = "green:poe";
gpios = <&gpio1 29 GPIO_ACTIVE_LOW>;
};
These LED on DGS-1210-10MP F1 I am absolutely sure about because I tested them as boot and upgrade lights.
I added the reset pin patch and the same pin works for 28 and 52 port variants. And the latter even uses a different SoC.
It was quite easy to find it: export all GPIO ports (those in use might fail) and cat their value in loop. Press and hold the button and see who flipped.
I also used a similar brute force strategy to find the reboot pin: slowly assert and dessert all unused pins in sequence. You will notice when the wanted pin appears.
Those pins are in the extra GPIO chip. Maybe that one is different for the 10 port variant.
I tried the gpio 1 port 33 for reset when I tried making this work in the beginning to get it workin. I logged the GPIO outputs manually many times (like 5 or 10times) back then and analyzed the difference in the data. Pin 33 was in the end the only pin left changing every time.
But I never got any reset function when trying to build a image with that reset pin.
Nothing happened, tried holding the reset for 30sec without any reaction at all?
Is it possible to get a reset function (at least the first reset activation that reset the device to actual installed image) with the initramfs image loaded or does it only work with actually installed images?
Or is there some forgotten reset function in kernel setting that must be activated?
I took -28 as template for creating the -20 dts files. Assumed that Revision F switches use the same GPIOs. Additionally I noticed that running the -16 image (without GPIOs) does not allow to reboot the switch.
If there is something I can test just tell me.
Ok tried again and it now reboot. The actual fault was the fact that I pushed the reset button and waited like SOP for reset. But it actually only works with a quick push of the reset button.
So now I have made it work with initramfs image.
The gpio-restart block that was introduced in -28 dts, what controlls the input on gpio1 34 and is that block needed on the whole switch family?
Where in the code is the port status/act LED array shift registers controlled from?
These are managed by a dedicated port LED peripheral that in turn drives the shift registers. There is no driver for that on RTL838x (the hard part is not the driver, but making it acceptable for upstreaming), and a bit of a hacky method (raw register values in DTS) for RTL930x.
The Act Led in the Led array seems to its job as is. I was thinking about how the POE status led in the array is controlled by the mode key and the SoC.
It seems that pretty much all the connector pins for the IO card (led and keys and shift registers PCB) goes to the port expander.
Poe max led must be controlled by the realtek-poe package in the end because that is more like consumption > budget = turn on LED.
The PoE LEDs can be managed directly by the MCU, or by the OS. If there's a mode switch, it will probably be the latter, but the LED settings still need to go through the LED peripheral.
Was looking at my pictures of the I/O PCB and there is three 8-output shift registers behind the LED array.
So my hypothesis is that there are one shift register for each of 8 port Led: green 1Gb, orange 100Mb and one for the PoE Led?
Depends on how things are controlled, but the shift registers don't necessarily map to one type of LED. If all three LEDs are controlled through the SoC peripheral, the registers will be chained, and every 3rd output will correspond to a different port. For example: