Jetson Orin Nano :Bootloader question

I would like to know about the following two questions.

1.Does Jetson Orin nano perform CRC or Hash verification when loading kernel and device tree in UEFI?

2.In Jetson orin nano, do you run tests like BIST on bootloader to detect DDR memory defects?

Thanks

Hi kawabe-k,

Uefi secure boot and encryption is supported on kernel and kernel dtb.
You could refer to the following instruction for details.
Secure Boot — Jetson Linux Developer Guide documentation (nvidia.com)

Uefi supports for dram memory tests and will be available in the next release.

Hi KevinFFF,

Thank you for your answer.
Let me ask you one additional question.

Is there a simpler way to boot UFEI instead of Secure Boot?

For example, uboot allows mkimage header CRC verification (dcrc, hcrc).
Is the UEFI (non-secure default) normal boot equivalent?

Thanks

I haven’t solved this yet, so someone please help me.

Is there an easier way to verify kernel and kernel dtb in orin nano than secure boot?

I hope someone answers
Thanks

It seems the UEFI(non-secure default) would not verify the kernel image and dtb, it would load it directly.

May I know what’s your use case and purpose to do this?

Thank you for your answer.

The purpose is to ensure that if the kernel fails to load properly at boot time, it will not load the wrong data and boot halfway.

Let me ask you one additional question.
Is there a feature in UEFI for JetsonOrinNano that allows it to reboot using Watchdog?
The goal is for WatchDogtimer to reset and reboot if the Kernel does not boot due to some glitch.

Thanks

watchdog is default enabled in kernel.
You could find it from serial console log like the following.

[    1.539326] tegra_wdt_t18x 2190000.watchdog: Tegra WDT init timeout = 120 sec
[    1.546478] tegra_wdt_t18x 2190000.watchdog: Registered successfully

Thank you for your answer
Please let me check if my understanding is correct.

Is it correct to understand that UEFI does not have a function to start Watchdog, and that Watchdog is started immediately after the Linux kernel is booted?

Therefore, is it correct to understand that it is almost the same function as starting Watchdog in UEFI?

Thanks

Correct.

I’m not clear about what do you mean here.
There’s no watchdog in UEFI.

thank you for your reply

What is the kernel watch dog timer used for?

Kernel watchdog is not always enabled. It is a kernel feature, so it does not exist until the Linux kernel is loaded. What it does is to start a timer, and reads from a file in “/dev” when the timer expires (this is not a real file, it is the kernel driver/feature looking like it is a file for the purpose of allowing simplified read/write). If the file has not been updated, then it assumes some program which was supposed to write to it has failed. That program is the “heartbeat” of the kernel watchdog. If the timer is reached and the file has not been written to, then the system reboots.

So watchdog won’t help in boot stages, but the A/B redundancy is similar. Only the A/B doesn’t just reboot, it tries to switch from “A” content to “B” content.

1 Like

If you hit the kernel panic and get stuck for the period longer than 120s, it would trigger reset to help you exit that state.

Thank you for your reply.

Let me ask two additional questions.

1.“Uefi supports for dram memory tests and will be available in the next release.”
Does this refer to JetPack6 to be released in December?
How is the additional Dram memory test detected?

2.If you test DDR memory when shipping mass-produced modules, I would like to know the details of the shipping test.

It should be included in the next release of Jetpack 5.

What’s your use case for those details?
What kind of details would you like to know?

Thank you for your reply.

I understand that this will be included in the 5.1.3 release scheduled for December.
Could you tell me about the logic of the DDR test that will be added?
For example, write 0x55 to DDR memory and read it back to verify if the values match.

We would like to investigate the possibility of substituting outgoing inspection of DDR memory for outgoing inspection of products currently under development.

If DDR memory is tested for defect detection during shipping, I would like to know the logic and testing details.

Thanks

I’ve checked this with internal.

You could refer to the following header file.
https://github.com/NVIDIA/edk2-nvidia/blob/main/Silicon/NVIDIA/Include/Library/MemoryVerificationLib.h

Its implement is as following.
https://github.com/NVIDIA/edk2-nvidia/blob/main/Silicon/NVIDIA/Library/MemoryVerificationLib/MemoryVerificationLib.c

and it would be called in https://github.com/NVIDIA/edk2-nvidia/blob/main/Silicon/NVIDIA/Library/PlatformBootManagerLib/PlatformBm.c#L213

There’re several TestMode. Please just refer to the source for your use case.

Thank you for your information.