Conditions for eks partition update from runtime?

[madisongh]

Conditions for eks partition update from runtime?

[madisongh]

There should still be an eks partition even if you don't have secure boot enabled. You can find out more about why it's having trouble locating the partition using strace (see here).

I made the addition of the other partitions in 6bacf26 to test the ability of completely reformatting and repopulating the entire eMMC in the installer image I'm using for the secureboot-enabled TX2. IIRC I ran into this same issue using nv_update_engine, so I switched to using my own tegra-bootloader-update tool for updates as well as the initial installation. There's probably a better solution that doesn't involve making changes to the BUP payloads that nv_update_engine can't handle.

(updated to add) Now I remember... nv_update_engine doesn't handle having blobs in the BUP payload for non-redundant partitions.

[kekiefer]

Thanks, that explains it. This turns off my big flashing red light for not being able to rewrite the flash during updates in the inevitable case NVIDIA decide to change up the entire flash layout in L4T (again).

I think it makes sense to put the tegra-boot-tools in meta-tegra, for the same reasons we moved tegra-bup-payload. I'd also like to be able to use tegra-bootinfo for other update mechanisms in the way it is used in testdistro.

As I'm looking at tegra-bootinfo, I'm also thinking the bootcountcheck service and the initrd-setup that calls it might be nice as well, to avoid duplicating all that, but that's starting to feel a little bit too specialized.

[madisongh]

This turns off my big flashing red light for not being able to rewrite the flash during updates in the inevitable case NVIDIA decide to change up the entire flash layout in L4T (again).

Yeah, this is tricky. I'm not sure I have it working for all cases... I did come up with an OTA upgrader to handle an update from R32.2.x to R32.3.1, and a slightly different method to handle my slightly-off R32.3.1 flash layout updating to the correct layout (which also works with R32.4.2) that didn't require a complete reformat of the flash. But the bootloader is very finicky in ways I'm not sure I fully understand yet.

I think it makes sense to put the tegra-boot-tools in meta-tegra

I'm open to this. The tools there could use some additional sprucing up in the code and the documentation, though.

[kekiefer]

Thanks for the input. I'll spend a little more time with tegra-boot-tools and send over any PRs that make sense.