Mainline Linux firmware with good network support.

[Neil Brown]

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]

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]

Here here! Massive Acks all around! Thank you.

[Todd Adam]

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]

- 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]

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]

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]

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]

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]

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]

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]

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]

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/gnubee/6f94d6bc-f323-4c09-9254-091a38cd6474%40googlegroups.com.

[Todd Adam]

Yep that worked.  Not sure why the config file didn't work.

[Josef Vybíhal]

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]

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]

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]

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]

01-lo 02-eth0-1 02-ethblack

[Neil Brown]

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]

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]

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]

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]

Sorry, I think I must have rebuilt the pc2 firmware, but not the pc1.

The should both be uptodate now.

Thanks.

[Leo Crawford]

Works perfectly. Thank you for all your work and help.

[Fred Rubble]

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]

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]

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/gnubee/7c0bf033-d06f-4bd9-8788-fa83354ab016%40googlegroups.com.

[scottjl]

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]

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]

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]

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]

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]

Logs related to the problem, hopefully I had everything plugged into the correct ports on that run

syslog: https://pastebin.com/3cnkDACT

kern.log: https://pastebin.com/ZTEa3RNq

messages: https://pastebin.com/Jy8gq658

[Neil Brown]

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]

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/gnubee/7b5fdf19-c8b9-44fb-9ecf-49de07033f62%40googlegroups.com.

[Luke Picciau]

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]

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

To view this discussion on the web visit https://groups.google.com/d/msgid/gnubee/5dc431eb-cd5d-c0cf-e9ee-57f8a0517d6c%40itscode.red.

[Damon Lane]

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]

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]

I solved my network issues by increasing the timeout in `/etc/dhcp/dhclient.conf`

```

timeout 3000;
retry 10;

```

worked for me.

[Neil Brown]

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]

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]

Thank you Neil, my music is back! And everything else seems normal.

[antoine besnier]

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]

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]

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]

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]

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]

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]

Thanks for the detailed explanation. It all makes sense now.

[Alex Davies]

It looks like the firmware images are down right now?

[Pedro Bezunartea López]

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.

[Alex Davies]

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]

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

[Alex Davies]

 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]

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]

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]

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]

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.

> an email to gnu...@googlegroups.com
> <mailto:gnu...@googlegroups.com>.

[Neil Brown]

The config that I use for building the firmware can be found in the gnubee-tools

package, in the kern_config directory.

All of the md modules should be present, except raid1 which is build in to the

kernel (no module needed).

I wonder why you don't see them...

For the other changes you suggest, I'd be very happy to receive a patch or pull request with any changes that you would like made.

I may make some of them myself

NeilBrown

[Neil Brown]

I'm not sure what you are asking for here ... the default firmware doesn't contain your root filesystem - which is where btrfs-progs might be installed.

Maybe you are asking for mfks.btrfs to be in the initramfs so you can create btrfs to install on to.  Is that right?

Is mkfs.btrfs all that you would need?

[Alex Davies]

Mostly when I'm in the default firmware it's because something has gone wrong. I would like to have my root filesystem on btrfs, although I recognize it's not critical. It just makes it easier for me to "version" different revisions of the rootfs-image, so I can roll back if I make a mistake or install something in a way that's hard to reverse.

mkfs.btrfs is good.

`btrfsck` is useful for obvious reasons, and is just a symlink to the main `btrfs` program, which takes up 916k. I think it's pretty important for a base image, if your FS root is btrfs-based. Between that and mkfs.btrfs we're doing good.

If we've got another meg to use, I'd also include `btrfs-select-super` and `btrfs-find-root`, but things would have to have gone pretty wrong before you'd need those, I think.

But yeah 508K for `mkfs.btrfs` and 916K for `btrfs` which includes btrfsck.

[Neil Brown]

I think you might have meant "dm" modules, rather than "md".  It is easy to confuse them.

I've just built and uploaded firmware images based on 5.4.6 and 5.2.21 which contain

all the dm modules, no RTC code, and various other changes.

