ARM SBC Support Discussion

Mochabin is an open source quad-core networking board focused on hi speed connectivity with Wi-Fi 6, 5G, and 10Gigabit ethernet
https://www.kickstarter.com/projects/874883570/mochabin-5g

quad-core Corex-A72

Networking

  • 1x 10GbE SFP+, 1x 1GbE SFP (via 88E1512 PHY)
  • 4x Gigabit Ethernet RJ45 LAN ports via Topaz 88E6141 switch
  • 1x Gigabit Ethernet RJ45 WAN port (via 88E1512 PHY) with PoE support; Note: multiplexed with 1GbE SFP, so only one can be used at any time
  • Optional 4G or 5G cellular connectivity via M.2 2250 socket plus SIM card slot
  • Optional NXP 88Q9098 based Mini PCIe wireless card for 802.11ax WiFi 6 and Bluetooth 5
1 Like

Hi did you benchmark IDS/IPS on the nano pi r2s?

I am using nano pi r2s as openwrt as home router, but i want to add a (lowcost) device to do ips/ids.
Do you think the nano r2s i viable as ips/ids,
or it’s better to get a r4s or bpi-w2?
Do you think the Orange Pi R1 Plus Orange Pi R1 Plus router SBC features Rockchip RK3328, Dual GbE - CNX Software is compatible? (same hardware as the nanopi r2s)

I don’t think rk3328 is a best solution for ids/ips.

If you have a small network and less device then make rk3399 nanopir4s will do the job.
Ids did work in my test but i don’t think use it for more than a day as i had just set it up to see how much of load it can take.

1 Like

Hello,

another possible “low power” alternative until dual LAN (not switches) ARM SoC become available:

Odroid H2 (x86)

https://magazine.odroid.com/article/odroid-h2-the-new-and-enhanced-x86-platform/

Problem: they basically sold out within a minute
 it might be hard to get hold of them

** END OF LIFE - NO LONGER AVAILABLE **

Availability: Discontinued

So no option.

There are so many X86 cheap and low power devices.

You can check hardware recommendation section for that.

From my perspective of view this is the wrong way to do business. One need not to support this clientele.
I do not want to be offensive, so I do apologies if this could be seen so. IPFIRE is a great product and should focus on customers which valuate this.
Again I do not to be too hard in my argumentation. I only want to support Michaels point of view from some one who dealt a lot with business concepts in the past.

These SBC get superceded so quickly. nanopi R5S now looks a better option. It has features people have been seeking:

  • 3 ethernet
  • 2.5 Gb/s ethernet
  • 2 GB RAM
  • HDMI - might be possible to install & operate without needing UART adapter

It will take some time for it to get supported in mainline linux kernel.
Pcie3 for rk356x is still under review.

Hopefully yes.

There’s is Station P2 also with dual gigabit lans.

What is bad about a serial console?
This interface is just very simple and used for decades. And thus IMO the best solution for the system console. No requirements for an adequate graphic hw and keyboard interface.

1 Like

The serial console is yet another failure point. I find that SBC can need to be rebooted (uncleanly) or the UART adapter unplugged/plugged to get the arrangement to respond. I’ve drilled a hole in the case of my R1S, so that the serial adapter can be permanently in place, because the system breaks so often. The R5S also does not have external access to the UART pins.

The need for serial adapter is also a deterrent for less experienced users, who might otherwise be able to install & operate IPFire.

Well what is wrong in having HDMI output when there is HDMI port on the hardware ?

Serial consoles are so much better. I don’t even have a screen in my office any more that has HDMI. It is dying.

1 Like

Hello

So another new router hardware with a powerful soc.

Banana Pi M2S

We can get mainline uboot and working dts patch.

But sadly it will not be upstreamed anytime soon.

I might put in some time to bring it up under Manjaro Arm project but currently that’s a very low priority :slight_smile:

Let me know your thoughts on this sbc.

