Need some clarification about custom boards

Hey all,

we designed a custom board for the Xavier NX Module. I’d like to understand what the proper workflow is for getting the image right. Please see my questions in bold

For now we got:

  • Ubuntu Base Image modified with apply_binaries.sh and our custom mods
  • Kernel compiled with our own config based on the standard tegra_defconfig added to the rootfs
  • Kernel modules installed

I have read that the proper way to flash the system is by creating your own .cfg file.
So I have made a copy of the p3509-0000+p3668-0000-qspi.conf and replaced the name of the EMMC_CFG
I place our configs in a seperate folder and copy them into the L4T folder before flashing/building.

When I use the initrd_flash to flash external the system won’t accept the EMMC_CFG used in this file and forces me to use the -c command…that’s not what I expected. Can I force it to use the name in the config? I’d like to use a config to flash QSPI and one for NVME for convenience.

As our board is very similar to the Devkit I guess the source “${LDK_DIR}/p3668.conf.common” should stay in there.
I have created the dtsi file from the Excel sheet Jetson_Xavier_NX_Pinmux_Configuration_Template_v1.06.xlsm and converted that to a pinmux and a padvoltage file.

The following parameters are not part of the dev guide but I suppose I should edit the values of the PINMUX_CONFIG and PMC_CONFIG with the files I generated from the dtsi?

As I understand it the cfg files will be used by CBOOT. So I am done with the bootloader after this.

Next I’ll need the dtb for the kernel. That one will be compiled during the kernel compile step and is then copied from the kernel output directory. When I set the DTB_FILE in the .cfg file it will use the file from Linux_for_Tegra\bootloader\t186ref to include it in the partition but not copy it to the rootfs?

The dev guide states that the config of the board should be named like the board name. I have not found any way to define the actual board name in the build process. Does it actually matter what the files are called like or is it sufficient to point to the correct file in the .cfg file?

Did I miss any other files which should be updated in the cfg?

Seems to be a hard one again.

Addional question:

We created a dts file for our board and added the commin include:

#include "common/tegra194-p3668-common.dtsi"

After that we added the pinmux dtsi file from the Excel sheet. After inspecting the contents of the common/tegra194-p3509-0000-a00.dtsi and the file which is generated by the Excel sheet it seems like something is missing in there? The p3509 file contains a lot more information. Is it supposed to be kept in our dts file before the file from the Excel sheet?

Could yo clarify what command you want to use here but failed?

I tried:

        $L4T_DIR/tools/kernel_flash/l4t_initrd_flash.sh --no-flash ${BOARDNAME}-qspi internal

        $L4T_DIR/tools/kernel_flash/l4t_initrd_flash.sh --no-flash \
        --external-device nvme0n1 \
        -S $SIZE \
        --showlogs \
        --external-only --append $BOARDNAME external

I though I could create one board config for QSPI and one for NVME and add all my variables including the required board config to the $BOARDNAME.conf. Instead the script tells you to use the -c parameter to point to the xml file for the partition layout.

But apparently it is only intended to use the board config when using internal flash.

As for your other questions:

The following parameters are not part of the dev guide but I suppose I should edit the values of the PINMUX_CONFIG and PMC_CONFIG with the files I generated from the dtsi?

The pinmux spreadsheet will generate out few dtsi files and you will need to use the pinmux python tool under your Linux_for_Tegra/kernel/pinmux. To generate cfg file with dtsi files as input parameters.

When I set the DTB_FILE in the .cfg file it will use the file from Linux_for_Tegra\bootloader\t186ref to include it in the partition but not copy it to the rootfs?

Generally, you need to put your dtb to Linux_for_Tegra/kernel/dtb so that it will be copied. But by default, NX loads dtb from partition. Not rootfs. If you want to use dtb from rootfs, you need to modify extlinux.conf.

The dev guide states that the config of the board should be named like the board name. I have not found any way to define the actual board name in the build process. Does it actually matter what the files are called like or is it sufficient to point to the correct file in the .cfg file?

Actually, the board config name does not matter. I would suggest you can just modify the original file to save time and prevent error.

Okay, seems I did it right, but the Dev Guide, Scripts do something different than you told me.

The pinmux spreadsheet will generate out few dtsi files and you will need to use the pinmux python tool under your Linux_for_Tegra/kernel/pinmux. To generate cfg file with dtsi files as input parameters.

I used the python script and generated the config. As soon as I include my pinmux file it won’t boot anymore, while the original file will work. Will further analyze the issue. At least that’s a sign that it swallowed the file. Or is my issue that I replaced the original pinmux config ad did not just ADD mine? It is unfortunately documented nowhere. It only tells me to generate the files, not where to put them.

Generally, you need to put your dtb to Linux_for_Tegra/kernel/dtb so that it will be copied. But by default, NX loads dtb from partition. Not rootfs. If you want to use dtb from rootfs, you need to modify extlinux.conf.

I noticed that the file which is referred to in the .cfg file is copied from Linux_for_Tegra/kernel/dtb to the dtb partition AND the rootfs. The file is signed and renamed to kernel_[name]. Also the extlinux.conf in the rootfs is automatically modified by the script to use the kernel_[name] file. Does that mean it will then try to load the file from the dtb partition or will it use the rootfs one in this particular case?

Actually, the board config name does not matter. I would suggest you can just modify the original file to save time and prevent error.

Thats too late now as the board bring up guide told me to create new files. Anyway it seems to ‘work’ now. Kept all the entries in the config like they were and just replaced the EMMC_CFG,PINMUX_CONFIG and PMC_CONFIG

When I had it wrong I noticed that the blob which is sent was not able to boot the device for flashing. We’re getting closer.
I found it quite confusing that the developer guide stops at the point where the python script generates the cfg files from the dtsi file.

There is no more mention what to do with the cfg files and the dtsi file. I think an additional entry about this would be quite useful for some beginners who never had to do anything in common with device trees. Especially the fact that the PINMUX_CONFIG and PMC_CONFIG are not mentioned in the dev guides list of parameters which can be used in the board config files. You just find them when looking at the common config for the p3668.

I used the python script and generated the config. As soon as I include my pinmux file it won’t boot anymore, while the original file will work. Will further analyze the issue. At least that’s a sign that it swallowed the file. Or is my issue that I replaced the original pinmux config ad did not just ADD mine? It is unfortunately documented nowhere. It only tells me to generate the files, not where to put them.

Sorry for that. All the cfg file in use by MB1 are under Linux_for_Tegra/bootloader/t186ref/BCT. I also read the conf file every time when dealing with different kinds of boards. May try to add this to document.

I noticed that the file which is referred to in the .cfg file is copied from Linux_for_Tegra/kernel/dtb to the dtb partition AND the rootfs. The file is signed and renamed to kernel_[name]. Also the extlinux.conf in the rootfs is automatically modified by the script to use the kernel_[name] file. Does that mean it will then try to load the file from the dtb partition or will it use the rootfs one in this particular case?

Unless extlinux.conf has a “FDT” field, it won’t read the dtb from rootfs. It will load it from partition.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.