I just start to study the TX1 platform and need to enable SPI for my project.
What my question are as below,
1.what’s the two file kernel_headers.tbz2 and kernel_supplements.tbz2 work in the TX1 system? should I generate new file when I went to enable SPI
I see the description in Tegra_Linux_Driver_Package_Development_Guide-24.2.1.pdf, but still, have no sense of the two files
2.When I enable SPI which modify tegra210-jetson-cv-base-p2597-2180-a00.dts, should I repeat all steps to make kernel/kernel modules/dtc/dtbs?
Should you want to rebuild a new kernel you’d use the kernel source plus a config. This is available for R24.2.1 here (look for “Source Packages”, then “Sources”…the full kernel is within that): https://developer.nvidia.com/embedded/linux-tegra
…don’t bother though unless you actually need the full kernel build.
The kernel_supplements.tbz2 file is used during the apply_binaries.sh step of a flash and contains files specific to the nVidia hardware and module. The linux-headers file contains kernel header definitions only for use in compiling modules or outside source which refers to kernel headers (think of third party hardware drivers which don’t come with the full kernel source).
Note that the specific dtb file is named in the “/boot/extlinux/extlinux.conf” file, and that if you change the firmware blob, then this is a required file copy. However, if you just change the dtb file, then there is a good chance the kernel itself won’t need to be touched in any way. The dtb file is loaded by the boot loader prior to the Linux kernel ever loading…its effect on Linux is because the hardware state at the moment of kernel load is inherited by the kernel. Kernel drivers will depend on some hardware being initialized in a certain way prior to the kernel starting, so this is why u-boot does some config early on (consider there to be a desire to keep hardware-specific settings out of the kernel source to make kernel source itself a bit more modular…the dtb can set up hardware without the kernel source having this hard wired in…dtb is typically built separately from the rest of the kernel even when they ship together in the same source tree).
Note that a dtb can be reverse compiled into a dts, examined, edited, and rebuilt back into a modified dtb without ever touching the kernel source. Example:
Thanks for your reply.
One more question to confirm.
1.After I make the modules(make modules_install INSTALL_MOD_PATH=$KERNEL_MODULES_OUT), I could see the version 3.10.96+. Is this info coming from kernel_headers.tbz2 file? Or this file is generated just when modules were made.
Normally “EXTRAVERSION” is empty, but something you are working on might set this in a Makefile. Default is empty:
EXTRAVERSION =
A typical result from this is “3.10.96”.
After that CONFIG_LOCALVERSION is appended. Somewhere between Makefile EXTRAVERSION and CONFIG_LOCALVERSION is where anything beyond “3.10.96” is set. You probably want to check any Makefile and be sure EXTRAVERSION is not set.
I think JetPack can deal with kernel source, but the flash step itself just uses a previously compiled kernel. Headers would make no difference except when compiling modules from outside of the kernel source tree. That URL’s step 9 is designed to make sure any version info in a Makefile or Kconfig file match for cases of using separate headers.
Basically something part of the kernel source uses the normal kernel compile with its own headers, Makefile, and Kconfig; separate headers would be used for third party driver compiles or for compiles of anything tied to kernel headers when full kernel source is either not available or not required (and this implies separate Makefile and Kconfig as well). Should headers and source code differ things may not work well…versioning can be a way to determine if there are modifications. I have not used that “step 9” from the URL, but it seems the step is designed to keep headers matching source when separate headers are used instead of full kernel source. Between EXTRAVERSION and CONFIG_LOCALVERSION the final source and headers must match…the repackaging of headers accomplishes this and is unnecessary when using full source. You’ll have to figure out if a Makefile EXTRAVERSION exists in the headers, and if it does, make sure it matches your installed system. Same for CONFIG_LOCALVERSION (CONFIG_LOCALVERSION is part of Kconfig, EXTRAVERSION is part of the Makefile).
I don’t know enough about SPI on Jetson to answer SPI questions. However, the “210” of “Tegra210” directly names the SoC of a Jetson TX1, so anything named roughly “t210” or “tegra210” probably applies. You can reverse compile any dtb file produced to be sure changes actually occurred when expected. Should it turn out that your dts/dtb changes did not make it, you can make just the dtb files via the kernel compile target “make dtbs” if things are already configured.
Test the loopback first before connecting 3rd-party SPI peripherals to verify the SPI channel is configured correctly from the Jetson side.
The loopback involves installing a jumper or short wire between SPI1 MISO/MOSI signals on the devkit’s J21 Expansion Header (pins 19 & 21).
The user loopback tool is included with the L4T kernel source and verifies the data integrity.
I am following the steps as mentioned in the elinux wiki page. While building the SPIdev Module, while running “make M=drivers/spi/”, I get warning “Symbol version dump /home/ubuntu/sources/kernel/Module.symvers is missing; modules will have no dependencies and modversions”.
It completes building though. But on installing the module, and rebooting, the module is not loaded.
During your build did you set CONFIG_LOCALVERSION to match the suffix of the “uname -r” for the running kernel? For example, if “uname -r” were “4.4.15-tegra”, then CONFIG_LOCALVERSION would require setting to “-tegra” for that module to match the kernel when compiled against 4.4.15 source.
Since the missing part should be in kernel source (or headers), can you try to first build a complete kernel? You could for example start with a make mrproper (but use the “O=/where/ever/building” to point to your build location if not building directly in the kernel source), then put in the .config from the running system, verify CONFIG_LOCALVERSION, build the whole kernel, and then build the module naming the same “O=/where/ever/building” to see if something in a full build might add in the missing information for symbol version. I’m thinking you’re probably trying to build just the module, and something the module depends on might not be configured, but a full kernel compile might fix that (you don’t have to use the kernel, just build it for setup).