Boot into unknow dtb after power off

Basic Info:

hardware: jetson-agx-orin-devkit
JetPack : 6.2
Jetson Linux : 36.4.3

Issue:

It seems like the system boot up using a dtb which is not the uefi_dtb after power off

  1. I modify the dts
  2. compile and flash to board
  3. boot into system to check that I modify is correct, after flash to board which is as expect
  4. reboot system with command reboot in shell
  5. reboot into the system again and check the modification is also correct as expect
  6. poweroff the board with command poweroff or just shutdown the power supply plug
  7. power up the board, bootup the system and check the modification, which is something wired, the dtb is roll back to something old dtb? which I don’t konw where it load from?

i check the bootup console log which is direct boot, and also reset all the setting in L4T Launch, and test , which is also failed

Any way I to debug this problem?

Maybe you could try to share the full log and full dts from /proc/device-tree.

And make sure you are booting from the the medium you want to use.

log.txt (362.3 KB)
what i modify the dts: is remove the typec

the log.txt contain two boot log , first boot after the step 3, after flash, there is no typec error, which is as expect

the second boot up log is step 6, claim the typec probe error, which mean the dtb is not as expected

export the two dts from system, which as what I though, the err dtb is enable the typec

ok.dts.txt (399.9 KB)

err.dts.txt (400.7 KB)

question is , where is the dtb load from? after poweroff

Do you have other boot medium in use on your board?

Nope, only emmc

Hi,

How did you flash your dtb there?

The problem here is in your first boot, you are booting from partition A.

I> Partition name: A_cpu-bootloader
I> Size of partition: 3670016
I> Binary@ device:3/0 block-24832 (partition size: 0x380000), name: A_cpu-bootloader

But your 2nd boot is from partition B.

I> Partition name: B_cpu-bootloader
I> Size of partition: 3670016
I> Binary@ device:3/0 block-87808 (partition size: 0x380000), name: B_cpu-bootloader

I only flash the partition A,

so, why is that the boot second time boot from partition B? Any way to config it?

Hi,

Want to clarify. Does this issue happen in every boot on your side or it will only happen after you boot up multiple times?

I found this issue today afternoon, the day before it works fine for me

and now it happen every boot time after the hardware reset or poweroff

Does it always boot from slot B now and never go back to slot A?

according to the current status, it seems Yes, it always boot from the slot B, only Boot from slot A after the flash
./flash .. A-cpu_bootloadr …

please follow this and dump

nvbootctrl dump-slots-info

Yes , as the console log show, the current slot is 1, and the dump slot is also 1, so it’s bootup from partition B

Current version: 36.4.3
Capsule update status: 0
Current bootloader slot: B
Active bootloader slot: B
num_slots: 2
slot: 0, status: normal
slot: 1, status: normal

though, currently I modify the boot slot back to 0 it can boot from partition A

but ,still don’t know what’s the reason cause this issue happen?

saw this from your log

I> Task: Bootchain failure check
I> Current Boot-Chain Slot: 0
I> BR-BCT Boot-Chain is 1, and status is 0. Set UPDATE_BRBCT bit to 0

Could you do a experiment to confirm this behavior would repeat if you flash partition A or not?

After I manually correct the slot, the issue is not happen again, and the console log show is correct

Current Boot-Chain Slot: 0
BR-BCT Boot-Chain is 0, and status is 1. Set UPDATE_BRBCT bit to 0

Am I need to manually switch to slot 1 and flash slot 0 again?

What I guess now is, the issue is happen while the bootloader not autoupdate the slot

I dont ‘t do any flash, just remove the AGX orin module from the carrier board, and do some hardware modification on my carrier board, and reinstall the module on my carrier board, the issue happen again, just like the issue happen this time, the first time it happen is also happen after modify carrier board, but as i can tell now, the hardware modify on my carrier may not related to the core module bootup

I notice that, this bootup time tasks too long than before

I see something different in log file(maybe related to dpkg-reconfigure nvidia-l4t-bootloader)

the command above will toggle the boot slot? but I only run this command this this time

Enter to continue boot.

Update Progress - 5% **++++++++++++++++++++++++++++++++++++++++++++++++Update Progress -
6% ***+++++++++++++++++++++++++++++++++++++++++++++++Update Progress - 7% ***+++++++++++++++++++++++++++++++++++++++++++++++Update
Progress - 8% ****++++++++++++++++++++++++++++++++++++++++++++++Update Progress - 9% ****++++++++++++++++++++++++++++++++++++++++++++++
Update Progress - 10% *****+++++++++++++++++++++++++++++++++++++++++++++Update Progress -
11% *****+++++++++++++++++++++++++++++++++++++++++++++Update Progress - 12% ******++++++++++++++++++++++++++++++++++++++++++++Update
Progress - 13% ******++++++++++++++++++++++++++++++++++++++++++++Update Progress - 14% *******+++++++++++++++++++++++++++++++++++++++++++
Update Progress - 15% *******+++++++++++++++++++++++++++++++++++++++++++Update Progress -
16% ********++++++++++++++++++++++++++++++++++++++++++Update Progress - 17% ********++++++++++++++++++++++++++++++++++++++++++Update
Progress - 18% *********+++++++++++++++++++++++++++++++++++++++++Update Progress - 19% *********+++++++++++++++++++++++++++++++++++++++++
Update Progress - 20% **********++++++++++++++++++++++++++++++++++++++++Update Progress -
65% ********************************++++++++++++++++++Update Progress - 66% *********************************+++++++++++++++++Update
Progress - 67% *********************************+++++++++++++++++Update Progress - 68% **********************************++++++++++++++++
Update Progress - 69% **********************************++++++++++++++++Update Progress -
70% ***********************************+++++++++++++++Update Progress - 71% ***********************************+++++++++++++++Update
Progress - 72% ************************************++++++++++++++Update Progress - 95% ***********************************************+++
Update Progress - 100% **************************************************???Shutdown state requested 1
Rebooting system …

see the last time bootup log in the attach file

remove-from-carrierboard.txt (1.3 MB)

If you didn’t trigger the update by yourself (apt-get upgrade will trigger that), then you could try these.

You can try to disable both packagekit.service and anacron.timer as following to prevent auto update.
$ sudo systemctl stop packagekit.service
$ sudo systemctl disable packagekit.service
$ sudo systemctl stop anacron.timer
$ sudo systemctl disable anacron.timer
If you want to configure them in BSP package before flash, please remove them from rootfs as following.
$ sudo rm <Linux_for_Tegra>/rootfs/lib/systemd/system/packagekit.service
$ sudo ln -s /dev/null <Linux_for_Tegra>/rootfs/lib/systemd/system/packagekit.service
$ sudo rm <Linux_for_Tegra>/rootfs/lib/systemd/system/anacron.timer
$ sudo ln -s /dev/null <Linux_for_Tegra>/rootfs/lib/systemd/system/anacron.timer

The second this issue happen, I do manually trigger the reconfigure

But the First time I don’t do that, and see no “Update Progress” in console log

So “dpkg-reconfigure nvidia-l4t-bootloader” this can lead to toogle the slot? I will test that out later

You have to realize that nvidia-l4t-bootloader wont’ know what customization you ever did on your side.

It just does one thing to reinstall every bootloader components from default NVIDIA package.