JetPack 5.0.1 compiling dtb

Hi,

I’m trying to compile the dtb from source using the following command:
cross compile is set as instructed: l4t-gcc/bin/aarch64-buildroot-linux-gnu-

and when i’m running dtb compiling:
make ARCH=arm64 O=$TEGRA_KERNEL_OUT dtbs

I get:
<FULL_PATH>/tegra194-soc-base.dtsi:1256.27-28 syntax error
FATAL ERROR: Unable to parse input tree

regarding the following lines:
resets = <&bpmp_resets TEGRA194_RESET_SLVSEC>;
reset-names = “slvs-ec”;
clocks = <&bpmp_clks TEGRA194_CLK_SLVSEC>,
<&bpmp_clks TEGRA194_CLK_SLVSEC_PADCTRL>,
<&bpmp_clks TEGRA194_CLK_PLLP_OUT0>;

every line that shows that error include the ‘&bpmp_clks’

I haven’t changed those lines at all.
please advise.

Did you fully configure prior to the build? Are you also certain the configuration is propagated? As a contrived example to show how config can fail, if you configured, and then ran the kernel Image build as a target, then this makes sure configuration is propagated everywhere you need it; however, if you configured, and were to skip the kernel and directly build the modules target, then config would have failed…for that you would need something like “make modules_prepare” before a module build would work without another step propagating configuration. Basically this is just to demonstrate that basic config needs to trigger the recursive copy of that config into other locations, and that normally building the kernel itself does this, but that if this step is skipped, then other build targets which lack proper configuration will fail. I am wondering if the configuration you set up for is correctly in place. The “acid test” is to see if you can build the kernel “Image” target…if this works, then the error you got from the device tree target is probably a valid error.

Assuming it is a valid error, then it might matter where you got the source code from. You’ll find that several ways of getting this source have “out of tree” kernel code (directories in addition to the pure kernel source which the kernel source can access via relative path). Most likely this is not an issue, but this is worth mentioning. If source code is a subdirectory like this, then probably it is ok (except this is a 4.9 kernel example, yours would be a 5.x example…the “hardware/” part is the out of tree content):

.
├── hardware
│   └── nvidia
└── kernel
    ├── kernel-4.9
    ├── nvgpu
    └── nvidia

In summary, how did you configure?

I have tried running the kernel build as you suggested before running the dtbs build.
I still get an error from the run.

the command I run is:
make ARCH=arm64 LOCALVERSION=“-tegra” CROSS_COMPILE=<cross_compiler_path> O=$TEGRA_KERNEL_OUT dtbs

and the output (both stdout and stderr):
output.txt (88.5 KB)

i’m getting (as in the attached file):
Error: /usr/include/t19x-common-modules/tegra194-cvm-p2888-0000-a00.dtsi:0.75-76 syntax error
FATAL ERROR: Unable to parse input tree

I have not edited this file at all, it’s the original from the nvidia site public_packages

please advise.

update: I succeed at compiling the dtbs

but… I dont have tegra194-p3668-all-p3509-0000.dtb file in my $TEGRA_KERNEL_OUT dir.
that although the compilation finished successfully.
I only have tegra194-p2888-* files and not at all tegra194-p3668-all-* files…

any idea why?

Can I verify if you are cross compiling, or native compiling? I was building a kernel with defaults at the time I ran into this, and from your log I see an actual error, but when I compile natively it succeeds. From my output location:

$ find . -name 'tegra194-p3668-all-p3509-0000.*'
./kernel/arch/arm64/boot/dts/nvidia/tegra194-p3668-all-p3509-0000.dtb

Native build uses a different compiler, and although I might at first think this is the difference, the dtc app is actually part of the kernel source itself and the .dtb output should be independent of compiler. Even so I am thinking maybe the error is based on either:

  • Environment
  • Configuration (my configuration was default “tegra_defconfig”…what changes did you make relative to the default config?)

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