Adding OpenWrt support for Xiaomi AX3600 (Part 1)

robimarko · 2023-01-12T12:58:44.684Z

That should only work with the downstream QTI_CTX driver which stores the crash log in SMEM memory.

I pushed the new sysupgrade recipe which should set everything to pretty much make it impossible to boot from the second rootfs.

Simulating a kernel crash with: echo "c" > /proc/sysrq-trigger doesn't do anything, it boots again fine

McGiverGim · 2023-01-12T13:13:05.621Z

robimarko:

fw_setenv flag_last_success 1

This represents last partition that started without errors? If yes, I think is better to specifiy 0, in this way the uboot knows that partition 0 is ok.

fw_setenv flag_boot_rootfs -> rootfs used at this moment, must be 0
fw_setenv flag_last_success --> latest partition that started ok, I suppose must be 0
fw_setenv flag_boot_success -> latest boot attempt result, must be 1 to specify that partion 0 is ok.

In this way it will start from partition 0 because is ok and latest start was ok.

EDIT: I've found this in a LEDE patch of Mi Router 3G:

uboot expects to find bootable kernels at nand addresses 0x200000 &
0x600000 known by uboot as "system 1" and "system 2" respectively.
uboot chooses which system to hand control to based on 3 environment
variables: flag_last_success, flag_try_sys1_failed & flag_try_sys2_failed

last_success represents a preference for a particular system and is set
to 0 for system 1, set to 1 for system 2. last_success is considered if
and only if both try_sys'n'_failed flags are 0 (ie. unset) If either
failed flags are set then uboot will attempt to hand control to the
non failed system. If both failed flags are set then uboot will check
the uImage CRC of system 1 and hand control to it if ok. If the uImage
CRC of system is not ok, uboot will hand control to system 2
irrespective of system 2's uImage CRC.

NOTE: uboot only ever sets failed flags, it never clears them. uboot
sets a system's failed flag if that system's was selected for boot but
the uImage CRC is incorrect.

jmmc · 2023-01-12T13:22:55.003Z

Thank you! It worked!!

robimarko · 2023-01-12T13:29:27.349Z

Ok, so setting both to failed makes sense as we are gonna end up booting rootfs 0 as its the only one with uImage at all.

Basically, I gotta change the flag_last_success to 0 as well.

But where does flag_boot_success fit into this?

Ansuel · 2023-01-12T13:43:31.534Z

@robimarko did we tried to remove the variables? crazy idea... wonder if one of them is part of xiaomi firmware and not handled by uboot?

robimarko · 2023-01-12T13:45:27.938Z

That will not work as bootloader is for sure interpreting them as well, it will also set them but it doesn't clear them.

Setting:

# Make sure that UART is enabled
fw_setenv boot_wait on
fw_setenv uart_en 1

# Enforce single partition.
fw_setenv flag_boot_rootfs 0
fw_setenv flag_last_success 0
fw_setenv flag_boot_success 1
fw_setenv flag_try_sys1_failed 8
fw_setenv flag_try_sys2_failed 8

Should really be bulletproof

McGiverGim · 2023-01-12T14:47:13.142Z

Tested with my second router with the new "recipe" and the sysupgrade worked perfectly. I don't know if it was luck or not, but I did the same than for the other one.

One thing: the new Action build of your repo seems stuck trying to download sources.

jmmc · 2023-01-12T14:49:16.249Z

I have been trying in depth and I think in original firmware is a bit faster. Is there anything left to configure?

Does ax3600 support hardware offloading?

Thank you!

Edit:

Got full speed disabling offloading and leaving Packet Steering enabled.

robimarko · 2023-01-12T15:20:20.109Z

Yeah, ath10k-ct firmware page is down so it has to timeout for each file before reverting to OpenWrt CDN mirror.

So, it only now got to building tools

soxrok2212 · 2023-01-12T16:22:50.972Z

IIRC, the AX6S and Redmi AX6000 were set to 8 as the bootloader would default to the first partition if both were more than 6 or 7, I don’t remember.

See https://pastebin.com/xzRXCbzU

I had issues with this too on the AX6000. 8 for both worked perfectly.

robimarko · 2023-01-12T16:23:44.150Z

Thanks for reaching out, for me they seem to work at 8 as well, I presume they all share the same logic in the bootloader

Ansuel · 2023-01-12T16:32:48.327Z

 if ( check_factory_mode() == 1 )
 {
setenv("uart_en", "1");
setenv("boot_wait", "on");
}

oh wow....

robimarko · 2023-01-12T16:35:56.859Z

Yeah, but you cannot force it into factory mode

Ansuel · 2023-01-12T16:36:59.535Z

the mode is triggered by writing a specific value in the crash partition... they totally have a bin in the original fw that do that with a specific packet

robimarko · 2023-01-12T16:38:57.366Z

Thankfully they left more easily exploitable LUA holes.

BTW, moved the switch scheduler etc into the ESS DTSI.
Working on DP now, and well its a mess in which DP numbers are willy-nilly used

Ansuel · 2023-01-12T16:39:41.530Z

anyway from what i can read in the code.... setting flag_try_sys2_failed to something > 1 will force booting from the first partition in any possible case

robimarko · 2023-01-12T16:39:58.504Z

Hehe, that is exactly what we need

Ansuel · 2023-01-12T16:41:43.254Z

yep any check condition is ignored and they just force partition 0... and i also remember discovering that...

if both try_sys1 and try_sys2 were 1 uboot always loaded partition 0 (but i wasn't so sure and the test were really old)

And that is exactly what is present in the code.

Edrikk · 2023-01-12T16:43:55.963Z

Hi Robi,
So as to not risk an upgrade to the next build causing the issue, is it sufficient to "simply fw_setenv" the above and then do a sys_upgrade to the next version, or should a file in the firmware be manually updated before running the sysupgrade?

I guess another way to ask is if fw_setenv is used to manually update the values as you've noted, does the current code overwrite with incorrect setenv values unless updating a file?

Ansuel · 2023-01-12T16:44:29.081Z

robimarko:

Working on DP now, and well its a mess in which DP numbers are willy-nilly used

from what i notice we have common stuff

max dp6
everything sgmii
mactype all 0 (only a few have dp5 and dp6 set to 1)
phy handle vary a lot but they can be generalized if we really want... the common configuration should be the 4 internal port + custom stuff for the dp5 and dp6... only qnap have a very strange configuration