5 ms·

> OpenFirmware was a much more elegant technology sitting around for the lifetime of modern x86 but intel had to be different. Let's rather look at the reasing

> OpenFirmware was a much more elegant technology sitting around for the lifetime of modern x86 but intel had to be different. Let's rather look at the reasing of the UEFI developers why they have a different opinion on Open Firmware (page 5 of http://www.uefi.org/sites/default/files/resources/A_Tale_of_Two_Standards_0.pdf http://www.uefi.org/sites/default/files/resources/A_Tale_of_...): "Another effort that is similar in its role to the PC/AT BIOS-based platform occurred with Open Firmware (OF) [4] and the Common Hardware Reference Platform (CHRP). CHRP was a set of common platform designs and hardware specifications meant to allow for interoperable designs among PowerPC (PowerPC) platform builders. Open Firmware, also known as IEEE-1275 [4], has issues in that it is an interpreted, stack-based byte-code. Very few programmers are facile in Forth programming, and it is renowned as being “write-once/understand-never”, and having poor performance, and non-standard tools. Also, Open Firmware has a device tree essentially duplicating ACPI static tables. As such, the lack of Forth programmers, prevalence of ACPI, and the fact that UEFI uses standard tools and works alongside ACPI — versus instead-of — helped spell Open Firmware’s lack of growth. In fact, it is used on SPARC and PowerPC, but it is unsuitable for high-volume machines and thus prevent it from making the leap from niche server & workstation markets."

wmf 9y ago
That's pretty revisionist considering that OF predates ACPI. Just like all other stories of path dependence, Intel backed themselves into a corner and now they're stuck there forever.
- wolfgke 9y ago
  > Just like all other stories of path dependence, Intel backed themselves into a corner and now they're stuck there forever. Beside the "well-known" implementations of UEFI for x86-32, IA-64 (Itanium) and X64-64, there also exist official UEFI implementations for ARM AArch32 and ARM AArch64. According to https://en.wikipedia.org/w/index.php?title=Unified_Extensible_Firmware_Interface&oldid=809635217#Processor_compatibility https://en.wikipedia.org/w/index.php?title=Unified_Extensibl... there also exist inofficial implementations for POWERPC64, MIPS and RISC-V. One consumer example where UEFI on ARM processors was used was the ARM-based Windows RT laptops (they were not very successful in the market). Much more importantly an UEFI implementation is required for ARM's "Server Base Boot Requirements (SBBR) - System Software on ARM® Platforms" standard: > http://infocenter.arm.com/help/topic/com.arm.doc.den0044b/DEN0044B_Server_Base_Boot_Requirements.pdf http://infocenter.arm.com/help/topic/com.arm.doc.den0044b/DE... (read section 3 and appendices A to D). So about every ARM server uses an UEFI firmware.
  - kev009 9y ago
    Going back to the intel FUD paper, if you consider volume shipment as success as in their document, uboot looking thing with FDTs are the most successful paradigm by orders of magnitude. The kind of systems using FDTs aren't going to switch I don't think. I have to imagine that ARM64 UEFI was done for marketing and by clueless product management. The CPUs and integration of ARM servers have been so pathetic, nobody was buying, and they were fumbling around at this level while ignoring the elephant in the room. TX2 and Centriq are the first realistic implementations for general purpose servers, and now they are unfortunately saddled with UEFI and ACPI. This was a rare 2-3 decades kind of mistake. Not a lot of software gets that privilege.
    - yuhong 9y ago
      It wasn't long ago that there was another thread: https://news.ycombinator.com/item?id=15695903 https://news.ycombinator.com/item?id=15695903
kev009 9y ago
That is almost entirely FUD, every Mac before the intel switch had OpenFirmware. FCode was elegant in that it is cross platform, and the option ROMs can work across multiple uarchs. The only valid point is that Forth is obscure. I don't know how much that matters in reality due to how obscure working at that level is itself, as an OS dev you're working on the device tree and runtime services in a language like C. But I will grant benefit of the doubt since I'm an OS dev and not an option ROM dev.. and say, well, Petitboot is the logical endgame as the industry has made Linux uber alles and you're going to be writing drivers for it anyway.
- snuxoll 9y ago
  Also, talking about the OF device tree duplicating functionality in ACPI like it's a bad thing. ACPI is a huge shitshow, if transitioning from legacy BIOS to something other than UEFI happened maybe we could have killed it off and done something better. With that said, UEFI isn't TERRIBLE - the complexity is hard to overlook and for all the benefits boot services among other things can bring it's rarely used by anybody but Apple.
  - wolfgke 9y ago
    > With that said, UEFI isn't TERRIBLE - the complexity is hard to overlook UEFI is not actually that complex (though not a jewel of tinyness). There are lots of features that are optional. So in principle it is possible to build a quite small UEFI implementation if desired. The problem is that most mainboard vendors deliver very bloated implementations. I actually can understand there reasoning: They only want to (barely) support one implementation. If a feature is left out, there will be customers that complain. On the other hand, if they leave it in, it "suffices" to add an option in in the UEFI configuration tool that enables the user to disable the feature.
    - justinjlynn 9y ago
      well, to be fair, they generally buy implementations from third party vendors. Those vendors throw things in for competitive advantage because some other vendor footed the bill for implementation and "why maintain multiple builds or a kconfig file". It's a bit of a crap spiral. If the implementations were open source with a strong consulting component for integration you'd probably see less non-removable bloat.
