Jetson Nano custom board not booting up

Autonomous Machines Jetson & Embedded Systems Jetson Nano
,
26

@WayneWWW you mentioned an earlier version of bootloader.

Does this statement in the log confirm it?
64NOTICE: BL31: v1.3(release):0a5b424
NOTICE: BL31: Built : 02:17:39, Jun 5 2019

27

sudo ./flash.sh jetson-nano-emmc mmcblk0p1

I have also used to specify the dtb file:
sudo ./flash.sh -d jetson-nano-emmc mmcblk0p1

28

sudo ./flash.sh -d jetson-nano-emmc mmcblk0p1

I am not sure if this would work. Don’t recommend to use this command.

Flash.sh is like a script that has been in use since tk1 era, those parameters you see inside it are not always working. Just put the dtb to Linux_for_Tegra/kernel/dtb and do the full flash.

As for the bootloader version, what I need to check is like below one. This is from my rel-32.5.1 jetson nano.

[0000.125] [L4T TegraBoot] (version 00.00.2018.01-l4t-e82258de)

Just be smart, you can try to check that on devkit. No need to always use your board to check.

But anyway, if you don’t want to check the version, you can just try rel-32.2 or rel-32.3.1. Even if you identify the bootloader version, what you can do is still flash those old jetpack release.

29

I this some part of the command was not sent
 not sure why
-d path_to_dtb_file is what it should be.

I will keep your advice in mind and not use it in the future

I am in the process of flashing 32.3.1.
I will update you on the L4T TegraBoot as well

30

hello shravya.boggarapu1,

what’s the flash configuration you’re using, if your board schematic differs from that for Jetson Nano Developer Kit carrier board, you must change the pinmux configuration applied by the software.

31

@WayneWWW

For our logs, bootloader version is as follows:
[0000.270] [L4T TegraBoot] (version 00.00.2018.01-l4t-e82258de)

32

Hi,

We have designed the board such that all the electrical connections are the same as dev-kit b01. We only disabled peripherals we don’t need. We checked all the pins in the pinmux spreadsheet. They are the same as what we have on our custom board.
Do we need to change the pinmux even if it is just about disabling the peripherals?

Also, currently we first need to know what is happening at boot time, so we need to get the logs from the serial console. Irrespective of pinmux changes, we should be able to see some logs, even if it a failed boot.

Please let us know if our understanding is wrong and guide us to how we can get boot logs through serial console.

33

I am not quite sure what is going on here.

If this value “e82258de” is from your “empty SOM”, it means the bootloader on the “empty SOM” is also rel-32.5.1 bootloader.

It means there is no software diff between the “empty SOM” in bootloader before and after you flash the sdkm.

34

Yes, that is why we are confused as to why we are not getting any messages at boot time.

Although to be fair, we think it may have something to do with HDMI not being present on custom carrier board or something to do with when the serial console is activated. Like, there is a failure before the point from where the logs are sent

35

Just want to know, did you ever use the devkit to dump the uart log before?

36

Yes.

UART serial logging works on devkit. We sent the bootloader version through the same

37

Is it possible to remove the FTDI232 on the uart pin to check if it is the cause of this issue?

38

It is definitely not.

Instead of using a TTL cable on devkit, we have used the same FTDI232 chip (attached externally) to convert signal of UART2_TXD, UART2_RXD pins from 3.3V to 5V on the devkit too. That works without issue. Drivers are also not a problem. We have checked that too.

Also, FTDI chip on custom board sends logs to the host PC when “empty SOM” is placed.

In fact, even though boot logs are not seen through a flashed SOM placed on custom board, it is properly identified as an FTDI chip on the host PC

42

Hi @vindhya.devalla ,

Just want to double confirm, where did you run this command? I mean where is your driver package coming from? SDKM? or you prepare it manually?

sudo ./flash.sh jetson-nano-emmc mmcblk0p1

43

We did both but generally we do it manually.

44

Can you try that one from sdkm again to avoid any possible mistake?

45

we have done a standard flashing through SDKM. We don’t get the logs from that either.

49

HI @vindhya.devalla ,

Is it possible to share your schematic ,especially the UART part ?

Also, I want to summarize this topic so far, please help check if what I understand is correct.

  1. A fresh out-of-box nano module, plug into your custom board and uart is able to print log

  2. Same module, flash with sdkm/jetpack on devkit (since your board has no flash port), move to custom board again, and it fails to output UART.

  3. Use the devkit to check what is exactly the tegraboot signature on the module after (2), and it said e82258de.

I am not quite sure what is the signature in (3) coming from, is it the “factory image” version or it is after you flashed with sdkm?

52

HI Wayne, I think there was a mistake on our end. We misunderstood what logs you asked from dev-kit.

You are right that it was not the empty SOM. It was a flashed SOM. We assumed the bootloader version is independent of L4T version.

When placing the SOM with the “factory image” on the dev-kit, the L4T version is as follows:
[0000.171] [TegraBoot] (version 00.00.2018.01-l4t-4138149d)

After flashing SDKM:
[0000.270] [L4T TegraBoot] (version 00.00.2018.01-l4t-e82258de)

Full log:
empty_som_devkit.txt (61.6 KB)

53

Hi,

Please also share the schematic if possible.