New firmware with Linux 5.19.13

[Neil Brown]

New firmware images based on 5.19.13 are available at http://neil.brown.name/gnubee/

Source code for the kernel and gnubee-tools have been updated at github/neilbrown

There are still a few small patches needed to mainline linux to make the gnubee work.  Maybe we'll get there for 6.2.

I haven't testing this on the PC2 as my test machine died.  So if anyone does have a PC2 and tries this firmware, please report the results.  Particularly if the network all works.

Of course result for PC1 users are also welcome.

Some changes with 5.19:

By default the network interfaces on the PC1 are named "ethblack" and "eth1".

This is because the blue port no longer uses the internal switch but instead is connected to the second port on the internal buss.  The init code in my firmware renames eth1 to ethblue so you shouldn't notice the difference.

The leds have been renamed.  gb-pc1:green:system is now called green:power

gb-pc1:green:status is now called green:system.  That changed happened upstream and it seemed easiest to just live with it.

Have fun,

NeilBrown

[Brett Neumeier]

Tested on GnuBee PC2, works great.

I had to reconfigure my network interfaces to adjust for the interfaces being called `ethblack` and `ethblue`. I'm kind of surprised I didn't have to do that before, but it certainly was not hard. After the firmware does whatever renaming it does, `ip link` shows:

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1504 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether 6e:4d:31:97:5b:59 brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 90:50:5a:55:48:1e brd ff:ff:ff:ff:ff:ff
4: ethblack@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state LOWERLAYERDOWN mode DEFAULT group default qlen 1000
    link/ether 90:50:5a:55:48:1c brd ff:ff:ff:ff:ff:ff
5: ethblue@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 90:50:5a:55:48:1d brd ff:ff:ff:ff:ff:ff

I have not plugged anything into black or yellow, so I don't know whether those are actually working ... I will try that sometime soon, it's been a busy week so far.

I don't know what the expected behavior of the LEDs is, or how to test them. Is there a userspace program that controls how they are used? I am running debian 11.5, if that is significant. At present, the bottom LED is lit and the top LED is not lit, neither one seems to correlate to HDD activity.

I notice there is a lengthy delay during boot --

[    0.942727] io scheduler mq-deadline registered
[    0.951610] io scheduler kyber registered
[   19.952052] mt7621_gpio 1e000600.gpio: registering 32 gpios
[   19.964307] mt7621_gpio 1e000600.gpio: registering 32 gpios

I don't know if that is expected, it doesn't seem problematic to me but I thought it was worth mentioning.

If you have any specific questions, just ask! I am here.

--

Brett Neumeier (bneu...@gmail.com)

[NeilBrown]

On Fri, 21 Oct 2022, Brett Neumeier wrote:
>
> Tested on GnuBee PC2, works great.
>
> I had to reconfigure my network interfaces to adjust for the interfaces
> being called `ethblack` and `ethblue`. I'm kind of surprised I didn't have
> to do that before, but it certainly was not hard. After the firmware does
> whatever renaming it does, `ip link` shows:

That's probably my fault.
When we transitioned from the heavily patched 4.4 kernels to more
lightly patched mainline kernels, the device names changed from "eth0.1"
and "eth0.2" to "ethblue" and "ethblack".
I wanted people to be able to have a clean upgrade experience so I added
some code to the pre-boot scripts (in the initramfs) to check if
/etc/network/interfaces mentioned ethbl*. If it didn't then
/etc/network got replaced by a tmpfs mount which contained exactly the
same content, except eth0.1 was changed to ethblack and eth0.2 was
changed to ethblue.

I decided to remove that very recently
https://github.com/neilbrown/gnubee-tools/commit/69d42832194abd5f604790003b7dc9ae42e49d10
because I was removing all the old references to eth0.[12] as they
haven't been used for years.
But of course some people (like you) might still be using a root
filesystem which still have eth0.1 etc, and that will now not work.

I should restore that code, but get it to edit the files in-place rather
then doing it in a temporary tmpfs filesystem. Having the initramfs
edit the root filesystem seems a little unclean (and might be awkward as
it is probably read-only at this time), but it is probably the right
thing to do.

>
> I don't know what the expected behavior of the LEDs is, or how to test
> them. Is there a userspace program that controls how they are used? I am
> running debian 11.5, if that is significant. At present, the bottom LED is
> lit and the top LED is not lit, neither one seems to correlate to HDD
> activity.

The userspace program is "cat" to determine the current setting, and
"echo" to change it.

$ cat /sys/class/leds/green:power/trigger
none rfkill-any rfkill-none timer mtd nand-disk heartbeat cpu cpu0 cpu1 cpu2 cpu3 mmc0 activity [default-on] transient panic netdev mt7530-0:00:link mt7530-0:00:1Gbps mt7530-0:00:100Mbps mt7530-0:00:10Mbps rfkill0

You can see that "default-on" is selected. If you want to change to
e.g. "heartbeat" you could
echo heartbeat > /sys/class/leds/green:power/trigger

>
> I notice there is a lengthy delay during boot --
>
> [ 0.942727] io scheduler mq-deadline registered
> [ 0.951610] io scheduler kyber registered
> [ 19.952052] mt7621_gpio 1e000600.gpio: registering 32 gpios
> [ 19.964307] mt7621_gpio 1e000600.gpio: registering 32 gpios
>
> I don't know if that is expected, it doesn't seem problematic to me but I
> thought it was worth mentioning.

I've noticed that too. I think there has always been a delay, but 19
seconds does seem like a lot. I is likely that devices are being probed
during that time. It is fairly easy to enable some debug messages to
see if some particularly device takes a while to be probed. I'll try
that when I find some time.

Thanks,
NeilBrown