Title: Device-tree overlay to enable SPI2 (SM_SPI2) on Luna SL1680’s 40-pin header
Board: Luna SL1680 SBC (Synaptics SL1680) OS: Common Torizon OS 7.5.0-devel-20260123143454+build.0 (scarthgap) Kernel: 6.12.11-Torizon (Linux torizon-winglet 6.12.11 #1-Torizon SMP PREEMPT)
What I’m trying to do:
Connect an AS5048A SPI magnetic encoder to the 40-pin header’s SPI2 pins (per the datasheet: pins 19/21/23/24/26 = SPI2_SDO/SPI2_SDI/SPI2_SCLK/SPI2_SS0n/SPI2_SS1n, internally SM_SPI2).
What I’ve found so far:
No /dev/spidev* node exists.
No SPI controller appears anywhere in the currently-loaded device tree (find /proc/device-tree -iname "*spi*" returns nothing at all — not disabled, genuinely absent).
No spi_master class entries, no SPI kernel module loaded.
The general “How to use SPI on Torizon” guide’s example overlay targets Verdin iMX8M Plus (&ecspi1, compatible = "toradex,verdin-imx8mp") — that syntax obviously doesn’t apply to the SL1680’s SoC family.
The Synaptics Astra SL1680 user guide confirms the header’s SPI is called SM_SPI2 in the SoC’s own pin-mux tables, but doesn’t give a Linux device-tree node label, path, or compatible string.
The Luna SL1680 datasheet itself notes the detailed pinout/overlay documentation is still “Coming soon.”
Question:
Is there a published (or example) device-tree overlay for enabling SM_SPI2 as a usable /dev/spidev* on the Luna SL1680’s 40-pin header? Specifically I need the correct SPI controller node path/label and compatible string for this SoC, equivalent to what &ecspi1 is for the i.MX8M Plus boards.
Happy to share more diagnostics (full /proc/device-tree dump, dmesg, etc.) if useful. Luna_SL1680
I might make mistakes or occasionally get you wrong. Our support team will step in if needed.
I don’t have specific documentation for the Luna SL1680 SBC in the available sources. The documentation I have access to covers Toradex System-on-Modules (SoMs) from the Colibri, Apalis, Verdin, Aquila, and SMARC families(1), which use NXP and Texas Instruments SoCs(1).
The Luna SL1680 uses a Synaptics SL1680 SoC, which is not part of Toradex’s supported hardware lineup in the available documentation. The device tree overlay examples and SPI enablement procedures documented are specific to Toradex modules(2)(3).
For the Luna SL1680, you would need:
SoC-specific device tree documentation from Synaptics that defines the SPI controller node name and compatible string for SM_SPI2
Pin control (pinmux) configuration specific to the SL1680’s pin controller
The correct device tree include files that define SL1680-specific macros
Since this board falls outside Toradex’s product scope, I recommend:
Contacting the Luna SL1680 manufacturer directly for device tree overlay examples
Checking the kernel source tree for synaptics,sl1680 or similar compatible strings in arch/arm64/boot/dts/ (or equivalent architecture directory)
Examining /sys/firmware/devicetree/base/ on your running system to identify the SPI controller node structure
I can help with Toradex-specific SPI configuration if you’re working with any of our supported modules.
Best regards,
Toradex AI Assistant.
Did you like my answer?
If I answered your question, please tick the “Solution” checkbox.
For follow-up questions to me, please use @ToradexAI in your post.
Add the device to SPI to have the spidev available
Here you can do something similar to what we do for our other devices, using the "rohm,dh2228fv" compatible string: aquila-imx95_spi1_spidev_overlay.dts
That’s very helpful, and matches what I found cross-checking the live device tree (i2c0/i2c1/uart2/uart3 all under the same apb@f7e80000 cluster as spi1).
I’ve hit a blocker trying to actually build the overlay: I used torizoncore-builder images download --remote-host to fetch the exact base image matching what’s running on our unit, but the download failed — our board is on a nightly prerelease build (torizon-docker-winglet-Tezi_7.5.0-devel-20260123143454+build.0), and that nightly has since been pruned from the artifactory retention window (only kept a few weeks).
What’s the recommended path here — is that specific nightly archived somewhere we could still pull it from, or should we update the device to a current nightly/stable build first and build the overlay against that instead? If the latter, any guidance on which channel/version to move to would help.
