Configuring SPI pins in Beaglebone AI

@Mahaboob ,

It seems I was a bit correct and incorrect. Anyway, Bone-Buses is still a thing so I realized after a new post in this forum: Beagleboard:BeagleBone cape interface spec - eLinux.org .

Please scroll down and see SPI as the reference.

Seth

P.S. Look below:

Directly_From_eLinux

Okay. So, what I thought was a reminder or nice things to come was nothing. See here:

/dev/bone/


/dev/bone
total 0
drwxr-xr-x 2 root root 80 Jan  1  2000 i2c
drwxr-xr-x 2 root root 60 Jan  1  2000 uart

I have no SPI devices listed as expected. Still trying!

Hey!


/dev/bone/spi
total 0
lrwxrwxrwx 1 root root 15 Feb  3 02:21 0.1 -> ../../spidev1.1

Is this it?


total 0
lrwxrwxrwx 1 root root 15 Feb  3 02:48 0.0 -> ../../spidev1.0
/dev/bone/spi

Okay. So, from what I can tell so far, one would need to adjust the board in this manner:

  1. git clone https://github.com/beagleboard/BeagleBoard-DeviceTrees
  2. cd BeagleBoard-DeviceTrees
  3. git checkout v4.19.x-ti-overlays
  4. make && sudo make install
  5. sudo nano /boot/uEnv.txt
  6. add your newly found .dtbo files like so:
    a. uboot_overlay_addr1=BONE-SPI0_0.dtbo

I say try one at a time until you are ready to BRICK your system. For some reason, I have not tried to use two .dtbo files at the same time.

Hi @silver2row ,

I followed the steps provided and checked /dev/ folder. I can observe the spi - spidev1.0, spidev1.1 interface.

root@beaglebone:~# ls -l /dev/bone/spi
total 0
lrwxrwxrwx 1 root root 15 Feb 3 14:48 0.0 → …/…/spidev1.0
lrwxrwxrwx 1 root root 15 Feb 3 14:48 0.1 → …/…/spidev1.1

I think I can able to write into spi interface but couldn’t able to read it. Seth Have you connected any spi Hardware and accessed it? Still, I couldn’t access the SPI Hardware.
Don’t know what’s going wrong. Let me revisit once again and check.

In previous posts say I tried adjusting using overlay but with am5729-beagleboneai-roboticscape.dts.

Thanks and Regards,

Mahaboob

Hello,

I have not connected any SPI device yet. I will have to try soon. I am sorry but this is as far as I got on this idea so far.

Seth

P.S. I think I have a SPI Cam around here somewhere. I can try. This will not happen right away but in the meantime, I can do the loopback tests on each/different SPI peripheral on the BBAI.

@Mahaboob @silver2row were you able to get the SPI interface enabled on BBAI? I am putting together a cape and want to add an Everspin MR25H256 MRAM chip. I can’t seem to get the SPI interface enabled at all. If I can get it working I will port the std Linux Everspin driver to 4.19 or 4.14 which ever I can get to work.

Thanks for any info you can provide

1 Like

Hello,

Not so far, i.e. as I do not have any testing module for SPI right now. I am not sure what @Mahaboob found so far after building and changing things in his personal DT file.

Seth

P.S. I should get around to it soon. @jostmp , I am looking into getting some type of hardware for testing soon. I will plug it in to the ole oscilloscope and try it out. Be ready for some odd photos of SPI functioning and also…

You can always do the loopback test of your SPI device by shorting the COPI CIPO pins.

I have been using the HiLetgo cheapy SPI logic analyzer(about $12) with Sigrok (Shareware)for a couple of years. Better than chasing SPI with a 2 channel o-scope. :slight_smile: I will keep pushing on the SPI interface. If I get something working I will post it.

1 Like

@jostmp ,

Hello…I promised some funny photos for loopback test and Chip Select. I cannot decipher them right now but I will update you soon. Also, /dev/spidev1.0 works in the loopback test on the AI.

Seth

P.S. Here is a photo w/ the CS line and CLK source on the /dev/spidev1.0 interface peripheral due to ExploringBB from Molloy’s book in Ch. 8 and his driver.

rigg

So, it seems when CS goes high, the CLK is doing business under the hood.

image

