AML-S905X-CC Wiring Tool Overlays Description

This is a list of device tree overlays provided by the Libre Computer Wiring Tool and what they do.

If this document is not up to date, please let us know.

There are a lot more functionality not exposed in which you have to write your own overlay. These serve as simple references for you to get started with. You can reference Raspberry Pi’s overlays here. Decompile them with the dtc command and switch the compatibles, targets, buses, GPIOs, and interrupt. Most hardware will work but certain hardware features like I2S will not have matching pin positions due to differences in pinmux.


so by activating spicc.dts the spi pin 19-21-23-24 on the 40 pin should work just like it does on rpi?

Raspberry Pi SPI is usually the spicc-cs dtbo where /dev/spidev0.0 is enabled by pin 24 and /dev/spidev0.1 is enabled by pin 26. You can use the ./spidev-setup cs1

1 Like

If using the new raspbian distro image, would you still need to run the wiring tool and activate the right SPI to have the same pin layout and usage as the pi?

Yes, Raspberry Pi depend on the bootloader to read config.txt. Our bootloader does not read it at all. We are exploring creating a service to do it but that’s still in the conceptual stage at this point.


I have a PCF8523 RTC that I’ve previously used on Raspberry Pis. To use it on the aml-s905x-cc, should I be able to just change line 23 in i2c-ao-ds3231.dts to compatible = "nxp,pcf8523", build, install, and merge?

Try it and let us know. Check that the driver is in kernel and make sure the compatible exists. We don’t have the hardware.

Unfortunately, in the kernel you provide, you don’t include the module for this particular RTC. Would you consider adding it to the kernel config you are using? It’s part of the mainline device tree, so it should just require enabling it as a module (and looking at the kernel config in /boot, it lists it as an option-it’s line 7378 in the current 6.0.19 kernel).

This is enabled on the latest kernel. Please update your kernel in 24 hours and it should have this module.

That did it. The overlay worked with the update. I’ll clean up the header info and submit a PR to the Githup repository later this week.

1 Like

In regards to the I2S pinout differences, is this also applicable to the ROC-RK3328-CC?

I’m attempting to connect a simple PCM5102 DAC board. On Raspberry it uses pins 12 (BCK), 35 (LRCK) and 40 (DATA).

Are there limitations are which pins can have interrupts enabled on the Le Potato? I’ve tried adding the following to a .dts file (physical pin 37):

    tipi-reset-gpio = <&gpio 84 17>;
    interrupt-parent = <&gpio_intc>;
    interrupts = <94 2>;

I get the gpio description in a kernel module with gpiod_get and export it via gpiod_export + gpiod_export_link. Which all seems fine, except the exported sysfs artifacts do not have the ‘edge’ file which from the Linux docs indicates that the gpio doesn’t support interrupts…

Following up on @Matthew_Splett’s question, what is the recommended way to enable interrupts on GPIO pins? I am not familiar at all with Device Tree Overlays, and I would not know how to start writing one.

@technoryt, my repository is here: GitHub - jedimatt42/tipi_kernel_module: use modern linux kernel gpio access, if that helps. The wiring tool repository has Libre’s source for their device tree overlays. There are a few examples that include ‘interrupts’ but I’m not comprehending yet what is missing to get interrupt to work.

I also would like to add support for this RTC and I saw your submission in the git repository. So, here’s a stupid question: what steps did you take “update the kernel?”

You can use the meson-gic.h defines for the GPIOs.

Example of its use for Le Potato here.

For Renegade, you can just use this.

Ok, I’ve updated my project to use the C preprocessor to apply the includes and use the defines in the wiring tool repository, and that isn’t enough to get this to work. I know I’m getting the correct pin, as when I export it via sysfs I can loop over reading the ‘value’ file and see when my attached device sets it low. There is still no ‘edge’ file when exporting the gpio.

Now I have this: tipi_kernel_module/tipi_le_potato.dts at 0302facc0d517cba39a4b796b33b102ef1f98757 · jedimatt42/tipi_kernel_module · GitHub

    tipi-reset-gpio = <&gpio GPIOX_5 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
    interrupt-parent = <&gpio_intc>;

So, I tried going back to basics (still Le Potato) with the gpiod tools… I ldto reset my device tree overlays to remove what I had done, and rebooted. Then tried

gpioget gpiochip1 84

That’s fine. Then tried with:

gpiomon -l -f gpiochip1 84

and it replies: gpiomon: error waiting for events: No such device

My understanding is that this gpiod tool, gpiomon, is supposed to be using the /dev/gpiochip1 with ioctl calls to setup the interrupt and then poll it in a totally standards based way.

Le Potato does not support gpio_to_irq so userspace tools do not work, only overlays as IRQ interrupt monitoring is limited.

Overlays should work. You can watch interrupts via cat /proc/interrupts.

1 Like

Hello @librecomputer I am trying to use an MCP23017 chip on the i2c bus with the i2c-ao.dts overlay.

When I scan the i2c-1 but I only see the addresses of 0x30 and 0x50. I am looking for the address of 0x20 for the MCP23017 device. In the original raspbian image there is an overlay that is applied but I do not believe the original overlays are being applied.

Would you be able to help with accessing the MCP23017 via pins 3 and 5 over i2c please. Thank you!

Have you tried scanning i2c-0? I know if you merge rather than enable overlays it will swap the device numbers. It may happen in other circumstances too.

1 Like