3 3
chwe

BananaPi R2 (.csc mt7623 as new boardfamily)

Recommended Posts

On 11/27/2018 at 7:49 PM, frank-w said:

i've got second gmac working in 4.19

I tried to 'steal' your patches.. at the moment 'ip a' shows the interface whereas ifconfig has still issues and somehow the interface doesn't come up.. I 'assume' it's currently a networkD issue. but well.. We'll see... A patch series for bringing up HDMI is also on my local repo but I don't feel comfortable to push it cause I've no possibility to test it (I don't even understand why I prepared it cause my interest in it is non-existing and my willingness to debug it in case it doesn't work is below that). Maybe tomorrow.. who knows.

Share this post


Link to post
Share on other sites

This is a picture with an R2 located in a RACK assembly.

 

20190129_105300.thumb.jpg.75bd0bfc2db52d85326993466d99ccaa.jpg

 

The set has an Orange Pi Zero as a "communication/firewall device", together with a Banana Pi M2+ as the Application Server and the Banana Pi R2 (v1) as a Database/NFS/ClamAV server.  I am configuring a Moodle on the machine.

 

As a recommendation from TKaiser in a previous post, the R2 it is managing two 2TB hard disks with BTRFS and not RAID1 (really it is smoother and easier to configure than a software RAID).  The disks power it is provided directly by the 430W power supply (not the R2 power connectors) ... I know this is as a 12 cylinder engine in a Beetle :-) ... The enclosure has 3 fan, so no machine arrive to 50C degrees.

 

It can be improved.  There are details, but in the future things will be better.  In this moment only the power led it is attached to something, and the Power Supply has a wire in the CPU connector to "simulate" something there (if not, the Power Supply will not work).  The machines are located in a presentation cardboard piece painted with temperature resistance silver paint, as no screw post in the enclosure match the SBC machines holes.  They are suspended on the board with metal posts.

 

One if my "nightmares" with this machine has been the internal networking.  Basically the old style ifup-ifdown doesn't work.  Armbian it is a complex thing because it keeps the ifup-ifdown together with the NetworkManager and the SystemD.NetworkD, all at the same time.  So, sometimes you do something but it doesn't work because "the other guy" works against you and you really have no idea what it is happening, and things go wild when working three machines at the same time.

 

At the end, The M2+ and the Zero were configured with NetworkManager and the R2 with SystemD.NetworkD ... in this respect, they are not compatible in the Armbian setup methodology.

 

--

 

The Zero and the M2+ take their power from the R2 (later I will use the Power Supply directly).  I remember when having the legacy 3 kernels and the zero was possible to use the USB cables for networking with the g_ether module.  But I never was able to do this to work well with the 4 series kernels.  In fact, now Armbian comes loaded with the g_serial instead.  Could be interesting to recover that functionality, as this could reduce the complexity with this type of machine combinations.  By now, I am relying in the old friend RG45.

 

Share this post


Link to post
Share on other sites
16 minutes ago, malvcr said:

One if my "nightmares" with this machine has been the internal networking.  Basically the old style ifup-ifdown doesn't work.  Armbian it is a complex thing because it keeps the ifup-ifdown together with the NetworkManager and the SystemD.NetworkD, all at the same time.  So, sometimes you do something but it doesn't work because "the other guy" works against you and you really have no idea what it is happening, and things go wild when working three machines at the same time.

 

as instruction for removing network-manager I used the page:
https://edulab.unitn.it/tecnici/how-to-disableremove-network-manager-in-ubuntu-or-debian/

 

ifupdown did work for me (on another device and after removing network-manager) while using these commands:
 

sudo service network-manager stop
sudo update-rc.d NetworkManager remove

check for working/correct:
--------------------------
- /etc/network/interfaces
- /etc/resolv.conf

sudo apt remove network-manager
sudo apt autoremove

after reboot you could delete first line of /etc/resolv.conf:
# managed my network-manager

 

Share this post


Link to post
Share on other sites

Hi Guidol ...

 

I have been doing a loooot of things as the ones you are describing for years by now.  However, things are becoming more complex and the solutions are not so crystal clear anymore.

 

When working them with the OPI-Zero, latest Armbian version (no problem in legacy ones), to remove the network managers resulted in so unstable environment that I was forced to reinstall the OS.  And ... as Armbian is oriented to NetworkManager, I preferred to learn how to work it.

 

About the R2, what happens is that it is a "work in progress" unsupported device.  So you have no guarantees about what could happen if you break something.  Also, it is more complex that other machines because it has an exotic networking equipment... in those cases, when it works it is better not to try strange things on it unless it is laboratory hardware (I have other machines for that).

 

The specified instructions work for standard Ubuntu on a very regular machine, but not necessarily will work perfectly in a constrained SBC computer where the OS has been fine-tuned to perform well.

 

---

I would prefer if Armbian let me "choose" what networking method I like to use, and in an orderly way disables all other ones.  However, I understand that such thing would involve a lot of work and it is not a priority.

 

Share this post


Link to post
Share on other sites

nice to see that at least someone uses the work.. (tbh, mine is collecting dust since I'm low on time..)

 

4 hours ago, malvcr said:

One if my "nightmares" with this machine has been the internal networking.  Basically the old style ifup-ifdown doesn't work.  Armbian it is a complex thing because it keeps the ifup-ifdown together with the NetworkManager and the SystemD.NetworkD, all at the same time.  So, sometimes you do something but it doesn't work because "the other guy" works against you and you really have no idea what it is happening, and things go wild when working three machines at the same time.

another option for you could be to run them all on NetworkD..

Spoiler

systemd-meme.jpg

 

you can tell networkmanager to ignore interfaces.. and then it shouldn't touch it.. (assuming it's working correctly.. that's what we do on the R2 for all the wired interfaces)..

 

4 hours ago, malvcr said:

In fact, now Armbian comes loaded with the g_serial instead.  Could be interesting to recover that functionality, as this could reduce the complexity with this type of machine combinations.

if only serial is needed.. maybe you can use the pinheader or the R2? somehow similar to this one?

last paragraph.. TBH, I never tested the pinheader on the R2. could be fun to test..

 

3 hours ago, malvcr said:

I would prefer if Armbian let me "choose" what networking method I like to use, and in an orderly way disables all other ones.  However, I understand that such thing would involve a lot of work and it is not a priority.

We 'need' a system which works 'reliable' on first boot. There are a bunch of people don't have an USB-UART to configure their Network after first boot.. Wifi on /etc/network/interfaces is also something only for masochists... :ph34r: Honestly.. I prefer NM on all of my machines.. especially the dispatcher is a great tool... :)But as with a lot of stuff.. if you've 3 people in a room, you get 4 opinions what's the perfect tool for the job.. :D

 

 

Share this post


Link to post
Share on other sites

Hi Martin

 

I really prefer the clear and simple things.  The GUI tools hide many things and this makes me to be worried about the final results.  You know, a tiny detail and then I let a hacker to play with my stuff.  I used the Armbian TUI just to check where the things were located, but then I modified the configuration files directly to understand them better.

 

Maybe the big problem with all this (just a comment for not to be far from the R2 context) is that there is no "network framework" to justify any of the tools.  They are just incomplete.

 

For example, if I like to create a NAT fortified Router/Firewall, I can't depend on NetworkManager alone and I need to tweak here and there with some iptables rules, some systemctl modifications and to cross my fingers expecting that everything be OK.  And when you check on the Internet, there is a big salad of options, many of them "mixing" incompatible things to have a result.

 

Would be wonderful to have a tool where I just describe in almost plain english what I expect.  Something like this (light idea, being tired at 11:23 p.m.). 

 

eth0 = iface( --ipaddress/netmask:gateway-- )

eth1 = iface( --ipaddress/netmask:gateway-- )

eth2 = iface( --ipaddress/netmask:gateway-- )

public = alias(eth0)

dmz = alias(eth1)

lan = alias(eth2)

webserver = address(10.x.x.x)

database = address(192.168.y.z)

 

forward port 80 from public to dmz(webserver)

open port 3610 from dmz(webserver) to lan(database)

route lan to public(any port) 

close any other port from public to dmz

close any port from public to lan

close any other port from dmz to lan

 

Everything together, without surprises.  All details covered by the tool.  Who knows, maybe I work that some day :-) 

Share this post


Link to post
Share on other sites

About the g_ether / g_serial issue.

 

The g_ether it is a very nice option.  No networking infrastructure, just a good quality USB data cable ... and you obtain more than fast ethernet throughput.  When using g_serial it is very slow (obviously they have different purposes).

 

As you can see in my machine, there are several SBC making a tiny private network.  Having g_ether working correctly it is very useful in such scenarios.

 

Anyway, I already have the standard networking equipment there.  Maybe in another setup I could try g_ether again, but with latest kernels.

 

 

Share this post


Link to post
Share on other sites

I would go for UART as well when possible. Even if your SBC is more or less 'dead' you get often an output from UART, whereas everything else gets silent.. So having a really 'low level debug' possibility might be helpful. Having g_ether might be helpful as well to reduce the cables needed inside.. :) Just double-check then the network config on the R2.. It already has a messed up network configuration... :rolleyes::P

Share this post


Link to post
Share on other sites
On 1/30/2019 at 3:05 AM, martinayotte said:

So, I must be masochist since ALL by boards using old fashion /etc/network/interfaces ... :P

Appeler un chat un chat.. yes you are.. otherwise you wouldn't deal with boards like the RK3399 opi board.. :rolleyes::lol:

 

Si nous parlons français:

On ne peut pas faire une omelette sans casser des œufs.
 

 

I assume my old french-teachers would kill me for that.. :D

Share this post


Link to post
Share on other sites
2 hours ago, Ryder.Lee said:

Just checking, what can I do for you guys?:)

 

I am not sure for current versions, but the R2 has a very annoying problem without a clear solution (just some dangerous hacks that I am not very happy to apply).

 

Could be possible to have a different method to power up/power down and to reset the machine?  I don't know, maybe some pin headers where be able to add some buttons or something like that.  And to have the possibility for power up by default when needed instead of having it off when providing electricity (this last convenient when creating routers or similar networking stuff where the R2 looks promising).

 

In the RACK case from above, I was forced to let the side with buttons near the back border and later I added a plaque with a hole to be able to power up the machine with my fingers ... I am working the machine by myself, but it is complicated to assemble a customer's solution with the current behavior ( press 7 seconds on so small button and to wait for the green light to be continuously on for two seconds ).


In fact ... I think that this type of hardware extensions could be useful for any other future SBC.  Just think ... some pins for power, reset, power led and hard disk led ...   :) 

Share this post


Link to post
Share on other sites
16 hours ago, malvcr said:

 

Could be possible to have a different method to power up/power down and to reset the machine?  I don't know, maybe some pin headers where be able to add some buttons or something like that.  And to have the possibility for power up by default when needed instead of having it off when providing electricity (this last convenient when creating routers or similar networking stuff where the R2 looks promising).

 

 

Sorry,  I'm not familiar with hardware layout, but maybe I can help to answer questions about driver or u-boot .

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
3 3