ARM SBC Support Discussion

  1. from a security stand point would not be RISCV “the best” platform? (spectre, meltdown) but again: no boards with dual lan

best regards

ARM

Dual LAN:

BANANA PI BPI-M4 (2GB RAM) - Banana Pi - BPI-M4

BANANA PI BPI-W2 Router RAM ← looks like made for it :slight_smile:

PS: what about “virtualized” or “dockerized” ipfire (e.g. on a server “that is there anyway” and has many LAN connections, too much network latency with those virtual nics? (at least in virtualbox yes!)

After many u-boot, kernel config and dtb changes the NanoPi R2S should now work.
I have commited the changes to next tree.

https://nightly.ipfire.org/next/latest/aarch64/

1 Like

What’s the status of the NanoPi R4S?

1 Like

Did you give it a try?

I will try it tomorrow for sure.

If R2S works then hopefully R4S should work too. i will try it on Rockpro64 as I cannot test on my R4S coz it’s in production with opnsense.

u-boot will not build, i have tried it but trusted firmware will fail complaining about ram config. I have not found a working example yet.
also the kernel has no dtb for r4s

so there is some work to do and i have no board to test

2 Likes

One step closer :slight_smile:

sd card is found by the kernel now I need to check why dracut cannot find the partition when the partitions are clearly visible in the logs.

Please advice idk much about dracut though.

UPDATE: My mistake, I didn’t update the UUID of the new image :stuck_out_tongue:

It works fine.

Both NIC detected
image

Rebooted and all looks good.

Update: So far in my test it have worked quite smoothly.
I tried to enable IPS and it got enabled. I do not have the test environment to try the IPS.

I will try to give more time to see how well R2S can handle webproxy, ad blocking, VPN (openvpn) etc for normal home use cases. I don’t know if wireguard is possible in ipfire.

Update: Iperf test

$ iperf -c 192.168.80.1
------------------------------------------------------------
Client connecting to 192.168.80.1, TCP port 5001
TCP window size:  280 KByte (default)
------------------------------------------------------------
[  3] local 192.168.80.10 port 55984 connected with 192.168.80.1 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  1.04 GBytes   890 Mbits/sec

I am using 1Gb on green and 100MB on red. this test is on green line.

Update
Successfully tested R2S for around 8hrs without any issue. I installed clamav and ips to test if it will make the device slow but it worked out fine and it is very smooth as compared to older devices like R1S.

2 Likes

Why have you changed the bootloader? The nightly build should boot out of the box on R2S.

1 Like

I didn’t know this. I flashed R2S uboot and changed boot method to use extlinux.conf

I will try it again without making any changes to the bootloader

You may have mine for that.

forget about BANANAPI R1, it is a 5 port layer 2 switch with only 1 (!) NIC so propably no good for any router-firewall… newer versions of BANANAPI (except BANANA PI BPI-W2 for 150€) are not available on the market currently (Banana Pi BPI-M2S)

so yes, except NanoPi R4S (~80€) there is NO ARM based dual LAN hardware available (as crazy as this sounds)

any experience with adding secondary ethernet via usb? (probably neither fast nor reliable)

has NanoPi same “won’t start without this binary closed source blob” problem? “Broadcom silicon that powers the Pi has a significant amount of proprietary tech that the chipmaker has been unwilling to let us peer too closely at, each and every Raspberry Pi operating system has shipped with a precompiled binary blob containing the proprietary Broadcom code”

Hi.

A question. Would it work with the NanoPI R2C version?. It’s more cheapper.

https://www.friendlyarm.com/index.php?route=product/product&path=69&product_id=285

Thanks.

1 Like

Looking at the specs, it should work out of the box on the OS side. On bootloader side it might need some updates.

This is the first time I see this model. Looks good for IPFire use case.
The difference I see in R2S and R2C is 100Mhz increase in CPU and different Ethernet chip, Mostly cause of chip shortage.

1 Like

Yes, I suspect that as the reason why there suddenly is a very similar model, too.

Obviously this is now becoming a nightmare for us software people when hardware people create many different revisions of pretty much the same system. Saving money here will cause a lot of development, debugging and testing.

I have never heard of this Motorcomm YT8521S chip. Do we have this in some other hardware already? The vendor doesn’t even exist in fireinfo.

Meh. The other LAN port is still connected via USB.

1 Like

Most device have that, Only few have over PCIE.
USB3 works fine for home use cases.

1 Like

I have first seen Motorcomm as phy at kernel 5.15 oldconfig.
So i think 5.10 will not found this phy and use only the usb3 nic.

so no usses with those ARM-USB-NICs?

because once upon a time had a PC-USB-NIC and it was catastroph (used to drop connection)

It can be used small home use but not heavy use.

No this doesn’t really happen now it very stable just not fast enough for heavy load.

1 Like

USB NICs are not that good anyways. This has nothin to do with ARM. There is a great write-up from Tom here:

1 Like

As far as I know, you can’t generalize a statement like that.
It makes a difference whether the corresponding USB LAN NIC is directly soldered on the SBC or only connected via USB-dongle. There are also different models of the chips in different quality.
Some of the users at cnx-software.com know about it pretty well.
But I don’t like lan over USB either.

NanoPi 4RS: one Native Gigabit Ethernet, and one PCIe Gigabit Ethernet

1 Like