Belkin RT3200/Linksys E8450 WiFi AX discussion

For Developers
6184

Hi! Excuse me for probably simple questions, but I'm a little confused. Made a mistake in the first place by flashing wrong image from stock firmware (kernel instead of installer from owrt-ubi-installer), after that made a serial connection

mtk_uartboot -a -s COM3 -p mt7622-ram-1ddr-bl2.bin -f openwrt-mediatek-mt7622-linksys_e8450-ubi-bl31-uboot.fip && putty.exe -serial COM3 -sercfg 115200,8,n,1,N

Flashed bl31-uboot.fip, bl2, different snapshot and stable images by tftp to production and recovery, tried ubiupdatevol, but I still get same "Bad VID magic". I'm pretty sure I'm missing something but can't come with it. Could someone give a little guidance on what steps should be made to make router boot? It boots in Production and Recovery with mtk_uartboot, but not without.
Thank you.

F0: 102B 0000
F6: 0000 0000
V0: 0000 0000 [0001]
00: 0000 0000
BP: 0400 0041 [0000]
G0: 1190 0000
T0: 0000 02ED [000F]
Jump to BL

NOTICE:  BL2: v2.10.0   (release):OpenWrt v2024.01.17~bacca82a-3 (mt7622-snand-ubi-1ddr)
NOTICE:  BL2: Built : 22:41:02, Nov 24 2024
NOTICE:  WDT: [40000000] Software reset (reboot)
NOTICE:  CPU: MT7622
NOTICE:  SPI-NAND: adjusting SPI-NAND pin drive strength to 12mA
NOTICE:  SPI-NAND: FM35Q1GA (128MB)
NOTICE:  UBI: scanning [0x80000 - 0x8000000] ...
NOTICE:  UBI: Bad VID magic in block 0 f35301a9
NOTICE:  UBI: Bad VID magic in block 1 e43f40f9
NOTICE:  UBI: Bad VID magic in block 2 21a02791
NOTICE:  UBI: Bad VID magic in block 3 00fc48d3
NOTICE:  UBI: Bad VID magic in block 4 e20315aa
NOTICE:  UBI: Bad VID magic in block 5 6fffff17
NOTICE:  UBI: Bad VID magic in block 6 6c782920
NOTICE:  UBI: Bad VID magic in block 7 00000000
NOTICE:  UBI: Bad VID magic in block 8 00000000
NOTICE:  UBI: Bad VID magic in block 9 00000000
NOTICE:  UBI: scanning is finished
NOTICE:  UBI: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
NOTICE:  UBI: VID header offset: 2048 (aligned 2048), data offset: 4096
ERROR:   UBI error: No volume named fip could be found
NOTICE:  UBI: scanning [0x80000 - 0x8000000] ...
NOTICE:  UBI: Bad VID magic in block 0 f35301a9
NOTICE:  UBI: Bad VID magic in block 1 e43f40f9
NOTICE:  UBI: Bad VID magic in block 2 21a02791
NOTICE:  UBI: Bad VID magic in block 3 00fc48d3
NOTICE:  UBI: Bad VID magic in block 4 e20315aa
NOTICE:  UBI: Bad VID magic in block 5 6fffff17
NOTICE:  UBI: Bad VID magic in block 6 6c782920
NOTICE:  UBI: Bad VID magic in block 7 00000000
NOTICE:  UBI: Bad VID magic in block 8 00000000
NOTICE:  UBI: Bad VID magic in block 9 00000000
NOTICE:  UBI: scanning is finished
NOTICE:  UBI: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
NOTICE:  UBI: VID header offset: 2048 (aligned 2048), data offset: 4096
ERROR:   UBI error: No volume named fip could be found
ERROR:   BL2: Failed to load image id 3 (-2)
6185

The error you're seeing is that the router doesn't see the UBI data structures where it expects to find them. This isn't a surprise given that stock firmware doesn't use UBI and so there was never a UBI partition in the first place. However, the random writing of images in an attempt to fix the router might have caused a serious problem depending on the order in which things took place.

