4 ms·

To disrupt any kind of x86 dominance ARM Motherboard manufacturers will first need to get their UEFI and ACPI support working first, otherwise their boards are

To disrupt any kind of x86 dominance ARM Motherboard manufacturers will first need to get their UEFI and ACPI support working first, otherwise their boards are nothing more than one-purpose toys running only a specific build of a system.

M95D 2y ago
But ACPI and UEFI won't solve anything. We already have devicetrees that are open and free vs. ACPI and UEFI that are just binary blobs. It would be even worse than Broadcom blobs on Raspberry Pi. What you probably want is less variability in SoC devices. Now each chip has a different SDHCI, different USB, different UART and different I2c, each needing a different driver. x86 only has 2: the Intel variant or the AMD variant.
- MrHamburger 2y ago
  Open and free devicetree is absolutely useless if it needs to be part of OS image. The purpose of ACPI and UEFI is to have single booting mechanism with standardized device enumeration which is available directly on the hardware. If you need to have a random file in your OS image to actually boot on board X and if you have a file for board Y then OS will just crash boot loop, then your solution is useless for 90%+ of users because people are not going to build their own Linux distributions for their own hardware. If you know what board are you booting on, then you can load correct hardware drivers for everything else. But that's not going to work without UEFI and ACPI.
  - M95D 2y ago
    And why does it have to be UEFI and ACPI? Just put u-boot and devicetree on an EEPROM - the same EEPROM/flash that would be needed for UEFI.
    - MrHamburger 2y ago
      Because it is a standard. Your proposed solution is ad-hoc which will work on your device(s), but nowhere else. Just make a mind experiment - Is flash memory SPI or parallel NAND? What if it is a Parallel NOR? Is EEPROM I2C? On which address? Which I2C controller should you use if there is more than one? Is EEPROM SPI? Which SPI controller you should use? How you should configure your SPI/I2C/Parallel controller? Which registers, on which addresses? On which GPIO pins is your memory device connected? You would still need some board specific mini device tree in your OS to resolve this issue. That's the reason why we have UEFI booting first and letting board manufacturer resolve it and then just providing a communication layer to make standardized queries without knowing all those questions above.
      - M95D 2y ago
        > Because it is a standard. UEFI isn't a standard (as ISO is, or even a RFC). It's actually a specification. If you call UEFI a standard, then DeviceTree would be a standard too [1]. > [...] letting board manufacturer resolve it and then just providing a communication layer to make standardized queries [...] Letting the board manufacturer resolve UEFI is the same as letting the board manufacturer resolve u-boot + devicetree instead. > Just make a mind experiment - Is flash memory SPI or parallel NAND? [...] That's not how u-boot works. U-boot is always manufacturer- and board-specific, just like UEFI/BIOS/ACPI. U-boot loads the devicetree into memory in a board-specific manner that the OS doesn't need to know/care about. The OS receives the devicetree in a memory location, usually just appended to the end of the kernel image. It doesn't read any SPI/NAND/I2c or any other device except memory, which is already initialized by u-boot. If uboot is in a EEPROM/flash onboard, then there is no need for the OS to include it, or any other board-specific data. The notable difference is that u-boot + devicetree would not allow the manufacturer to compromise a system after boot, like UEFI can, because the kernel overwrites the u-boot in memory, keeping only the provided devicetree, which doesn't contain any executable code. After kernel starts, u-boot can't execute again, unlike UEFI and ACPI which can even inject .DLLs into Windows (see Thinkpad's CompuTrace). Actually, the only "advantage" of UEFI is exactly this requirement for the OS to execute it while running. It's great for spyware and rootkits. [1] https://www.devicetree.org/specifications/ https://www.devicetree.org/specifications/

M95D 2y ago

But ACPI and UEFI won't solve anything. We already have devicetrees that are open and free vs. ACPI and UEFI that are just binary blobs. It would be even worse than Broadcom blobs on Raspberry Pi. What you probably want is less variability in SoC devices. Now each chip has a different SDHCI, different USB, different UART and different I2c, each needing a different driver. x86 only has 2: the Intel variant or the AMD variant.

MrHamburger 2y ago
Open and free devicetree is absolutely useless if it needs to be part of OS image. The purpose of ACPI and UEFI is to have single booting mechanism with standardized device enumeration which is available directly on the hardware. If you need to have a random file in your OS image to actually boot on board X and if you have a file for board Y then OS will just crash boot loop, then your solution is useless for 90%+ of users because people are not going to build their own Linux distributions for their own hardware. If you know what board are you booting on, then you can load correct hardware drivers for everything else. But that's not going to work without UEFI and ACPI.
- M95D 2y ago
  And why does it have to be UEFI and ACPI? Just put u-boot and devicetree on an EEPROM - the same EEPROM/flash that would be needed for UEFI.
  - MrHamburger 2y ago
    Because it is a standard. Your proposed solution is ad-hoc which will work on your device(s), but nowhere else. Just make a mind experiment - Is flash memory SPI or parallel NAND? What if it is a Parallel NOR? Is EEPROM I2C? On which address? Which I2C controller should you use if there is more than one? Is EEPROM SPI? Which SPI controller you should use? How you should configure your SPI/I2C/Parallel controller? Which registers, on which addresses? On which GPIO pins is your memory device connected? You would still need some board specific mini device tree in your OS to resolve this issue. That's the reason why we have UEFI booting first and letting board manufacturer resolve it and then just providing a communication layer to make standardized queries without knowing all those questions above.
    - M95D 2y ago
      > Because it is a standard. UEFI isn't a standard (as ISO is, or even a RFC). It's actually a specification. If you call UEFI a standard, then DeviceTree would be a standard too [1]. > [...] letting board manufacturer resolve it and then just providing a communication layer to make standardized queries [...] Letting the board manufacturer resolve UEFI is the same as letting the board manufacturer resolve u-boot + devicetree instead. > Just make a mind experiment - Is flash memory SPI or parallel NAND? [...] That's not how u-boot works. U-boot is always manufacturer- and board-specific, just like UEFI/BIOS/ACPI. U-boot loads the devicetree into memory in a board-specific manner that the OS doesn't need to know/care about. The OS receives the devicetree in a memory location, usually just appended to the end of the kernel image. It doesn't read any SPI/NAND/I2c or any other device except memory, which is already initialized by u-boot. If uboot is in a EEPROM/flash onboard, then there is no need for the OS to include it, or any other board-specific data. The notable difference is that u-boot + devicetree would not allow the manufacturer to compromise a system after boot, like UEFI can, because the kernel overwrites the u-boot in memory, keeping only the provided devicetree, which doesn't contain any executable code. After kernel starts, u-boot can't execute again, unlike UEFI and ACPI which can even inject .DLLs into Windows (see Thinkpad's CompuTrace). Actually, the only "advantage" of UEFI is exactly this requirement for the OS to execute it while running. It's great for spyware and rootkits. [1] https://www.devicetree.org/specifications/ https://www.devicetree.org/specifications/