TX2 reboots continuously after enabling SPI module and the SD card is inserted

Robotics & Edge Computing Jetson & Embedded Systems Jetson TX2
1

Hi all,
I was able to enable the SPI port available on header J21 following the guide available at [url]https://elinux.org/Jetson/TX2_SPI[/url].

However, the SD Card reader is giving me some troubles. Specifically, if I keep the SD Card inserted before pressing the power button, the TX2 reboots continuously after a kernel panic error. If I remove the SD Card, the TX2 is able to boot. Once the TX2 has booted, I can use the SD card without any problem.

I tried to factory reset the TX2 (without enabling SPI) and the board boots without problems.

Then I tried again the guide for enabling the SPI and I got again the same issue.

So, it seems to be the SPI module that is causing some kind of issue.

I did another factory reset and this time I tried the guide provided by dwd_pete: [url]https://devtalk.nvidia.com/default/topic/1024806/jetson-tx2/how-to-enable-spi-spidev-on-28-1-on-target-/post/5217032/#5217032[/url]. But unfortunately, with this guide I don’t see the SPI module under /dev. I’m not sure if I am missing some step.

I have also tried to use the guide written by dwd_pete updating the url to get the kernel source with the following: [url]sudo wget http://developer.download.nvidia.com/embedded/L4T/r28_Release_v2.0/BSP/source_release.tbz2[/url], but it didn’t work either.

My TX2 is configured with the JetPack 3.3.

Do you have any suggestion?

Please let me know if you need some output from my board.

2

@alexandros
Could you help to try J4.2?

3

Hi ShaneCCC,
unfortunately I cannot use J4.2 since my camera is compatible with Ubuntu 14.04/16.04 only and the J4.2 is based on Ubuntu 18.04.

Thanks

4

Could you help to break down if the dtb or kernel Image cause the issue.

5

I believe is the dtb, because when I follow the guide in [url]https://elinux.org/Jetson/TX2_SPI[/url] I don’t have any problem in rebooting after recompiling the kernel: The instructions contained in paragraph Building the Kernel are fine and the board is able to reboot after them.

Furthermore, I connected an FTDI cable to the UART debug port on header J21 and I have seen some error concerning the dtb file (sorry I’m back home and I don’t have access to the TX2).

6

Did you apply the DTB by flash command or modify the extlinux.conf?

7

I tried both. The first time I have modified the extlinux.com. But it didn’t work.

The second time I tried using the flash command. Concerning the flash command, I’m not sure I have done the correct procedure. Following the same guide, this is what I have done:

After the command:

sudo dtc -I dts -O dtb -o tegra186-quill-p3310-1000-c03-00-base.dtb extracted_proc.dts

I have powered off the board and then repowered in recovery mode. On my host machine I then run the flash utility as follows:

sudo ./flash.sh -r -k kernel-dtb jetson-tx2 mmcblk0p1

The flashing was successful, but the problem remained.

I have few questions anyway:

  1. I have noticed that the guide says to add a patch into the spi@3240000 section, as follows:
spi@3240000{
    compatible = "nvidia,tegra186-spi";
    reg = <0x0 0x3240000 0x0 0x10000>;
    ....
    ....
    ....
    linux,phandle = <0x80>;
    spi@0 {
      compatible = "spidev";
      reg = <0x0>;
      spi-max-frequency = <0x1312D00>;
      nvidia,enable-hw-based-cs;
      nvidia,cs-setup-clk-count = <0x1e>;
      nvidia,cs-hold-clk-count = <0x1e>;
      nvidia,rx-clk-tap-delay = <0x1f>;
      nvidia,tx-clk-tap-delau = <0x0>;
    }; 
 };

I have noticed that on my board the line linux,phandle = <0x80>; shows another value (0x7d if I don’t remember wrong - I’ll check tomorrow morning). Is that fine?

  1. When I recompile the dtb file, do I have to copy it from my TX2 into the host machine before running the flashing tool?
8

I have checked. After extracting the dtb, this is what I get concerning section spi@3240000:

spi@3240000 {
		reg = <0x0 0x3240000 0x0 0x10000>;
		dmas = <0x19 0x12 0x19 0x12>;
		interrupts = <0x0 0x27 0x4>;
		compatible = "nvidia,tegra186-spi";
		clock-names = "spi", "pll_p", "clk_m";
		reset-names = "spi";
		clocks = <0xd 0x4a 0xd 0x10d 0xd 0x261>;
		nvidia,dma-request-selector = <0x19 0x12>;
		resets = <0xd 0x2b>;
		status = "okay";
		#address-cells = <0x1>;
		phandle = <0x7d>;
		nvidia,clk-parents = "pll_p", "clk_m";
		#stream-id-cells = <0x1>;
		#size-cells = <0x0>;
		dma-names = "rx", "tx";
		<b>linux,phandle = <0x7d>;</b>
	};

As you see, linux,phandle = <0x7d>; has 0x7d instead of 0x80, as reported in the guide.
Would you say this might be an issue? Should I use 0x80?

After the patch, this is what I get:

spi@3240000 {
		reg = <0x0 0x3240000 0x0 0x10000>;
		dmas = <0x19 0x12 0x19 0x12>;
		interrupts = <0x0 0x27 0x4>;
		compatible = "nvidia,tegra186-spi";
		clock-names = "spi", "pll_p", "clk_m";
		reset-names = "spi";
		clocks = <0xd 0x4a 0xd 0x10d 0xd 0x261>;
		nvidia,dma-request-selector = <0x19 0x12>;
		resets = <0xd 0x2b>;
		status = "okay";
		#address-cells = <0x1>;
		phandle = <0x7d>;
		nvidia,clk-parents = "pll_p", "clk_m";
		#stream-id-cells = <0x1>;
		#size-cells = <0x0>;
		dma-names = "rx", "tx";
		linux,phandle = <0x7d>;
                spi@0 {
                  compatible = "spidev";
                  reg = <0x0>;
                  spi-max-frequency = <0x1312D00>;
                  nvidia,enable-hw-based-cs;
                  nvidia,cs-setup-clk-count = <0x1e>;
                  nvidia,cs-hold-clk-count = <0x1e>;
                  nvidia,rx-clk-tap-delay = <0x1f>;
                  nvidia,tx-clk-tap-delau = <0x0>;
                }; 
	};

Any idea?

Thanks.