nvbootctrl fails to select boot chain

[khschneider]

Hi,

I'm developing on an Jetson AGX Xavier using latest Kirkstone branch.
It is running on an Auvidea X221 Baseboard so I have created a custom machine reusing mostly everything from jetson-agx-xavier-devkit. It is called jetson-agx-xavier-x221.

Now I want to get some sort of firmware update mechanism working. Mender doesn't compile, so I decided to give the Nvidia tools a try.

First thing I did try is to switch boot chain from A -> B and back. nvbootctrl tool fails to set the corresponding EFI-Variable due to read only mounted:

root@jetson-agx-xavier-x221:~# nvbootctrl set-active-boot-slot 1
Error: open fail errno = 30 reason = Read-only file system 
Error: write variable BootChainFwNext failed!

If I make /sys/firmware/efi/efivars writable and execute the command again, the Kernel crashes with a Kernel Panic!

Thinking that this is maybe related to my customization I tried the procedure with jetston-agx-xavier-devkit. Say what: nvbootctrl succeeded. After digging around I found that /etc/nv_boot_control.conf differs. When I copy the file from jetson-agx-xavier-devkit image to my custom one, nvbootctrl works again.

nvbootctrl seems to expect the string jetson-agx-xavier-devkit somewhere in nv_boot_control.conf. If found it modifies EFI variables via esp partition. If not, it accesses /sys/firmware/efi/efivars.

Did I messed something up or is this wrong behaviour of the Kernel and/or nvbootctrl?

[madisongh]

It wouldn't surprise me if nvbootctrl has some hard-coded device names in it to decide on whether or not it's using eMMC only (try running strings and grep on that binary, you'll see them).

IMHO, it's premature to even attempt full-image OTA updates at this point, at least for any sort of production use case. The bootloader updates in particular don't appear to be implemented in a fail-safe way. Also, there is just one ESP partition, so that, too, can't safely be field-updated.

You could try doing rootfs-only updates, and enable extlinux.conf support to cover the kernel. To work around the nvbootctrl problem, you could try adding a bbappend for the setup-nv-boot-control recipe to put jetson-agx-xavier-devkit in the TNSPEC that the script generates instead of the default (${MACHINE}).

[khschneider]

Yes I did run strings on nvbootctrl and it showed me all the device names wit *-devkit.
In fact, nvbootctrl doesn't seem to work at all, what makes it pretty useless.

What I see is, provided nvbootctrl succeeds, the boot chain is switched sometimes.

• Boot from slot A
• Switch to B using nvbootctrl
• Power-Cycle (reboot actually doesn't work, due to some problem with the base board, not specific to meta-tegra)
• UEFI may recognize the request to change boot chain and issue a reboot, mostly it simply doesn't

Haven't found any pattern what makes it work or not :-(

[dwalkes]

See related discussion in thread at OE4T/tegra-demo-distro#231

[khschneider]

Tanks to pointing me there