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
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 
Will push changes soon (but above image files do not yet contain it).
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
Great .I'm still waiting for my device to arrive from cyber monday impulse buy
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?
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).
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).
@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?
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?
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
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.
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
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?
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! 
) as soon as those changes from mt76 are merged into OpenWRT main. (Edit: newest mt76 is merged now)
1 Like
The PHYs talked about refer to the wireless radios in this case AFAIK, so that seems very relevant.
1 Like
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
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.
Sorry, I don't know.
Regarding the performance, I did a short test with iperf3 between my Windows machine (connected via LAN to the Router) and my Mac (connected via Wifi):
If the Mac is directly connected to the 5GHz wifi of the router:
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 282 MBytes 236 Mbits/sec 0 sender
[ 5] 0.00-10.00 sec 281 MBytes 236 Mbits/sec receiver
If the Mac is connected to the 5GHz Wifi of DAP-X1860 (running as AP connected to the Router LAN):
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 258 MBytes 216 Mbits/sec 0 sender
[ 5] 0.00-10.00 sec 257 MBytes 216 Mbits/sec receiver
If the Mac is connected to the 2.4GHz Wifi of DAP-X1860 (running as AP connected to the Router LAN):
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 125 MBytes 104 Mbits/sec 0 sender
[ 5] 0.00-10.00 sec 124 MBytes 104 Mbits/sec receiver
Used image: https://workupload.com/file/mU3gvLR4VKd (based on https://github.com/RolandoMagico/openwrt/commit/84749101b72c589fc90ddb3946fad18c7ff5aba4)
Did you use the web interface to upload the image? In my case it says firmware update failed.