Issues with lamobo-r1 and new distribution


Recommended Posts

Hello

I had installed on my lamobo-r1 as of this afternoon, armbian 5.20... I then decided to upgrade to 5.23 and after that networking went haywire... nothing worked anymore

 

"swconfig list" showed nothing as if module for the broadcom switch wasn't loaded

 

After the last buggy updates I'm almost afraid to upgrade anymore... what if anything else breaks in the process

 

Right now I'm back to 5.20 with hold on "linux-dtb-next-sunxi linux-firmware-image-next-sunxi linux-headers-next-sunxi linux-image-next-sunxi linux-jessie-root-next-lamobo-r1 linux-u-boot-lamobo-r1-next"

 

Very bad "puttycat"... quite sad actually I was really hoping some improvement since I do get some freezes once in a while... winter is coming and right now I can't hope anymore to rely on the R1 to use as a thermostat ...

 

Link to post
Share on other sites
Donate and support the project!

I have no idea what it is, I would need to hook up a board but have currently no motivation, a headache because of stress and lack of sleep. 

 

During two major updates, there was few cheer ups & thanks, a bunch of useless questions, support question on a private comm, what I "like" most, and we raise 15 euros. One, one person answered to our plead for help and saves us / you some time.

 

I will repeat this plead once again. We need regulars on testing. On daily basis, otherwise such things will continue to happen. We can't test all boards for everything on every update, nobody of the core crew even have them. If you want top service, we need volunteers and cash. I already work full time / way too much and I need to cut down my involvement within the project. Things can go only worse if tasks wont be patched on the way.

 

This service can sustain top quality level only with proper support from users, makers and us. Otherwise it will drift away from end user back to geeks, which always find a way ...

Link to post
Share on other sites

After the last buggy updates I'm almost afraid to upgrade anymore...

 

Well, why not switching to distros that do not receive any upgrades? The problem Armbian project currently faces is a lack of community involvement and unless this changes it's a really good idea to slow down a lot (eg. fixing Dirty COW not within 2 days with all kernels but in the same amount of time as most other OS images do: never).

 

Apart from that me personally would drop support for Crapboard R1 rather sooner than later since so many people still don't get how insanely insecure this thingie is when used in the way as advertised by its careless manufacturer.

 

but have currently no motivation

 

 

I tend to agree on that.

Link to post
Share on other sites

Dear badrianiulian, i understand that you are sad about thoses problems.

What make me more sad is the answer of Igor. Since what Igor answered i am beginning to think that Armbian is more for tester and/or experimented users. I said that because i am a end user and from what he answered, i see no place for me here anymore. I really appreciate what Armbian teem is doing but as a end user, i cannot really help them very much. Finally as a end user, i also have a bunch of « USELESS » questions but it does not appear to be welcome.

Link to post
Share on other sites

@dvachon

 

please don't be so hard.

 

Currently the small Armbian team is doing a lot, so much that I just cannot follow. There is a lot of progress and so far quite properly architectured.

 

The only big issue, the team is too small and barely can communicate properly.

 

That has led to a huge misunderstanding with zador.blood.stain & I (that I am sorry)

 

What are your questions?

Link to post
Share on other sites

Dear badrianiulian, i understand that you are sad about thoses problems.

This answer is close to unbelievable and one of the reasons I will stop for a while here.

 

The 'problem' is that Armbian is not a bunch of smelly OS images but actively developed (kernel, u-boot, package management, settings tuning and a lot of more stuff) but lacks testers. We get almost no feedback on beta OS images that are there for exactly this reason: identifying when changes introduce problems. Only after release people start to complain. This sucks.

 

The 'secret' why this doesn't happen with other OS images is that almost none of them receive any updates after release. Since we lack testers this is something remaining Armbian team might document: how to prevent updating Armbian core (turning an actively developed software project into a bunch of smelly and outdated OS images).

Link to post
Share on other sites

It is good to express how you feel, but I guess I also read some 'over reactions'.

Let's go a step back and look at it.
 

We need regulars on testing. On daily basis, otherwise such things will continue to happen.


Quantity vs Quality

I think this belongs to both, releases and SBC (Single Board Computer)

 

If you look at Debian, you can see the recipe - they have certainly been there, done that.

 

ie. define which board you really support

ie. define a testing channel and a stable

just to name one or two

 

okay okay TK don't get started at me I know you know much more about this.

If the stable  bugfix  is just every 2 or 4 weeks, I will offer my help, but I cannot on a daily basis.

 

your thoughts ?

Link to post
Share on other sites

Hm - sorry about all the problems. Maybe it would be best for the endusers to not upgrade without a way back.

There is a thread in this forum about backup of sdcards.

Is there a possibility to "force" or at least strongly motivate the users to not upgrade before at least a copy of the old sdcard has been made?

About the money: maybe lead the downloaders to donate page first?

 

Best wishes, and I appreciate!

gnasch

Link to post
Share on other sites

Sorry about complaining yesterday

I too was frustrated since I spent the afternoon trying to make the new armbian 5.23 to work...

I know that for armbian to be compatible with all boards takes a lot of work and testing. Since I enjoy tinkering with my board, not beeing able to fix what was happening, took a toll on me... Wasn't fair to you guys

So to make this clear, thank you for your hard work. As for donations... fire away with a paypal account or something... I'm sure I'm not the only one that can spare some cash for the cause

Link to post
Share on other sites

Have been trapped by the same issue today.

 

The trouble comes from the new b53 driver which now uses switchdev for the configuration of the Broadcom 53125 switch, not the old switch configuration tool. I have played a little with it but without any good documentation on the switchdev topic it’s actually quite hard to set up things.

 

After modprobe’ing all the modules from the b53 folder I was rewarded with 5 new interfaces, lan1…lan4 and wan (watch the dmesg output). Note that no additional interface representing the internal eth0 port was added. Setting the link up on the virtual external interfaces works, and configuring the VLAN on each port works (as long as you don’t forget to specify the option `self` to the `bridge` command). However, I haven’t been able to assign VIDs to the eth0 port, the same applies to my VLAN’ed internal ports for wan and lan. So I wonder how connecting the external VLANs to the internal port is supposed to work. I also played with brctl, but this didn’t have any significant effect either.

 

A final attempt was done using the non-VLANed eth0. However, the packet loss was so high (1 out of 10 pings replied) that I refrained from further experimenting and just swapped back to 5.20.

 

I suppose the next step is to fix the driver regarding the high packet loss. I’d expect that to be a regression or something. Only then it makes sense to start playing with the iproute2 stuff again.

Link to post
Share on other sites

I’d really recommend to go back to 5.20 immediately at this time. Only if you don’t mind not having access to your Ethernet ports, which is the point of using a BPI-R1 in the first place for most people, you can go on with any Kernel 4.8.

 

Update:

Returning to 5.20 is not hard, just remember that you need the respective packages, which sometimes are hard to fetch if the network interfaces don’t work anymore. I took all files from here: http://apt.armbian.com/pool/main/l/linux-4.7.3-sunxi/ (, put them on the uSD from another computer via a tethered Wifi from my smartphone) and installed them just like the following on the BPI-R1 (Note: I don’t know whether the order of package installs is relevant, but this order did work for me):

$ sudo dpkg -i linux-image-*.deb linux-dtb-*.deb linux-firmware-*.deb linux-headers-*.deb
$ sudo reboot

I assumed (right) that the newer u-boot is quite okay, and I’d assume that newer dtb packages should work as well, but let’s be on the safe side now and install all 4 packages. Before the reboot you can take a look at /boot and ensure that the right softlinks have been created.

Link to post
Share on other sites

Ah, I forgot: @Igor, @tkaiser, I really appreciate your work! :)

 

Can you tell to which degree you anticipated the b53 changes in Kernel 4.8? Since the ports are automagically named correctly after their positions on the back I’d assume that *some* work has been done.

 

Any clue about my first attempts with high packet loss? I’m not sure whether this is actually an issue or just an artifact of a bad overall configuration.

Link to post
Share on other sites

Before kernel 4.8 Armbian used b53 driver from OpenWRT with some fixes on top (to compile on newer kernels).

Since 4.8 mainline kernel has b53 driver by default: https://linux-sunxi.org/Linux_mainlining_effort#Merged_into_4.8

Commit message for the driver reported that it was tested on R1: https://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/?id=23c731e830009a51a39a7a558179007235c84eb7

 

I would recommend doing some more tests (ideally wait until someone else can confirm this issue on another board), and if packet loss or other issues can be reliably reproduced, your best bet is contacting driver author/maintainer.

 

Edit: for clarification - maintainer e-mail is listed in MAINTAINERS file in the commit I linked above.

Link to post
Share on other sites

Before kernel 4.8 Armbian used b53 driver from OpenWRT with some fixes on top (to compile on newer kernels).

Since 4.8 mainline kernel has b53 driver by default: https://linux-sunxi.org/Linux_mainlining_effort#Merged_into_4.8

Commit message for the driver reported that it was tested on R1: https://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/?id=23c731e830009a51a39a7a558179007235c84eb7

 

I would recommend doing some more tests (ideally wait until someone else can confirm this issue on another board), and if packet loss or other issues can be reliably reproduced, your best bet is contacting driver author/maintainer.

 

Edit: for clarification - maintainer e-mail is listed in MAINTAINERS file in the commit I linked above.

 

Any guide on how to use the b53 driver?

