Just to update you, the Amlogic GXL family has an interrupt controller that is able to monitor up to 8 interrupts. Each monitored interrupt can be falling or rising edge and monitoring both counts as 2 interrupts. So it’s very limited and reserved mostly for device-tree bound devices. You can look at the dtoverlays in the libretech-wiring-tool to see how it’s done. Due to the small number of monitorable interrupts, it is easy to exceed this if gpio_to_irq is enabled so upstream decided to leave that disabled for this SoC family. This effectively prevents gpiomon from working.
That works, thank you. I have been using spicc-ce1-ads7846-irq-22.dts and spicc-mcp2515-can0.dts as references to write overlays for PPS and the SC16IS752 (and ultimately more variants for SC16IS75x/76x) but have been short on time to work on it.
1 Like
Feel free to send a pull request if it is a mass market peripheral! As long as the licensing terms are compatible with GPL 2.0.
In this specific case it’s just a custom board for my personal use, but the SC16IS75x/76x family are commonly used SPI/I2C to RS232 from NXP (1 or 2 rs232 ports depending on variants) present on a number of Pi hats, and an overlay for PPS would be useful for anyone who wants to interface a GPS receiver to the S905x for timing purposes (ntp time server, etc.)
I will share the overlay files when they are ready and tested.
2 Likes
Maes, any update on an overlay for PPS? I’ve been trying to write one but get an error from the kernel that it can’t allocate an interrupt: pps-gpio pps: failed to map GPIO to IRQ: -6
1 Like
Hi Maes
I’ve checked out both the Raspbian and Ubuntu images and both seem to update to Linux aml-s905x-cc 6.0.19-02543-g73f2949c2dd9 #1 SMP PREEMPT_DYNAMIC Tue Feb 14 05:59:27 UTC 2023 aarch64 aarch64 aarch64 GNU/Linux if I remember correctly.
Trying to create and enable an overlay in either distro for pps-gpio with the recipe in:
Pps-gpio for s905x - Software - Libre Computer Hub
results in:
[ 531.161421] pps-gpio pps: failed to map GPIO to IRQ: -6
[ 531.161538] pps-gpio: probe of pps failed with error -22
Is this not supported on these boards?
Peter
I haven’t heard anything more from libre from my post. I know little about .dts, so I’m at my edge of understanding on the pps, GPIO and interrupt mapping. My recipe was distilled from docs and examples I found while searching and is my best guess. I did read that the s905x has an interrupt controller (two I think) which may add a layer to the .dts model that is in use from libre that I just can’t find docs about. The pps-gpio works like a charm on FriendlyElec H3 boards, so I have a nanosecond accurate clock via GPS running now. I’m simply trying to duplicate that setup on this board and the only barrier is the pps-gpio bit.
I ended up using my last Pi 3. They’re unobtanium but luckily I had one left. I have plenty of Potato boards for everything else. I was hoping to use the Potato as my NTP server too … perhaps someday.
Hi, LibreComputer!
Yesterday I was able to create gpio-keys overlay based on the example provided HERE
In my modified overlay there is no actual power button functionality (wakeup-source removed) as in example, but was just interested of getting events from push button press/release.
Then I continued to testing all GPIOX_x pins from 0 to 18 using the modified overlay and found out that GPIOX_6 and GPIOX_17 will hang up the system right after enabling the overlay with ldto and SSH connection drops (also the blue leds start blinking more rapidly). All other GPIOX_x’s were working as expected when using evtest and pressed push button.
Can you tell is there something special in these two GPIOX pins and should they work as all others? The issue happens always exactly same way for GPIOX_6 or GPIOX_17 right after reboot when there are no other overlays enabled.
This is my overlay used for testing:
/dts-v1/;
/plugin/;
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/gpio/meson-gxl-gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/interrupt-controller/meson-gic.h>
/ {
compatible = “libretech,cc”, “amlogic,s905x”, “amlogic,meson-gxl”;
fragment@0 {
target-path = "/";
__overlay__ {
gpio_keys: gpio-keys {
compatible = "gpio-keys";
#address-cells = <1>;
#size-cells = <0>;
power-button {
label = "Power Button";
linux,code = <102>;
interrupts-extended = <&gpio_intc MESON_GIC_GXL_GPIOX_6 IRQ_TYPE_LEVEL_LOW>;
linux,can-disable;
};
};
};
};
};
My board is aml-s905x-cc 2GB and it’s updated the latest distro:
Linux lepotato 6.1.26-05272-g26c406245a2c #1 SMP PREEMPT_DYNAMIC Thu Apr 27 10:15:40 UTC 2023 aarch64 GNU/Linux
There shouldn’t be anything special about those two. Are you resetting the overlays and rebooting before applying the new ones? This is where an UART cable gets handy.
Yes, I’ve tested each pin separately with following procedure:
- Reboot board
- Modify the overlay dts-file with desired GPIOX_x
- Execute install.sh script
- Enable newly builded overlay with ltdo
- Disable overlay with ltdo
- Continue with step 1 for next GPIOX_x pin
Merged overlays are not used to ensure that they won’t interfere the test. I can try test this using my 2nd board and different SD card. However, if someone else could also test is it a real issue or not.
UPDATE: The same issue happens also with the 2nd AML-S905X-CC SBC. One time after enabled the overlay I managed to got the following messages in SSH terminal before the disconnect:
May 26 05:21:50 lepotato sudo[717]: gevol : TTY=pts/0 ; PWD=/home/gevol/overlays/libretech-wiring-tool ; USER=root ; COMMAND=/usr/local/bin/ldto enable gpio-keys-gevol-input
May 26 05:21:50 lepotato sudo[717]: pam_unix(sudo:session): session opened for user root(uid=0) by gevol(uid=1000)
May 26 05:21:50 lepotato kernel: OF: overlay: WARNING: memory leak will occur if overlay removed, property: /symbols/gpio_keys
May 26 05:21:50 lepotato sudo[717]: pam_unix(sudo:session): session closed for user root
May 26 05:21:50 lepotato kernel: input: gpio-keys as /devices/platform/gpio-keys/input/input2
May 26 05:21:50 lepotato kernel: cpufreq: __target_index: Failed to change cpu frequency: -5
May 26 05:21:51 lepotato kernel: thermal thermal_zone0: failed to read out thermal zone (-110)
May 26 05:21:52 lepotato kernel: thermal thermal_zone0: failed to read out thermal zone (-110)
May 26 05:21:53 lepotato kernel: thermal thermal_zone0: failed to read out thermal zone (-110)
May 26 05:21:54 lepotato kernel: thermal thermal_zone0: failed to read out thermal zone (-110)
…
I also tried to create versions for GPIOX_6 and GPIOX_17 pins using the example overlay “gpio-key-power-7j1-31.dts” but only changing the file name and corresponding GPIOX pin in the file (–> gpio-key-power-7j1-29.dts and gpio-key-power-7j1-33.dts) The same issue than described above happens also with these examples and no change to even get to press the push button when enabled the overlay. So I kindly ask if Librecomputer could check with these pins on their end.
UPDATE2: Continued testing with GPIOAO_x pins → all pins are working as expected. However, the same symptoms than GPIOX_6 and GPIOX_17 are also found for pin GPIOCLK_0.
UPDATE3: Testing GPIOX_6 and GPIOX_17 pins for gpio-keys overlay with “ubuntu-22.10-preinstalled-base-arm64+aml-s905x-cc.img” → exactly same behavior than with Rasbian Bullseye. Now I was able to see from console window following error when enabled the overlay for GPIOX_6:
Based on all these findings and testing I would say that there is something wrong with GPIOX_6 and GPIOX_17 pins when trying to use them as gpio-keys overlay due to all other GPIOX_x and GPIOAO_x pins are working as expected.
GpioX_6 and GpioX_17 (pins 33 and 29 on the 40-pin header) are unique in that they are the only GPIO pins that have internal pull-down resistors.
All the rest have internal pull-up resistors, except for GpioDV_26 and GpioDV_27, which are marked as Open Drain.
I’m not sure how that might impact your project, but it is something unique about those particular pins.
OK, thanks for the information. I’m evaluating the board as an alternative for Raspberry Pi 3B+. My PCB is using pin 33 for the push button so new PCB design is then needed to use some other pin instead.
I should clarify. All the GPIO have both internal pull-up and pull-down resistors (approx 60kohms each). But, pins 29 and 33 are configured as pull-down by default and the rest are configured as pull-up by default. This is all internal to the S905 SOC. You can override the defaults.
Again, I’m not sure how/if this would affect your specific use case. I was just pointing out that there is this one difference with the 2 pins you are having issues with.
Lesson learned. This was crucial information, so by adding 4.7k pull-up resistors GPIOX_6 (pin 33) and GPIOX_17 (pin 29) the gpio-keys overlay started working OK for these pins as well. Apparently, the CPU stalled for continuous interruptions due to the internal pull-down resistors immediately when the overlay was enabled. Thanks again Tiki!
EDIT: @Tiki: Regarding to your comment “you can override the defaults” - do you mean that I could override this setting in the overlay somehow and then the external pull-up resistor would not be required?
What I meant is that if you are writing software that uses libgpiod you can set the bias on the GPIO pins when you configure them as inputs or outputs. You can also select whether inputs should be treated as active high or active low.
I believe you can also specify the bias for the GPIO pins in a custom overlay. But, I haven’t tried writing any overlays yet.
I am brand new to both Linux and single-board computing, so I’m hesitant to point you in the wrong direction. But, there is a post around here somewhere from LibreComputer where they linked to the source code on Github for the main device tree source (of course I can’t find it right now…). If you look through there, you will probably find some examples where they set the bias. You might also check the source code for some of the reference overlays.
This is correct. You can set default biases on GPIO pins. Just creat an overlay targetting the GPIO alias and add bias-pull-up.
Unfortunately it seems to be a lot harder in practise 
I tried the following for GPIOX_6 but with no success:
fragment@0 {
target = <&pwm_a_pins>;
__overlay__ {
mux {
bias-pull-up;
};
};
};
When enabling the overlay should the pin state change immediately or should it be merged to be happen during the boot?