You have two options, I guess.
Either try to flash it directly, using option 2, or use option 1 to load the initramfs, then fash the sysupgrade image from the initramfs.
What one works ? No idea ...
Plus you also have the recovery you already posted about.
Thanks @frollic, I tried option 2 in uboot. Looks promising, the initramfs image is now started afer a reset without using TFTP.
Tried to flash the sysupgrade after booting, but it fails:
Fri Jul 7 18:15:30 UTC 2023 upgrade: Sending TERM to remaining processes ...
Fri Jul 7 18:15:30 UTC 2023 upgrade: Sending signal TERM to ntpd (2328)
Fri Jul 7 18:15:30 UTC 2023 upgrade: Sending signal TERM to ntpd (2331)
Fri Jul 7 18:15:34 UTC 2023 upgrade: Sending KILL to remaining processes ...
[ 92.403637] stage2 (3094): drop_caches: 3
Fri Jul 7 18:15:40 UTC 2023 upgrade: Switching to ramdisk...
Fri Jul 7 18:15:41 UTC 2023 upgrade: Performing system upgrade...
[ 93.310195] do_stage2 (3094): drop_caches: 3
Could not open mtd device: firmware
Can't open device for writing!
cat: write error: Broken pipe
sysupgrade aborted with return code: 256
Is it only because all my partitions are read-only (I'm using https://github.com/RolandoMagico/openwrt/blob/D-Link_EAGLE_PRO_AI_M32/target/linux/mediatek/dts/mt7622-dlink-eagle-pro-ai-m32.dts) or is there something else which can be wrong?
don't know much about the DTSes, but you're not supposed to flash an initramfs.
Ok, looks like the partition must be named "firware" to be able to sysupgrade. After sysupgrade, I cannot boot the image:
[ 2.186355] mtdblock: MTD device 'rootfs' is NAND, please consider using UBI block devices instead.
[ 2.195825] List of all partitions:
[ 2.199322] 1f00 512 mtdblock0
[ 2.199327] (driver?)
[ 2.205868] 1f01 256 mtdblock1
[ 2.205873] (driver?)
[ 2.212396] 1f02 512 mtdblock2
[ 2.212400] (driver?)
[ 2.218930] 1f03 256 mtdblock3
[ 2.218935] (driver?)
[ 2.225469] 1f04 256 mtdblock4
[ 2.225473] (driver?)
[ 2.231994] 1f05 512 mtdblock5
[ 2.231998] (driver?)
[ 2.238524] 1f06 512 mtdblock6
[ 2.238527] (driver?)
[ 2.245054] 1f07 46080 mtdblock7
[ 2.245057] (driver?)
[ 2.251579] 1f08 8192 mtdblock8
[ 2.251582] (driver?)
[ 2.258108] 1f09 37888 mtdblock9
[ 2.258112] (driver?)
[ 2.264642] 1f0a 46080 mtdblock10
[ 2.264646] (driver?)
[ 2.271254] 1f0b 1024 mtdblock11
[ 2.271257] (driver?)
[ 2.277869] 1f0c 2048 mtdblock12
[ 2.277873] (driver?)
[ 2.284488] 1f0d 3072 mtdblock13
[ 2.284492] (driver?)
[ 2.291097] No filesystem could mount root, tried:
[ 2.291099] squashfs
[ 2.295970]
[ 2.299712] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(31,9)
Any hint would be great, otherwise I'll check the next days.
Ok, i have now an setup where the sysupgrade is accepted and sysupgrade itself is doing something. After sysupgrade, booting is still working but Luci shows me that I'm still in recovery (initramfs) mode.
For me it's not yet clear which partitions are required for sysupgrade (firmware/kernel/rootfs/ubi??) and how the sysupgrade image must look like to flash it correctly. And is a call to nand_do_upgrade always required in platform.sh as soon as NAND memory is used?
Not sure if it is related to flashing the initramfs to flash. As @frollic already stated, that's probably not the best idea...
Any help is appreciated
Update: I have an image now which is not the initramfs and can be used via TFTP:
It's not yet working with the recovery web interface, seems some kind of checksum is missing here:
Enter http firmware upgrading mode:
!!!!!! buf_setup load_addr = 4007ff28
upgrade_open
ERROR(-103) Invalid file-header checksum
upgrade_write_intr:539 upgrade_status(-103) error
psock_readbuf:380 upgrade_write failed(-1)
upgrade_close:673 error, upgrade_status(-103)
there's no guarantee you will be able to figure it out, there's a reason why sometimes flashing using initramfs is required, you're bypassing the recovery checks.
check with similar devices from dlink, see how they are flashed.
Current state:
Update: WPS button is correct in DTS but not usable by the script. After running rmmod gpio_button_hotplug, the button state can be read.
DIR-X3260 might be a similar device, see https://forum.openwrt.org/t/support-d-link-dir-x3260
I checked with other D-Link devices but didn't find any solution for it. So I have to go with the initramfs/sysupgrade approach unitl I figure out which data the recovery mode expects.
If anybody wants to try OpenWrt on the M32 Mesh, perform the following steps:
1. System Load Linux to SDRAM via TFTP." in the boot menuIf you want to revert back to stock firmware:
2. System Load Linux Kernel then write to Flash via TFTP." in the boot menuIf you want to build your own image, you can apply this patch to OpenWrt main:
The whole history is available here: https://github.com/RolandoMagico/openwrt/tree/D-Link_EAGLE_PRO_AI_M32
If you don't want to build images manually, you can use the one from https://github.com/RolandoMagico/openwrt-build/releases/tag/EAGLE_PRO_AI_M32_Build_20230710_1112
The images contain LuCI (also in the initramfs) which should it make easy to create a backup of the Kernel1 partition and flash the sysupgrade image.
As there is no long term experience with this device, the images still can contain bugs.
There seems to be still problems with wifi:
Update: Looks like the OpenWrt TX power settings for the 2.4GHz Wifi are not applied correctly. Increasing the transmit power works around the problem and WiFi is working but it's not the solution of the problem. There are also open issues regarding this topic (TX power setting using MT76), for example https://github.com/openwrt/mt76/issues/787
Hello @mk24, I saw your post (Trouble with Wi-Fi on Belkin RT3200 & 23.05.0-rc2 - #5 by mk24) and was wondering if I face the same issue with the M32 (wich is similar to Belkin RT3200 and Linksys E8450).
In my setup, 2.4GHz doesn't work but 5GHz does. Both calibration data are in the same partition.
If this can be the case: Is it possible to check for ECC errors somehow?
Thanks
Roland
I also tried the calibration data from https://github.com/ericwoud/buildR64arch/blob/main/rootfs/boot/dtbos-BPIR64/wmac-eeprom.dts
At least the wifi signal gets better (from 10% to 50%) but still far away from the expected signal strength.
Then I tried to add the calibration data from my device as mediatek,eeprom-data entry in the DTS instead of referencing the factory partition, no improvement. At least that indicatees that the previously mentioned ECC topic is not my problem.
2.4GHz is finally working. Not an issue in the MT76 component or reading the calibration data, only my own incompetence in writing DTS files. Required changes:
I figured out how to decrypt the D-Link images (tested with two different firmware versions). So I have the unencrypted files with the header. Useful to investigate further regarding the headers/checksums.
The data for decryption are stored in the ODM partition. There is also a private key, some hope that encrypted images for the stock web interface can be provided as well.
There is probably another way for going back to stock firmware: Dump ODM partition and decrypt a D-Link image with it.
Is the AES key the same for different versions?
FYI, in D-Link DAP-1620 the AES key is generated using the following:
echo -n DAP-1620 | openssl dgst -sha1 -hmac MT76XMT7621-RP-PR2475-NA
(MT76XMT7621-RP-PR2475-NA is a string that appears in the firmware, similar to your DLK6E6010001)
I'm not familiar with openssl, but your command prints 40 bytes/characters while the Firmware Key from my devices has a length of 32 bytes/characters.
Indeed, SHA-1 is a 160-bit digest. But perhaps a similar idea is used.
No GPL sources, right?