I’m currently trying to connect a SPI slave to the Aquila development board with an AM69 SOM, and apparently neither SPI interface is fully functional?
SPI1 and SPI2 are both listed in the run-time devicetree and come up as /dev/spidev1.0 and /dev/spidev2.0. At first glance it looks like the corresponding DTBOs are both loaded–although the “chosen” overlays do not match previously-documented formats, so I’m not sure how to interpret this:
root@gwaihir:~# hexdump -C /sys/firmware/devicetree/base/chosen/overlays/aquila-am69_spi1_spidev_overlay.dtbo
00000000 30 00 |0.|
00000002
root@gwaihir:~# hexdump -C /sys/firmware/devicetree/base/chosen/overlays/aquila-am69_spi2_spidev_overlay.dtbo
00000000 30 00 |0.|
00000002
From what we can tell with an oscilloscope, when we try to send SPI traffic over spidev1.0, we see SCLK and MOSI behave as expected…but CS is never asserted. When we try to send SPI traffic over spidev2.0, we don’t even see any activity on its SCLK.
Are these DTBOs expected to be complete in scarthgap 7.2? Based on the sysfs values quoted above, have they been successfully loaded at run-time? (How should we interpret those sysfs values, anyways?)
For reference, tdx-info reports:
Software summary
Bootloader: U-Boot
Kernel version: 6.6.84-7.2.0-devel-g8bf00740f043 #1-Torizon SMP PREEMPT Thu Mar 27 16:42:10 UTC 2025
Kernel command line: root=LABEL=otaroot rootfstype=ext4 quiet logo.nologo vt.global_cursor_default=0 plymouth.ignore-serial-consoles splash fbcon=map:3 ostree=/ostree/boot.1/torizon/cab77ab08b74a6aaaaf11e1789d0dae2d8fcecdead853b841e6b8d43a71c7eb5/0
Distro name: NAME=“Torizon OS”
Distro version: VERSION_ID=7.2.0-devel-20250407145936-build.0
Distro variant: VARIANT=“Minimal”
Hostname: gwaihir
Hardware info
HW model: Toradex Aquila AM69 on Aquila Development Board
Toradex version: 0088 V1.0A
Serial number: 12593347
Processor arch: aarch64
Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!
Did you like my answer?
Hello!
It seems that the Aquila AM69 SPI device tree overlays are not currently listed in the pre-built overlays documentation. This might indicate that they are not fully implemented yet. You can check the list of pre-built overlays here: Pre-built Overlays Documentation.
For working with device tree overlays in general, you should ensure the following:
- You have a
.dts source file and a compiled .dtbo binary file. More details can be found here: Device Tree Overlays Overview.
- The overlay should be deployed to the
/boot/dtb/overlays/ directory.
To verify if an overlay is properly loaded, consider these steps:
- Ensure the overlay binary is loaded by the bootloader and bound to the kernel at boot time.
- Check that the overlay appears in your system with the correct configuration.
Since the Aquila AM69 is a newer module, it might be helpful to keep an eye on updates for device tree overlays in future releases.
If you need further assistance or a general approach for working with device tree overlays on Toradex modules, feel free to ask!
Best regards, Toradex AI Assistant.
And…I’m just now realizing the “chosen” overlay attribute does match the documented format, it’s just null-terminated instead of newline-terminated. So that’s one less question to address.
Hey @jarndraugr,
SPI requires the child node to be included for each SPI slave device. Have you added your SPI device to the device tree?
Here is the device tree binding, you can see an example.
https://git.toradex.com/cgit/linux-toradex.git/tree/Documentation/devicetree/bindings/spi/spi-bus.txt
-Eric
A little bit. For background, we’re strictly using our SPI slave device(s) from userland code, so we haven’t bothered adding anything beyond the basic overlay for the SPI master interfaces. Our initial testing was just scoping the lines while sending out basic messages from the master with spidev_test.
For some reason, this started working as expected a day or two later, but not without hiccups. On one boot cycle it seemed spidev1.0 and spidev2.0 were reversed, such that spidev1.0 transactions were coming out the SPI2 pins on the board. On another boot cycle the spidev ordering apparently swapped back to normal.
For now, it seems to be working as expected. We’ve been able to hook up a SPI slave and received what looks like correct responses. We’re still a little concerned that the SPI links went from non-working, to swapped, to working normally, apparently without us changing anything.
hey Frank,
On spidev swapping, I found an ticket that explains this behavior exactly (and verified solution).
https://community.toradex.com/t/spidev1-0-and-spidev2-0-initialisations-are-swapped-on-some-device-starts/24161
Eric Singer
Toradex
Hey Frank,
Was this a good solution for you?
Thanks
Eric Singer
Toradex
So far, so good. I delved into the existing udev rules and found the /dev/aquila-spi*-cs* symlinks, so that sufficiently addresses the interface swapping issue.
As far as the original issue of individual SPI pins not working, we haven’t been able to reproduce it since then. We have since connected a SPI slave device with a level shifter and seem to be consistently getting appropriate signals on all pins.
