Hacker News Reader

Comment by catiopatio | Hacker News Reader

Historically, OpenFirmware provided exactly what you were asking for — self-describing devices, device driver methods hanging off the device nodes, and portable, architecture-independent bytecode-based option ROM drivers on expansion cards.

Devicetree is a paired down version of OF; they retained the tree containing key/value device metadata, and dropped all the good bits.

View on HN

> and dropped all the good bits.

Something like the missing Forth interpreter would be invaluable on development boards as well as for diagnostics on embedded devices. Or simply for fun. I used to spend hours exploring PowerMacs and Forth programming, all thanks to OpenFirmware.

> architecture-independent bytecode-based option ROM drivers on expansion cards.

UEFI still has this doesn't it? EFI byte code [0].

[0] - https://edk2-docs.gitbook.io/edk-ii-uefi-driver-writer-s-gui...

Microsoft won't sign EBC drivers, but even before Secure Boot made that difficult I think we'd found a total of 2 EBC UEFI drivers in the real world. It's honestly easier to just embed an x86 emulator.

How are architecture-independent bytecode-based option ROM drivers the good bits in the context of open source systems?

You could ship bootable PCI cards that worked on any OF-capable architecture.

Open source doesn’t mean not shipping binaries.

It was Forth bytecode; the disassembly was pretty readable, without any fancy tools, straight from the OF console (at least on PPC Macs).

I wonder if anyone could implement an OF binary for the Z-Machine. Can OF read files? I mean, not just booting them into memory at $ADDRESS, but read/parse them. I know a Tetris it's doable.

How are they NOT the BEST bits? With Open Firmware you can build Open Source systems that boot on hardware that you’ve not only never seen but never will see. Open Firmware + ELF can still be our future if we embrace it.

Except no one wants to write drivers in Forth.

Reply on news.ycombinator.com