Well, the docs are bit convoluted and they require a Python script that is not public, the only public script is the mkheader one that adds their filetype header to kernel which then U-boot uses.
We need to dump the QFPROM fuses that hold the certificate hash to see whether we have the right certificate, unfortunately I will be travelling for 10 days or so so I wont be able to work on anything.
I was able to download the 10.01.201 firwmware. If interested pls provide a link where I can drop the file
Please upload it to gdrive, mega or somewhere like that where it does not expire.
Thanks, this will make it way easier for anybody to return to stock or recover
sure ... just make sure you download the file as I am not paying to having it store indefinetely
looking forward to get an openwrt image that can be flashed permanently 
@robimarko apart from the memory how you feel this device compares to the xiaomi ax3600 ? ... if I can extend to the ax9000
Its better than AX3600 as it uses IPQ8072A, has 1GB of RAM and 2.5G port.
AX9000 is better as it has the QCN9024 for higher performance 5G
Any news on that device? Currently only booting the initramfs is working, right?
I got one on eBay for 45,- Euro 
Yeah, though bootcmd can be overriden to boot unsigned
How can I overwrite it? Do I need serial access?
I guess it’s more work than just getting ssh access, „ubiformat“ your build and “fw_setenv bootcmd“ with the right partition?
lucky you mr thorsten from previous replies earlier i think yes you need uart .... for this device (vs ax9000) from my personal experience you will need to soldier the uart... hoping that this gets Robi's priority once the xiaomi ax3600 goes upstream with a PR... as the xiaomi 9000 is not viable I feel bearing in mind only the devices with the chinese firmware are viable
Not soldering needed if you find the proper connector.
good job everyone was able to get the uart witha 4-pin 2.0mm (thx @Gost6 ) and load robi's openwrt itb image ... has anyone flashed the firmware on rootfs and then changed the bootcmd ? .. .forgot the openwrt images need to be signed if we are not to bypass bootipq...
So I was able to get openwrt both on mtd18 & mtd20
had to tweak uboot with the following
bootargs=ubi.mtd=rootfs root=mtd:ubi_rootfs rootfstype=squashfs
mtdparts=mtdparts=nand0:0x6100000@0x1000000(fs),0x6100000@0x7a00000(fs_1),
mtdids=nand0=nand0
setpartfs=ubi part fs;ubi read 0x44000000 kernel 0x80000000
setpartfs1=ubi part fs_1;ubi read 0x44000000 kernel 0x80000000
bootcmd=run setpartfs;bootm 0x44000000#config@rt5010w-d350-rev0
saveenv
this has allowed me to bypass the signature check ..
not a permanent solution of course
I am traveliing, will look into it again once I return.
Though, there doesnt seem a way to avoid changing boot cmd and having to set the u-boot rootfs parts
yes ... i guess the upgrade script will probably have to set the bootcmd & other env variables via fw_setenv ... the challenge will be how to do uboot saveenv to populate mtd14 for people without uart or can copy a backup ...
unless of course we get the attestation cert or don't need it...
safe travels @robimarko
I was able to sysupgrade successfully a few times with the following logic on
target/linux/ipq807x/base-files/lib/upgrade/platform.sh
platform_do_upgrade() {
case "$(board_name)" in
dynalink,dl-wrx36)
active="$(fw_printenv -n active)"
if [ "$active" -eq "1" ]; then
# currently on rootfs_1 start switch to rootfs
CI_UBIPART="rootfs"
fw_setenv bootcmd 'run setpartfs;bootm 0x44000000#config@rt5010w-d350-rev0'
fw_setenv active 0
else
# currently on rootfs start switch to rootfs_1
CI_UBIPART="rootfs_1"
fw_setenv bootcmd 'run setpartfs1;bootm 0x44000000#config@rt5010w-d350-rev0'
fw_setenv active 1
fi
nand_do_upgrade "$1"
Does u-boot not have hush shell enabled? Ideally the active variable should only be needed, something like:
bootcmd=run setup && run bootlinux
setup=if test $active = 0; then ubi part fs ; else ubi part fs_1; fi
bootlinux=ubi read 0x44000000 kernel 0x80000000 ; bootm 0x44000000#config@rt5010w-d350-rev0
Might want to build in a failsafe too to tftp boot when fs and fs_1 both fail.
thank you @clayface yes indeed... makes sense your proposal ... i feel from a production perspective whatever logic we have the challenge is to build the uboot env variables for users without uart ... the device comes out with a mtd14 empty that needs to be populated with saveenv...