Booting With Custom Carrier Board

Hi,

I am designing a custom carrier board for jetson nano module.
Currently I cannot boot up but I can get the log from the UART debug and see it keeps on restarting.
I already make sure the 5V to jetson nano and the PW_EN is stable.
While I’m inspecting the log difference between the jetson nano development kit and my customer carrier board I found there are some differences.
" pmic max77620 NVERC : 0x40
[0000.152] RamCode = 2
[0000.154] Platform has DDR4 type RAM"
The log from normal jetson nano developer kit board is RamCode=0.

I am also confused to find that the jetson nano have A02 and B01, and I also find information saying the jetson nano developer kit board is different with the jetson nano production module. Currently, I have the jetson nano developer kit and remove the SOM and put it into my custom carrier board.

I want to know whether the above is true and if I am following the schematic from DLC, which pinout it is referring to?
If I buy the new version which is B01 is it the same with Jetson Xavier pinout and the same with the carrier board schematic provided from DLC?

nano_board.log (19.1 KB)

Custom design should follow B01 docs in DLC. Devkit with A02 module is for development only and is not compatible to B01 carrier board. That might be the cause of ramcode error.

Hi,

Ok understood.
Right now I am buying the B01 modules so it works with my carrier board.
My question is the B01 have the development kit with SD card, can I remove the B1 module with SD card and move it to my carier board?
OR to use my carier board I need to use B1 modules with eMMC and cannot use B01 development kit?
Also for flashing the B01 modules, what connection I should use for if my custom carier board does not pinout usb? can I use the ethernet or uart debug?
As for Sd card image provided in DLC, can I flash it to B01 devkit and remove the module and move it to my carrier board?

It depends on your carrier board. If your design follow OEM DG well and has no problem, it should be able to work with B01 module on the devkit.

Only USB port is available for flashing.

Hey Trumany,

Thanks for your help.
We already managed to put B01 both the production modules and from the development kit.

But | have another question, as for the usb port for flashing, after the flashing can this usb port be used for normal usb operation? or how can I modify something to use this port?

Sure, it is normal USB port, no need to modify anything.

Are you certain about that?
Currently in my carrier board I have 2 usb to uart connection to USB0 and USB1.
I have 2 identical carrier board and both can detect the usb to uart connection only in USB1 not USB0.

I also try to use the developement kit B01 and try to connect The Micro USB port connected it double ended Type-A connection and externally powered it to the 5V and connect it to USB-Uart and still cannot detect it.
Is there anything I miss?

USB0 is device only, maybe your device need USB port to be host, right? USB0 does not support that.

Hi,

The original design of devkit only enables usb0 as device mode because the ID pin is floating. Thus, the device tree only writes it in device mode too. If your carrier board has enabled the otg function, you need to follow the Nano adaptation guide to modify the device tree to enable host mode.

Hi Wayne and Trumany,

Yes I want the USB0 as host.
I saw the Nano adaptation guide about modifying the device tree.
But It is not clear to me where is the device tree is located and how to modify it?
Is it in some directory when we are in the jetson nano file directory system or we modify it in host system when it creates an images and then flash it using SDK manager?

You need to download the device tree code from our dlc and follow the instructions in l4t developer guide to build it.

After you have a new dtb, you need to put it under somewhere_on_you_host/Linux_for_TEGRA/kernel/dtb.
This folder is installed by sdkmanager so I cannot tell what is the correct path, but you should find it.

Hey Wayne,

Thank you very much for your reply.
I found the …/kernel/dtb.
I follow a source that use this steps, please confirm it whether it is correct:

  1. Download toolchain Linaro 7.3.1 2018.05 toolchain for L4T 32.3
  2. Download kernel sources from ttps://developer.download.nvidia.com/embedded/L4T/r32-3-1_Release_v1.0/Sources/T210/public_sources.tbz2
  3. Modify the device tree code following the platform adaptation guide
  4. compile the kernel and dtb
  5. Replace the kernel/dtb from the folder installed by sdkmanager with the compiled dtb from kernel sources
  6. flash the new image with sdk manager

I will try this in few hours.
Meanwhile, I am wondering after we change usb0 to host mode, will we able to flash it again? as in when we put the jumper to force recivery mode it will change the usb0 back to device mode?

Hi,

1. Download toolchain Linaro 7.3.1 2018.05 toolchain for L4T 32.3
2. Download kernel sources from ttps://developer.download.nvidia.com/embedded/L4T/r32-3-1_Release_v1.0/Sources/T210/public_sources.tbz2
3. Modify the device tree code following the platform adaptation guide
4. compile the kernel and dtb
5. Replace the kernel/dtb from the folder installed by sdkmanager with the compiled dtb from kernel sources
6. flash the new image with sdk manager

Your work will not need to reflash the kernel driver but only the dtb. These two are different.

And you are not going to use “sdkmanager” anymore. You have to use the flash.sh script under the Linux_for_Tegra folder to do this work. Because sdk would try to download it again when you click the button, such behavior will overwrite everything you have updated.

Meanwhile, I am wondering after we change usb0 to host mode, will we able to flash it again? as in when we put the jumper to force recivery mode it will change the usb0 back to device mode?

The recovery mode has nothing to do with the change you are working on now. RCM mode does not depend on kernel. It is triggered by hardware.

You could think of such scenario… When developing kernel, it is very easy to get system hang or some kernel error which would cause system not able to boot up. If RCM mode depends on kernel, then the device would become brick very easily.

1 Like

Hi Wayne Trumany,

Thank you very much for your help, now we are able to use USB0 as host as well.
Appreciate your help and happy from the support of NVIDIA.