Great to see the v23.05 backport for this device was merged a couple days ago, I'm currently testing on gluon and it's working fine so far 
The device is also available for around ~80 EUR at the moment:
https://www.x-kom.de/m30-aquila-pro-ai-3000mb-s-a-b-g-n-ac-ax
Hi @s_2 ,
really nice that you have this working.
On filogic devices, we always experience tq instability:
I did not find a way to track down that error.
Did you also experience such behavior on your device when meshing yet?
It's been running smoothly for the last couple hours since I installed my build (gluon master from yesterday evening). Is there anything that could help to trigger the behaviour, or should we just wait? There are few clients around here, but several mesh partners.
I had a look at the M30:
mtd write /tmp/OpenWrt.mtd6_Odm.bin /dev/mtd6I checked the new OEM images:
As switching the active partitions currently doesn't work anymore if an update to the latest OEM version was already done, I created an additional image:
This image supports booting from the second partition (and only from the second partition). Any sysupgrade in this image will write it to the first partition and change the boot settings to start from the first partition afterwards. This also means that both partitions will contain OpenWrt afterwards.
The flash procedure would be the following:
Meanwhile I had detached my gluon test device (needed the socket for something else), but it was running for two weeks uninterrupted and I could not reproduce any issue with gluon meshing (it did not have any ethernet cable connected, and there are several routers nearby).
Regarding the image for flashing from the second partition, I guess the only curious problem about this would be how to make the openwrt build system generate both images at once 
if the .dts is different, but the device name should not be (i.e. gluon autoupdate should fetch the regular sysupgrade for the "first" partition, so we don't have two different device models on the map based on which partition was used for flashing), that might still be a thing we could solve in gluon (modified autoupdate string + SUPPORTED_DEVICES), but it should preferably also work for upstream OpenWrt images... I have no idea how to achieve this with the build system (at least we have a DEVICE_DTS variable for this target, not sure how helpful it would be though).
I notice this device now has a stable image and an incomplete ToH entry.
Since it looks very very similar in hardware to the recently released OpenWRT One, I am seriously considing it.
I need something to replace a family member's ageing Asus RT-AC87U which currently runs the last release of Merlin (now EOL for that specific model). Flashing OpenWRT plus an external WiFi 6 AP (since the WiFi is Broadcom on the RT-AC87U and thus not supported on OpenWRT) has been considered but I think that's a bad idea (LAN1 on its own proprietary SOC!) and it's almost 10 years old now anyway...
Back to the M30 Aquila Pro. It seems to fit all the requirements for a replacement. A nice SOC, working WiFi, an all-in-one box I can drop in, and more storage space compared to other hardware with a Filogic 820 (like the Cudy WR3000 which has only 16MB; fine for an AP but I think a bit tight here). I also sort of like the form factor of the Aquila too.
The only trouble is, I can see this thread as a record of the bringup of OpenWRT on this device, but not many accounts of using it day-to-day as a router and AP (neither here, nor elsewhere). So I guess my main question is - is anyone using this as their main router/gateway/AP and are they happy/unhappy with it?
This sort of thing is a little concerning for example. The outgoing RT-AC87U may be old, but it has been rock solid, so looking for similar in the replacement...
Might add some more information.
This view also has a bit more info:
https://openwrt.org/toh/hwdata/d-link/d-link_aquila_pro_ai_m30
A couple days ago, I installed OpenWRT 24.10-rc2 on 2 M30 that I use as wireless APs in my house. I use them in conjunction with a MikroTik router. They have been working flawlessly so far. I am getting better speeds than with the official firmware.
Is there anything else that you would like to know?
For the record: about a month ago, I had flashed 23.05.5 and ran that for a week before returning to D-Link's official firmware. Everything seemed to work well except for my wife. At that time, she had frequent issues connecting to the wireless networks using her Windows laptop. All other devices (Android, Linux, various IoTs) had no issues. I believe that this might have been due to how I had (mis-)configured DAWN. I didn't have time to investigate more—my wife works from home often and needs reliable wifi—so I opted to simple revert back to the official firmware until I had more time. When I finally flashed OpenWRT again this week, I enabled roaming (802.11r), but didn't set up DAWN or anything else yet. My wife hasn't had any issue so far... 
Thank you @laurentlbm, this was exactly the type of testimonial I was looking for 
Update - I've ordered one...
Update 2 - this arrived today (15/12) and I am pretty impressed for the price (it was £40.99 new direct from Amazon UK).
Flashing was easy, I just followed the "Flashing via Recovery Web Interface" instructions from the git commit listed on the Techdata page. I was able to flash the standard 23.05.5 recovery image using the recovery web interface, and there was no need to use any special second partition image as per #45.
The WiFi performance and range packs a punch, and as with the similarly specced Cudy WR3000, I was able to get about 380Mbps in both directions for SQM using cake/piece_of_cake. I connected it behind my main gateway which has a 500/500 connection.
It's going back in the box now until the Christmas period when I am going to set it up in its final home - an asymmetric 250/25 DOCSIS cable connection. So it should have plenty in the tank for that and any future package/ISP changes in future.
Thanks for the help all. I will report back if I discover anything of interest once it has been in place for a while.
I started work on the M60:
LAN/WAN/Wifi, buttons, LEDs and flashing to partition 0 are working.
Recovery flashing is not yet working, needs some time to figure out how the image crypto is working.
Hello @RolandoMagico, @GreenSystemAdmin, and @laurentlbm, I have a few questions regarding the D-Link M30 that I hope you can help me with.
Thank you for your assistance! 
Hello @spike0en,
Some answers from my side:
As far as I know, there is currently only revision A1
No, unfortunately not. I currently would recommend using UART for loadting the initramfs, create a backup of UBI and UBI1 partitions and then perform sysupgrade via SSH/command line. D-Link changed the firmware crypto in the last firmware and there is no way to get back to OEM otherwise. Because of dual boot, initramfs is also recommended to set the U-Boot variables correctly.
Update: I found a way to decrypt also the new factory images (replacing the public key, firmware key and adjusting the signature length in the implementation of my tool seems to be sufficient).
Based on the hardware specs 512MB RAM and 128MB flash, it should be supported for a while. But I cannot provide a detailled estimation.
The OEM firmware version doesn't matter because it's not used for flashing. See my above comment about flashing.
I don't know
Sysupgrade will work as long as the partition scheme is unchanged. Until now, we don't have any changes in the memory layout so I cannot guess what is happening in future. From my point of view, changes in the flash layout are unlikely.
If you created a backup of the UBI partitions as mentioned above, you can use the OpenWrt initramfs to restore the backup to switch back to OEM.
Encrypted are the ones from D-Link, there are no decrypted images available in public. Due to the change of the image crypto, there are no decrypted images for the latest OEM firmware at all.
To sum it up: It's currently tricky to get OpenWrt initially running on the device, you should have some knowledge of the points I mentioined above.
Thanks for the response. I hope that the installation procedure becomes easier in future 
I think I implemented the U-Boot handling incorrectly on M30 (saw the issue while porting M60 to OpenWrt). Maybe someone with more U-Boot experience can have a look at it.
What I understood until now:
Before flashing, sw_tryactive must be set to 0 because OpenWrt runs on partition 0
During reset after flashing, U-Boot executes the following line:
boot_rd_auto_sw_img=if itest.s ${sw_tryactive} == 2; then run boot_by_part; else run boot_by_tryactive; fi
As sw_tryactive was set to 0 before flashing, boot_by_tryactive will be executed:
boot_by_tryactive=if itest.s ${sw_tryactive} == 0; then setenv sw_tryactive 2; setenv sw_active 1; saveenv; run ub0; else setenv sw_tryactive 2; setenv sw_active 2; saveenv; run ub1; fi
As sw_tryactive was set to 0 before flashing, sw_active will be set to 1 and ub0 will be executed:
ub0=setenv bootpart 0; mtkboardboot; run ub0to1; uip main; reset
If the OpenWrt boot is successful, ub0to1 and uip main will never be executed. Only in case OpenWrt cannot be loaded, mtkboardboot will return and the fallback ub0to1 is executed.
Conclusion: It's sufficient to set sw_tryacitve to 0 before flashing, the added code in target/linux/mediatek/filogic/base-files/etc/init.d/bootcount is useless.
In the worst case (/proc/cmdline doesn't contain bootpart=ubi0 as expected), the bootpart variable would be set to 1 and causes starting the firmware from the second partition instead of the one on the first partition.
PR:
Did some investigation regarding the recovery images for M60. Looks a little bit strange for me. I found several firmware images on the D-Link site:
I updated the wiki entry for this device:
https://openwrt.org/toh/d-link/aquila_pro_ai_m30_a1
It should contain now all required information for flashing OpenWrt and for reverting back to OEM.
@spike0en: FYI. If something is missing, feel free to contact me.