Hi,
I have similar problem like here on Xavier AGX JP 5.0.2 L4T 35.1 on custom CarrierBoard.
But in my case UEFI boot error happens every 3 reboots and system can never boot again (boot log attached).
This issue does not reproduce on Xavier AGX devkit. I also have not managed to reproduce it on custom CarrierBoard with L4T 34.1.1.
log.txt (326.1 KB)
UPD: Just replaced 35.1 uefi_jetson.bin by 34.1.1 uefi_jetson.bin and seems the issue disappeared. Device continues to boot after multiple reboots despite of validating rootfs error.
Jetson UEFI firmware (version r34.1-975eef6 built on 2022-05-16T20:58:45-07:00)
Press ESCAPE for boot options ** WARNING: Test Key is used. **
......
ValidateRootfsStatus: Failed to get RootfsInfo variable: Not Found
Failed to validate rootfs status: Not Found
L4TLauncher: Attempting GRUB Boot
L4TLauncher: Attempting Direct Boot
EFI stub: Booting Linux Kernel...
EFI stub: Using DTB from configuration table
EFI stub: Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID device path
EFI stub: Exiting boot services and installing virtual address map...
��I/TC: Secondary CPU 1 initializing
I/TC: Secondary CPU 1 switching to normal world boot
I/TC: Secondary CPU 2 initializing
I/TC: Secondary CPU 2 switching to normal world boot
I/TC: Secondary CPU 3 initializing
I/TC: Secondary CPU 3 switching to normal world boot
I/TC: Secondary CPU 4 initializing
I/TC: Secondary CPU 4 switching to normal world boot
I/TC: Secondary CPU 5 initializing
I/TC: Secondary CPU 5 switching to normal world boot
I/TC: Secondary CPU 6 initializing
I/TC: Secondary CPU 6 switching to normal world boot
I/TC: Secondary CPU 7 initializing
I/TC: Secondary CPU 7 switching to normal world boot
��[ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x4e0f0040]
Please flash UEFI debug binary to your system and share the full log again.
You can get UEFI debug binary by build it from source.
Where is the source code of UEFI located for L4T 35.1?
please use the source from this link first.
Hi,
It looks like you can boot into sometimes but you will fail and then it got reboot, is that correct?
Did you remember to modify the cvb eeprom read size in the mb2 configuration since this is custom board?
BTW, your issue is totally different from that link you posted…
Also, was this carrier board ever working if flashed by jp4 release?
Also, was this carrier board ever working if flashed by jp4 release?
This carrier board works successfuly on all JP releases begining from JP 4.3. It even works on JP 5.0.1 L4T 34.1.1.
It looks like you can boot into sometimes but you will fail and then it got reboot, is that correct?
I can always boot successfully after flashing device. Then I reboot device manually by sudo reboot command. After 3 reboots boot fails.
Did you remember to modify the cvb eeprom read size in the mb2 configuration since this is custom board?
I tried to change eeprom.cvb_eeprom_read_size to 0 in tegra194-mb1-bct-misc-flash.cfg and tegra194-mb1-bct-misc-flash.cfg, but it did not help.
Is it correct? I can try to do it once again.
Hi,
Could you remove every peripherals on the device and boot up and see if issue is still there?
Just want to check what causes the kernel to auto reboot first.
Just want to check what causes the kernel to auto reboot first.
Kernel does not reboot automatically. I reboot it by sudo reboot command (please find it in last attached log).
user@tegra-ubuntu:~$ sudo reboot
[sudo] password for user:
Stopping Session 1 of user user.
Stopping Session c1 of user gdm.
Anyway I will remove as much peripheral as possible from carrier board.
Oh ok. Sorry that didn’t notice it.
Since this is custom board, could you also share how did you prepare the BSP to flash it? What did you change there?
I have managed to reproduce this issue on Xavier devkit with L4T 35.1 out-of-box. However I used custom rootfs.
The log and rootfs.tar.gz are attached.
rootfs.tar.gz (64.8 MB)
log_devkit.txt (444.3 KB)
What is the debug logic here?
You cannot just use devkit and some random steps to create a UEFI error and told me “hey I can reproduce this issue on devkit too”. Please elaborate what is the relationship between what you are doing with the custom board case
For example, what is that custom rootfs doing here? If you don’t use it but our official rootfs, will you still be able to hit this issue?
Also, it is actually making no sense if you just paste a 64MB rootfs to other people… Please at least tell us what is the difference between this rootfs and with our official rootfs…
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.