BananaPi R2 (.csc mt7623 as new boardfamily)

[chwe]

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.

[TonyMac32]

4 hours ago, chwe said:

(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)

https://www.merriam-webster.com/dictionary/masochism

 

(I would recommend sticking with definition 2.  Although it's tough these days to know for sure...) 

[malvcr]

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

 

 

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.

 

[guidol]

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

 

[malvcr]

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.

 

[chwe]

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

 

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

 

 

[martinayotte]

2 hours ago, chwe said:

Wifi on /etc/network/interfaces is also something only for masochists...

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

[malvcr]

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 :-) 

[malvcr]

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.

 

 

[chwe]

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

[chwe]

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

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

 

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

[martinayotte]

34 minutes ago, chwe said:

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

[Ryder.Lee]

Just checking, what can I do for you guys?

[malvcr]

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

[chwe]

a bit of housekeeping..

https://github.com/armbian/build/commit/864de31d5cb3e02d950ff5d658d065be8bb31541

uboot was bumped to 2019.01 so that most of the u-boot patches are gone now.. reboot issue on eMMC is still there.. but at least we're not longer on an rc uboot version.

[Ryder.Lee]

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 .

[Christoo]

I apologise I made a new thread, bu this post was probably better suited here:

 

Hello all,

 

Firstly, thank you for all your great work.

Though my question pertains to Armbian Bionic on the BananaPi R2, I believe the question is further reaching.

I have an R2 Board and have installed an IO Crest 8 Port PCIE Serial Card Link: http://www.iocrest.com/en/product_details629_a.html

 

Installs and boots fine.

Card has mainline kernel support.

Running lspci -v returns:

 

00:00.0 PCI bridge: MEDIATEK Corp. Device 0801 (rev 01) (prog-if 00 [Normal decode])
        Flags: bus master, fast devsel, latency 0, IRQ 226
        Memory at 60300000 (32-bit, non-prefetchable) [size=64K]
        Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
        Memory behind bridge: 60000000-600fffff
        Capabilities: [40] Power Management version 3
        Capabilities: [70] Express Root Port (Slot-), MSI 00
        Capabilities: [100] Advanced Error Reporting
        Capabilities: [148] Virtual Channel
        Kernel driver in use: pcieport

00:01.0 PCI bridge: MEDIATEK Corp. Device 0801 (rev 01) (prog-if 00 [Normal decode])
        Flags: bus master, fast devsel, latency 0, IRQ 227
        Memory at 60310000 (32-bit, non-prefetchable) [size=64K]
        Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
        I/O behind bridge: 00001000-00001fff
        Memory behind bridge: 60100000-601fffff
        Prefetchable memory behind bridge: 60200000-602fffff
        Capabilities: [40] Power Management version 3
        Capabilities: [70] Express Root Port (Slot-), MSI 00
        Capabilities: [100] Advanced Error Reporting
        Capabilities: [148] Virtual Channel
        Kernel driver in use: pcieport

01:00.0 Serial controller: Exar Corp. Device 0358 (rev 03) (prog-if 02 [16550])
        Flags: bus master, fast devsel, latency 0, IRQ 226
        Memory at 60000000 (32-bit, non-prefetchable) [size=16K]
        Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
        Capabilities: [78] Power Management version 3
        Capabilities: [80] Express Endpoint, MSI 01
        Capabilities: [100] Virtual Channel
        Kernel driver in use: exar_serial

02:00.0 IDE interface: ASMedia Technology Inc. ASM1061 SATA IDE Controller (rev 02) (prog-if 85 [PCI native mode-only controller, supports bus mastering])
        Subsystem: ASMedia Technology Inc. ASM1061 SATA IDE Controller
        Flags: bus master, fast devsel, latency 0, IRQ 227
        I/O ports at 1010 [size=8]
        I/O ports at 1020 [size=4]
        I/O ports at 1018 [size=8]
        I/O ports at 1024 [size=4]
        I/O ports at 1000 [size=16]
        Memory at 60100000 (32-bit, non-prefetchable) [size=512]
        [virtual] Expansion ROM at 60200000 [disabled] [size=64K]
        Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit-
        Capabilities: [78] Power Management version 3
        Capabilities: [80] Express Legacy Endpoint, MSI 00
        Capabilities: [100] Virtual Channel
        Kernel driver in use: ahci

But when I run:  ls /dev/ttyS*

I only get:

/dev/ttyS0  /dev/ttyS1  /dev/ttyS2  /dev/ttyS3

Any ideas?

When I did some investigation, I found some references to Debian installs having the number of serial ports limited in the kernel, but this is  way outside of my knowledge.

I would value your feedback.

[martinayotte]

10 hours ago, Christoo said:

Any ideas?

Did you check output of "dmesg" ?

Maybe that card need a custom DT overlay ...

[chwe]

honestly I've never tested mPCI cards.. I think @Igor tested a few

On 7/16/2019 at 4:50 AM, Christoo said:

Card has mainline kernel support.

did you check if we actually have it in our config? the config is far away from complete..

 

https://github.com/armbian/build/blob/master/config/kernel/linux-mt7623-default.config

 

 

[Igor]

4 hours ago, chwe said:

I think @Igor tested a few

 

Yes. Its more or less a representation that PCI stack works ... which is the case here as well. 
 

On 7/16/2019 at 4:50 AM, Christoo said:

but this is  way outside of my knowledge.

 

Solving problems you have here is way way outside help which we sponsor(!) to your board (not what you attach to it) that support is matured enough that we can afford helping. 3rd party hardware and especially some odd card nobody saw before, can only receive few hints, but generally: no support at all. Linux kernel is a work of thousands of people and we are just a few working on "great work" which "you" cover only at around 0.5% of the total costs.

 

Perhaps you hire someone to solve you this general Linux kernel/IO card driver problem? There are many people out there that provide such services. 

[Lion Wang]

BPI-MT7615 802.11 ac wifi 4x4 dual-band PCIe module Mass production version,support BPI-R64 ,BPI-R2

http://forum.banana-pi.org/t/bpi-mt7615-802-11-ac-wifi-4x4-dual-band-pcie-module-mass-production-version/10037

[Lion Wang]

#BananaPi BPI-R64 + #MT7615 test #wifi function with #openwrt

 

http://wiki.banana-pi.org/BPI-R64_%2B_MT7615_function_test

[Lion Wang]

[Banana Pi BPI-R64] Mainline OpenWRT image

 

http://forum.banana-pi.org/t/banana-pi-bpi-r64-mainline-openwrt-image/11415/260