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?
The default pinmux setting of SPI1 group is GPIOs not SPI1, you can try modify pinmux sheet and generate new pinmux and gpio .dtsi files.
Is there a guide for compiling the new device tree with the output of that spreadsheet? I’m not very familiar with the device tree.
I’ve tried just compiling the device tree source for the default image (on the device) and I get an error about “Unable to parse the input tree”.
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:
dtc -I dtb -O dts -o /tmp/extracted.dts /boot/tegra210-jetson-tx1-p2597-2180-a01-devkit.dtb
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:
dtc -I dts -O dtb -o /boot/tegra210-jetson-tx1-p2597-2180-a01-devkit-CUSTOM.dtb /tmp/extracted.dts
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.
Please refer to “EXPORTING PINMUX FOR THE L4T LINUX KERNEL” section in Tegra_Linux_Driver_Package_TX1_Adaptation_Guide.pdf included in https://developer.nvidia.com/embedded/dlc/l4t-documentation-24-2-1 .
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:
That’s essentially what I described above.
This post gives the means to turn a dts into a dtb:
If you have a correctly configured kernel source, then you can use this make target:
So far as I know those are the two choices.