Meet the experts: On open source firmware development

A team of experts discusses Slimline Open Firmware development and usage

Slimline Open Firmware (SLOF) provides a largely machine-independent BIOS, illustrating what is needed to initialize and boot Linux®, a hypervisor, or any other operating system or virtualization layer on PowerPC®-based machines based on the de-facto industry Open Firmware boot standard. Join three experts as they discuss the decisions in developing SLOF and where they'd use it and provide a picture of the boot-up process under SLOF.


Slimline Open Firmware (SLOF) is initialization and boot source code based on the IEEE-1275 standard (also known as the Open Firmware standard). Of what possible use is it?

If you're a software engineer interested in PowerPC-based systems, it can be invaluable when developing boot firmware, an operating system, or low-level application code. For hardware engineers, it provides fast bring-up of PowerPC systems, verification, and prototyping of hardware support and drivers. SLOF is important, too, in that it allows a vendor to separate the low-level firmware from the SLOF layer.

In this interview, developerWorks discusses the issues surrounding SLOF with:

Otto Wohlmuth, Firmware Manager in the Boeblingen Lab and Platform Lead and Personnel Manager for the Cell project: With IBM for about six years, Otto also worked in the zSeries® mainframe environment.
Segher Boessenkool, PowerPC Firmware Developer, Boeblingen Lab: Segher has been with IBM for about two years; he came to the Lab when it was looking for an Open Firmware guy.
Hartmut Penner, Firmware Designer, Boeblingen Lab: Hartmut has been with IBM now for almost nine years and in that time has worked on all different kinds of projects, mostly in zSeries firmware as well as open source work with GCC. He joined the SLOF project two years ago and has been involved with the SLOF design and development for Cell.

developerWorks: Are there more of you on the SLOF project altogether, or is it mainly you three?

Otto Wohlmuth: We three are working more or less on the SLOF design development and on the strategy, how we want to proceed with this; and we have, for the Cell-based project, an additional core team member, Stefan Koch. He is focusing on the low-level firmware which is the first code running on the CPU; he is a very experienced engineer and was a member of the team who did the first PowerPC-based blade.

What is SLOF for?

dW: Can you describe when and why I would want to use SLOF?

Wohlmuth: Yes. The main focus of this project is to run Linux natively on a PowerPC 64-bit system -- not having additional code layers in between so that the device drivers and everything is running directly on the hardware. For sure there is some runtime support possible, but this is optional. This is not something you really need. It's a kind of possibility to abstract some of the very hardware-specific things from the operating system.

Hartmut Penner: SLOF is meant primarily for companies who want to build a system based on the PowerPC 970 processor or other low-end PowerPC 64 processors; SLOF is a very attractive solution for that kind of development because it has a very simple design and you can really go to market fast with this product. Like, you have your board, you put SLOF on it, you have to write some low-level firmware code which is board-specific, and then you have a tool to debug the system and to boot Linux.

The other place where SLOF is very useful is when you want to boot and run a hypervisor-like development to open source such as Xen, for example, on a JS20. You cannot run it on the current system firmware because it already has a hypervisor. And so SLOF could be a base for doing hypervisor development.

Cell blade prototype development

dW: With your internal development on the Cell blade prototype boards, are you using SLOF for that firmware? With the booting?

Penner: The firmware for the Cell-based blades is SLOF, so we are also the team for the firmware development of the Cell-based blades. And we are working very closely together with the Linux development in Boeblingen, including Arnd [Bergmann, see Resources], so there's pretty much a synergy between the native Linux kernel development, also done for Cell and SLOF.

dW: And what did you use before you got to the point where you could use SLOF?

Penner: We started with SLOF development on Cell bring-up boards in STIDC in Austin.

dW: So your very first flash was with SLOF.

Wohlmuth: For our Cell blades, yes.

Penner: And SLOF is the only firmware booting that Cell blade.

dW: So developers that are looking forward to working with the Cell blades can expect to see SLOF as the firmware?

Hartmut: Yes.

Segher Boessenkool: Yes. There is no other firmware so far to boot Linux on Cell blades.

SLOF versus Open Firmware (OF)

