I am not sure what the DTS/DTB file relative to the production Nano Module. When I use the SDK-manager download L4T targeting at P3448-0020, the following dtb file in L4T/kernel can be got.
Seem there is no different with those dtbs when targeting at P3448. And I know my Nano dev kit use tegra210-p3448-0000-p3449-0000-a02.dtb. (1) Then what is the above DTB file I should select to base on when porting the production Nano module to a customized carried board?
I also find a lot dts file in the kernel source directory as below.
The Tegra_Linux_Driver_Package_Nano_Adaptation_Guide just say The device tree files are saved in the same location as the Excel spreadsheet. After the file is generated, make sure that the file name matches the one you use in your kernel code. Correct the file name if there is a mismatch. Later, you will copy the device tree files into the Linux kernel source tree…
Still I don’t know how to use the pinmux document generating dtsi files below.
a. tegra210-jetson_nano_module-gpio-default.dtsi
b. tegra210-jetson_nano_module-pinmux.dtsi
If the “tegra210-p3448-0002-p3449-0000-a02.dts” I should select, then I know just include the two dtsi files in this dts file.
(2) Please tell me is the tegra210-p3448-0002-p3449-0000-a02.dts file under sources/nvidia/platform directory I should chose for the production Nano Module?
(3) The Exporting Pinmux for U-Boot section of Tegra_Linux_Driver_Package_Nano_Adaptation_Guide says the Pinmux document generated dtsi files need to be ported to u-boot. As for production Nano module, must we do this step on L4T 32.3.1 release?
Sadly the r32.3.1 documentation is not up to where we need it to be yet. Especially if you’re doing your own custom carrier board. There seems to be too much focus on the devkit rather than us trying to make our own products with production modules.
The entire section regarding PinMux,GPIO, and uboot should be deleted from the documentation as this is no longer the way it’s done and also no longer works. Cboot and uboot have been changed for the worse. The new Jetson-io tool is great for tinkerers using the devkit but useless for us making real products. Instead this is a step backwards. It seems we are no longer able to do PinMux changes via dts files on the host.
From what I understand is that cboot now blocks the dts PinMux Changes.
I would really love for someone from Nvidia to prove me wrong and also address the documentation.
When I flash the customized board with production Nano module, I use sudo BOARDID=3448 FAB=B01 ./flash.sh --no-flash jetson-nano-emmc mmcblk0p1 script, and get below log.
Not devkit. We are use a production module for a industrial product. But at this moment no module in in handy. But we have to made a FW to test a faraway customized board.
As for Jetpack 4.3, do we need rebuild uboot with dtsi files generated by pinmux document for our industrial product consisted of the Nano production Module and a customized carrier board?
Hi, this is something I’m trying to figure out myself properly.
The uboot code for PinMux settings has been deleted. So the documentation is definitely wrong and needs to be updated. If you want it back you can git checkout tag r32.2.2 from uboot source.
Anyway it’s interesting looking at the uboot git history and changes, you will see exactly what they have done.
It may be as simple as including your dtb file in the extlinux.conf with the FDT parameter.
Hopefully someone from Nvidia can describe the best method to do this now. And I mean not for the dev kit but for us making our own carrier boards for P3448-0020.
Good luck and I would appreciate you sharing anything you learn on this topic.
What DTB file in do you use for the Nano production module(B01) by default, is it the “Linux_for_Tegra/kernel/dtb/tegra210-p3448-0000-p3449-0000-b00.dtb”?