mediatek: Add support for D-Link EAGLE PRO AI R32

[RolandoMagico]

R32 is like the M32 part of the EAGLE PRO AI series from D-Link.

Specification:

• MT7622BV SoC with 2.4GHz wifi
• MT7975AN + MT7915AN for 5GHz
• MT7531BE Switch
• 512MB RAM
• 128 MB flash
• 2 LEDs (Status and Internet, both can be either orange or white)
• 2 buttons (WPS and Reset)

Compared to M32, the R32 has the following differences:

• 4 LAN ports instead of 2
• The recory image starts with DLK6E6015001 instaed of DLK6E6010001
• Individual LEDs for power and internet
• MAC address is stored at another offset in the ODM partition

MAC addresses:

• WAN MAC is stored in partition "Odm" at offset 0x81
• LAN (as printed on the device) is WAN MAC + 1
• WLAN MAC (2.4 GHz) is WAN MAC + 2
• WLAN MAC (5GHz) is WAN MAC + 3

Flashing via Recovery Web Interface:

• Set your IP address to 192.168.0.10, subnetmask 255.255.255.0
• Press the reset button while powering on the deivce
• Keep the reset button pressed until the internet LED blinks fast
• Open a Chromium based and goto http://192.168.0.1
• Download openwrt-mediatek-mt7622-dlink_eagle-pro-ai-r32-a1-squashfs-recovery.bin

Flashing via uBoot:

• Open the case, connect to the UART console
• Set your IP address to 10.10.10.3, subnet mask 255.255.255.0. Connect to one of the LAN interfaces of the router
• Run a tftp server which provides openwrt-mediatek-mt7622-dlink_eagle-pro-ai-r32-initramfs-kernel.bin.
• You can rename the file to iverson_uImage (no extension), then you don't have to enter the whole file name in uboot later.
• Power on the device and select "1. System Load Linux to SDRAM via TFTP." in the boot menu
• Enter image file, tftp server IP and device IP (if they differ from the default).
• TFTP download to RAM will start. After a few seconds OpenWrt initramfs should start
• The initramfs is accessible via 192.168.1.1, change your IP address accordingly (or use multiple IP addresses on your interface)
• Create a backup of the Kernel1 partition, this file is required if a revert to stock should be done later
• Perform a sysupgrade using openwrt-mediatek-mt7622-dlink_eagle-pro-ai-r32-squashfs-sysupgrade.bin
• Reboot the device. OpenWrt should start from flash now

Revert back to stock using the Recovery Web Interface:

• Set your IP address to 192.168.0.10, subnetmask 255.255.255.0
• Press the reset button while powering on the deivce
• Keep the reset button pressed until the internet LED blinks fast
• Open a Chromium based and goto http://192.168.0.1
• Flash a decrypted firmware image from D-Link. Decrypting an firmware image is described below.

Decrypting a D-Link firmware image:

• Download https://github.com/RolandoMagico/firmware-utils/blob/M32/src/m32-firmware-util.c
• Compile a binary from the downloaded file, e.g. gcc m32-firmware-util.c -lcrypto -o m32-firmware-util
• Run ./m32-firmware-util R32 --DecryptFactoryImage
• Example for firmware R32A1_FW103B01: ./m32-firmware-util R32 --DecryptFactoryImage R32A1_FW103B01.bin R32A1_FW103B01.decrypted.bin

Revert back to stock using uBoot:

• Open the case, connect to the UART console
• Set your IP address to 10.10.10.3, subnet mask 255.255.255.0. Connect to one of the LAN interfaces of the router
• Run a tftp server which provides the previously created backup of the Kernel1 partition.
• You can rename the file to iverson_uImage (no extension), then you don't have to enter the whole file name in uboot later.
• Power on the device and select "2. System Load Linux Kernel then write to Flash via TFTP." in the boot menu
• Enter image file, tftp server IP and device IP (if they differ from the default).
• TFTP download to FLASH will start. After a few seconds the stock firmware should start again

There is also an image openwrt-mediatek-mt7622-dlink_eagle-pro-ai-r32-a1-squashfs-tftp.bin which can directly be flashed via U-Boot and TFTP. It can be used if no backup of the Kernel1 partition is reuqired.

Flahsing via OEM web interface is currently not possible, the OEM images are encrypted. Creating images is only possible manually at the moment.
The support for the M32/R32 already includes support for flashing from the OEM web interface:

• The device tree contains both partitions (Kernel1 and Kernel2) with conditions to select the correct one based on the kernel command line
• The U-Boot variable "boot_part" is set accordingly during startup to finish the partition swap after flashing from the OEM web interface
• OpenWrt sysupgrade flashing always uses the partition where it was initially flashed to (no partition swap)

[RolandoMagico]

I updated to the lastest main which includes setting the MACs in the device tree instead of using the following files:

• /etc/board.d/02_network
• /etc/hotplug.d/iee80211/11_fix_wifi_mac

Looks like incrementing the MAC adresses within nvmem-cells = <macaddr_odm, x> doesn't work so the device tree still contains mac-address-increment = <x>.

@neheb, @Ansuel : Any idea how to fix this?

