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.
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:
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.
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?