Jetson AGX Xavier DevKit won’t boot after reboot - UART log shows CVB EEPROM read failures / WDT / data abort

Robotics & Edge Computing Jetson Systems Jetson AGX Xavier
1

Hi NVIDIA team,

My Jetson AGX Xavier DevKit was working fine, but after a reboot it stopped booting. The monitor shows nothing and I can’t connect over the network. I connected UART and recorded the boot log (attached).

jetson-log.log (1.1 MB)

The device runs Jetson Linux (L4T) R35.6.3 on eMMC. /etc/nv_tegra_release - Release R35, Revision 6.3, Board t186ref, build date Fri Sep 19 21:57:54 UTC 2025. nvidia-l4t-core is 35.6.3-20250919144642. The power supply is the standard DevKit PSU.

The only change I made before the reboot was adding a systemctl --user service. After the reboot the board no longer boots.

Could you please:

  1. Please tell me, if possible in detail, what the log suggests is failing (what is the root cause)?

  2. Tell me the safe way to recover the device?

Thank you.

2

I see a lot of “command not found”, but they are not actual commands, they are fragments of the device tree as if it was corrupted and the device tree was becoming used as a command instead of as data for arguments to programs. I don’t know enough about this to be particularly useful, but I’m going to bet that you are going to want to clone just the root filesystem, and then reflash with that instead of installing a new rootfs. On the host PC it would give you a way to mount the raw partition on loopback to remove any customization here prior to that:

  • ~/.config/systemd/user/
  • ~/.local/share/systemd/user/

A typical command line clone of just the rootfs is like this:
sudo ./flash.sh -r -k APP -G my_backup.img jetson-agx-xavier-devkit mmcblk0p1

The above would produce raw clone my_backup.img.raw and my_backup.img (sparse). These are enormous files so it takes a long time and you need a lot of disk space prior to starting. The raw clone is the size of the entire partition, e.g., if your partition is 24 GB, then the file is that size. The sparse clone is the size of the content within the partition, so as the partition fills it approaches the size of the partition itself. If near full, then the space consumed is about twice the size of the partition. You don’t need the sparse version, which in theory is smaller, as both can be used for flash but only the raw partition can be loopback mounted and edited.

Command line flash can allow you to use an existing image, and so if you copy my_backup.img.raw to “Linux_for_Tegra/boot/system.img”, then this is the exact image which gets flashed. It takes a long time to copy that much data, and again you’d end up on the host PC with two files where each is the size of the full partition. If you use a copy then there is no fear of a failed flash or something going wrong, and although the correct flash command won’t alter system.img, an incorrect one will, and so it is safer to use a copy.

Your file “my_backup.img.raw” can be mounted on the host PC like this:

sudo mount -o loop ./my_backup.img.raw /mnt
cd /mnt
# ...you can now do things like:
cd home/someuser/.config/systemd/user/
ls
# ...do stuff...
cd
sudo umount /mnt
1 Like
3

As a result, I did not find the reason for nvidia’s strange behavior, but cloning allowed me not to lose data.
I will flash the system, so the branch can be considered resolved.

Thank you for your reply.