RE the bigger issue of compiling things direct into linuxbios.
I've been thinking for some time of an experiment, namely turning this whole business inside-out. Think of it this way: there is a runtime startup for every program your write, called in old times crt0 (which is why I used that name for LinuxBIOS). But from your point of view, your program is not crt0, it's main().
So looking from the point of view of the compiler and library writers, who know nothing of your program when they write the compilers and libraries, the world is libc.a and crt0. You don't care about that, and from your point of view, the world is your program. You use the compiler to get your startup code and some library calls.
This leads to a natural question: what if we think of linuxbios as something to be linked into a boot loader such as openbios, filo, 9load, or even a special linux kernel? In other words, invert our view of the world: we don't compile a boot loader as part of building linuxbios; we compile linuxbios into a bootloader. Linuxbios provides startup (analogous to crt0) and some library functions the boot loader needs (print* support, pci enumeration, etc) but the really important bit is the boot loader.
In this view, linuxbios is a library that you link your bootloader with to build a bios. This really changes things around a bit. It also removes some nasty problems, as the bootloader no longer has to supply (e.g.) its own PCI enumeration code, and can use the linuxbios PCI enumeration code, which can help boot loaders avoid bugs in chips (consider the VT8601 and the PCI bugs it used to have).
This view is sort of halfway from old bios ideas (INT xy) and current ideas (the payload doesn't know linuxbios exists). It's a huge change -- maybe a very bad idea, as it means that now LinuxBIOS provides an API, which we never intended it to do. I have no idea if it even makes sense -- just wondering.
Back to our irregularly scheduled arguments :-)
ron