3 ms·

Microsoft forced a lot of uniformity on x86 designs, with standard methods of probing to find all of the buses and devices, while historically ARM devices where

by not2b 2y ago

Microsoft forced a lot of uniformity on x86 designs, with standard methods of probing to find all of the buses and devices, while historically ARM devices where embedded and the architecture was arbitrary, which was why you needed device trees. The kernel couldn't figure out the device configuration on its own.

bubblesnort 2y ago
The BIOS on an IBM PC was cloned by Compaq iirc. Back in the day it was normal for software (including OS kernels) to call into BIOS ROMs because storage was limited. This was in a different era where most PCs weren't networked. x86_64 has moved to UEFI and SecureBoot since, but is still mostly expected to boot any live distro you'd like. Replacing x86 could drastically reduce the chances of replacing non-free vendor software with free software.
- kmeisthax 2y ago
  And to add onto this: pre-ACPI, the IBM PC platform wasn't that far off from, say, any one particular SoC vendor in the ARM ecosystem. In fact, Microsoft originally planned to license out MS-DOS to competing x86 computer vendors using incompatible platforms and firmware[0]. Which is close[1] to the state of non-UEFI/non-PSCI ARM now. It's only because Compaq was able to legally clone the PC and it's BIOS that x86 standardized itself on one platform and firmware. The presence or lack thereof of standardized interfaces for firmware, device configuration, or the underlying platform are orthogonal to issues regarding Secure Boot and trust management. Apple Silicon Macs use nonstandard boot firmware (iBoot) but booting a "fully untrusted OS" (or fuOS) is an explicitly supported[2] use case on them, gated only by the user needing to boot recoveryOS (OTR specifically) once and enter their password to sign the alternative kernel. They even support per-volume boot policies, so you can keep your macOS install fully locked down while your Asahi Linux does whatever you want. And likewise Intel isn't stopping you from building in whatever user-hostile nonsense you want into x86 firmware. There's actually a whole range of laptops that have BIOS rootkits preinstalled, specifically to force-install Computrace onto whatever Windows install gets booted for corporate IT management purposes. The thing is, corporate IT has a terrible habit of leaving this shit on laptops they've sold", either because the laptop was stolen internally or because IT couldn't give a shit to do the computer equivalent of signing the title, so people wind up buying laptops that will lock up and wipe themselves if you ever install Windows on them. [0] The most successful of these being the PC-98, which lasted all the way up until the Windows 9x era [1] ARM SoC vendors additionally commit the crime of not being compatible with themselves. It is common for new SoCs to have completely different memory and device layouts. Apple is the only exception, ironically because they make both the OS and the SoC, which is the one time where such crimes would be excusable. [2] I'm told Apple's original intent was Boot Camp with Windows on ARM, but Microsoft wouldn't license Windows on ARM on Macs because they have an exclusivity deal with Qualcomm.
  - rbanffy 2y ago
    > so people wind up buying laptops that will lock up and wipe themselves if you ever install Windows on them. This is a feature rather than a bug ;-) They could just refuse to install Windows. It'd be more polite.
M95D 2y ago
But Microsoft didn't do that. Hardware industry did: ISA PnP, PCI, USB. Those are all hardware standards. ARM devices are embedded in the SoC. That's basically the definition of a SoC. Intel & co. at that time didn't produce SoCs. A CPU was just a CPU. It didn't have UARTs, GPU, SDHCI, I2c, SPI and other stuff in it. The only thing x86 (basically Intel, not Microsoft) did good was to standardize I/O addresses like framebuffer, IDE ports, serial I/O and later to make the rest discoverable via ACPI standard (which is a bad standard, btw, and UEFI is far worse). You may view ACPI as the x86 devicetree. The only difference is that x86 comes with ACPI written in a chip, while ARM firmware is a separate file you add into your bootable image next to the kernel, without the need for a separate EEPROM chip. You shouldn't be complaining about the ARM device descovery (devicetree), but about the absolute jungle of devices that ARM includes. Just think how many different USB controllers are out there. Each manufacturer designed it's own controller and every ARM chip needs a different driver. On x86 there are/were only 2: Intel (UHCI) and AMD (OHCI), and then they cooperated and made universal EHCI and xHCI.

