uarta.dts - uart a on pin 8 and 10 with flow control on pin 16 and 18
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.
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
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?
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).
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.
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?”
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.
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.
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.