[mt7622] Re-enable Redmi AX6S/Xiaomi AX3200 snapshot builds

For Developers
1

Snapshot builds for the Redmi AX6S/Xiaomi AX3200 have been disabled on Feb 17, 2024 in this commit by @daniel

There are some discussions about the changes needed to re-enable this build buried in the main AX6S topic proposed by @remittor which I'm not sure it is the right solution.

So Iā€™m creating this specific topic to track what is needed to re-enable AX6S snapshot builds in master/main (and future 24.xx builds).

BTW, @nbd re-enabled RFB1 UBI in this commit (which also had been disabled by this other @daniel's commit) with the following comment:

The boot loader does not have a fixed size limit for the kernel,
so we're free to change the layout. This may break sysupgrade, but a fresh
flash from initramfs works.

Would this same approach (using initramfs) to apply a fresh flash to AX6S work the same way? If so, could the AX6S/AX3200 builds be re-enabled?

UPDATE 10-Mar-2024: there is a pull request by @981213 that would sove the problem with the following apprach:

(...) changed the flash layout and added a second u-boot where the kernel supposed to be.
Now the vendor u-boot chainloads our mainline u-boot, and our u-boot reads kernel+rootfs from UBI, verifies it, and boot into OpenWrt. (...)

More details in Gitlab's pull request here.

1 Like
2

To be sure, you need to try all the options yourself and check all the conditions.

I've been trying out my solution for a long time: https://github.com/openwrt/openwrt/pull/14768
And today I tried @981213 solution: https://github.com/openwrt/openwrt/pull/14770

Both solutions are absolutely working!
Only the solution using an additional loader required modification of the code in XMiR-Patcher and facinstall (I've already fixed and checked everything).

1 Like
3

Thank you. Personally I still have to try your suggestions (I need to find some spare time to do this).

My question here is more in the sense about how this will be fixed in the official builds by committing a patch to the main branch, and what would be the upgrade path from 23.05 to 24.xx. Since I am not a developer, the best I can do is to follow instructions to apply a patch, test and report results.

BTW, we need to provide instructions to both main use cases below:

  1. Users who are on stock firmware and want to install a snapshot/24.xx build and
  2. Users who are already on 23.05 builds and want to install a snapshot/24.xx build (no XMiR-Pacther required)

I am willing to test use case 2 above.

4

build 03 Mar 2024: https://drive.google.com/drive/folders/1i-Je-fNN7kySjz4Iz_Rh5edc7OGtIQAC (with ubi-loader)
Only for testing! (required UART access)

Install under stock firmware:

  1. Copy factory.bin image to /tmp dir.
  2. Type this commands via SSH:
nvram set ssh_en=1
nvram set uart_en=1
nvram set boot_wait=on
nvram set flag_try_sys1_failed=8
nvram set flag_try_sys2_failed=8
nvram set flag_boot_rootfs=0
nvram set flag_boot_success=1
nvram set flag_last_success=1
nvram set "boot_fw1=run boot_rd_img;bootm"
nvram commit
mtd -r write /tmp/factory.bin firmware

Upgrade from OpenWRT with 5.15 kernel:

  1. Copy factory.bin image to /tmp dir.
  2. Type this commands via SSH:
dd if=/tmp/factory.bin bs=1M count=4 | mtd write - kernel
dd if=/tmp/factory.bin bs=1M skip=4 | mtd write - ubi
echo c > /proc/sysrq-trigger
2 Likes
5

Install under stock firmware:

Thanks, but as many I am already at 23.05.2. What's the upgrade path from 23.05? This is what many users will need, and honestly I believe this should he the main use case to be prioritized.

6

You should be able to upgrade and downgrade, without any issues.

7

Speaking as an openwrt user (not developer) I would say that it does not really matter what method is used.
This is openwrt and as such not a main stream product.
It is reasonable to expect that users are able to do some fiddling and even semi complicated manual fixes.
The important thing is to get a working fix, not necessarily to evaluate every possible solution.
Even require UART access might be reasonable.
It is easy to install and as pointed out, this is an ageing product, in many cases out of warranty.

1 Like
8

your opinion is not at all objective!

1 Like
9

I've upgraded 2 devices from 5.15 and it works great. Thank you!

1 Like
10

(with ubi-loader)

Just confirming: is this the factory boot loader?

Also, would you mind in providing a patch file that can be applied on top of the official source tree? I do my own builds from official source tree, and it would be really good if you could provide a patch file.

I believe this would also be a forward path to try to get your changes merged into the official master/main repository in order to re-enable official support to the AX6S/AX3200.

11
1 Like
12

This phrase below explains the information I was looking for, thank you!!!

(...) Now the vendor u-boot chainloads our mainline u-boot, and our u-boot reads kernel+rootfs from UBI, verifies it, and boot into OpenWrt.(...)

1 Like
13

@981213's pull request does not seem to have any attention from the OpenWrt devs (it requires 6 OpenWrt devs to approve it, and so far it has none).

Does anyone know how is there is any way to prioritize this pull request to re-enable AX6S/AX3200 snapshot builds?

Specially now that mt76 drivers have just been updated in the main branch and it includes various fixes for the mt7915.

mt76: mt7915: initialize rssi on adding stations
mt76: mt7915: fix mcu command format for mt7915 tx stats
mt76: mt7915: fix bogus Tx/Rx airtime duration values
mt76: mt7915: fix HE PHY capabilities IE for station mode
mt76: mt7915: only set MT76_MCU_RESET for the main phy
mt76: mt7996: only set MT76_MCU_RESET for the main phy
mt76: mt7915: add support for disabling in-band discovery
mt76: mt7915: add mt7986, mt7916 and mt7981 pre-calibration
mt76: mt7915: add fallback in case of missing precal data

1 Like
14

I'm busy with other stuff recently and haven't found time to finish it yet. The PR is currently missing a flash instruction.

4 Likes
15

I noticed that you just merged your pull request into main. This weekend I will do my build and test.

Many thanks @981213!!!

https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=a6991fc7d251f7ab65a588546e22abfd4f8ce472

16

Ah, it's been merged into master.

Although I think we've left out necessary changes to the stock u-boot vars to stop it trying to boot from 2nd kernel partition offset from the commit message?

eg. setenv bootcmd boot_fw0 & saveenv or similar?

Although it shouldn't change anything if your device was already booting an OpenWrt image beforehand. Should only be an issue for new installs, which can just be addressed with updated instructions on the wiki entry.

17

So this is not the main bootloader, but only an auxiliary one, which loads by stock bootloader from Xiaomi into memory.

18

Regarding this instruction from the commit:

There are two possible ways to convert from the old fw:
Flash the factory image using mtd (provided by @rany2):

mount -o remount,ro /
mount -o remount,ro /overlay
cd /tmp
dd if=factory.bin bs=1M count=4 | mtd write - kernel
dd if=factory.bin bs=1M skip=4 | mtd -r write - ubi

Is the factory.bin image the one generated as part of the build process? Or is it a special image we should get from @rany2?

19

I'm worried about bootxq leading to boot_fw1 before reaching the 2nd stage?

Probably the openwrt-mediatek-mt7622-xiaomi_redmi-router-ax6s-factory.bin generated by build process?

20

So the user is required to pre-configure the stock bootloader.
Example: [mt7622] Re-enable Redmi AX6S/Xiaomi AX3200 snapshot builds - #4 by remittor