Jetson Nano + custom board, how to set them up?

Autonomous Machines Jetson & Embedded Systems Jetson Nano
,
1

Hi all,
My use case is that we have a custom PCB onto which the Jetson Nano (Production Module) would be plugged into as a controller/DSP. I am trying to follow the Platform Bring-up guide (Jetson Nano Platform Adaptation and Bring-Up.

I have a created the custom _pinmux.dtsi and _gpio-default.dtsi with the Excel Sheet tool. Do we need to rebuild the kernel AND the U-boot? How do I tell the kernel/bootloader to load my custom pinmux for the board? Apologies for this stupid question because I am very new to the process of board bring-up and setting the pinmuxes and stuff.

3

hello shubhamp,

your customize pinmux configuration should convert as *.dtsi files, please update the the device tree image, by re-flash the target device for the new pinmux configuration to be applied.
thanks

4

Hi Jerry,

There are a few gpios that appear to be hogged by some drivers or other entity.

 gpio-64  (                    |i2c-mux-gpio        ) out hi

Is there a way to find out and possibly release the control on this gpio (sysfs: 64, GPIOI0) so that my application can take over? Unfortunately this pin is connected to the chip_enable pin of an IC on the custom board and always stays high (I need to pull it low for “chip reset”).

Is rebuilding the device-tree the only way?

5

hello shubhamp,

you may review pinmux spreadsheets for the default pin configurations.
if you’re working with 40-pin expansion header, please refer to Configuring the 40-Pin Expansion Header, you may enable Jetson-IO python tool to simplify the configuration of the I/Os exposed by the 40‑pin expansion header.
thanks

6

Hi Jerry,

Thank you for the quick response. To explain my situation: I have 2 jetson-nano modules: 1 from the dev-kit and one is a separately bought-out p3448-0002 production module with EMMC. I am bringing up the software on the devkit-module but the production module has to be used in the final product.

I have been able to use the Jetson-IO python tool with the devkit-module and I am able to talk through SPI and PWMs, except for this problem:

For the production-module, I understand that the device tree blob has to be rebuilt and jetson-IO won’t work for this module. Although, I haven’t had luck getting the SPI and other peripherals working yet. I had followed the steps under Jetson Nano Platform Adaptation and Bring-Up > Pinmux Changes through Updating the Bootloader Pinmux. I am suspecting that some steps are not for correct for the production module, for example:

$ cp arch/arm64/boot/dts/tegra210-p3448-0000-p3449-0000-*.dtb /kernel/dtb/

Looks like the part in the bold should have been 0002 instead for the production module. I separately copied ${JetPack_root}/JetPack_4.4.1_Linux_JETSON_NANO/Linux_for_Tegra/sources/kernel/kernel-4.9/arch/arm64/boot/dts/tegra210-p3448-0002-p3449-0000-b00.dtb into kernel/dts/ and flashed again. I am using spidev_test.c in loopback mode to test the SPI functionality.

So in conclusion, I have 2 problems:

  1. Inability to use gpio-64 (GPIO3_I.00, SODIMM pin #130), both on the devkit and production module.
  2. None of the intended peripherals are working on the production module.

Could you please let me know if I am missing something? Are there some other changes in the pinmux instruction that has to be adopted for the p3448-0002-b00 production module?
Attaching the exported dtsi files from the Excel utility (changed to txt for the forum).
Thanks.

tegra210-jetson-cv-gpio-p2597-2180-a00.txt (1.8 KB)
tegra210-porg-pinmux-p3448-0002-b00 .txt (38.1 KB)

7

hello shubhamp,

I would usually double check the flash messages for the correct file name of the device tree blob.
for example,

[ 260.8830 ] Writing partition DTB with tegra210-p3448-0000-p3449-0000-a02.dtb.encrypt
[ 260.9492 ] [................................................] 100%
9