kabdib 9y ago
I hate FORTH as a general purpose environment, and I've seen a lot of FORTH-based train wrecks written by FORTH fanatics. But FORTH really, really shines in the boot environment, it's a fantastic tool for setting up hardware and gluing things together. As for the arguments that it's got poor performance, I'd like to point out that the BIOS / UEFI based systems on most of the systems I work with take minutes to POST, tens of minutes for the bigger machines, and I think it's a clear case of not looking critically at their own work.
- jandrese 9y ago
  My favorite is waiting 8-10 minutes for UEFI to finish whatever the hell it is doing to have exactly one second to hit the appropriate F key to get into the boot options.
  - exikyut 9y ago
    On servers, I presume?
    - userbinator 9y ago
      That's probably due to a very thorough memory test, and it's not particular to UEFI either --- I have worked with older servers, with regular BIOS, that do the same thing. There may be an option to disable it.
      - exikyut 9y ago
        Makes sense. I should hope there is such an option, for OS/boot debugging etc!!
      - kabdib 9y ago
        Memory tests are a big part of it, but definitely not the only really slow component. (The 10+ minute boot time on our bigger servers already is the fast version of the memory test. I've never turned on the more exhaustive one).
gioele 9y ago
> Open Firmware, also known as IEEE-1275, has issues in that it is an interpreted, stack-based byte-code. Very few programmers are facile in Forth programming And ACPI is based on an interpreted, non stack-based bytecode, AML. [1] There is one order of magnitude or two more Forth programmers than AML/ASL programmers. [1] http://wiki.osdev.org/AML http://wiki.osdev.org/AML
- kjkjhkjhkjhdsa 9y ago
  precisly AML requires freaking garbage collection in the interpreter and deal with a zillion complex data types. AML is so crazily obscure and ugly with its 4 character identifier limit. its is all bad and ugly and the people responsible for this monster should be forced to write AML interpreters in AML forever until they die.
xorgar831 9y ago
Fair enough, but why is there no standard shell or alternative interpreter?
- wolfgke 9y ago
  > Fair enough, but why is there no standard shell or alternative interpreter? There actually exists the UEFI Shell, but not every UEFI implementation has it built in. For example the UEFI implementation that Intel provides for the Minnowboard Max (now EOL) and Minnowboard Turbot does provide an UEFI Shell. If the producer of the mainboard/laptop has not built in the UEFI Shell, there still exist options to start an UEFI Shell binary as an ordinary UEFI application (just as a bootloader etc. is also just an UEFI application): > https://superuser.com/a/1057594/62591 https://superuser.com/a/1057594/62591 In principle it should even be possible to write an alternative shell for UEFI and start it this way, but I am not aware that someone has written one.
raverbashing 9y ago
You know what else is a stack-based byte code? JVM They could have had an easier to read language on top of that VM (could be Python/Lua or something else)

wmf 9y ago

That's pretty revisionist considering that OF predates ACPI. Just like all other stories of path dependence, Intel backed themselves into a corner and now they're stuck there forever.

wolfgke 9y ago
> Just like all other stories of path dependence, Intel backed themselves into a corner and now they're stuck there forever. Beside the "well-known" implementations of UEFI for x86-32, IA-64 (Itanium) and X64-64, there also exist official UEFI implementations for ARM AArch32 and ARM AArch64. According to https://en.wikipedia.org/w/index.php?title=Unified_Extensible_Firmware_Interface&oldid=809635217#Processor_compatibility https://en.wikipedia.org/w/index.php?title=Unified_Extensibl... there also exist inofficial implementations for POWERPC64, MIPS and RISC-V. One consumer example where UEFI on ARM processors was used was the ARM-based Windows RT laptops (they were not very successful in the market). Much more importantly an UEFI implementation is required for ARM's "Server Base Boot Requirements (SBBR) - System Software on ARM® Platforms" standard: > http://infocenter.arm.com/help/topic/com.arm.doc.den0044b/DEN0044B_Server_Base_Boot_Requirements.pdf http://infocenter.arm.com/help/topic/com.arm.doc.den0044b/DE... (read section 3 and appendices A to D). So about every ARM server uses an UEFI firmware.
- kev009 9y ago
  Going back to the intel FUD paper, if you consider volume shipment as success as in their document, uboot looking thing with FDTs are the most successful paradigm by orders of magnitude. The kind of systems using FDTs aren't going to switch I don't think. I have to imagine that ARM64 UEFI was done for marketing and by clueless product management. The CPUs and integration of ARM servers have been so pathetic, nobody was buying, and they were fumbling around at this level while ignoring the elephant in the room. TX2 and Centriq are the first realistic implementations for general purpose servers, and now they are unfortunately saddled with UEFI and ACPI. This was a rare 2-3 decades kind of mistake. Not a lot of software gets that privilege.
  - yuhong 9y ago
    It wasn't long ago that there was another thread: https://news.ycombinator.com/item?id=15695903 https://news.ycombinator.com/item?id=15695903

kev009 9y ago

That is almost entirely FUD, every Mac before the intel switch had OpenFirmware. FCode was elegant in that it is cross platform, and the option ROMs can work across multiple uarchs. The only valid point is that Forth is obscure. I don't know how much that matters in reality due to how obscure working at that level is itself, as an OS dev you're working on the device tree and runtime services in a language like C. But I will grant benefit of the doubt since I'm an OS dev and not an option ROM dev.. and say, well, Petitboot is the logical endgame as the industry has made Linux uber alles and you're going to be writing drivers for it anyway.

snuxoll 9y ago
Also, talking about the OF device tree duplicating functionality in ACPI like it's a bad thing. ACPI is a huge shitshow, if transitioning from legacy BIOS to something other than UEFI happened maybe we could have killed it off and done something better. With that said, UEFI isn't TERRIBLE - the complexity is hard to overlook and for all the benefits boot services among other things can bring it's rarely used by anybody but Apple.
- wolfgke 9y ago
  > With that said, UEFI isn't TERRIBLE - the complexity is hard to overlook UEFI is not actually that complex (though not a jewel of tinyness). There are lots of features that are optional. So in principle it is possible to build a quite small UEFI implementation if desired. The problem is that most mainboard vendors deliver very bloated implementations. I actually can understand there reasoning: They only want to (barely) support one implementation. If a feature is left out, there will be customers that complain. On the other hand, if they leave it in, it "suffices" to add an option in in the UEFI configuration tool that enables the user to disable the feature.
  - justinjlynn 9y ago
    well, to be fair, they generally buy implementations from third party vendors. Those vendors throw things in for competitive advantage because some other vendor footed the bill for implementation and "why maintain multiple builds or a kconfig file". It's a bit of a crap spiral. If the implementations were open source with a strong consulting component for integration you'd probably see less non-removable bloat.

kabdib 9y ago

I hate FORTH as a general purpose environment, and I've seen a lot of FORTH-based train wrecks written by FORTH fanatics. But FORTH really, really shines in the boot environment, it's a fantastic tool for setting up hardware and gluing things together. As for the arguments that it's got poor performance, I'd like to point out that the BIOS / UEFI based systems on most of the systems I work with take minutes to POST, tens of minutes for the bigger machines, and I think it's a clear case of not looking critically at their own work.

jandrese 9y ago
My favorite is waiting 8-10 minutes for UEFI to finish whatever the hell it is doing to have exactly one second to hit the appropriate F key to get into the boot options.
- exikyut 9y ago
  On servers, I presume?
  - userbinator 9y ago
    That's probably due to a very thorough memory test, and it's not particular to UEFI either --- I have worked with older servers, with regular BIOS, that do the same thing. There may be an option to disable it.
    - exikyut 9y ago
      Makes sense. I should hope there is such an option, for OS/boot debugging etc!!
    - kabdib 9y ago
      Memory tests are a big part of it, but definitely not the only really slow component. (The 10+ minute boot time on our bigger servers already is the fast version of the memory test. I've never turned on the more exhaustive one).

gioele 9y ago

> Open Firmware, also known as IEEE-1275, has issues in that it is an interpreted, stack-based byte-code. Very few programmers are facile in Forth programming And ACPI is based on an interpreted, non stack-based bytecode, AML. [1] There is one order of magnitude or two more Forth programmers than AML/ASL programmers. [1] http://wiki.osdev.org/AML http://wiki.osdev.org/AML

kjkjhkjhkjhdsa 9y ago
precisly AML requires freaking garbage collection in the interpreter and deal with a zillion complex data types. AML is so crazily obscure and ugly with its 4 character identifier limit. its is all bad and ugly and the people responsible for this monster should be forced to write AML interpreters in AML forever until they die.

xorgar831 9y ago

Fair enough, but why is there no standard shell or alternative interpreter?

wolfgke 9y ago
> Fair enough, but why is there no standard shell or alternative interpreter? There actually exists the UEFI Shell, but not every UEFI implementation has it built in. For example the UEFI implementation that Intel provides for the Minnowboard Max (now EOL) and Minnowboard Turbot does provide an UEFI Shell. If the producer of the mainboard/laptop has not built in the UEFI Shell, there still exist options to start an UEFI Shell binary as an ordinary UEFI application (just as a bootloader etc. is also just an UEFI application): > https://superuser.com/a/1057594/62591 https://superuser.com/a/1057594/62591 In principle it should even be possible to write an alternative shell for UEFI and start it this way, but I am not aware that someone has written one.

raverbashing 9y ago

You know what else is a stack-based byte code? JVM They could have had an easier to read language on top of that VM (could be Python/Lua or something else)