Early boot debugging

Autonomous Machines Jetson & Embedded Systems Jetson AGX Xavier
1

Hi,
We currently have a Jetson AGX industrial we’re using with a Diamond systems Stevie board. Our goal is to program this board with a Linux distro we created using the meta-tegra project.

We’re currently having issues with the board coming out of reset after being programmed with the meta-tegra tools. We’re not seeing anything on the console or serial ports.

I’ve seen various posts about enabling some debug output for the MB1 bootloader; so far looking at the value for odmdata (0x9190000) passed into tegraflash_internal.py, it seems the enable-debug-console, so we should be seeing some output.

We can successfully program this configuration with the nvidia tooling + nvidia reference distribution, so we’re debugging some issue with the open embedded tools, and having as much insight as to what is happening during the early boot process will be very helpful.

2

Hi,

I don’t know much about the board you are using. Does it ever output anything from the serial console port?

Is your BSP still the default Jetpack or you have modified a lot?

3

Hi Wayne,
Not seeing any output from serial console, the total silence leads to me to believe we’re having a failure early in the process. The Linux for Tegra Jetpack works just fine.

We created our own Linux distro and that worked fine for the non-industrial Jetson with the Stevie board.

4

The Linux for Tegra Jetpack works just fine.

Where is this BSP installed ? Also on your board? Or you are talking about something else?
Any log to share here?

I don’t think you need to enable anything to make serial console to dump log. Default BSP shall all enable them.

It is also weird that you disabled it accidentally in past and don’t know how to enable again now (if that is the case).

5

I read part of the manual for that board and it looks like the manufacturer provides their own software, but the flash command is the same (my guess is that it has a different device tree). They use the maxn model.

The manufacturer may have also provided boot content (and even Linux stage content) which does not enable the serial console. What do you see, when booted, for the following:

cat /proc/cmdline
cat /proc/device-tree/chosen/bootargs
grep APPEND /boot/extlinux/extlinux.conf
head -n 1 /etc/nv_tegra_release
6

It is also weird that you disabled it accidentally in past and don’t know how to enable again now (if that is the case).

I’m working with several boards to interface with the Jetson, one from Seeeed Studios and the other from Diamond systems. I think we have an interface board from nvidia, I will be trying that one. The Diamond and Seeed studio boards do not have the USB-A port that should be on the nvidia board. The only serial output I can get is the console from Linux (TCU0, iirc) and I’ve not been able to get the output from the early bootloader in any case. Is there a config parameter where some of the buffer can be left in ram or redirected to a different port?

As far as booting, on the Seeeed board, the nvidia programming works, but it seems to be booting into the initramfs and then going into some sort of recovery. During the nvidia programming, it looks like it builds the initramfs from the rootfs directory, so I made some changes there to get the board to start running /bin/bash so I could get a console and have a look. I think I will need to make a few more changes (being deprived of less and vi, for example, makes looking at logs difficult) to have something useful.

I can’t seem to get the system to stop at the uefi bootloader. Most uefi bootloaders have a method for booting the system from the network or sdcard, that would be helpful to me in debugging as well.

7

Could you share what is the exact “early bootloader” log you want to see and what is the log you have now?

I just don’t get your definition of “early bootloader log”.

Mostly likely because the custom board you are using is a pure usb port. But the micro usb port on devkit actually is not a true usb port…

8

I just don’t get your definition of “early bootloader log”.

I’m interested in seeing the output from mb1 bootloader. I think the system boot is micro-code → mb1 → cboot (uefi) → kernel. Or at least this is what I’ve read/observed about the Jetson boot process.

During my testing, I saw that the uefi bootloader started a recovery boot. Do you know what triggers the uefi bootloader to perform a recovery boot opposed to presenting the menu in /boot/extlinux/extlinux.conf?

9

Hi,

Could we just focus on your original question? We only check one issue in one topic.

For your original question, please make sure you are using the UART port on each carrier board instead of the usb port to dump log.

For recovery boot question, please file a new topic for it.

10

For your original question, please make sure you are using the UART port on each carrier board instead of the usb port to dump log.

OK, I will do that.

11

Just a reminder, the micor usb port on NV AGX Xavier devkit is not a real usb port. It is a uart port with usb-ttl adapter installed. So actually none of the early boot log is from usb port.

12

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.