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?
Merged and happens during boot.
Tried to merge and reboot but pull-up was not activated for some reason. Then tried to enable gpio-keys overlay for GPIOX_6 but again it stalled CPU. Should I combine the fragments in following way or how I get the pull-up working?
/ {
compatible = "libretech,cc", "amlogic,s905x", "amlogic,meson-gxl";
fragment@0 {
target = <&pwm_a_pins>;
__overlay__ {
mux {
bias-pull-up;
};
};
};
fragment@1 {
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;
};
};
};
};
};
ldto has the show and diff commands. Check the state of the DT with it.
ltdo diff:
--- CURRENT
+++ NEXT
@@ -57,12 +57,12 @@
kaslr-seed = <0x00 0x00>;
linux,uefi-mmap-desc-ver = <0x01>;
linux,uefi-mmap-desc-size = <0x28>;
- linux,uefi-mmap-size = <0x640>;
- linux,uefi-mmap-start = <0x00 0x576fd068>;
+ linux,uefi-mmap-size = <0x668>;
+ linux,uefi-mmap-start = <0x00 0x576fc068>;
linux,uefi-system-table = <0x00 0x7de81938>;
bootargs = "BOOT_IMAGE=/boot/vmlinuz-6.1.29-06024-g1987da89199c root=UUID=ba3ecd3b-3a6f-48f1-93e7-389921830f5d ro noquiet";
- linux,initrd-end = <0x00 0x5acc333d>;
- linux,initrd-start = <0x00 0x597be000>;
+ linux,initrd-end = <0x00 0x5acc233d>;
+ linux,initrd-start = <0x00 0x597bd000>;
u-boot,version = "2022.07+";
#address-cells = <0x02>;
#size-cells = <0x02>;
ltdo show:
pwm_a {
bias-pull-up;
phandle = <0x83>;
mux {
groups = "pwm_a";
function = "pwm_a";
bias-disable;
};
};
Does it look OK?
The bias is not changed.
I had made mistake with the overlay in previous compile but now tried with this again:
fragment@0 {
target = <&pwm_a_pins>;
__overlay__ {
mux {
bias-pull-up;
};
};
};
ldto show:
pwm_a {
phandle = <0x83>;
mux {
bias-pull-up;
groups = "pwm_a";
function = "pwm_a";
bias-disable;
};
};
bias-pull-up shows in correct place but why bias-disable is still there?
You need to delete the property in the overlay.
Tried this code but no effect:
fragment@0 {
target = <&pwm_a_pins>;
__overlay__ {
mux {
bias-pull-up;
/delete-property/ bias-disable;
};
};
};
You can not delete the property in the overlay since the property does not exist in the overlay. It has to be deleted during the compilation against the base device tree.
Does it means then to re-flash the bootloader?
In your /boot/efi/dtb/amlogic folder, decompile the device tree, edit it, and then recompile it in place.
Well, this was an instructive case! The recompilation was indeed successful (of course there were quite a lot of warnings?), but with the help of the decompiled and edited dts file, the bias-disable property could be removed and the bias-pull-up property could be set instead after reboot. In the end, enabling the pwm_a overlay caused the respective GPIO pin to go up state and after this I was able to enable the actual gpio-keys overlay for push button events without CPU stall issues.
I have been trying to follow along with these posts, but am confused. I cannot find a /dtb/ or /amlogic/ folder on my SD card with latest Raspian OS from Libre Computer installed. They do not appear under /boot/efi/ for me. What am I missing?
You can merge the overlay first and then the file will pop up.
Yes, merge the overlay first and meson-gxl-s905x-libretech-cc.dtb appears in /boot/efi/dtb/amlogic
I used this sequence:
Decompile DTB with command
sudo dtc -I dtb -O dts -o meson-gxl-s905x-libretech-cc.dts meson-gxl-s905x-libretech-cc.dtb
Edit decompiled .dts file (removed bias-disable property for pwm_a or similar)
Recompile DTB with command
sudo dtc -I dts -O dtb -o meson-gxl-s905x-libretech-cc.dtb meson-gxl-s905x-libretech-cc.dts
Reboot