Correct information about MB1 and early boot for r35.4.1?

[riz94107]

I’m currently in the process of learning how early boot on the Xavier NX works, in service of moving our setup from r32 to r35, but I’m running into lots of instances where the documentation is simply wrong - this makes trusting anything written really hard.

For example, I’m in the MB1 Platform Configuration section of the documentation, and I see things like:

The pinmux/GPIO configuration file contains pinmux and GPIO configuration information. It is stored at:

Linux_for_Tegra/bootloader/t186ref/BCT/tegra194-mb1-bct-pinmux-gpio-p2972<board>-<revision>.cfg

… but there are NO FILES WHICH MATCH this pattern anywhere in the Linux_for_Tegra directory:

p51-22:riz  ~/testing/jetson_top_r35.4.1/Linux_for_Tegra> ls bootloader/t186ref/BCT/tegra194-mb1-bct-pinmux-gpio-p2972*
zsh: no matches found: bootloader/t186ref/BCT/tegra194-mb1-bct-pinmux-gpio-p2972*
p51-22:riz  ~/testing/jetson_top_r35.4.1/Linux_for_Tegra>

…in fact, there are no files which match even just the pinmux-gpio part:

p51-22:riz  ~/testing/jetson_top_r35.4.1/Linux_for_Tegra> ls bootloader/t186ref/BCT/*pinmux-gpio*
zsh: no matches found: bootloader/t186ref/BCT/*pinmux-gpio*

There ARE some files with "pinmux* in the name:

p51-22:riz  ~/testing/jetson_top_r35.4.1/Linux_for_Tegra> ls bootloader/t186ref/BCT/*pinmux*
bootloader/t186ref/BCT/tegra19x-mb1-pinmux-p2888-0000-a00-p2822-0000-a00.cfg
bootloader/t186ref/BCT/tegra19x-mb1-pinmux-p2888-0000-a04-p2822-0000-b01.cfg
bootloader/t186ref/BCT/tegra19x-mb1-pinmux-p2888-0000-p2822-0000.cfg
bootloader/t186ref/BCT/tegra19x-mb1-pinmux-p2888-0004-e3900-0000.cfg
bootloader/t186ref/BCT/tegra19x-mb1-pinmux-p2888-0008-b01-p2822-0000-jaxi.cfg
bootloader/t186ref/BCT/tegra19x-mb1-pinmux-p2888-slvs-0000-a00-p2822-0000-a00.cfg
bootloader/t186ref/BCT/tegra19x-mb1-pinmux-p3668-a01.cfg
bootloader/t186ref/BCT/tegra234-mb1-bct-pinmux-p3701-0000-a04.dtsi
bootloader/t186ref/BCT/tegra234-mb1-bct-pinmux-p3701-0000.dtsi
bootloader/t186ref/BCT/tegra234-mb1-bct-pinmux-p3701-0002-P3711-0000.dtsi
bootloader/t186ref/BCT/tegra234-mb1-bct-pinmux-p3701-0002-p3740-0002-b01.dtsi
bootloader/t186ref/BCT/tegra234-mb1-bct-pinmux-p3701-0002-p3740-0002.dtsi
bootloader/t186ref/BCT/tegra234-mb1-bct-pinmux-p3701-0008-p3740-0002-c01.dtsi
bootloader/t186ref/BCT/tegra234-mb1-bct-pinmux-p3767-dp-a03.dtsi
bootloader/t186ref/BCT/tegra234-mb1-bct-pinmux-p3767-hdmi-a03.dtsi
p51-22:riz  ~/testing/jetson_top_r35.4.1/Linux_for_Tegra>

…I can see a file there which might be appropriate for our boards, which are Xavier NX a01 - perhaps bootloader/t186ref/BCT/tegra19x-mb1-pinmux-p3668-a01.cfg ??

At the top of this file, it says:

## Pinmux version 1.6
## Input pinmux file name: tegra19x-jetson_xavier_nx_devkit-pinmux.dtsi
## Input gpio file name: tegra19x-jetson_xavier_nx_devkit-gpio-default.dtsi
## Generation date: 2022-02-14 14:52
## PLEASE DO NOT EDIT THIS FILE
## This is autogenerated file using the script pinmux-dts2cfg.py

However, neither tegra19x-jetson_xavier_nx_devkit-pinmux.dtsi nor tegra19x-jetson_xavier_nx_devkit-gpio-default.dtsi exist anywhere under Linux_for_Tegra.

All this is to say, clearly, that the documentation must be out of date - or maybe just wrong? It’s REALLY REALLY frustrating to have a system as complex as this and where I can’t even rely on the documentation to steer me in the correct direction. Is there documentation on booting under the new UEFI regime which is actually correct, but hiding somewhere?

Really, what I want, is a concise (and accurate!) explanation of how to set things up so that I can achieve a goal of transitioning a fleet from r32.7.3 (where we boot from USB drives) to r35.4.1 (where we also boot from USB drives, but would like to transition to NVME drives). All the documentation is so riddled with inaccuracies that I wind up wasting days throwing stuff against the wall in hopes that something sticks.

Rant over. Sigh.

[WayneWWW]

Sorry that the document is out of date. I will make a update there.

Generally the pinmux cfg file is generated from the pinmux spread sheet over here.

Jetson Download Center

And we didn’t provide the original file of these dtsi files. You can generate them from the spreadsheet and then use pinmux-dts2cfg.py tool to convert that to cfg file.

tegra19x-mb1-pinmux-p3668-a01.cfg is the file for every jetson xavier NX module when it runs over Xavier NX devkit.

[WayneWWW]

Really, what I want, is a concise (and accurate!) explanation of how to set things up so that I can achieve a goal of transitioning a fleet from r32.7.3 (where we boot from USB drives) to r35.4.1 (where we also boot from USB drives, but would like to transition to NVME drives).

As for this, actually sdkmanager already supported to flash things to nvme and you could try that first.

[riz94107]

Thanks for the quick reply. The problem with using sdkmanager for anything is that it requires GIGANTIC amounts of resources that we wind up having to strip out anyway. It was useful in the very beginning to help understand the documentation, but at this point, it gets in the way a lot more than it helps.

[WayneWWW]

Hi,

If you are totally new to this, I would suggest just try sdkmanager first.

There are multiple ways to flash a nvme drive. Sdkmanager just wrap up the command line tools into a GUI.

Learn from that first and I can give you the next steps to do. Or at least let sdkmanager download the BSP directory to your host PC first.
This could prevent you have anything wrong when preparing the BSP.

Also, I would suggest you start from the Quick start section instead of MB1 configuration. Flashing a NVMe drive does not require to read MB1 configuration section.

The whole developer guide document is more like a dictionary. You only look into the dictionary when you want to find specific info. But not directly finish reading the whole dictionary and go back to work…
Thus, if you only want to flash a board, then you could check from quick start section first…

If you want to do anything else, tell me what you want and I can point out what to check.

[riz94107]

I’ve been working with these boards for two years; I’m not coming into this completely fresh. I have used sdkmanager - I used it extensively with r32, and now that I’m working with r35 I did use it to clarify to myself that I could make a working system. I have done that! SDKmanager wraps the commandline tools, yes - but in a way that requires me to have a ludicrous amount of free space available on the system I’m using. I started working with r35.3.1, and just two weeks ago, r35.4.1 came out - using the commandline tools, I limited the amount needed to download and test to about 40GB. Using SDKmanager requires something like three times that (in order to switch between versions)! Combined with the fact that SDKmanager forces me to boot my Ubuntu 22.04 laptop into Ubuntu 18.04 (I don’t have 20.04 on this laptop) in order to use it, this is just too much. So, I work with the command line. My goal is to understand how the process works, so I can customize it to my liking: the hyper-complex system I’m working with seems to have a goal of PREVENTING me from understanding. It’s clear that there’s a lot of internal (nvidia-only) documentation available, and NVidia (the company) wants to keep me from understanding how it works.

I do appreciate your help; I appreciate that you answered me at all. I also understand that you (“WayneWWW”) are not making the decisions with which I am so frustrated.

Anyway - I do know that MB1 is not needed for booting the basic system. The real problem is that the documentation is fragmented and targeted at two separate audiences: those internal to nvidia, who can get the details I’m after, and chumps like me, who have to explain things again and again and again in slightly different ways just to get appropriate details at an appropriate level about how the system works so that I can deliver a product to MY customer that does what I expect it to do.

Rant over. I don’t actually expect a reply here - I know you’re doing your job. I just hate, hate, HATE the way the system is evolving and I’ve stopped trying to hide my frustration.

[DaneLLL]

Hi,
We are sorry for your frustrations – we will updated the pinmux documentation with the latest information. Thank you for pointing it out.