Jump to content

Banana Pi R64

tkaiser

By tkaiser
in Off-topic

 Share

Recommended Posts

malvcr

malvcr

Posted
Posted

I didn't notice this board until yesterday.  There is another reference here:

 

https://www.cnx-software.com/2018/07/27/banana-pi-bpi-r64-router-board-is-powered-by-mediatek-mt7622-supports-802-11ac-wifi-poe/

 

By now, I have been working in an R2 based information system (not a router), and the machine works well.  I even have a Linux-based RAID-1, and I am using the cryptography capacity with ALF_ALG.  I am aware that the machine it is not a speed beast and that the RAID have throughput compromises because both SATA ports share the same PCIe line.  However, this is good enough for many applications as the one I have.  My point here is ... the R2 machine has a 4 core 32 bit CPU with 2GB RAM; then, why to make a 2 core 64 bit based machine but reduce the RAM to half?  In fact, in the current SBC world with limited resources, 32 bit based architectures are a better solution than 64 bit ones.

 

In my opinion, to create an application enhanced SBC in 2018 - 2019 needs to take into consideration the 4GB RAM ratio and, 4 or more cores.  This can open the usefulness of the machine in many areas.  And also must exist some IoT very small based devices with 1GB or less RAM, but not to produce a big bird with small wings.

 

The R64 machine it is very focused on the router application and sequential programming.  The R2 it is a better machine for general usage scenarios  (R1 was a prototype, not really useful machine).

 

PS.  To have only one SATA it is not so big deal.  In fact, it is better to add a hardware-based RAID complement as this one (https://www.amazon.com/RAIDON-iR2420-2S-S2-2-5-Inch-RAID-Storage/dp/B0065SMI3S/) .. just an example.

tkaiser

tkaiser

Posted
  • Author
Posted
23 minutes ago, malvcr said:

In fact, it is better to add a hardware-based RAID complement as this one

 

In fact I strongly disagree ;) . Hardware based RAID was always a problem (RAID controller being a proprietary single point of failure) and primitive RAID-1 is just a joke today: https://forum.openmediavault.org/index.php/Thread/18637-Home-NAS-build-FS-info/?postID=146935#post146935

 

Wrt R64... you know SinoVoip is just choosing random SoCs, then designing a board around and thinking the job will be done? I've no idea why they're doing so instead of focusing on SoCs they already support. But anyway: at least this approach (always choosing a new SoC on every new board they throw out) ensures initial software support will be crappy. Seems they think that would be something desirable.

 

Maybe the SoC can only cope with 1 GB RAM max since targeted at 'routers, home automation gateways, wireless audio and storage'? Who cares...

malvcr

malvcr

Posted
Posted

Thanks for the opinion about RAID ... I will check btrfs with care.

 

Really, I neither know why to have the R64.  The R2 it is advancing (slowly) but the R64 will just be a noise source as it is based in a different SoC.  From my point of view, I would prefer to wait at least another year to invest in the R2 platform before announcing that strange machine.  They need to learn from Raspberry people ... they are patient, they squeeze their machines capabilities to the maximum and then they evolve them a little obtaining solid devices.

 

By now I have the RAID1 just as a catastrophic security measure.  My system will make verified and versioned backups outside the system.  But if I can improve the general reliability with btrfs I will do it.  And thinking about it, here is where more cores make a difference.  Software RAID and redundant verified file systems need extra CPU work; when you have less cores, as with the R64, other concurrent areas will suffer.

 

chwe

chwe

Posted
Posted

pro:

  • mainline support for the mt7622 should be decent, for the people running such a 'routerboard' with a BSP kernel - I don't understand you guys... :D 
  • if you use it as a router/IoT 'masternode' I think, even with a 64bit userland linux 1gb ram should be ok-ish, if you mix it then with some NAS-stuff well it might be better that performance will suck then just to avoid that people do this.. :lol:
  • On 2/25/2018 at 3:24 PM, tkaiser said:

    bootloader commit suggests that the board will be equipped with 802.11ac (AC2600) Wi-Fi.

    according to cnx it's equipped with a MT7615 which should be a 4x4 2.4/5.0 GHz wifi-chip, let's hope that the driver is less garbage than for the one they put on the R2 (well, I was never interested in wifi there, but on this board it might make sense if you use it as a wifi router)

  • There's a SATA connector which is worth the name.. On the R2 this was a bit nasty (SATA power to this tiny little connector was never sold by sinovoip and also otherwise not that easy available, soldering iron and old molex adapters I never used did the trick. Pro tip: if you want to make some extra bucks you sell those adapters for 5$ each in your store... :lol:)

questionable:

  • performance of Ethernet (if it's similar to the R2 it will be the perfect companion for the RPi 3B+ you don't even need flow control :lol:, I saw that @frank-w has now the second gmac running on his 4.14 kernel, didn't check if this helps)
  • I saw something like 'laptop sata' written on CNX , in case this means 5V rails only.. this will be a missed opportunity (cause they removed the 12V rails on the R2 so that 3.5'' HDDs don't fit without a nasty powersetup).
  • u-boot is likely the same old one from 2014. At least, I didn't spot that mediatek pushed this stuff upstream (not understandable for me, cause they push their SoCs hard for mainline kernel but u-boot seems not to be on their todo list)

All in all, from a hardware point, this board doesn't look that bad (IMO it would make more sense to have a SFP cage instead of the 'wan' but that's more personal preferences). It all comes to the software support, kernel-wise this shouldn't be much an issue, if u-boot is the same that they used for the R2 (and chances are high cause it looks that this version of u-boot supports the MT7622 https://github.com/chwe17/u-boot-mt/blob/0c307e770fc2624ea0101766ec0c796f3432cd72/boards.cfg#L378), get it working shouldn't be that a hard anymore (if you need some inspiration, my repo is still there... :D). It will still be a horrible outdated u-boot but it should work. I think it might be possible to support those two SoCs with one kernelconfig/u-boot but that's just speculation. Let's see if someone is willing to bring the board up and running, contribution for the R2 from the armbian community was minor when I started with the board bring up. 

tkaiser

tkaiser

Posted
  • Author
Posted
32 minutes ago, chwe said:

Let's see if someone is willing to bring the board up and running

 

As part of Armbian? Are you kidding?

 

The Banana folks still do not provide 'documentation' or 'information', they still allow their copy&paste monkey to assemble random words and numbers to silly nonsense. Look at http://wiki.banana-pi.org/Banana_Pi_BPI-R64 (archived version). What's available on the mPCIe socket? USB? PCIe? How large is the board here? '148 mm × 100.5mm' which is somewhat different than the '120mm ×100mm' they list there (archived version). They're not even able to tell anyone something that simple as dimensions of their boards. They are not able to improve for whatever strange reasons. They simply don't give a shit about anything that would be important for externals to support their hardware. Nothing has changed within the last 3 years. It's unbelievable.

 

Next problem: Supporting a new SoC requires tons of efforts. Working on a SoC that is only used on one specific board is somewhat moronic especially if the board maker has no interest in supporting external communities (providing accurate documentation is most basic requirement).

 

Let's have a look at SinoVoip's SoC choices:

  • Allwinner A83T: Used on BPi M3 and not a single other SBC out there
  • Allwinner A33: Used on BPi M2 'Magic' and just one other board (Olimex A33-OLinuXino)
  • Allwinner R40: Used on BPi M2 'Ultra' and not a single other SBC out there
  • Allwinner V40: Used on BPi M2 'Berry' and not a single other SBC out there
  • MediaTek MT7622: Used on BPi R64 and not a single other SBC out there
  • MediaTek MT7623: Used on BPi R2 and not a single other SBC out there
  • Realtek RTD1296: Used on BPi W2 and not a single other SBC out there

They seem to be obsessed by the idea to choose exotic SoCs to ensure software support will be crappy. Why joining this club?

 

Their SoC choices require tons of efforts for no reason.

chwe

chwe

Posted
Posted
2 minutes ago, tkaiser said:

They seem to be obsessed by the idea to choose exotic SoCs to ensure software support will be crappy. Why joining this club?

See it positive.. They provide boards so that kernel devs can mainline all those SoCs.. :ph34r:  (I should start a second career in marketing :lol:)

 

6 minutes ago, tkaiser said:

Supporting a new SoC requires tons of efforts

I know, I did a bring up with the R2 and a features bring up with the RK3288 (CSI worked on my 'userbuild' before RockChip decided to trash their 4.4 kernel). Can't really say which one droves me more nuts, the tinkercam or the R2 ask @TonyMac32, he was the punching ball during both projects when I was frustrated.. From the kernel-side both SoCs are well supported in mainline which makes a bunch of stuff easier. Basic knowledge to deal with this version of u-boot is here, in case someone wants to deal with it I might have some tips. 

Question is more, is Debian/Ubuntu the right OS for a 'routerboard'? It will work for sure, but fact is that most people prefer LEDE/OpenWRT for their routers means that less people will help to increase the support. From a features point of view, the r64 makes more sense than the R2. I just don't see a reason to finish this work. Even testers are non-existing for the R2 here. 

tkaiser

tkaiser

Posted
  • Author
Posted
23 hours ago, parrotgeek1 said:

MT7622 appears to already be part of OpenWRT: https://github.com/openwrt/openwrt/tree/master/target/linux/mediatek/mt7622

 

Great! So buyers of this board know where to look for and whom to ask for support.

 

Wrt Armbian situation is a bit different since if we would start to support a new SoC family we need to play with all relevant kernel variants that are flying around to solve problems like IRQ affinity settings (since we hate hardware running slower than possible) or monitoring thermal situation (since we hate the idea users getting in trouble due to their devices overheating).

 

In the Banana wiki there's a kernel 4.4 and a 4.14 mentioned (no idea whether that's just the result of their copy&paste monkey doing silly things or if that's related to SoC reality). Then there's mainline support. Just walking through 3 different kernel families to get an idea what's working or not and what needs fixes is wasting more than a whole day.

chwe

chwe

Posted
Posted
On 7/30/2018 at 7:35 AM, parrotgeek1 said:

I will never buy anything with a phone/tablet SoC (3G IOT/4G IOT/BPI R2).

The R2 has an mt7623 which is for sure not a phone/tablet SoC... :lol: 

 

Actually, the R2 is quite well mainlined.. Not perfect but most features 'work' on mainline. I'm quite sure both SoCs could be maintained with one kernel (similar as we do for Sunxi in mainline). 

 

On 7/30/2018 at 7:14 AM, parrotgeek1 said:

Because of this I think it is very likely for this board to be a stable CSC (unlike R1/R2).

CSC boards for a SoC which doesn't have any wip or supported boards is IMO pointless. As shown in the 2G-IoT, nobody cares and maintains those boards/kernels. IMO this doesn't make sense, better the users chose a distro which maintains the board as they stick to a csc armbian which doesn't get maintained. Cause both SoCs are well mainlined I still hope that other boardmakers pick up these SoCs for some boards. Something like a HC1 could be made out of it.. :P 

1
tkaiser

tkaiser

Posted
  • Author
Posted
43 minutes ago, chwe said:

Something like a HC1 could be made out of it..

 

Same PCB to provide a HC1 and a HC2. Even with support for NBASE-T (2.5GbE):

 

MT7622-A-Block-Diagram.png

 

The remaining PCIe lane exposed as mPCIe allows users to add 2 or 4 more SATA ports and if such a thing would be priced competitively it would be very interesting.

 

@frank-w: Neither USB3 nor SATA are PCIe attached here.

frank-w

frank-w

Posted
Posted

I had thought that the system is similar to r2 (it is mentioned in r2-forum which is renamed now) and soc have similar number (mt7623 vs. mt7622 1 less).

moore

moore

Posted
Posted

mt7621: MIPS 1004k dual core, and two vpe for each core (880Mhz x 2)

mt7622: ARM CA53 dual core (1.35Gx2)

mt7623: ARM CA7 qual core (1.3Gx4)

 

Ryder.Lee

Ryder.Lee

Posted
Posted
On 7/29/2018 at 4:20 AM, chwe said:

u-boot is likely the same old one from 2014. At least, I didn't spot that mediatek pushed this stuff upstream (not understandable for me, cause they push their SoCs hard for mainline kernel but u-boot seems not to be on their todo list)

 

I've done for some basic support for MT7623N (based on the latest uboot version) - and have plan to submit the patches . 

But I can't give you any roadmap for that since I do it in my spare time and I have been doing a similar kind of work for the internal projects in parallel.

Ryder.Lee

Ryder.Lee

Posted
Posted
On 7/30/2018 at 1:14 PM, parrotgeek1 said:

But it's maybe 80% mainlined and the rest is in OpenWRT (except for HW NAT because they don't support that for any SoC).

