Add support for D-Link M30 (AQUILA PRO AI AX3000 Smart Mesh Router)

Thanks, in the Release Notes it states:

Disable FW manual version downgrade

Do we have to update some version number in the factory image header here? Maybe use some very high number to be future-proof, if people one day want to update their devices from a later OEM version.
// edit: wait, it also states Add FW AES-128 Encryption so this is already the version we have here?

Dual images are indeed annoying, not sure how to proceed from here with ubi0 vs ubi1 :thinking:

1 Like

@Pondera : Thanks for the information

I have to check if this is affected. But as long as there is no solution for the dual partition boot, factory images don't make sense in my opinion.

I was able do decrypt the image with the current version of dlink-ai-firmware-tool without changing anything, not sure what they mean until now. Also flashing the decrypted image from the recovery web interface works as usual.
The problem I currently have is that I cannot flash OpenWrt recovery images anymore. I have to ivestigate if I bricked my router with the OEM web interface flash tests or if the update changed something in the bootloader which causes the problem.

1 Like

How far does it get, is an image flashed but not booting, or is the flashing no longer working? (any Linux updates in the meantime? maybe try the script from the COVR-P2500 wiki page for uploading).
I wouldn't believe they updated the bootloader, but maybe some environment variables :thinking:

I had to adapt the DTS, initially there were two partitions ubi and ubi1. OpenWrt was running in ubi until now.
But with my device, the recovery web interface loaded OpenWrt in ubi1 all the time. So I had so rename ubi to ubi_bak and ubi1 to ubi. Now OpenWrt is up and running again.
Similar to the issue with dual boot and the factory images. So I have to search for a way to select the correct UBI partition during startup :frowning:
Maybe that can be done somehow in target/linux/mediatek/filogic/base-files/lib/preinit/75_rootfs_prepare, similar to creating the rootfs_data partitions during first boot. But never did it before...

Some background to the boot procedure of the device:

  • There are two partitions in the OEM firmware:

    • mtd5 is "ubi" (different name in U-Boot: "mtd6")
    • mtd6 is "ubi1" (different name in U-Boot: "mtd7")
  • There are three U-Boot environment variables involved:

    • bootpart (0: Boot from UBI0, 1: Boot from UBI1)
    • sw_active (1: Active SW in UBI0, 2: Active SW in UBI1)
    • sw_tryactive (0: Try to boot from UBI0, 1: Try to boot from UBI1: 2: normal boot based on variable bootpart)
  • U-Boot checks during boot if sw_tryactive == 2, in this case a "normal" boot is performed:

    • If bootpart == 0,set sw_active = 1 (if not alredy set). Set bootpart = 0, boot from UBI0
    • If bootpart != 0, set sw_active = 2 (if not already set). Set bootpart = 1, boot from UBI1
  • If sw_tryacitve != 2, try the new firmware:

    • If sw_tryactive == 0: set sw_tryactive = 2 and sw_active = 1, boot from UBI0
    • If sw_tryactive != 0: set sw_tryactive = 2 and sw_active = 2, boot from UBI1

If the software is running in mtd5, the following variables are set:

  • cat /proc/cmdline contains bootpart=ubi0
  • U-Boot variable: sw_active=1
  • U-Boot variable: sw_tryactive=2
  • U-Boot variable: bootpart=0
  • During flashing a new firmware via the OEM web interface, sw_tryactive is set to 1

If the software is running in mtd6, the following environment is set:

  • cat /proc/cmdline contains bootpart=ubi1
  • U-Boot variable: sw_active=2
  • U-Boot variable: sw_tryactive=2
  • U-Boot variable: bootpart=1
  • During flashing a new firmware via the OEM web interface, sw_tryactive is set to 0

So OpenWrt has to set bootpart after flashing:

  • If cat /proc/cmdline contains bootpart=ubi0 and bootpart==1, bootpart must be set to 0
  • If cat /proc/cmdline contains bootpart=ubi1 and bootpart==0, bootpart must be set to 1
1 Like

The problem is that the U-Boot recovery web interface always flashes to the active partition. Current workaround:

  • General information: The recovery web interface is started if the reset button is pressed while powering on the device. Keep the button pressed until the LED blinks red. Now the recovery web interface is accessible via http://192.168.200.1
  • Ensure that you have an OEM image available (encrypted an decrypted version)
  • Flash OpenWrt via recovery web interface
    • If OpenWrt was flashed to the first partition, it will boot after startup and is accessible via 192.168.1.1
    • If OpenWrt was flash to the second partition, it will not boot and there won't be any watchdog reset or failsafe mode.
      • In this case, perform the following steps:
        • Start the web recovery interface again and flash the decrypted OEM image. This will be flashed to the second partition as well. The OEM firmware web interface is afterwards accessible via http://192.168.200.1.
        • Now flash the encrypted OEM image via OEM firmware web interface. In this case, the new firmware is flashed to the first partition. After flashing and the following reboot, the OEM firmware web interface should still be accessible via http://192.168.200.1.
        • Start the web recovery interface again and flash the OpenWrt recovery image. Now it will be flashed to the first partition, OpenWrt will boot correctly afterwards and is accessible via 192.168.1.1.
1 Like

There is also an open PR which addresses the dual boot issue: https://github.com/openwrt/openwrt/pull/10674

Maybe this would help not requiring the workaround anymore