try tftpboot 0x84000000
instead
Yes. But the first problem is that tftp times out. I usually do (after symlinking x.bin to the image I want on the tftp server)
rtk network on; tftpboot 0x84f00000 x.bin; bootm
Yes, tftpboot with 0xb4100000
will times out.
Can any physical port be used for tftpboot?
And is the firewall configured properly, server-side?
Shouldn't be an issue, all ports are connected to that single switch.
Thanks worked like a charm.
It boots the 23.05.2 initramfs
.
I have no GS1900-8v1 23.05.2 bootlog to compare with.
But looking through the log I see:
[ 14.143595] random: jshn: uninitialized urandom read (4 bytes read)
[ 14.717244] RESETTING 8380, CPU_PORT 28
[ 14.922418] rtl838x-eth 1b00a300.ethernet eth0: configuring for fixed/internal link mode
[ 14.931510] In rtl838x_mac_config, mode 1
[ 14.939306] rtl83xx-switch switch@1b000000 lan1: configuring for phy/internal link mode
[ 14.948730] rtl838x-eth 1b00a300.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
[ 14.958444] 8021q: adding VLAN 0 to HW filter on device lan1
[ 14.965425] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 14.972652] rtl83xx_fib_event: FIB_RULE ADD/DEL for IPv6 not supported
[ 14.980281] rtl83xx_fib_event: FIB_RULE ADD/DEL for IPv6 not supported
[ 15.030289] rtl83xx_fib_event_work_do: FIB4 failed
[ 15.035704] RTL8380 Link change: status: 1, ports 100
[ 15.058425] rtl83xx_fib_event_work_do: FIB4 failed
[ 15.063842] rtl83xx_fib_event_work_do: FIB4 failed
[ 15.073773] random: procd: uninitialized urandom read (4 bytes read)
[ 16.658272] rtl83xx_fib_event: FIB_RULE ADD/DEL for IPv6 not supported
[ 17.438507] rtl83xx_fib4_del: no such gateway: 0.0.0.0
This repeats for every port.
Luci is accessible and I don't see any errors there.
I have the full bootlog and systemlog if someone needs them.
That error is not shown in the v1 bootlog here, but I can see it in other models. Perhaps because the live image is not configured?
To everyone else: what could @goetz do to deduce the hardware configuration to compare with the previous revision? Does the initramfs have inxi or something like it?
Those are run of the mill errors on rtl838x, nothing to worry about.
Reboot problem with D-Link DGS-1210-16 G2 and OpenWRT 23.05.02
My D-Link DGS-1210-16 hangs on reboot just as mentioned here. From the information there, it looks like the DGS-1210-16 also needs to have GPIO pin 34 pulled low for proper reboot, just like the rest of the RTL838x based DGS-1210 family. But - unlike the close cousins DGS-1210-20 and DGS-1210-28 - the DTS for the DGS-1210-16 does not include the relevant DTSI.
Is that just by accident, or is the DGS-1210-16 really that different from DGS-1210-20 and DGS-1210-28?
We had a similar discussion about a year ago in this thread
And in that discussion, you said that the DGS-1210-16 also needs to use GPIO Pin 34 for reboot, which suggests that it works just like the DGS-1210-20 and DGS-1210-28.
But the current DTS for the DGS-1210-16 does not include rtl83xx_d-link_dgs-1210_gpio.dts which defines the related functions (support for the rtl8231 GPIO chip, reboot via GPIO 34 on that chip, and wiring up the reset button on GPIO 33).
Hence my question: Is that just a missing include in the DTS, or does the DGS-1210-16 need something different here than the 1210-20 and 1210-28 (both of which do use rtl83xx_d-link_dgs-1210_gpio.dts)?
Edit: I'm just browsing through the DTS for DGS-1210-16 and DGS-1210-20, and the only difference I can see is the include line for rtl83xx_d-link_dgs-1210_gpio.dts. and the "compatible" line.
Does that mean I can just flash the DGS-1210-20 image to get (possibly) working reboot, or do I run the risk of bricking my switch with that?
Since you've got the device, you will have to answer this yourself - I only own a -28MP. And if you come to the conclusion that this GPIO is correct and needed, please submit a PR with the required changes.
I'm willing to try - but I think I'll try to go with using the DGS-1210-20 image first. The DTS for both look almost identical (except the GPIO include and the device name in "comaptible" and the D-Link website is inconsistent on whether their 20-port DGS-1210 switch is named DGS-1210-16 or DGS-1210-20 (mine is labeled DGS-1210-16, but as it actually has 20 ports DGS-1210-20 would be the more logical name), which makes me supsect that the DGS-1210-16 and the DGS-1210-20 are actually the same device...
The only thing that makes me a bit reluctant is that I need to open the case to get at the serial console, which would a) void my warranty and b) get me uncomfortably close to wires carrying 220V...
After browsing both https://www.dlink.com/en/products/dgs-1210-series-gigabit-smart-plus-switches and https://www.dlink.com/de/de/products/dgs-1210-series-gigabit-smart-switches, I think D-Link is just inconsistent in their own naming scheme: The english web site has a DGS-1210-20, DGS-1210-28 and DGS-1210-52 with 20, 28 and 52 ports (four of which are combo SFP/1000Base-T ports). The german website has switches with exactly the same specs and number of ports, but names them DGS-1210-16, DGS-1210-24 and DGS-1210-48.
I don't think that you need serial console for this, unless something fails. If you're already running OpenWrt, you can force-upgrade to the -20 image if you are certain that it is similar enough that it's going to work. The -20 image just won't flash from the OEM interface, as the model doesn't match.
If you were able to flash from the OEM interface, you picked the right OpenWrt image in the first place.
That said, it is probably safer to build a -16 image with the GPIO fix applied and flash that using regular sysupgrade.
D-Link is known for changing SoCs between revisions, so there are -48 variants with really "just" 48 ports (only copper ports are counted, they do not include SFP ports in their port count). The -52 has 4 additional RJ45 ports (as combo ports, shared with SFP).
That is exactly what I just did, and it worked perfectly. Working reboot, and a working reset/failsafe button.
So, for the record: If you have a DGS-1210-16 Revision G2, you can use the OpenWRT 23.05.2 image for the DGS-1210-20 to get a working reboot and reset button support.
Will do so. Done - see https://github.com/openwrt/openwrt/pull/14943
The device name has not always matched the number of (independent) ports on these switches: https://svanheule.net/switches/dgs-1210_series
The model names should be consistent globally for the different revisions. So sometimes you can tell if it will contain a Realtek SoC, sometimes you also need to know the revision.
In this case, it seems that D-Link uses different names for the same realtek based hardware. Or at least for hardware that is similar enough that the existing OpenWRT images for one can be used on the other:
- openwrt-23.05.2-realtek-rtl838x-d-link_dgs-1210-20-squashfs-sysupgrade.bin does run on a D-Link DGS-1210-16 Rev. G2
- Checking the OpenWRT sources strongly suggests that openwrt-23.05.2-realtek-rtl838x-d-link_dgs-1210-16-squashfs-sysupgrade.bin should run on a realtek based D-Link DGS-1210-20 (which should be revision F if I can believe the D-Link website)
- Comparing the current english and german product pages for the DGS-1210 family suggest that the following devices are either identical or at least similar enough that they can run the same OpenWRT images:
- DGS-1210-20 Rev. Fn and DGS-1210-16 Rev. Gn
- DGS-1210-28 Rev. Fn and DGS-1210-24 Rev. Gn
- DGS-1210-52 Rev. Fn and DGS-1210-48 Rev. Gn
The common pattern in the naming scheme seems to be that the english version counts all ports (including the 4 RJ45/SFP combo ports) in the device name, while the german version only counts the pure RJ45 ports.
I reviewed and approved this simple pull request. @svanheule could you possibly merge it?
I installed 23.05.2
fine.
The following error is logged and repeats many time during boot and while running:
rtl83xx_fib_event: FIB_RULE ADD/DEL for IPv6 not supported
rtl83xx_fib_event_work_do: FIB4 failed
Searching for this, reveals that other RTL838x
bootlog and patch discussions on the openwrt-devel
mailinglist contain this as well.
If someone from the moderators
would give me a wiki account, I would start to update the device page.
@svanheule is a formal patch needed to include v2
in the firmware / buildbot docs?