I use TX2 and L4T R32.4.4, and the usb of custom board could not used.
I tried this posthttps://forums.developer.nvidia.com/t/third-usb-on-custom-board-not-working-with-jetpack-4-2/72918/14
to modify some dts files such as ../hardware/nvidia/platform/t18x/quill/kernel-dts/tegra186-quill-p3310-1000-c03-00-base.dts.
But I really do not know how to compile it to dtb file and re-flash into TX2.
This page [Welcome — Jetson Linux<br/>Developer Guide 34.1 documentation](Tegra Linux Driver Package Development Guide) give the method that how to custom the kernel, but i do not know if it would re-compile ../hardware/nvidia/platform/t18x/quill/kernel-dts/*.dts directory.
I feel confused because the kernel source code directory is orgnized as
~/kernel_src/kenerl/kernel-4.9/... and ~/kernel_src/hardware/.../tegra186-quill-p3310-1000-c03-00-base.dts
hello yeah_imwyx,
that’s make commands to compile and build the device tree blob.
all the reference device tree files were under hardware folder of kernel_src package.
it’s t18x of the chip version if you’re working with TX2 series.
thanks
Did you mean if i use make under ..../kernel-4.9/ directory, the device tree files under ~/kernel_src/hardware/... would be completely compiled?
hello yeah_imwyx,
the device tree blob should be generated if you configure the build settings correctly to build the Jetson linux kernel.
Hi JerryChang
I also want to bulid the dts/dtsi files under the ~/kernel_src/hardware directory, how to configure the build setting you said
You should probably start a new topic, but generally speaking, knowing why one can build a device tree using kernel source would explain much of what you are asking.
A device tree is technically not part of the kernel itself. Instead, a device tree can be viewed as arguments being passed to drivers rather than being part of the drivers themselves. Arguments from one driver are irrelevant on a different driver. One can provide meaningless arguments, and rather than causing an error, the drivers would ignore arguments they are not interested in.
From this it should become more intuitive that “standard arguments” being passed only matter if that kernel feature or driver is built. Whenever you build a kernel with certain integrated features/drivers, along with module format features/drivers, then you essentially have a shopping list of what device tree arguments might be relevant to pass, and thus the parts of a device tree which should be built (you could build other parts, but they would be meaningless). Normal kernel configuration to select features also selects device tree components as a kind of utility shopping list.
Normally one would start a kernel build for a Jetson as a match to the existing build, and by default that would be the “tegra_defconfig” build target. Then you might customize by adding a driver for some favorite device. Then you’d either build the “Image” target (the integrated kernel) and/or modules (part of the kernel, just loadable/unloadable). If one builds the “Image” after some sort of configuration, then all configuration is complete. If one were to build only modules, and not the “Image”, then one would have to first build target “modules_prepare” to get the configuration to update throughout the source prior to building actual modules. Anything which provides a complete configuration update also will configure correctly prior to building target “dtbs”. It is the “dtbs” target which builds a device tree compiler and then the actual device tree.
So the lesson is to simply configure source to match your existing kernel, make sure the configuration is complete, and then build target “dtbs”. The result is that one or more device trees will be built (there might be more than one tree because there might be more than one hardware revision). Don’t configure specifically for the dtbs, configure for a full kernel and module build, and the result will end up correct when building dtbs.