Jetson Nano production module does not boot on custom carrier board, but does so on auvidea's

Hi WayneWWW,

We finally managed to get the UART logs, for our custom carrier boards. Please find attached the logs for the booting and non-booting case.
UARTLogsNanoBooting (18.6 KB)
UARTLogsNanoNotBooting (18.9 KB)

It seems that for our non-booting case, we have a peculiar log:
We get a prompt for:

“Tegra210 (P3450-Porg) # MC: “

instead of

“switch to partitions #0”.

One more difference is that vdd_core voltage is set to 1125 mV in case of the booting Nano, but 1075 mV in case of the non-booting one. Is this something to worry about? Although for the non-booting case, we have also seen 1125mV being set as the vdd_core voltage, in some other logs that we have.

Can you please advice regarding this?

Hi WayneWWW,

Do you have an update on this yet?

hello jetson_user,

it looks you stuck at u-boot stage due to bad device.

U-Boot 2016.07-gd917e08cec (Jul 16 2019 - 16:52:59 -0700)

TEGRA210
Model: NVIDIA P3450-Porg
Board: NVIDIA P3450-PORG
DRAM:  4 GiB
MMC:   Tegra SD/MMC: 0, Tegra SD/MMC: 1
Using default environment

In:    serial
Out:   serial
Err:   serial
Net:   No ethernet found.
MMC: no card present
** Bad device mmc 1 **

could you please have summarize what’s the modification you had done,
since it’s a custom carrier board, did you fully check schematic to review the board design? had you also done pinmux customization.
in addition, what’s the release image you’re now using.

Hi JerryChang,

Did you mean the changes related to software or hardware? For software, I tried with Jetpack 4.2.1, and changed the command line argument, like adding console=ttyTHS1 and early_printk, as can be followed in our previous discussion: How to obtain UART logs on Jetson Nano production modules, over UART 2 - #10 by jetson_user. We also tried with Jetpack 4.6 and 4.5.1, and still the booting is stuck, for some of the Nanos. Of course, at this moment we are able to get the UART logs. And we have resumed with Jetpack 4.2.1, because our drivers are based on that.

For hardware, I will have to get back to you with the details.

The bad device message also appears for the booting case, in the logs: UARTLogsNanoBooting. So might this still be the issue?

Hi JerryChang,

We finally have the root cause known for (some of) the Nanos not being able to boot on our custom carrier boards. It seems there was noise on pin 238 (UART2-RX) which we had left unconnected. This caused the uboot to detect a BREAK signal, apparently. On applying a pull-down resistor on this pin, the Nanos are booting.

We need to change the circuit of course, but we were wondering if there was some easy way to ignore the detection of this signal in the u-boot source code, for now? We are using L4T_R32-2_public_sources. Also could you please let us know a good way to distribute this new u-boot binary in the field Nanos? Do we need to use the encryption method as we do for signing device tree binaries and updating some partition? If this is so, could we have details on that please?

Eagerly waiting for your reply. Thanks!

Hi JerryChang,

Do you by chance have an update on this issue yet?