Where does file 'kernel_tegra194-p2888-0001-p2822-0000.dtb' come from in extlinux.conf?

How does the file kernel_tegra194-p2888-0001-p2822-0000.dtb get recompiled?

I saw in the rootfs/boot/extlinux.conf file, the referenced dtb file was named with a ‘kernel_’ prefix, like ‘kernel_ tegra194-p2888-0001-p2822-0000.dtb’.

Where does this file come from? I did not see it after my kernel compile completed, only the tegra194-p2888-0001-p2822-0000.dtb file.

I even tried to just recompile the dtbs and didn’t see it as a result.

I am creating a new custom .dts file, so I need to know how my new .dtb files
will be used/referenced.

Thanks!

Put your new kernel dtb into Linux_for_Tegra/kernel/dtb and doing the flash process.

The flash tool will generate this file.

The prefix does not really matter to the functionality.

1 Like

This is just some trivia around your question, which might or might not be useful to you…

The name itself:

  • tegra194 is named after SoC itself. I think it is major version Tegra 19, and the particular variant 4. At least long ago that was how it worked, e.g., the Tegra 3 is anything tegra30 to tegra39, but I only saw tegra30; the TK1 is tegra124, but anything tegra12 was TK1, the tegra124 was specific to the Jetson. There was a TK1 tablet type product that was a tegra12, but it was not the tegra124 because the chip was a variant of that. Anyone know if that is how it still works for the SoC naming?
  • The p2888-0001 and p2822-0000 would be designations for module plus carrier board. The 0001 and 0000 are revisions. So the naming tegra194-p2888-0001-p2822-0000 is a combination of SoC naming, module naming, and carrier board naming.

Device trees are more or less arguments to drivers. This includes the ability to find components the drivers work with (which are non-plug-n-play components). Part of the function is to tell the SoC which lanes to route where since many of the pins have multiple functions possible. There might also be different hardware present on different modules or carrier boards since the number of pins which are exposed may differ with models, and the carrier board itself might use or ignore some pins. During production maybe a part might go out of production on the carrier board, and so a revision might be to deal with a different chip that does the same thing as the old chip. Changes in memory would be a good example.

The device tree is not part of the kernel, it is data passed to specific parts of the kernel. However, there is no need to create a device tree for drivers not built, so you can find device tree fragments in the kernel which can be built if that driver is selected in configuration. You would only get the right device tree if you build a kernel of the right configuration. You might still need other fragments for variants of carrier boards. A driver which sees a tree fragment for some other driver will ignore that fragment, so you might see fragments which the kernel ignores in some configuration.

The PINMUX spreadsheet is a spreadsheet which shows various features, and allows selecting options, followed by export to device tree format if you have enabled macros. This is a good customization tool, and an alternative to building via kernel source.

Thanks @linuxdev. That helps a lot. Appreciate the information.

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