[neheb]

I see no diff.

[RolandoMagico]

I see no diff.

This are the changes for wifi: https://github.com/openwrt/openwrt/compare/2ac58a7e5511405826149271aefc46167798353f..6c43b07e35de36962befded713bf8646ab7d523f

The wifi mac adresses (macaddr_odm + 2 and macaddr_odm +3) are only working if mac-address-increment is present, otherwise the value in macaddr_odm is used without adding a value.

I tried to do it in the same way it was done in 3eb899f, but I don't understand how it works there without using mac-address-increment

[neheb]

I believe it doesn’t work for UBI yet. In my conversions, I’ve avoided touching user space MAC stuff.

[neheb]

@RolandoMagico btw macaddr_odm needs to use mac-base.

edit: you also need

#nvmem-cells = <1>;

see my mac-base commits.

[RolandoMagico]

Thanks @neheb, now it's working as expected. The MAC addresses are set correctly without having to use mac-address-increment anymore.
Regarding mac-base: Do you mean compatible = "mac-base";? If yes: This is already present in the device specific DTS files (I had to put it there because the MAC adress is stored at different offsets for M32 and R32).

[raenye]

May I also nag about LEDs? (color and function properties instead of label, node names led-xxx)

[RolandoMagico]

May I also nag about LEDs? (color and function properties instead of label, node names led-xxx)

Sure, do you have a recommendation?

[raenye]

See, e.g., e29f4a3.

[RolandoMagico]

See, e.g., e29f4a3.

Do I have to know anything special about the changed LED configuration? Currently it looks like the LEDs change their behavior: The usual red/orange blinking during boot and firmware upgrade is missing and the white power LED isn't on after boot.

As soon as I assign labels to the led entries in the DTS, the usual behavior is back.

[raenye]

Until #13837 is merged, LEDs referenced in aliases need to have a label.
(I cherry picked this for my local tree).

[RolandoMagico]

Until #13837 is merged, LEDs referenced in aliases need to have a label. (I cherry picked this for my local tree).

Understood. Can cherry-picking be modelled in a pull request? If not: I subscribed to #13837, so I'll do the remaining changes as soon as it is merged.

[raenye]

Understood. Can cherry-picking be modelled in a pull request?

AFAIK no. In my local git tree I have per-PR branches, which only have the commits I want to push, and a mybuild branch which has everything including some not yet merged commits from PRs I like.

[raenye]

I'll do the remaining changes as soon as it is merged.

It has just been merged :)

[RolandoMagico]

I'll do the remaining changes as soon as it is merged.

It has just been merged :)

Done

[s-2]

rebuilt from your branch, sysupgraded my device (settings erased) from whatever was running on it before... needed a power cycle before ethernet would work, not sure if this is intended (due to bootloader or something? WAN LED was glowing both white and orange).
After power cycle, both wifi interfaces needed to be enabled before scan was possible, but I think we've had that before.
Otherwise, everything is working fine, thanks for the PR 🙂

[RolandoMagico]

both wifi interfaces needed to be enabled before scan was possible, but I think we've had that before.

I saw the issue also on other devices and opened #14207

[RolandoMagico]

Is there anything to do from my side to get the PR accepted? Or do I just have to wait for the required approval?

[neheb]

wait unfortunately.

[neheb]

ping @dangowrt

[dangowrt]

No tftp.bin for the r32 like we got for the m32?

I kinda find the recovery.bin naming inconsistent with the existing use of that image name suffix (which hints that the file is used as recovery image rather than to be flashed by a vendor's recovery system), but that already happened now...

[RolandoMagico]

The tftp image is created for both devices. It's defined in Device/dlink_eagle-pro-ai-ax3200-a1 and used by Device/dlink_eagle-pro-ai-m32-a1 and Device/dlink_eagle-pro-ai-r32-a1.
Any suggestions for the naming of the recovery image? I took over the naming from D-Link DAP-X1860.

[raenye]

Wouldn't initramfs.bin be considered the recovery for OpenWrt?
AFAIK recovery.bin is for vendor uboot recovery in several devices already.

[RolandoMagico]

Currently I have a initramfs-kernel.bin which can be loaded to RAM via U-Boot and a squashfs-recovery.bin which can be downloaded via the recovery web interface from D-Link (a part of U-Boot). Additionally there is a squashfs-tftp.bin which can be flashed to the external flash directly via U-Boot TFTP.

[RolandoMagico]

needed a power cycle before ethernet would work, not sure if this is intended (due to bootloader or something? WAN LED was glowing both white and orange).

I cannot reproduce it with latest main. If you want to retry it, that's the version I used:
https://github.com/RolandoMagico/openwrt-build/releases/tag/EAGLE_PRO_AI_R32_Build_20231218

Edit: just saw that there are reports of reset/boot problems in a similar device:
https://forum.openwrt.org/t/belkin-rt3200-linksys-e8450-wifi-ax-discussion

[RolandoMagico]

I updated the recovery image creation because during porting the M30, it turned out that there is another checksum in the header of the recovery image. It's currently not used by the recovery web interface of M32/R32, but if it would be considered in newer devices, it would work as well.