PC Engines EOL
pcengines.ch
pcengines.ch
I have had an APU2C4 acting as my firewall (running OpnSense) at home for the past few years. It's been pretty a pretty good little box. My singular complaint is that the CPU has always been much slower than I'd like. Standard firewall functionality works fine, but doing any admin stuff involving package management takes ages, even with an SSD.
I'm not sure what I will replace it with when the time comes. Despite talk of alternatives in these comments, there is nothing on the market that checks all of the same boxes that the APU2 does: 1) AMD64 2) fanless 3) low power 4) multiple interfaces 5) under $200.
A Raspberry Pi would be an excellent choice if they ever offered one with multiple gigabit interfaces. But it's the only ARM board I would currently consider for the role.
* Much better options for flash storage; it's real easy to buy an extreme high endurance m.2 with the device, vs constantly rolling the dice with a microsd card on a raspberry pi. The APU also has a SATA port and an SD card slot (which they also provide very high endurance SD cards for).
* x86 + coreboot means the device is well understood and open, and will run basically anything you want unmolested. No need to deal with crazy Broadcom firmware.
* High quality Intel Gigabit NICs mean they always "just work" in Linux, and work well.
* Expandable with m.2 pcie cards instead of relying on USB...PC engines will sell you a good vetted 802.11 card that basically just drops into their existing chassis.
* I think all of the APU2s have ECC ram.
* Before the Raspberry Pi 4, the APU2 had significantly more compute power than any prior RPi. I don't own a Raspberry Pi 4, so I have no idea how they stack up.
I've had a bunch of these for years now, and they all run unmolested basic Debian, and I've never seen one of them fail (I've seen an Alix fail, but it was recent and that unit has to be very, very old at this point). Every Raspberry Pi I've ever used has felt like a gamble whether or not it was going to die (I've lost a few, not being abusive to them either). In a router, it's absolutely worth it to know that every time that device powers up, it's going to work.
> people still buy the WRT54GL in large enough numbers that Linksys continues to earn millions of dollars per year selling an 11-year-old product without ever changing its specs or design. "To be honest, it somewhat baffles my mind," Linksys Global Product Manager Vince La Duca told Ars. But production won't stop any time soon as long as Linksys' suppliers, including chipmaker Broadcom, keep selling the parts needed to build the WRT54GL. "We'll keep building it because people keep buying it," La Duca said ... The WRT54GL and other routers in the WRT54G line have sold 31 million units in their 14-year lifetime. The WRT54GL is the only one still being manufactured and sold.
ODROID-H3/ODROID-H3+, maybe? [1, 2]
1) AMD64/x86-64 architecture (Intel chip).
2) optional fan; I'm unsure if it's necessary for any particular load
3) 2W at idle up to 18W with CPU+GPU pegged
4) 2 2.5GbE NICs builtin, M.2 card available to add another 4
5) bare board is $165 direct from hardkernel (H3+) or $129 (H3). Almost certainly over $200 once you include RAM, SSD, case, power supply, and shipping, but I think the same is true for pcengines stuff too?
What I would wish for would be a low-cost embedded solution (< $400) with support for ECC memory.
[1]: https://protectli.com/
[2]: https://www.hardkernel.com/ low-power, fanless
open-source coreboot firmware
Intel NICs (vs Realtek)
open schematics
USB, SD, SATA or mSATA storage
ECC RAM
GPIO
TPM and DRTM
3rd party cases for rack/wall mount
supported by Linux, Xen, OpenBSD, FreeBSD, pfSense, OPNsense
Alternatives have different feature subsets, https://news.ycombinator.com/item?id=35635900#35636898
It's not listed, but they used to sell Infineon TPMs for the LPC socket. Have you emailed them to ask?
The pros of Hardkernel are open schematics (same as PC Engines), which is crucial if one would like to have open-source firmware like coreboot. Quite good testing documentation, transparency, and community. UP2 does not provide schematics, and their support could be better, which can be proven by reading their forums. There needs to be a sense of transparency and community building for UP2.
Of course, UP2 and Hardkernel products have other drawbacks compared to PC Engines, namely, no D-RTM, fewer NICs, higher TDP, no ECC, etc.
- has at least three network interfaces
- is a relatively straightforward x86 system you can just slap a mainstream Linux distro on
- is small enough to be integrated into a custom enclosure
- is affordable.
It's been a reliable platform with only one broken serial port and one broken ethernet interface in some 500 deployed systems (flash endurance is another story, however).
That said, I have been extremely happy with my old WRAP boards; they worked for years without a hitch with PfSense (now I would use OpnSense), and didn't swap them with newer PcEngines boards just because at that time they were already a tad slow for today's Internet.
ServeTheHome has some video reviews and user forum threads on them.
Still holding my breath for a Ryzen-Embedded-based APU successor but that's the closest I'm aware of.
In any case, due to COVID-induced shortages we already had to transition away to other hardware. This has been a huge relief as we had to ditch our custom legacy software stack built on APU+OpenWRT and came up with a generic Ansible/AWX based solution you can run on almost any platform with no tweaking.
Something like this? https://www.solid-run.com/fanless-computers/industrial-embed... (can't find prices yet, sadly.)
Also some time this year a successor to the (Zen1 and very dated) Epyc 3000 series is supposed to show up. I've been running 2 of those and they were nice back when they were fresh. Much more of a small-server setup though.
- no ECC
- no DRTM
- no schematics
- no open-source firmware support
Trustworthiness of those devices is at least questionable.
Today AMD announced [1] Ryzen 5000 with network appliance as target market. I can only imagine how expensive it would be in final design.
[1]: https://www.amd.com/en/newsroom/press-releases/2023-4-20-amd...
They weren't part of the wish-list I replies to, though!
The cost depends on how much memory / storage you need, obviously, but it's not that different from the ALIX/APU once you include things like power supplies, cases, etc.
I built a home OpenBSD router several years ago using the APU2. I haven't touched it/loggied in for several years although I keep meaning to so i can update the OS. It's been sat ticking along nicely doing DNS, DNS filtering, cross subnet routing, wireguard for remote hiccup free.
I'm not sure there's any equivalent now?
$400 HP T740 Ryzen Embedded thin client from eBay, add Intel PCIe quad port NIC, https://www.neelc.org/posts/hp-t740-freebsd/
$800 OPNsense Ryzen Embedded 10GbE router, https://wiki.junicast.de/en/junicast/review/opnsense_dec740
1: https://www.asrockrack.com/general/productdetail.asp?Model=D...
Thanks for linking!
https://www.amd.com/en/products/embedded-minipc-solutions
https://www.amd.com/en/products/specifications/embedded-cata...
Meanwhile, AI cloud compute depends on data from edge sensors, https://www.servethehome.com/amazon-building-for-retail-stor...
> Between cameras and CCTV, it now takes over 2000 cameras and 100,000 sensors to run a retail establishment. So much, so that the edge processing demands led Amazon to start its own OCP project to meet the processing and networking needs.
What really sucks is that this frell over a huge market segment. Industrial embedded stuff is all crazy expensive. New embedded systems are often $700 plus.
I'm also curious to know what availability on embedded parts is. I get the impression old parts aren't necessarily easy to get, much less get with reasonable discount prices. The low-end R1505G from 2019 was $80 when announced, & my vague impression is this is still about as low as one's gonna go for getting a embedded Ryzen chip. The GX-412 chips from 2014 were probably half the price.
It's so awful that the gap between rpi & x86 grows. Sure there are excellent second hand markets, but the x86 market running upmarket is a terrible general situation. Decent embedded chips should be a very cost effective available baseline, should make lots of affordable baseline low frills systems available.
PC Engines designed one of the best-regarded boards of the last decade. It's unlikely that they needed babysitting by AMD.
What they sought from AMD was a low-power embedded SoC without a GPU, in ~price and perf/watt of sub-10W TDP SoC used in the fanless APU2.
An SoC with different TDP and price tier would have meant no upgrade path for APU2 customers, and market development for new customers.
Ryzen Embedded V2000 (2020) customers included casinos. All models included iGPU, https://www.tomshardware.com/news/amd-launches-v2000-ryzen-e...
Ryzen Embedded V3000 (2022) finally dropped the iGPU, https://www.servethehome.com/amd-ryzen-embedded-v3000-launch...
While we're having a moment of silence for PC Engines, they deserve credit for small biz survival through 2020-2022, with supply chain disruptions and grey markets for Intel NICs and other components. Now AMD is ending sales of embedded GX-412TC, with 6 month backlog and >30% drop in laptop sales.
Why can't AMD extend sales of this old SoC until they have a replacement Ryzen Embedded V3000 SKU with comparable power profile? GX-412 is an older node. Customers want to buy it. AMD has struggled to get adoption and design wins for Ryzen Embedded. Why abandon existing embedded customers?
AMD has definitely scaled up but a configurable 10W TDP hardly seems like a showstopper. It's a little hard to know what TDP really means these days, which complicates, but it feels like some give/take in design to handle a 10W chip should be managable.
Overall good post & a great different view. I'm not convinced of either your view nor what I've said. It just doesn't feel like it should be a huge blocker as is. And it feels like there should be better than 10 year old offerings that would work.
Solidrun/Compulab in Israel announced a DIN-mountable fanless router based on Ryzen Embedded V3000, https://www.solid-run.com/fanless-computers/industrial-embed.... Premium components and proprietary cooling to support 30W+ TDP. Impressive, but probably $1K price tier.
Indeed today it remains a niche but we see some reasonable momentum and it's getting traction.
Again I don't know anything about PCEngine (reading the title I though they were still making that game console from the 90s...) but I am interested to see where RISC-V could take over some x86 business and that's looks like it.
Many have already chosen RISC-V.
No. All the instructions get turned into uops regardless of what instruction set is exposed. Supporting x86 is an advantage.
>and being "open" and free can be manufactured by anyone.
That makes no sense. You can't manufacture an instruction set.
Compatibility-wise, there's no doubt. The software ecosystem is most broad on x86.
But x86 is really bad at reliability / high assurance due to its complexity and due to obtrusive (SMM mode), non-auditable firmware.
Those modes are one of the ways to enforce export controls. Any competitive chip has something similar, say ARM TrustZone or whatever x86 manufacturers name their security mode.
If you don't put such features, the Asian manufacturers will instantly copy your IC.
Yet, the most reliable services people use every day run on x86. It's not "really bad".
>due to its complexity
I don't see the complexity of the instruction set causing downtime. Compilers abstract 99% of it away.
>due to obtrusive (SMM mode), non-auditable firmware.
I've never seen SMM mode cause down time, nor have I had the non-auditability of the firmware caus me down time. These are low level things that are a part of how the CPU works. When you are working at a high level you can just ignore them for the most part. For reliability you are always going to need to be able to handle bad chips due to manufacturing defects once you are operating at scale.
When reliability is paramount (e.g. pacemakers), x86 is naturally avoided.
>I don't see the complexity of the instruction set causing downtime. Compilers abstract 99% of it away.
Complexity of the ISA affects the whole system. It breeds bugs not just in hardware, but also in operating systems and toolchains. These can affect reliability.
>I've never seen SMM mode cause down time
I have. With SMM, the rug is pulled under the OS's feet. Your CPU can be taken away at any time, for any unexplained reason, without prior warning, and for an undetermined amount of time.
I have seen SMM cause spikes of latency breaking pro audio pipelines, and I have seen SMM grab a CPU and not return it.
Hyperscalers (OCP) pushing for coreboot and LinuxBoot have probably different experience. AFAIK they hate SMM especially with SMI handlers coming form unknown source.
Not saying SMI latency is huge problem in industrial applications like CNC.
APU2 ships with open-source coreboot firmware and DRTM-capable silicon for measured OS launch with TPM.
Let's be honest every architecture has the same problem of parallel "trusted" execution environment, some have even more than one.
- ARM TrustZone
- POWER SBE
- RISC-V SBI
For starters, it is a fairly simple, open specification of an interface[0], with an open implementation, opensbi, that so far everybody uses.
Furthermore, it is not "hidden" in any way from the OS, which can take over its roles, partially or completely.
The openness of specification only matters a little here - UEFI specification about management mode is also open. But IBVs screwed us many times [3] by implementing low-quality SMIs that could elevate privileges, and the spec does not guarantee that implementers follow it. Lack of tooling makes compliance difficult - it slowly changes with various startups seeing that as an opportunity (e.g., Binarly, Eclypsium?).
My point is that SMM as TEE is not a unique x86 feature, and other significant architectures have similar mechanisms. OS has a means of figuring out that it was in SMI, so it is not entirely hidden but still has superpowers. In the CNC world SMI latency is measured from OS [4].
Trusted execution environments are hammers and can be used for a good purpose in a transparent way and for malicious purposes. Further typically depends on the trustworthiness of mechanisms implemented and used by vendors, but thus keep the fact that TEEs and peripheral MCUs are everywhere, which may lead to the extended attack surface.
Why do we see those TEEs, peripheral MCUs, everywhere? I like the explanation in this lecture [5]. No architecture can quickly fix that problem.
[1]: https://hex-five.com/multizone-security-tee-riscv/
[2]: http://docs.keystone-enclave.org/en/latest/Getting-Started/H...
[3]: https://research.nccgroup.com/2023/04/11/stepping-insyde-sys...
[4]: http://wiki.linuxcnc.org/cgi-bin/wiki.pl?FixingSMIIssues
It already did well enough by standardizing SBI and by providing a high-quality open implementation of it.
This minimizes (or even removes) incentives to provide a proprietary solution.
Some vendors will of course do whatever they want, instead of just using opensbi.
But they'll be opting out of being compliant with the platform specs, and of benefiting from the support for SBI present in operating systems and embedded toolchains. Such an implementation would just make themselves and everybody else miserable.
In an ideal world, the market will avoid non-compliant SoCs. In practice, there will be some of these to point at as examples of how not to operate.
RISC-V doesn't give you a magic wand to create chips. It just gives manifacturers easier terms for licensing. Not you or PC Engines an easier time to design and source things. AMD also has all the licenses it wants. The advantages that RISC-V brings doesn't affect them.
Moreover any actual RISC-V chip that's worth replacing the AMD in PC Engines will be at least as proprietary as the AMD chip. It will have its own design requirements that PC Engines still needs to obtain from the whatever manufacturer.
RISC-V only makes the job of the IC manufacturers easier. For everybody else, it is yet another thing to struggle with porting.
> Not PC Engines an easier time to design and source things
Isn't it better to rely on a "standard" technology than a proprietary one? x86 is not standard, it's widespread. The Duopoly in place can decide the price, the feature, even its client. They can decide one day to stop providing what you need and that's it. With a standard chip, you can go next door in Shenzhen and get what you need.
> Moreover any actual RISC-V chip that's worth replacing the AMD in PC Engines will be at least as proprietary as the AMD chip
Why? We are not talking about a supercomputer to train LLM here but simple network appliance than needs efficiency. The GX-412TC PC Engines was using, doesn't look that impressive. Aren't there already RISC-V chip today on par with it? Like VisionFive for example?
Anyone can manufacture a chip based around one of Arm's CPU core designs if they pay a licensing fee to Arm, and many different manufacturers do. If you want to, you can even make your own CPU design supporting an Arm ISA, again if you pay a licensing fee.
Likewise, you could license a RISC-V CPU design from some company… for a smaller licensing fee, but you will have RISC-V's worse software compatibility, and probably worse overall performance, efficiency, die area and quality.
The ISA is a tiny piece of the puzzle and not the most important one. RISC-V is cool because Arm won't sue you for making a hobby project that implements it in hardware, but it doesn't solve problems other than “Arm's license fees are too high”.
Unlikely. E.g. SiFive offerings beat the crap of ARM equivalents, in performance, power and area.
>but you will have RISC-V's worse software compatibility,
Using the standard ISA gets you the widest possible ecosystem.
Of course, this isn't true yet, but it will be in practice, when considering the current trends and the fact hardware takes years from the time the decision is made till having hardware in hand.
>RISC-V is cool because Arm won't sue you for making a hobby project that implements it in hardware,
With 10b+ cores shipped in 2022, we're well past the "niche ISA for hobby projects" stage.
https://www.semianalysis.com/p/ventana-risc-v-cpus-beating-n...
> The question on everyone’s mind is when RISC-V will come to user-facing applications. The answer is that this may be closer than people expect. There are currently 4 companies working on large RISC-V cores that compete with the biggest and fastest from Intel, AMD, Arm, Apple, etc. These 4 companies are Ventana Micro Systems, Tenstorrent, Rivos, and Akeana. Each of these companies have teams with impressive pedigrees, but that alone doesn’t guarantee success.
ARM does not actually have a high performance competitive with Intel, AMD, Apple or the incoming high performance cores from those 4 companies.
ARM does not belong in that list.
Should a networking device BOM budget be spent on unused graphics silicon?
Why not? Its not like the silicon is the expensive thing here
That silicon could be spent on additional compute performance, e.g. Ryzen V3000 series without iGPU.
There were also security improvements between Ryzen Embedded V1000 and V3000.
Do embedded customers want a "perfectly sufficient" equivalent of their 8-year old device, or a flexible device with headroom for the next 8 years of sales & support?
PacketShader was from 2010. We have made so little visible progress since then. https://shader.kaist.edu/packetshader/
There has been some progress since then. There's probably other fronts, but my first question to myself here was, "I wonder what P4 (network programming language) has been up to with acceleration." (https://opennetworking.org/p4/). And sure enough there are a couple hits, P4GPU (2016), APUNet (2017), P4GPU (2022). Alas none seem to be open source atm.
FPGA's are the more common target, with so called "smart nics". They're present in lots of fancy cloud hardware & could be excellent at helping us push packets at a good power point. I think if the software market were more evolved people would be clamboring for these things & they would have become more mainstream popular & in demand, & would be available at lot more price points.
AMD should be releasing cpu+fpgas (from their Xilinx acquisition) pretty soon, and if they're smart there'll be some affordable low end options - small ryzen embedded cpus and a modest chunk of network processing fpga - so folks can mess around & get good. We are seeing them start to upstream some software stuff. The actual kernel drivers for the XDMA CPU<->FPGA DMA made it into the upcoming 6.3 (https://www.phoronix.com/news/AMD-Xilinx-XDMA-Linux-6.3), there's a whole new FPGA bus "CDX" that is slated for 6.4 (https://www.phoronix.com/news/AMD-CDX-For-Linux-6.4), and there's a LLVM-based eBPF XDP C code to FPGA compiler Nanotube (https://www.phoronix.com/news/AMD-Xilinx-Nanotube-Compiler) that... well... looks like it might categorically enable these use cases with almost no effort. (After years of being thrashed by awful OpenWRT router's quirky vendor packages for network accelerating, I say: heck yes, yes pleaseeeee!)
GPUs do indeed seem >50% likely to be bypassed, that FPGA just fits better & wins faster. But they both had & have a ton of potential. Especially if there are APU style GPUs that have shared memory (where there's not the latency of sending stuff back and forth over PCIe). Think of all the years ago AMD tried to sell us "Fusion" and Heterogenous Systems Architecture (https://en.wikipedia.org/wiki/Heterogeneous_System_Architect...). Well, here we are 12 years latter & it's happening. It could already have happened, we just didn't have software to actualize it, especially in the networking domain.
To your point, I do think 2 cores can be a potential issue. Ideally the iGPU should be able to power down quite effectively, ideally d3 cold sleep. Wasting the silicon isn't ideal, but generally I think a vanishingly small iGPU has such a small penalty to include, adds so much value to a chip for so little real cost. It feels overzealous to me to exclude iGPU-having chips & I think it's based in older prejudices from times when iGPUs used to entail more real trade-offs, with more impactful power budget & chip-size hits. What's important now is whether there's enough processing (which the networking world for now continues to ask for in the form of CPU), memory bandwidth, and network bandwidth, at solid price and power points.
We have so few examples to learn from, so few embedded machines available these days at reasonable price points (<$400), that I think we just don't know how suitable what we have would be or not.
I went once in Zurich and knocked at the door of PC Engines to buy a Wistron wifi card (it was cheaper then shipping it to Belgium), it was one guy in a house with plenty of hardware. Memories!
Some factual mistakes I have read in this lengthy thread (not going to individually jump to each post to reply there):
APU2-3-4-5-6 all models running literally the same ~10 year old obsolete prehistoric SoC / CPU. And to be precise, its clock speed is just 1.0Ghz! Not 1.4Ghz! It makes a huge difference in this case, ~40%. The 1.4Ghz is a boost clock speed, and its only possible for a single (1!) core, and only while the other 3 cores are literally idle. The 1.2Ghz boost is an interim clock speed though. Quite unrealistic sustained workload, right? So if you want to calculate performance based on clockspeed and IPC, you'd need to assume the 1.0Ghz, and not the 1.4. By the way, this CPU boost feature was broken since inception, until 2019, so literally only 1.0Ghz was possible even for single core workloads until that time. Have to mention it was a PITA for the firmware developer subcontractor (a word about this as well below) to make it work with lot of sweat and blood and tears. Thanks to AMD being a jerk, and not providing any support document for these folks. (People assume its only Intel who the dick company is. But I can assure everyone, AMD is the same arrogant profit-oriented a..hole company, as Intel. No difference! Just because Zen is successful in the past t-6 yrs, AMD is still a difficult company to deal with, if you are an embedded system integrator partner of theirs. End of rant.)
- ECC: thats another misleading feature: its mentioned (very only in the schematics PDF, nowhere else you will find this technical info clearly written in the APU2 models page: only the 4GB RAM model has ECC. The 2GB models DO NOT HAVE ECC! As a proof, you can see it for a fraction of second when the BIOS boots, and you see the RAM information. If you bought a 2GB board, believing you'll also have ECC, you are screwed!
Intel 210 vs 211 NIC: because the quad-core CPU in this prehistoric SoC is so low powered, it DOES MATTER that the i210 supports 4TX&RX queue, but the i211 only supports 2! So if your workload is heavy packet processing, the i210 is a must! As the i211 wont be able to distribute packets evenly among all the 4 cores, only between 2, so performance will suffer.
Bonus little known fact: PPPoE protocol does not support the RSS (Receive Side Scaling) protocol, because PPPoE is NOT based on IP. So all your PPPoE traffic will hammer CPU0, and that core only. Performance will suffer. Nowhere near close to gigabit routing under such conditions buddy! Just you wont read this caveat anywhere, thanks "sponspored" reviewers, hiding this painful fact! The internet is full of people complaining about their gigabit speed not achieved, and it always turns out a PPPoE-type of subscription is in service.
Firmware: because pcengines is a 1manshow company, he (she?) outsourced writing the BIOS for APU to a polish company called 3mdeb. When you buy an APU, you rely on a 3rd party company to provide coreboot BIOS support.
As if you bought a motherboard from Asus or Gigabyte, but the UEFI comes from an "unknown" company. When they bankcrupt, and you go to Asus/Gigabyte, they will tell you: sorry, but the bios is not provided by us for your motherboard, go complain to that company who (was) responsible for it! Sounds strange, right?
So in short, there is no such thing as a default non-coreboot BIOS in the APU product. This became an issue, when people wanted to see improvements on the BIOS, and the PCENGINES github issue tracker was full of open items. And the 1manshow pcengines company replied that its 3mdeb who writes the bios, pcengines doesnt deal with such topics. Contractually the customer bought a product, that is branded as PCENGINES, not a oroduct that has the 3mdeb logo on it, I hope you see my point.
But anyway, this was sort of ok until very recently. In Aug 2022, the continuous flow of coreboot releases for APU stoppes suddenly. Feeling the coming bankruptcy of pcengines, 3mdeb backtracked from the relationship this February (the CEO of 3mdeb confirmed this on various forums). So everyone who is following the story knew, that pcengines APU is officially dead by now.
Last point: it is very disappointing, that this product will be gone. While it had its limitations and weaknesses, it was a so-so performant and reliable x86 router solution. As many pointed out, full-x86-64 compatibilits, noFAN, ECC, multi-NIC support was the pros. Cannot understand why on earth there are no other zen1-2-3based embedded routers in the 10Watt-range, that consumers could buy, without paying the artificial "embedded-so-it-will-cost-100%-more" TAX? Also I have to question PCENGINES 1manshow person as well: built a product 6 years ago (if I am not mistaken, APU2 has been released in 2016-17?), the EOL of the SoC was known on the 1st day. But did not prepare another alternative, based the whole company on literally only 1 product (apu2-3-4-5-6 are all based on the same SoC, so technically they are still 1 product, even if there are differences in the # of NICs, and the SIM slots). So when the known EOL time comes, hasnt prepared for a new product? Yes I know, AMD to blame. But seriously, throwing away this whole market segment?
Connecting to its serial port brought up a Linux prompt, but I didn't know the password. I popped the compact flash card into a reader; maybe I could see it in the password file in /etc? Hmmm... seems to be encrypted. Well I have write access too; can I just... make the password empty?
I was fairly new to Linux at this time, so the fact that that worked was a huge boost to my confidence. I played around with putting different minimal Linux distros on it, and just generally having fun fooling around with a tiny x86 SBC.
When I needed a new router for my home network, there was no question but that I was going to get one of these (though I got the newer APU2 board of course).
I can't believe PC Engines is shutting down! End of an era.
I also have fond memories of my personal Soekris box running m0n0wall in the early 2000s (I think back then pfSense was more bloated/slow on limited hardware). My experience with that setup was definitely what made me consider the PC Engines equipment for work.
Similarly I have also switched to Ubiquiti for home use.
I coincidentally replaced mine just before this with 2.5G arm64 based board, also fanless.
Thanks!
[1]: https://voidst.one/posts/comprehensive-guide-to-pc-engines-a...
With upstream coreboot support, one could build the firmware.
I remember building it, see https://github.com/pcengines .
While RPi prices are still stupid, there's a variety of low-spec IoT ESP32, STM32, and pocketbeagle. Bananapis are far more capable than RPis for about +50% $.
If you have more money, embedded Ryzen and EPYC such as used by Deciso OPNsense boxes (FreeBSD-based).
https://shop.opnsense.com/dec800-series-opnsense-desktop-sec...
https://premioinc.com/pages/amd-ryzen-embedded-single-board-...
Glad I got in while they're still being made. It seems like an underserved niche.
Question to HN: What hardware are you using today for things you would have used an APU for a decade ago?
At 10G and above, it's just very hard for such CPUs to keep up, and reasonable power usage seems to require hardware acceleration.
I think part of the issue is the tiny ethernet frame size. Dealing with millions of packets per second is just hard on a low power CPU. And unfortunately due to the internet, jumbo frames are only a viable thing on the inside.
So now the equation swings towards purpose-built devices that can actually accelerate routing, bridging and firewalling in hardware.
What we were able to realize over the years of writing firmware and researching new solutions for network appliance vendors is that support for accelerators is considered a premium feature and typically is available only behind paywall corporate unobtanium. Consider very respected silicon vendors, such as Marvell [1] or NXP [2].
If you have in mind hardware (no matter if x86, Arm, RISC-V, or POWER) that would be able to mark all checkboxes that PC Engines score [3] with 10G performance, then it would be exciting competition otherwise, we are very far from community expectations, where most BSD users with open-source firmware based hardware choose PC Engines or Protectli [4].
[1]: https://www.spinics.net/lists/linux-crypto/msg53306.html
[2]: https://www.nxp.com/support/support/nxp-engineering-services...
[3]: https://news.ycombinator.com/item?id=35636960
[4]: https://bsd-hardware.info/?view=computers&f=node_coreboot&v=...
My comments is about designs that potentially could meet the requirements, but surprisingly those have different problems. How we know those designs? We consult for firewall vendors doing research. We would be glad to be wrong by being pointed to viable competing solution which can reach score close to PC Engines. Performance is not the only factor for small ISP and security-concious privacy-concerned infrastructure builders.
So it is not that trivial to purposefully build firewall these days that can compete with PC Engines low power consumer/SOHO design.
If I may, my current NAS runs off a 10+ years old Atom D410 which is way slower than the GX412, still perfectly adequate for managing two ZFS pools and serving them over a local network via NFS and CIFS while running some other services. I'm sure if you moved from firewalls to other things, you could find other niches in need of new products, especially now that the Raspberry Pi 4, which is comparable speed wise is nearly unobtanium and way overpriced. How much would it cost to design two new boards, say one with 1 or 2 NICs and 5 SATA ports, then one with one NIC, WiFi and a good number of GPIOs? I would surely buy a few of them, and probably others would as well.
Those boxes are at higher price point, but far exceed the apu lineup in features/compute.
All firmware component source code (e.g., ARM Trusted Firmware and U-Boot)
The most recent project update was July 2021? https://www.crowdsupply.com/traverse-technologies/ten64/upda...
https://forums.servethehome.com/index.php?threads/article-yo...
> [Ten64] platform (Layerscape) is somewhat interesting but sadly has been so slow to appear in reasonable products that it has been surpassed by basic Celeron-based systems ... seems to me that the Layerscape platform will go the same route as the Marvell (Armada 385 I think) ones did; one or two revisions and then radio silence where only highly integrated partners still keep using it ... it's not powerful enough as a CPU, and the hardware acceleration suffers from the same problems that basic Broadcom SoCs and higher-end ASIC-accelerators do: they get outdated and useless rather quickly
Ten64's have been shipping for a while now, though you are best to ask in our support forum: https://forum.traverse.com.au/ . We haven't posted much on Crowd Supply as it's a very manual process to get stuff up on there.
I'm not too familiar with TrustZone, but I'm not aware of any limitations in the secure world. I haven't tried OP-TEE or any similar secure world firmware' simply as no one has asked for it.
You can see all our firmware components here: https://gitlab.com/traversetech/ls1088firmware
https://www.youtube.com/watch?v=xZoCtNV8Qs0&t=9080s
https://documentation-service.arm.com/static/620e0f9b0ca3057...
https://review.trustedfirmware.org/q/topic:%22mb%252Fdrtm-pr...
Improving the routing performance in Linux is near the top of my TODO list, however. XDP is one candidate (see https://forum.traverse.com.au/t/vyos-build-my-repo/181/5 for some results) and using the LS1088's AIOP is another possibility.
I see that support for FreeBSD going in good direction:
https://forum.traverse.com.au/t/freebsd-preview-for-ten64/17...
Are there any performance reports for FreeBSD? Especially VPN/wireguard bandwidth would be interesting.
The performance has improved compared to how it was a year ago (e.g struggling to get 400mbps throughput) but there are some severe issues in -CURRENT :( I believe dsl is trying to get them fixed by 14.0-RELEASE.
https://protectli.com/product-comparison/
https://shop.opnsense.com/product-categorie/hardware-applian...
The i7 model has TPM and DRTM features matching the $200 APU2, but costs ~$1000 USD, https://protectli.com/product/vp4670/
I’ve configured ~150 pfSense CE setups on APU2s. It’s a sad day for small businesses. Hopefully Netgate doesn’t increase prices on that low end appliance. I’d love to be proven wrong, but it’s the only pragmatic option now for small businesses.
1. https://shop.netgate.com/collections/desktop-appliances/prod...
used office (thin-)clients make much, much beefier routers and mediacenters without using more power (thou some have fans running at idle load) and costing less.
[0]: https://fitpc.com/