dW: How about SLOF compared with, for instance, what Apple uses to boot their PowerPC? They're using an Open Firmware specification. I believe they were involved with a company called FirmWorks in order to design their very first Open Firmware 1.05 system.

Now, the FirmWorks Company will design and implement a Forth-based boot code for you [see Resources], but of course you're going to be paying commercial prices for this. Can SLOF be considered a candidate to be basically an open source alternative to something like that?

Boessenkool: Yes. Right now, SLOF does not have very many high-level features, so it's a bit bare. The FirmWorks stack is of course more sophisticated now.

dW: But commercial.

Boessenkool: But commercial, yes.

dW: What hardware debugging features does SLOF have currently?

Penner: You can use the standard user interface for debug and bring-up purposes which can easily be extended for specific needs.

dW: You said that the implementation had some omissions, or that stuff was not yet implemented regarding some of the client/user interface for debugging purposes, stuff like .registers, dis. Are these things available?

Penner: Most of it is available -- the features are available, but with the first release not all interfaces were implemented according to the standard.

dW: Okay. I was using Apple's versions of what you would use to see the registers. So from the command-line interface you can examine addresses in memory, different CPU registers, including some of the special registers?

Boessenkool: Yes. And if you want more, it's easy to add them.

dW: Yes, I noticed that the documentation on the process of adding functionality from within C was quite good.

Penner: It is really easy to add the functionality. If you want to look at a different special-purpose register which is not in, you have to change some code -- which is described in the README -- at two places. So as SLOF is currently, you can really easily adapt it to your purposes. I think that's an attractive thing about it. It is not a black box, it's a very easily expandable system.

Open Firmware compliance, trade-offs, and specifics

Boessenkool: But we are also trying to be fully Open Firmware-compliant.

Wohlmuth: Which is somehow a trade-off.

Boessenkool: Yes. The currently released code is about the bare minimum you need to boot Linux on the JS20. It's a bit more, but not very much more.

dW: Speaking of being Open Firmware-compliant, in the boot process typically firmware will develop a device tree; in an Open Firmware case, you have the PowerPC and the PCI bindings. Is SLOF compliant with those bindings?

Boessenkool: As far as we know, it's fully compliant with the PowerPC bindings. But we don't implement most of the PCI bindings. We do build a full device tree, though, but we do not scan the PCI bus.

dW: So if you were to do a dev / ls in the command user interface, what would you see?

Boessenkool: You would see an error. [Laughter.]

That's an invalid command, because after dev, you can't have other commands from the same command line.

dW: What would be the equivalent command then, in the command-line interface, for someone debugging or establishing a ...

Boessenkool: Yes. There is an ls command in SLOF. It outputs the full device tree, always.

dW: Okay.

Boessenkool: And it is possible to do the same thing that the dev command does, but you'll have to type quite a bit by hand. The reason that we don't implement most of the PCI binding is that Linux doesn't use it. Linux scans all of PCI by itself, so for our purposes, it's not really necessary to have it in the device tree then.

dW: So you would use normal PCI routines for discovery of devices on the PCI buses?

Boessenkool: Yes.

The gritty details

dW: The firmware is in Forth?

Penner: Yes. Almost all of it is in Forth. The low-level firmware is in Assembly. The paflof engine is in C. And it's fully portable except that it needs GCC, and it currently doesn't work on GCC Versions 4 or higher. But other than that, it's pretty much portable.

dW: So you said that the paflof engine is in C. How does that work? What part does that generate in your final image that you load into flash?

Penner: The paflof part, it's executable code, like three kilobytes of it or something. It's a Forth engine and it works like a virtual machine. The core engine is pre-compiled because that is the code that has to interpret the rest of the Forth code during runtime; it can't compile itself. That doesn't work. And that part is pre-compiled by a fairly nasty Perl script. [Laughter.]

dW: So the paflof engine is the Forth interpreter?

Boessenkool: Yes.

dW: Okay. One question: In the documentation, it says that the SLOF image has to be loaded into the flash ROM on your boot system. In particular, you could use this in the JS20. Would you need to have an existing system already installed in order to be able to flash the image into memory?

