GnuBee Personal Cloud One

My NAS is now on Crowd Supply.

The GnuBee Personal Cloud One is now funding at https://www.crowdsupply.com

The 6 drive NAS uses a MT7621A SoC.

you have a first article here


maybe you could reply with some transfer numbers

Larry, Xiaoping, please don't take it the wrong way, in the world of over-priced and over-hyped home/personal file-servers your product is a breath of fresh air, but as history demonstrated has clearly thru demise of Novell, people want more than a file-server from their storage boxes and 512Mb of pre-soldered RAM just doesn't cut it.

I wish you all the luck and I hope your 1st gen product is very successful and you eventually release more powerful (with more RAM and/or user-installable RAM) gen 2 version when it's time for me to upgrade my HP N54L. :wink:

PS. Why aluminium and not "3d-printed" plastic case? Is it because of vibration?

Anyone get theirs yet?

Yes some Backers already have their units.

@neheb Do you have your unit now?

Arrived today actually. First impression was quite positive.

One thing I noticed is that the reboot command in LEDE is broken. It doesn't reboot the device.

Sorry about that it needs a patch applied that is apparently unacceptable upstream.

https://gogs.librecmc.org/ldpinney/GnuBee-libreCMC/src/v1.4-stage/target/linux/ramips/patches-4.4/0902-mediatek-4-byte-spi-reset.patch

Ah thanks for that.

I also happened to discover a huge performance bug with the ethernet driver on the GnuBee. Details on the LEDE mailing list. I think it affects all mt7621 units based on the comments in the driver but I have not tested others.

Yes ... I saw that.
It looks like that might apply to all mt7621 devices.

A few notes:

The USB3 port seems to be underpowered. It's doing 500mA when it should be doing 900mA. This is causing issues and data corruption. Dmesg shows the message as a USB reset. I can't use my Y cable as the other USB ports are in the back.

Speaking of which, why is there a hub for the USB2 port? Must be a use case that I don't see. Would be better to put a USB3 and a USB2 port next to each other partially because of what I said above.

Btrfs is useless on this. Data gets corrupted by itself. Probably no testing gets done on MIPS, just x86 and ARM.

It's slow. This shouldn't be a surprise but rsync gets ~4MB/s. It needs hardware acceleration badly, but that seems to come with mt7623, which is ARM.

This definitely needs a fan. My hard drives we're running at 45 C yesterday. The open enclosure doesn't seem to help much.

Love the serial cable. Makes it massively easier. Not in love with the default speed though. I know I can change it but flashing a bootloader is quite annoying.

Another issue, the time is drifting forward. This might hsve to do with the stock clock of 900MHz vs. 880Mhz.

I think the clock code in the current kernel is broken.

You can change the bootloader.
https://github.com/gnubee-git/GnuBee_Docs/tree/master/GB-PC1/firmware/uBoot
Or try setting 900 in the mt7621.dtsi

More info for hardware acceleration is available here

is flashing the bootloader as simple as unlocking the partition and using mtd write?

dd if=/dev/mtd0 results in a bigger file than the files in the github repo.

I think it's easier to use the Serial Console and the bootloader...

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.

Had no idea option 9 even existed. Will try later.

In other news, clock works fine after setting the proper clock in the DTS file.

edit: Any idea why "poweroff" or "halt" does not work? It seems to be an issue with all or more ramips devices.

The bootloader will always boot if power is present.
So ... 'halt' = 'reboot'

Looks like I'm getting silent data corruption on a daily basis on my RAID10 setup with 6 drives. btrfs and mdadm + ext4 show the same pattern.

My next strategy is to set the board to stock clocks (880MHz 1066 RAM) and see if that fixes it. If it does not, I'm abandoning this.

status update: RAM clock makes no difference. The clock speed does. Switching back to 880MHz solves everything. btrfs might not actually be a problem now.

still having issues with USB, even with a Y cable. I upgraded the PSU to a 12V 3.5A one but it doesn't seem to help. Maybe more is needed? I have a 12V 5A one that i could test with. We'll see.