In order to overlay the device tree file named spi_settings_rev02 on the beaglebone ai-64 board, refer to the URL and proceed as follows.
URL : BeagleBone Black Enable SPIDEV - eLinux.org
dtc -O dtb -o spi_settings_rev02.dtbo spi_settings_rev02.dts
cp spi_settings_rev02.dtbo /lib/firmware
Then, to enable the device tree overlay,
echo spi_settings_rev02 > /sys/devices/bone_capemgr.*/slots
I gave the command, but currently there is no bone_capemgr.*/slots on my device.
Therefore, when I looked for the path where the slots file was located, it existed in the following path.
/sys/devices/armv8_cortex_a72/caps/slots
/sys/bus/pci/slots
However, these are not all slots files directly related to device tree overlays.
So you can’t go to the next step, and you can’t overlay on the board.
If anyone has implemented a device tree overlay using a beaglebone ai-64 board, any help would be greatly appreciated.
Things are different for the BBAI-64.
Edit the file
/boot/firmware/extlinux/extlinux.conf
Depending on which SPI device you want to use you will need a line that says
fdtoverlays /overlays/BONE-SPI0_0.dtbo
Multiple overlays can be included on the same line, just separate them with a space.
The source for the devicetress is in (the dtb-xxxxx part depends on your kernel)
/opt/source/dtb-5.10-ti/src/arm64/overlays
If you need to write a custom overlay, put it there and then from /opt/source/dtb-5.10-ti run
make && make install
That will copy all the overlays to the correct location ( /boot/firmware/overlays )
If using spi_dev you will also want to edit and add spidev to the end of the file
root@BeagleBone:~# cat /etc/modules-load.d/modules.conf
# /etc/modules: kernel modules to load at boot time.
#
# This file contains the names of kernel modules that should be loaded
# at boot time, one per line. Lines beginning with "#" are ignored.
spidev
2 Likes
Thank you very much. Everything you said has come true.
If you have completed this process, you successfully overlaid the spi_settings_rev02 file on your BeagleBone ai-64 board?
now, Can I use it in the SPI initialization process after setting #define SPI_DEVICE “/dev/spidev1.0” in the executable code?
That depends.
If you do
ls -l /dev
does /dev/spidev1.0 exisit ? Check the group and owner of the device also.
You can also do lsmod to see if the spidev driver has loaded.
If both are there, then any software that uses spidev should work.
1 Like
Before checking spidev, after going through the above process and rebooting, the board could not be connected…
Do you know what the problem is?
Have you got a serial console cable that you can connect ?
What exactly was in your overlay file ?
Sound like it broke something.
If that is the case then you are probably going to need to boot of an SD card and either reflash the eMMC, or quickest option would be just to mount the eMMC file system after booting from an SD card and disable the overlay from loading.
1 Like
Did you happen to load spi_settings_rev02.dtbo on the bbai64, that was written only for the am335x beaglebone black… It would definitely cause a big issue on the bbai64, and break boot…
Regards,
1 Like
After flashing, there was a default file and a spi_settings_rev02.dtbo file.
So, after flashing the image file directly to the sd card, I changed the method to insert the sd card into the board and proceed.
LED No. 6 (power) also lights up, and No. 1 blinks well, but the serial setting part doesn’t work.
It was prepared based on beaglebone ai-64.
If you attach the contents of the written dts, it is as follows.
/* Enabling SPIDEV with cape manager : URL reference /
/ BeagleBone Black Enable SPIDEV - eLinux.org */
/* SPI6 /
/ D1 Output and D0 Input /
/ INPUT_PULLUP : 0x30, OUTPUT_PULLUP : 0x10 */
/dts-v1/;
/plugin/;
/ {
compatible = “ti,beaglebone”, “ti,beaglebone-ai-64”;
/* identification */
part-number = "spi6mux";
fragment@0 {
target = <&tda4vm_pinmux>;
__overlay__ {
spi6_pins_s0: spi6_pins_s0 {
pinctrl-single,pins = <
0x38 0x04 /* spi6_sclk.spi6_sclk(SCK) | MODE4 */
0x39 0x04 /* spi6_d0.spi6_d0(MISO) | MODE4 */
0x40 0x04 /* spi6_d1.spi6_d1(MOSI) | MODE4 */
0x28 0x04 /* spi6_cs0.spi6_cs0(SS) | MODE4 */
>;
};
};
};
fragment@1 {
target = <&spi6>;
__overlay__ {
#address-cells = <1>;
#size-cells = <0>;
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <&spi6_pins_s0>;
spidev@6 {
spi-max-frequency = <16000000>;
reg = <0>;
compatible = "linux,spidev";
};
};
};
};
Not sure where that file came from, but those pinmux values do not look right.
Looking at the various dts files 0x38 is going to configure P8.8 which does not have any SPI functionality on mux 4. 0x39 is just plain wrong as the address has to be 32 bit aligned. You can’t have odd addresses in there.
There are already 2 overlays for SPI.
BONE-SPI0_0.dtbo
P9.17 spi6_cs0
P9.22 spi6_clk
P9.21 spi6_d0
P9.18 spi6_d1
and
BONE-SPI0_1.dtbo
P9.23 spi6_cs1
P9.22 spi6_clk
P9.21 spi6_d0
P9.18 spi6_d1
I am pretty sure one of those should work for you, depending on which chip select you are using. In the above d0 (MOSI) is out and d1 (MISO) is in which I assume is how the BBB has them configured.
1 Like
Oh… I guess I was wrong.
I will put BONE-SPI0_0.dtbo in extlinux.conf and run it again.
I’ll flash again with the BONE-SPI0_0.dtbo file.
Thank you for answer.
The J721E_IOPAD macro takes 3 paramters, but the last 2 are just or’d together.
I believe that ultimately the pinctrl values are just register address and value to write there. Could be wrong though.
1 Like
The image file in the path was downloaded and flashed.
And the BONE-SPI0_0.dtbo file in it was reverse-compiled into dts.
Since my device is not rohm, compatible = “rohm,dh2228fv”; → compatible = “linux,spidev”;
I changed it.
Is this correct?
ah! Speaking of my final implementation purpose, it is to transmit card tag information of RFID RC522 module to beaglebone ai-64 board through SPI communication.
no leave that as is. it is just one of the quirks of using spidev
1 Like
Thank you, guys.
https://docs.beagleboard.org/latest/boards/beaglebone/ai-64/ch07.html#connector-p9
Also, referring to the above URL, I looked up the pin-out information of the BBAI-64 board, and it was confirmed as the value below.
P9.17 spi6_cs0 : GPIO pin 1 28
P9.22 spi6_clk : GPIO pin 1 38
P9.21 spi6_d0 : GPIO pin 1 39
P9.18 spi6_d1 : GPIO pin 1 40
Is it different from the site I saw?
No that is not right. You are probably looking at the BBB. The BBAI-64 is very different and a lot more complicated.
To complicate matters further some of the Pin headers are connected to 2 different pins on the MCU.
If you do a search on this forum for “bbai-64 pinmux spreadsheet” you will find a post I made with a spreadsheet containing the header pins and the various mux options for those pins.
You will see that some pins have 2 rows associated with them. Obviously you can only use the functions of one. The other pin needs to be set as a gpio input pin to stop conflicts. doing this has allowed for more options, but has increased the complexity a little.
Also if you are plugging wires into the P9 header, be aware that P9.1 is not at the top. The first 2x2 holes are USB connections. P9.1 row is inline with P8.1 row
1 Like
oh!! thanks for the nice answer
Additionally, is the BONE-SPI0_0.dtbo file created by flashing automatically applied without adding a command to the extlinux.conf file?