Dynalink DL-WRX36 Askey RT5010W IPQ8072A technical discussion

from within the stock firmware:

admin@DL-WRX36:~# fw_printenv
Warning: Bad CRC, using default environment
bootcmd=bootipq
bootdelay=2
baudrate=115200

Partition is empty as well here....what is going on?

Can you try saving the env from u-boot?
Cause, they are maybe using the default env since bootqca is gonna sort everything out on the fly anyway

like that?

First setenv mtdids + mtdparts and then:

nand read 0x44000000 0xd00000 0x40000

and

tftpput 0x44000000 0x40000 env

file "env" is empty

Or did I do something wrong?

No, I meant just run saveenv and then dump it from OpenWrt

Yes! Now fw_printenv is working :grinning:

LOL, so they dont even have the env saved on the NAND by default and rely just on the default env plus bootqca command

Last question:

is this intentionally in the platform.sh?

dynalink,dl-wrx36)
active="$(fw_printenv -n active)"

There is not variable "active" defined in the environment....I can't understand how that should switch partitions.

I does not exist in the stock FW, its a idea about preserving dual-fw and using completely custom u-boot env for booting.

It was just a start, never completed

All right, that means we have to make sure, that "active" is properly set during sysupgrade due to uboot doesn't even know about it.

Thats really a non issue, you can set whatever you want during sysupgrade.

I assume the plan is to remove the stock OS? Do we have any way to return to stock if needed?

For switching between active partitions can borrow the logic from the Edge-core EAP102's ubootenv (maybe EAP101 as well).

As for install procedure, how about something along the lines of this:

  1. install config from backup.cfg
  2. ssh in, paste some boot config using fw_setenv (eg to enable tftp booting)
  3. reboot and allow device to tftp boot an OpenWrt image
  4. copy OpenWrt factory image across
  5. ubiformat /dev/mtd18, /dev/mtd20 using factory image
  6. include a script or tell user to paste some more fw_setenv commands to set bootcmd and make active option functional - better done once previous two steps are complete
  7. reboot

Well, you can just flash the stock backup or if someone manages to get the firmware binary image.

The logic to change between the partitions is nothing special, its just a matter of time at this point.

@clayface
can you post your smeminfo from uboot?

I have the feeling, we have two possible mtdpart definition combinations for rootfs and rootfs_1.

This is from my device:

18: rootfs           0x0000ffff        0x7a00000        0x6100000
20: rootfs_1         0x0000ffff        0x1000000        0x6100000

but in robimarkos device they are switched (from bootlog)

0x000001000000-0x000007100000 : "rootfs"
0x000007a00000-0x00000db00000 : "rootfs_1"

This results in a different bootipq call.

This is bootipq debug from my device:

setenv mtdids nand0=nand0 && setenv mtdparts mtdparts=nand0:0x6100000@0x7a00000(fs),0x6100000@0x1000000(fs_1),${msmparts} 

And this is from robimarko:

setenv mtdids nand0=nand0 && setenv mtdparts mtdparts=nand0:0x6100000@0x1000000(fs),0x6100000@0x7a00000(fs_1),${msmparts} 

This would mean, we need to cover both possible combinations in sysupgrade as we need to set the bootcmd manually incl. the different mtdparts.

Yes that is what the active flag is for. When performing a sysupgrade the alternate rootfs will be used. If there is an issue booting the logic will revert to the other partition.

The order they appear doesn't matter, as long as both locations and sizes are correct. (I have the same order as you).

Hi so I got the device and have now ssh access but I have not enabled uart etc. Any means to load Robi's firmware without having uart? i have the issue that I am unable to switch root as in the ax3600/9000 .... would copy one of your 0:APPSBLENV to my device enable me to switch root ?

1 Like

Dont, its not complete.

1 Like

@robimarko:

BTW the luks passwort for the certificate partition can be found here:

strings sbin/mf_tool|grep cryptsetup

Now we have the private key, so in theory we could sign our image and could use bootipq.....

2 Likes

Now that would be awesome, though we would probably have to make our own tooling if QCA didn't accidentally share the QSDK one publicly as they are not signing the FIT image but rather using their custom ELF header on top.

1 Like

BTW, can confirm that the LUKS password is current and the certificate volume is unlockable and mountable.
It contains:
ec_cert.pem ec_private.pem lost+found roots.pem

However, I think that the attestation certificate is missing

Yeah, it's just hardcoded in that file.

Didn't know, that we would need an attestation cert in addition to sign the image.