Platform adaptation - adapted pinmux XLS, and then?

Dear community,

I want to adapt Linux for Tegra 28.1 for our custom carrier board having the TX2 module. I’ve found Tegra_Linux_Driver_Package_TX2_Adaptation_Guide.pdf

I’ve successfully modified the NVidia provided XLSM, generated the device tree sources. Now what? Where shall I copy them? Which files should I overwrite?

Which files should I modify in the flasher?

I’ve actually tried to adapt the jetson-tx2.conf and the p2771-0000.conf.common files, basically copying the originals (and the referenced configuration and device tree files) to the same file name, except replacing “quill” with our custom board’s name. So I’ve copied the files and done a clever search and replace in the files.

The interesting thing is that with the same - just renamed (and replaced in the source) - configuration files the flashing fails:
flash.sh fails with “Cannot open USB”.
On the Tegra serial console I see:
C> I2C command failed
C> block index = (1) and rail_id = (4)
C> Addr: Reg = [0x72:0x07]: 336166925
C> Failed to bringup SRAM rails
C> ERROR: Highest Layer Module = 0x28, Lowest Layer Module = 0x26, Aux Info = 0x0, Reason = 0xd

The interesting thing is that with the original configuration (jetson-tx2.conf) the flashing is successful.

hello wachagj,

please also check the release 28.1 developer guide,
check [U-Boot Customization]-> [TX2 Configuring Pinmux GPIO and PAD] for more details.
thanks

Sorry, I cannot accept this as an answer, actually I’ve read those documents. The only information they have is:

“modify one of the distributed configuration files to describe the design of your platform.”

Apparently pinmux configuration is distributed into the following files:
./nvidia/soc/t18x/kernel-dts/tegra186-soc/tegra186-soc-vcm.dtsi
./nvidia/soc/t18x/kernel-dts/tegra186-soc/tegra186-soc-cvm.dtsi
./nvidia/soc/t18x/kernel-dts/tegra186-soc/tegra186-soc-sata.dtsi
./nvidia/soc/t18x/kernel-dts/tegra186-soc/tegra186-soc-base.dtsi
./nvidia/platform/t18x/quill/kernel-dts/tegra186-quill-e3313-1000-a00-00-e2598.dts
./nvidia/platform/t18x/quill/kernel-dts/tegra.dts
./nvidia/platform/t18x/quill/kernel-dts/tegra186-quill-p3310-1000-c03-00-base.dts
./nvidia/platform/t18x/quill/kernel-dts/tegra186-quill-p3310-1000-a00-00-base.dts
./nvidia/platform/t18x/common/kernel-dts/t18x-common-platforms/tegra186-quill-p2382-010-a01-eqos-pinmux-manual.dtsi
./nvidia/platform/t18x/common/kernel-dts/t18x-common-platforms/tegra186-quill-common.dtsi
./nvidia/platform/t18x/common/kernel-dts/t18x-common-platforms/tegra186-quill-spmic-p3310-1000-a00-00.dtsi
./nvidia/platform/t18x/common/kernel-dts/t18x-common-platforms/tegra186-quill-power-tree-p3310-1000-a00-00.dtsi
./nvidia/platform/t18x/common/kernel-dts/t18x-common-plugin-manager/tegra186-quill-p3310-1000-300-plugin-manager.dtsi
./nvidia/platform/t18x/common/kernel-dts/t18x-common-plugin-manager/tegra186-quill-p3310-1000-a00-plugin-manager.dtsi

So, which shall I overwrite with the generated pinmux?

Other interesting thing is that the default pinmux xlsm generates a pinmux which crashes the kernel

  • download pinmux XLSM
  • generate a DTS
  • include the dtsi files in your device tree

During boot:
iommu: Adding device 3460000.sdhci to group 0
iommu: Adding device 3400000.sdhci to group 0
CPU5: SError detected, daif=1c0, spsr=0x600000c5m noudr=80000103, esr=bf40c000
CPU3: SError detected, daif=1c0, spsr=0x600000c5m noudr=80000103, esr=bf40c000
CPU0: SError detected, daif=1c0, spsr=0x600000c5m noudr=80000103, esr=bf40c000
CPU4: SError detected, daif=1c0, spsr=0x600000c5m noudr=80000103, esr=bf40c000
Watchdog detected hard LOCKUP on cpu 1

hello wachagj,

could you share the steps to crash the kernel with default pinmux?

we had verified this with tx2/r28.1,
after replace generated *.cfg files for flashing, there’s no issues after boot up,
thanks

I just included the generated dtsi files at the end of the main device tree file.

hello wachagj,

please converts those DTS files into .cfg format for flashing,
check [U-Boot Customization]-> [TX2 Configuring Pinmux GPIO and PAD] for more details.
thanks

It has been done already. (Altough the flasher modifies the name of the boot config files you set in p2771-0000.conf.common based on an EEPROM value - so a different file is used instead what you set which is confusing…)

But shouldn’t these generated device tree files be included in the main dts? If not, why does the pinmux XLSM generate DTSIs instead the boot config files?

hello wachagj,

please check the documentation,
you should replace the *.cfg files.

paste some flashing message for your reference,
thanks

