MCP251x on P3448-0002 with L4T 32.5.1

I am trying to make some MCP251x SPI CAN thingies work on a p3448-0002 production board with a b00 carrier board. These are identified as such by the p3448 having eMMC instead of SD card and the carrier board has two camera connectors.

Flashed with the basic image, I find four SPI nodes under /dev. So far, so good.

Running some basic test software and monitoring pin 23 on the 40 pin header with an oscilloscope shows nothing no matter which of the devices I choose to “talk through”. This pin should be the clock of at least one of the SPI devices.

I looked into the p3448-0000 dtb file and noticed that, compared to the p3448-0002 dtb file, all the pins for SPI have the nvidia,tristate and nvidia,enable-input tags’ value flipped. Example follows:

			spi1_miso_pc1 {
				nvidia,pins = "spi1_miso_pc1";
				nvidia,function = "rsvd1";
				nvidia,pull = <0x1>;
				nvidia,tristate = <0x1>;
				nvidia,enable-input = <0x0>;
			};

			spi1_miso_pc1 {
				nvidia,pins = "spi1_miso_pc1";
				nvidia,function = "rsvd1";
				nvidia,pull = <0x1>;
				nvidia,tristate = <0x0>;
				nvidia,enable-input = <0x1>;
			};

EDIT: I’ve now come torealize the difference is, that the MCP251x DTBO files that are applied using the jetson-io tool enables the pins on the p3448-0000 versions, but they should be enabled by default on the p3448-0002 versions.

I also tried applying the mcp251x dtbo files directly to the base dtb file. This makes the system look for the chips, but they fail to find them.

Is there something wrong or am I doing something wrong? I am not a device-tree expert in any way!

NOTE 1: An identical setup with a p3448-0000 module was tested to see if it was a general issue and worked pretty much out of the box.
NOTE 2: I did the following:

$ sudo grep spi1 /sys/kernel/debug/tegra_pinctrl_reg
Bank: 1 Reg: 0x70003050 Val: 0x0000e044 -> spi1_mosi_pc0
Bank: 1 Reg: 0x70003054 Val: 0x0000e044 -> spi1_miso_pc1
Bank: 1 Reg: 0x70003058 Val: 0x0000e044 -> spi1_sck_pc2
Bank: 1 Reg: 0x7000305c Val: 0x0000e048 -> spi1_cs0_pc3
Bank: 1 Reg: 0x70003060 Val: 0x0000e048 -> spi1_cs1_pc4C: 0:2 1f 00 00 00 00 00 000000

$ sudo cat /sys/kernel/debug/tegra_gpio
Name:Bank:Port CNF OE OUT IN INT_STA INT_ENB INT_LVL
 A: 0:0 64 40 40 04 00 00 000000
 B: 0:1 f0 00 00 00 00 00 000000
 C: 0:2 1f 00 00 00 00 00 000000

From TX1 SPI1 is disabled in JetPack4.2.2 I would come to thing that all the C pins (which are most of the SPI pins) aren’t active. This is the state after I went into the dtb file and changed all the spi1_ and spi2_ pins from “rsvd1/2” to “spi1/2”.

Hi morten,
It’s not added for 0002 but you can try using dtbo from 0000. Copy tegra210-p3448-0000-p3449-0000-a02-mcp251x.dtbo of p3448-0000 into p3448-0002 and rename it to tegra210-p3448-0002-p3449-0000-a02-mcp251x.dtbo .
Also, change compatible in the dtbo:
compatible = “nvidia,p3449-0000-b00+p3448-0000-b00”, “nvidia,p3449-0000-a02+p3448-0000-a02”;
to
compatible = “nvidia,jetson-nano”, “nvidia,tegra210”;

Then run jetson-IO tool. New dtb should have all the settings for MCP.

'Lo!

First of all, thank you for replying!

Now a second thing: I dont believe the jetsion-io tool works with the eMMC versions. It has been reported elsewhere, and when you use it, the following happens:

$ sudo /opt/nvidia/jetson-io/config-by-pin.py 
Traceback (most recent call last):
  File "/opt/nvidia/jetson-io/config-by-pin.py", line 51, in <module>
    main()
  File "/opt/nvidia/jetson-io/config-by-pin.py", line 34, in main
    jetson = board.Board()
  File "/opt/nvidia/jetson-io/Jetson/board.py", line 147, in __init__
    self.name = _board_get(self.compat)
  File "/opt/nvidia/jetson-io/Jetson/board.py", line 81, in _board_get
    raise RuntimeError("No board data found!")

So what I did instead was to

  1. Update a freshly flashed Nano
  2. scp’ed the dtb and dtbo files from /boot to my local device
  3. dtc’ed them with the latest version of dtc and made the change, then dtc’ed them back
  4. combined them with fdtoverlay
  5. used the flash script to update the dbt on the system

This did not work, though.

In the mean time, due to time limitation, we have decided to go back to the SD card version for now. However, we still have to find a solution at some point, so any other ideas are still welcome.