Adding OpenWrt support for Xiaomi AX3600 (Part 1)

For Developers
9911

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.

9912

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

9913

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.

9914

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

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

oh wow....

9916

Yeah, but you cannot force it into factory mode

9917

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

9918

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

1 Like
9919

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

9920

Hehe, that is exactly what we need

9921

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.

9922

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?

9923

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
9924

Also @robimarko setting flag_boot_rootfs is not useful as

in the code they will setenv("flag_boot_rootfs", "0"); (based on the partition number)
and do a save_env

so actually we can use flag_boot_rootfs as a way to detect the current booting partition... it will always reflect what is loaded... it's not used as a value to chose what to boot.

9925

in short this can be reduced to...

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

# Enforce single partition.
fw_setenv flag_try_sys2_failed 2
9926

@Ansuel
I mean, boards use the DP indexes willy-nilly without any ordering (QCA does the same stupid thing).
PHY handles will be left to individual boards as they can use weird addresses and stuff.
qcom,mactype is a weird one, it seems that 0 means 1G MAC, while 1 means 10G MAC mode, will default to 0 and override if needed.

BTW, Dynalink is using mactype 1 for one of the QCA8075-s, that's extremely weird.

You sure that only fw_setenv flag_try_sys2_failed 2 is enough?

9927

if the decompiled code is correct yes

image

the else part is all the checks for ota boot and last success... but we never enter as v10 will be true for the condition v10 = flag_try_sys2_failed > 1;

later in the code there is

image

2 Likes
9928

I tried a series of different env configs somewhere in here that might help.

1 Like
9929

@Ansuel Look how Dynalink solved port numbering in stock FW:

&dp1 {
	status = "okay";
	qcom,id = <6>;
	reg = <0x3a007000 0x3fff>;
	phy-handle = <&qca8081>;
	label = "wan";
};

&dp2 {
	status = "okay";
	qcom,id = <4>;
	reg = <0x3a001600 0x200>;
	phy-handle = <&qca8075_3>;
	label = "lan1";
};

&dp3 {
	status = "okay";
	phy-handle = <&qca8075_2>;
	label = "lan2";
};

&dp4 {
	status = "okay";
	qcom,id = <2>;
	reg = <0x3a001200 0x200>;
	phy-handle = <&qca8075_1>;
	label = "lan3";
};

&dp5 {
	status = "okay";
	qcom,id = <1>;
	reg = <0x3a001000 0x200>;
	qcom,mactype = <1>;
	phy-handle = <&qca8075_0>;
	label = "lan4";
};

By completely changing the DP indexing, now that we have labels we can sort that out easily.
Gonna have to disable my Dynalink and connect UART to get this sorted out, as only Dynalink and EAP102 override the indexes

9930

Yes i notice that while diffing dts... so the idea is to restore id back to a sane value and just assign a correct label correct?