Open Firmware is now free
As of this week, however, one aspect of Mr. Bradley's job has changed: he is now working with free software. Between code releases by Sun Microsystems and FirmWorks, the entire Open Firmware system is now free. Most of it is available under the BSD or MIT license; it can be browsed on the net or obtained from the Subversion repository at svn://openbios.org/openfirmware.
Open Firmware is an interesting system. At its core, it is an interpreter for the Forth language; most of the higher-level functionality is implemented in Forth and run on the interpreter. That will make the Open Firmware source relatively opaque for those of us who are not accustomed to working in stack-based languages; Open Firmware will certainly have the only ext2 filesystem code which looks like this:
: ext2fsfread ( addr count 'fh -- #read ) drop dup bsize > abort" Bad size for ext2fsfread" file-size lblk# bsize * - ( addr count rem ) umin swap ( actual addr ) lblk# read-file-block ( actual ) dup 0> if lblk#++ then ( actual )
The use of Forth does help to keep the Open Firmware code compact and quick, however. This system can work with several different filesystems, perform TCP/IP networking (including functioning as an HTTP server or client), work with USB devices, and drive a wide range of devices in general. And it all fits in about 350KB of flash, with the ability to shoehorn it into 256KB if need be.
Open Firmware can also be useful for debugging hardware issues. The Forth interpreter is available at the system console, allowing a sufficiently clued developer to poke at device registers directly and see what happens. This feature is especially useful when trying to bring up new hardware which is displaying unexpected behavior. As Mr. Bradley has been heard to say:
Open Firmware is a foot-shooting tool of substantial power.
The Open Firmware code was widely used, even when it was a proprietary product. This code will be even more widely distributed soon. Back in October, the One Laptop Per Child project announced that it would be adopting Open Firmware for its systems. LinuxBIOS will remain on those systems as the low-level BIOS, but Open Firmware will be the code which performs boot loading and presents the firmware-level interface to the user. The OLPC decision was based on smaller size, greater speed, and greater flexibility of the Open Firmware code. Once Open Firmware set on the path toward a free release, OLPC's decision was relatively easy.
In the future, the now-free nature of Open Firmware may cause it to appear
on a number of new systems, in places where a proprietary BIOS would have
been found before. As a result, a part of our systems which has
traditionally been proprietary and closed might just become open and free.
So, while many of us may never work with this code directly, we'll likely
benefit from its freedom anyway.
Posted Nov 16, 2006 5:37 UTC (Thu)
by flewellyn (subscriber, #5047)
[Link] (1 responses)
Posted Nov 16, 2006 7:27 UTC (Thu)
by felixfix (subscriber, #242)
[Link]
Posted Nov 16, 2006 14:37 UTC (Thu)
by rfunk (subscriber, #4054)
[Link] (7 responses)
Posted Nov 16, 2006 16:36 UTC (Thu)
by hollis (subscriber, #6768)
[Link] (5 responses)
In practice, I suspect bootloaders will always exist on Open Firmware systems as long as people understand C better than Forth.
Posted Nov 17, 2006 21:39 UTC (Fri)
by giraffedata (guest, #1954)
[Link] (4 responses)
Regardless of familiarity with the language, I don't see how Open Firmware is better than Grub. I'd rather have just enough code in ROM to load the next stage from a more mutable device, which is what we typically have today.
A big part of what OF is is pluggable device drivers to let you boot from lots of different kinds of devices. I'd rather just see a program that can boot from only one kind of device -- a removeable, standard, USB flash drive. You can put as much intelligence on that drive as it takes to boot the next stage from whatever you want, so instead of today's POST or OF, I would probably put a tiny Linux on it. In some cases, I wouldn't even need a next stage.
With such a small initial program, people wouldn't have much interest in seeing its source code or updating it; it would be equivalent to code inside the network adapter, but even less interesting.
Posted Nov 18, 2006 17:33 UTC (Sat)
by hollis (subscriber, #6768)
[Link] (3 responses)
Don't forget that flash is mutable.
The "small initial program" you talk about is an accurate description of today's BIOS or Open Firmware, yet for some reason many people are interested in open source firmware instead. Firmware access would mean we could fix bugs and add features instead of awkward workarounds at higher levels of software. For example, we could add an LVM driver to the firmware itself, and not have to worry about loading successive "stages" like GRUB must resort to.
Posted Nov 20, 2006 4:41 UTC (Mon)
by giraffedata (guest, #1954)
[Link] (2 responses)
OK. But I sensed that was being used as a argument in favor of switching to Open Firmware from what we have today. I don't think it's a good argument. In fact, even if I had Open Firmware, I'd probably have it load Grub from my disk.
I meant to refer to something smaller than today's BIOS and much, much smaller than Open Firmware. I can understand why people want an open source alternative to the BIOS boot loader we have now, but if it were as small as I would like, I don't think they would care that it's closed source.
I would rather add an LVM driver to something more mutable than flash, such as the standard USB flash drive I mentioned. That's why I don't care if I have open source firmware (if "firmware" means what lives in the flashable read-only memory that sits in the main address space at boot time).
Posted Nov 27, 2006 20:23 UTC (Mon)
by jimwelch (guest, #178)
[Link] (1 responses)
I care about closed source for all the normal open/close reasons. The main reason's that affect me:
1. BUGS - some of my "old" computers don't do big disks.
Most of this is just not cost effective under the ancient proprietary system in use today for BIOS.
Posted Nov 28, 2006 7:04 UTC (Tue)
by giraffedata (guest, #1954)
[Link]
...
Most of this is just not cost effective under the ancient proprietary system in use today for BIOS.
Those are all good reasons to care about closed source of today's BIOS, but not relevant to the point to which you are responding. That point is that with a small initial program instead of what we have today, people wouldn't care about having its source code. Such a boot program wouldn't be involved in any of the issues you list.
Getting back the OF question: The reasons listed are not only good reasons to have open source for the code that handles those things, but also for being able to update that code easily, for example with a 'cp' shell command instead of an arcane BIOS flash procedure. And in a way that if you screw it up, you can easily repair the damage. Open Firmware doesn't do any better than today's BIOS in those areas, and in fact is worse because there's so much more code in there that you'll want to update.
Posted Nov 16, 2006 19:40 UTC (Thu)
by jg (guest, #17537)
[Link]
Then again, we're not trying to boot multiple operating systems (nor will vanilla Windows boot on our hardware, due to lack of VGA support in the BIOS, since the code was not free).
Posted Nov 17, 2006 2:09 UTC (Fri)
by salimma (subscriber, #34460)
[Link] (2 responses)
Posted Nov 17, 2006 21:54 UTC (Fri)
by giraffedata (guest, #1954)
[Link]
A good reason to have two separate programs is the same thing that led to having two separate programs (BIOS and OS) on the first ISA computers: BIOS is married to the hardware and OS is married to the application. You mix and match in order to have any combination of application and hardware.
When OF runs without a separate BIOS, it contains a machine-type-dependent BIOS. The only difference really is one of packaging and naming. To me, it makes the most sense to package bona fide BIOS with the hardware and package everything else separately, for more flexibility and better compatibility.
In the case of Sparc, Mac, and IBM System P, the OF instance is designed for a particular machine type and supplied with that machine, so there's no reason to have a machine type compatibility layer (BIOS) under it. But if you're going to separately distribute one OF to run on a variety of machines distributed by someone else, separate BIOS makes a lot of sense.
Posted Nov 18, 2006 17:40 UTC (Sat)
by hollis (subscriber, #6768)
[Link]
Of course, inside Open Firmware you have different components: the Forth interpreter and the low-level firmware (responsible for initializing the memory controller, discovering PCI devices, etc) are obviously separate. As a systems vendor you would naturally use the same Forth interpreter and combine it with a different low-level firmware for each system.
By the way, "BIOS" is just the name for the standard PC firmware interface. The generic term is "firmware". :)
This is wonderful, not only for the listed reasons, but also because Open Firmware, and Forth, Open Firmware is now free
are just fun to mess around with. What other boot firmware can you write Tower of Hanoi
programs in?
Yes, since I do almost everything from Emacs, it does qualify as boot firmware, for sufficient values of "boot" and "firmware" :-)Emacs lisp
It's worth noting that Macs have used OpenFirmware for some years now. Open Firmware is now free
OpenFirmware could also remove the need for GRUB and LILO, correct?
All open source firmware could remove the need for bootloaders like LILO or GRUB, because you could simply extend the firmware to provide the functionality.Open Firmware is now free
Open Firmware is now free
It's not that Open Firmware is "better" than GRUB. It's that if you have open source firmware (be it BIOS, Open Firmware, or "other" like u-boot), GRUB is unnecessary.Open Firmware is now free
Open Firmware is now free
It's not that Open Firmware is "better" than GRUB. It's that if you have open source firmware (be it BIOS, Open Firmware, or "other" like u-boot), GRUB is unnecessary.
The "small initial program" you talk about is an accurate description of today's BIOS or Open Firmware
For example, we could add an LVM driver to the firmware itself
>> I don't think they would care that it's closed source.Open Firmware is now free
2. DRM - some talk of only allowing certain OS's on a unit.
3. Features - LVM, boot from flash (missing on my old units), the next big hardware item (firewire disks).
4. Lack of support from the vendor to fix the above problems for old units.
Open Firmware is now free
I care about closed source for all the normal open/close reasons. The main reason's that affect me:
We aren't using grub or lilo on the OLPC system.Open Firmware is now free
- JIm
Do Sun and Apple (pre-Intel) use OpenFirmware entirely, or do they also use a separate lower-level BIOS? I'm curious as to whether the next version of OLPC will switch to OpenFirmware entirely. Seems redundant to use two separate BIOSes apart from for easing the transition.Open Firmware is now free
Open Firmware is now free
Seems redundant to use two separate BIOSes
Open Firmware comes in ROM, so in that sense there is no "separate" firmware."lower-level BIOS"