CS is most times active low. But not always. anyway if you are capturing with a two channel clock and data are what you usually want to see. I captured this for a bit banged SPI on PRU1_1. This is a screen capture from sigrok pulseview with the HiLetGo logic analyzer. You can see all four pins. CS goes low, clk starts driving, and MOSI data appears on D3.

Which pins are you monitoring with the scope?

1 Like

Hello @jostmp ,

Is that on the BBAI?

Seth

Yes, that is bit banging a SPI interface to a Maxim Integrated device using PRU1_1 pins P8.13,15,16,18. I am trying to enable Linux SPI interface to eventually read/write an MRAM chip from user space.

Hello,

I mean…from what I can tell, the devices are listed from the details of Bone-Buses if you add in the respective .dtbo files in the /boot/uEnv.txt file.

Seth

P.S. I am using P9.28/29/30/31 on the AI now for loopback from Molloy’s book.

I have yet to figure out the specific syntax to use.
enable_uboot_overlays=1
uboot_overlay_addr0=./dtbs/4.19.94-ti-r64/overlays/BONE-SPI1_1.dtbo

I have tried
=/lib/firmware/
=
and the above directory spec. All result in unable to find error. So I must be getting the syntax wrong.

loading /boot/dtbs/4.19.94-ti-r64/am5729-beagleboneai.dtb …
253052 bytes read in 7 ms (34.5 MiB/s)
uboot_overlays: [fdt_buffer=0x60000] …
uboot_overlays: unable to find [mmc 1:1 ./dtbs/4.19.94-ti-r64/overlays/BONE-SPI1_1.dtbo].

This was from seven days ago. Oh!

/dev/spidev1.0 is P9.17/18/21/22 and /dev/spidev2.0 is P9.28/29/30/31. I am pretty sure.

Seth

P.S. Try the instructions. At least for me, it worked. I can test w/ my o-scope which probably needs a source update. Blah. But soon after this update, I can get some more ideas out.

uboot_overlay_addr0=BONE-SPI1_0.dtbo
uboot_overlay_addr1=BONE-SPI0_0.dtbo

Yep, tried that. still get “couldn’t load overlay” errors. I have to run some errands but will be back to try more otions later.

Okay…

@jostmp :slight_smile:


uname_r=4.19.94-ti-r71
#uuid=
#dtb=

###U-Boot Overlays###
###Documentation: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays
###Master Enable
enable_uboot_overlays=1
###
###Overide capes with eeprom
uboot_overlay_addr0=BONE-SPI1_0.dtbo
uboot_overlay_addr1=BONE-SPI0_0.dtbo
#uboot_overlay_addr2=<file2>.dtbo
#uboot_overlay_addr3=<file3>.dtbo

That is my /boot/uEnv.txt file so far.

Seth

I had to specify absolute path to the overlay

The magic incantation:

copy the .dtbo file to /boot/dtbs/4.19.94-ti-r64/overlays directory

add this to uEnv.txt

enable_uboot_overlays=1
uboot_overlay_addr0=/boot/dtbs/4.19.94-ti-r64/overlays/BBAI-SPI0_1.dtbo

show-pins list the spi pins as active.
P9.18a 242 fast rx up 0 spi 1 d0
P9.21b 241 fast rx up 0 spi 1 d1
P9.22b 240 fast rx up 0 spi 1 sclk
P9.23 237 fast rx up 3 spi 1 cs1

CLK, MOSI, & CS all showing active on my analyzer. Connecting P9.18 → P9.21 would achieve loop-back if you are using an app that writes and reads.

Thanks for the help!

2 Likes

Hello,

Nice. I was unaware of the PATH to use and if that would work too. Now I know.

Seth

for folks that are having headaches with kernel hanging (BRICK) when loading a new overlay I found a quick work around.

need serial cable to access u-boot console
press space bar at startup to get u-boot prompt.
then edit capeloadoverlay environment variable and remove run loadoverlay;else from the command.
=> editenv capeloadoverlayif test -e ${devtype} ${bootpart} ${uboot_overlay}; then run loadoverlay;else echo uboot_overlays: unable to find [${devtype} ${bootpart} ${uboot_overlay}]…;fi;

delete that phrase hit enter, type boot, hit enter
=>boot

this allows the board to boot without loading the overlay. Fix overlay or edit your uEnv.txt to remove the overlay.

This has saved me a bunch of time. As you well know it is real easy to hang the BBAI with an overlay it doesn’t like.

edit: