Bootup failure

[Gerriko]

I am using the Pine SOQUARTZ board with the latest CLI (headless) Plebian Debian image.

I have a bootup failure, which I cannot resolve. It has happened on more than one occasion and I cannot figure out whether it is a random issue or something that was done during setup and overlay configuration. It never happens on first boot.

It happens at the exact same place, based on the bootup log stream (via UART):

[    3.708204] evm: security.ima
[    3.708476] evm: security.capability
[    3.708805] evm: HMAC attrs: 0x1

In a normal boot the next steps are triggered:

[    4.352737] dw-apb-uart fe660000.serial: forbid DMA for kernel console
[    4.365313] Freeing unused kernel memory: 6208K
[    4.421042] Checked W+X mappings: passed, no W+X pages found
[    4.421619] Run /init as init process
[    4.421959]   with arguments:
[    4.422235]     /init
[    4.422450]   with environment:
[    4.422738]     HOME=/
[    4.422959]     TERM=linux
Loading, please wait...
Starting systemd-udevd version 252.6-1

PS (Edit): I thought it might be linked to using "sudo reboot" but now looks more likely to be linked to an overlay file, which does not cause an error on load but seems to cause this issue.

[Gerriko]

Yes, this boot up failure is linked to my DTBO/DTS which contains a definition for an Interrupt pin. I am struggling to work out how to do this correctly.

I was using this RockPro64 example as guidance but something is causing this to crash the boot up

https://github.com/CounterPillow/overlay-examples/blob/main/rockpro64/pcf8574_interrupt.dts

I could not work out if these were valid for the Pine SOQuartz: reg = <0x20>;

gpio-cells = <2>;

    #interrupt-cells = <2>;     /* Required for interrupt controllers */

[Gerriko]

It turns out that Interrupts are handled by default (see pin-ctrl section and gpio0...gpio4).

https://kernel.googlesource.com/pub/scm/linux/kernel/git/thierry.reding/linux-pwm/+/for-next/arch/arm64/boot/dts/rockchip/rk356x.dtsi

Thus the #gpio-cells and #interrupt-cells lines are not needed at all within your overlay. I just need the reg, and interrupt-parent reference (to gpio0...gpio4) and interrupts offset number.

One thing I did notice is that the device tree compile program does not like it if you include:

include <dt-bindings/interrupt-controller/irq.h>

include <dt-bindings/pinctrl/rockchip.h>

Hence you cannot use interrupts = ; for example You have to use something like interrupts = <24 0x00>;

[CounterPillow]

Thus the #gpio-cells and #interrupt-cells lines are not needed at all within your overlay.

yes they are, they don't apply to the gpio controller and interrupt controller that is the spi peripheral device, not the gpio controller the interrupt is connected to.

One thing I did notice is that the device tree compile program does not like it if you include:

include <dt-bindings/interrupt-controller/irq.h>

include <dt-bindings/pinctrl/rockchip.h>

Hence you cannot use interrupts = ; for example You have to use something like interrupts = <24 0x00>;

You can use the constants and includes if you pass the file through the C preprocessor first, which the makefile does for you.

[Gerriko]

I don't know how to develop overlays well enough so you are probably right. I just don't understand why as I would have thought that using interrupt-parent = <&gpio4>; was sufficient in telling the system about #gpio-cells and #interrupt-cells.

Thanks for the guidance about using make process.

BTW, here is the overlay I was using which caused the bootup problem I'm guessing the likely causes here (as could not work out the problem):

• I had usedinterrupts = <131 0x01>; instead of interrupts = <3 0x01>;
• similarly, rockchip,pins = <4 131 0 0x00>; instead of rockchip,pins = <4 3 0 0x00>;
• or it could also have been caused by the inclusion of fragment@1
• or something different entirely.

/dts-v1/;
/plugin/;

/ {
    compatible = "pine64,soquartz", "rockchip,rk3566";

    fragment@0 {
        target = <&spi3>;
        __overlay__ {
            #address-cells = <1>;
            #size-cells = <0>;
            status = "okay";

            eth01: qca7000@0 {
                compatible = "qca, qca7000";
                reg = <0>;

                pinctrl-names = "default";
                pinctrl-0 = <&qca7000_int_pin>;

                interrupt-parent = <&gpio4>;
                interrupts = <3 0x01>;
                spi-cpha;
                spi-cpol;
                spi-max-frequency = <8000000>;

                #gpio-controller;
                #gpio-cells = <2>;

            };
        };
    };

    fragment@1 {
        target = <&pinctrl>;
        __overlay__ {
            qca7000 {
                qca7000_int_pin: qca7000-int-pin {
                    rockchip,pins = <4 3 0 0x00>;
                };
            };
        };
    };
};

[CounterPillow]

My guess is that whichever pin you ended up using as an interrupt pin was being used by something else that caused an interrupt storm as the interrupt kept firing whenever the level changed. Changing the added peripheral to not use interrupts naturally fixes the interrupt storm and therefore the lockup.

That's merely my theory though.

In general, always make sure you're using the right pin on the right controller, and the right trigger condition (level, edge, etc) and unless you absolutely need interrupts feel free to just not use them at all.