Hello,
I am trying to use the SPI1 bus with two SPI devices, one on CS0 and one on CS1. I have SPI enabled and can see traffic however CS1 (pin E13) is always pulled low. I suspect that the “Audio Expansion” use of this pin in the default image is causing this.
Is there a way, I assume in the device tree, to remove this conflict?
This isn’t for kernel compile, but if you simply want to quickly test a dtb file change it is sometimes useful to just reverse compile, edit, and recompile just the dtb. The dtc command is the compiler, option “-I” is input format, opttion “-O” is output format, “-o” is output file. If you don’t have dtc on your system, or if your dtc is the wrong version, keep in mind that kernel source always has dtc specific to that kernel version in the “scripts/dtc/” directory if you build firmware. Should you compile a specific kernel version, you might consider saving a copy of the dtc program with a version in its name.
An example to reverse compile “tegra210-jetson-tx1-p2597-2180-a01-devkit.dtb” into “tegra210-jetson-tx1-p2597-2180-a01-devkit.dts” is:
You could edit that file with an ordinary editor. This file is equivalent to what the kernel sources compiled in, but lacks some of the comments and naming…it’s a somewhat more generic source code…but you might find what you’re interested in that way and test it without building from a kernel. An example after edit:
Thanks, linuxdev.
I need to ensure that all the pins are mapped to their usage on our carrier board. For this, it seems like the only sane approach is to use the pinmux spreadsheet pointed to above and the dtsi files it generates. Unfortunately, they depend on many other pieces that I cannot get to compile correctly.
Directly testing the dtb change first is perhaps simplest. If the dtb change works then I’d go for kernel source edits. If the dtb does not work, then the rest of what follows could probably be skipped.
In the case of a kernel compile issues I’d recommend attaching the config to your post (hover the mouse over the upper right corner quote icon and a paper clip icon will show up as well…the paper clip is to attach a file to an existing post…just name the config with a “.txt” extension). A note as to how the config was derived (for example, via “make menuconfig” or direct file edit) would be useful.
Along with that I’d recommend compiling the kernel with “-j1” to avoid multiple compile thread messages from intermixing, and post logs of enough of the final compile error to see what’s going on. Add to this the compile target, e.g., if it was “make dtbs” or “make Image”, and the version of compiler you used.
My goals is to just compile the device tree for an existing kernel. It may be a naive assumption on my part that I can do that.
I’m really looking for more insight into how to handle the output of the pinmux spreadsheet specifically. I get two dtsi files that look like should be included from my primary device tree source however I am not certain which existing includes should be omitted.
I can get the default device tree to compile now so my last hurdle is editing the include list to match my pinmux output.
That section does not answer the question of how to compile the output into a new DTB (without doing a whole kernel build). The entirety of that section is: