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?
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.
I agree with Michael but from a different perspective, people may feel reluctant to support it.
NanoPi r5s comes without UART pins soldered, and I am too lazy to get my hands dirty.
Although HDMI is there, I don’t see the startup information from HDMI until it hits kernel.
The ATF is not opensourced yet, although their(rockchip) bin compiles fine with u-boot 2.7, there is no HDMI ouput yet. And because lack of UART pins, I cannot be bothered to spend time on it.
It’s probably my fault of being lazy, but if I have other choises why bother?
1 Like
Hi @bonnietwin,
thanks for your brief introduction and insights to IPFire.
After reading your reply I realized I misunderstood/misexpressed ‘driver’ & ‘patch’ & ‘kernel module’ & ‘integration’:
It looks like there are two main techniques to make an ARM system/board running under Debian/IPFire/.ux/.ix:
- Integration of patches into the kernel, that have resource addresses hard-coded
- Providing hardware description files *.dts, respectively its serialized pendant *.dtb
The first approach is the one you addressed?
I was aiming on the latter The SBC I mentioned is reflected in arch/arm64/boot/dts/ti branch of kernel.org in means of *.dts files:
The question is how to make IPFire read the *.dts/ *.dtb files. As I understood the second approach solves the shortcomings of patching/building the kernel every time a new board / CPU / hardware revision has emerged. DTS’s/DTB’s shift the work for hardware integration from kernel developers back to system vendors who just provide a standardized data structure every linux distribution understands.
So, in my understanding, IPFire (or any ohter distribution) shall easily support the latest hardware, as long as the system vendor provides such files? Does IPFire kernel hardening requirements allow this approach, and if, how is this done?
Thanks for the clarification. I have seen dts files being mentioned on this forum but I am not familiar with them at all.
All my IPFire experience is with regard to x86_64 based systems so I can’t help you with your question but there are others on the forum who should be able to provide more info on the topic.
To build the dts files from the mentioned folder you have to enable the “K3” architecture which is currently disabled in IPFire.
set CONFIG_ARCH_K3=y
in config/kernel/kernel.config.aarch64-ipfire
might be interesting: (UNTESTED!)
# Nanopi R5S (latest)
NanoPi R4S a bit expensive)
https://de.aliexpress.com/i/1005001831487845.html
NanoPi R2S Open Source Board Dual-Gbit / s-Ethernet-Ports mit Metallschutzhülle | eBay) (MAKE SURE TO SELECT excluding import tax?)
https://wiki.friendlyelec.com/wiki/index.php/NanoPi_R4S#Hardware_Spec
NanoPi R2S
(BE WARNED! IF IT IS VERY CHEAP (BELOW 50€) YOU PROBABLY ARE ONLY BUYING THE COOLER WITHOUT THE COMPUTER!)
keep up the good stuff
In my opinion we should stay away from FriendlyArm / FriendlyElec.
I don’t have any experience with the Rock Pi devices…
it says “Dual G-LAN network 1000Mbps x2”
https://trading.made-in-china.com/start-order.html?from=3&prodId=CwPGhReJfScK&sample=1
looks pretty interesting, but as written above, “Made in China” that ships directly from China: no support, no warranty, no nothing, so it MIGHT be better to go with ROCKPro64 4GB Single Board Computer - PINE STORE
- LTS (long Term Supply)
- PINE64 committed to supply at least for 5 years until year 2023 and beyond (src)
or devices from https://www.concept.biz/
2 Likes
yes you are right, with all “Made in China” there is no service, no refunds, nada
this is the cost of shipping all jobs and factories to Asia.
if u got me an Made in US or Made in EU or Made in South Korea or Made in Japan alternative, let me know 
so the “only” solution is, to buy from a middle-vendor that sits in US/EU like https://www.concept.biz/ (expensive, but there will be at least 1 year warranty + service + support)
this board (less expensive, a bit slower) could be upgraded with a PCIe LAN card and then it also has Dual-LAN
this guy suggest as well, could be upgraded with a 4x LAN PCIe card (UNTESTED!) to have 5x LAN
Just a collection of interesting informations
Maybe helpful
Best
1 Like
Since some days I have an R5S Naopi here (the one with three ports) and really like it. Until now I tried several images from friendlyelec but the main purpose for this device was a firewall to separate different networks - so I found IPFire and thought: How to install it?
So reading all the above I am not really sure - do I have a chance to get it up and running? Was there support for those boards built in since the discussion last August? Should I use the aarch64 Flash Image?
Sad that there seems no ARM support.
It means I need to go with OpenWrt
1 Like
Jep, initially IPFire was exactly what I wanted, but the image did not even boot, at least the Flash Image.
1 Like