First and foremost, do you remember whether you tried to write the stable OpenWRT first, or did you try to write the snapshot first? If you wrote the snapshot first, you've probably blitzed your factory partition and therefore the process gets... unpleasant. That partition's content is unique to that specific router, and WiFi relies upon data within said partition.

However, if you wrote stable first and given that the above log output shows that you don't have the snapshot layout on the flash chip, there's a chance the partition is intact. In order to know for sure, we need to test the data. Boot up using mtk_uartboot with the FIP for 23.05.5 and issue the following commands:

mtd dump spi-nand0 0x1C0000

The above will produce a long dump of data. What you're looking for is at the start of the output. The first two bytes at address 0x001c0000 should read 22 76. If they are anything else, the factory partition is gone. If they do match, you also need to check the following:

mtd dump spi-nand0 0x1C5000

The first two bytes at address 0x001c5000 should be 15 79. If they do match, we can perform the final check with

mtd dump spi-nand0 0x23F800

This time, you're looking for the last line of output, address 0x0023fff0. What you see there should be ff ff ff ff followed by your LAN MAC address and your WAN MAC address. If this is the case, you appear to have an intact factory partition.

My factory partition is intact.

As long as your factory partition is present in the MTD partition, you can safely write the bl2 from version 22.03.7 (NOT 23.05.x!) and the FIP from 23.05.5. You'll then need to clear and format UBI with ubi detach; mtd erase ubi && ubi part ubi before installing the recovery and production images, also from 23.05.5.

My factory partition is corrupted or missing.

If the above checks show that your factory partition is damaged, you'll need to rebuild it in order to get WiFi and stable MAC addresses. There is a surrogate partition available in a post in this very topic, under the heading 'Hard Recovery' Belkin RT3200/Linksys E8450 WiFi AX discussion - #5108 by grauerfuchs. That topic post provides the instructions needed to rebuild your device's factory partition to mostly full function as well as reformat and reload your router to a point where it will run the OpenWRT stable firmware.

Please note that the above instructions will only get you to stable 23.05.x and not to SNAPSHOT or to any subsequent stable release. If you want to run something newer, you'll need to run the proper installer after recovering.

2 Likes
6186

First of all, thank you for your time and such a detailed answer, I did all the steps, and that helped. Thank you very much

6187

Everything works, except 5Ghz radio, I'm very glad router works now, just curious is it fixable or there is not way to fix it? Thank you

[    7.132924] mt7622-wmac 18000000.wmac: registering led 'mt76-phy0'
[    7.192960] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
[    7.257451] mt7915e 0000:01:00.0: assign IRQ: got 146
[    7.262597] mt7915e 0000:01:00.0: enabling device (0000 -> 0002)
[    7.268693] mt7915e 0000:01:00.0: enabling bus mastering
[    7.302799] mt7622-wmac 18000000.wmac: HW/SW Version: 0x8a108a10, Build Time: 20190801210006a
[    7.302799]
[    7.392745] mtk-pcie 1a143000.pcie: msi#0 address_hi 0x0 address_lo 0x44d6d0c0
[    7.395603] mt7622-wmac 18000000.wmac: N9 Firmware Version: _reserved_, Build Time: 20220630094834
[    7.438738] mt7915e 0000:01:00.0: HW/SW Version: 0x8a108a10, Build Time: 20220929104113a
[    7.438738]
[    7.581208] mt7915e 0000:01:00.0: WM Firmware Version: ____000000, Build Time: 20220929104145
[    7.616603] mt7915e 0000:01:00.0: WA Firmware Version: DEV_000000, Build Time: 20220929104205
[    7.733281] mt7915e 0000:01:00.0: eeprom load fail, use default bin
[    7.739749] mt7915e 0000:01:00.0: Direct firmware load for mediatek/mt7915_eeprom.bin failed with error -2
[    7.749497] mt7915e 0000:01:00.0: Falling back to sysfs fallback for: mediatek/mt7915_eeprom.bin
[    7.766544] mt7915e: probe of 0000:01:00.0 failed with error -12
6188

Unfortunately, it looks like your factory partition cannot be read. When the router fails to load the firmware (the error appears in your log), the device won't populate. The 2.4GHz radio will also be limited to 6dBm if the factory partition can't be read.

