I’v created a custom carrier board for Nano and now I’m trying to follow the "adaptation and bring-up guide " from here Tegra Linux Driver
The first hint of the problem was this phrase from the guide - “you must obtain Jetson_Nano_customer_pinmux_release.xlsm from NVIDIA and customize it”. Well, of course my request of such file is still without reply. So I went ahead and modified the only available pinmux spreadsheet (the one from nano downloads section), mostly by disabling stuff since my board only uses a few peripherals (3 UARTs, USB3.0, USB2.0).
Then, when running “csv-to-board.py” script on my modified file I hit an error “Header row not found” and that’s where my following of the guide stops :(
This is my first time doing something similar (low level embedded linux stuff) so I’m sure I’m missing some otherwise obvious things. there are few questions:
what do I do? This seem to be too general, but I mean it - any advice on how to do this adaptation is welcome
do I really need a special “customer” pinmux file from Nvidia to be able to follow the official bring-up guide? I’ve read somewhere here that one can manually edit device tree files to adapt new boards.
is it safe to start the board in ForceRecovery with un-flashed Nano connected or should I first flash it using DevKit carrier somehow?
Thank you all in advance for any hints/advices/solutions!
You don’t need to run any pinmux setting script (csv-to-board.py) in uboot after rel-32.3 anymore because it is all handled by cboot and the only thing you need to do for pinmux is put those dts file to kernel source and replace the old pinmux dts file.
do I really need a special “customer” pinmux file from Nvidia to be able to follow the official bring-up guide? I’ve read somewhere here that one can manually edit device tree files to adapt new boards.
No, please just use the spreadsheet on the download center.
is it safe to start the board in ForceRecovery with un-flashed Nano connected or should I first flash it using DevKit carrier somehow?
It sounds not harmful. Recovery mode does not know whether your module is ever flashed before. It is hardware mechanism and all the flash binary is sent from host by usb directly.
Honestly speaking, adaptation guide is more like a simple tutorial and does not point out which file you really need to replace.
You need to understand what is the dtb file you are flashing to your board and track which gpio dtsi file is using by this dtb file. Then you replace your new dtsi file which contains the gpio/pinmux change to that old one.
I would suggest you should download our kernel source from our download center first and go to check which dts file is your board using and trace down the code.
I synchronized the kernel sources using “source_sync.sh” as described in the guide. Would that be the same as downloading from download center?
How do I know which dtb file (why not dts?) is used for Nano SDK? And where are those dtb files generally located?
The source code you downloaded from script should be same as tarball.
To tell which dtb file your board is using, you could search “dts” in your kernel log on Nano and it should tell.
DTB is the binary file built from dts. If you are not familiar with dts file, maybe you should study it from some public linux resources first. It may be painful but this is the basic of device bring up when working on custom carrier board.
If you want to know how to build dtb, our L4T development guide has the tutorial in “Kernel customization” section. All documents are on the download center too.
Then I modified the the #include lines of that file to link my own pinmux and gpio dtsi files:
#include “tegra210-porg-p3448-common.dtsi” #include “porg-platforms/tegra210-lis_nano-pinmux.dtsi” <--------- modified by me #include “porg-platforms/tegra210-lis_nano-gpio-default.dtsi” <--------- modified by me
After, I proceeded with kernel, DTB, modules compilation (as per L4T documentation), replaced the original (from the driver package) kernel image and dtb files with the compiled ones and flashed the module using:
sudo ./flash.sh jetson-nano-emmc mmcblk0p1
The flashing went well and I rebooted the board only to find that it can’t boot the kernel. There are a lot of “failed” in the log, specificaly, all I2C writes fails and others.
I’m attaching the log from the serial console.
could you, please, give it a quick look and see if you can detect what went wrong?
I’m using the newest “NV_Jetson_Nano_Module_Pinmux_Config_Template.xlsm” v1.01
I’ve changed AS column (“customer usage”) to “unused …” for the pins that aren’t connected anywhere on my board. I’ve put “Z” in the AT column (“Pin Dir”) for those pins.
The only pins I’ve left active are:
MOD_SLEEP*
SHUTDOWN_REQ*
SYS_RESET*
SLEEP/WAKE*
FORCE_RECOVERY*
UART1_TXD
UART1_RXD
UART1_RTS*
UART1_CTS*
UART0_TXD
UART0_RXD
UART0_RTS*
UART0_CTS*
UART2_TXD
UART2_RXD
USB0_D_N
USB0_D_P
USB1_D_N
USB1_D_P
USBSS_RX_N
USBSS_RX_P
USBSS_TX_N
USBSS_TX_P
I was tired of “I2C Write failed” messages (and associated wait times) in the log so I went in “tegra210-porg-3448-common.dtsi” and disabled I2C4 as well as anything remotely connected to display (since I don’t have any).
I’m attaching the log after that (still the same kernel panic…). I also removed “quiet” from the bootargs so the kernel part of the log is much bigger. Please, let me know if that isn’t necessary. boot_log_jetson_nano_4_3.log (58.4 KB)
I see the error log seems from VI driver. If you don’t need that, could you try to disable vi@54080000 in dts?
Actually, I think you could use the original pinmux first and see if there is any issue. Then, use your own one.
I mean generate one with no change and put it into dts/rebuild the dtb and flash. Even though there are some pins unused, it should be able to boot into system with some error/warning messages.
Well, I couldn’t find the vi@54080000 in the dts file…
Here is my boot log after flashing the default image with dtb generated from pinmux.xlsm untouched. boot_log_jetson_nano_default.log (74.7 KB)
I looks like successful, apart from failed EDID read, of course.
I suppose I should run the oem-config now.
what serial port device I should put in “nv-oem-config.conf.t210” to be able to do that over UART0 (the one I use to get the logs) ? right now it says “ttyGS0”
thank you so much for your help! that did the trick and I could boot and log into the system.
But now I still want to be able to adapt the system to my hardware.
Typically, the USB 3.0 devices are not recognized by the system (USB 2.0 are ok) right now, maybe because DevKit has a USB3.0 hub on it, so my current unmodified Device Tree has the description of this hub somewhere. but my board has direct route to a single USB A connector. This would be my main concern for now, as USB 3.0 is quite crucial for our applications.
What would be the correct way of changing the pinmux file? Or where to look directly in the dts files maybe?
For usb issue, it may not be just pinmux issue. DT modification is also required.
This is a very very common question on this forum board.
I would suggest you to refer to the usb porting guide in adaptation guide. This would teach you how to modify the device tree.