Found this in an article ( https://lwn.net/Articles/634787/ )

bridge vlan add vid 1 dev sw0p1 pvid untagged
bridge vlan add vid 1 dev sw0p2 pvid untagged
bridge vlan add vid 1 dev sw0p3 pvid untagged
bridge vlan add vid 1 dev sw0p4 pvid untagged
bridge vlan add vid 1 dev sw0p8

bridge vlan add vid 2 dev sw0p0 pvid untagged
bridge vlan add vid 2 dev sw0p8

Does this do the trick to configure the ports as a router?

Any other config tricks needed for it to work?

I would like to test the new distro... as I understand, this new switch driver could fix the freezing issue

Link to post
Share on other sites
I would like to test the new distro... as I understand, this new switch driver could fix the freezing issue

 

I try a test build briefly and it actually boots and everything but there is no network ... so something is wrong on a switch driver. I am not sure this article will help you to understand. Driver was working fine all the way up to 4.7.x and it become broken in last build. What was changed ... need to be investigated.

Link to post
Share on other sites

I try a test build briefly and it actually boots and everything but there is no network ... so something is wrong on a switch driver. I am not sure this article will help you to understand. Driver was working fine all the way up to 4.7.x and it become broken in last build. What was changed ... need to be investigated.

 

I'm on the Fedora side of Banana Pi R1 :-)

https://www.wiesinger.com/opensource/fedora/kernel/BananaPi-R1/

 

So far, same Problem on Fedora.

 

Things I found out already:

DSA=Distributed Switch Architecture drivers

https://github.com/torvalds/linux/blob/master/Documentation/networking/dsa/dsa.txt

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

 

didn't help:

echo 'force_drivers+=" b53_common b53_mdio b53_spi b53_mmap b53_srab "' > /etc/dracut.conf.d/banana-switch.conf

 

https://www.phoronix.com/scan.php?page=news_item&px=Networking-Linux-4.8

 

https://github.com/Bananian/bananian/blob/master/kernel/4.3.3/patches/0002-b53_switch_driver.patch

 

Please enable B53 mdio switch driver

https://lists.debian.org/debian-kernel/2016/08/msg00230.html

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=836231

 

# bridge entry not there

echo 1 >/sys/class/net/eth0/bridge/vlan_filtering

https://www.spinics.net/lists/netdev/msg133237.html

 

https://www.spinics.net/lists/netdev/msg380994.html

 

Was also not successful yet.

 

Proprietary swconfig is not used anymore, we have to find how to configure the switch with new DSA infrastructure. Above posted bridge vlan commands might help.

 

https://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/?id=23c731e830009a51a39a7a558179007235c84eb7

 

Guess we should contact the author, which had it running: David S. Miller <davem@davemloft.net>

 

Ciao,

Gerhard

Link to post
Share on other sites

I'm on the Fedora side of Banana Pi R1 :-)

https://www.wiesinger.com/opensource/fedora/kernel/BananaPi-R1/

 

So far, same Problem on Fedora.

 

Things I found out already:

DSA=Distributed Switch Architecture drivers

https://github.com/torvalds/linux/blob/master/Documentation/networking/dsa/dsa.txt

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

 

didn't help:

echo 'force_drivers+=" b53_common b53_mdio b53_spi b53_mmap b53_srab "' > /etc/dracut.conf.d/banana-switch.conf

 

https://www.phoronix.com/scan.php?page=news_item&px=Networking-Linux-4.8

 

https://github.com/Bananian/bananian/blob/master/kernel/4.3.3/patches/0002-b53_switch_driver.patch

 

Please enable B53 mdio switch driver

https://lists.debian.org/debian-kernel/2016/08/msg00230.html

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=836231

 

# bridge entry not there

echo 1 >/sys/class/net/eth0/bridge/vlan_filtering

https://www.spinics.net/lists/netdev/msg133237.html

 

https://www.spinics.net/lists/netdev/msg380994.html

 

Was also not successful yet.

 

Proprietary swconfig is not used anymore, we have to find how to configure the switch with new DSA infrastructure. Above posted bridge vlan commands might help.

 

https://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/?id=23c731e830009a51a39a7a558179007235c84eb7

 

Guess we should contact the author, which had it running: David S. Miller <davem@davemloft.net>

 

Ciao,

Gerhard

Contacted David regarding this thread.

 

Ciao,

Gerhard

Link to post
Share on other sites

I'm back with good news I hope: an update with network configuration on the new 5.25 jessie mainline distribution
I've been using the 5.24 nightly builds for a while (now I'm back on the 5.25 main builds) and with the help of weisl's comment on git hub: https://github.com/igorpecovnik/lib/issues/511#issuecomment-269622336, I've managed some working network configs that everyone can find on this link: https://www.dropbox.com/sh/ciiun8n56c46q2n/AACfXvu5cEoZS5jbO6Xc5L4Ha?dl=0
Add those into '/etc/network' folder and they should work ('interfaces' and 'lamobo-r1' files). I only tested the ppp router configuration since that is all I need but feel free to test the other ones as you please and reply with the needed changes or the confirmation that they work.
Testing the new b53 dsa driver looks promising until now... I'll hold of the nightly builds for a while to see if the freezes will resurface like they used to and will be back with a feedback
For those who are curious, the second archive in the dropbox share named w1-therm.tar.gz is a script that I used to patch the dtb so I wouldn't have to go at each upgrade through this process: https://forum.armbian.com/index.php/topic/993-ds18b20-temperature-sensor-in-lamobo-r1/#entry16089

Link to post
Share on other sites

@badrianiulian
I downloaded your dropbox files.
In the file: lamobo-r1 you have 4 sections:

#!/bin/bash

case "$1" in
    routerup)
	# ========================================================================================================================================================
	# Setup interfaces and VLANs
	# ========================================================================================================================================================
	ip link set eth0 up

    routerdown)
	# ========================================================================================================================================================
	# Delete interfaces and VLANs
	# ========================================================================================================================================================
	# Delete bridge br1 on VLAN 102 with interfaces/tagged: wan untag eth0.102 tag

    switchup)
	# ======================================================================================================================================================== 
	# Setup interfaces and VLANs 
	# ========================================================================================================================================================
	ip link set eth0 up

    switchdown)
	# ========================================================================================================================================================
	# Delete interfaces and VLANs
	# ========================================================================================================================================================
	# Delete bridge br0 on VLAN 101 with interfaces/tagged: lan1 untag lan2 untag lan3 untag lan4 untag wan untag wlan0 untag eth0.101 tag
	

Why do I need this ?
How do you start the section per event ?

Link to post
Share on other sites
Guest
This topic is now closed to further replies.