Aquila S2 Firmware

[Adele Strecker]

Thesame model of the Aquila 3d printer came with a different motherboard chip. For example, the Voxelab Aquila X2 could have the H32 or N32 chip. And in some rare cases of early X2 printers the G32 chip. Instead, the first model (Voxelab Aquila) could have a G32, N32 or H32 chip. If you want to be 100% sure you could read the text on the black motherboard chip(read the NOTE for more). You need to find out what model you have on your machine.

Now that you know what chip model you have, you need to download the printer and display firmware based on your 3d printer setup and preferences (The display firmware is the same for all the 3d printer chip models). Now fisrt follow the steps for the display firmware because it is the same for all chip models, and than follow the printer firmware steps based on your printer chip model.

Download the display firmware zip file from this github repository direct download link, extract it on the desktop of your computer. Than you need to open it, and go in the Display firmware -> Firmware Sets folder, go and copy the DWIN_SET (Voxelab Red) folder on the desktop. Rename it DWIN_SET. Later, this folder will be put on the SD card to flash the display firmware.

WARN: It is recommended to perform the following steps a Windows or Linux, because Macs leave hidden files on the SDcard that will prevent the firmware from installing, more likely with the display firmware (More in info could be found here).Also large capacity SDcards can cause problems so i suggest to avoid any other one with a greater size fomr the factory one that is 8GB.

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?

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.

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.

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

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

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...

E30 looks interesting indeed, the 180 days short term confidentiality for the FCC filings for KA2E30A1 is over since 2024-04-25, so we can finally see internal photos (only on the FCC website for now, fccid.io is not yet updated).

Although the case design looks similar to DAP-X1860 (by Acelink/Edimax), it was to be expected this device is completely different. Only MT7976CN can be seen in the pictures, not sure what the other chip is (one of them might be RAM?). Or are they really using a wireless SoC as a peripheral here to a main MCU? But it's probably just RAM and eMMC.

Well, probably there is a switch indeed, as the Ethernet lines definitely go to the unknown chip in the picture, so it might as well be a switch then Makes no sense with one port of course, but then again that was probably the working software package they had, so...

Do you mean page 3?

As far as I understood, in the bottom, there is the MT7976CN for wireless, above would be MT7981 and RAM/FLASH, similar to what we have in the M30 shown here Add support for D-Link M30 (AQUILA PRO AI AX3000 Smart Mesh Router) - #10 by frollic.

I think for the M30, the switch is the chip covered with the gray pad. I don't see something similar in the E30.

And at page 2 of the PDF, I assume the chip on the left side is the LED controller.

Could you check if meta-myproject/recipes-dlink/fota/files/ contains anything interesting (at least for M32 this was the folder), technically they should at least have their firmware updated on the FOTA servers if not on TSD (although most D-Link devices would successfully display "you already have the latest firmware" when there is not even connectivity to check for updates in the first place, so they're probably not in a rush to supply firmware there either before shipping a new model).

Indeed, the full URL is not part of the FOTA software package. I looked at the fota binary in ghidra, there is a function get_fota_url (at 0x001063b0) that calls read_csman, i.e. it would read stuff from the odm partition.

The string behind the ODM key 0x8015003b contains Default for e.g. my dump of E32, the E30 FOTA compares this to be either CN or not, then uses different hostnames to compose the URL (either api.fota.dlink.com or prepended with cn), the rest of the URL is taken from ODM key 0x801501e0, which is not even in the M32 dump (would have to check others though).

Some more investigation required to support the new firmware encryption.

Update: Also looks like the firmware crypto for M30 was changed. I cannot decrypt the images anymore. Tried my firmware utility and the scripts from D-Link in the GPL package, same result.

are they actually updating the bootloader, or could we technically flash an old (decrypted) OEM version via recovery and then upgrade to newer OEM?

The user would need to know about the decrypted OEM images of course.

Maybe we were too quick this time, supporting devices in OpenWrt that are still actively supported by the ODM, so they can force them to change firmware encryption once again (However, it's also still on my bucket list to see some OEM, intentionally or accidentally, actually use the crypto code from OpenWrt for their devices when they release new versions or new devices from the same family )

// edit: the only relevant publication I found from D-Link was on the Realtek devices from this series, also made by AMIT and apparently sharing lots of higher level software. Maybe they reproduced this also with the MediaTek models?

=SAP10394

So I downloaded M32A1_FW110B02_revise from that support page, could not decrypt it manually using the IV from the header (I think it's called revise for this device since there was a previous release called "HOTFIX" for M32 already; in any case it also contains the same release notes document as the others).

But factory for the new AES key is probably not happening since we'd also need the RSA key for signing, and the initial attept of flashing revise over the very old one failed due to signature 2 mismatch already (printed to serial console), so they also changed that one, but now probably learned not to publish it anymore

// edit: ok this was just the change within the "old" format, but E30 indeed uses something different, not the MH01 amit-split encapsulation, but just the DLK6E header. So the first part is 0x200 in size, maybe the signture? and the rest is a high-entropy file, so maybe they use constant IV for those devices and something yet different?

There is also E30A1_FW110B02 on the TSD website, which is not identical to the hotfix variant, but same format. So the hotfix change might be somewhat unrelated to the format change? Or maybe they just didn't feel like changing the new E30 format was necessary yet...

We believe in the power of teamwork and collaboration. We are a dynamic and supportive team of Eagles sharing a passion for pushing the boundaries of what is possible. We're looking for exceptional people driven to power the future by solving first-class problems with world-class engineering, and everyone owns their work end-to-end. No need to deal with crazy legacy spaghetti where you have no idea why things were done "how they've always been done".

First, implementing a fast and performant control suite for the targeting system. With support from the team in delivering a light-speed optical targeting signal, the role involves interfacing, controlling, and actuating the real-time fine steering system to target a drone at 1km.

Second, programming the receiver firmware systems to communicate with the ground (sunflower) and roughly aim the drone-mounted gimbal (suncave) to the ground laser turret (sunflower). Utilising off-the-shelf RTK and radio solutions and modified off-the-shelf gimbal solutions to optimise development time. This role involves reliably transmitting critical data to the ground via radio.

The role spans all design aspects, from requirements definition through learning, design, implementation, and automated testing of PCB (or FPGA if required) boards and their firmware routines and implementing cutting-edge control algorithms in performant low-level software.

A proven ability to produce complex firmware for embedded, including debugging and testing, with or without an RTOS leveraging demonstrated proficiency in low-level STM32 programming and encompassing expertise in bare-metal coding.

3a8082e126