Some question for SPI enable

Hello,

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?

Thanks

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:

dtc -I dtb -O dts -o /tmp/extracted.dts /boot/the_firmware_in_extlinux.dtb
# ...examine and edit human-readable "extracted.dts"...
dtc -I dts -O dtb -o /tmp/modified.dtb /tmp/extracted.dts

Someone else will need to answer the SPI-specific questions.

Hi Linuxdev

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.

2.I compile the kernel flow all the steps in this web “Compiling Tegra X1/X2 source code - RidgeRun Developer Connection” and step 9 to generate the headers. I confuse for this step, what’s the condition I should modify the version?

Thanks

The version within the Makefile is this:

KERNELVERSION = $(VERSION)$(if $(PATCHLEVEL),.$(PATCHLEVEL)$(if $(SUBLEVEL),.$(SUBLEVEL)))$(EXTRAVERSION)

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).

Hi linuxdev

Thanks

After I modify tegra210-jetson-cv-base-p2597-2180-a00.dts just like the URL “https://devtalk.nvidia.com/default/topic/795253/embedded-systems/enable-spi-on-jetson-tk1-l4t-r21-1-/post/4423188/” description, my SPI could be open and set, but when I do the read / write action, the data seems fail.
Does any difference setting between TX1 and TK1?
Take the compatible for example, should I modify it as Tegra210?

Thanks

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.

Hello, here’s a link to a wiki article documenting the procedure for enabling and testing SPI with loopback:

[b][url]http://elinux.org/Jetson/TX1_SPI[/url][/b]

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.

The issue is similar to https://devtalk.nvidia.com/default/topic/995399/how-to-load-spided-ko-automatically-after-reboot-/

running depmod again doesn’t solve the issue either.

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.

Yes. I set it as mentioned in the wiki.

What did you use for your starting config? Was it a match for the current running system?

Yes I got the config from the current system.

The module won’t be loaded until SPIdev is added in device tree. After doing that, SPIdev module is loaded, and it shows up as a device node as well.

In the wiki, “Verifying SPIdev has Loaded” is done before “Enabling SPIdev in the Device Tree”, which fails.

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).