SolidRun MACCHIATObin ($349 with a useless 4GB DIMM included, $449 with a 16GB one, there’s a more expensive “Double Shot” version with more Ethernet ports and higher CPU clock.. out of the box, setting a jumper seems to achieve 2GHz on “Single Shot” just fine)
Supported in upstream TianoCore EDK2 + Arm TF-A. Firmware provided by your own build or mine, out of the box comes with U-Boot instead, can boot firmware from microSD or SPI flash or streamed over UART (for recovery).
PCIe controller does support ECAM, but has a bug. It doesn’t filter something about which device the packets are from (I forget the term) so some devices would appear as replicated into all slots (or just a couple slots). The upstream EDK2 workaround is the “ECAM offset” (making the OS only see the last device), but that’s bad because some devices (that use ARI (IIRC) or do their own filtering for some reason otherwise (modern Radeons)) don’t get duplicated, so a Radeon RX 480 would just be completely unseen with the offset, so it’s rolled back in my FW builds. But a Radeon HD 7950 did get duplicated into two slots. Had to patch the FreeBSD kernel to ignore the devices after the first one to test that card :)
There were plans to add setup toggles to upstream EDK2 for the offset, or to add a _HID that would let OSes use a quirk, but idk where that went.
Not the most attractive option now that the LX2160 is out there and with good firmware, you can get a 16-core instead of a 4-core.
and now some random fun stuff that we can’t get our hands on
Gigabyte MP30-AR1 (seems unobtainable by now, maybe keep monitoring ebay for years)
Huawei Kunpeng Desktop Board (not retail, only sold to businesses?)
Official website links to a “Get Pricing/Info” form with a “Budget” field where the smallest value is “less than $50,000”.
A non-standard protocol, Secure Launch, is used by Windows to be able to launch its hypervisor at EL2 on this platform. This protocol isn’t supported by Linux.
Huh, there is a way to run a hypervisor on Qualcomm’s weird firmware at all?! If someone reverse engineers this, would it eventually make KVM on Android phones possible? :D
It’s not the newest product around anymore, and its performance class today is in the same one as a much cheaper Raspberry Pi 4, although that has less I/O expansion.
Huh, there is a way to run a hypervisor on Qualcomm’s weird firmware at all?! If someone reverse engineers this, would it eventually make KVM on Android phones possible? :D
Yup, but remember the “Secure” part, good luck for the signature. (the thing is that Qualcomm has already their hypervisor there for DRM stuff, and so if you just give access to EL2 to anyone their DRM scheme is toast)
One objection could be that the standard shouldn’t be for U-Boot, but for something more generic. Of course, there are already standards for booting which aren’t specific to U-Boot. Cynically, I think it’s due to secure boot, for which EFI has a better story than U-Boot.
Device Tree is also not a real standard, but it’s instead “whatever Linux does”.
Technically, there is a devicetree specification, but for the rest (e.g. 95% of real device trees) it’s just “whatever Linux does.” FWIW Linux does have good support for doing some traditional things a specification might require (like providing a way to validate one’s device trees), but the semantics of bindings are much more fast-and-loose.
And it turns out that Apple uses device trees too, but an incompatible implementation that pre-dated Device Tree on Linux on Arm in the first place, for their own devices.
(same format set in stone from the iPhone in 2007 to the Apple Silicon Macs today)
Device Tree and FDT are also somewhat different. The only official specification for FDT is the ePAPR specification. I’m the author of the BSD-licensed dtc tool and almost all of the DTS files in the Linux tree now include extensions from the GPL’d dtc tool that are not part of the ePAPR standard. They are not always well documented so some reverse engineering is typically needed. Modern Linux / FreeBSD FDT includes a basic form of dynamic linking (‘overlays’), so you can refer to things in one blob from another. In traditional OpenFirmware FDTs, any of this was handled by Forth code in the expansion module.
SolidRun MACCHIATObin ($349 with a useless 4GB DIMM included, $449 with a 16GB one, there’s a more expensive “Double Shot” version with more Ethernet ports and higher CPU clock.. out of the box, setting a jumper seems to achieve 2GHz on “Single Shot” just fine)
Supported in upstream TianoCore EDK2 + Arm TF-A. Firmware provided by your own build or mine, out of the box comes with U-Boot instead, can boot firmware from microSD or SPI flash or streamed over UART (for recovery).
PCIe controller does support ECAM, but has a bug. It doesn’t filter something about which device the packets are from (I forget the term) so some devices would appear as replicated into all slots (or just a couple slots). The upstream EDK2 workaround is the “ECAM offset” (making the OS only see the last device), but that’s bad because some devices (that use ARI (IIRC) or do their own filtering for some reason otherwise (modern Radeons)) don’t get duplicated, so a Radeon RX 480 would just be completely unseen with the offset, so it’s rolled back in my FW builds. But a Radeon HD 7950 did get duplicated into two slots. Had to patch the FreeBSD kernel to ignore the devices after the first one to test that card :) There were plans to add setup toggles to upstream EDK2 for the offset, or to add a
_HIDthat would let OSes use a quirk, but idk where that went.Not the most attractive option now that the LX2160 is out there and with good firmware, you can get a 16-core instead of a 4-core.
and now some random fun stuff that we can’t get our hands on
Gigabyte MP30-AR1 (seems unobtainable by now, maybe keep monitoring ebay for years)
Ancient Applied Micro X-Gene 1. Proprietary AMI UEFI. See http://chezphil.org/rwanda/
Huawei Kunpeng Desktop Board (not retail, only sold to businesses?)
Official website links to a “Get Pricing/Info” form with a “Budget” field where the smallest value is “less than $50,000”.
Huh, there is a way to run a hypervisor on Qualcomm’s weird firmware at all?! If someone reverse engineers this, would it eventually make KVM on Android phones possible? :D
It’s not the newest product around anymore, and its performance class today is in the same one as a much cheaper Raspberry Pi 4, although that has less I/O expansion.
Yup, but remember the “Secure” part, good luck for the signature. (the thing is that Qualcomm has already their hypervisor there for DRM stuff, and so if you just give access to EL2 to anyone their DRM scheme is toast)
Why UEFI, and not (mainline) u-boot?
One objection could be that the standard shouldn’t be for U-Boot, but for something more generic. Of course, there are already standards for booting which aren’t specific to U-Boot. Cynically, I think it’s due to secure boot, for which EFI has a better story than U-Boot.
That’s much higher-level, and Linux-specific.
Linux isn’t the only OS that matters. (and this choice is not Secure Boot related)
UEFI is an actual standard instead of an implementation. Device Tree is also not a real standard, but it’s instead “whatever Linux does”.
UEFI + ACPI on Arm64 allows you to boot Windows, the BSDs…
Technically, there is a devicetree specification, but for the rest (e.g. 95% of real device trees) it’s just “whatever Linux does.” FWIW Linux does have good support for doing some traditional things a specification might require (like providing a way to validate one’s device trees), but the semantics of bindings are much more fast-and-loose.
And it turns out that Apple uses device trees too, but an incompatible implementation that pre-dated Device Tree on Linux on Arm in the first place, for their own devices.
(same format set in stone from the iPhone in 2007 to the Apple Silicon Macs today)
See what it looks like: https://gist.github.com/freedomtan/825993147700874119f590ecfdae97ed
Quite close isn’t it? But yet totally incompatible.
That’s not surprising, OS X had a quite strong dependency on OpenFirmware, where Device Trees originated.
Device Tree and FDT are also somewhat different. The only official specification for FDT is the ePAPR specification. I’m the author of the BSD-licensed
dtctool and almost all of the DTS files in the Linux tree now include extensions from the GPL’ddtctool that are not part of the ePAPR standard. They are not always well documented so some reverse engineering is typically needed. Modern Linux / FreeBSD FDT includes a basic form of dynamic linking (‘overlays’), so you can refer to things in one blob from another. In traditional OpenFirmware FDTs, any of this was handled by Forth code in the expansion module.