3 ms·

I've also been interested in a different kind of "PC-compatible non-x86", as in building a standardized architecture with all the normal pieces and just swappin

I've also been interested in a different kind of "PC-compatible non-x86", as in building a standardized architecture with all the normal pieces and just swapping out the CPU. It is 100% possible to make a machine with an arch64 CPU that boots using UEFI, handles device enumeration like a PC, has the usual buses and everything, lives in an ATX case, and in every way it looks and acts like a regular PC that just happens to have a different CPU.

derefr 3y ago
I think the x86 "standardized architecture" is an example of Conway's law: it's a natural outgrowth of the way the x86 hardware ecosystem evolved, with CPU, motherboard, and "card" manufacturers all being different companies that need formal standards to enable post-production integration (first by dedicated system builders setting DIP switches; then later at runtime with "plug and play"); and with each party being incentivized to swap out partners / "commoditize their complement", and therefore wanting constrained standards that ensure that they can design/code once to the standard's spec, and then switch suppliers without re-work. Other architectures that came into existence more recently — ARM mainly, but possibly RISC-V is going this way as well — are mainly employed to produce integrated devices in a more supply-chain-oriented way, with vendors producing and licensing designs for "IP cores", and then device integrators combining these "IP cores" to fab SoCs. Conway's Law (and game theory) predict that such an arrangement would have no need for API standards. It's pretty hard to force an ecosystem to do something, when they have no natural incentive to do it.
- AnthonyMouse 3y ago
  > It's pretty hard to force an ecosystem to do something, when they have no natural incentive to do it. You don't need an ecosystem to do it, you only need one manufacturer, because the competing ecosystem already exists. Suppose someone produced an ARM or RISC-V system board in an ATX form factor with BIOS or UEFI and standard PCIe and memory slots etc. That's all you need -- then you use the same chassis, power supply, memory, expansion cards, etc. as any commodity PC without having to establish a new ecosystem for any of those things.
  - derefr 3y ago
    The problem isn't with the hardware compatibility for the external components, but with software compatibility for the internal components. "Adhering to x86 standards", would imply that the software of such a device, must be able to do unified management of hardware components — both external and internal — through x86 facilities like ACPI. As, even if you've got a system built out of (some) x86-compatible components, if you can't make use of software — like drivers and OS subsystems — designed to assume the x86 system architecture on it, then what's the point? So, for example, the SoC's GPU IP-core. Until about eight years ago, SoC-internal GPUs were just something directly memory- and IO-mapped at addresses hardcoded into proprietary device-specific drivers given by the IO-core developer to be (arbitrarily modified and then) compiled by the integrator. And even today, with DeviceTree, the DeviceTree descriptor for each of these devices is still something handed over out-of-band along with the core, and burned into the device's NVRAM or OS base-image by the integrator. But now, in getting that same GPU to support "the x86 system-level architecture", the GPU would instead have to be "registered" somewhere inside the SoC in order for the SoC CPU to probe and discover it as a PCIe device — with an ACPI DDST available within a UEFI-discoverble boot-ROM address mapping, that can be used to power-manage it correctly (including complex things like the CPU being able to put the GPU or its individual cores into particular sleep-states through ACPI); with a PCIe HW device ID, that binds it to generic drivers when available, rather than allowing for device-specific driver customization; etc. And all of the ensuing device initialization that the driver does, would have to occur through ACPI and PCIe. Even though the core is internal to the SoC! Support for complex ACPI hooks, and a driver impl that's flexible enough to be runitme-configured to serve various devices' needs without integration-time customization (so that it can be upstreamed into OSes), are both things that the IP-core vendor would have to implement. Currently, they are not implementing those things — and mostly wouldn't even know how. Being an IP core vendor — where you're running a job-shop producing designs to spec for specific downstream integration projects — isn't at-all the same job as being a peripheral card vendor in an ecosystem, where you actually have to deal with all these concerns. The IP-core vendors would have to learn how to do these things. And if you don't do this — don't require this kind of software-visible x86-platform-ization for the internal IP-core hardware — then what you end up with is a hybrid system that needs its OS to manage both external PCie ACPI devices with generic drivers, and internal DeviceTree devices with device-specific drivers — potentially also virtualizing one as the other whenever needed (by e.g. making up PCIe device IDs for the DeviceTree devices). And not even Linux knows how to deal with that[0]. [0] If you're curious — https://docs.kernel.org/arch/arm64/arm-acpi.html#booting-using-acpi-tables https://docs.kernel.org/arch/arm64/arm-acpi.html#booting-usi.... As stated, ARM BSA/BBR devices are expected and required to use solely ACPI-registered device descriptions; such systems don't use DeviceTree at all. This severely restricts ARM SBA/BBR OEMs' choices of IP-core vendors, as those vendors, mostly know nothing about how to produce cores compliant with ACPI, nor drivers generic enough to be signed, sealed, and used in ACPI environments — let alone upstreamed. This is what I mean by "an ecosystem problem"! And it's precisely why consumer SBCs — that include all the nice-to-have features like a GPU — aren't already SBR compliant!
cpgxiii 3y ago
This is basically what the Arm SBSA does (UEFI + ACPI) and essentially how all arm64 (and arm32) devices that support Windows work. SBSA doesn't solve the dismal lack of drivers for hardware in consumer devices, though, so just because there are arm64 devices that can be booted with UEFI+ACPI doesn't mean they "just work" like we expect amd64 machines to.
- yjftsjthsd-h 3y ago
  Yeah, I was actually thinking of SystemReady when I wrote my comment, and I have some vague understanding that Microsoft is all-in on it because ex. even their phones used UEFI, which is kind of beautiful. So the pieces are there, but sadly not nearly-universal like with x86 PCs:\ Separately, I will grant that drivers are their own sticking point, but I would like for them to be approximately the only sticking point. And even on x86 drivers are a problem; Linux generally has good mainline coverage of most networking cards, even wifi is good these days, but fingerprint readers have always been hit-or-miss. I just wish we could get to the point where once the drivers are upstreamed everything does Just Work and we can be free of "well this distro has a Raspberry Pi image but if you want to try an Orange Pi you need to find an OS that supports that exact board..."

derefr 3y ago

I think the x86 "standardized architecture" is an example of Conway's law: it's a natural outgrowth of the way the x86 hardware ecosystem evolved, with CPU, motherboard, and "card" manufacturers all being different companies that need formal standards to enable post-production integration (first by dedicated system builders setting DIP switches; then later at runtime with "plug and play"); and with each party being incentivized to swap out partners / "commoditize their complement", and therefore wanting constrained standards that ensure that they can design/code once to the standard's spec, and then switch suppliers without re-work. Other architectures that came into existence more recently — ARM mainly, but possibly RISC-V is going this way as well — are mainly employed to produce integrated devices in a more supply-chain-oriented way, with vendors producing and licensing designs for "IP cores", and then device integrators combining these "IP cores" to fab SoCs. Conway's Law (and game theory) predict that such an arrangement would have no need for API standards. It's pretty hard to force an ecosystem to do something, when they have no natural incentive to do it.

