BPI-R4 U-Boot 2025.07 breaks GPIO for LED

Banana Pi Router design BPI-R4/BPI-R4 Pro(MT7988)
1

Hi all,

I was playing around with a new U-Boot and I saw starting from 2024.01 there is a MT7988 support in mainline.

But this commit mediatek: mt7988: move gpio-controller up and rename pinctrl to pio · u-boot/u-boot@cd06e60 · GitHub changes the gpio structure in DTS:

-		gpio: gpio-controller {
-			gpio-controller;
-			#gpio-cells = <2>;
-		};
+		gpio-controller;
+		#gpio-cells = <2>;

Now if I want to define LEDs for the board I can’t compile a dtsi like this:

/ {
        compatible = "bananapi,bpi-r4", "mediatek,mt7988";

        keys {
                compatible = "gpio-keys";

                wps {
                        label = "wps/reset";
                        gpios = <&gpio 14 GPIO_ACTIVE_LOW>;
                };
        };

        leds {
                compatible = "gpio-leds";

                led_status_green: green {
                        label = "green:status";
                        gpios = <&gpio 79 GPIO_ACTIVE_HIGH>;
                };

                led_status_blue: blue {
                        label = "blue:status";
                        gpios = <&gpio 63 GPIO_ACTIVE_HIGH>;
                };
};

How can it be solved? One way was to revert this patch and using the code in dts, but how can be used with new configuration?

Kind regards, EasyNetDev.

2

Just use pio instead of gpio for the phandles

Just like in linux:

https://patchwork.kernel.org/project/linux-mediatek/patch/[email protected]/

The patch from Christian was to make the uboot driver compatible for linux dts (of_upstream).

Be aware that defining the leds may set eeprom readonly (green led must be off to allow writing to eeprom).

1 Like
3

Thanks @frank-w !

Moving from gpio to pio U-Boot compiled successful and also I can control the LEDs:

        leds {
                compatible = "gpio-leds";

                led_status_green: green {
                        label = "green:status";
                        gpios = <&pio 79 GPIO_ACTIVE_HIGH>;
                };

                led_status_blue: blue {
                        label = "blue:status";
                        gpios = <&pio 63 GPIO_ACTIVE_HIGH>;
                };
        }

Regarding the EEPROM, I know green LED is sharing a common physical circuit with EEPROM write protection. I saw it in the schematics and I know from OpenWRT firmware that is setting green LED to off to write in EEPROM.

The patch from Christian was to make the uboot driver compatible for linux dts (of_upstream).

That’s good also to know!

1 Like
4

Just wanted to note this…to not being surprised :slight_smile: i wondered why u-boot and linux behaved differently when not defining the gpio-leds…u-boot allowed writing where linux does not. So i added the gpio-leds patch to my series to allow also writing from linux.

1 Like
5

Right! :+1:. Indeed this is an issue :joy: if you don’t know it.