During various stages seems to halt the boot "eventually", at some random point.
Too late and it'll proceed to boot.
Looking at extracted firmware: /etc/openwrt.config
#
# ATF
#
CONFIG_PACKAGE_atf-mtk=y
#
# atf-mtk settings
#
# CONFIG_ATF_MTK_USE_VERSION_2_5 is not set
CONFIG_ATF_MTK_USE_VERSION_2_7=y
CONFIG_ATF_MTK_VERSION="2.7"
CONFIG_ATF_MTK_VERSION_2_7=y
#
# Boot Loaders
#
CONFIG_PACKAGE_uboot-mtk=y
#
# uboot-mtk settings
#
# CONFIG_UBOOT_MTK_USE_VERSION_6_0_4 is not set
# CONFIG_UBOOT_MTK_USE_VERSION_1_2_1 is not set
CONFIG_UBOOT_MTK_USE_VERSION_2022_01_rc4=y
CONFIG_UBOOT_MTK_VERSION="2022.01-rc4"
CONFIG_UBOOT_MTK_VERSION_2022_01_rc4=y
So yes, ATF is used as well as u-boot. It's likely BL33, which is not missing from the bootlog, it's just not present.
Upload some firmwares(no ssh enabled) collected from their QQ group. looks like a full firmware upgrade contains 4 files: preloader.bin, fip.bin, crash.bin, firmware_ubi.bin
Set it up on a spare Belkin E8450 I have running OpenWrt 22.03-rc4. I verified with wget that it pulled the right config when loading up http://169.254.31.1/cgi-bin/luci/api/xqsystem/token from my laptop. All checked out normally. When attempting this on the RedMi AX6000 (using the correct stok), I'll either get a internal server error or a 502 Bad Gateway. I can see on the E8450 that it has joined as a client, but for whatever reason it fails.
That particular exploit was patched even before the previous model (RB03) was released.
I suggest diffing the lua between the newest and the oldest versions. They'll still be byte-identical with the same input into their obfuscator, so comparison should still show which ones have changed. (They in theory could shuffle opcodes or add no-op junk everywhere, but I believe the primary purpose is mostly to discourage IP theft.)
Changes in their binaries will be harder to track, but I imagine bindiff or similar should work. (I'm not sure of the workflow to do it in batch though)
I'm thinking more about this device and how it uses ATF. I'm wondering if there's a System Control Processor (SCP) on the board and the exposed UART header we have is UART0 and that is connected to the SCP. This means there's likely another UART1 connected to the SoC somewhere else (and this is exactly as I've seen in other devices before). Once the SCP finishes the ATF boot process, it hands off to the application processor and to the other UART interface. This explains why we don't see U-Boot (or the linux kernel booting) on the console, as that is booted on the application processor.
Also see https://www.reddit.com/r/embedded/comments/t6e30j/atf_uboot_experience/ U-Boot is likely printed to some other console. I took my AX6000 apart completely late last night (really late so might've been tired and missed it) but didn't see anything that looked like a UART console.
Strange... They still have it pointing at ttys0 in the bootargs too...
It's obviously not HW flow control since uart0 does not support it (The other two channels do), but maybe they did a funny and enabled software flow control after initial boot? They'd need a way to debug returns somehow, surely? Either that or there's a sneaky 6 pads on there for the other uart channel or jtag. I can't seem to find the jtag enable/disable strap in the BPi reference materials like on the 7622 though.
On another note, that Xiaomi HomeWifi product I noticed in the firmware a few months ago was announced finally...
I don't understand why they disable onboard UART to avoid install custom ROMs.
We paid for device and it became ours.
Why companies try to avoid our access to our paid hardware unit.
They could sell more HW units if they are friendly with consumers.
I reached out to them asking for the source for the open source components. Unfortunately for us, ATF (and SCP-firmware, if used) are BSD-3 - meaning they don't have to disclose those components to us. However, they do have to disclose U-Boot and OpenWrt sources to us due to GPLv2 licenses there. I'll see what they say.
I did have to go through their Chinese site as they don't sell this model outside of China (yet?) so I tacked on a Google Translate Chinese version of my request. Hopefully it doesn't just get thrown out.
Could we upload OpenWRT firmware using TFTP debricking procedures?
Does router checks it at start? Might be, with a help of a reset button at start... If it starts TFTP detection etc... I am not really good on TFTP protocols. It just came into my mind. There should be a debrick procedure for it...
Well, I just picked the router too quick by guessing that if consumers are allowed to root it as older (Mi 3G) routers.
No, the image format is signed. You'd need their keys. Or notice some sort of terrible bug in their image verification. (I haven't looked at it past "Yup, they're checking the image signature")
I asked for the AX3600 kernel source a long time ago and... I hope you will understand that it is very important to us that we provide you with the accurate and expedient resolution regarding any issue you face. However, we are bonded to the terms and conditions of the company policies and we have to serve to be within the restrictions.
I would strongly encourage you to reach out to the FSF. That could be some hefty fines for them. I’ll bet there’s something hidden in there they don’t want people to see