by not2b 2y ago

bubblesnort 2y ago

The BIOS on an IBM PC was cloned by Compaq iirc. Back in the day it was normal for software (including OS kernels) to call into BIOS ROMs because storage was limited. This was in a different era where most PCs weren't networked. x86_64 has moved to UEFI and SecureBoot since, but is still mostly expected to boot any live distro you'd like. Replacing x86 could drastically reduce the chances of replacing non-free vendor software with free software.

kmeisthax 2y ago
And to add onto this: pre-ACPI, the IBM PC platform wasn't that far off from, say, any one particular SoC vendor in the ARM ecosystem. In fact, Microsoft originally planned to license out MS-DOS to competing x86 computer vendors using incompatible platforms and firmware[0]. Which is close[1] to the state of non-UEFI/non-PSCI ARM now. It's only because Compaq was able to legally clone the PC and it's BIOS that x86 standardized itself on one platform and firmware. The presence or lack thereof of standardized interfaces for firmware, device configuration, or the underlying platform are orthogonal to issues regarding Secure Boot and trust management. Apple Silicon Macs use nonstandard boot firmware (iBoot) but booting a "fully untrusted OS" (or fuOS) is an explicitly supported[2] use case on them, gated only by the user needing to boot recoveryOS (OTR specifically) once and enter their password to sign the alternative kernel. They even support per-volume boot policies, so you can keep your macOS install fully locked down while your Asahi Linux does whatever you want. And likewise Intel isn't stopping you from building in whatever user-hostile nonsense you want into x86 firmware. There's actually a whole range of laptops that have BIOS rootkits preinstalled, specifically to force-install Computrace onto whatever Windows install gets booted for corporate IT management purposes. The thing is, corporate IT has a terrible habit of leaving this shit on laptops they've sold", either because the laptop was stolen internally or because IT couldn't give a shit to do the computer equivalent of signing the title, so people wind up buying laptops that will lock up and wipe themselves if you ever install Windows on them. [0] The most successful of these being the PC-98, which lasted all the way up until the Windows 9x era [1] ARM SoC vendors additionally commit the crime of not being compatible with themselves. It is common for new SoCs to have completely different memory and device layouts. Apple is the only exception, ironically because they make both the OS and the SoC, which is the one time where such crimes would be excusable. [2] I'm told Apple's original intent was Boot Camp with Windows on ARM, but Microsoft wouldn't license Windows on ARM on Macs because they have an exclusivity deal with Qualcomm.
- rbanffy 2y ago
  > so people wind up buying laptops that will lock up and wipe themselves if you ever install Windows on them. This is a feature rather than a bug ;-) They could just refuse to install Windows. It'd be more polite.

M95D 2y ago

But Microsoft didn't do that. Hardware industry did: ISA PnP, PCI, USB. Those are all hardware standards. ARM devices are embedded in the SoC. That's basically the definition of a SoC. Intel & co. at that time didn't produce SoCs. A CPU was just a CPU. It didn't have UARTs, GPU, SDHCI, I2c, SPI and other stuff in it. The only thing x86 (basically Intel, not Microsoft) did good was to standardize I/O addresses like framebuffer, IDE ports, serial I/O and later to make the rest discoverable via ACPI standard (which is a bad standard, btw, and UEFI is far worse). You may view ACPI as the x86 devicetree. The only difference is that x86 comes with ACPI written in a chip, while ARM firmware is a separate file you add into your bootable image next to the kernel, without the need for a separate EEPROM chip. You shouldn't be complaining about the ARM device descovery (devicetree), but about the absolute jungle of devices that ARM includes. Just think how many different USB controllers are out there. Each manufacturer designed it's own controller and every ARM chip needs a different driver. On x86 there are/were only 2: Intel (UHCI) and AMD (OHCI), and then they cooperated and made universal EHCI and xHCI.