Issues with initial setup on custom carrier board

I have a custom carrier for the Jetson Nano. I’m trying to evaluate that it works with my Jetson Nano (from the dev kit I was using) before we spin more boards, get non-dev kit Nanos, etc.

I’m having issues when I boot using the standard SD card image. Warnings about i2c accessing address 0x50 show on the serial console.

My custom carrier does not have HDMI output/etc.

I installed Nvidia sdkmanager, and then https://github.com/jtagxhub/jetpack-agx-build and ran a kernel build. However, none of the items from the guides on Nvidia’s site seem to line up with the filesystems I have. For example, seeing where to modify the board name, which DTS files need editing, where the uboot source is, etc all are confusing to me.

Any help with a step-by-step pointer of what has to be done from ‘clean’ to a new SD card image to flash to it (I don’t have ethernet access to it when in the custom carrier, but can put it in the dev kit carrier again if needed) would be very much appreciated.

One of the i2c controllers uses 0x50 for the EDID data query from the HDMI DDC wire. Unless you have correctly disabled that i2c controller (and thus HDMI is not attempting to query missing hardware), then I would suspect this is the cause. I don’t know which device tree node this is off the top of my head, but anything disabling HDMI in the device tree would likely help.

Even with the SD card image on the device in the standard carrier board, boot happens with no EDID (I2C 0x50) warnings but no video ever appears on screen. Powering via DC, with jumper bridged, at 5V.

So, gave up on working off of that and rebuilt. However, during flash.sh run, via USB recovery port, when I get to “Writing partition APP with system.img”, I get nothing happening it seems. One run stopped at 3%, another run hung at 0%.

Any suggestions to debug or expectations for if we need to wait more than an hour?

The only warnings I see are things like:

  • Warning: no sdram params
  • Applet is not running on device. Continue with bootloader.

I have a 16GB SD card inserted. I expect that should be plenty but wanted to mention as well.

I have also now tried just flashing the uBoot by specifying LNX, and this hangs after it says it is running tegradevflash.

You won’t get video unless a valid true HDMI monitor is connected. If you use an adapter which does not pass through EDID, and which does not provide the EDID of a monitor with specs the Nano works with, then there will be no video.

An i2c error for the HDMI DDC wire has a few possibilities for showing an error. One is that if the device tree shows HDMI hardware is present, but no such hardware exists. Another would be if you have the correct hardware, but the device tree has not powered on the correct power rails.

There isn’t much more I know about to check for a custom board, but in the case of i2c errors related to HDMI, do check that only hardware which is present is enabled, and that any related power rails is correctly enabled or disabled.

By ‘check that only hardware which is present is enabled’, I presume you mean to set the relevant signals to undefined/unused in the device tree spreadsheet and update the dts? Is there anything else that has to be done, or anything to change in other files other than pinmux DTS?

The PINMUX spreadsheet can do the job. Sometimes people edit device trees directly though, and this tends to be what I do, but I only make edits and do not create carrier boards from scratch. The PINMUX spreadsheet is probably a better choice when designing a carrier board from scratch, and directly editing a device tree is probably simpler when making minor changes to an already known and working carrier board.

If you are directly editing a device tree, then you will see this in places where hardware is enabled:

status = "okay";

(if anything says “okay”, then the hardware and its power must be present)

In the adaptation and bring-up guide (and in the various documents at https://developer.nvidia.com/embedded/downloads#?tx=$product,jetson_nano) you will find references to both PINMUX and device tree, and the device tree is perhaps the more specific and direct way to edit what needs to be changed.

Anything which changes the dts and then compiles it into a dtb prior to flash will do the job.