That is is kind of the thing that the easiest and fastest way to get the grips of this LED hardware is to measure the connections and make a circuit schematic.
I tried a real install with a build with active reset key.
But the push of reset key start the
linux,code = <KEY,RESTART>
command and makes a reboot.
And this reset command is on almost all OpenWrt devices I looked in the dts files.
It looks like a reset when testing it with initramfs image since the initramfs image is dropped on reboot.
But that isn’t a reset, it is just a reboot. How are we supposed to get it to actually reset the installed firmware?
If you want to factory reset, just hold the button for some time, the it will factory reset
1 Like
Ok, nice! Now it works. It was that part that never worked when holding the key when running a initramfs image. Then only a small push worked.
Seems to be around 7seconds to activate the reset.
The gpio-restart block from the -28 dts file doesn’t seem to be needed for the -10P/MP.
If that pin does trigger the reset, I believe it might be interesting to keep it. It might reset more things than the SoC. Linux Kernel can use multiple methods to reset the machine. However, I'm still a newbie in realtek target. The experts might say I'm wrong.
The devicetree should describe the hardware as accurately and completely as possible IMHO. If the reset line is wired to a GPIO, then that should be preferably be described as such.
For Linux/OpenWrt specifically, gpio-restart on these boards will take precedence over the watchdog restart, if the reboot priority of gpio-restart is greater than, or equal to, 129. These GPIO -triggered reboots are typically more reliable.
But if I have it in the dts file, how do I even test if the gpio connection for this gpio-restart even exist and work on the PCB on the -10mp since the heatsink is soldered with rivets to the PCB.
You can take that node out of the DTS and then manually toggle the GPIO. The moment you set the line's output to GND (logic low for a non-inverted GPIO), the device should reboot. If nothing happens, then that GPIO is not connected to the device's reset pin.
1 Like
Tried today manually set GPIO485 (gpio1 pin 34) and it restarted right away so the function is available for -10MP also.
1 Like
To double check if you got everything right, you can add the gpio-restart node and disable the watchdog. With both nodes removed/disabled, the device should hang when rebooting, with a "failed to reboot" error message.
Do I do that i kernel menuconfig?
You can do that in your device's DTS:
&watchdog0 {
status = "disabled";
};
1 Like
You say both nodes but do you mean to add the gpio-reset block to the dts and disable WDT?
Am I supposed to activate the reset with pin 34 or reset key?
With "both nodes" I did indeed mean watchdog@3500 and gpio-restart. Setting status = "okay" on either one of them should allow you to reboot your device. Having status = "okay" on both of them will result in the GPIO restart being used to reboot the device (when using the default priority or higher).
Once you have (one of) these nodes enabled, the associated driver(s) will register a so-called 'restart handler' with the kernel. That's a piece of code that the kernel will use when a request to restart the device comes in. You can generate such a request this by running the reboot utility, or (in OpenWrt) by pressing a button that will send a KEY_RESTART event. Usually, a button labelled "reset" will issue such an event, but this needs to be set up correctly in the devicetree. See for example the DGS-1210-28.
Ok, I first disabled both the WDT and the gpio-reset block and then reboot failed.
I then tried with WDT disabled and gpio-reset enabled and the reboot worked.
So it seems that the reset function works initiated with reset button.
1 Like
Have anyone made an attempt for the SFP I2C communications for the D-link dgs-1210 series?
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>;
};
};
gpio-restart {
compatible = "gpio-restart";
gpios = <&gpio1 34 GPIO_ACTIVE_LOW>;
open-source;
};
keys {
compatible = "gpio-keys-polled";
poll-interval = <20>;
mode {
label = "mode";
gpios = <&gpio1 30 GPIO_ACTIVE_LOW>;
linux,code = <KEY_LIGHTS_TOGGLE>;
};
reset {
label = "reset";
gpios = <&gpio1 33 GPIO_ACTIVE_LOW>;
linux,code = <KEY_RESTART>;
};
};
This is what have concluded at this point for the -10mp that is added from the original -10p dts file I begun with.
I tried (and failed) with dgs-1210-52 but it has a different SoC. That device might need more work.
You can try using this branch https://github.com/bkobl/openwrt/tree/rtl8214qf_merge. It looks like there is support for dgs1210-16. I believe it should work with all dgs-1210 devices but the -52 variant.
1 Like