OpenWrt Support for D-Link DAP-X1860

For Developers
41

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
42

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 https://elixir.bootlin.com/linux/latest/source/drivers/mtd/ubi/io.c#L583, 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:

openwrt-ramips-mt7621-dlink_dap-x1860-a1-initramfs-kernel.bin
openwrt-ramips-mt7621-dlink_dap-x1860-a1-squashfs-factory.bin
openwrt-ramips-mt7621-dlink_dap-x1860-a1-squashfs-sysupgrade.bin

// edit: images updated on 2022-12-03 with final partiton layout, nmbm and fixed rssi ucidefs

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
43

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

44

I've noticed that your dts doesn't include support for recently added Mediatek NMBM .This is special bad block handling for NAND . It seems OEM uboot is using that feature similar like recent ARM based designs . This interesting topic is from AX6000 thread.

2 Likes
45

Thanks, I was wondering already whether the nmbm driver was just a proprietary equivalent of the mtk-nand, since I could not find anything called nmbm within other devices. I'll check the AX6000 thread. Maybe this could fix the IO error seen by ubi when it tries to format the volume initially.

By the way, I have also switched to mtd-concat to use the reserve partition as well, looks good so far, around 85 MiB of freee space for packages after installation :slightly_smiling_face: Will push changes soon (but above image files do not yet contain it).

46

This really seemed too easy, just added one line in dts and NMBM is successfully initialized, starting from 0x7800000. I see that for some devices further options are set, e.g. the AX6000 or Zyxel NWA50AX, which also has

mediatek,bmt-max-ratio = <15>;
mediatek,bmt-max-reserved-blocks = <64>;
mediatek,bmt-remap-range = ...

but it seems everything relevant is automatically detected:

[    0.669775] mt7621-nand 1e003000.nand: ECC strength adjusted to 4 bits
[    0.678367] Signature found at block 1023 [0x07fe0000]
[    0.683490] NMBM management region starts at block 960 [0x07800000]
[    0.693644] First info table with writecount 2 found in block 960
[    0.711178] Second info table with writecount 2 found in block 963
[    0.717456] NMBM has been successfully attached
4 Likes
47

Great .I'm still waiting for my device to arrive from cyber monday impulse buy

48

Hi, Are the files intended to be used with the original firmware? Can I use the factory binary to update a virgin device to openwrt?

49

The factory.bin can be uploaded via the recovery, i.e. keep reset button pressed during plug-in and upload via http://192.168.0.50 (Chromium-based browser recommended).

50

Fixed spelling of dlink,dap-x1860-a1 and resulting alphabetical order in 01_leds, but without any result regarding the RSSI display in OpenWrt (interfaces wlan0 and wlan1 seem to exist initially in disabled state, but as soon as an AP or STA interface is enabled, a new interface will spawn with a dedicated identifier. Not sure how other devices with RSSI display (e.g. DAP-1330) would behave in latest OpenWrt master.

Curiously, for downstream builds of freifunk-gluon, the RSSI display is now working, even without there being a wlan0 interface listed in the output of iwinfo (maybe this is due to some gluon-related magic though). Additionally, it was observed there is no RSSI graph on the gluon device status page, however for another device with supposedly identical hardware (Zyxel NWA55AXE), the channel graph would flawlessly display RSSI measurements for both of the radios.

So there seem to be (at least) three distinct issues here, one of which was solved by fixing the spelling of the model name in 01_leds. I might check the behaviour of DAP-1330 with latest master, and consider the DAP-X1860 ready for opening a PR if the RSSI display issue indeed persists with other devices.

// edit: Confirmed with ath79:
In 22.03 the interface was still named wlan0, in latest snapshot it is phy0-sta0.
After calling uci set system.rssid_wlan0.dev='phy0-sta0'
the RSSI display is working (after reboot) for that particular interface (on both DAP-1330 and DAP-X1860).

So this is indeed an issue to be addressed within the rssileds package, it seems the current approach of mapping RSSI display to a single interface would no longer be feasible (besides most OEMs would usually have some magic to determine the actual uplink path a repeater is using at any given time, and automatically display the RSSI for that interface only).

51

@s_2 : I tried you last commit with merges from the openwrt master branch. Changed settings are stored and also available after a reboot.
If somebody is interested in the images: https://workupload.com/file/TsrPUA7Ufnc
After connecting the device to a 5GHz wifi, the LED (green:rssihigh) is also active.

One question: During build of the image, I see a lot of lines (106 times):

make[6] -C target/linux/rampis/image/lzma-loader compile loader.bin

Not sure if it was present before, at least I didn't remember seeing them before. Is this normal?

52

The lzma-loader seems to be built for the target independently of the current device selection, I see a lot of these in the build log as well.

Weird, so wlan0 would actually refer to phy1 and vice versa? I must admit I had only really tested this on the 2.4G band, but a quick check with my latest image did not make it work with 5G either.

Do you still have the setting from the above post in uci, i.e. is really just rssihigh lit up, not the full bargraph?

53

You're rigth, I made changes in the LED configuration. I think I did something wrong in the configuration which seems to enable/disable the LED depending on the wifi configuration. But I reset the device now and just connected 5GHz, no LED activity.
Sorry for the confusion

54

Not sure if there are still any problems with LEDs or with functionality in general, as I have not tried any of the builds yet, but i found this issue to be an interesting read: ramips: correct the pcie port number for some mt7621 devices (fix Wi-Fi lost) and although they are not talking about mt7915E ... there are a few recent comments at the bottom talking about LED behaviour, which could be used as the base for some experimentation.

55

Regarding the LEDs, they are working in general. Problem is that wlan0 or wlan1 interfaces are not available when setting up a wireless connection with default settings.
As @s_2 mentioned, as a workaround this line can be used:
uci set system.rssid_wlan0.dev='phy0-sta0'

I also had success by renaming the interface name to wlan0 after setting up a wifi connection. After a reboot, the LEDs are also showing the expected behavior

3 Likes
56

Hello. I have been following this thread, but I am kinda lost. Are just the LEDs not working and the image is safe to use, or is there still some work need to be done?

57

In the last days, there were multiple additions to the mt76 driver and the upstream linux kernel "Linux-next". Many of those were for mt7915. With regard to LEDs, the following commit is of special interest: https://github.com/openwrt/mt76/commit/81edc468fc620a28bb5e5708e27139ef3f5d304a. At first glance I have not found a commit explicitly dealing with issues related to wlan interfaces and default settings, but that could be because my expertise is lacking with regard to interpreting code.

Anyway, I would expect performance changes (hopefully improvements! :slight_smile: ) as soon as those changes from mt76 are merged into OpenWRT main. (Edit: newest mt76 is merged now)

1 Like
58

The PHYs talked about refer to the wireless radios in this case AFAIK, so that seems very relevant.

1 Like
59

Hi, from my point of view everything except LEDs is basically working. Did some tests yesterday with the latest OpenWrt master merged. I don't know if it was tested enough to ensure it's "stable". At my environment, OpenWrt is not yet in an productive environment so there is no long term experience.

Regarding testing, there seems to be a problem with the latest updates, see Probable wifi regression in mt7621 snapshot

1 Like
60

Regarding the LED support, I'm not quite sure if I understood it correctly (please correct me if I'm wrong): The RSSI LEDs are connected to MT7621 GPIO 7/8/22/23/26/27).
This are different pins than the LED pins of MT7915E or MT7975.