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?
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
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)
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)
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?
They need firmware to make the device boot on power on.
Every device needs its own firmware and linux support which is very difficult to maintain given the low number of device which can fully handle ipfire features.
You might have to add support for this device.
I doubt it will boot as R5S will need its own uboot.
Sadly also, manufacturers of RISC-V SBC are heading down the same path.
Which leaves low wattage x86_64 as the only option for many users. The wattage quoted by suppliers of these systems is misleading. I’ve tested the external power supplies that came with several and none had efficiency greater than 60%.
Thanks for the info, seems like it is more difficult than expected. My idea was to put IPFire to an SD card, plug it in and run it. Seems like I was wrong.
Which is very sad because the R5S is really a device that screams “IPFire device” so loud, my initial plan was to put WAN to WAN port, regular network to port 1 and IoT to port 2 with strict rules set up. Seems like I have to search for an alternative - any hints would be highly appreciated.
Yes, the TDP rating is really misleading. First you read something like “<10W” but then: “10W idle 70Wload” and “100W PSU” and this all with the factory setup, not like e.g. the R5S with 3 NICs that really have good throughput.
The SBC I mentioned is reflected in 
