Mainline Linux firmware with good network support.

942 views
Skip to first unread message

Neil Brown

unread,
Mar 30, 2019, 8:32:19 PM3/30/19
to GnuBee
With Linux 5.1 (which isn't quite released yet) we have good support for the network ports on the GnuBee.
Both ports on the Gnubee-PC1, and all three on the Gnubee-PC2 are independently usable.

Consequently I've decided that it is time to move on from the 4.4 kernels and start providing support for, and encouraging the use of, mainline.

Mainline isn't 100% working (just very close) so I have a few patches on top of the latest 5.1 Release Candidate.  The code that I'm building can be found in the "gnubee/v5.1" branch of https://github.com/neilbrown/linux.  I build a complete firmware image using my gnubee-tools package, found at  https://github.com/neilbrown/gnubee-tools.git
The README.md file for that package has useful information about how to work with this firmware.  It includes support for creating a brand new Debian installation without the need for a serial cable.

Prebuilt firmware images can be found that http://neil.brown.name/gnubee/

Note that if you are upgrading from a 4.4 installation, the network device names have changed and this can cause some confusion.  They were previously eth0.1 and eth0.2.  They are now ethblack and ethblue.
The initramfs code creates a new copy of the Debian "/etc/network" directory and edits the interface files so that the correct names are used.  This new copy is in a tmpfs filesystem which is mounted over /etc/network.  Once you decide to stay with 5.1, you should probably make the changes permanent.  If you aren't sure how, please ask.

I'll be updating code and images as new release-candidates come out, and will probably follow 5.1-stable for a while before switching to 5.2

Please report any problems, and also feel free to just let me know if you find this useful.

Brett Neumeier

unread,
Mar 30, 2019, 8:38:27 PM3/30/19
to Neil Brown, GnuBee
On Sat, Mar 30, 2019, 19:32 Neil Brown <ne...@brown.name> wrote:
With Linux 5.1 (which isn't quite released yet) we have good support for the network ports on the GnuBee.
Both ports on the Gnubee-PC1, and all three on the Gnubee-PC2 are independently usable.

That is really exciting news! Thank you for all of your efforts in providing support to all the other gnubee users. It is hugely appreciated!

Zenaan Harkness

unread,
Mar 30, 2019, 9:17:47 PM3/30/19
to GnuBee
Here here! Massive Acks all around! Thank you.

Todd Adam

unread,
Apr 3, 2019, 10:30:48 AM4/3/19
to GnuBee
I have tried this and can't get the recovery to work.  I press the black button on boot and can't get to 192.168.10.1.

Neil Brown

unread,
Apr 3, 2019, 6:39:21 PM4/3/19
to GnuBee

- Do you have the PC1 or the PC2?
- Are you holding the black button throughout the boot sequence?
- do you see the 'system' LED flashing with a 4:1 duty cycle (mostly on, briefly off)?
- are you connecting to the Black network port
- What IP address are you using on the computer you are connecting from?

Thanks for trying this firmware out!

If you see the system LED flashing with a 1:4 duty cycle (short flashes) then the init script didn't see the button as being pressed at the right time.

As an alternate to holding the button, you can create a FAT filesystem on a USB storage device, place a file called "gnubee-config.txt" in the top level directory, and place the line
CONFIGURE_NET=1
in the file.  Pluging this in has the same effect has holding the button.

Larry Pinney

unread,
Apr 3, 2019, 11:12:15 PM4/3/19
to GnuBee


On Wednesday, April 3, 2019 at 9:30:48 AM UTC-5, Todd Adam wrote:
I have tried this and can't get the recovery to work.  I press the black button on boot and can't get to 192.168.10.1.

If one is attempting to use the uboot TFTP recovery try 192.168.1.1 :

Our IP address is:(192.168.1.1)
Wait for TFTP request...

Todd Adam

unread,
Apr 4, 2019, 12:53:57 AM4/4/19
to GnuBee
I have a PC2
Not sure but when trying firmware there is only two led states the bottom on is solid or it is blinking.
Yes I'm connected to the black port
192.168.10.100
When using the config file I get the solid LED

Josef Vybíhal

unread,
Apr 4, 2019, 2:44:48 AM4/4/19
to GnuBee
Amazing job Neil! Really appreciate it. I have built it and after tinkering with network/interfaces, I was good to go with ethblack/ethblue (your sed in initramfs did not quite catch what I had defined there).

I have a question. I would like to enable FUSE, but I seem to not be able to get it compiled. It is probably because of my limited knowledge about kernel compiling, so sorry if this is not right place.

in kern_config/gbpc1-5.1 I defined CONFIG_FUSE_FS=m and hoped to be done. But after running gbmake firmware gbpc1-5.1-jv it just hangs and is doing nothing:

make[1]: Entering directory '/home/jv/git/github/gnubee-new/linux/jv5.1-fuse'
  HOSTCC  scripts/basic/fixdep
  GEN     Makefile
  HOSTCC  scripts/kconfig/conf.o
  HOSTCC  scripts/kconfig/confdata.o
  HOSTCC  scripts/kconfig/expr.o
  LEX     scripts/kconfig/lexer.lex.c
  YACC    scripts/kconfig/parser.tab.h
  HOSTCC  scripts/kconfig/lexer.lex.o
  YACC    scripts/kconfig/parser.tab.c
  HOSTCC  scripts/kconfig/parser.tab.o
  HOSTCC  scripts/kconfig/preprocess.o
  HOSTCC  scripts/kconfig/symbol.o
  HOSTLD  scripts/kconfig/conf
scripts/kconfig/conf  --oldconfig Kconfig
*
* Restart config...
*
*
* File systems
*
Validate filesystem parameter description (VALIDATE_FS_PARSER) [Y/n/?] y
Second extended fs support (EXT2_FS) [N/m/y/?] n
The Extended 3 (ext3) filesystem (EXT3_FS) [N/m/y/?] n
The Extended 4 (ext4) filesystem (EXT4_FS) [Y/n/m/?] y
  Use ext4 for ext2 file systems (EXT4_USE_FOR_EXT2) [Y/n/?] y
  Ext4 POSIX Access Control Lists (EXT4_FS_POSIX_ACL) [N/y/?] n
  Ext4 Security Labels (EXT4_FS_SECURITY) [N/y/?] n
  Ext4 debugging support (EXT4_DEBUG) [N/y/?] n
JBD2 (ext4) debugging support (JBD2_DEBUG) [N/y/?] n
Reiserfs support (REISERFS_FS) [N/m/y/?] n
JFS filesystem support (JFS_FS) [N/m/y/?] n
XFS filesystem support (XFS_FS) [Y/n/m/?] y
  XFS Quota support (XFS_QUOTA) [N/y/?] n
  XFS POSIX ACL support (XFS_POSIX_ACL) [N/y/?] n
  XFS Realtime subvolume support (XFS_RT) [N/y/?] n
  XFS online metadata check support (XFS_ONLINE_SCRUB) [N/y/?] n
  XFS Verbose Warnings (XFS_WARN) [N/y/?] n
  XFS Debugging support (XFS_DEBUG) [N/y/?] n
GFS2 file system support (GFS2_FS) [N/m/y/?] n
Btrfs filesystem support (BTRFS_FS) [M/n/y/?] m
  Btrfs POSIX Access Control Lists (BTRFS_FS_POSIX_ACL) [Y/n/?] y
  Btrfs with integrity check tool compiled in (DANGEROUS) (BTRFS_FS_CHECK_INTEGRITY) [N/y/?] n
  Btrfs will run sanity tests upon loading (BTRFS_FS_RUN_SANITY_TESTS) [N/y/?] n
  Btrfs debugging support (BTRFS_DEBUG) [N/y/?] n
  Btrfs assert support (BTRFS_ASSERT) [N/y/?] n
  Btrfs with the ref verify tool compiled in (BTRFS_FS_REF_VERIFY) [N/y/?] n
NILFS2 file system support (NILFS2_FS) [N/m/y/?] n
F2FS filesystem support (F2FS_FS) [N/m/y/?] n
Enable filesystem export operations for block IO (EXPORTFS_BLOCK_OPS) [N/y/?] n
Enable POSIX file locking API (FILE_LOCKING) [Y/n/?] y
  Enable Mandatory file locking (MANDATORY_FILE_LOCKING) [N/y/?] n
FS Encryption (Per-file encryption) (FS_ENCRYPTION) [N/y/?] n
Dnotify support (DNOTIFY) [N/y/?] n
Inotify support for userspace (INOTIFY_USER) [Y/n/?] y
Filesystem wide access notification (FANOTIFY) [Y/n/?] y
Quota support (QUOTA) [N/y/?] n
Old Kconfig name for Kernel automounter support (AUTOFS4_FS) [M/n/y/?] m
Kernel automounter support (supports v3, v4 and v5) (AUTOFS_FS) [M/y/?] m
FUSE (Filesystem in Userspace) support (FUSE_FS) [M/n/y/?] m

Can you please point me out to correct direction?

Dne neděle 31. března 2019 1:32:19 UTC+1 Neil Brown napsal(a):
With Linux 5.1 (which isn't quite released yet) we have good support for the network ports on the GnuBee.
Both ports on the Gnubee-PC1, and all three on the Gnubee-PC2 are independently usable.
...

Neil Brown

unread,
Apr 4, 2019, 8:15:52 PM4/4/19
to GnuBee
What should happen with the LEDs is:
They are off at power-on while u-boot initialized and checks to see if you plugged in a USB with a new gnubee.bin on it.
Then the system LED (lower down) blinks slowly about twice while it waits to see if you will type on the serial console to interrupt the boot.
Then system LED is solid on for about 15 seconds while the kernel is loaded and initialises all the hardware.
Then if it detects that the button is being presses, or finds a gnubee-config.txt with "CONFIGURE_NET=yes" then the system LED will blink on for 800msec and off for 200msec while listening for a network connection on 129.168.10.1 (block port).

If it doesn't detect the button or gnubee-config.txt it sets the system LED to blink 200msec on, and 800msec off while it searches for GNUBEE-ROOT.  If that is found the LEDs are switched off and boot continues.  If not it switches to 800-on, 200-off and runs a console shell.

So a solid LED for more than 20 seconds is surprising.

I just tried gnubee-5.1-rc3-gbpc2.bin on myu gnubee2 and it worked exactly as expected - though it is an early version with, for example, all the network ports black, so maybe there is a small hardware difference.

Do you have a filesystem labeled GNUBEE-ROOT on your gnubee at all?  If so, maybe try disconnecting all the storage hardware and see what happens then.

Neil Brown

unread,
Apr 4, 2019, 8:24:22 PM4/4/19
to GnuBee
Thanks for the encouragement!

If I understand correctly, it is the build process that is hanging - yes?

The last line it prints is:
    FUSE (Filesystem in Userspace) support (FUSE_FS) [M/n/y/?] m

??

I tried the same experiment and the next line should be:

  Character device in Userspace support (CUSE) [N/m/?] (NEW) m

at which point it waits for you to give an answer.
Are you running this build in a normal terminal window, or have you redirected output to a file or something else?
Are you running this on the gnubee, or are you cross-compiling?

I've added CONFIG_FUSE_FS=m and CONFIG_CUSE=m to my configs to the next firmware I build will have this support included.

L. D. Pinney

unread,
Apr 4, 2019, 10:56:17 PM4/4/19
to Neil Brown, GnuBee

This is the serial output from a PC1 using the shipped Das U Boot 
WITH the (black) RESET button held down during power up :

U-Boot 1.1.3 (Aug  7 2017 - 16:23:41)

Board: MediaTek APSoC DRAM: 512 MB

Config XHCI 40M PLL 
MediaTek SPI flash driver, SPI clock: 45MHz
spi device id: 1 2 19 4d
find flash: S25FL256S
*** Warning - bad CRC, using default environment

============================================ 
MediaTek U-Boot Version: 5.0.1.0-6
-------------------------------------------- 
ASIC MT7621A DualCore (MAC to MT7530 Mode)
DRAM_CONF_FROM: Auto-Detection 
DRAM_TYPE: DDR3 
DRAM bus: 16 bit
Xtal Mode=3 OCP Ratio=1/3
Flash component: SPI Flash
Date:Aug  7 2017  Time:16:23:41
============================================ 
icache: sets:256, ways:4, linesz:32, total:32768
dcache: sets:256, ways:4, linesz:32, total:32768 

 #### The CPU freq = 900 MHZ #### 
 estimate memory size = 512 Mbytes

 Reset MT7530
set LAN/WAN WLLLL
(Re)start USB...
USB0:   mtk-xhci: init hccr be1c0000 and hcor be1c0020 hc_length 32
Register 300010f NbrPorts 3
Starting the controller
USB XHCI 0.96
scanning bus 0 for devices... 2 USB Device(s) found
       scanning bus for storage devices... 0 Storage Device(s) found

 No USB Storage found. Upgrade FW failed!

Please choose the operation: 
   1: Load system code to SDRAM via TFTP.
   2: Load system code then write to Flash via TFTP.
   3: Boot system code via Flash (default).
   4: Enter boot command line interface.
   5: Load system code then write to Flash via USB Storage.
   6: Load system code then write to Flash via Httpd.
   9: Load U-Boot code then write to Flash via TFTP.                                                                              0 

   
3: System Boot system code via Flash.
RESET button pressed!
 
## Enter to Rescue Mode (manual) ##
(Re)start USB...
USB0:   mtk-xhci: init hccr be1c0000 and hcor be1c0020 hc_length 32
Register 300010f NbrPorts 3
Starting the controller
USB XHCI 0.96
scanning bus 0 for devices... ERROR: unexpected command completion code 0x11.

      USB device not accepting new address (error=80000000)
1 USB Device(s) found
       scanning bus for storage devices... 0 Storage Device(s) found

 No USB Storage found. Upgrade FW failed!

 NetTxPacket = 0x9BFB6CC0 

 KSEG1ADDR(NetTxPacket) = 0xBBFB6CC0 

 NetLoop,call eth_halt ! 

 NetLoop,call eth_init ! 
Trying eth2

 ETH_STATE_ACTIVE!! 
Using eth2 device

Our IP address is:(192.168.1.1)
Wait for TFTP request...
D D D D D D

--
You received this message because you are subscribed to a topic in the Google Groups "GnuBee" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/gnubee/YVM08lfWUUc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to gnubee+un...@googlegroups.com.
To post to this group, send email to gnu...@googlegroups.com.
Visit this group at https://groups.google.com/group/gnubee.
To view this discussion on the web visit https://groups.google.com/d/msgid/gnubee/5352d1dc-f594-4e70-a5ea-26d3f82e39dc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Neil Brown

unread,
Apr 4, 2019, 11:03:59 PM4/4/19
to GnuBee

Ahhh.. . that probably explains it, thanks.

So to use the black button to interrupt the firmware boot, you need to press it *after* the system LED has become solid green, and hold it until the LED starts blinking.
This is a 15 second window, so it should be easy to hit.

This still doesn't explain why the gnubee-config.txt method didn't work, but there is probably an explanation just waiting to be found.

Thanks!

L. D. Pinney

unread,
Apr 4, 2019, 11:20:26 PM4/4/19
to Neil Brown, GnuBee

AFAIK the RESET button does only one thing during U Boot ... namely TFTP recovery using the default address of 192.168.1.1

Also note that if you trigger HTTP recovery using the console (option 6) the same address is used.

U-Boot 1.1.3 (Aug  7 2017 - 16:23:41)
MT7621 # printenv
bootcmd=tftp
bootdelay=5
baudrate=57600
ethaddr="00:AA:BB:CC:DD:10"
ipaddr=192.168.1.1
serverip=192.168.1.2
stdin=serial
stdout=serial
stderr=serial
autostart=no
ethact=eth2

Environment size: 174/4092 bytes

Using setenv one may change the ipaddr and/or serverip if desired.
If you do so use saveenv to write your changes to the flash memory chip.

--
You received this message because you are subscribed to a topic in the Google Groups "GnuBee" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/gnubee/YVM08lfWUUc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to gnubee+un...@googlegroups.com.
To post to this group, send email to gnu...@googlegroups.com.
Visit this group at https://groups.google.com/group/gnubee.

Todd Adam

unread,
Apr 4, 2019, 11:56:19 PM4/4/19
to GnuBee
Yep that worked.  Not sure why the config file didn't work.

Josef Vybíhal

unread,
Apr 5, 2019, 2:27:39 AM4/5/19
to GnuBee

If I understand correctly, it is the build process that is hanging - yes?

yes
 

The last line it prints is:
    FUSE (Filesystem in Userspace) support (FUSE_FS) [M/n/y/?] m

??

I tried the same experiment and the next line should be:

  Character device in Userspace support (CUSE) [N/m/?] (NEW) m

at which point it waits for you to give an answer.
Are you running this build in a normal terminal window, or have you redirected output to a file or something else?
Are you running this on the gnubee, or are you cross-compiling?

I've added CONFIG_FUSE_FS=m and CONFIG_CUSE=m to my configs to the next firmware I build will have this support included.

 Indeed, I was missing CONFIG_CUSE, when added, it's building. Thanks, I should really improve my knowledge about kernel builds :)

Josef Vybíhal

unread,
Apr 5, 2019, 2:32:11 AM4/5/19
to GnuBee

Sorry fo double message. I missed some questions, and I should answer for clarity.


at which point it waits for you to give an answer.

I can not answer, It just shows this on stdin and is idle. I have to kill it via ctrl+c, and then kill other scripts that start after that, because generated .config is incomplete (hope I say that right)
 
Are you running this build in a normal terminal window, or have you redirected output to a file or something else?

Classic terminal, nothing fancy, no redirection. basicaly following your README from gnubee-tools.
 
Are you running this on the gnubee, or are you cross-compiling?

cross, Archlinux with cross-mipsel-linux-gnu-binutils 2.32-1 && cross-mipsel-linux-gnu-gcc49 4.9.4-1

Anyway, my hickup seems to be resolved. Thanks again.

Todd Adam

unread,
Apr 6, 2019, 11:33:28 AM4/6/19
to GnuBee
So I booted into recovery installed Debian with config command but it doesn't pull an ip with DHCP on the black port.


On Saturday, 30 March 2019 18:32:19 UTC-6, Neil Brown wrote:

Neil Brown

unread,
Apr 6, 2019, 8:25:33 PM4/6/19
to GnuBee

Please
- boot into recovery again,
- mount the root filesystem (e.g. mount /dev/sda1 /mnt)
- report the contents of /mnt/etc/network/interfaces.d/*

Thanks.

Todd Adam

unread,
Apr 6, 2019, 11:02:24 PM4/6/19
to GnuBee
01-lo 02-eth0-1 02-ethblack

Neil Brown

unread,
Apr 7, 2019, 8:10:38 PM4/7/19
to GnuBee
Those are the files in the directory.  I need to know what is in those files.
e.g.
  grep . /mnt/etc/network/interfaces.d/*



On Sunday, April 7, 2019 at 1:02:24 PM UTC+10, Todd Adam wrote:
01-lo 02-eth0-1 02-ethblack

Leo Crawford

unread,
Apr 10, 2019, 6:13:47 PM4/10/19
to GnuBee
Thanks loads for the work on this, it gives me the confidence to use the device for real work which I wouldn't have done before a mainline kernel. 

For info when using the latest build you've provided (http://neil.brown.name/gnubee/gnubee-5.1-rc4-gbpc1.bin) the `config` script relies on `swconfig` which isn't in the path, and `find` suggests isn't anywhere on the system. The fact this isn't copied then means that scripts like '/etc/network/scripts.d/no_switch' (which rely on it) fail.

I'll try going back through the older versions tomorrow and see if others work, but thought I'd share.

Leo

Neil Brown

unread,
Apr 12, 2019, 1:17:59 AM4/12/19
to GnuBee
Thanks for testing and reporting!

The  script doesn't really rely on swconfig.  If swconfiig doesn't exist (which it won't for mainline kernels) it does print an ugly error message, but still works correctly.
However, the network scripts were wrong - they should not be testing for dsa like that are. That was the real problem.

I've modified the scripts to check for the existence of swconfig and to be silent when it doesn't exist.  I've also fixed the network scripts.
I've replace the 5.1-rc4 firmware images with versions that include this fix.

Todd Adam: this explains the problem you reported too.  If you retry this the latest firmware, it should work better.

Leo Crawford

unread,
Apr 13, 2019, 7:52:32 AM4/13/19
to GnuBee
Thanks. I've seen the timestamp update on 5.1-rc4 firmware but appears identical. Hash of both seems to be 0bc33beca2456cac17ac9f48b59107f8. Have the updates made it to the site (http://neil.brown.name/gnubee/) OK? 

Neil Brown

unread,
Apr 13, 2019, 6:58:20 PM4/13/19
to GnuBee
Sorry, I think I must have rebuilt the pc2 firmware, but not the pc1.
The should both be uptodate now.

Thanks.

Leo Crawford

unread,
Apr 14, 2019, 3:19:05 PM4/14/19
to GnuBee
Works perfectly. Thank you for all your work and help.

Fred Rubble

unread,
Apr 28, 2019, 1:21:57 AM4/28/19
to GnuBee
So in the process of installing the newest RC but wondering if this improves the sata performance?


On Saturday, 30 March 2019 18:32:19 UTC-6, Neil Brown wrote:

scottjl

unread,
May 19, 2019, 12:40:41 AM5/19/19
to GnuBee
So I had a PC1 and PC2 both sitting around collecting dust. I meant to use them "some day" and that day finally arrived this week. Both had very out-of-date LEDE images which it seems support for is long gone. Actually it seems like the original developer has dropped the product entirely..?

Anyway, after finding this group and reading this thread it didn't take me too long to get both units up and running with 5.1-rc5. Both are running near identical configurations with 2tb drives, mdadm'ed up into a RAID 5 with 5+1 drives. It took 2 days for the arrays to build on each system and each reports just over 9tb of space free. Not really sure what I'll do with them, and several of the drives in them are old and have questionable life still in them. I installed several packages including samba and rsync for access and a few other minor things.

I just wanted to support my success story and many thanks to Mr. Brown for the firmware images. Where do I send the beer?

Eric Culp

unread,
May 19, 2019, 12:49:12 AM5/19/19
to scottjl, GnuBee
How did you build 5.1-rc5? neilbrown's branch (https://github.com/neilbrown/linux/tree/gnubee/v5.1) seems to be on 5.1-rc3?

--
You received this message because you are subscribed to the Google Groups "GnuBee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gnubee+un...@googlegroups.com.

To post to this group, send email to gnu...@googlegroups.com.
Visit this group at https://groups.google.com/group/gnubee.

scottjl

unread,
May 19, 2019, 12:52:53 AM5/19/19
to GnuBee
I didn't build it, there are pre-built images at http://neil.brown.name/gnubee/ as mentioned in the first post, 5.1-rc5 seems to be the latest there.

security researcher

unread,
Jun 3, 2019, 11:02:07 AM6/3/19
to GnuBee
Hi Neil,

Is there a list of patches you've applied to 5.1 ? Or better yet could be rebase your patches on top of 5.1 instead of merging in 5.1? That way it would be very easy to cherry pick your patches. I'm trying to build a 5.2-rc3 based firmware, but not sure if I need your patches or not.

Thanks.

Brett Neumeier

unread,
Jun 4, 2019, 8:33:55 AM6/4/19
to security researcher, GnuBee
On Mon, Jun 3, 2019 at 10:02 AM security researcher <sec.rese...@gmail.com> wrote:
Hi Neil,

Is there a list of patches you've applied to 5.1 ? Or better yet could be rebase your patches on top of 5.1 instead of merging in 5.1? That way it would be very easy to cherry pick your patches. I'm trying to build a 5.2-rc3 based firmware, but not sure if I need your patches or not.

Hello Security Researcher,

I don't know if this will help you at all, but I have done basically that already -- if you look at the bn-gnubee-v5.1 branch at https://github.com/bneumeier/linux.git, the patches on top of 5.1.7 are:

staging: mt7621-pci: use perst gpio instead of builtin perst
    -- this is an in-progress patch from Sergio Paracuellos to resolve some PCI issues

mmc: mtk-sd: enable internal write-protect logic.
mmc: mtk-sd: enable internal card-detect logic.
staging: mt7621-dts: update sdhci config.
mmc: mtk-sd: add support for config found in mt7620 family SOCs.
mmc: mtk-sd: don't hard-code interrupt trigger type
mmc: mtk-sd: support "voltage-ranges" setting.
mmc: mtk-sd: avoid error when second IO resource missing.
    -- these are patches from the gnubee/sdhci branch in Neil Brown's git

Update gnubee1 defconfig and add gnubee2.
Add gbpc2 dts file for the gnubee-pc2.
mt7621.dts: add pinctrl for sdhci
spi-nor: remove warning.
Add sample gnubee1 defconfig
ramips: fix some clocks in mt7621.dtsi
ramips: fix cpu clock of mt7621 and add dt clk devices
ramips: fix register range of memc node in mt7621.dtsi
    -- these are the patches from the gnubee/v5.1 branch in Neil Brown's git

That's essentially what I have running on my gnubee pc1 and pc2 -- the only difference being that I only just rebased that onto 5.1.7; my gnubees are running 5.1.5.

HTH

Brett

security researcher

unread,
Jun 4, 2019, 11:24:00 AM6/4/19
to GnuBee
Perfect! This is exactly what I need. Thanks much!

On Tuesday, June 4, 2019 at 7:33:55 AM UTC-5, Brett Neumeier wrote:

Alex Davies

unread,
Jul 31, 2019, 4:40:00 PM7/31/19
to GnuBee
I'm also having network issues, everything look right.

/etc/network/interfaces.d/01-lo:auto lo
/etc/network/interfaces.d/01-lo:iface lo inet loopback
/etc/network/interfaces.d/02-eth0-1:auto eth0.1
/etc/network/interfaces.d/02-eth0-1:iface eth0.1 inet dhcp
/etc/network/interfaces.d/02-eth0-1: pre-up /etc/network/scripts.d/set_switch
/etc/network/interfaces.d/02-ethblack:auto ethblack
/etc/network/interfaces.d/02-ethblack:iface ethblack inet dhcp
/etc/network/interfaces.d/02-ethblack: pre-up /etc/network/scripts.d/no_switch

Unfortunately I don't have the appropriate serial adapter right now, so I can't look at live output.

Alex Davies

unread,
Jul 31, 2019, 8:00:25 PM7/31/19
to GnuBee
Logs related to the problem, hopefully I had everything plugged into the correct ports on that run

Neil Brown

unread,
Aug 9, 2019, 7:19:36 PM8/9/19
to GnuBee

I've now build a 5.2.8 kernel. Kernel source, config files and prebuild images are available in the places described in the original post.

Luke Picciau

unread,
Aug 9, 2019, 7:39:21 PM8/9/19
to gnu...@googlegroups.com

Is it possible to upgrade to this version using apt? Or do I have to reinstall?

On 10/8/19 8:49 am, Neil Brown wrote:

I've now build a 5.2.8 kernel. Kernel source, config files and prebuild images are available in the places described in the original post.

--
You received this message because you are subscribed to the Google Groups "GnuBee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gnubee+un...@googlegroups.com.

Luke Picciau

unread,
Aug 10, 2019, 12:31:20 AM8/10/19
to gnu...@googlegroups.com

I just installed the latest version on a fresh SD card but it prints

cat: can't open '/mnt/gnubee-config.txt': No such file or directory
[   20.163309] Searching for partition GNUBEE-ROOT...
[   20.181277] Assembling md arrays
[   20.222487] random: crng init done
mdadm: No arrays found in config file or automatically
findfs: unable to resolve 'PARTLABEL=GNUBEE-CRYPT-ROOT'
findfs: unable to resolve 'LABEL=GNUBEE-ROOT'

While booting

On 10/8/19 8:49 am, Neil Brown wrote:

I've now build a 5.2.8 kernel. Kernel source, config files and prebuild images are available in the places described in the original post.

Luke Picciau

unread,
Aug 10, 2019, 3:21:37 AM8/10/19
to gnu...@googlegroups.com

Nvm I just forgot you have to run the config script after flashing the firmware.

Damon Lane

unread,
Aug 10, 2019, 9:27:53 AM8/10/19
to GnuBee
Hi Neil, thanks for the update! Did you leave the usb sound driver out of this version? I updated from 4.4 and lost sound.

aplay: device_list:270: no soundcards found...

modprobe: FATAL: Module snd-usb-audio not found in directory /lib/modules/5.2.8+

I know at least one other person was trying to use their gnubee as a music server. Previously I had added it myself, but it was nice and easy when you had included it.

Alex Davies

unread,
Aug 11, 2019, 1:52:31 PM8/11/19
to GnuBee
Not with apt, no. But as per the readme you can run `flashcp -v gnubee-pc1-4.4.174-1.bin /dev/mtd3` from a running system to update the firmware image.


On Friday, August 9, 2019 at 8:39:21 PM UTC-3, Luke Picciau wrote:

Is it possible to upgrade to this version using apt? Or do I have to reinstall?

On 10/8/19 8:49 am, Neil Brown wrote:

I've now build a 5.2.8 kernel. Kernel source, config files and prebuild images are available in the places described in the original post.

--
You received this message because you are subscribed to the Google Groups "GnuBee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gnu...@googlegroups.com.

Alex Davies

unread,
Aug 11, 2019, 3:07:42 PM8/11/19
to GnuBee
I solved my network issues by increasing the timeout in `/etc/dhcp/dhclient.conf`

```
timeout 3000;
retry 10;
```

worked for me.

Neil Brown

unread,
Aug 11, 2019, 6:45:51 PM8/11/19
to GnuBee
You cannot install with APT, but you don't need a full re-install either.
You just need to replace the firmware in flash.

What I do is:
 copy the firmware image onto my gnubee as, for example, /tmp/gnubee.bin
 copy it to flash with:  flashcp -v /tmp/gnubee.bin /dev/mtd3
 reboot
 copy modules to the root filesystem with: /lib/modules/keep

If anything goes wrong, I put old working gnubee.bin on a USB stick, plug that in
and reboot.  Then wait while the old firmware is automatically re-loaded.

Neil Brown

unread,
Aug 11, 2019, 7:07:50 PM8/11/19
to GnuBee
I did leave them out, but not on purpose.
New firmware images have been uploaded with lots of sound modules added.
Please test and confirm that it meets you needs.

Damon Lane

unread,
Aug 11, 2019, 7:53:11 PM8/11/19
to GnuBee
Thank you Neil, my music is back! And everything else seems normal.

antoine besnier

unread,
Sep 8, 2019, 8:10:38 PM9/8/19
to GnuBee
Hi Neil, 

Thanks for everything you do for the GnuBee support!
I tried to install the latest firmware (gnubee-5.2.8-gbpc1.bin). I suppose it installs well, but when I restart my GnuBee, all the lights are off. I can go in Rescue mode and run the config script, but if I restart, same problem; all lights off; and no connectivity.
Any idea what may happen?
Thanks!

antoine besnier

unread,
Sep 10, 2019, 7:31:14 PM9/10/19
to GnuBee
Well, I don't know what changed, but I tried again. Still no lights but connectivity restored! So I can happily enjoy a 5.2.8 kernel.

security researcher

unread,
Sep 24, 2019, 9:20:42 PM9/24/19
to GnuBee
Hi Neil,

Are there any thermal sensors on this board? I tried enabling CONFIG_THERMAL in the kernel config, but I don't see anything under /sys/class/termal. I was wondering if it would be possible to read CPU/RAM temp.

Neil Brown

unread,
Sep 25, 2019, 3:04:32 AM9/25/19
to GnuBee
I cannot help you here, sorry.
I'm not aware of any thermal sensors.
The limited documentation that I have on the MT761 SOC does not contain the word "thermal"
or anything else suggestive of temperature.

security researcher

unread,
Sep 25, 2019, 9:37:14 AM9/25/19
to GnuBee
No worries. Thanks for looking it up.
Another question.
If I enable CONFIG_BONDING will I be able to use ethblue and ethblack in a bonding interface ?
Also where can I find details about the soc's ehternet specs ? I see eth0, ethblue, ethblack.
I've never been clean on the ehternet part of the GnuBee.

Thanks

Neil Brown

unread,
Sep 25, 2019, 6:06:06 PM9/25/19
to GnuBee
The best I can offer is "probably - it is worth a try".

I assume you have the GB-PC1 ??  On the PC2 you would see an eth1 as well.

The frame engine in the MT7621  (which generates and accepts ethernet frames) has two ports.
On the PC1 only one is used.  It is internally connected to a 5-port ethernet switch.

Two of the other ports of this switch are connected to Ethernet PHYs (physical ports).
The kernel knows about this and provides ethblue and ethblack which represent those phys.
eth0 needs to be "up", but otherwise shouldn't be used.
You can use  ethblue and ethblack like normal network interfaces.
If you enable bridging, I think the kernel will ask the internal switch to do some of the
packet shuffling so that it doesn't have to.
I don't know if the kernel can offload anything when you configure bonding, but if not, then the
kernel will do whatever is needed.

Hope that helps.

security researcher

unread,
Sep 28, 2019, 1:55:32 PM9/28/19
to GnuBee
Thanks for the detailed explanation. It all makes sense now.

Alex Davies

unread,
Dec 14, 2019, 8:22:48 PM12/14/19
to GnuBee
It looks like the firmware images are down right now?

Pedro Bezunartea López

unread,
Dec 25, 2019, 8:52:38 PM12/25/19
to GnuBee


On Sunday, 15 December 2019 02:22:48 UTC+1, Alex Davies wrote:
It looks like the firmware images are down right now?

Yeap, the web hosting for neil.brown.name appears to be down.
Message has been deleted

Alex Davies

unread,
Dec 26, 2019, 12:27:09 PM12/26/19
to Pedro Bezunartea López, GnuBee
I've had a hard time building from sources, as the current guide assumes you're bootstrapping from a Debian system of the right architecture. I'd love to get a working buildroot image.

On Thu, Dec 26, 2019, 13:01 'Pedro Bezunartea López' via GnuBee <gnu...@googlegroups.com> wrote:


On Sunday, 31 March 2019 01:32:19 UTC+1, Neil Brown wrote:
With Linux 5.1 (which isn't quite released yet) we have good support for the network ports on the GnuBee.
Both ports on the Gnubee-PC1, and all three on the Gnubee-PC2 are independently usable.

Consequently I've decided that it is time to move on from the 4.4 kernels and start providing support for, and encouraging the use of, mainline.

Mainline isn't 100% working (just very close) so I have a few patches on top of the latest 5.1 Release Candidate.  The code that I'm building can be found in the "gnubee/v5.1" branch of https://github.com/neilbrown/linux.  I build a complete firmware image using my gnubee-tools package, found at  https://github.com/neilbrown/gnubee-tools.git
The README.md file for that package has useful information about how to work with this firmware.  It includes support for creating a brand new Debian installation without the need for a serial cable.

Prebuilt firmware images can be found that http://neil.brown.name/gnubee/

Is there a mirror of neil.brown.name/gnubee some where? I have successfully installed debian jessie using Neil's firmware and I'm missing the modules.

I will try to build them myself from Neil's sources in the meantime.
 

Note that if you are upgrading from a 4.4 installation, the network device names have changed and this can cause some confusion.  They were previously eth0.1 and eth0.2.  They are now ethblack and ethblue.
The initramfs code creates a new copy of the Debian "/etc/network" directory and edits the interface files so that the correct names are used.  This new copy is in a tmpfs filesystem which is mounted over /etc/network.  Once you decide to stay with 5.1, you should probably make the changes permanent.  If you aren't sure how, please ask.

I'll be updating code and images as new release-candidates come out, and will probably follow 5.1-stable for a while before switching to 5.2

Please report any problems, and also feel free to just let me know if you find this useful.

Using the USB-to-UART adaptor allowed me to set up the network and install debian jessie. No major issues.

Thanks again Neil, great job!

--
You received this message because you are subscribed to the Google Groups "GnuBee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gnubee+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gnubee/79582f22-9fe5-46df-a89c-8880c2b9384e%40googlegroups.com.

Neil Brown

unread,
Dec 28, 2019, 6:17:38 PM12/28/19
to GnuBee

neil.brown.name is back up again.  Sorry about that.

Alex Davies

unread,
Dec 29, 2019, 2:16:27 PM12/29/19
to GnuBee
 Thanks, I appreciate all the work you've done. When I bought the gnubee I didn't look into it too much, I knew it ran an embedded firmware and had "gnu" in the name so I assumed it would be a pretty simple process. I'm using it as part of an off-grid home, so it's a great fit for my use-case, but without your work I probably wouldn't have been able to use that hardware.

Also I'm getting "database error" when I try to access your site, so not quite back up yet :p

Neil Brown

unread,
Dec 29, 2019, 7:53:36 PM12/29/19
to GnuBee

Also I'm getting "database error" when I try to access your site, so not quite back up yet :p

Groan... sometimes I like being my own sysadmin.  Other times ....
I must have done an 'apt-get upgrade' and something when wrong, because mysqld just
wasn't work.  And I didn't notice.

So I've now done a dist-upgrade and have mariadb now, and it all seem to be working nicely.
Thanks.

Neil Brown

unread,
Dec 30, 2019, 2:45:39 AM12/30/19
to GnuBee


On Friday, December 27, 2019 at 4:27:09 AM UTC+11, Alex Davies wrote:
I've had a hard time building from sources, as the current guide assumes you're bootstrapping from a Debian system of the right architecture. I'd love to get a working buildroot image.

Motivated by this comment, I've added something new to my "gbmake" script in gnubee-tools.

If you run "gbmake chroot" before the test of the build (or at least before "gbmake initramfs"), it will use debootstrap to create a debian root file tree, and then copy files out of that .
The result is that you can build a complete "gnubee.bin" firmware without needing a GnuBee.
I've been testing this on my x86_64 openSUSE desktop and it seems to work well.  So you don't need debian or mips anywhere to create the firmware.

Adirelle

unread,
Dec 31, 2019, 7:12:03 AM12/31/19
to Neil Brown, gnu...@googlegroups.com
Hello,

By the way, would it possible to slightly change the default
modules/drivers included in your kernel config?

* There are no md modules at all, which seems to me a bit weird for a
kernel that should run on a NAS. Would it possible to include them along
with the raid modules (raid{0,1,10,456}, md-{mirror,raid}) ?

* I think there is no need for the RTC drivers since there is no RTC
chip on the board.

* I am not sure that the drivers for onboard ethernet NICs are useful at
all (beside MT's ones). I generally disable all of them.

Each time you publish a new version, I struggle to build it with those
changes applied. Would it be possible to enable the /proc/config.gz ?

Best regards,

Adirelle.
> --
> You received this message because you are subscribed to the Google
> Groups "GnuBee" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to gnubee+un...@googlegroups.com
> <mailto:gnubee+un...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/gnubee/5b667dfc-8b58-4fe1-85a3-70e4035be9a0%40googlegroups.com
> <https://groups.google.com/d/msgid/gnubee/5b667dfc-8b58-4fe1-85a3-70e4035be9a0%40googlegroups.com?utm_medium=email&utm_source=footer>.

Alex Davies

unread,
Dec 31, 2019, 1:05:58 PM12/31/19
to GnuBee
As long as we're making requests, I quite like the btrfs filesystem for use on a NAS. The in-line compression is great, especially if you're backing up a lot of source code and text. It would be good if the default firmware shipped with btrfs-progs.