UBoot or CBoot for Mender with TX2 NX

[dat-tran-matternet]

I'm using Mender with TX2 NX. The examples show options using cboot only or with uboot.

Questions:

1. Will I miss any important features if I went with cboot only? ( I don't really have a need to use any advance tools in uboot)
2. Which method is more stable with Mender? Eventually I will want to enable secure boot.

Thanks

[ichergui]

Hey @dat-tran-matternet

1. I don't think that you will miss any important feature when using cboot
2. I believe that using cboot only is the right choice to go with for OTA updates
   Please try it and let us know if you will face any issue

[madisongh]

Does that error cause the mender client to fail? For the cboot platforms, we provide stripped-down implementations of the fw_printenv and fw_setenv commands (via the libubootenv-fake recipe), and that message looks like it's coming from there. The canary check is done by the mender client to ensure that the u-boot configuration is correct, and if that variable doesn't exist, that shouldn't cause a failure. If it's behaving differently with 3.1.x versions, we may need to adjust the libubootenv-fake implementation to accommodate.

[dat-tran-matternet]

It doesn't fail. It doesn't seem to affect it. (in v3.1.0)

I'll verify 2.6.1 on my custom image and report back. I suspect it will not have the error in 2.6.1.

I noticed mender client 3.2.1 is also released. I'll try that version as well.

[dat-tran-matternet]

Update: mender 2.6.1 doesn't have the mender_check_saveenv_canary error. Seems like it's something new with version 3+; tested with 3.1.0 and 3.2.1

Here is the mender source code comments related to the new variable:

// If "mender_check_saveenv_canary=1" exists in the environment, check that
// "mender_saveenv_canary=1" also does. This is a way to verify that U-Boot has
// successfully written to the environment and that the user space tools can
// read it. Only the former variable will preexist in the default environment
// and then U-Boot will write the latter during the boot process.

[ichergui]

Thanks @dat-tran-matternet for the updates
I will take a look then will give you feedback

[dat-tran-matternet]

Thanks @dat-tran-matternet for the updates I will take a look then will give you feedback

Thanks for your support. I also noticed using the tegra-demo-distro (dunfell branch) the following issues with mender:

1. After a "mender install" and reboot, then a reboot WITHOUT "mender commit":
   Expected behavior: Mender to automatically roll back to the original rootfs because I didn't run "mender commit"
   Actual behavior: New partition is still active no matter how many times I reboot

2. After a "mender install" and reboot, then "mender rollback":
   Expected behavior: Mender to rollback to original rootfs after a reboot
   Actual behaviro: Mender states that it will roll back to original rootfs but new partition is still active after a reboot

Setup:

Project: tegra-demo-distro
Branch: dunfell (dc1dd889fce7d3fa04975a862aba19474892fb4e)
Machine: jetson-xavier-nx-devkit-tx2-nx
Image: demo-image-base
Mender-client: v2.6.1 and v3.2.1

Thanks

[madisongh]

The main reason we switched to cboot-only for the Mender builds in tegra-demo-distro is that with u-boot in the boot chain, you can end up with mismatches between u-boot and cboot as to which of the A/B slots should be used. It was too easy for the two bootloaders to get out of sync, and too difficult to come up with a definitive fix for that issue.

Eliminating u-boot also helps reduce the work in getting your secure boot chain in place, since you then only need to worry about signing the NVIDIA bootloaders and your kernel. With u-boot in the mix, cboot loads u-boot, and then you have to implement an additional link in your chain of trust in u-boot as well.

[dat-tran-matternet]

Thanks that make sense.

Is this true for all Jetson variants, specifically TX2 NX? I noticed in the tegra mender demo it uses UBoot if building for TX2 COT. Also what does COT stand for? Thanks

# Use u-boot by default on the TX2 COT when using the FIT image
PREFERRED_PROVIDER_virtual/bootloader_jetson-tx2-devkit-cot = "u-boot-tegra"

[madisongh]

That's an extra machine configuration set up as an example for how to implement FIT images. @ichergui can tell you more about it, but it doesn't get regular testing in the distro.

[ichergui]

@dat-tran-matternet Let me know if you have any question about TX2 COT