Belkin RT3200/Linksys E8450 WiFi AX discussion

Nope, it's actually kinda easy.
The reason for this move is explained here: https://openwrt.org/toh/linksys/e8450

Thank you, I think i got it now. Learned something. I have seen the wiki page countless times, but I always misses to click on the gitdiff link, which does explain it.

So basically:

  • before: old slow driver was used, that one was compatible to flash format of manufacturer partition format and manufacturer images. THe old driver had defect management in the flash driver.
  • 2021-08-27 a new more performant more low level flash driver was introduced. That driver is faster, but incompatible to the older flash low level cell addressing. New one also requires UBI layer on top, as now UBI does the cell defect management.

So switching from old to new driver now has side effects:

  1. Defect management now has to be taken over by UBI driver layer above that
  2. as the defect management layer is removed from the driver, the flash address layout changes, requiring all partition data to be rewritten
  3. A new different bootloader must be rewritten as well (am I right?)

As a minor side bonus, since the partition table had to be completely rewritten anyway, the 2 alternating firmware partitions got enlarged, to better use available flash space utilization.

So it was not the plain wish to just enlarge partitions that caused the migration pain, it was the driver architecture change that started it. And that change was due to performance reasons.

…So thats what the effort and script was all about.

4 Likes

@darksky Thanks again for maintaining this page.
I have no editor rights, but I do have some suggestions:

  • add: install and enable irqbalance
  • add: enable packet steering in global network options
  • add: a word on colors for beam forming (btw, is there a way to find used colors on a given frequency?)

Thank you, I think i got it now. Learned something. I have seen the wiki page countless times, but I always misses to click on the gitdiff link, which does explain it.

So all older RT/Linksys OpenWRT firmware images had relied on using a flash driver that was slow, but compatible to the original flash driver from the manufacturer firmware images.

Performance really wasn't an issue with either of the three drivers for
MediaTek SPI-NAND.

The old driver did the defect management via some flash-persisted mapping table and indirection pointers, defect management handled in driver layer itself.

2021-08-27 a new more performant flash driver had been commited to the master. This new driver skips the pointer indirection to address flash, it works one layer lower and does not do defect management on driver level.

MediaTek's BMT is also supported with the new driver and also that
wasn't the reason for the switch. After all, the very same driver is
also used for other devices which do depend on BMT as the original
bootloader uses that.

That change now has side effects:

  1. Defect management now has to be taken over by UBI driver layer above that

Yes, that's correct. We use UBI instead of BMT (One can also use UBI
on top of BMT, though this can have unwanted side effects)

  1. as there is now no more indirect adressing on driver level, the old physical cell data addresses not longer matches the physical cell address expectations as used by the new driver. Thats why completely new partition data has to be written.

It's unlcear to me what you mean by this, probably this is a
misunderstanding about how flash memory is partitioned, see below.

  1. A new different bootloader must be rewritten as well (am I right?)

Yes, and this was also most of the original motivation to begin with: To
have a bootloader with a meaningful dual-boot scheme which actually
prevents soft-bricking the device. The vendor loader, despite supporting
an A/B dual-boot scheme, often ended up in a condition where the user
would have to connect the serial adapter to revive the device.

As a minor side bonus, since the partition table had to be completely rewritten anyway, the 2 alternating firmware partitions got enlarged, to better use available flash space.

There is no such a thing as a partition table on raw NAND flash. This
terminology only makes sense on block storage where we use MBR or GPT
partition table. On raw flash, the partitioning is defined in device
tree, ie. not stored on a fixed block of the flash memory itself.

So it was not the plain wish to just enlarge partitions that caused the migration pain, it was the driver architecture change that started it. And that change was due to performance reasons.

That's wrong. Performance has never been a significant factor in the
whole process.

…So thats what the effort and script was all about.

Not quite. My original intention was to have the option to replace the
bootloader for something 100% built from source, more robust and yet
also more flexible than the vendor's approach. Later on the change of
the NAND driver resulted in read errors of the 'factory' partition
which, because the ECC data in OOB area didn't match the new drivers
expectations. This problem initially affected both, the UBI and non-UBI
builds. However, as the UBI installer was already re-writing most of the
flash it was easy to also make it re-write the 'factory' partition to
fix the ECC errors.
This is why most users at this point switched to the UBI version because
also for using the non-UBI version one had to re-write the factory data
to get rid of the read errors and installation became non-trivial for
that reason.

5 Likes

I do not believe that irqbalance does anything the that the system isn't doing without it. Try looking are cat /proc/interrupts after some uptime without it then add it enabled it and repeat.

I may have missed something obvious, but when the UBI change became permanent did that drop the -ubi from the firmware image name?

I'm trying to go from 22.03.0 -> 22.03.2

On that same note, is there not something similar for updating to official releases like how we could use an updater within LUCI for snapshot versions?

No.
The "UBI" is still prominently in the ubi variant file names.

You have the wrong file.

https://downloads.openwrt.org/releases/22.03.2/targets/mediatek/mt7622/

Considering a Belkin RT3200 and had a couple of questions.

From the device OpenWRT wiki page, there is documentation on how to "Change the default CPU governor" Is there any downside to making this change and if so may I ask why it is not the default?

Regarding "Enabling Wireless Ethernet Dispatch (WED) HW acceleration for Wireless clients," while I fully understand there is no way to specifically quantify the improvement in speed if enabled but is the improvement like 10-25% or something greater?

Any way for these options to be made user selectable in the firmware GUI in a future build?

TIA

Wireless Ethernet Dispatch (WED) HW acceleration for Wireless clients makes wireless downlink (download) from the router to the clients bypass the CPU for lower CPU load. But not for uplink (upload) from the clients on this router.

Thanks for the additional info on WED although I'm not sure it really addresses my questions. The wiki states, "reduce CPU loads/increase routing throughput" so is the difference significant or just theoretical?

That limitation seems to be changing:

commit 4e1a6ee903369cec5de1eb435ce614d4ff77beb0
Author: Felix Fietkau <nbd@nbd.name>
Date:   Mon Nov 21 20:46:46 2022 +0100

    kernel: add WED rx support for mediatek
    
    This is required for rx flow offloading on mt76 with MT7986 and MT7915

Yes, but only for newer SoCs. The MT7622 found in RT3200/E8450 only supports WED TX.

That is because RT3200 have the md7915e version?

[    7.256920] mt7915e 0000:01:00.0: assign IRQ: got 146

No. The MT7622 SoC simply doesn't support WED RX. Only newer SoC (MT7986, ...) does.
MT7915 would be fine for RX and TX WED, but not with this MT7622 SoC.

3 Likes

@dan3 Do you get proper transfers with collectd/luci-app-statistics? For me none of the transfers (except maybe for eth0) show proper values - for example puling ~150Mbps from the internet on lan3 port (linux host) I don't see this traffic neither on wan nor lan3 port graphs.. It shows for ex.13,5kbps...

I guess it could be because of HW acceleration you could try to turn it off and see.

I have not had much luck with tracking bandwidth. I think I broke it by installing both luci-app-statistics and luci-app-nlbwmon. I believe polling Tx/Rx stats resets the values to zero. With two services polling the same stats, and saving their results in separate rrd files, neither service has good data. SMH.

I try to activate wed as described on router openwrt page https://openwrt.org/toh/linksys/e8450#enable_wed but this file /etc/modules.conf doesn't exist, any help?

I observed the same on 22.03.
My APs with WED are all on SNAPSHOT.

Create the file