4 ms·

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 S

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/
- MrHamburger 2y ago
  > The OS receives the devicetree in a memory location Which memory location? Any ARM SoC does not have defined where RAM must be. So which address are you going to touch from your OS to get the configuration? Yep, that's exactly what UEFI and ACPI are for And no "at the end of kernel image" is not a memory location, because then your solution works only with your specific ad-hoc setup. All the Linux distros are not working, BSD is not working, Windows is not working. Only your blessed Linux Kernel will work and that's going to be all. No difference from adding a device tree directly into a Kernel then.
  - 201984 2y ago
    > Which memory location? The location of the device tree is given to the kernel in x0 by the boot loader. See https://docs.kernel.org/arch/arm64/booting.html https://docs.kernel.org/arch/arm64/booting.html. This device tree has information about the RAM location and hardware on the device, so in theory this can work just as well as ACPI does.
    - MrHamburger 2y ago
      Which will work only for a Linux, everything else won't boot on your ad-hoc solution.
      - M95D 2y ago
        A quick Google shows that BSD supports devicetree too. So that leaves... Windows? Don't tell me you're a Windows fan?? That would explain why you love ring -2 binary blobs too.
  - M95D 2y ago
    > Which memory location? > And no "at the end of kernel image" is not a memory location Like @201984 said, u-boot can load the devicetree separately and this is the more common way to boot. But even if it didn't, "the end of the kernel image" actually is a memory location. Kernel knows where it's executing from (all CPUs, not just ARM, have the Program Counter register) and it's own size (kernel decompressor knows the end of the compressed data). > Any ARM SoC does not have defined where RAM must be. That's known from the devicetree. > All the Linux distros are not working, BSD is not working, Windows is not working. False. You can take Ubuntu as example. There's only one bootable image for all ARM64. I have no experience with BSD and who tf. cares about Windows?

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/

MrHamburger 2y ago
> The OS receives the devicetree in a memory location Which memory location? Any ARM SoC does not have defined where RAM must be. So which address are you going to touch from your OS to get the configuration? Yep, that's exactly what UEFI and ACPI are for And no "at the end of kernel image" is not a memory location, because then your solution works only with your specific ad-hoc setup. All the Linux distros are not working, BSD is not working, Windows is not working. Only your blessed Linux Kernel will work and that's going to be all. No difference from adding a device tree directly into a Kernel then.
- 201984 2y ago
  > Which memory location? The location of the device tree is given to the kernel in x0 by the boot loader. See https://docs.kernel.org/arch/arm64/booting.html https://docs.kernel.org/arch/arm64/booting.html. This device tree has information about the RAM location and hardware on the device, so in theory this can work just as well as ACPI does.
  - MrHamburger 2y ago
    Which will work only for a Linux, everything else won't boot on your ad-hoc solution.
    - M95D 2y ago
      A quick Google shows that BSD supports devicetree too. So that leaves... Windows? Don't tell me you're a Windows fan?? That would explain why you love ring -2 binary blobs too.
- M95D 2y ago
  > Which memory location? > And no "at the end of kernel image" is not a memory location Like @201984 said, u-boot can load the devicetree separately and this is the more common way to boot. But even if it didn't, "the end of the kernel image" actually is a memory location. Kernel knows where it's executing from (all CPUs, not just ARM, have the Program Counter register) and it's own size (kernel decompressor knows the end of the compressed data). > Any ARM SoC does not have defined where RAM must be. That's known from the devicetree. > All the Linux distros are not working, BSD is not working, Windows is not working. False. You can take Ubuntu as example. There's only one bootable image for all ARM64. I have no experience with BSD and who tf. cares about Windows?