AnthonyMouse 3y ago
> It's pretty hard to force an ecosystem to do something, when they have no natural incentive to do it. You don't need an ecosystem to do it, you only need one manufacturer, because the competing ecosystem already exists. Suppose someone produced an ARM or RISC-V system board in an ATX form factor with BIOS or UEFI and standard PCIe and memory slots etc. That's all you need -- then you use the same chassis, power supply, memory, expansion cards, etc. as any commodity PC without having to establish a new ecosystem for any of those things.
- derefr 3y ago
  The problem isn't with the hardware compatibility for the external components, but with software compatibility for the internal components. "Adhering to x86 standards", would imply that the software of such a device, must be able to do unified management of hardware components — both external and internal — through x86 facilities like ACPI. As, even if you've got a system built out of (some) x86-compatible components, if you can't make use of software — like drivers and OS subsystems — designed to assume the x86 system architecture on it, then what's the point? So, for example, the SoC's GPU IP-core. Until about eight years ago, SoC-internal GPUs were just something directly memory- and IO-mapped at addresses hardcoded into proprietary device-specific drivers given by the IO-core developer to be (arbitrarily modified and then) compiled by the integrator. And even today, with DeviceTree, the DeviceTree descriptor for each of these devices is still something handed over out-of-band along with the core, and burned into the device's NVRAM or OS base-image by the integrator. But now, in getting that same GPU to support "the x86 system-level architecture", the GPU would instead have to be "registered" somewhere inside the SoC in order for the SoC CPU to probe and discover it as a PCIe device — with an ACPI DDST available within a UEFI-discoverble boot-ROM address mapping, that can be used to power-manage it correctly (including complex things like the CPU being able to put the GPU or its individual cores into particular sleep-states through ACPI); with a PCIe HW device ID, that binds it to generic drivers when available, rather than allowing for device-specific driver customization; etc. And all of the ensuing device initialization that the driver does, would have to occur through ACPI and PCIe. Even though the core is internal to the SoC! Support for complex ACPI hooks, and a driver impl that's flexible enough to be runitme-configured to serve various devices' needs without integration-time customization (so that it can be upstreamed into OSes), are both things that the IP-core vendor would have to implement. Currently, they are not implementing those things — and mostly wouldn't even know how. Being an IP core vendor — where you're running a job-shop producing designs to spec for specific downstream integration projects — isn't at-all the same job as being a peripheral card vendor in an ecosystem, where you actually have to deal with all these concerns. The IP-core vendors would have to learn how to do these things. And if you don't do this — don't require this kind of software-visible x86-platform-ization for the internal IP-core hardware — then what you end up with is a hybrid system that needs its OS to manage both external PCie ACPI devices with generic drivers, and internal DeviceTree devices with device-specific drivers — potentially also virtualizing one as the other whenever needed (by e.g. making up PCIe device IDs for the DeviceTree devices). And not even Linux knows how to deal with that[0]. [0] If you're curious — https://docs.kernel.org/arch/arm64/arm-acpi.html#booting-using-acpi-tables https://docs.kernel.org/arch/arm64/arm-acpi.html#booting-usi.... As stated, ARM BSA/BBR devices are expected and required to use solely ACPI-registered device descriptions; such systems don't use DeviceTree at all. This severely restricts ARM SBA/BBR OEMs' choices of IP-core vendors, as those vendors, mostly know nothing about how to produce cores compliant with ACPI, nor drivers generic enough to be signed, sealed, and used in ACPI environments — let alone upstreamed. This is what I mean by "an ecosystem problem"! And it's precisely why consumer SBCs — that include all the nice-to-have features like a GPU — aren't already SBR compliant!

cpgxiii 3y ago

This is basically what the Arm SBSA does (UEFI + ACPI) and essentially how all arm64 (and arm32) devices that support Windows work. SBSA doesn't solve the dismal lack of drivers for hardware in consumer devices, though, so just because there are arm64 devices that can be booted with UEFI+ACPI doesn't mean they "just work" like we expect amd64 machines to.

yjftsjthsd-h 3y ago
Yeah, I was actually thinking of SystemReady when I wrote my comment, and I have some vague understanding that Microsoft is all-in on it because ex. even their phones used UEFI, which is kind of beautiful. So the pieces are there, but sadly not nearly-universal like with x86 PCs:\ Separately, I will grant that drivers are their own sticking point, but I would like for them to be approximately the only sticking point. And even on x86 drivers are a problem; Linux generally has good mainline coverage of most networking cards, even wifi is good these days, but fingerprint readers have always been hit-or-miss. I just wish we could get to the point where once the drivers are upstreamed everything does Just Work and we can be free of "well this distro has a Raspberry Pi image but if you want to try an Orange Pi you need to find an OS that supports that exact board..."