we are working with a modified partition layout within 28.1.0 for TX2, for which i wrote an in-system updater, which by now is capable to update u-boot/kernel/dtb/rootfs. I implemented this by looking at what the flash.sh script does and use the provided tools to create the according images, which can be programmed in-system using raw writes / dd.
The missing parts are the closed source NVidia bootloaders MB1/MB2/CBoot in /dev/mmcblk0boot0, which are needed because of the Pinmux .cfg files linked to MB1. I don’t see how, with 28.1.0, MB1 could be updated in-system, as it seems to me that only an USB update via the flash.sh script is supported (where the MB1 image is prepared, USB downloaded and encrypted + programmed on the target).
Q1: Is it possible to realize an in-system update of the MB1/MB2/CBoot bootloaders within 28.1.0, considering a custom partition layout (only on the sdmmc_user device partition), and could you provide a detailed how-to including the necessary tools?
Q2: I thought that the .cfg Pin I/O settings are only relevant for the MB1/MB2/CBoot stages and afterwards the settings would anyway be overloaded by the u-boot/kernel .dtb. So i checked if the .cfg update is mandatory at all by disabling a GPIO only in the .cfg, but leaving it enabled in the kernel .dtb, and the result was that the function behind the GPIO wasn’t working anymore, which strongly points to that it is mandatory and my understanding was wrong. Can you explain to me why, is it because of pad voltages and why aren’t those reflected by the .dtb, from which the .cfg’s were generated? If the kernel .dtb settings would actually come through, the importance of the .cfg update could be reduced to something nice to have.
Btw, i found that meanwhile 28.2.1 has added new tools (nv_update_engine) for in-system updates of the bootloaders, and it was adjusted the full proper way using redundant partitions, which is nice to play safe, but hard to integrate it to our custom setup (modifications in sdmmc_boot and sdmmc_user + a new Linux_for_Tegra environment). I already started experimenting with it, and by now it is only working with the unmodified 28.2.1 Linux_for_Tegra cfg/u-boot/kernel/sample-rootfs, as soon as i exchange one part of it with our devel version, like u-boot, its failing (e. g. when trying to update MB2). I’m now starting to reverse engineer how i can get it to work, but i feel that it will be very time consuming and i would be happier with a positive answer for Q1.