[   0.7750 ] Generating recovery mb1-bct
[   0.7760 ] tegrabct_v2 --chip 0x18 --mb1bct mb1_bct.cfg --sdram P3310_A00_8GB_Samsung_8GB_lpddr4_204Mhz_A02_l4t.c     fg --misc tegra186-mb1-bct-misc-si-l4t.cfg --scr minimal_scr.cfg --pinmux tegra186-mb1-bct-pinmux-quill-p3310-1000-     c03.cfg --pmc tegra186-mb1-bct-pad-quill-p3310-1000-c03.cfg --pmic tegra186-mb1-bct-pmic-quill-p3310-1000-c03.cfg -     -brcommand tegra186-mb1-bct-bootrom-quill-p3310-1000-c03.cfg --prod tegra186-mb1-bct-prod-quill-p3310-1000-c03.cfg

As I wrote, I replaced them, I’ve found out which files are used.

But what about the device tree file for Linux? Where shall I include the generated dtsi? Shall I include them at all?

I have the exact same questions.

On a jetson TX2 using Jetpack 28.2 ) and the PinMux spreadsheet (1.05).
Using the default values, I generate the 3 dtsi files. I then use pinmux-dts2cfg.py to generate
tegra186-mb1-bct-pinmux-quill-p3310-1000-c03.cfg and
tegra186-mb1-bct-pad-quill-p3310-1000-c03.cfg.

I copy these to the BCT folder within the bootloader and can flash them over.
Using the original tegra186-quill-p3310-1000-c03-00-base.dtb file, the board boots fine.

If I recompile the DTB file by #including the 3 dtsi files in the tegra186-quill-p3310-1000-c03-00-base.dts file , then I get the following errors and CPU lockup.

iommu: Adding device 3460000.sdhci to group 0
iommu: Adding device 3400000.sdhci to group 1
CPU0: SError detected, daif=1c0, spsr=0x600000c5, mpidr=80000100, esr=bf40c000
CPU4: SError detected, daif=1c0, spsr=0x600000c5, mpidr=80000102, esr=bf40c000
CPU3: SError detected, daif=1c0, spsr=0x600000c5, mpidr=80000101, esr=bf40c000
CPU5: SError detected, daif=1c0, spsr=0x600000c5, mpidr=80000103, esr=bf40c000

Does this mean that the generated dtsi files shouldn’t be used to recompile the dtb?

hello wachagj, akmal.ali,

may i have confirmation that following the steps in the document works,
but you met an issue if “recompile the DTB file by including these generated dtsi files”
thanks

That is correct. Just using the .cfg files generated for MB1, boots correctly. However if a dtb compiled using the generated dtsi files is also flashed over, the errors occur.

For me too, the bootloader is OK. As I wrote in https://devtalk.nvidia.com/default/topic/1030396/jetson-tx2/platform-adaptation-adapted-pinmux-xls-and-then-/post/5246333/#5246333 , I replaced the boot config files.

However the question is still this:

Should we include the generated DTSI files in the kernel DTS or not. If yes, where? (see https://devtalk.nvidia.com/default/topic/1030396/jetson-tx2/platform-adaptation-adapted-pinmux-xls-and-then-/post/5244583/#5244583 ).

What I want to achieve: I want to use some pins of the TX2 as GPIOs - so I turned off the functionality of them. I also want to turn on SPI2 of the TX2 SOM.

What we see:

To summarize:

So the question again:
Should we include the generated DTSI files in the kernel DTS or not. If yes, where?

Without the pinmux DTSI included in the device tree, the pins does not seem to be configured as SPI2 (we do not see any change on the signals during the transmission).
With the pinmux DTSI the kernel crashes.

hi all,

please check the difference between the default DTB file and the customize one.
you could use below commands to disassembler the dtb file into txt file for comparison.
thanks

$ dtc -I dtb -O dts -o temp.txt tegra.dtb

JerryChang, please, we know what is the difference between the two device tree files, since we made that difference in the first place: in the working one the 3 generated dtsi files are not included, in the crashing one they are.

(Also, if you want to compare device tree files you should really add the switch -s to the dtc command which sorts the nodes and properties - it makes the outputs diffable (see man dtc).)

@JerryChang

Similarly the changes present in the dtsi are present in the compiled dtb file. I am finding the same as wachagj.

Note I have to replace TEGRA_GPIO( #, # ) with main TEGRA_MAIN_GPIO(#,#) or TEGRA_AON_GPIO(#,#) for the dtb to compile.

Could you tell us which dtb files take effect and at what stage?

From the documentation, it seems that the MB1 Bootloader uses the config files we give it to set Pinmux, GPIOs and Pad settings.

The bootloader (U-boot) has its own device tree, and loads the kernel device tree.

If the flash tool is used to flash the dtb over, do U-boot and the kernel both use that same dtb file?

Do pinmux/ GPIO settings in this dtb overwrite the settings set by MB1 stage?

Edit I have attached a diff of the dtb files in case you would like to check it

dtb file diff.txt (248 KB)

hi all,

please do NOT include these generated dtsi files into kernel-dtb since we take them to generate MB1 bct.

instead,
you should modify the device tree to enable SPI2 by updating the device tree

  • and -
    use the pinmux spreadsheet to generate a customize configuration file.
1 Like