The recovery post contains the information necessary to replace the factory partition with the surrogate in preparation for running the released 23.05.x version of OpenWRT or older. As part of the loading process, you really do want to make sure you set the proper MAC addresses before writing it to flash (those instructions are also present in the same post). If you don't do so, your MAC addresses will randomly change after reboots.

If the router has already been upgraded to snapshot, the instructions in the recovery post won't work without significant changes. As part of the new data layout, the factory partition's data was moved into a UBI volume.

1 Like
6189

Would there be any real-world change in WiFi performance? Does the factory WiFi calibration actually make much of a difference?

6190

In the context of this model router, there is no difference because the router did not ship with calibration data in the factory partition. However, the surrogate is a rebuild, cobbled together using the data identified within the driver source code that was used by OpenWRT at the time. Comparing the surrogate to the factory partitions in a number of routers shows that the surrogate is indeed missing a lot of data that shipped with the router.

At the time of testing, the surrogate showed no feature support differences or identifiable functional configuration differences when compared against the device operating with its factory-shipped partition. The radios were tested, and both were able to connect to client devices as well as act in the role of client devices. However, not being able to translate the "extra" data present in the partition means that the surrogate might be missing some kind of feature or option that was unseen, such as changes that appear in newer or older drivers.

2 Likes
6191

Do you mean all RT3200’s didn’t have any kind of WiFi calibration data?

Is the WiFi calibration something that could be optimised by way of a script that messes about with the data until maximum iperf3 bandwidth is scored?

6192

Given that neither my RT3200s nor my e8450s contained WiFi calibration sections in any of the EEPROMs, it is very unlikely that they calibrated any of them. The only situations I can see where they might have done would be if some regions required it by law or if they decided to repackage the same hardware as a different model and sell it as a higher level device for more $$$.

Trying to do so would be an exercise in futility and insanity. First of all, few of the parameters would result in any meaningful, trustworthy data under that kind of testing. You'd have many variables to take into account, and most of them can't be measured by the kind of data that iperf3 would give you. You might end up with a result that reads higher at the moment that it is done, only to find out that you ended up with overall degraded performance outside of those limited test conditions.

All that aside, changing some parameters without isolating the router in the proper test environment would probably violate the law. In nearly all regulatory domains, your radios must meet regulations for signal bandwidth, signal amplitude, signal deviation, limitation of unwanted signal inclusions (carriers, intermediate frequencies, harmonics, etc.), and far more. In tweaking parameters, there's a very real risk of one or more of those regulations being broken even if only temporarily. However, an illegal transmission is still an illegal transmission. On top of the transmit side parameters, you have the higher complexity on the receive/decode side as well. You may also need to take into account the effect of age and heat on certain components, and much more.

There's a reason the proper test equipment is so expensive. If you really want to calibrate the router and see if it makes a difference and how, then be ready to spend a lot of money to do so. What would the end result be under the majority of cases? I suspect you'd find the cost and work ends up well within the "not worth it" category by the time it is complete, but that is only an educated guess. As a side note, I suspect that if we were to analyze the EEPROMs from numerous models from many manufacturers, we'd find very few (and especially not the low-cost consumer-level devices) actually do the calibration.

Edit: ...and then there's also the issue of the calibration being used within the radio firmware BLOB and not by the open source drivers. The calibration data passes through the driver on its way to the radio, but it isn't parsed; There would be no value in the driver doing so. Even if we tried to script things like this, we'd have a much harder time getting hold of the documentation to identify exactly what is being changed and where within the calibration data.

6193

Operators of large fleets of devices (e.g. freifunk) did check this (comparing ART) for the tl-wr841n in the past, while these are old low-end (802.11n/ 2.4-GHz-only) devices, ART was generally seen as being (really) unique (after taking the MAC addresses in there out of the equation).

6194

Large operators and enterprise environments are places where I think tuning would be more important, and so of course they want to see whether or not the calibration and tuning are actually there and that they haven't received lower-grade devices. After all, the devices are more likely to operate better at scale when they are properly tuned.