Not a single USB 3.x port? Wow that’s cold. Also there is no case available. Nobody will run the bare hardware without any protection.

I agree. This early devkit. I think that will make the case available at launch.

I can’t see any benefits with this board. As long as the CPU won’t get their L3 cache I’m not interested into more cores. It’s the same why the old AMD APUs are so “low”. Therefore the board is at least 2 years too late.

1 Like

In response to recent discussions on this site, I’d like to make a plea for continued Raspberry Pi 4 (RPi4) support. Primarily because it works very well for home firewalls*.

I currently run 64-bit IPFire on a 2GB RPi4, with three USB Ethernet adapters, to provide a Red+Orange+Blue+Green firewall fronting a domestic broadband connection.

The RPi4 might not handle more demanding situations, but it copes well with the throughput of a typical domestic firewall, albeit one running at only 25mb/s (“fiber to cabinet” speed).

Equally importantly, it also does a good job of meeting the other primary requirements of a domestic firewall; it’s small and reliable, draws little power, needs no moving parts (fans etc), and is relatively cheap. This makes the RPi4 a useful platform to support, especially as there are very few alternatives that do as good a job of meeting all the domestic firewall requirements.

* I should note that, while the Rpi4 works well as a firewall, the rather odd bus architecture of the earlier variants (1, 2 and 3) means that they do not.

Hello Michael, Arne and Furkan,
Hello everyone,

I have been following this thread and despite developers saying ‘ARM is dead’ I am glad to see that this isn’t the case.

There is a potentially suitable device (industrial grade with long term support, 1GHz, 2GB RAM, 16GB eMMC, 2x GbE) that is well integrated into Debian and comes with DTB’s and support. I think Michael’s post #4 was heared

After flashing the latest aarch64 release and booting from SD the boot process halted. There was no graphics output at all (different to the vendor’s reference image) and UART output just reported lots of hardware errors - I assume the kernel could not access all resources due to missing hardware definitions/addresses.

Since I am new to IPFire and I am not familiar with architectural issues - some questions:

  • IPFire is based upon a standard linux kernel, so why doesn’t it incorporate the drivers that are integrated since 2020?
  • Isn’t there a ‘basic’ (e.g. generic) support for common devices for any kind of boards like USB, MMC, NIC, DP/HDMI?
  • Can I integrate DTB’s on my own?
  • How does the build process look like, is there a ‘hand’s on’ manual?
  • May I plea for such hardware support? :wink:

Hi @ming

Welcome to the IPFire community.

I believe this is related to 32 bit ARM. That will eventually be stopped. It has already been marked as a legacy release in the secondary architectures section of the download. Somewhere it will be marked as being deprecated and then stopped.

64bit ARM is still being supported - aarch64. Even there the concern is that every new arm system needs to end up having IPFire custom tuned to be able to work. That is not really supportable, when the devs only have a few examples of the hardware and there are so few core devs working on IPFire.

I can provide input on some of your questions.

IPFire has all the drivers that are in the kernel at the release currently running - 5.15.49. Unfortunately, not all hardware suppliers submit their drivers to the Linux Kernel team to be integrated.

https://wiki.ipfire.org/devel/ipfire-2-x/build-howto
Bear in mind that if you are looking at integrating specific drivers into the build then you can not just build them and add them in.
For security of the firewall, all kernel modules are signed in the build and after the build is completed the key is deleted so no one can ever build a module or rootkit against the IPFire kernel. So to add an additional driver you will have to build the whole kernel and add that to your build process.
If you know the specific driver and it is GPL compatible then you can either submit a patch for the addition of the driver.
https://wiki.ipfire.org/devel/submit-patches
https://community.ipfire.org/t/arm-sbc-support-discussion/2650/68

The other alternative is to raise the driver requirement as a bug but that may take some time as there are only a few people capable of dealing with the integration of drivers into IPFire

For your remaining questions other people with more knowledge of arm on IPFire will have to provide answers.