The Orange Pi 6 Plus
taoofmac.com
taoofmac.com
Sometimes easier to acquire, but usually the same price or more expensive.
Not sure how this compares to the OrangePI in terms of performance per watt but it is already pretty far into the area of marginal gains for me at the cost of having to deal with ARM, custom housing, adapters to ensure the wall socket draw to be efficient etc. Having an efficient pico psu power a pi or orange pi is also not cheap.
A lot of the cheaper mini PCs seem to let the chip go wild, and don't implement sleep/low power states correctly, which is why the range is so wide. I've seen N100 boards idle at 6W, and others idle at 10-12W.
Boost enabled. WiFi disabled. No changes to P clock states or something from bios. Fedora. Applied all suggestions from powertop. I don’t recall changing anything else.
It has major overheating issues though, the N100 was never meant to be put on such a tiny PCB.
It performs well but there is definitely a thermal problem compared to other N100 based systems I got.
It's 127 x 127 x 508 mm. I think most mini N100 PCs are around that size.
The OrangePi 5 Max board is 89x57mm (it says 1.6mm "thickness" on the spec sheet but I think that is a typo - the ethernet port is more than that)
Add a few mm for a case and it's roughly 2/3 as long and half the width of the A40.
Big by comparison, but still pretty small
Unless you strictly need the tiny form factor of an SBC you are so much better going with x86.
I think everyone considering an SBC should be warned that none of these are going to be supported by upstream in the way a cheap Intel or AMD desktop will be.
Even the Raspberry Pi 5, one of the most well supported of the SBCs, is still getting trickles of mainline support.
The trend of buying SBCs for general purpose compute is declining, thankfully, as more people come to realize that these are not the best options for general purpose computing.
Were people actually doing that?
If the RPI came with any recent mid-tier Snapdragon SOC, it might be interesting. Or if someone made a Linux distro that supports all devices on one of the Snapdragon X Elite laptops, that would be interesting.
Instead, it's more like the equivalent of a cheap desktop with integrated GPU from 20 years ago, on a single board, with decent linux support, and GPIO. So it's either a linux learning toy, or an integrated component within another product, and not much in between.
Since the introduction of the OG Raspberry Pi, 14 years ago, there's been an ongoing cognitive problem wherein people look at the price of a brand new, never used SBC that can purchased from a reliable retail company.
Then they also look at the price of a used corpo PC (that is bigger, and noisier) that some rando in Iowa is selling on eBay.
And then they boldly compare the prices of the two things as if these details just don't exist.
But the details do exist. The details show that the two things are not the same. They can never be the same.
One is a shiny fresh apple that is free of blemishes, and the other is a bruised old grapefruit that someone has already started eating. They're both fruit, but they're very different things.
There are at least 3 or 4 SBCs with it, in RPI sizes and prices.
Cortex-A78 is much faster than the Cortex-A76 from RK3588 or the latest RPI (e.g. at least 50% faster at the same clock frequency), and its speed at the same clock frequency does not differ much from that of recent medium-size cores like Cortex-A720 or Cortex-A725.
Cortex-A78 is the stage when Arm stopped making significant micro-architectural changes in medium-sized cores. The later improvements were in the bigger Cortex-X cores. The main disadvantage of the older Cortex-A78 is that it does not implement the SVE instruction set of the Armv9-A ISA.
While mini-PCs with Intel/AMD CPUs are usually preferable, for an ARM SBC I would no longer buy any model that has older cores than Cortex-A78.
Besides the Qualcomm Dragonwing based SBCs, there are also Cortex-A78 based SBCs with Mediatek or NVIDIA CPUs, but those are more expensive.
Raspberry Pi are excellent at being general-purpose, full-Linux boxes that consume very low power (some can idle at <1W). Perfect for ambient computing, cron-jobs, MQTT-related hackery, VPN gateways, ad-blocking DNS servers, or anything else that isn't CPU-bound, but benefits from being always available[1].
1. In my case, this ironically includes orchestrating higher-wattage computers via Wake-on-Lan and powering them down when not needed
I have a couple of RPi4 with 8GB and 4GB RAM respectively, these I have been using as kind-of general computers (they're running off SSDs instead of SD cards). I've had no reason so far to replace them with anything Intel/AMD. On the other hand they can't replace my laptop computer - though I wish they could, as I use the laptop computer with an external display and external keyboard 100% of the time, so its form factor is just in the way. But there's way too little RAM on the SBCs. It's bad enough on the laptop computer, with its measly 16GB.
I think in all cases it's the sheer novelty of doing something with a different ISA and form factor. Having built and racked my share of servers I see no reason to build a miniature datacenter in my home but, hey, to each their own.
I wouldn't wish it upon an enemy, but it's a thing.
I thought raspberry pi could basically run a mainline kernel these days -- are there unsupported peripherals besides Broadcom's GPU?
The major difference is Raspberry Pi maintains a parallel fork of Linux and keeps it up to date with LTS and new releases, even updating their Pi OS to later kernels faster than the upstream Debian releases.
Likewise, the 64-bit version of the OS looks like it supports every Raspberry Pi model that has a 64-bit CPU.
Going big-name doesn't even help you here. It's the same story with Nvidia's Jetson platforms; they show up, then within 2-3 years they're abandonware, trapped on an ancient kernel and EOL Ubuntu distro.
You can't build a product on this kind of support timeline.
If we take a step back, I think this is something to be saddened by. I, too, find boards without proper mainline support to be e-waste, and I am glad that we perhaps aren't producing quite as much of that anymore. But imagine if a good chunk of these boards did indeed have great mainline support. These incredibly cheap devices would be a perfect guarantor of democratized, unstoppable general compute in the face of the forces that many of us fear are rising. Even if that's not a fear you share, they'd make the perfect tinkering environment for children and adults not otherwise exposed to such things.
It's now way easier to write drivers/libraries etc whereas before, smaller hardware wasn't worth dedicating developer cycles.
Worse, if you flash it to UEFI you’ll lose compat with the one system that did support it (older versions of BredOS). For that, you grab an old release, and never update. If you’re running something simple that you know won’t benefit from any update at all, that’s great. An RK3588 is a decent piece of kit though, and it really deserves better.
Not on this list is the current GPU Vulkan drivers Collabora are working on too. Don't think that's really blame Rockchip since they're ARM Mali-G610 GPUs, but yeah those didn't get stable in Mesa until last year.
Don't bother trying anything before kernel 6.18.x -- unless you are willing to stick with their 6.1.x kernel with a million+ line diff.
The u-boot environment that comes with the board is hacked up. eg: It supports an undocumented amount of extlinux.conf ... just enough that whatever Debian writes by default, breaks it. Luckily, the u-boot project does support the board and I was able to flash a newer u-boot to the boot media and then the onboard flash [1].
Now the hdmi port doesn't show anything and I use a couple of serial pins when I need to do anything before it's on-net.
--
I purchased a Rock 5T (also rk3588) and the story is similar ... but upstream support for the board is much worse. Doing a diff between device trees [2] (supplied via custom Debian image vs vanilla kernel) tells me a lot. eg: there are addresses that are different between the two.
Upstream u-boot doesn't have support for the board explicitly.
No display, serial console doesn't work after boot.
I just wanted this board for its dual 2.5Gb ethernet ports but the ports even seem buggy. It might be an issue with my ISP... they seem to think otherwise.
--
Not being able to run a vanilla kernel/u-boot is a deal-breaker for me. If I can't upgrade my kernel to deal with a vulnerability without the company existing/supporting my particular board, I'm not comfortable using it.
IMHO, these boards exist in a space somewhere between the old-embedded world (where just having a working image is enough) and the modern linux world (where one needs to be able to update/apply patches)
[1] https://www.reddit.com/r/OrangePI/comments/1l6hnqk/comment/n...
[2] https://gist.github.com/imoverclocked/1354ef79bd24318b885527...
It's pretty hacky for sure but wouldn't classify it as useless. e.g. I managed to get some LLMs to run on the NPU of an Orange pi 5 a while back
I see there is now even a NPU compatible llama.cpp fork though haven't tried it
But now, I just did the system update, rebooted and got 7.0.0-1 from the package manager, which is never than my x86 laptop. I still have trust issues with this, expecting it to not boot or get up without HDMI output zo.
I guess manjaro just abandoned arm entirely. The options are armbian (probably the pragmatic choice, but fsck systemd), or openbsd (no video acceleration because the drivers are gpl for some dumb reason).
This sort of thing is less likely to happen to rpi, but it’s also getting pretty frustrating at this point.
Er?
https://manjaro.org/products/download/arm explicitly lists the pinebook pro?
Maybe the LLM was wrong and manjaro completely broke the gpg chain (again), but it spent a long time following mirror links, checking timestamps and running internet searches, and I spent over an hour on manual debugging.
Came looking for this. It's the pitfall of 99% of hardware projects. They get a great team of hardware engineer, they go through the maddening of actually producing a thing (which is crazy complex) at scale, economically viable (hopefully), logistic hurdles including tax worldwide, tariffs, etc... only to have only people on their team be able to build and run a Hello World example.
To be fair even big player, e.g. NVIDIA, sucks at that too. Sure they have their GPU and CUDA but if you look at the "small" things like Jetson everybody I met told me the same thing, great hardware, unusable because the stack worked once when shipped then wasn't maintained.
The reality for actual products is even worse. Qualcomm and Broadcom (even before the PE acquisition) are some of the worst companies to work with imaginable. I’ve had situations where we wasted a month tracking down a bug only for our Qualcomm account manager to admit that the bug was in a peripheral and in their errata already but couldn’t share the whole thing with us, among many other horror stories. I’d rather crawl through a mile of broken glass than have to deal with that again, so I have an extreme aversion to using anything but RPi, as distasteful as that is sometimes.
And today that is replaced with a single relatively tiny in area chip (those old FPGAs were huge) from Broadcom, which does literally everything and complies with newest standard and uses tens of watts of power, and it is passively cooled. It's not quite the correct comparison since arch changed in the meantime, but if someone would build an exact replacement for that older big device using new chips and have the same specs, it would be half as big and use under 1000W or even less. And all software is ready to use without reinventing half of it manually.
But yeah, Broadcom's support is slow and opaque. and they will stall any non-major customer for month for almost any request, because they are prioritizing different tasks internally. It's like a drug dealer dependency and there is only one dealer in your town :) .
That’s just the radios, which is their bread and butter. A lot of their other products have similar barriers to entry.
As the sibling comment noted, FPGAs aren’t even in the running. Ignoring their power consumption, the biggest FPGAs only have a hundred thousand or so logic elements. While its not easy to map that to number of transistors per se, even a legacy nodes are capable of much more complex designs than you can fit on an cutting edge FPGA. This really makes a difference even at the lower end because you have to get the timing right between all the different parts of your logic, and making everything smaller gives a lot more room for error (its a lot easier to put delay lines than to reconfigure a section of your design to fit closer to another section).
There are no ARM NUCs at such prices, and even if there were the GNU/Linux support would be horrible.
To me it would be the opposite conclusion: stay away from ARM SBCs with proprietary firmware and just go Intel-x86 NUCs if you don't want surprises.
And yes, RPI was(is?) a proprietary-FW SBC as the Broadcom VideoCore GPU driver was never open sourced from the start and relied on community efforts for reverse engineering, which the rPI foundation then leveraged to sell their products at a markup to commercial customers after the FOSS community did all the legwork for them for free. Like so long and thanks for all the fish.
Meanwhile Intel iGPUs had full linux kernel drivers out of the box. That's why they're great Jellyfin transcoding servers.
I had to throw away, literally, a Gigabyte BRIX, because its firmware did not recognised any distro I throwed at it from internal drives, only if connected externally over USB.
The experiements with various kinds of SSD modules, Linux distros, and UEFI booting partitions, end up killing the motherboard in someway due to me manipulating it all the time, whatever.
Raspberry PIs are the only NUCs I can buy in something like Conrad Electronic, and be assured it actually works without me going through it as if I had just bough Linux Unleashed in 1995's Summer.
The thing is, for such a niche use-cases it's expected it's not gonna have major retailer availability since it's not something the general consumer is gonna be knowledgeable enough for it to sell in high volumes to be wort for retail stores wherever you may live to stock up shelves on NUCs with Linux preinstalled just to cater to your limited demographic who refuses to order online for some reason, is a very tall order and not really a good faith argument for anything.
The market for people who are like "ah shit, I need to spontaneously go out to the store and pick up a NUC right fucking now, and it has to have Linux preinstalled, because I can't wait a couple of days till it arrives online or know how to install Linux myself", is really REALLY small.
On a more serious note, how do you want normies to get introduced to the Year of Desktop Linux, outside WebOS LG TVs, Android/Linux and ChromeOS, instead of getting Mac minis and Neos at said stores?
I guess it is buying SteamDecks to play Windows games. /s
Raspeberry PIs are the few devices that normies can buy with GNU/Linux pre-installed.
LE to your reply from below here: Excuse me but a form of expression for what? The spec sheet of that Gigabyte Brix explicitly lists only Windows 11 as the supported OS, not Linux. You tried to install an unsupported OS, and you broke it in the process. What exactly do you expect the retail store workers to do to fix the issue you yourself caused via using the product in a way it wasn't advertised? You can contact the manufacturer for warranty or return it via the online return window, but the fuckup is still on your end and not the issue of retail workers.
But I was in Target one day anyway, and they had a Raspberry Pi 3 kit for sale on the shelf. IIRC, it was one of the Google DIY smart speaker kits. I thought that was neat to see.
My usual source for Raspberry Pi stuff is Microcenter. That's also not near to me, but it's a viable destination that's worth a trip all on its own.
At this Microcenter, they move enough Pi hardware that they don't even have them on the shelves anymore. They're instead stocked at each checkout register, and priced at or below MSRP. They're right there alongside a wide assortment of minimally-packaged house-brand SD cards and USB keys and other geek fodder.
It's quick and easy to walk in and grab a couple of spools of printer filament, some 22AWG solid wire for breadboarding, a card of LR44 batteries for the digital calipers, and a Raspberry Pi. (Well, it can be quick. Last time I went, I got sucked into the mechanical keyboard department for an embarrassingly long time.)
Anyway, they also have NUC-shaped computers there if someone wants go that direction instead. Just pick one out, pay for it, and take it home.
IMO the key benefit of a Pi over an x86/a64 box, assuming you aren't using the IO breakouts and such, is power efficiency (particularly at idle-ish). The benefits of the x86/a64 boxes is computing power and being all-in-one (my need was due to my Pi4-based router becoming the bottleneck when my home line was upgraded to ~Gbit, and I wanted something with 2+ built-in NICs rather than relying on USB so didn't even look into the Pi5). Both options beat other SBC based options due to software support, the x86/a64 machines because support is essentially baked in and the rPi by virtue of the Pi foundation and the wider community making great efforts to plug any holes. A Pi range used to win significantly on price (or at least price/performance) too, but that is not the case these days.
This is a common business model sadly where the seller wants the buyer to buy an additional support contract for any actual firmware development.
As far as I can tell, the OrangePi 6 remains distinctly uncompetitive with SBCs based on low-end intel chips.
- Orange pi consumes much more power (despite being an arm CPU) - A bit faster on some benchmarks, a bit slower on others - Intel SBC is about 60% the price, and comes with case + storage - Intel SBC runs mainline linux and everything has working drivers
Unreliable USB: https://github.com/raspberrypi/linux/issues/3259
Unreliable Wi-Fi:
* https://github.com/raspberrypi/linux/issues/7092
* https://github.com/raspberrypi/linux/issues/7111
* https://github.com/raspberrypi/linux/issues/7272
I don't understand why many say that RPi software/firmware support is 'fantastic'. Maybe it used to be in the beginning compared to other chips and boards, but right now it's a bit above average: they ignore many things which is out of their control/can't debug and fix (as in Wi-Fi chip firmware).
Because other vendors are way worse. Those tickets would not be "unreliable" but simply "broken" with a "Won't fix" status.
Check the Wi-Fi tickets, they are sitting without any replies from the RPi team since 2025. It is broken in these configurations, I decided not to use this strong general term for this case (it's broken only in certain configurations and use cases).
The USB bug (from 2019) has not be fully fixed. They got it much less extent, but did not eliminate the issue.
>Because other vendors are way worse.
There's only a single difference: Chinese vendors don't fix issues in both things they do control and in things they don't. The thing they control is usually a "Distro Build" or Buildroot rootfs hierarchy, which I personally see little value in.
Bugs related to third-party hardware and firmware present on the board gets rarely fixed by both sides.
Don't get me wrong, I'm absolutely not happy with it. I bought Intel NUC, which has Intel Ethernet and Intel Wi-Fi, as my PC with the idea that Intel has end-user support and writes drivers, and NUCs should come with golden Linux support, right? Yet Intel developers still supposed that I had to fix the bug in Intel drivers myself: https://marc.info/?l=linux-pci&m=175368780217953&w=2
There's a reason people just default to RaspberryPi even though better _hardware_ exists. RPi at least gets drivers and software support consistently.
This is the problem with every SBC that is not a Pi. I don't understand how they just ignore the software problem. I guess people keep buying them?
Often they can go their entire lifespan without some hardware feature being usable because of lack of software.
The blunt truth is that someone has to make that software, and you can't expect someone to make it for you. They may make it for you, and that's great, but really if you want a feature supported, it either has to already be supported, or you have to make the support.
It will be interesting to see if AI gets to the point that more people are capable of developing their own resources. It's a hard task and a lot of devices means the hackers are spread thin. It would be nice to see more people able to meaningfully contribute.
Right?
Proprietary and closed? One can hope.
https://github.com/tianocore/edk2-platforms/tree/master/Plat...
However many of these ARM chips have their own sub-architecture in the Linux source tree, I'm not sure that it's possible today to build a single image with them all built in and choose the subarchitecture at runtime. Theoretically it could be done, of course, but who has the incentive to do that work?
(I seem to remember Linus complaining about this situation to the Arm maintainer, maybe 10-20 years ago)
I think it's a good thing that people are realizing that these SBCs are better used as development tools for people who understand embedded dev instead of as general purpose PCs. For years now you can find comments under every Raspberry Pi or other SBC thread informing everyone that a mini PC is a better idea for general purpose compute unless you really need something an SBC offers, like specific interfaces or low power.
Is it the lack of drivers in upstream? Is it something to do with how ARM devices seemingly can't install Linux the same way x86 machines can (something something device tree)?
On the one hand there is no stable driver ABI because that would restrict the ability for Linux to optimize.
On the other hand vendors (like Orange Pi, Samsung, Qualcomm, etc etc) end up maintaining long running and often outdated custom forks of Linux in an effort to hide their driver sources.
Seems..... broken
ARM devices aren't even really similar to one another. As a weird example, the Raspberry Pi boots from the GPU, which brings up the rest of the hardware.
The lack of standardized boot and runtime discovery isn't such a big issue; u-boot deals with the former and devicetrees deal with the latter, we could already have an ecosystem where you download a bog standard Ubuntu ARM image plus a bootloader and devicetree for your SBC and install them. It wouldn't be quite as elegant as in x86 but it wouldn't be that far off; you wouldn't have to use SBC-specific distros, you could get your packages and kernels straight from Canonical (or Debian or whatever).
The reason we don't have that today is that drivers for important hardware just isn't upstream. It remains locked away in Qualcomm's and Rockchip's kernel forks for years. Last I checked, you still couldn't get HDMI working for the popular RK3588 SoC for example with upstream Linux because the HDMI PHY driver was missing, even though the 3588 had been out for many years and the PHY driver had been available under the GPL for years in Rockchip's fork of Linux.
Even if we added UEFI and ACPI today, Canonical couldn't ship a kernel with support for all SBCs. They'd have to ship SBC-specific kernels to get the right drivers.
Now maybe the O6 also happens to only use hardware which works with upstream kernels, I don't know. I haven't been able to find anything definitive about that (though the fact that they link to special "Orion O6" versions of Fedora and Debian rather than their standard ARM images doesn't inspire confidence). But that's independent of UEFI.
I think so because I looked in up when it was released and people were able to boot standard images ("All UEFI based ARM images with Mainline Kernel 6.6 and above" [0]). Their specific Fedora and Debian images reflect the progress in better support in the CPU, GPU, etc.
Looking back I should have bought many of those just for the 64Gb of RAM...
- [0] https://sbcwiki.com/docs/soc-manufacturers/cix/cd8180-p1/boa...
I doubt this. Microsoft played a role in standardizing UEFI/ACPI/PCI which allows for a standardized boot process and runtime discovery, letting you have one system image which can discover everything it needs during and after boot. In the non-server ARM world, we need devicetree and u-boot boot scripts in lieu of those standards. But this does not explain why we need vendor kernels.
What is this supposed to mean? There is no device tree to rebuild on x86 platforms yet you can have a custom kernel on x86 platforms. You sometimes need to use kernel forks there too to work with really weird hardware without upstream drivers, there's nothing different about Linux's driver model on x86. It's just that in the x86 world, for the vast, vast majority of situations, pre-built distro kernels built from upstream kernel releases has all the necessary drivers.
Someone still has to put in meaningful effort to get the AI to do it and ship it.
The flash images contain information used by the bios to configure and bring up the device. It's more than just a filesystem. Just because it's not the standard consoomer "bios menu" you're used to doesn't mean it's wrong. It's just different.
These boards are based off of solutions not generally made available to the public. As a result, they require a small amount of technical knowledge beyond what operating a consumer PC might require.
So, packaging a standard arm linux install into a "custom" image is perfectly fine, to be honest.
the firmware is usually an extremely minimal set of boot routines loaded on the SOC package itself. to save space and cost, their goal is to jump to an external program.
so, many reasons
- firmware is less modular, meaning you cant ship hardware variants without also shipping firmware updates (the boot blob contains the device tree). also raises cost (see next)
- requires flash, which adds to BOM. intended designs of these ultra low cost SOCs would simply ship a single emmc (which the SD card replaces)
- no guaranteed input device for interactive setup. they'd have to make ui variants, including for weird embedded devices (such as a transit kiosk). and who is that for? a technician who would just reimage the device anyways?
- firmware updates in the field add more complexity. these are often low service or automatic service devices
anyways if you're shipping a highly margin sensitive, mass market device (such as a set top box, which a lot of these chipsets were designed for), the product is not only the SOC but the board reference design. when you buy a pi-style product, you're usually missing out on a huge amount of normally-included ecosystem.
that means that you can get a SBC for cheap using mass produced merchant silicon, but the consumer experience is sub-par. after all, this wasn't designed for your use case :)
Using whatever compute you have sitting in a drawer usually makes the most sense (including an old phone).
Can also plug in a power bank. https://us.ugreen.com/collections/power-bank?sort_by=price-d...
The advantage is that if the machine breaks or is upgraded, the dock and pb can be retained. Would also distribute the price.
The dock and pb can also be kept away to lower heat to avoid a fan in the housing, ideally.
Better hardware should end up leading to better software - its main problem right now.
This 10-in-1 dock even has an SSD enclosure for $80 https://us.ugreen.com/products/ugreen-10-in-1-usb-c-hub-ssd (no affiliation) (no drivers required)
I'd have another dock/power/screen combo for traveling and portable use.
How much otherwise highly useful stuff are people sitting on that they can't get going (or going well) for one reason or another? Also, recycling I expect will end up important at some point, and knowing who has what (and where) could expedite this process.
With that being said, CIX and their main board partner, Radxa, have been open with the UEFI.
I am not an expert in low-level environments such as the kernel or the UEFI, but if these tidbits sound interesting I would encourage anyone who is to look further into the CIX P1. To my untrained eyes, CIX looks like a company that is working towards a desktop/laptop chip with real UEFI/ACPI support. I look forward to the day it is polished up a bit.
``` alias findpi='sudo nmap -sP 192.168.1.0/24 | awk '\''/^Nmap/{ip=$NF}/B8:27:EB|DC:A6:32|E4:5F:01|28:CD:C1/{print ip}'\''' ```
On every `.bashrc` i have.
But I just don't get... everything, I don't get the org, I don't get the users on hn, I'm like skinner in the 'no the kids are wrong' meme.
It's a lambda. It's a cheap, plug in, ssh, forget. And it's bloody wonderful.
If you buy a 1 or 2 off ebay, ok maybe a 3.
After that? Get a damn computer.
Want more bandwidth on the rj45? Get a computer.
Want faster usb? Get a computer.
Want ssd? Get a computer
Want a retro computing device? Get a computer.
Want a computer experience? Etc etc etc, i don't need to labour this.
Want something that will sit there, have ssh and run python scripts for years without a reboot? Spend 20 quid on ebay.
People demanded faster horses. And the raspi org, for some, damn fool, reason, tried to give them.
There are people bemoaning the fact that raspberry pi's aren't able to run LLM's. And will then, without irony, complain that the prices are too high. For the love of God, raspi org, stop listening to dickheads on the Internet. Stop paying youtubers to shill. Stop and focus.
You won't win this game
> On every `.bashrc` i have.
You might want to try mDNS / avahi
It's like commercial success is a three step tragedy:
(1) solve 1 problem well
(2) pivot to trying to solve all problems for all users, undermining (1) but chasing mass adoption
(3) pivot back to solving 1 problem again, this time for a very specific whale customer with very specific needs, undermining (1) and (2)
I would say Arduino is at step (3) and RPI is at (2)
That's how PCIe works. A PCIe port - both upstream and downstream - is a "PCI bridge". The link is one bus. A switch chip's "interior" is another bus. The next links are each their own bus again. One per port. There's no switch here, bus 0 ( / 30 / 60)is "in" the CPU, each port is it's own bus.
The more interesting thing is the PCI domain, the first 4 digits:
0000:60:00.0 PCI bridge: CIX Technology Group Co., Ltd. CIX P1 CD8180 PCI Express Root Port
0000:61:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8126 5GbE Controller
0001:30:00.0 PCI bridge: CIX Technology Group Co., Ltd. CIX P1 CD8180 PCI Express Root Port
0001:31:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8126 5GbE Controller
0002:00:00.0 PCI bridge: CIX Technology Group Co., Ltd. CIX P1 CD8180 PCI Express Root Port
0002:01:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8852BE PCIe 802.11ax Wireless Network Controller
Doesn't have to, though; it might be due to some technicality, driver bug, misunderstanding, whatever else.
I've still been on the hunt for a cheap Arm board with a Armv8.3+ or Arvm9.0+ SoC for OSDev stuff, but it's hard to find them in hobbyist price range (this board included, $700-900 USD from what I see).
The NVIDIA Jetson Orin Nanos looked good but unfortunately SWD/JTAG is disabled unless you pay for the $2k model...
Yep, I'll pass. I'm done dealing with that kind of crap that is spread like a nasty STD through the ARM world. I'm sticking with x64 unless/until ARM gets this crap together.
But at a certain point I guess it just breaks? And they need an objective "I gave these tokens, I got out those tokens". But I guess that would need an objective gold standard ground truth that's maybe hard to come by.
Is this a thing? I read an article about how due to some implementation detail of GPUs, you don't actually get deterministic outputs even with temp 0.
But I don't understand that, and haven't experimented with it myself.
The main difference comes from rounding order of reduction difference.
It does make a small difference. Unless you have an unstable floating point algorithm, but if you have an unstable floating point algorithm on a GPU at low precision you were doomed from the start.
I couldn't imagine recommending any of these boards to people who aren't already SBC tinkerers.
There are some perplexity comparison numbers for the previous gen - Orange pi 5 in link below.
Bit of a mixed bag, but doesn't seem catastrophic across the board. Some models are showing minimal perplexity loss at Q8...
https://github.com/invisiofficial/rk-llama.cpp/blob/rknpu2/g...
If you're in the business of selling unbundled edge accelerators, you're strongly incentivized to modularize your NPU software stack for arbitrary hosts, which increases the likelihood that it actually works, and for more than one particular kernel.
If I had an embedded AI use case, this is something I'd look at hard.
This is an honest, neutral question, and it's specifically about what can concretely be done with them right now. Their theoretical use is clear to me. I'm explicitly asking only about their practical use, in the present time.
(One of the reasons I am asking is I am wondering if this is a classic case of the hardware running too far ahead of the actual needs and the result is hardware that badly mismatches the actual needs, e.g., an "NPU" that blazingly accelerates a 100 million parameter model because that was "large" when someone wrote the specs down, but is uselessly small in practice. Sometimes this sort of thing happens. However I'm still honestly interested just in what can be done with them right now.)
Massively simplified, 2.5G is 1G sped up while 5G is 10G slowed down. It makes no sense and the market agrees. The ladder of popularity goes:
1000base-T, <long break>, 10Gbase-T, 2.5Gbase-T, <long break>, 5Gbase-T. (Depends on context ofc, 2.5G is quite popular on APs for example.)
And note a lot of 10Gbase-T hardware is not Nbase-T compatible, and there are chips that do only 1G, 2.5G and 10G - no 5G.
I guess if your design doesn't work at 10GbT you try with 5? Ugh.