BananaPi R2 (.csc mt7623 as new boardfamily)

[malvcr]

I think that the R2 it is a good machine.  It is not the fastest, doesn't have the maximum RAM, could have some compromises the way the use the SoC data lines, but in general has enough good points to make it attractive for some usages that would need a lot of extra stuff, wiring or similar problems.  Right now I don't have my data at hand, but the other alternatives had some negative elements when checking them that the R2 doesn't have (I made my homework).

Also, Mediatek it is an important SoC producer.  This is similar to Qualcomm, why there is no Armbian for Qualcomm?  ... there must be reasons, one of them is the limited time to work on a voluntary basis, but both are important and will continue being important in the future.

 

In fact, from my perspective, the R2 works better than the OPI Zero 2+ H5, even having a semi unknown Mediatek SoC vs an H5.  And yes, the mainline it is becoming better on this area, together with some individuals hard work here and there.

 

--

A theme on a different thread it is about the installation process.  There are particular wired elements in some points that make difficult (or more work intensive) to deal with new SBCs.  But something must be taken into consideration is that this area it is not just limited to Xunlong, Sinovoip or a hand of particular producers ... these machines are becoming very important and they are taking new novel areas in the computing landscape, so it is important to pay attention to other options.  If we can improve/generalize the installation process and other bring-up details, could be possible to add even completely unknown specimens to the distribution world.

 

Armbian it is wonderful.  I am very happy that I can use it to resolve many different working scenarios.  But the Linux success it is based on the fact that everything can be improved.  In fact, the R2 exercise it is important for me because I can use the machine in real world problems, but also because I can check, "first hand", how Armbian bring-up process work.  Will this be easy or not? .... I really don't know, but hard problems are usually the most rewarding ones, and permit you to have a deeper understanding on some gray areas.

 

[Igor]

13 hours ago, TonyMac32 said:

No crazy errata to worry about?

Not found yet but that doesn't mean it's not there.

 

13 hours ago, TonyMac32 said:

is it worth to bring this up?  I see 3 people who can work and support if they are so inclined, and even the Mediatek guy.

Without questioning it's worth at least as unofficial CSC testing images: https://www.armbian.com/bananapi-r2/  (only direct link for now). 

[TonyMac32]

1 hour ago, Igor said:

Not found yet but that doesn't mean it's not there.

 

Of course, but it seems better than might be feared if it hasn't appeared yet. 

 

1 hour ago, Igor said:

only direct link for now

Well, we might find out sooner rather than later then.

[chwe]

4 hours ago, malvcr said:

In fact, the R2 exercise it is important for me because I can use the machine in real world problems, but also because I can check, "first hand", how Armbian bring-up process work. 

well it might not be a perfect example of a board bring up.. It was done by a beginner as well.. Currently it's a pure mainline kernel which makes it quite easy to keep it recent (e.g. the packaging script for kernel is the generic for every kernels, the few wifi drivers we patch in are patched in in other kernels as well.). We don't support the BSP kernel and I skip the onboard wifi (there's a mPCIe - untested if someone wants decent wifi, for the onboard one, I don't care - last rumors I heard, it's based on an android kernel and I'm not patient enough to patch it in). The only issue software wise are the blobs/preloader which I don't fully understand yet (and probably never, they're not documented and various versions are online I hope this get's better as soon as the patches for u-boot are upstream).. But no ATF pain..

 

Hardware wise, I don't have much equipment to test it.. The DSA network driver didn't perform well in the past and the whole DSA architecture 'just starts' in mainline so things are slightly different to normal network drivers. It 'works' with networkd, but I think it's not made for NetworkManager. As csc/wip board, I can take responsibility for it but it's not a 'beginners' board and features wise recent RK3399 based boards may be more interesting (crypto performs better there, mainline is 'similar mature' and more boards are on the market).

2 hours ago, Igor said:

Without questioning it's worth at least as unofficial CSC testing images: https://www.armbian.com/bananapi-r2/  (only direct link for now). 

I think it makes sense to transfer my branch to armbian (I'll create a PR against master). As long as no nand sata script adjustments are there, it can't mess up other boards, it's only one entry in the buildscript, the rest are independent files. Anyway, it is/was a nice learning experience to get it working.. The kernel is originally based on arm7 multiarch devconfig and might still some missing/not needed drivers on it.. but time and testers will show us what's missing. eMMC may need some tweaks (the blobs differ), HDMI may come up with lima drivers (they did some work in the lima branch see page one of this thread where it's about defconfig for kernel, I don't plan to monitor progress there cause for me it's obviously a router/headless board not some display thingie - still no spare HDMI screen to dive into this adventure.. ).

 

Reboot works, USB worked last time I tested it, SATA as well (btw. the needed sata cables can be bought in xunlongs aliexpress store - sinovoip doesn't have them in their online shop @Nora Lee you might offer them as well? ). mPCI according to Igor as well (didn't had time to test it). Thermals are there, crypto is there, DVFS is there, cleaned up bootscript is there, as soon as u-boot is upstream I'll clean up (partly) the u-boot mess - at the moment u-boot is AS IS and I don't plan to go through all RC candidates just to keep it updated. Let's fix this as soon as it reaches upstream u-boot. For a CSC it's fairly well supported. Funfact, the hardest nuts was u-boot and it got obsolete...

[malvcr]

3 hours ago, chwe said:

(btw. the needed sata cables can be bought in xunlongs aliexpress store - sinovoip doesn't have them in their online shop @Nora Lee you might offer them as well? ).

 

I recommend to have one of two "extra" cables.  I have some purchased directly from sinovoip (not their online shop) ... and one of them was defective in a RAID configuration, making the RAID to fail erratically.  This gave me a lot of headaches for several weeks, making me to doubt about several things that were not in fault (this happens when you are not sure about many things at the same time) ... sometimes, the problems are not in the complex area but they are derived from simple things.

[chwe]

after some pain, it finally works.. edit: with it.. I mean nand-sata-insall to eMMC

Last login: Sun Nov 11 22:02:07 UTC 2018 on ttyS2
 ____                                  ____  _   ____  ____  
| __ )  __ _ _ __   __ _ _ __   __ _  |  _ \(_) |  _ \|___ \ 
|  _ \ / _` | '_ \ / _` | '_ \ / _` | | |_) | | | |_) | __) |
| |_) | (_| | | | | (_| | | | | (_| | |  __/| | |  _ < / __/ 
|____/ \__,_|_| |_|\__,_|_| |_|\__,_| |_|   |_| |_| \_\_____|
                                                             

Welcome to ARMBIAN 5.66 user-built Debian GNU/Linux 9 (stretch) 4.19.1-mt7623   
System load:   0.76 0.18 0.06  	Up time:       0 min		
Memory usage:  4 % of 2010MB 	IP:            
CPU temp:      39°C           	
Usage of /:    14% of 7.1G   	

[ 0 security updates available, 27 updates total: apt upgrade ]
Last check: 2018-11-11 22:10

[ General system configuration (beta): armbian-config ]

@Igor can you review and accept the PR.. @malvcr can you test if it works on your board too? Have fun with testing.

[chwe]

to replicate:

first install u-boot (entry 4) then install to emmc (entry 1). remove sd card cause per default it 'should' boot sd if it is present..

[Nora Lee]

Dear Chwe,

 

You can find BPI SATA cable on aliexpress by https://www.aliexpress.com/premium/Bpi-SATA-cable.html?SearchText=Bpi+SATA+cable&d=y&tc=ppc&initiative_id=SB_20181112004947&origin=y&catId=0&isViewCP=y

[malvcr]

Let me try ... I have 1.1 and 1.2 version boards.  I will check both.

 

[Igor]

35 minutes ago, malvcr said:

1.2 version boards

Running from eMMC http://ix.io/1rDj

[chwe]

it didn't work when I tried to have the rootfs on a btrfs partition.. I assume it needs some adjustments in the bootscript.. I'll have a look into it in the next days..

[Lion Wang]

OpenMPTCProuter use MultiPath TCP (MPTCP) to aggregate multiple Internet connections and OpenWrt. and have official support BPI-R2.

 

https://www.openmptcprouter.com/

 

source code on github:

 

https://github.com/Ysurac/openmptcprouter

 

[malvcr]

There is something strange with the R2 1.1 version (tomorrow I will check with more care, even with a 1.2 one).

 

For checking this I updated the source code and produced a fresh image.  Just boot the image and when checking I noticed that the MAC addresses are someway mixed.

 

wan, eth0, lan0, lan1, lan2, lan3 ... all them share the same address.  Then, the br0 (bridge?) has the other address.

 

For this type of machines, it is supposed that the "wan" port it is the one is isolated, while the lan ones are the ones sharing the MAC address (this is some type of router machine).  So, the wan port must have a different address than the lanX ports.

 

 

[chwe]

15 hours ago, malvcr said:

wan, eth0, lan0, lan1, lan2, lan3 ... all them share the same address.  Then, the br0 (bridge?) has the other address.

 

could actually be defined in: /etc/systemd/network/

https://github.com/armbian/build/blob/70bb483a3fc3e5d6a431c6e8d67e0dcb88330b28/config/sources/mt7623.conf#L59

 

all interfaces are handled by networkd. During the time I played with network I just looked for a way to bring all interfaces up. The current driver only allows to bring up eth0 (eth1 should be possible as well, but those patches never reached mainline - look through the thread here, you should find it). Feel free to play with it. Actually eth0 and eth1 should be connected to the DSA chip (but DSA networking is slightly different from normal networking so be prepared.. ). @frank-w ported it to 4.14 if I'm right but no idea if he ever ported it to >4.14 cause there were some bigger changes in network for the kernel.

https://www.kernel.org/doc/Documentation/networking/dsa/dsa.txt

 

e.g. this patch series would be needed (and firstly adjusted):

https://lore.kernel.org/patchwork/patch/793309/

 

 

 

[frank-w]

The main porting of second gmac was done by john crispin. There was only a small mistake which we fixed (both cpu-ports need to use same mode).

 

I tried to port it to 4.19,but currently i can't get it working (eth1 is visible but dsa-ports got lost) so i stuck here without any help. I've contacted John,but he tells me he is currently busy and has not the time he need to help me.

 

https://github.com/frank-w/BPI-R2-4.14/commits/4.19-gmac

 

Have contacted dave miller as maintainer of network-part,but got no response yet

[chwe]

Quote

Quote

No. Those kernels are too different which means a lot of work. Except HDMI, there is nothing that important left to port.

which Parts are too different? it’s mainline-Kernel, i’ve added features by merges, which you can also use to integrate in your Kernel…

from the BPi forum here: http://forum.banana-pi.org/t/bpi-r2-new-image-armbian-with-kernel-4-19-y-2018-11-5-support-by-armbian/7193/17

 

I won't respond in the BPi Forum. My time is currently very limited and don't follow all forums related to the SBCs I use. Yes we could patch in all the nice stuff you did, or even use your kernel tree for the BPi R2. But either we rely on an out of tree kernel (yours) or we've to heavily patch mainline with all the patches you applied. The first could be an option but during development I decided to not go that way. The second would mean that we've to adjust this patches everytime they break during kernel bump to newer versions, something I'm not willing to to. Keep in mind, Armbian support for the R2 was quite a long time a one man show.. Nobody was interested in contribution therefore I could do whatever I thought would fit best.. Since my interest in HDMI is somehow non-existing at the moment.. I simply don't care if it works.. Similar to nand-sata install.. It wasn't of interest for me for a long time.. I recently thought let's give it a try and I 'wasted' the whole Sunday afternoon to get it working with a minimal adjustment to ensure it doesn't harm the >50 other boards Armbian supports (means for me - reading into how nand-sata-install basically works.. try a bunch of time to get it working, write a PR, just a side-note: without some hints I got back in may from Wolfgang and your wiki, this wouldn't ever happen. Collecting all the missing bits to get such stuff up is just painful thanks to both of you, things were a way easier... ).

To keep my workload for the board in an acceptable range I tend to go for pure mainline. If mainline supports feature X, no problem to support it in Armbian (for the mt7623) as well. If mainline doesn't support it.. Well I wont spend much time trying to bring it up. Maintaining patches over time is time intensive.. @Igor and others do a lot of work for other SoCs to have features supported before they reach mainline.. For the R2 this wont happen. It's only one board in the MT7623 family.. So we (as Armbian) have to keep the support costs as low as possible, means everything which probably opens Pandora's box should be avoided. People tend to not understand that Mali != video acceleration. If HDMI and Mali is there people want KODI running.. I'm not willing to deal with questions like "why's KODI not working smooth on Armbian on the R2". Simply not. If people want KODI on it they should ask the KODI people. If people want HDMI on it, they should use your image or prepare a sane patch based on mainline for it. I won't do it. Similar for the onboard wifi.. I never touched it cause I personally didn't see an use-case for it. It just bloats more support questions in case this chip doesn't work reliable. We as Armbian don't have experience with the one soldered on this board. Igor packed it now but disabled it by default which is okay for me (at the moment), but in case support questions for it are overwhelming I'll take care that it gets wiped out from the buildscript cause I don't want to have a second XR819.

The only chance I see to bring this board from csc to wip or fully supported in the future is to keep the maintenance costs as low as possible. So stick it to 'as clean as possible' vanilla LTS kernels which should not break and when time allows it I'll maintain a next branch with mainline (4.20 --> 5.0 etc.)... We try to reduce the workload for all the boards we support (see here: https://forum.armbian.com/topic/6281-board-support-general-discussion-project-aims/?do=findComment&comment=63170 and follow ups). For a one board SoC I clearly prefer a mainline only approach to keep it maintainable. The main features are supported, and for the rest.. It's up to the user-base of this board to bring it up and test it. My 'job' is 'done' as soon as I can stick it to a proper upstream u-boot and the bootscript is fixed so that people can put their rootfs on something else than ext4 with nand-sata-install (which is currently broken for btrfs - at least when I tested it). The second gmac up would be a 'nice to have' a sane network config (everything under one bridge is probably not preferred by everyone) would be nice as well but not of high priority to me. I do in chemistry not computer science.. bringing up such stuff an testing it took me nuts and a bunch of reading/testing every-time..

For me this is definitively not a 'beginners SBC' so people using it with Armbian should either be experienced with such stuff so that they can fix things on their own or at least willing to learn (as I had to as well)... I wont write any step by step procedure do get things running for it.. If *joe random* needs such step by step procedures I suggest you go for a board which has a bigger community or use another Image where the creator is willing to give you such step-by-step procedures. My offer is a 'pure' vanilla kernel and an Armbian rootfs which supports most of the features provided for this board and thanks to Armbians buildscript you can create all needed updates on your own, so in the end you get a set of nice *.deb packages which allow to update your board(s) with dpkg -i *.deb and in case the board ever enters wip or supported you'll get those packages even on armbians apt server so that an apt update && apt upgrade will work. Kernel-support is quite mature but for whatever reason no other board-maker picked up the SoC.

 

I think that's not a bad offer for a board which ended in a closed thread the first time it was discussed cause involved people were more focused on personal insults. Is it perfect? Indeed not.. It's no up to all users to make it better. You now get an Image which boots out of the box from SD-Card and also works on eMMC with a simple nand-sata-install call packed with a 'near to upstream' u-boot.. working armbianEnv.txt with working mPCI, USB and SATA and all blobs needed for it are prepacked with the Image. If you really need decent wifi, go for an mPCI based one (@Igor tested a few). If you need for whatever reason a display, IMO there are better boards for such use-cases.

 

If you want to contribute: provide some real-world numbers what the network is capable to deliver. I simply don't have time and enough equipment to test it at the moment. Encrypted and not encrypted would be nice.. Or find a more sane approach for the overall network configuration: https://github.com/chwe17/build/tree/46665fc32f1ec0a4981a743fc259173c07383c04/packages/bsp/mt7623

there's your starting point..

[malvcr]

Hi people ... I was trying the nand-sata-install in one of my R2 1.1 ... 

 

It seems to work, but I lost my serial console.  I was figuring what could be the problem, if the R2 was bricked or something.  But just the serial doesn't work anymore (could be an unrelated issue, but it is important to indicate it).  So, I supposed it really didn't work ... then I attached an ethernet cable to one of the bridged ports and located the DHCP assigned address to connect there using SSH.

 

It is working from the emmc so the process really it is writing the OS there and the R2 boots without the SD.

 

However, there are differences between 1.1 and 1.2 that must be taken into consideration.  In the 1.1 version, there is no switch to choose between emmc or sd; instead there is a connector for a battery.

 

As this is not a very supported bring-up effort, my recommendation it is to forget the 1.1 version.  I have it because I was an early adopter, but the second time I purchased cards I received already 1.2 version cards.  I am not really aware of what other hidden differences could be between 1.1 and 1.2.  My feeling is that will have more headaches in the trip.

 

I will use my 1.1 cards for laboratory and mechanical construction (design and test cases), not for production.  And I can do crazy things on the configuration if needed for my specific cases; just that I won't use that version for production or to provide systems to my customers.  It is a little risky.

 

--

 

Frank has a nice 4.14 kernel.  It works well and can be used for routing needs.  I fully understand about applying minimum things on the Armbian case, as the distribution it is used by a lot of people with many different hardware options.  I think that both efforts are important because they will help to understand more machines based on this particular type of SoC.  I am still grasping my head with the DSA thing, to see how I can help there, and checking about a modular installation method.  And this is Linux, a lot of people helping here and there :-)

 

[Igor]

5 minutes ago, malvcr said:

It seems to work, but I lost my serial console. 

Can you check if this has effect? Possible fix: https://github.com/armbian/build/blob/master/config/boards/orangepizero.conf#L10

[chwe]

4 hours ago, malvcr said:

However, there are differences between 1.1 and 1.2 that must be taken into consideration.  In the 1.1 version, there is no switch to choose between emmc or sd; instead there is a connector for a battery.

shouldn't matter.. as long as you don't break u-boot.. it should always look for a bootscript on SD-Card first.. They have also such an firmware uploader tool similar to RockChip, so you should be able to unbrick it in case something goes really wrong..

 

4 hours ago, malvcr said:

Frank has a nice 4.14 kernel.  It works well and can be used for routing needs.  I fully understand fabout applying minimum things on the Armbian case, as the distribution it is used by a lot of people with many different hardware options.

Don't get me wrong, Franks work was and is still important to get this thingie working.. Without his wiki, or the proof that this board works good on mainline, this thread wouldn't even exist. It's just a 'maintenance cost calculating'... Even when I would leave Armbian, the current kernel/patch level would allow the other maintainers to still support the board assuming that mainline doesn't break stuff.. With an out of tree kernel such stuff gets complicated... What happens if Frank doesn't manage his kernelfork anymore? We would have a kernel where we had to apply all patches by hand to keep it in an good shape. Whereas with mainline, the things are just there.

 

4 hours ago, malvcr said:

However, there are differences between 1.1 and 1.2 that must be taken into consideration.  In the 1.1 version, there is no switch to choose between emmc or sd; instead there is a connector for a battery. 

the switch only matters if you have a boot binary on SD & eMMC. So my switch is still on SD when I boot from eMMC (obviously with a removed SD-Card). I don't know what defaults the 1.1 board has. I don't have one so I can't test. Can you test it? Boot from SD-Card with an working image on eMMC and check where it goes? If you want to be sure that it boots from SD-Card just unlock boot0 and erase it with:
 

echo 0 > /sys/block/mmcblk0boot0/force_ro
dd if=/dev/null of=/dev/mmcblk0boot0

then it should go back to SD-Card...

 

4 hours ago, malvcr said:

I am still grasping my head with the DSA thing, to see how I can help there, and checking about a modular installation method.  And this is Linux, a lot of people helping here and there :-)

a great source for understanding stuff: https://wiki.archlinux.org/index.php/systemd-networkd

without arch, I would be lost.. They have really user-friendly wikis..

 

Just to keep important information in the same thread:

[chwe]

@frank-w

Quote

can you post your default config because you cannot match mac, you have to use interface-name (ethx,wan,lan) to create config

how do you put eth0 up?

 

as far as I understand the purpose for boards which have a SoC link to a DSA is that eth0 should be always up not?

see here for config.. https://github.com/armbian/build/tree/master/packages/bsp/mt7623

Spoiler

root@bananapir2:~# ifconfig
br0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether d2:5b:bd:d1:eb:e3  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::6467:cff:feda:202e  prefixlen 64  scopeid 0x20<link>
        ether 66:67:0c:da:20:2e  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 38  bytes 7056 (6.8 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 213  

lan0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether 66:67:0c:da:20:2e  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lan1: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether 66:67:0c:da:20:2e  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lan2: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether 66:67:0c:da:20:2e  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lan3: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether 66:67:0c:da:20:2e  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 3  bytes 312 (312.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 3  bytes 312 (312.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wan: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether 66:67:0c:da:20:2e  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

 

e.g. everything related to wan/lan starts with 10.   by default all interfaces are bridged and should get their IP by DHCP. It's not 100% satisfying but as long as people don't mess and use networkD, it should work. If people try to use archaic /etc/network and do insane stuff there.. well networkD might not play well as most services which end with s D... For the board bring up, it was IMO the best way to get it working. For configuration afterward.. well people have to understand network d good enough to configure it properly.. If they just purge part without understanding and reading this thread here.. Well you're on your own.. I won't support your mess. 

one of my concerns when I started the work on this board:

Quote

From a support point of view: This board has a bunch of features which people will mix together (from router/NAS/'home cloud' up to HDMI capabilities) for a relative affordable price, so 'less experienced' people will buy it, will mess with it and will ask here a bunch of questions when we decide to build images or have it as .csc in armbians repo.

 

and it seems to become true.. It is a board for experienced users or people willing to learn stuff.. @frank-w or @Igor can you please link this thread into the BPi forum? so that people read stuff (or at least have a chance to read) before they mess up their images. I think I was quite open during development/board bring up. Nobody cam up with better ideas how to solve stuff so I did it the way I think it's acceptable...

 

[chwe]

from the bpi forum:

Quote

I have noticed strange issue after installing Armbian on EMMC. After success boot to the system if I do “sudo reboot” after restart it stops on “Starting kernel…”. If I manually reboot using button on R2 it loads correctly. Does anybody else experience same issue? It reproduces for me all the time.

can be reproduced. Just checked again on SD card and there it doesn't happen, that's why I didn't spot it during my testings..

[frank-w]

18 hours ago, chwe said:

@frank-w

as far as I understand the purpose for boards which have a SoC link to a DSA is that eth0 should be always up not?

see here for config.. https://github.com/armbian/build/tree/master/packages/bsp/mt7623

i see it right you bridged all dsa-ports (wan+lan) to the same bridge (br0)? how to use it as router if it works as a switch

 

and you enable dhcp on eth0 to bring them up? makes not really sense to me

[chwe]

11 minutes ago, frank-w said:

i see it right you bridged all dsa-ports (wan+lan) to the same bridge (br0)? how to use it as router if it works as a switch

it was just a quick adaption from the stuff we do for the EspressoBin. Armbians default is NetworkManager for organizing network related stuff... Network Manager doesn't like DSA devices so I went for networkD. Thinking about sane network config ended as soon as 'network worked'.. During this time I had bigger issues than the perfect network configuration. It may make sense to think about it, for sure for 'route configuration' bridge all interfaces isn't the most 'sane' configuration. Not sure if we should let it up to the user to decide or delivering some templates. Templates means testing those but would make it easier to begin with.

I encourage everyone to play with..

[malvcr]

Hi ... I must be sincere.  Network Manager have been extremely unstable for me when dealing with complex networking configurations. 

 

The problems appear because it seems wrong to configure "by hand" things while the NM it is working.  Basically, NM doesn't pay attention to your manual definitions (/etc/network/interfaces file) and decides to change things dynamically, breaking your own definitions in any moment.  And for that there are only two solutions:

1. Don't do anything by hand (use everything as NM dictates it) ... "this is something I need to learn carefully how to do well".
2. Purge NM, as it can't be 100% disabled (why? ... I really don't know ... you disable it and one or two reboots later it is alive again).

NM was designed to deal with complex networking scenarios where things can change.  However, it depends how you design your routers and what is their purpose.  In a big quantity of opportunities for servers or IoT, you live in a 100% static scenario where NM it is just an extremely complex piece of software for a very easy task.

 

Maybe ... and this is just an opinion ... when installing, could be better to let the user to choose what option to use and not to include the other options in the running environment.

 

[malvcr]

About the mt7623

 

I know that the DSA requires some extra work.  However, this could be done in stages.

 

1) As it is now, no secondary networking element (this is just a 4 core machine with 2 gb RAM)

2) As the original 4.4.70 BPI kernel.  WAN in one side and everybody else in the OTHER one (as a switch)

3) Full DSA with the capacity to separate all 4 ports in the CPU interface and full routing capacity in all 5 ports.

4) Everything and WIFI.

5) USB-OTG networking

6) Whatever the user connect in the PCI port.

 

[chwe]

9 hours ago, malvcr said:

• Don't do anything by hand (use everything as NM dictates it) ... "this is something I need to learn carefully how to do well".
• Purge NM, as it can't be 100% disabled (why? ... I really don't know ... you disable it and one or two reboots later it is alive again).

NM ignores all wired interfaces for the R2 in the current config.

 

17 minutes ago, malvcr said:

2) As the original 4.4.70 BPI kernel.  WAN in one side and everybody else in the OTHER one (as a switch)

3) Full DSA with the capacity to separate all 4 ports in the CPU interface and full routing capacity in all 5 ports.

no chances to to it similar to the 4.4 kernel.. for MT7530 only a DSA driver exists in mainline..

[malvcr]

Understood ... then we must make everything to work ...  ... 

When I have a chance, let me check the differences between DSA in 4.14 and 4.19.  I have been reading the code but it is not so easy to catch what is not working.

 

[malvcr]

There are many changes between 4.14 and 4.19 ... in particular with the mt7530 driver.

 

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/diff/drivers/net/dsa/mt7530.h?id2=v4.14.81&id=v4.19.2

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/diff/drivers/net/dsa/mt7530.c?id2=v4.14.81&id=v4.19.2

 