Because of this I think it is very likely for this board to be a stable CSC (unlike R1/R2).

 

The best news is that the final patchset version for HNAT framework was accepted ( kernel 4.16) and it's based on nftables. - https://www.spinics.net/lists/netfilter-devel/msg50973.html


We will try to add netfilter-base HNAT support for MT7622 & MT7623  in the future.

1
Ryder.Lee

Ryder.Lee

Posted
Posted

Hello,

 

Add latest U-boot support for BPI-R2 & BPI R64 (not yet)

 

Status:

I’ve already sent the first round patches for MT7623n,  and the most of the drivers are based on mainline Linux, like clock, timer, mmc, pinctrl, watchdog, power domain and DTS.

 

I will also upstream U-boot  and ATF for MT7622 (BPI-R64) in the future.

 

The following are the major differences between Linux and U-boot:

-Modify the driver interface to adapt the U-boot DM framework.

-Remove unneeded DT nodes as they don’t have proper drivers in U-boot yet.

-Just add the basic functions (step-by-step) so that we can monitor the size.

-Reuse UART driver ns16550.c but add a highspeed register for MediaTek chips.

 

The current progress for R2:

-Boot from eMMC or SD card.

-ROM -> MediaTek preloder -> U-boot -> Linux

 

Todo list:

-Ethernet driver

-Other peripheral drivers.

-U-boot for MT7622

-ATF (arm trusted firmware) for MT7622

 

The patch sets:

-https://patchwork.ozlabs.org/project/uboot/list/?series=68601

 

How to build:

-make mt7623n_bpir2_defconfig; make

 

Ryder

1
Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept