Users needed to test LED and 3rd Port of GB-PC2 on OpenWrt

[Arınç ÜNAL]

Hey everyone.

I'm planning to update the GB-PC2 devicetree on OpenWrt. Currently it doesn't define the 3rd port on the device. I need anyone with a GB-PC2 to test whether the 3rd port works with my changes. For example, connect a computer to the 3rd port and try to ping GB-PC2 or vice versa. The IPv4 address of the GB-PC2 will be 192.168.1.1.

About LEDs, I'd like to confirm how many LEDs are on the device and how many or if any of them can be controlled by GPIO?

I see only two LEDs on the device schematics, PLED & SYS_LED which PLED is not wired to a GPIO pin, the other does not seem to be wired at all, so I already took the LED definitions out on the upstream devicetree:

https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/commit/?h=staging-next&id=5bc148649cf358d0cccf525452a4efbd4bc89a0f

Here are the images for GB-PC2 to test:

https://github.com/arinc9/openwrt/releases/tag/snapshot-gnubee_gb-pc2

Either boot the initramfs image on memory via tftp or flash the sysupgrade image.

You can check the devicetree changes here:

https://github.com/arinc9/openwrt/commits/gnubee_gb-pc2

[Jernej Jakob]

The schematics for the GBPC2 are inaccurate.
I did some reverse engineering of my actual hardware, I documented how
the LEDs are connected here

https://github.com/gnubee-git/GnuBee_Docs/issues/82#issuecomment-571585771

Unfortunately I don't have the time to test your images right now, I do
plan on updating my GBPC2 in the coming months so I could do it then.

[Jernej Jakob]

On Thu, 17 Mar 2022 13:42:39 -0700 (PDT)
Arınç ÜNAL <arinc...@gmail.com> wrote:

> Hey everyone.
>
> I'm planning to update the GB-PC2 devicetree on OpenWrt. Currently it
> doesn't define the 3rd port on the device. I need anyone with a GB-PC2 to
> test whether the 3rd port works with my changes. For example, connect a
> computer to the 3rd port and try to ping GB-PC2 or vice versa. The IPv4
> address of the GB-PC2 will be 192.168.1.1.
>
> About LEDs, I'd like to confirm how many LEDs are on the device and how
> many or if any of them can be controlled by GPIO?
> I see only two LEDs on the device schematics, PLED & SYS_LED which PLED is
> not wired to a GPIO pin, the other does not seem to be wired at all, so I
> already took the LED definitions out on the upstream devicetree:
> https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/commit/?h=staging-next&id=5bc148649cf358d0cccf525452a4efbd4bc89a0f

That is inaccurate at least for the GBPC2 hardware I have, all the LEDs
are wired and can theoretically be controlled from the SoC, even
BOTH the green LEDs next to the power switch. They DID work in a
previous kernel release (see my previous mail and the linked Github
issue) but stopped some time after 5.1. I don't know why, I opened a GH
issue for it as well, but it doesn't seem to have been picked up by
anybody.
When they worked, they were controllable via the gbpc1 sysctl's.
The yellow port LEDs never worked for me, Neil Brown did try to edit
the devicetree to get them to work according to my reverse engineering
findings, but I don't know if that went anywhere.

https://github.com/gnubee-git/GnuBee_Docs/issues/110
https://github.com/gnubee-git/GnuBee_Docs/issues/82
https://github.com/neilbrown/gnubee-tools/issues/28

[Arınç ÜNAL]

I have finally had some time to work on this. Here's what I understand:

• Green LED of black port
  • Used for showing the link activity.
  • I2C_SCLK/GPIO4
• Green LED of blue port
  • Used for showing the link activity.
  • I2C_SD/GPIO3
• Green LED of yellow port
  • Used for showing the link activity.
  • JDIO/GPIO15
• Orange LED of yellow port
  • Used for showing the link state.
  • JTMS/GPIO15
• Two green LEDs for power and system.
  • Power LED is always on, system LED shows disk activity.

If there arent any other LEDs, I will submit a patch adding all the LEDs above:

    gpio-leds {
        compatible = "gpio-leds";

        ethblack_act {
            label = "green:ethblack_act";
            gpios = <&gpio 4 GPIO_ACTIVE_LOW>;
        };

        ethblue_act {
            label = "green:ethblue_act";
            gpios = <&gpio 3 GPIO_ACTIVE_LOW>;
        };

        ethyellow_act {
            label = "green:ethyellow_act";
            gpios = <&gpio 15 GPIO_ACTIVE_LOW>;
        };

        ethyellow_link {
            label = "orange:ethyellow_link";
            gpios = <&gpio 13 GPIO_ACTIVE_LOW>;
        };

        power {
            label = "green:power";
            gpios = <&gpio 6 GPIO_ACTIVE_LOW>;
            linux,default-trigger = "default-on";
        };

        system {
            label = "green:system";
            gpios = <&gpio 8 GPIO_ACTIVE_LOW>;
            linux,default-trigger = "disk-activity";
        };
    };

Arınç

[Arınç ÜNAL]

Typo fix: JTMS/GPIO13

All the act and link LEDs won't work out of the box as there is no way to define the netdev trigger function on devicetree.

Enable with these commands:

echo netdev > /sys/class/leds/green:ethblack_act/trigger

echo ethblack > /sys/class/leds/green:ethblack_act/device_name

echo 1 > /sys/class/leds/green:ethblack_act/tx

echo 1 > /sys/class/leds/green:ethblack_act/rx

echo netdev > /sys/class/leds/orange:ethyellow_link/trigger

echo eth1 > /sys/class/leds/orange:ethyellow_link/device_name

echo 1 > /sys/class/leds/orange:ethyellow_link/link

[Arınç ÜNAL]

We've made the 3rd port work with Petr Louda's GB-PC2. Also, the two LEDs for the 3rd port are not controllable using GPIO13 and GPIO15 pins.

[Arınç ÜNAL]

I got a GB-PC2 of my own. I can control ethyellow port's orange and green LEDs with GPIO 13 and 15. Not sure why it didn't work before on others.

Anyway, I'll send a patch to mainline soon to address all this.

Arınç