(Alex: I haven't added btrfs tools yet)

As always, I welcome feedback - successes and failures.

[Adirelle]

Hello,

I am trying the 5.4.6 build and it seems to be working.

However I think I forgot to mention that I use extended ACLs on ext4 and
the module seems to be missing, so I get this on mount:

[   34.892383] EXT4-fs (dm-5): acl option not supported

Now that I have your 5.4 config file, I will try to rebuild it with the
ACL module.

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/04b90a9b-f02d-4108-8482-81b8c976ee43%40googlegroups.com
> <https://groups.google.com/d/msgid/gnubee/04b90a9b-f02d-4108-8482-81b8c976ee43%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Adirelle]

ACL handling is ok with the changes I included at the end of this mail.

The initramfs init script spits some errors (with both your and my
builds), see below. The grep, sed and cd should be easy to fix. I am
more concerned about the modprobe and ip ones.

Is there a quick way to rebuild the initramfs with a new init script to
test it?

[   22.192950] Run /init as init process
ln: /bin/wget: File exists
modprobe: module ahci not found in modules.dep
[   23.980293] usbcore: registered new interface driver usbfs
[   23.991418] usbcore: registered new interface driver hub
[   24.002230] usbcore: registered new device driver usb
[   24.020482] xhci-mtk 1e1c0000.xhci: 1e1c0000.xhci supply vbus not found, using dummy regulator
[   24.037812] xhci-mtk 1e1c0000.xhci: 1e1c0000.xhci supply vusb33 not found, using dummy regulator
[   24.055514] xhci-mtk 1e1c0000.xhci: xHCI Host Controller
[   24.066133] xhci-mtk 1e1c0000.xhci: new USB bus registered, assigned bus number 1
[   24.086150] xhci-mtk 1e1c0000.xhci: hcc params 0x01401198 hci version 0x96 quirks 0x0000000000210010
[   24.104444] xhci-mtk 1e1c0000.xhci: irq 20, io mem 0x1e1c0000
[   24.117458] hub 1-0:1.0: USB hub found
[   24.125216] hub 1-0:1.0: 2 ports detected
[   24.133979] xhci-mtk 1e1c0000.xhci: xHCI Host Controller
[   24.144651] xhci-mtk 1e1c0000.xhci: new USB bus registered, assigned bus number 2
[   24.159585] xhci-mtk 1e1c0000.xhci: Host supports USB 3.0 SuperSpeed
[   24.172483] usb usb2: We don't know the algorithms for LPM for this host, disabling LPM.
[   24.189791] hub 2-0:1.0: USB hub found
[   24.197445] hub 2-0:1.0: 1 port detected
[   24.219765] usbcore: registered new interface driver usb-storage
modprobe: module sd_mod not found in modules.dep
modprobe: module mtk_sd not found in modules.dep
modprobe: module mmc_block not found in modules.dep
modprobe: module ext4 not found in modules.dep
modprobe: module gpio_keys_polled not found in modules.dep
[   24.356891] input: gpio-keys as /devices/platform/gpio-keys/input/input0
[   24.399571] mtk_soc_eth 1e100000.ethernet eth0: configuring for fixed/rgmii link mode
[   24.415566] mtk_soc_eth 1e100000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[   24.432513] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[   24.652835] usb 1-2: new high-speed USB device number 2 using xhci-mtk
ip: SIOCGIFINDEX: No such device
[   24.844356] hub 1-2:1.0: USB hub found
[   24.851923] hub 1-2:1.0: 4 ports detected
[   26.887322] random: crng init done
modprobe: module md_mod not found in modules.dep
[   27.003722] Searching for partition GNUBEE-ROOT...
[   27.040328] Assembling md arrays
[   27.089713] md: md127 stopped.
[   27.121608] md/raid1:md127: active with 2 out of 2 mirrors
[   27.132809] md127: detected capacity change from 0 to 5368643584
mdadm: /dev/md/127_0 has been started with 2 drives.
findfs: unable to resolve 'PARTLABEL=GNUBEE-CRYPT-ROOT'
modprobe: module fs-ext4 not found in modules.dep
[   28.627206] EXT4-fs (md127): mounted filesystem with ordered data mode. Opts: (null)
[   28.651632] Partition GNUBEE-ROOT found. Starting...
grep: /mnt/root/etc/network/interfaces.d/*: No such file or directory
sed: /mnt/root/etc/network/interfaces.d/*: No such file or directory
/init: cd: line 84: can't cd to /mnt/root/etc/network/script.d: No such file or directory
===== Created temporary /etc/network to handle new interface names ======
ifconfig: SIOCGIFFLAGS: No such device
ifconfig: SIOCGIFFLAGS: No such device
ifconfig: SIOCGIFFLAGS: No such device

---

diff --git a/kern_config/gbpc1-5.4 b/kern_config/gbpc1-5.4

index 6848fdd..24408af 100644

--- a/kern_config/gbpc1-5.4

+++ b/kern_config/gbpc1-5.4

@@ -3000,7 +3000,7 @@ CONFIG_FS_IOMAP=y

 # CONFIG_EXT3_FS is not set

 CONFIG_EXT4_FS=y

 CONFIG_EXT4_USE_FOR_EXT2=y

-# CONFIG_EXT4_FS_POSIX_ACL is not set

+CONFIG_EXT4_FS_POSIX_ACL=y

 # CONFIG_EXT4_FS_SECURITY is not set

 # CONFIG_EXT4_DEBUG is not set

 CONFIG_JBD2=y

@@ -3010,7 +3010,7 @@ CONFIG_FS_MBCACHE=y

 # CONFIG_JFS_FS is not set

 CONFIG_XFS_FS=y

 # CONFIG_XFS_QUOTA is not set

-# CONFIG_XFS_POSIX_ACL is not set

+CONFIG_XFS_POSIX_ACL=y

 # CONFIG_XFS_RT is not set

 # CONFIG_XFS_ONLINE_SCRUB is not set

 # CONFIG_XFS_WARN is not set

[Neil Brown]

There is now 5.4.14 firmware on http://neil.brown.name/gnubee/

It include btrfs utils, better POSIX_ACL support, and a few other things.

On the PC2, the green LEDs for the first two lan ports can now be controlled, and the LEDs on the third port *might* be controllable.

It doesn't work for me, but I have a pre-release board (all the LAN ports are black!) so it might be a bit different.

Success/failure reports alway welcome.

[Alex Davies]

Awesome, thanks. Completely killed my motivation to get this working with buildroot ;p

[Ryan Mullen]

Hi Neil,

On Friday, January 24, 2020 at 9:11:47 PM UTC-5, Neil Brown wrote:

There is now 5.4.14 firmware on http://neil.brown.name/gnubee/

Success/failure reports alway welcome.

I really appreciate the work you put in here. I was able to use your gnubee-tools to cross compile the firmware 5.4 for a GB-PC2 and get a working Debian system with btrfs on a md raid5 target - your docs and scripts all worked well. The system isn't yet stable as am continuing to tweak the kernel config and Debian, but I just wanted to add my gratitude.

[Rob Johnson]

Hi.

I'm a bit stuck and I hope someone can point me in the right direction.  I had my Gnubee 1 all set up with Debian Jessie and OMV 3, on the 4.4 kernel.  Bit slow, but no issues.

Decided to update to a 5.x kernel.  But no matter what, I could never do anything other than boot into recovery.  Nothing appeared on my network in the 192.168.1 range, nor directly from my PC on 192.168.10.x (unless in recovery).

I don't have a serial cable (yet).

I've messed with interfaces.d, tried a few 5.x kernels, done the config script, everything.  I feel like I've done every combination of everything multiple times.  In the end I started from scratch, 4.4, but got it up to Debian Stretch and OMV 4.  All fine.  Tried a newer kernel, and couldn't get a peep.  Flash 4.4, all as was, fine.  Spent at least 16 hours on it yesterday and today!

Guidance appreciated!

[Neil Brown]

I assume you are using the same root filesystem and just trying to replace the kernel?

Probably problem is that network interface names have changed.  What do you have in interfaces.d?

[Neil Brown]

Firmware based on Linux 5.6.3 is now available.  Source code and pre-built images available at the same places as previously.

Headline feature this time is that the boot-time hang appears to be fixed.

Some people have reported that cold-boot (from power-off) would sometimes hang during the probing of PCI.  This seems to affect some boards more than others.  I have 2 GnuBee-PC1, one of which would hang 4 in 5 boots, the other hangs maybe 1 in 20 boots.

Anyway, thanks to the continuing work of Sergio Paracuellos, this now seems to be resolved.

With 5.6 we get the 'wireguard' VPN which some people might like to play with.

Have fun.

[Neil Brown]

Firmware based on 5.7 is now available.  No intereting Gnubee-specific changes.

[Hein Osenberg]

New kernels come every few weeks now! 

Thank you very much for putting so much work into the GNUBEE devices. This will help a lot keeping these nice little devices in service for the coming years.