UEFI Variables and A/B Slots

[elbbit01]

Hello everybody,
I see the topic is complex and more people are having trouble here, but I separate the question because it is specific.
Please somebody with deep understanding on the flashing process and UEFI Variable handling have a look until the observations in the end.

Some context:
I have a system with our own developed OS using your layer for a Jetson Xavier AGX.
I am using Kirkstone branch still with r35.2.1.
Since march I got working the A/B updates and everything with UEFI.
Now we are adapting the layers to an extended bsp based on Jetson Xavier AGX with some changes.
After my changes, everything works fine on my devices, but for others (flashed from a different computer) the A/B is deactivated.

Question:
I followed the answer I got here #1182 (comment) for activating A/B. As I said, it has been working and still works for me pretty good but, is there somewhere where I can read a documentation on why and how exactly are right now the EFI variables passed to UEFI? Why I can not read or even edit them like it is possible from the official ubuntu distro from nvidia?

Here is my patch, just in case you see something obvious that I dont:

diff --git a/Silicon/NVIDIA/Tegra/DeviceTree/L4TConfiguration.dts b/Silicon/NVIDIA/Tegra/DeviceTree/L4TConfiguration.dts
index 2c619e21..b254ae76 100644
--- a/Silicon/NVIDIA/Tegra/DeviceTree/L4TConfiguration.dts
+++ b/Silicon/NVIDIA/Tegra/DeviceTree/L4TConfiguration.dts
@@ -37,7 +37,7 @@
locked;
};
RootfsRedundancyLevel {
- data = [00 00 00 00];
+ data = [01 00 00 00];
runtime;
locked;
};

Observation:
Analyzing logs and differences, when I flash from my computer, a file called cvm.bin.9y4BU (the last part is random, but it is always 5 chars long) is generated at the folder where I flash. It is 0 bytes big but it is there. For every version of the OS I flashed from my computer.
On the flashing computer where the flashing works but the targets get no A/B activated (and just this is different, no error in the logs, no error in dmesg, nothing. The updates to the other partition succeed with rauc, but the bootloader is not booting from the other rootfs, obviously, because it is not activated) this file is not generated, all other are the same. This was also like that for previous versions of our OS where the flashing was working.

Question regarding the Observations:

• Do you know what is this file doing or meaning? It is most likely nothing related, but it is the only thing I found at the moment.

I know the whole case is tricky and a little bit deviated from where you can help, but may be you can help me with the questions so I can get with a solution.

I thank you in advance, even if you are only reading this and trying to understand, and I hope it is clear enough.

Regards,
Alvaro.

[kekiefer]

Starting at the top with your questions, you should be able to read EFI variables from the runtime. You can find them mounted in /sys/firmware/efi/evivars, and you can also interact with them using efivar, e.g.:

# efivar -p -n 781e084c-a330-417c-b678-38e696380cb9-RootfsRedundancyLevel
GUID: 781e084c-a330-417c-b678-38e696380cb9
Name: "RootfsRedundancyLevel"
Attributes:
	Non-Volatile
	Boot Service Access
	Runtime Service Access
Value:
00000000  01 00 00 00                                       |....            |

[elbbit01]

Thank you kekiefer,
I think I remember that after rebooting, this changes on the variables are somehow not staying. Am I right?
But testing this again I got to a new clue.
Of course on the non working devices, the 01 is not set, it is all 0s.

Observation:

• In attributes, I dont have Non-Volatile (in any of my devices but may be an important missconfiguration)
• If I export the Efivar content, edit it and import it, I get an error. I guess there is some kind of checksum.
• If I export the Eficar from the working device and import it to the "broken" one, it accepts it but the values are not changed (even after chattr -i)
  My expectation is to be able to change this variable and then after reboot may be is lost, something is odd here.

Thanks anyway, cos I was trying the whole time with dd and efivar tool is easier. I am not an expert on EFI so every help is nice.

Regards,
Alvaro.

[madisongh]

Analyzing logs and differences, when I flash from my computer, a file called cvm.bin.9y4BU (the last part is random, but it is always 5 chars long) is generated at the folder where I flash. It is 0 bytes big but it is there.

That's a temporary file, created in the helper script to hold the output of the CVM EEPROM. It should get cleaned up later in the script, unless the script exits early due to an error.

[elbbit01]

Hi guys,
thank you for the help. Apparently our devices were being released with a bootloader preflashed in SPI eeprom, and this has automatically prio over the one I was flashing in sdmmc. That is why I was seeing everything correctly flashed but still the behavior and the flags were wrong.
Choosing the proper memory xml layout fixed it.
I hope this hint might help other developers in the future.

Regards,
Alvaro.