For fun, try something new and discover different solutions!
ARC firmware uses C language and closer to UEFI, Openfirmware uses Forth language.
“For the RISC machines of the 1990’s, there was an effort to rally around a common firmware
standard. An industry group referred to as Advanced RISC Computing (ARC) [6] aimed to unify
the boot environment for MIPS CPU and DEC Alpha. ARC shared some features with UEFI,
including the support of a FAT file system in the firmware, firmware boot variables, and a C-
callable interface. But ARC lacked, GPT, the extensibility of UEFI, and clear legal specification
governance or an evolution path like the UEFI Forum and UEFI specification. As a design,
another issue with ARC was that it specified platform design definitions. This design mandated
that various components must exist in a platform, thereby limiting diversity of platform
designs. Also, ARC was never ported to a volume architecture such as IA-32® or x64.
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.”
NetBSD has good documentation on ARC firmware: