D-Link DIR-685 booting a mainline kernel with prompt in the little display. The touchkeys on the right provide "enter" but that is the only useful input to the terminal without any GUI tools.
I have moved the basic use and set-up of the device to the corresponding OpenWrt DIR-685 device page where it is properly maintained by the community. This page is just my own musings and tricks, and a bit of history.
Files
- Here is my latest factory image for the router, this is based on mainline OpenWrt as of 2024-05-15, and has ksmbd and LuCI compiled in. Flash it using the recovery web server in the device as described on the OpenWrt page.
- There is a datasheet from D-Link.
- 2024-05-15 I am working on some Gemini ethernet fixes to stabilize the network, these are in the image on this page, and submitted for inclusion into OpenWrt and mainline Linux.
- 2023-12-02 Three fixes for the Gemini ethernet affecting DIR-685 has been merged into kernel v6.1.64 and is now in the OpenWrt images.
- 2023-08-07 OpenWrt Patches for kernel v6.1 have been merged since late may, but v6.1 is still unstable in OpenWrt mainline. I found a small patch was needed for DIR-685 due to changes around the RTL DSA switches. Built factory image for kernel v6.1, available above.
- 2022-07-07 The prebuilt image on this page was updated to use v5.15 and the latest OpenWrt with ksmbd enabled. Gemini patches were merged and also the backport of RTL8366RB improvements were merged to OpenWrt.
- 2022-04-12 OpenWrt was bumped to kernel v5.15 and I pushed a patchset to move Gemini forward with this device as well.
- 2021-11-08 the RTL8366RB switch has been extensively improved, supports port isolation and proper switch states. Patches merged for kernel v5.16.
- 2021-04-12 the RTL8366RB switch now support tagging in both directions (ingress/egress) and the patch is available in kernel v5.10 and a patch has been submitted to OpenWRT to bump to this version. The image on this webpage is updated.
- 2020-08-09 the RTL8366RB switch is now working with the mainline Linux kernel soon to be released as v5.9-rc1.
- 2020-06-18 I figured out parts of the DSA tag format for the RTL8366RB protocol "A" and sent preliminary patches to the netdev list, so that the network thru the switch can hopefully be made to work out-of-the-box.
- 2018-08-08 Also the WAN port on the RTL8366RB is working.
- 2018-07-14 I have the RTL8366RB router chip working on all four LAN ports (not the WAN port) so ethernet is up.
- 2018-04-11 I have it booting OpenWRT and working graphics, touchkeys, LEDs, SATA, DMA etc.
- Wireless - because of no working RT2880F driver and firmware
- D-Link DIR-685 opened up
- D-Link DIR-685 touch input PCB
- D-Link DIR-685 touchkeys close-up
- D-Link DIR-685 screen
- D-Link DIR-685 PCB front 1, 2
- D-Link DIR-685 PCB back
- D-Link DIR-685 Fan
- A Ilitek ILI9322 display controller for 320RGBx240 connected to a panel with the label LM918A01-1A SY-B4-091116-E0199 connected to the main PCB with a flat cable (we know this is driven by a ILI9322 from the boot messages)
- Touch input module PCB with a Cypress Semiconductor CY8C214 MCU, with a LED connected to it (the WPS flashing LED), connected to the main PCB with a flat cable
- A Sunon Maglev GM0502PFV2-8GN 0.4W fan connected to the main PCB, software controlled
- A soldered (!) Alpha Networks WMP-N08 Mini-PCI RaLink RT2880F-based wireless network card, inside the shield box is a RT2850L antenna driver. The Linux driver is named "ralink_RT2880_iNIC" and is version v1.1.8.3 in the source drop but it doesn't contain the source code.
- Main PCB:
- A blue LED indicating power on
- A Spansion S29GL256 256 Mbit (32MB) CFI NOR-flash memory
- A Hynix HY5DU121622DTP-D43 512 Mbit (64MB) SDRAM classed at 200MHz
- A Bothhand GST5009 LF 1000 Base-T magnetic module (galvanic isolator) facing the WAN port
- A RealTek RTL8366RB switch using GPIO for control
- Two LFE9407 Delta LFE9407 LAN Filters (also galvanic isolators) facing the four LAN ports
- A TI SN54LVC14A schmitt-trigger array
- Inside the shield box:
- The Storlink SL3516 SoC ASIC
- RealTek RTL8366SR ethernet PHY/switch
- Another Hynix HY5DU121622DTP-D43 of 64MB SDRAM so in total we have 128MB SDRAM
- An LXC16373 latch array
Status
This is missing:
Getting into it
You need to remove four screws on the bottom and then there are plastic snap locks around the edges, I open these with a credit card or a letter knife.
Circuit board photos
Identified electronics:
Connecting a UART
J3 on the top is obviously the serial port. Helpfully there is even a header. There is some documentation I found online on the layout of the serial port:
PINS: o o o _ o | | | | | | | RX | | VCC | GND TX
The serial port configuration should be: 19200 baud, 8 bits, no parity, no flow control. After soldering a RS232 interface accordingly, the console works like a charm!
Getting OpenWRT up on it
PRELIMINARY INSTALLATION INSTRUCTIONS, WARNING WE DO NOT YET SUPPORT SYSUPGRADE SO CONSOLE ACCESS IS REQUIRED TO REFLASH!
- Plug the DIR-685 into your computer ethernet using one of the LAN ports on the back. Set your computer to obtain network from DHCP.
- Turn on the router. The router should boot and assign an IP number to your computer. Check what IP you get: I got 192.168.0.100.
- Check that you can contact the router: ping 192.168.0.1
- Start a browser and browse to 192.168.0.1
- Log in as "Admin", blank password.
- Select "Tools" from the top row pane
- Select "Firmware on the left pane
- Select "Browse" in the "FIRWMARE UPGRADE" box
- Select the openwrt-gemini-dlink_dir-685-squashfs-factory.bin file from the OpenWrt build or from another trusted source
- Hit "Upload"
- The router says "The F/W is updating..." also in the little display.
- Next thing that happens is that OpenWrt boots the kernel from flash.
- Note that INSTALLATION IS NOT FINISHED YET if you just reboot the router here, it will be bricked.
- Wait for the following text on the console (this can take a few
minutes):
jffs2_build_filesystem(): erasing all blocks after the end marker... jffs2: notice: (1645) jffs2_build_xattr_subsystem: complete building xattr subsystem, 0 of xdatum (0 unchecked, 0 orphan).
This means the flash is set up and ready to be used. - Configure networking so you get SSH access to the host
- Upload the openwrt-gemini-dlink_dir-685-squashfs-sysupgrade.bin image to the routers
/tmp directory.
If your networking is set up properly it should be just:
scp openwrt-gemini-dlink_dir-685-squashfs-sysupgrade.bin root@192.168.1.2:/tmp - Issue:
sysupgrade /tmp/openwrt-gemini-dlink_dir-685-squashfs-sysupgrade.bin - The DIR-685 will flash the firmware upgrade and reboot
- After this you can proceed with full configuration etc.
The firmware can also be reflashed from the RedBoot derivative "Boot Menu" that comes up if you have a serial console like this:
- Select "Y: Upgrade Kernel" by pressing "Y"
- Select TFTP or serial download (see elsewhere for how that works) Download the openwrt-gemini-dlink_dir-685-squashfs-factory.bin file using TFTP, you need to rename it because the boot loader cannot handle this long filename. I just name it openwrt
- The boot loader will erase and flash the image looking something
like this:
Erase flash (0x30040000): Size=32768000 ........ Program flash (0x30040000): Size=6750212 ........ Reboot to start the new firmware and it should come up.
After first boot the dmesg displays this stuff on the console. DO NOT POWER OFF THE DEVICE WHILE THIS IS GOING ON!
[ 25.636854] mount_root: jffs2 not ready yet, using temporary tmpfs overlay (...) [ 74.996487] jffs2_scan_eraseblock(): End of filesystem marker found at 0x0 [ 75.126315] jffs2_build_filesystem(): unlocking the mtd device... [ 75.126340] done. [ 75.256101] jffs2_build_filesystem(): erasing all blocks after the end marker... [ 189.309087] jffs2: notice: (1645) jffs2_build_xattr_subsystem: complete building xattr subsystem, 0 of xdatum (0 unchecked, 0 orphan). [ 191.353679] overlayfs: upper fs does not support tmpfile.
After this df -Tm should display this:
Filesystem Type 1M-blocks Used Available Use% Mounted on /dev/root squashfs 4 4 0 100% /rom tmpfs tmpfs 60 0 60 0% /tmp tmpfs tmpfs 60 0 60 0% /tmp/root tmpfs tmpfs 1 0 1 0% /dev /dev/mtdblock4 jffs2 25 1 24 4% /overlay overlayfs:/overlay overlay 25 1 24 4% /
Quick Install of Hard Disk Boot partition with Busybox or OpenWRT
It is possible to prepare a SATA hard disk and use that to boot OpenWRT and set the device up as a router and NAS without any soldering or other trickery. All you need to know is how to use OpenWRT.
- Put a SATA disk in a cradle to prepare it, any size works, if some filesystems get automounted under /run/media/... or so, unmount them.
- dd if=/dev/zero of=/dev/sdN bs=1M count=10 - use applicable device, this blanks the partition table
- Create a single partition, here is my procedure:
fdisk /dev/sdN
[n p 1 ENTER ENTER w] - mkfs.ext4 /dev/sdN1
- mkdir /mnt/rootfs
- mount /dev/sdN1 /mnt/rootfs
- cd /mnt/rootfs
- For Busybox:
wget https://dflund.se/~triad/krad/gemini/rootfs-gemini.cpio
cpio -d -i -F rootfs-gemini.cpio - For OpenWRT:
wget https://dflund.se/~triad/krad/dlink-dir-685/openwrt-gemini-device-dlink-dir-685-rootfs.tar.gz
tar xvf openwrt-gemini-device-dlink-dir-685-rootfs.tar.gz
This obviously uses my pre-brewn image. - umount /mnt/rootfs
- Remove harddisk from cradle, insert into the DIR-685, boot a kernel using the serial console as described below. Currently you MUST have a console to interact with the system. The flashing heartbeat LED (WPS LED) should come up so you see the kernel is alive.
Booting a kernel
- The default image will drop you to a prompt so you can look around inside the D-Link firmware. It is not very bad, it is using Busybox v1.0 and the v2.
- At boot after turning on the power switch (on the cord), press CTRL+C and you
will be dropped into the boot loader which is called "Boot Menu"
and which seems to be a variant of the RedBoot boot loader. It looks like
this:
Boot Menu ============================================================================== 0: Reboot 1: Start the Kernel Code 5: Enter Command Line Interface 6: Set IP Address 7: Set MAC Address 8: Show Configuration X: Upgrade Boot Y: Upgrade Kernel Z: Upgrade Firmware A: Upgrade Application R: Upgrade RAM Disk - Typing 5 takes you to a command line interface where it is possible to load a kernel over Xmodem
- Load the kernel with Xmodem to 0x400000 (use minicom's CTRL+A then S) and execute it with:
sl-boot> load -m xmodem -b 0x400000 sl-boot> go 0x400000 - Obviously you should select the zImage and upload it using the xmodem protocol. With minicom this is done with CTRL+s then browse and push space over the zImage and ENTER.
- If you instead set up a TFTP server
(which I recommend, because it is faster) you need to set up the IP address
in the boot menu using alternative 6 to be 169.254.1.2, plug the ethernet crossed
cable into one of the LAN ports (not the WAN port! the bootloader does not support
configuring the WAN port properly!) and then you can use:
sl-boot> load -m tftp -b 0x400000 TFTP Server IP Address: 169.254.1.1 Image Path and name(e.g. /images/zImage): zImage TFTP Download zImage from 169.254.1.1 ....................................... Successful to download by TFTP! Size=4646107 sl-boot> go 0x400000
Compiling the kernel
To compile the kernel you first need a ARMv4 toolchain to build it with, then you need to configure and compile the kernel, and possibly also attach an initramfs.
I use a special gemini.mak makefile that I put in the root of the kernel directory, edit the makefile to select the right DTB then I type:
make -f gemini.mak config && make -f gemini.mak buildAnd this will build the whole kernel, attaching an initramfs and a DTB file, and put the resulting zImage in $HOME as well as in /var/lib/tftpboot if it is writeable. You will need the rootfs-gemini.cpio rootfs for this to succeed.
Pre-built kernel images
These can be downloaded and booted using the method described above.
- zImage v5.8 v4.19-rc1 using an external rootfs on the harddisk (sda1), only 4 patches for the RTL8366RB on top of the vanilla v5.8 kernel. Network switch should work fine.
- zImage v4.19-rc1 v4.19-rc1 using an external rootfs on the harddisk (sda1), I prefer openwrt. All hardware except USB and the funky wireless card is working.
- zImage v4.18-rc1 patched v4.18-rc1 using an external rootfs on the harddisk, I prefer openwrt. This has working RTL8366RB ethernet routing, you might need to issue ifconfig lan0 up after booting into OpenWRT.
- zImage v4.17-rc1 plain v4.17-rc1 using an external rootfs on the harddisk, I prefer openwrt.
- zImage v4.16 plain v4.16 using an external rootfs on the harddisk, I prefer openwrt.
- zImage v4.16-rc1 a plain v4.16-rc1 with some patches giving graphics and a busybox rootfs with initramfs
- zImage v4.14-rc1 a plain v4.14-rc1 with some patches giving graphics and a busybox rootfs with initramfs
Analyzing the vendor code
This bootlog from the unmodified firmware shows some kernel init and flash partitioning etc. A modified busybox binary was needed to get the dmesg out. It shows us that the kernel shipping in my router was compiled on march 25, 2010.
The vendor tree has a custom GPIO userspace access driver in boards/wrgns01/apps/nas_gpio_access/nas_gpio_access.c exposing GPIO in /proc/nas_gpio/gpio looking like this:
# cd nas_gpio/ # ls gpio # cd gpio/ # ls outen_pa_7 outen_pa_14 outen_pb_7 outen_pb_14 data_pa_13 data_pa_11 outen_pa_8 outen_pa_16 outen_pb_8 outen_pb_16 data_pb_6 data_pa_12 outen_pa_11 outen_pa_18 outen_pb_11 outen_pb_18 data_pa_7 outen_pa_12 outen_pa_6 outen_pb_12 outen_pb_6 data_pa_8
Inspecting the driver we see that for ports A and B it creates all the same output enable and data input/output files. So this means GPIO lines 6, 7, 8, 11, 12, 13, 14, 16, 18 are used on either port A or port B, and line 13 is only used as input.
There is further a userspace program for GPIO and LED control in boards/wrgns01/apps/fresetd.c where the use of different lines can be deduced. This illustrates that the blue and orange HD LEDs cannot be on at the same time.
After reverse-engineering the following is deducted:
- A7 controls the WPS LED
- A8 is input for the RESET button on the back
- A11 controls the blue HD LED
- A12 controls the orange HD LED
- A14 controls RTL8366RB RESET
- A15 is input for the RTL8366RB link ready IRQ
- A13 is input for the UNMOUNT button on the side
- A16 controls the backlight
- A/B 18 ?
- A21 is RTL8366RB MDC
- A22 is RTL8366RB MDIO
- B6 controls the fan
18 is still unknown, we don't know which port it is used on or for what.
Some were found inspecting the vendor code that contains boards/wrgns01/apps/rtl8366/rtl8366rb a kernel module for controlling a RealTek RTL8366RB switch using GPIO.
A compiled kernel module named switch.ko is in the directory and disassebling it hints that it is doing control of the switch over GPIO in response to custom ioctl() calls from userspace. armv4l-objdump -d switch.ko |less yields things like this:
00000ad0 <_smi_start>:
ad0: e1a0c00d mov ip, sp
ad4: e92dd800 push {fp, ip, lr, pc}
ad8: e24cb004 sub fp, ip, #4 ; 0x4
adc: e3a01001 mov r1, #1 ; 0x1
ae0: e3a00016 mov r0, #22 ; 0x16
ae4: ebfffffe bl 934
ae8: e3a01001 mov r1, #1 ; 0x1
aec: e3a00015 mov r0, #21 ; 0x15
af0: ebfffffe bl 934
af4: e3a00015 mov r0, #21 ; 0x15
af8: e3a01000 mov r1, #0 ; 0x0
afc: ebfffffe bl a40
b00: e3a00016 mov r0, #22 ; 0x16
b04: e3a01001 mov r1, #1 ; 0x1
b08: ebfffffe bl a40
(...)
It includes some kind of interrupt handler named linkInterruptHandle, setting link status, gpio_set_dir_bit, gpio_read_bit, gpio_write_bit, rtl8366rb_setEthernetPHY etc. 0x16 is passed to gpio_read_bit and 0x15 and 0x16 is passed to gpio_write_bit, so it is reasonable to assume that GPIOs 0x15 (21) and 0x16 (22) are used for controlling MDC and MDIO for the RTL8366RB SMI interface.
SMI is not MDIO. It is not following the standard anything else than electrically, sadly. So it needs a separate implementation.
We find the RESET GPIO line and the interrupt line the same way. This is not very nice kernel design since the GPIO registers are mapped directly into this driver creating races etc.
In the vendor kernel tree there is some sort of driver in driver/net/sl351x_gmac.8366rb.c
The DD-WRT people have a driver dump here specifically for the 8366RB here.
RT2880F-based PCIe card
I also looked at the Ralink RT2880F mini PCI card. The source dump contains a binary kernel module rt2880_iNIC.ko but it does not contain the source code. iNIC spells out "intelligent network interface card", I guess the lowercase i is a tribute too all Apple stuff named like that or something. It has a curious Makefile in dir685.gpl.source.new0611/dir685/progs.priv/ralink_RT2880_iNIC/v1.1.8.3/build/module-v1.1.8.3 that indicates codenames for all projects Ralink have delivered this PCI card to:
#PLATFORM = PC #PLATFORM = RT2880 #PLATFORM = TWINPASS #PLATFORM = 5VT PLATFORM = STORLINK #PLATFORM = STAR #PLATFORM = VITESSE #PLATFORM = RDC #PLATFORM = SIGMA #PLATFORM = BRCM #PLATFORM = IKANOS_VX160 #PLATFORM = IKANOS_VX180 #PLATFORM = PIKA #PLATFORM = MNDSPEED #PLATFORM = MNDSPEED2
This PCIe card looks like so in lspci:
00:0c.0 Class 0200: 1814:0801
The card also appears in Asus DSL-N13, Asus WL-127n, Alcatel Lucent Cellpipe 7130, Pegatron WL227N-5G Wireless Card, and the Billion BiPAC 7800N. I checked the source code for that device as well. It also just has a binary module.
The DD-WRT source tree contains a Makefile in drivers/net/wireless/Makefile that references:
#obj-$(CONFIG_RT2880v2_INIC_MII) += iNIC/mii/ #obj-$(CONFIG_RT2880v2_INIC_PCI) += iNIC/pci/
In some referenced linux-ramips_mt7620a/linux-3.10.17 the config symbol CONFIG_RT305x_INIC_MII is used to build this driver, maybe some MT7620 or RT5350 source tree accidentally contains this driver?
dir685.gpl.source.new0611/dir685/progs.priv/ralink_RT2880_iNIC/v1.1.8.3/build/module-v1.1.8.3.tmp_versions/rt2880_iNIC.mod reveals that we are looking for this source code set:
comm/rt_profile.c comm/raconfig.c comm/iwhandler.c comm/ioctl.c comm/iwreq_stub.c comm/mbss.c comm/wds.c comm/apcli.c comm/crc32.c pci/rt_pci_dev.c rt2880_iNIC.mod.c
BINGO! there is the sourcecode in the middel of Canal+ r7oss project with open source code for the Canal+ Set Top Boxes. Thank you Canal+! Also an subset of it called ralink inic can be found in use by Vitalii Kovzik apparently working on the same thing.
Kernel TODO
Create a device tree for this platform (patch merged for v4.14)Create a driver for the Realtek RTL8366RB using the SMI interfaceFigure out if the chip is connected using plain MDIO or I2C (conclusion: it uses SMI which is neither, it used MDIO electrical levels and its own protocol)Augment the Realtek PHY driver to handle the RTL8366RB bridged PHY (patch merged for v4.19)Create device tree bindings for the Realtek RTL8366RB DSA switch chip (patch merged for v4.19)Create a driver for the Realtek RTL8366RB DSA switch chip (patch merged for v4.19)Augment the DIR-685 device tree to activate ethernet and RTL8366RB DSA switch (patch merged for v4.19)Make the WAN port (port 4) work properly (patch exists)Figure out how DSA tagging should work with RTL8366RB and implement that in the net/dsa DSA tagging formats. (first patchset, last patchset)- Figure out TX offloading FDB and other characteristics of the RTL8366RB in accordance with this post from Vladimir Oltean.
- Figure out proper FID usage in accordance with this post from Vladimir Oltean.
Create a pin control flash add-on so we can multiplex NOR flash and GPIO access for the display that uses GPIO over re-used bit-banged flash CS pins.Support graphics on the small screenAdd a TVE200 DT binding and driver (Gemini-generic, patches merged for v4.15)Add a vendor prefix for Ilitek (patch)Add a device tree binding for the Ilitek ILI9322 panel (patch merged for v4.16)Create a driver for the Ilitek ILI9322 panel (patch merged for v4.16)Create device tree entries for the ILI9322 with TVE200 in the DIR-685 DTS (patch merged for v4.16)Activate the TVE200 and ILI9322 drivers in the Gemini defconfig (patch merged for v4.17)Figure out some way to make the screen blank automatically after a timeout I'm pretty sure Linux used to support this. Turns out to be simple: pass consoleblank=300 as parameter to the kernel.
Create a driver for the touchpad. There is a driver in the vendor kernel in drivers/i2c_alpha that uses bit-banged GPIO to emulate I2C on pins 5 (SDA) and 6 (SCL) and an interrupt on GPIO 17. It then provides ioctl()s to userspace.Add device tree bindings for the touchpad (patch, merged for v4.13)Add an input driver for the touchpad (patch, merged for v4.13)Add the bit-banged GPIO and the touchpad to the device tree (patch merged for v4.14)Enable the bit-banged I2C GPIO driver in the Gemini defconfig (patch merged for v4.17)
Find a way for ATA drivers supporting S.M.A.R.T. temperature monitoring to be represented in the Linux kernel and mapped as a hwmon sensor so we can connect it back to a kernel thermal policy The vendor tree has a userspace driver in the code dump dir685.gpl.source.new0611/dir685/boards/wrgns01/apps/hdparm/smart_spindown.c that deals with this. It turns on the fan at 46 degrees and turns it off at 41 degrees (celsius). Since the device lacks a temperature sensor, this jacks into the hard disk SMART monitor, if and only if a hard disk is mounted. This functionality needs to be replicated so as to stop the router from overheating. The plan is to let the kernel thermal framework take care of this.Propose a patch to integrate ATA SMART temperature sensors into Linux hwmon subsystem (RFC patch, v2 patch, patch v3 from Guenter, merged for v5.6)Propose a generic DT binding for ATA drives as subnodes of ATA hosts (merged for v5.6)Propose a piece of code that assigns the DT node to the SCSI device node that handled the temperature sensor (merged for v5.7)Add temperature zone to the Gemini DIR-685 device tree (patch merged for v5.7)Activate the hwmon disktemp driver in the Gemini defconfig- Enable the Alpha Networks WMP-N08 RT2880-based wireless mini-PCI card, this seems a bit tricky...
- Asked for help on the linux-wireless mailing list
- Located a piece of source code for it.
- Set the CMA limit to 10% in the gemini_defconfig (really?)
OpenWRT TODO
Kernel v6.6:Bump the kernel patches to v6.6Create a kernel config to v6.6Switch to kernel v6.6
Kernel v6.1:Bump the kernel patches to v6.1Create a kernel config to v6.1Backport the FOTG210 patches from v6.2Switch to kernel v6.1
Kernel v5.15:Bump the kernel patches to v5.15Create a kernel config to v5.15Backport the RTL8366RB patches from v5.16Switch to kernel v5.15
Kernel v5.10:Bump the kernel patches to v5.10Create a kernel config to v5.10Switch to kernel v5.10
Kernel v5.4:Bump the kernel patches to v5.4Create a kernel config to v5.4Switch to kernel v5.4
Kernel v4.19:Bump the kernel patches to v4.19Bump the kernel config to v4.19Switch to kernel v4.19
Default-enable the tools needed for a DSA switch. I currenly manually enable:
Network/Routing and redirection: ip-bridgeImage generation: generate a kernel image that is suitable for deploying into the internal flash (patch merged, uses WRGG firmware format, need testing and the flash access patches to work properly).Sysupgrade: the problem with the flash memory is that you cannot communicate with the display if you activate the flash memory. SOLVED. What we need to do is figure out where in flash to put the kernel and rootfs.Proper sysupgrade script support.Initscript to bring up the ethernet and all DSA ports. This will start working properly out-of-the-box once the DSA tagging on the switch works somewhat.Initscript to wind down the harddisk when unused to save power (patch exist).Initscript to display the OpenWRT banner on the framebuffer console (patch exist).
Testing ethernet with the DSA switch
Recent versions of OpenWRT and the Linux kernel v5.10 should bring up the DSA switch and interfaces lan0, lan1, lan2, lan3 and wan automatically. You should be able to do things like ping on each lan0, lan1 (etc) port and see packets coming out/in on that very port.
The manual way to test an ethernet connected through a DSA switch is kind of idiomatic and involves bringing the CPU-facing eth0 and the lan0 switch port independently:
ifconfig eth0 169.254.1.2 netmask 255.255.255.0 up ifconfig lan0 up ifconfig lan1 up ifconfig lan2 up ifconfig lan3 up ifconfig wan up
Configuring a static IP in OpenWRT will handle the first automatically, the 5 other ports need to be set up manually for now.
Getting RT2880 wireless going
Because of missing driver support this device does not work yet.