The problem isn't with the hardware compatibility for the external components, but with software compatibility for the internal components. "Adhering to x86 st

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!