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?
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
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:
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 ?
Dont, its not complete.
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.....
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.
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.