Boessenkool: Yes, you would need to. Unfortunately.

dW: So this isn't a bootstrap situation.

Boessenkool: No. We have internal and development systems [which] have some other mechanisms to program the flash. And it would be nice if we could provide a way to write a flash from native Linux itself, but if you don't have a native Linux running on SLOF yet, then you can't use that. It would be nice to have a way to program the flash from the firmware, but it's kind of a chicken-and-egg situation, you know?

Wohlmuth: As long as you don't have the firmware on the system which is capable of flashing ...

Boessenkool: Then you can't flash.

In development systems, you normally have some extra hardware to do the flashing for you. Or you can just remove the flash tier but go into an external flash program.

dW: So this would be a -- I guess -- would you consider SLOF to be kind of an intermediary step in releasing a final hardware product?

Boessenkool: It could be used for that, yes. If SLOF is not good enough for the product you want to release, does not have all the features you need for the product you want to release, you can still use it for bringing up the hardware.

SLOF as a teaching tool

dW: Do you see also using SLOF as a teaching tool? As a way to teach how to design and implement an Open Firmware code?

Boessenkool: Yes, it is a bit of a reference implementation and for the release code, we cleaned it up a lot, added a lot of comments, and so on. So in some ways it's perhaps a bit of a teaching tool.

Penner: Internally, we use much of that code to teach people to get used to Forth and Open Firmware because it's a really nice, small tool for teaching.

Boessenkool: It's hard though, in that environment. It still doesn't have any more command-line editing than the backspace, and that was only added like a month ago.

[Laughter.] Sorry, no -- a year ago, I mean.

dW: I found reading the source code to paflof and SLOF in general to be a very good teaching tool. I do have some experience with Forth and Open Firmware and I really appreciated seeing how the underlayment below the actual Forth level [worked] and seeing how you can use C to compile and extend a firmware implementation. So I would like to compliment you on your effort there.

Boessenkool: Thanks.

Comparing SLOF and paflof

dW: Before SLOF, Segher, you worked on paflof, which is in some ways similar. Can you describe the similarities or differences between paflof and SLOF?

Boessenkool: Paflof was only a Forth engine, whereas SLOF is an Open Firmware implementation using paflof as the Forth engine.

dW: Paflof was released under a GPL, and SLOF under a BSD-like license. Can we talk about why?

Wohlmuth: No. We're not supposed to talk about licensing issues.

Future revisions

dW: What changes can we expect in the future? Are you working on a revision to SLOF?

Wohlmuth: [Short term,] we are working on updating and providing new functions and probably fixes. It's a little bit depending on the release process on the Web and how this can be aligned with our internal development processes, but we are intending to provide fixes.

Boessenkool: [Longer term,] there are huge parts of the OF standard that we don't implement at all right now because we didn't need them. But it would be nice to have them. Like, we don't have an FCODE evaluator in the release source, for example, which you do need if you have plug-in cards with FCodes on them.

Wohlmuth: But the main purpose is not to provide a full-blown firmware implementation with all the bells and whistles. We are really focusing on keeping it small. We might extend it if there is truly a requirement for it, to add more functionality, but we'll keep it small and easy to maintain.

dW: Okay, great. Thank you so much for taking the time to talk to us about SLOF.

Wohlmuth: Thank you.



  • Interested in Cell programming? The following papers define the Cell specification and are now available without registration from the IBM Semiconductor solutions technical library.
  • This introduction to the IBM Cell Blades prototype building blocks covers the following technologies: IBM Blade Center platform, the Cell processor, open system software (like Linux), and commodity high-speed switches (IBM Research).
  • The OpenBIOS Project is a free portable firmware implementation with the goal of implementing a 100% IEEE 1275-1994-compliant firmware.
  • Meet the experts: Arnd Bergmann on Cell features Arnd Bergmann, a kernel hacker with the IBM Linux Technology Center, the Linux on Cell kernel maintainer, and author of the spufs file system (developerWorks, June 2005).
  • FirmWorks has been developing Open Firmware for PowerPC since 1995.

Get products and technologies



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into developerWorks

Zone=Multicore acceleration
ArticleTitle=Meet the experts: On open source firmware development