OpenWrt Support for D-Link DAP-X1860

Fixed jffs2 creation by recklessly adding more padding after pad-rootfs, now the deadc0de marker will be de-xored without issue. After uploading, Ctrl+C can be pressed in the uboot console, and md.b 80010000 100 will expose the received and de-xored upload in RAM, still wrapped in the multipart/mime headers of the http upload. By incrementing the above offset by the uploaded file size, the end of the file can be observed, as it would be written to flash.

There is still no persistence though, at this point I'm not sure if this is caused by the mtdblock6 device not being writable, as it was not initialized upon some UBI or other FTL container?
@nicefile maybe fixed size partitions are indeed required here.

1 Like

Meanwhile tried switching to ubi, but it would fail when trying to attach and expand the volume for the first time, erasing all blocks untl the end of partition:

[    2.867788] ubi0: attaching mtd4
[    2.876059] mt7530 mdio-bus:1f: Link is Up - 1Gbps/Full - flow control rx/tx
[    2.969558] UBI: EOF marker found, PEBs from 35 will be erased
[    3.214077] ubi0 error: ubi_io_is_bad: error -77 while checking if PEB 225 is bad
[    3.221616] ubi0 error: ubi_attach_mtd_dev: failed to attach mtd4, error -77
[    3.228688] UBI error: cannot attach mtd4
[    3.233467] /dev/root: Can't open blockdev
[    3.237605] VFS: Cannot open root device "(null)" or unknown-block(0,0): error -6

resulting in kernel panic and reboot. First fix involved shrinking the ubi partition in dts and adding lots of padding, which worked but would waste most of the free flash space.

Eventually called nand erase 0x580000 0x3000000 in uboot shell, it detected one bad block and it was fixed: OpenWrt worked, reverting to OEM worked, as well as back to OpenWrt. So it's not the fault of the ELX unpacking here, but what seem to be physicals errors in the lower NAND layers.

The error -77 arises from, but I could not track it down to the actual code where the value of 77 is composed, eventually function pointers are used to abstract this for different lower level nand drivers. So this error -77 must be an issue within the mtk-nand implementation, probably when dealing with bad blocks.

The first device I used for testing back in 2021 was suddenly bricked even when running OEM firmware: It would still boot, but only come up with a default SSID like MTK_HARRIER_AP_2.4G or similar, and flashing the OEM image via recovery would not fix this. Maybe that's due to the same NAND error?

So I tried another device (which had OEM working), but it was the same: Error -77 occured on a different PEB here, erasing manually via uboot fixed it again.

Now I wonder what happens with factory-new devices, which had not been used for so much experimentation... Feel free to try :slightly_smiling_face:


If you get a bootloop (red LED flashing, pause, flashing, ...) it's probably error -77 as well. Try to flash initramfs then, ssh into it and call mtd erase /dev/mtd4, reboot back into the recovery and flash factory again. But I really hope it only affected my two test devices.

RSSI leds not working, no idea what we should use as the interface name.

reserve partition is not yet used, this wil require mtd-concat eventually, I'm curious as to whether this plays nicely with ubi volumes being split into two chunks :joy:

1 Like

I don't have an IT background and am a complete newby, so please take my info with grain of salt, but I have found documentation for Linux MTD NAND driver and it says

"Most NAND chips mark the bad blocks at a defined position in the spare area. Those blocks must not be erased under any circumstances as the bad block information would be lost. It is possible to check the bad block mark each time when the blocks are accessed by reading the spare area of the first page in the block. This is time consuming so a bad block table is used."