I want to be able to buy ARM boards like I'm buying ITX PC boards. I don't want a special build of Linux from the SBC OEM, I don't want weird bootloaders, firmware and other embedded-like stuff. I just want an ARM-based PC board for my desktop and server closet (so Ampere stuff is out of the picture unfortunately).
It seems they've been stopping short of completion. Once the next gen chip is released, they are done and stop working on fixing issues.
Hopefully, with some time this gets better as it's not like they have to start from scratch with each generation. But it does leave a sour taste in my mouth that they quit so early before finishing.
I bought a Radxa Cubie A7A over the weekend because my homelab machine of 5 months threw an SSD and I wanted something to limp along with while I wait for a replacement. I was a bit nervous about the special builds, driver issues, etc but didn't really run into any significant issues (or if I did, Claude took them in stride). And it was a very good test of the Ansible Playbook I'd thrown together over time to rebuild the system from scratch. Was missing a number of small things, but it should be rock solid by the time (if) the other company gets a new drive to me.
I’m baffled by the current state of Linux for ARM where every board needs a special .dtb/.dts to describe its hardware and, often, peripherals, rather than there being some kind of self-describing plug-and-play-ish system like has been standard on other mainstream architectures since the ’90s.
That's what the Arm SystemReady certification is for. Blame manufacturers for ignoring it. Let's be honest, fixing device trees is usually lot easier than patching an ACPI table. Though, one manufacturer I know ships a DT with nearly 500k lines of if-def'd nodes.
I hope Linux support for these chips matures quickly. Qualcomm's laptop chips are the only serious competitor to Apple's M-series in single core performance and power efficiency. Intel and AMD are both far behind.
I hope not just Linux support for these chips matures - but that the rest of the fabless chip vendors get a leg up as well, because .. The world needs non-Apple/-Qualcomm variants of this hardware architecture, imho.
I have been tinkering with the Windows Dev Kit 2023 which shares the same SoC as this board. Linux support has been improving but with only third party kernel patches. GPU support has been okay but I have noticed oddities at higher resolutions. Speaking of, none of the display port options could provide 4K at 120Hz so maybe this is one area that the Q8B can prove to be more capable; it is supposed to have an HDMI 2.1 port and two DP 1.4 capable usb-c ports.
What would it cost to fund swe and design professionals to write a 9front port with a haiku skinjob to hit milestones at 9, 18, 27 month intervals? the incubation period for Macintosh, NeXTSTEP, BeOS, HarmonyOS Next would have estimates.
> What would it cost to fund swe and design professionals to write a 9front port with a haiku skinjob ...
Patches welcome. The community is very small and most everyone involved has jobs. There is also a tendency to only support the most common *useful* hardware instead of Raspberry Pi clone du jor.
As for a haiju skin job, see lola, a new window manager: https://shithub.us/aap/lola/HEAD/info.html I think it has a BeOS theme, if not, likely an easy patch because the dev designed it to be very hackable vs rio.
> ... to hit milestones at 9, 18, 27 month intervals? the incubation period for Macintosh, NeXTSTEP, BeOS, HarmonyOS Next would have estimates.
Not sure what any of this means. 9front is a rolling fork. People submit patches and if useful, are applied. sysupdate(8) is a small script that binds the 9front git repo over root and then runs git/pull. Then you run 'mk install' in /sys/src.
As someone trying to port 9front onto a similar board, I can tell you firsthand that it is not trivial (I actually did that because it was “simpler” than porting Haiku, but then the Haiku folk point blank refused to have anything to do with the precursor build scripts because the README had emoji and I do use Codex, and… it’s a very long story… I decided to not waste tokens on Luddites)
But I will get 9front going, it’s already loading the kernel.
(Ironically, I came here to comment that the review is completely unreadable with the amount of ad inserts - almost one per paragraph!)
If I could find a 6GB Q6A in stock (or Radxa eMMC, or fan-powered case, or most Radxa products in general) I would celebrate this announcement but they seem to be in small batch mode right now.
It says that it has four 10 Gb/s USB ports (2 Type A and 2 Type C).
It is unknown whether the ports are independent, or some of them or all of them are connected to an internal hub.
Even if they were connected to a single CPU port through an internal hub, if you used two 5 Gb/s USB Ethernet interfaces you would get close to full speed for them.
Having 10 Gb/s USB instead of the so-called "5 Gb/s" USB (in reality 4 Gb/s), provides much more additional I/O throughput than having 5 Gb/s RJ45 instead of 2.5 Gb/s. I agree that having 5 Gb/s Ethernet would have been nice, but it is much more valuable that it has 10 Gb/s USB, which is very rarely encountered on Arm-based computers.
Unfortunately, USB does not work like Firewire, where this was possible.
USB 4, i.e. Thunderbolt, allows the emulation of network interfaces if you interconnect the USB Type C ports with a cable, but here you have USB 3, so this does not work.
On USB 3 you could interconnect 2 ports only if one of them implemented the On-the-Go specification, so it could work as either a peripheral port or a host port. Here this also does not work. On a system where this had been allowed by the hardware, it is likely that you would have needed to write yourself a device driver that emulates a network interface, because I am not aware of an already existing one, unlike for USB 4.
USB 4 includes more than Thunderbolt, because Thunderbolt was not compatible with USB, despite using the same connector.
All features of Thunderbolt 3 have been inherited by USB 4, like also all those of USB 3, including the ability of Thunderbolt to emulate Ethernet interfaces when you interconnect 2 computers with a cable through their USB 4 ports, like it was already possible with Thunderbolt ports.
10 Gb/s Ethernet interfaces work fine on 10 Gb/s USB.
Both interfaces have almost the same raw bit rate (in both cases "10 Gb/s" is only an approximation, but the differences between the true bit rates and 10 Gb/s are negligible, unlike for "5 Gb/s" USB, where the data bit rate is only 4 Gb/s).
The USB protocol has a slightly higher overhead than the Ethernet protocol, so the throughput of an Ethernet 10 Gb/s interface attached on 10 Gb/s USB will be a little lower than that of a PCIe NIC, but the difference is negligible, of only a few percent.
This exactly the missing laptop/lowend desktop performance bracket missing in the ARM ecosystem. Make a Mini-ITX compatible board for the SoC, upstream drivers into mainline Linux (and *BSD), and people will buy it as the low power 24/7 board for the home. Is it so fucking hard not shoot yourself in both feet?
I want to be able to buy ARM boards like I'm buying ITX PC boards. I don't want a special build of Linux from the SBC OEM, I don't want weird bootloaders, firmware and other embedded-like stuff. I just want an ARM-based PC board for my desktop and server closet (so Ampere stuff is out of the picture unfortunately).
Qualcomm has been upstreaming kernel support for their chips recently, so I'm hopeful.
It seems they've been stopping short of completion. Once the next gen chip is released, they are done and stop working on fixing issues.
Hopefully, with some time this gets better as it's not like they have to start from scratch with each generation. But it does leave a sour taste in my mouth that they quit so early before finishing.
Yeah, I want edk2 uefi and mainline linux support at least for most functions (dont care about npu for example)
Why would you ask for a pony and then only want half? Let's get mainline support for all functions, like the NPU.
Having a (somewhat) usable mainline linux sbc would already be a big improvement over the status quo
The O6 runs mainline pretty good, only hiccups I know of are gpu acceleration and the npu.
preach. and i want this to extend to phones too.
I bought a Radxa Cubie A7A over the weekend because my homelab machine of 5 months threw an SSD and I wanted something to limp along with while I wait for a replacement. I was a bit nervous about the special builds, driver issues, etc but didn't really run into any significant issues (or if I did, Claude took them in stride). And it was a very good test of the Ansible Playbook I'd thrown together over time to rebuild the system from scratch. Was missing a number of small things, but it should be rock solid by the time (if) the other company gets a new drive to me.
asrockrack has some ampere boards, in CEB and MicroATX iirc
Well, just the motherboard seems to be over 1200€ so it’s not really in the same league… https://smicro.eu/asrock-altrad8ud-1l2t-1?srsltid=AfmBOoqWFe...
I’m baffled by the current state of Linux for ARM where every board needs a special .dtb/.dts to describe its hardware and, often, peripherals, rather than there being some kind of self-describing plug-and-play-ish system like has been standard on other mainstream architectures since the ’90s.
That's what the Arm SystemReady certification is for. Blame manufacturers for ignoring it. Let's be honest, fixing device trees is usually lot easier than patching an ACPI table. Though, one manufacturer I know ships a DT with nearly 500k lines of if-def'd nodes.
I hope Linux support for these chips matures quickly. Qualcomm's laptop chips are the only serious competitor to Apple's M-series in single core performance and power efficiency. Intel and AMD are both far behind.
Yes! But these are rebadged 5 year old chips.
I hope not just Linux support for these chips matures - but that the rest of the fabless chip vendors get a leg up as well, because .. The world needs non-Apple/-Qualcomm variants of this hardware architecture, imho.
Pretty darn quick.
8cx Gen 3? That's the same SOC in the Thinkpad 13s we've had in a bit, so pretty promising.
I have been tinkering with the Windows Dev Kit 2023 which shares the same SoC as this board. Linux support has been improving but with only third party kernel patches. GPU support has been okay but I have noticed oddities at higher resolutions. Speaking of, none of the display port options could provide 4K at 120Hz so maybe this is one area that the Q8B can prove to be more capable; it is supposed to have an HDMI 2.1 port and two DP 1.4 capable usb-c ports.
A lot of these higher-end sbc have been out-of-stock for a while now, I've been trying to find an o6 since a few months.
What would it cost to fund swe and design professionals to write a 9front port with a haiku skinjob to hit milestones at 9, 18, 27 month intervals? the incubation period for Macintosh, NeXTSTEP, BeOS, HarmonyOS Next would have estimates.
> What would it cost to fund swe and design professionals to write a 9front port with a haiku skinjob ...
Patches welcome. The community is very small and most everyone involved has jobs. There is also a tendency to only support the most common *useful* hardware instead of Raspberry Pi clone du jor.
As for a haiju skin job, see lola, a new window manager: https://shithub.us/aap/lola/HEAD/info.html I think it has a BeOS theme, if not, likely an easy patch because the dev designed it to be very hackable vs rio.
> ... to hit milestones at 9, 18, 27 month intervals? the incubation period for Macintosh, NeXTSTEP, BeOS, HarmonyOS Next would have estimates.
Not sure what any of this means. 9front is a rolling fork. People submit patches and if useful, are applied. sysupdate(8) is a small script that binds the 9front git repo over root and then runs git/pull. Then you run 'mk install' in /sys/src.
As someone trying to port 9front onto a similar board, I can tell you firsthand that it is not trivial (I actually did that because it was “simpler” than porting Haiku, but then the Haiku folk point blank refused to have anything to do with the precursor build scripts because the README had emoji and I do use Codex, and… it’s a very long story… I decided to not waste tokens on Luddites)
But I will get 9front going, it’s already loading the kernel.
(Ironically, I came here to comment that the review is completely unreadable with the amount of ad inserts - almost one per paragraph!)
If I could find a 6GB Q6A in stock (or Radxa eMMC, or fan-powered case, or most Radxa products in general) I would celebrate this announcement but they seem to be in small batch mode right now.
Yeah, qualcomm. No open datasheets/soc user manuals, no thanks.
This is a one beautiful SBC.
Apparently we might be able to run OpenBSD on it [0]
FreeBSD is unclear [1]
- [0] https://www.openbsd.org/arm64.html
- [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=267292
Glancing at these benchmarks, isn't the first RVA23 SoC, the spacemiT K3, faster?
I just wish they had 2x5GbE like the Orion O6. i/o heavily matters for my compute nodes.
I wonder if 802.3ad bonding can bring 5gbit/s
Seems like you could add that pretty easily via USB and/or M.2. Either should have the necessary bandwidth.
I would use the m.2 e keys for sata and x4 m key for nvme ssds. That only leaves pcie gen3 x2.
I want to run a distributed network storage (ceph)
It says that it has four 10 Gb/s USB ports (2 Type A and 2 Type C).
It is unknown whether the ports are independent, or some of them or all of them are connected to an internal hub.
Even if they were connected to a single CPU port through an internal hub, if you used two 5 Gb/s USB Ethernet interfaces you would get close to full speed for them.
Having 10 Gb/s USB instead of the so-called "5 Gb/s" USB (in reality 4 Gb/s), provides much more additional I/O throughput than having 5 Gb/s RJ45 instead of 2.5 Gb/s. I agree that having 5 Gb/s Ethernet would have been nice, but it is much more valuable that it has 10 Gb/s USB, which is very rarely encountered on Arm-based computers.
They’re independent
I wonder how well a usb 10gbit ethernet adapter would work then
But I really apprecate your reply!
I'll definitely buy one for testing when they become available for reasonable prices <500EUR for 16gig memory
Hmm, is it possible to skip the Ethernet adapters in a configuration of USBC-Eth-Eth-USBC and connect USBCs directly one to another?
Unfortunately, USB does not work like Firewire, where this was possible.
USB 4, i.e. Thunderbolt, allows the emulation of network interfaces if you interconnect the USB Type C ports with a cable, but here you have USB 3, so this does not work.
On USB 3 you could interconnect 2 ports only if one of them implemented the On-the-Go specification, so it could work as either a peripheral port or a host port. Here this also does not work. On a system where this had been allowed by the hardware, it is likely that you would have needed to write yourself a device driver that emulates a network interface, because I am not aware of an already existing one, unlike for USB 4.
> USB 4, i.e. Thunderbolt
USB4 and TB are different things (confusingly enough)
USB 4 includes more than Thunderbolt, because Thunderbolt was not compatible with USB, despite using the same connector.
All features of Thunderbolt 3 have been inherited by USB 4, like also all those of USB 3, including the ability of Thunderbolt to emulate Ethernet interfaces when you interconnect 2 computers with a cable through their USB 4 ports, like it was already possible with Thunderbolt ports.
How could I forget about the staggering complexity of USB versions! Of course the answer is “maybe”.
10 Gb/s Ethernet interfaces work fine on 10 Gb/s USB.
Both interfaces have almost the same raw bit rate (in both cases "10 Gb/s" is only an approximation, but the differences between the true bit rates and 10 Gb/s are negligible, unlike for "5 Gb/s" USB, where the data bit rate is only 4 Gb/s).
The USB protocol has a slightly higher overhead than the Ethernet protocol, so the throughput of an Ethernet 10 Gb/s interface attached on 10 Gb/s USB will be a little lower than that of a PCIe NIC, but the difference is negligible, of only a few percent.
RTL8159 10GbE usb adapters seem to require USB3.2 Gen2 x2 and this seems to only have gen2
This exactly the missing laptop/lowend desktop performance bracket missing in the ARM ecosystem. Make a Mini-ITX compatible board for the SoC, upstream drivers into mainline Linux (and *BSD), and people will buy it as the low power 24/7 board for the home. Is it so fucking hard not shoot yourself in both feet?