The big question is whether or not the ART partitions were exclusively tuning data or whether or not they also contained general EEPROM data. Even on the RT3200/e8450, I noted that the sections not present within the driver's listed data (and therefore missing from the surrogate) had a lot of unique information on a per-device level. Maybe some of this was internally-stored and referenced parameters? Maybe it's something the radio firmware BLOB would use but I couldn't see? I don't know.

6195

Freifunk is a community mesh project (usually based on OpenWrt, not in the proprietary SDK sense, but 'just' extending OpenWrt (~gluon) with their meshing dæmons of choice (B.A.T.M.A.N., fastd, tunneldigger, etc. pp.), built up out of small regional groups using the devices provided by volunteers willing to operate them. There is no central buying power behind them, just advice for the current -cheap- entry level devices. So they've only collected the information from a couple hundreds/ a few thousands of user-provided/ user-bought off-the-mill wireless routers.

1 Like
6196

It's still a large operator overall. Especially in a mesh-style configuration, the efficiency and reliability are important. As for whether or not the manufacturers usually perform calibration, it still depends on many factors and my statement about them likely not bothering with it was merely a suspicion and was stated as such. It seems reasonable that some of the older hardware may have needed calibration in order to ensure reliable function, but modern chips may not need it. It's also possible that I could be entirely wrong on the suspicion altogether.

The information provided from them about the tl-wr841n is valuable information regarding that model and other similar models supported at the time. However, in performing their analysis, did they confirm whether or not a tuning/calibration section was present and enabled within that data?

A quick visual inspection showed a lot of unique values in the RT3200's EEPROM. However, nearly all of that unique data was present in those segments that were not referenced by the driver source. The driver source contains offsets for the tuning/calibration data along with flags that identify whether or not the feature is enabled. On the RT3200/e8450 EEPROMs I reviewed, not a single one contained calibration data or any flag that would enable its usage.

2 Likes
6197

For those of us still on 23.XX, in anticipation of upgrading to the new 24.XX release using the associated new installer, what steps would need to be taken to restore our existing config on top of the upgrade? Or would it be better to build up again from scratch?

6198

I did this two weeks ago. I restored my config without problems.

For future upgrades you have to bump compat_version.

uci set system.@system[0].compat_version='2.0' 
uci commit system

For adblock-lean i had to do the following, but i guess you are already aware of this.

uci set dhcp.@dnsmasq[0].confdir='/tmp/dnsmasq.d'
uci commit dhcp && reboot

With the changed storage layout it is not really clear to my how to move back to stock firmware (or 23.05) though, but at the moment i have no reason to go back. 24.10-SNAPSHOT works without issues (at least for me).

Here is the comment from @daniel, that i bookmarked.

6199

Is the new UBI format resulting from v1.1.3 installer backwards compatible to 23.05 branch?

I am planning to use my RT3200 for testing 24.10.0-rc. (Which will require this new format)

Can I downgrade back to 23.05 on the new UBI format if I have issues?
What is the downgrade process if I need to go down this path?

FWIW, here is what I have on the router right now:

root@rt3200:~# grep "(release)" /dev/mtd0ro
v2.4(release):OpenWrt v2021-05-08-d2c75b21-1 (mt7622-snand-1ddr)
v2.4(release):OpenWrt v2021-05-08-d2c75b21-1 (mt7622-snand-1ddr)
v2.4(release):OpenWrt v2021-05-08-d2c75b21-1 (mt7622-snand-1ddr)
v2.4(release):OpenWrt v2021-05-08-d2c75b21-1 (mt7622-snand-1ddr)
6200

According to the GitHub, it's not. I'm more worried about additional changes/bugs. 1.1.3 is tagged as a pre-release. I think I'll be staying on 23.05 until there is an official release.

6201

Am I right in thinking an updated installer will be released for those on 23.XX and old installer versions to upgrade to 24.XX?

6202

Edit:
I correct my answer...
Not quite sure, as there has been the suitable installer available for some time now. It differs from 23.05, yes, but the "updated installer" 1.1.3 has been available already since August 2024.

6203

But this was discussed all along, right?

And how then does one square that with: