I’d like to know how it is possible to read out the current bootloader version from the userland. I’d rather not install a bootloader every time I install an update, but only when it is necessary.
Hi seeky15,
What is the userland meaning? Do you mean the command in “userspace” to read bootloader version?
You could read the current Jetson release on your board with the following command
$ cat /etc/nv_tegra_release
Or just check the dmesg.
Yes, userland userspace, same thing.
Do you mean the command in “userspace” to read bootloader version?
→ YES
We’ve got a version of the bootloader in the /dev/mtd0
The access to /dev/mtd0 has been restricted. I’d like to read anywhere on the system what the current version of the bootloader is. Like that I can decide if I need to perform a bootloader update. I don’t want to overwrite the bootloader with the same version again.
Imagine me using A/B with 2x 5.0.2 bootloader and rootfs on it.
Now the rootfs and the bootloader changed, so both needs to be upgraded.
I update the bootloader on slot B and the rootfs on slot B to 5.1. Then we have 5.0.2 on A and 5.1 on B.
Now when I do the same again both A/B have the 5.1 version.
Since we change other parts of the rootfs than the L4T version, there are multiple different 5.1 releases we can install, with our own data. When I update from 5.1 to another 5.1 version now I’d like to detect that the 5.1 bootloader is already installed. Then the bootloader update should be skipped. For that to work, I’ll need to read the current bootloader version. I have not found a method to do this so far.
The nv_tegra_release is just a file with the version of the L4T, that will not help me as the rootfs is independent from the bootloader. dmesg does not show the bootloader version either. I can see it being logged on the serial output, but have not found any way to read it programatically from a running system.
How can we read the version?
Sorry, we don’t have userspace command to read bootloader version.
You could only read the hash info in the serial console log of boot up.
Is it possible to read the serial console log if I am not connected via serial? The update won’t be happening with serial attached. If I could read it after boot that would work too.
The log would be stored in /var/log/syslog, but I don’t think the log of bootloader would be here due to kernel not ready at that moment.
Okay that’s unfortunate…
Is the update process for the bootloader clever enough to detect that the update has already been performed?
I don’t want to expose us of any additional risk by updating something over and over again, without any real use.
Maybe there is a way to distinguish the efi versions using the efi variables? I know that the RootFsInfo was available in 5.0.2 but not in 5.1, so I can detect that difference there. Maybe one of the variables includes a build date or uefi version?
Just like the message in serial console log when boot up like the following
Jetson UEFI firmware (version 2.1-22e2cf3 built on 2023-01-15T14:07:59+00:00)
edk2/PrePi.c at main-edk2-stable202208 · NVIDIA/edk2 · GitHub
Yeah, I have seen that, but as you already pointed out I can only see it on the screen. It is not logged since no partitions are mounted or kernel is loaded when that happens.
Is the update process for the bootloader clever enough to detect that the update has already been performed?
It would still update the bootloader if you are using capsule update.
Thats quite bad. Can you please consult with the team if they can think of a way to read the bootloader version?
@seeky15 If you can get access to /dev/mtd0 (discussion here: Accessing Orin NX QSPI flash in Linux - #16 by Ursula) then you should be able to do this sort of thing… it’s not a pretty approach, and I wish nVidia would sort this out properly, but it’s at least something and might get you somewhere:
# strings /dev/mtd0 | grep 0.0.0.0-t234
0.0.0.0-t234-54845784-a9c0116a
0.0.0.0-t234-54845784-825d50f6
0.0.0.0-t234-54845784-a9c0116a
0.0.0.0-t234-54845784-825d50f6
@seeky15 Also, the UEFI version details are available from the kernel. Take a look at /sys/devices/virtual/dmi/id/bios_* which may help you out.
2 Likes
Hey @Ursula
the /dev/mtd0 has been restricted. But yeah with dmi, I can read a Bios build date and a version, that should be sufficient to decice if an installation is required.
Unfortunately that’s only available after installation. I had hoped that I could update the bootloader before the rootfs to prevent some unforeseen issues…
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.