And I saw the tread about the "trick" to make the second interface go up

 

http://forum.banana-pi.org/t/missing-nics-eth2-eth4/4571/15

 

These days (a little each time, as I am a little busy), let me check how the patch can live with the other changes, to see if it can be applied.  Also, as I understand on the BPI forum, that patch can't go to mainline because it is not an official change from the main DSA maintainers that are looking for that type of functionality in the DSA future improvements.

 

[frank-w]

i've got second gmac working in 4.19 and with some advice from a DSA-Maintainer, i changed it (back) to mdio_device (johns patch uses platform_device).

 

http://forum.banana-pi.org/t/help-for-testing-4-19-on-r2/7339

[chwe]

55 minutes ago, frank-w said:

i've got second gmac working in 4.19

highly appreciated! I'll have a look into it as soon as time allows it.

 

http://forum.banana-pi.org/t/bpi-r2-new-image-armbian-with-kernel-4-19-y-2018-11-5-support-by-armbian/7193/46

USB attached storage is also recognized and will be investigated. I had issues as well with the el cheapo inostar USB-SATA bridge.. It worked.. I cleaned up the kernel, and then it doesn't work anymore... an normal 64GB USB stick worked.. So I thought it's just an issue of the crappy cheap USB-SATA bridge I used.. I may go through the commit history to figure out what caused it.. Not sure anymore but I assume it happened here during 4.17 clean up..:

https://github.com/armbian/build/commit/065ee2a58cdec9cf73db600a88329db7bd1e83fd#diff-739e1697912e608c5c6406a65c271ad7