https://openfirmware.info/api.php?action=feedcontributions&user=Wmb&feedformat=atomOpenBIOS - User contributions [en]2024-03-28T13:26:03ZUser contributionsMediaWiki 1.40.0https://openfirmware.info/index.php?title=Building_OFW_for_QEMU&diff=398Building OFW for QEMU2011-03-18T22:05:47Z<p>Wmb: page rename</p>
<hr />
<div>This page tells how to build the x86 version of Open Firmware to run under the QEMU emulator. In this version, OFW replaces QEMU's normal "bios.bin" file, so QEMU boots directly into OFW, without a conventional BIOS. This version supports most of QEMU's I/O capabilities, illustrating some of the things that OFW can do. See the [[#QEMU Options / Things to Try]] section.<br />
<br />
The OFW tree contains a version of the platform-specific "early startup" code that is suitable for initializing QEMU's virtual hardware. The early-startup code for QEMU is as simple as such code can possibly be, because the QEMU core system "hardware" requires no initialization. On real hardware, you must turn on PLLs, configure bus bridges and superIO chips, detect DRAM characteristics and configure memory controllers, and do other complex chipset-dependent things in the early stages of startup. QEMU omits all that "magic" stuff that is outside of generic x86 programming models, so the only system-specific early startup code for QEMU is a simple memory sizing loop.<br />
<br />
In addition to this "direct" version, there are two other ways to run OFW under QEMU:<br />
* You can build OFW as "payload" for Coreboot, so Core boot does the early-startup stuff - see [[OFW as a Coreboot Payload]].<br />
* You can boot OFW from a conventional BIOS - see [[Building OFW to Load from BIOS]]<br />
<br />
=== Software Requirements ===<br />
<br />
* qemu-0.9.1<br />
* Open Firmware rev. >= 1051<br />
* GCC and GNU make - OFW builds with most versions<br />
<br />
=== Getting QEMU ===<br />
Get QEMU >= 0.9.1 from http://bellard.org/qemu/download.html<br />
<br />
=== Building Open Firmware ===<br />
<br />
Get the Open Firmware source:<br />
<br />
svn co svn://openfirmware.info/openfirmware<br />
<br />
Build OFW:<br />
<br />
cd openfirmware/cpu/x86/pc/emu/build<br />
make<br />
<br />
After make is finished (it shouldn't take long) there should be a file "emuofw.rom" in the build directory. Copy this to your qemu directory.<br />
<br />
<br />
=== Run Your ROM Image ===<br />
<br />
qemu -L . -bios emuofw.rom -hda fat:.<br />
<br />
That is the basic invocation; you should get a console window with OFW running in it. OFW is using the emulated Cirrus graphics display in linear framebuffer mode, not in VGA mode.<br />
<br />
=== QEMU Options / Things to Try ===<br />
<br />
QEMU has lots of options that let you do all sorts of fun things. The following sections illustrate a few of OFW's I/O capabilities.<br />
<br />
==== Memory Size ====<br />
<br />
If you look in OFW's startup banner, you should see "128 MiB memory installed". That is QEMU's default memory size. You can change that by adding "-m NNN" to the qemu command line, for example:<br />
<br />
qemu -L . -bios emuofw.rom -hda fat:. -m 32<br />
<br />
OFW as configured will work with power-of-two size between 32 and 2048 MiB (although my QEMU installation only works up to 1024 MB). Those limits aren't inherent inheret OFW, but rather artifacts of the way this particular "port" is configured.<br />
<br />
==== Hard Disk Images ====<br />
<br />
The command line argument "-hda fat:." as shown above makes the current directory on the host system appear to OFW as an IDE hard disk with a read-only FAT filesystem. You can inspect it with:<br />
<br />
ok .partitions c<br />
ok dir c:\<br />
<br />
The device name "c" is a devalias. You can see the actual device name with:<br />
<br />
ok devalias c<br />
ok devalias<br />
<br />
Instead of that "virtual FAT filesystem", you can make use Linux tools to make a filesystem image. In this example, we'll create a 10 MByte image with a single partition and an ext2 filesystem:<br />
<br />
$ dd if=/dev/zero of=filesystem.img bs=1M count=10<br />
$ /sbin/mke2fs -F filesystem.img<br />
$ dd if=filesystem.img of=fs.img bs=512 seek=1<br />
$ rm filesystem.img<br />
$ /sbin/sfdisk -L -uS -C 10 -H 64 -S 32 fs.img <<EOF<br />
,,L,*<br />
;<br />
;<br />
;<br />
EOF<br />
$ mkdir mnt<br />
$ sudo mount -o loop,offset=512 fs.img mnt<br />
$ # Now copy some files to "mnt"<br />
$ sudo umount mnt<br />
<br />
$ qemu -L . -bios emuofw.rom -hda fs.img<br />
<br />
In the QEMU OFW console window:<br />
<br />
ok dir c:\<br />
<br />
In the recipe above, the total size (10 MiB) appears on the first "dd" line (count=10) and on the "sfdisk" line (-C 10). The sfdisk values for heads (-H 64) and sectors (-S 32) are set so that the cylinder size is 1MiB (64*32*512), making it easy to set the overall size with the cylinders (-C) argument. It is more common to use the maximum values -H 255 -S 63 in order to maximize the possible overall size, but that results in a cylinder size of just under 8M, which isn't quite as easy to work with for this example. The recipe uses two "dd" lines instead of making the image file in one step because the "mke2fs" command doesn't give you the option of skipping the first sector where the partition map has to be located.<br />
<br />
==== Serial Console ====<br />
<br />
You can tell QEMU to emulate a serial port by adding "-serial NAME" to the command line, as with:<br />
<br />
$ qemu -L . -bios emuofw.rom -hda fat:. -serial `tty`<br />
<br />
Then you can tell OFW to use the serial console with:<br />
<br />
ok com1 io<br />
<br />
QEMU has lots of options for directing the emulated serial port to various places, including real serial ports on the host system and network connections to other machines. Read the [http://bellard.org/qemu/qemu-doc.html QEMU documentation] (-serial option) for more information.<br />
<br />
You can configure OFW to use the serial port by default, instead of the graphics screen and emulated PC keyboard. To do so, uncomment the line "create serial-console" in openfirmware/cpu/x86/emu/config.fth and re-execute the "make" command. Serial consoles are convenient because it's usually easy to cut-and-paste Forth code into the window that is acting as the "terminal emulator" for the serial console; you can't paste into QEMU's graphical console.<br />
<br />
==== Networking ====<br />
<br />
OFW has an extensive network stack, supporting many protocols including TFTP, NFS, HTTP (client and server), and Telnet (client and server). Here's an example qemu command line with networking support enabled:<br />
<br />
$ qemu -L . -bios emuofw.rom -hda fat:. -net nic,model=pcnet -net tap<br />
<br />
Consult the [http://bellard.org/qemu/qemu-doc.html QEMU documentation] (the "-net" option) to learn how to configure the "tap" interface to connect through to the real network.<br />
<br />
Here are some OFW networking commands that you might want to try:<br />
<br />
ok watch-net<br />
ok debug-net<br />
ok ping yahoo.com<br />
ok undebug-net<br />
ok ping firmworks.com<br />
ok more http:\\firmworks.com\hello.fth<br />
ok fload http:\\firmworks.com\hello.fth<br />
ok telnetd<br />
telnet://10.20.0.107<br />
<br />
Now start a telnet client on some machine, connecting to the IP address shown.<br />
Quitting the telnet client restores the OFW prompt to the QEMU console.<br />
<br />
ok telnet 10.20.0.5<br />
<br />
Instead of "10.20.0.5", use the hostname or IP address of a telnet server. To exit, type Ctrl-] .<br />
<br />
ok httpd<br />
http://10.20.0.107<br />
<br />
Browse to the URL shown. Type any key on the QEMU console to exit the HTTP server. In addition to static pages, the HTTP server can do server-side scripting with Forth, and of course you do client-side scripting by serving up Javascript or Java pages. This facility has been used for an interactive embedded system with a Web interface programmed entirely in Open Firmware - a multi-headed high-speed camera for real-time analysis of golf clubs and golf swings.<br />
<br />
OFW also supports IPV6 networking, but it's not compiled into this version.<br />
<br />
You can, of course, boot operating systems over the network, using TFTP, NFS, or HTTP.<br />
<br />
==== Graphics ====<br />
<br />
OFW uses the display in linear framebuffer mode, so it can display 2D graphics. To see a simple demo:<br />
<br />
ok fload http:\\firmworks.com\testrect.fth<br />
<br />
To clear the screen afterwards:<br />
<br />
ok page<br />
<br />
OFW has a graphical menu system that is not enabled in this configuration. You can navigate it with either the mouse or the keyboard. OFW can display .BMP files.<br />
<br />
==== USB ====<br />
<br />
To make QEMU emulate a USB mass storage device, do this:<br />
<br />
$ qemu -L . -bios emuofw.rom -hda fat:. -usbdevice disk:fat:.<br />
<br />
Then, in OFW:<br />
<br />
ok probe-usb<br />
ok dir u:\<br />
<br />
"p2" is an alias for "probe-usb" for us lazy people. Since OFW tries not to do stuff "behind your back", if you plug in a new USB device, you must tell OFW to rescan the USB bus. In this case, it will have already scanned the device (it does that automatically at startup), but rescanning is a convenient way to get OFW to show you what is there. You could instead say:<br />
<br />
ok show-devs usb<br />
<br />
but "p2" is easier to type.<br />
<br />
In the qemu command, you could attach a writable disk image with, for example:<br />
<br />
$ qemu -L . -bios emuofw.rom -hda fat:. -usbdevice disk:fs.img<br />
<br />
assuming that you have created a suitable fs.img file as per the instructions above. You can't use the same writable image for both -hda and -usbdevice, but it's okay to use the same read-only image (as with the fat:<directory> syntax) for both.<br />
<br />
OFW has reasonably good support for a wide selection of USB mass storage devices - flash keys, disks, CDROMs, multi-card readers, etc. OFW also supports USB keyboards, but I haven't yet figured out how to make that work under QEMU. OFW supports some USB 2.0 network interfaces and some USB-to-serial adapters. You might be able to make those work using QEMU's ability to connect to real USB devices on the host. On real hardware, OFW supports UHCI (USB 1.1), OHCI (USB 1.1), and EHCI (USB 2.0) host controllers.<br />
<br />
==== Sound ====<br />
<br />
To enable sound support in QEMU, do this:<br />
<br />
$ qemu -L . -bios emuofw.rom -hda fat:. -soundhw sb<br />
<br />
In OFW:<br />
<br />
ok select /sound<br />
ok d# 200 d# 2000 tone<br />
ok unselect<br />
<br />
That plays a 200 Hz sine wave for 2 seconds (2000 mS). OFW can also play .wav files, but that's not included in this configuration.<br />
<br />
QEMU has a lot of options to control the sound emulation; read the documentation to get totally confused.<br />
<br />
OFW's SoundBlaster driver, as included in this configuration, is rather rudimentary. OFW has better drivers for the more common AC97 sound hardware.<br />
<br />
<br />
__NOEDITSECTION__</div>Wmbhttps://openfirmware.info/index.php?title=OFW_as_a_Coreboot_Payload&diff=396OFW as a Coreboot Payload2011-03-18T22:04:59Z<p>Wmb: Page rename</p>
<hr />
<div>This page tells how to build Open Firmware as a Coreboot payload and run it under QEMU. You can also run Open Firmware under QEMU without Coreboot:<br />
* You can build a QEMU ROM image directly from code in the OFW tree - see [[Building OFW for QEMU]].<br />
* You can boot OFW from a conventional BIOS - see [[Building OFW to Load from BIOS]]<br />
<br />
=== Software Requirements ===<br />
<br />
* qemu-0.9.1<br />
* Open Firmware rev. >= 1051<br />
* coreboot >= v2<br />
* GCC and GNU make - OFW builds with most versions; I'm not sure which versions Coreboot needs<br />
<br />
=== Building Open Firmware ===<br />
<br />
Download the Open Firmware source:<br />
<br />
svn co svn://openfirmware.info/openfirmware<br />
<br />
Configure OFW for Coreboot:<br />
<br />
cd openfirmware/cpu/x86/pc/biosload<br />
cp config-coreboot.fth config.fth<br />
<br />
Build OFW:<br />
<br />
cd build<br />
make<br />
<br />
After make is finished (it shouldn't take long) there should be a file "ofwlb.elf" in the same directory. Copy this to your coreboot-v[x] directory.<br />
<br />
=== Building coreboot ===<br />
Follow the instructions in the coreboot documentation, using ofwlb.elf as your payload file.<br />
<br />
=== Getting QEMU ===<br />
Get QEMU >= 0.9.1 from http://bellard.org/qemu/download.html<br />
<br />
Version 0.9.1 should "just work". It supports reasonably large ROM images, determining the emulated ROM size from the size of the image file. There was a "qemu_biossize.patch" for qemu-0.9.0, but the site that hosted that patch is defunct.<br />
<br />
=== Run Your ROM Image ===<br />
<br />
qemu -L coreboot-v3/build -hda path/to/disk.img -serial `tty` -nographic<br />
<br />
=== Ideas for Improvement ===<br />
<br />
These instructions build a rather plain OFW configuration that lacks drivers for several of QEMU's specific I/O devices (Ethernet, video, sound). Suitable drivers are in the OFW tree, and are included in the QEMU build described in [[Building OFW for QEMU]]. It would be nice to add those drivers to the configuration described herein. If the Cirrus video driver were added, qemu could be used in graphic mode.<br />
<br />
<br />
__NOEDITSECTION__</div>Wmbhttps://openfirmware.info/index.php?title=Open_Firmware&diff=381Open Firmware2011-03-18T22:02:14Z<p>Wmb: /* Page rename */</p>
<hr />
<div>== Introduction ==<br />
<br />
In 2006 the company of Open Firmware inventor Mitch Bradley, [http://firmworks.com/ Firmworks, Inc], released their Open Firmware implementation (OFW) under a BSD license. This code shares some code with SUN's OpenBOOT implementation. The open source OFW supports x86, PowerPC, and ARM architectures. Other architectures, including SPARC and MIPS, may be added as time and interest dictate.<br />
<br />
The x86 version is used on the OLPC "XO" computer. The x86 version can be configured for numerous other environments, including<br />
* Direct QEMU ROM (replacing the "bios.bin" that is supplied with QEMU<br />
* Coreboot payload<br />
* Loadable on directly on top of a conventional PC BIOS (booted from floppy or hard disk like an OS). In this configuration it can run on an arbitrary PC, or on an emulator like QEMU, VirtualBox, or VMWare.<br />
<br />
OFW can boot Linux directly from a disk file (FAT, ext2, ISO9660, or jffs2 filesystems) without the need for an intermediate bootloader like LILO or GRUB. The Linux image can be in either ELF format (as created by the first phase of the Linux kernel compilation process) or in the "bzImage" format that "wraps" the ELF image. When booting an ELF image, OFW can read the ELF symbol table so OFW's assembly language debugger can resolve kernel symbols.<br />
<br />
OFW can also boot other ELF standalone images, providing to them rudimentary "libc" capability. That facility has been used for booting, for example, Minix, ReactOS, Plan9, Inferno and SqueakNOS. The OLPC system ROM includes several such "standalone client programs", including MicroEMACS, memtest86, and NANDblaster (a facility for fast OS updates over multicast wireless).<br />
<br />
On the OLPC system, OFW emulates enough legacy BIOS "real mode INTs" to boot Windows XP. On another system, OFW supports booting Windows CE.<br />
<br />
== Download ==<br />
<br />
You can [http://tracker.coreboot.org/trac/openfirmware/browser browse the source code online].<br />
<br />
The repository is available through Subversion:<br />
<br />
You can check it out as follows:<br />
$ svn co svn://openfirmware.info/openfirmware/<br />
<br />
if you want a specific revision: <br />
$ svn co svn://openfirmware.info/openfirmware -r 35<br />
<br />
If your company installed a firewall that blocks the svn port (3690) you can also check out using the webdav frontend:<br />
<br />
$ svn co <nowiki>https://www.openfirmware.info/openfirmware-svn/ openfirmware</nowiki><br />
<br />
==Building Different Versions==<br />
<br />
* Direct QEMU ROM: see [[Building OFW for QEMU]]<br />
* Coreboot: see [[OFW as a Coreboot Payload]]<br />
* OLPC: see [[Building OFW for OLPC]]<br />
* BIOS-loaded: see [[Building OFW to Load from BIOS]]<br />
* ARM: see [[Building OFW for ARM]]<br />
<br />
== Mailing List ==<br />
<br />
There's an Open Firmware mailing list at:<br />
<br />
* http://www.openfirmware.info/mailman/listinfo/openfirmware.<br />
<br />
The mailing list archive is also available:<br />
<br />
* http://www.openfirmware.info/pipermail/openfirmware/</div>Wmbhttps://openfirmware.info/index.php?title=Building_OFW_to_Run_Under_BIOS&diff=418Building OFW to Run Under BIOS2011-03-18T22:00:29Z<p>Wmb: moved Building OFW to Run Under BIOS to Building OFW to Load from BIOS: New title is more accurate</p>
<hr />
<div>#REDIRECT [[Building OFW to Load from BIOS]]</div>Wmbhttps://openfirmware.info/index.php?title=Building_OFW_to_Load_from_BIOS&diff=404Building OFW to Load from BIOS2011-03-18T22:00:29Z<p>Wmb: moved Building OFW to Run Under BIOS to Building OFW to Load from BIOS: New title is more accurate</p>
<hr />
<div>This page tells how to build the x86 version of Open Firmware to boot under a conventional BIOS. These instructions specifically describe a configuration that is good for running on the QEMU and VirtualBox emulators, but very similar instructions can be used to make a version that runs on any PC. In this version, OFW is stored on a floppy disk image. The conventional BIOS boots it as if it were an operating system like DOS or Windows. OFW then "takes over" the machine, ignoring the conventional BIOS that booted it. That BIOS has already done the work of early-startup machine initialization - turning on the memory controller and configuring chipset-dependent registers.<br />
<br />
In addition to this BIOS-loaded version, there are two other ways to run OFW under QEMU:<br />
* You can build an OFW image that replaces the QEMU BIOS ROM image, entirely from code in the OFW tree - see [[Building OFW for QEMU]].<br />
* You can build an OFW image that replaces the QEMU BIOS ROM image, using OFW as a "payload" for Coreboot, so Coreboot does the early-startup stuff - see [[OFW as a Coreboot Payload]].<br />
<br />
=== Software Requirements ===<br />
<br />
* qemu-0.9.1 or VirtualBox<br />
* Open Firmware rev. >= 1053<br />
* GCC and GNU make - most versions work for builing OFW<br />
<br />
=== Getting Open Firmware Source ===<br />
<br />
$ svn co svn://openfirmware.info/openfirmware<br />
<br />
=== Building OFW ===<br />
<br />
$ cd cpu/x86/pc/biosload/<br />
$ cp config-virtualbox.fth config.fth<br />
$ cd build<br />
$ make floppyofw.img<br />
<br />
The "config-virtualbox.fth" configuration is known to work with QEMU.<br />
Other configurations may work also - but the "qemu-loaded" config<br />
option isn't what you want for this technique, because it's a subcase<br />
of the CoreBoot-payload configuration.<br />
<br />
You will use the "floppyofw.img" output file in a later step.<br />
<br />
=== Making a bootable Floppy Image ===<br />
<br />
$ ../../../Linux/forth fw.dic ../makefloppy.fth<br />
<br />
This creates a file that is a bootable floppy image with an empty<br />
FAT12 filesystem. This step only has to be done once.<br />
<br />
=== Copying OFW onto the Floppy Image ===<br />
<br />
$ mkdir flp<br />
$ sudo mount -t msdos -o loop floppy.img flp<br />
$ sudo cp floppyofw.img flp/ofw.img<br />
$ sudo umount flp<br />
<br />
Copy floppy.img to the QEMU or VirtualBox directory.<br />
<br />
=== Booting OFW from QEMU ===<br />
<br />
$ qemu -L <dir> -boot a -fda floppy.img<br />
<br />
"<dir>" is the directory that contains QEMU's BIOS and VGA BIOS files.<br />
<br />
=== Booting OFW from VirtualBox ===<br />
<br />
The following VirtualBox configuration settings work for me:<br />
<br />
OS Type = Other/Unknown<br />
Base Memory = 64 MB<br />
Video Memory = 8 MB<br />
Boot Order = Floppy, Hard Disk<br />
ACPI = Disabled<br />
IO APIC = Disabled<br />
VT-x/AMD-V = Disabled<br />
PAE/NX = Disabled<br />
Floppy Image = floppy.img<br />
Network Adapter 1 = PCnet-PCI II (host interface, <tap name>)<br />
(other settings are mostly irrelevant)<br />
<br />
=== Recompiling ===<br />
<br />
If you want to make changes and recompile OFW, you need not repeat the<br />
"makefloppy" step; you can just loopback mount the floppy image and<br />
copy the new OFW version to ofw.img .<br />
<br />
=== What is on the Floppy Image ===<br />
<br />
The floppy image is a bootable floppy with a FAT12 filesystem. Its first two<br />
sectors contain a simple bootloader program that uses BIOS INT 13 callbacks to<br />
read floppy sectors. The program scans the FAT root directory entries to find<br />
the file "ofw.img", then loads that into memory and jumps to it.<br />
<br />
When you build floppyofw.img, as a side effect it also builds bootsec.img, which<br />
is that simple bootloader. The source code (Forth-style assembly language) is in<br />
biosload/bootsec.fth .<br />
<br />
The "makefloppy.fth" program that creates the image is pretty simple; it copies<br />
bootsec.img to the output file "floppy.img", creates a couple of initially<br />
empty FAT tables, zeros the root directory area, and fills the data area with<br />
zeros.<br />
<br />
=== Making a Prototype Floppy Image with Linux Commands ===<br />
<br />
Here's a pair of Linux commands that accomplish the same thing<br />
as makefloppy.fth:<br />
<br />
Step6a $ /sbin/mkdosfs -C -f 2 -F 12 -R 2 -r 224 -s 1 -S 512 floppy.img 1440<br />
Step6b $ dd <bootsec.img of=floppy.img conv=nocreat,notrunc<br />
<br />
The arguments to mkdosfs force the filesystem layout to match the layout that<br />
is specified in the BIOS parameter block in bootsec.img.<br />
<br />
The advantage of makefloppy.fth is that it reads the filesystem layout parameters<br />
from the BPB in bootsec.img, so its guaranteed to be consistent. If bootsec.fth<br />
were edited to change the layout, the arguments to "mkdosfs" would have to change.<br />
(But there's little need to change that layout, since it's a standard floppy<br />
size.)<br />
<br />
The advantage of the Linux command sequence is that it creates a file with<br />
"holes", thus saving disk space for awhile (until something fills in the holes).<br />
<br />
=== Booting on a Real PC from a USB Key ===<br />
<br />
To build for a real PC:<br />
<br />
$ cd openfirmware/cpu/x86/biosload<br />
$ cp config-usbkey.fth config.fth<br />
$ cd build<br />
$ make<br />
<br />
That will create a file named "ofw.c32" that can be booted from a USB key that has "syslinux" installed on it. http://www.911cd.net/forums//index.php?showtopic=21902 has some tips on how to install syslinux.<br />
<br />
Your syslinux.cfg file needs a line that says:<br />
<br />
kernel ofw.c32<br />
<br />
=== Booting on a Real PC via GRUB or Etherboot ===<br />
<br />
You can make a version in "Multiboot" format that you can boot with GRUB:<br />
<br />
$ cd openfirmware/cpu/x86/biosload<br />
$ cp config-grub.fth config.fth<br />
$ cd build<br />
$ make<br />
<br />
The output file is "ofwgrub.elf". Copy that in to /boot on your GRUB-enabled disk and add this to /boot/grub/menu.lst:<br />
<br />
title Open Firmware<br />
kernel /boot/ofwgrub.elf<br />
<br />
That version can also be booted via Etherboot. Here's an example of how to Etherboot it with QEMU (assuming that the ofwgrub.elf file is in /tmp on the host machine):<br />
<br />
qemu -L . -boot n -tftp /tmp -bootp /ofwgrub.elf</div>Wmbhttps://openfirmware.info/index.php?title=Building_OFW_for_ARM&diff=411Building OFW for ARM2010-08-11T18:45:42Z<p>Wmb: Info about other build versions</p>
<hr />
<div>This page tells how to build Open Firmware for an ARM target system.<br />
<br />
=== Host System Requirements ===<br />
<br />
During the Open Firmware build process, the Forth system inside OFW is executed several times to extend itself. Those steps must run on the same CPU instruction set (in this case ARM) as the final target. So you must build OFW either on an ARM computer or by using an ARM instruction set emulator running on some other computer. [[http://wiki.qemu.org/ QEMU]] works well for this purpose.<br />
<br />
==== Compiler Setup for Native ARM Host ====<br />
<br />
To compile on an ARM host, you need Linux on that host, along with the GNU toolchain (GCC), GNU make, and the Subversion version control system.<br />
<br />
==== Compiler Setup for x86 Host ====<br />
<br />
To compile on an x86 host, you need everything listed for the native host (Linux, GNU toolchain, GNU make, and Subversion), plus QEMU.<br />
<br />
Note that the GNU toolchain that you need is the native x86 one, not an ARM cross-toolchain. OFW uses its own built-in ARM assembler. The native x86 toolchain is needed for the one-time step of compiling a small interface program that lets the OFW builder operate under Linux. It would be possible to eliminate that need by distributing a precompiled binary of that interface program, but in practice, most developers already have the native x86 toolchain already installed, so requiring it isn't a problem (as opposed to cross-toolchains, which can be a serious hassle to set up correctly).<br />
<br />
To install QEMU:<br />
<br />
* Debian: sudo apt-get install qemu<br />
* Ubuntu 8.04 (Hardy): sudo apt-get install qemu<br />
* Ubuntu 9.10 (Karmic): sudo apt-get install qemu qemu-kvm-extras<br />
* Fedora: sudo yum install qemu-user<br />
<br />
In general, the file that you need is "qemu-arm". You can use commands like (Fedora) "yum whatprovides qemu-arm" or (Debian/Ubuntu) "apt-file search qemu-arm" to work out which top-level package to install.<br />
<br />
For Fedora, you might also need to temporarily disable SELinux security before OFW compilation:<br />
<br />
sudo /usr/sbin/setenforce 0<br />
<br />
=== Building Open Firmware ===<br />
<br />
Get the Open Firmware source:<br />
<br />
svn co svn://openfirmware.info/openfirmware<br />
<br />
Build OFW:<br />
<br />
cd openfirmware/cpu/arm/mmp2/build<br />
make<br />
<br />
The last line of the compilation output should say something like:<br />
<br />
--- Saving as ofw.rom<br />
<br />
That tells you the name of the output file.<br />
<br />
There are some other build directories like "cpu/arm/versatilepb/build". They work the same way - just type "make" in the directory. At present, those other versions are fairly rudimentary, containing core OFW plus a serial driver for interaction, but lacking drivers for most of the other hardware on those systems. Essentially, they are "quick ports to get an ok prompt". The MMP2 version is quite a bit more complete, on its way to being a fully-fledged OFW system. The MMP2 is Marvell's hardware development platform for their PXA688 chip, which is slated for use in the OLPC XO-1.75 system. We are using the MMP2 to get a jump-start on XO-1.75 development.</div>Wmbhttps://openfirmware.info/index.php?title=Building_OFW_for_ARM&diff=410Building OFW for ARM2010-08-11T18:03:06Z<p>Wmb: Clarified which toolchain</p>
<hr />
<div>This page tells how to build Open Firmware for an ARM target system.<br />
<br />
=== Host System Requirements ===<br />
<br />
During the Open Firmware build process, the Forth system inside OFW is executed several times to extend itself. Those steps must run on the same CPU instruction set (in this case ARM) as the final target. So you must build OFW either on an ARM computer or by using an ARM instruction set emulator running on some other computer. [[http://wiki.qemu.org/ QEMU]] works well for this purpose.<br />
<br />
==== Compiler Setup for Native ARM Host ====<br />
<br />
To compile on an ARM host, you need Linux on that host, along with the GNU toolchain (GCC), GNU make, and the Subversion version control system.<br />
<br />
==== Compiler Setup for x86 Host ====<br />
<br />
To compile on an x86 host, you need everything listed for the native host (Linux, GNU toolchain, GNU make, and Subversion), plus QEMU.<br />
<br />
Note that the GNU toolchain that you need is the native x86 one, not an ARM cross-toolchain. OFW uses its own built-in ARM assembler. The native x86 toolchain is needed for the one-time step of compiling a small interface program that lets the OFW builder operate under Linux. It would be possible to eliminate that need by distributing a precompiled binary of that interface program, but in practice, most developers already have the native x86 toolchain already installed, so requiring it isn't a problem (as opposed to cross-toolchains, which can be a serious hassle to set up correctly).<br />
<br />
To install QEMU:<br />
<br />
* Debian: sudo apt-get install qemu<br />
* Ubuntu 8.04 (Hardy): sudo apt-get install qemu<br />
* Ubuntu 9.10 (Karmic): sudo apt-get install qemu qemu-kvm-extras<br />
* Fedora: sudo yum install qemu-user<br />
<br />
In general, the file that you need is "qemu-arm". You can use commands like (Fedora) "yum whatprovides qemu-arm" or (Debian/Ubuntu) "apt-file search qemu-arm" to work out which top-level package to install.<br />
<br />
For Fedora, you might also need to temporarily disable SELinux security before OFW compilation:<br />
<br />
sudo /usr/sbin/setenforce 0<br />
<br />
=== Building Open Firmware ===<br />
<br />
Get the Open Firmware source:<br />
<br />
svn co svn://openfirmware.info/openfirmware<br />
<br />
Build OFW:<br />
<br />
cd openfirmware/cpu/arm/mmp2/build<br />
make<br />
<br />
The last line of the compilation output should say something like:<br />
<br />
--- Saving as ofw.rom<br />
<br />
That tells you the name of the output file.<br />
<br />
There are some other build directories like "cpu/arm/versatilepb/build". At the time of this writing, they have not been fixed up to "do the right thing" with the emulated build environment. The Makefile in cpu/arm/mmp2/build is the current "gold standard" for the build automation.</div>Wmbhttps://openfirmware.info/index.php?title=Building_OFW_for_ARM&diff=409Building OFW for ARM2010-08-11T17:45:04Z<p>Wmb: More information about finding qemu-arm</p>
<hr />
<div>This page tells how to build Open Firmware for an ARM target system.<br />
<br />
=== Host System Requirements ===<br />
<br />
During the Open Firmware build process, the Forth system inside OFW is executed several times to extend itself. Those steps must run on the same CPU instruction set (in this case ARM) as the final target. So you must build OFW either on an ARM computer or by using an ARM instruction set emulator running on some other computer. [[http://wiki.qemu.org/ QEMU]] works well for this purpose.<br />
<br />
==== Compiler Setup for Native ARM Host ====<br />
<br />
To compile on an ARM host, you need Linux on that host, along with the GNU toolchain (GCC and GNU make) plus the Subversion version control system.<br />
<br />
==== Compiler Setup for x86 Host ====<br />
<br />
To compile on an x86 host, you need everything listed for the native host (Linux, GNU toolchain, and Subversion), plus QEMU.<br />
<br />
To install QEMU:<br />
<br />
* Debian: sudo apt-get install qemu<br />
* Ubuntu 8.04 (Hardy): sudo apt-get install qemu<br />
* Ubuntu 9.10 (Karmic): sudo apt-get install qemu qemu-kvm-extras<br />
* Fedora: sudo yum install qemu-user<br />
<br />
In general, the file that you need is "qemu-arm". You can use commands like (Fedora) "yum whatprovides qemu-arm" or (Debian/Ubuntu) "apt-file search qemu-arm" to work out which top-level package to install.<br />
<br />
For Fedora, you might also need to temporarily disable SELinux security before OFW compilation:<br />
<br />
sudo /usr/sbin/setenforce 0<br />
<br />
=== Building Open Firmware ===<br />
<br />
Get the Open Firmware source:<br />
<br />
svn co svn://openfirmware.info/openfirmware<br />
<br />
Build OFW:<br />
<br />
cd openfirmware/cpu/arm/mmp2/build<br />
make<br />
<br />
The last line of the compilation output should say something like:<br />
<br />
--- Saving as ofw.rom<br />
<br />
That tells you the name of the output file.<br />
<br />
There are some other build directories like "cpu/arm/versatilepb/build". At the time of this writing, they have not been fixed up to "do the right thing" with the emulated build environment. The Makefile in cpu/arm/mmp2/build is the current "gold standard" for the build automation.</div>Wmbhttps://openfirmware.info/index.php?title=Building_OFW_for_ARM&diff=408Building OFW for ARM2010-08-11T08:52:36Z<p>Wmb: Output file name is ofw.rom, not mmp2.rom</p>
<hr />
<div>This page tells how to build Open Firmware for an ARM target system.<br />
<br />
=== Host System Requirements ===<br />
<br />
During the Open Firmware build process, the Forth system inside OFW is executed several times to extend itself. Those steps must run on the same CPU instruction set (in this case ARM) as the final target. So you must build OFW either on an ARM computer or by using an ARM instruction set emulator running on some other computer. [[http://wiki.qemu.org/ QEMU]] works well for this purpose.<br />
<br />
==== Compiler Setup for Native ARM Host ====<br />
<br />
To compile on an ARM host, you need Linux on that host, along with the GNU toolchain (GCC and GNU make) plus the Subversion version control system.<br />
<br />
==== Compiler Setup for x86 Host ====<br />
<br />
To compile on an x86 host, you need everything listed for the native host (Linux, GNU toolchain, and Subversion), plus QEMU.<br />
<br />
To install QEMU:<br />
<br />
* Debian: sudo apt-get install qemu<br />
* Ubuntu: sudo apt-get install qemu<br />
* Fedora: sudo yum install qemu-user<br />
<br />
For Fedora, you might also need to disable SELinux security during OFW compilation:<br />
<br />
sudo /usr/sbin/setenforce 0<br />
<br />
=== Building Open Firmware ===<br />
<br />
Get the Open Firmware source:<br />
<br />
svn co svn://openfirmware.info/openfirmware<br />
<br />
Build OFW:<br />
<br />
cd openfirmware/cpu/arm/mmp2/build<br />
make<br />
<br />
The last line of the compilation output should say something like:<br />
<br />
--- Saving as ofw.rom<br />
<br />
That tells you the name of the output file.<br />
<br />
There are some other build directories like "cpu/arm/versatilepb/build". At the time of this writing, they have not been fixed up to "do the right thing" with the emulated build environment. The Makefile in cpu/arm/mmp2/build is the current "gold standard" for the build automation.</div>Wmbhttps://openfirmware.info/index.php?title=Building_OFW_for_ARM&diff=407Building OFW for ARM2010-08-11T06:28:10Z<p>Wmb: Compiling the ARM version</p>
<hr />
<div>This page tells how to build Open Firmware for an ARM target system.<br />
<br />
=== Host System Requirements ===<br />
<br />
During the Open Firmware build process, the Forth system inside OFW is executed several times to extend itself. Those steps must run on the same CPU instruction set (in this case ARM) as the final target. So you must build OFW either on an ARM computer or by using an ARM instruction set emulator running on some other computer. [[http://wiki.qemu.org/ QEMU]] works well for this purpose.<br />
<br />
==== Compiler Setup for Native ARM Host ====<br />
<br />
To compile on an ARM host, you need Linux on that host, along with the GNU toolchain (GCC and GNU make) plus the Subversion version control system.<br />
<br />
==== Compiler Setup for x86 Host ====<br />
<br />
To compile on an x86 host, you need everything listed for the native host (Linux, GNU toolchain, and Subversion), plus QEMU.<br />
<br />
To install QEMU:<br />
<br />
* Debian: sudo apt-get install qemu<br />
* Ubuntu: sudo apt-get install qemu<br />
* Fedora: sudo yum install qemu-user<br />
<br />
For Fedora, you might also need to disable SELinux security during OFW compilation:<br />
<br />
sudo /usr/sbin/setenforce 0<br />
<br />
=== Building Open Firmware ===<br />
<br />
Get the Open Firmware source:<br />
<br />
svn co svn://openfirmware.info/openfirmware<br />
<br />
Build OFW:<br />
<br />
cd openfirmware/cpu/arm/mmp2/build<br />
make<br />
<br />
The last line of the compilation output should say something like:<br />
<br />
--- Saving as mmp2.rom<br />
<br />
That tells you the name of the output file.<br />
<br />
There are some other build directories like "cpu/arm/versatilepb/build". At the time of this writing, they have not been fixed up to "do the right thing" with the emulated build environment. The Makefile in cpu/arm/mmp2/build is the current "gold standard" for the build automation.</div>Wmbhttps://openfirmware.info/index.php?title=Open_Firmware&diff=380Open Firmware2010-08-10T18:11:46Z<p>Wmb: /* Added ARM building link */</p>
<hr />
<div>== Introduction ==<br />
<br />
In 2006 the company of Open Firmware inventor Mitch Bradley, [http://firmworks.com/ Firmworks, Inc], released their Open Firmware implementation (OFW) under a BSD license. This code shares some code with SUN's OpenBOOT implementation. The open source OFW supports x86, PowerPC, and ARM architectures. Other architectures, including SPARC and MIPS, may be added as time and interest dictate.<br />
<br />
The x86 version is used on the OLPC "XO" computer. The x86 version can be configured for numerous other environments, including<br />
* Direct QEMU ROM (replacing the "bios.bin" that is supplied with QEMU<br />
* Coreboot payload<br />
* Loadable on directly on top of a conventional PC BIOS (booted from floppy or hard disk like an OS). In this configuration it can run on an arbitrary PC, or on an emulator like QEMU, VirtualBox, or VMWare.<br />
<br />
OFW can boot Linux directly from a disk file (FAT, ext2, ISO9660, or jffs2 filesystems) without the need for an intermediate bootloader like LILO or GRUB. The Linux image can be in either ELF format (as created by the first phase of the Linux kernel compilation process) or in the "bzImage" format that "wraps" the ELF image. When booting an ELF image, OFW can read the ELF symbol table so OFW's assembly language debugger can resolve kernel symbols.<br />
<br />
OFW can also boot other ELF standalone images, providing to them rudimentary "libc" capability. That facility has been used for booting, for example, Minix, ReactOS, Plan9, Inferno and SqueakNOS. The OLPC system ROM includes several such "standalone client programs", including MicroEMACS, memtest86, and NANDblaster (a facility for fast OS updates over multicast wireless).<br />
<br />
On the OLPC system, OFW emulates enough legacy BIOS "real mode INTs" to boot Windows XP. On another system, OFW supports booting Windows CE.<br />
<br />
== Download ==<br />
<br />
You can [http://tracker.coreboot.org/trac/openfirmware/browser browse the source code online].<br />
<br />
The repository is available through Subversion:<br />
<br />
You can check it out as follows:<br />
$ svn co svn://openfirmware.info/openfirmware/<br />
<br />
if you want a specific revision: <br />
$ svn co svn://openfirmware.info/openfirmware -r 35<br />
<br />
If your company installed a firewall that blocks the svn port (3690) you can also check out using the webdav frontend:<br />
<br />
$ svn co <nowiki>https://www.openfirmware.info/openfirmware-svn/ openfirmware</nowiki><br />
<br />
==Building Different Versions==<br />
<br />
* Direct QEMU ROM: see [[Building OFW for QEMU]]<br />
* Coreboot: see [[OFW as a Coreboot Payload]]<br />
* OLPC: see [[Building OFW for OLPC]]<br />
* BIOS-loaded: see [[Building OFW to Run Under BIOS]]<br />
* ARM: see [[Building OFW for ARM]]<br />
<br />
== Mailing List ==<br />
<br />
There's an Open Firmware mailing list at:<br />
<br />
* http://www.openfirmware.info/mailman/listinfo/openfirmware.<br />
<br />
The mailing list archive is also available:<br />
<br />
* http://www.openfirmware.info/pipermail/openfirmware/</div>Wmbhttps://openfirmware.info/index.php?title=Building_OFW_to_Load_from_BIOS&diff=403Building OFW to Load from BIOS2008-12-29T11:03:26Z<p>Wmb: Added GRUB instructions</p>
<hr />
<div>This page tells how to build the x86 version of Open Firmware to boot under a conventional BIOS. These instructions specifically describe a configuration that is good for running on the QEMU and VirtualBox emulators, but very similar instructions can be used to make a version that runs on any PC. In this version, OFW is stored on a floppy disk image. The conventional BIOS boots it as if it were an operating system like DOS or Windows. OFW then "takes over" the machine, ignoring the conventional BIOS that booted it. That BIOS has already done the work of early-startup machine initialization - turning on the memory controller and configuring chipset-dependent registers.<br />
<br />
In addition to this BIOS-loaded version, there are two other ways to run OFW under QEMU:<br />
* You can build an OFW image that replaces the QEMU BIOS ROM image, entirely from code in the OFW tree - see [[Building OFW for QEMU]].<br />
* You can build an OFW image that replaces the QEMU BIOS ROM image, using OFW as a "payload" for Coreboot, so Coreboot does the early-startup stuff - see [[OFW as a Coreboot Payload]].<br />
<br />
=== Software Requirements ===<br />
<br />
* qemu-0.9.1 or VirtualBox<br />
* Open Firmware rev. >= 1053<br />
* GCC and GNU make - most versions work for builing OFW<br />
<br />
=== Getting Open Firmware Source ===<br />
<br />
$ svn co svn://openfirmware.info/openfirmware<br />
<br />
=== Building OFW ===<br />
<br />
$ cd cpu/x86/pc/biosload/<br />
$ cp config-virtualbox.fth config.fth<br />
$ cd build<br />
$ make floppyofw.img<br />
<br />
The "config-virtualbox.fth" configuration is known to work with QEMU.<br />
Other configurations may work also - but the "qemu-loaded" config<br />
option isn't what you want for this technique, because it's a subcase<br />
of the CoreBoot-payload configuration.<br />
<br />
You will use the "floppyofw.img" output file in a later step.<br />
<br />
=== Making a bootable Floppy Image ===<br />
<br />
$ ../../../Linux/forth fw.dic ../makefloppy.fth<br />
<br />
This creates a file that is a bootable floppy image with an empty<br />
FAT12 filesystem. This step only has to be done once.<br />
<br />
=== Copying OFW onto the Floppy Image ===<br />
<br />
$ mkdir flp<br />
$ sudo mount -t msdos -o loop floppy.img flp<br />
$ sudo cp floppyofw.img flp/ofw.img<br />
$ sudo umount flp<br />
<br />
Copy floppy.img to the QEMU or VirtualBox directory.<br />
<br />
=== Booting OFW from QEMU ===<br />
<br />
$ qemu -L <dir> -boot a -fda floppy.img<br />
<br />
"<dir>" is the directory that contains QEMU's BIOS and VGA BIOS files.<br />
<br />
=== Booting OFW from VirtualBox ===<br />
<br />
The following VirtualBox configuration settings work for me:<br />
<br />
OS Type = Other/Unknown<br />
Base Memory = 64 MB<br />
Video Memory = 8 MB<br />
Boot Order = Floppy, Hard Disk<br />
ACPI = Disabled<br />
IO APIC = Disabled<br />
VT-x/AMD-V = Disabled<br />
PAE/NX = Disabled<br />
Floppy Image = floppy.img<br />
Network Adapter 1 = PCnet-PCI II (host interface, <tap name>)<br />
(other settings are mostly irrelevant)<br />
<br />
=== Recompiling ===<br />
<br />
If you want to make changes and recompile OFW, you need not repeat the<br />
"makefloppy" step; you can just loopback mount the floppy image and<br />
copy the new OFW version to ofw.img .<br />
<br />
=== What is on the Floppy Image ===<br />
<br />
The floppy image is a bootable floppy with a FAT12 filesystem. Its first two<br />
sectors contain a simple bootloader program that uses BIOS INT 13 callbacks to<br />
read floppy sectors. The program scans the FAT root directory entries to find<br />
the file "ofw.img", then loads that into memory and jumps to it.<br />
<br />
When you build floppyofw.img, as a side effect it also builds bootsec.img, which<br />
is that simple bootloader. The source code (Forth-style assembly language) is in<br />
biosload/bootsec.fth .<br />
<br />
The "makefloppy.fth" program that creates the image is pretty simple; it copies<br />
bootsec.img to the output file "floppy.img", creates a couple of initially<br />
empty FAT tables, zeros the root directory area, and fills the data area with<br />
zeros.<br />
<br />
=== Making a Prototype Floppy Image with Linux Commands ===<br />
<br />
Here's a pair of Linux commands that accomplish the same thing<br />
as makefloppy.fth:<br />
<br />
Step6a $ /sbin/mkdosfs -C -f 2 -F 12 -R 2 -r 224 -s 1 -S 512 floppy.img 1440<br />
Step6b $ dd <bootsec.img of=floppy.img conv=nocreat,notrunc<br />
<br />
The arguments to mkdosfs force the filesystem layout to match the layout that<br />
is specified in the BIOS parameter block in bootsec.img.<br />
<br />
The advantage of makefloppy.fth is that it reads the filesystem layout parameters<br />
from the BPB in bootsec.img, so its guaranteed to be consistent. If bootsec.fth<br />
were edited to change the layout, the arguments to "mkdosfs" would have to change.<br />
(But there's little need to change that layout, since it's a standard floppy<br />
size.)<br />
<br />
The advantage of the Linux command sequence is that it creates a file with<br />
"holes", thus saving disk space for awhile (until something fills in the holes).<br />
<br />
=== Booting on a Real PC from a USB Key ===<br />
<br />
To build for a real PC:<br />
<br />
$ cd openfirmware/cpu/x86/biosload<br />
$ cp config-usbkey.fth config.fth<br />
$ cd build<br />
$ make<br />
<br />
That will create a file named "ofw.c32" that can be booted from a USB key that has "syslinux" installed on it. http://www.911cd.net/forums//index.php?showtopic=21902 has some tips on how to install syslinux.<br />
<br />
Your syslinux.cfg file needs a line that says:<br />
<br />
kernel ofw.c32<br />
<br />
=== Booting on a Real PC via GRUB or Etherboot ===<br />
<br />
You can make a version in "Multiboot" format that you can boot with GRUB:<br />
<br />
$ cd openfirmware/cpu/x86/biosload<br />
$ cp config-grub.fth config.fth<br />
$ cd build<br />
$ make<br />
<br />
The output file is "ofwgrub.elf". Copy that in to /boot on your GRUB-enabled disk and add this to /boot/grub/menu.lst:<br />
<br />
title Open Firmware<br />
kernel /boot/ofwgrub.elf<br />
<br />
That version can also be booted via Etherboot. Here's an example of how to Etherboot it with QEMU (assuming that the ofwgrub.elf file is in /tmp on the host machine):<br />
<br />
qemu -L . -boot n -tftp /tmp -bootp /ofwgrub.elf</div>Wmbhttps://openfirmware.info/index.php?title=Building_OFW_to_Load_from_BIOS&diff=402Building OFW to Load from BIOS2008-12-28T11:38:49Z<p>Wmb: typo</p>
<hr />
<div>This page tells how to build the x86 version of Open Firmware to boot under a conventional BIOS. These instructions specifically describe a configuration that is good for running on the QEMU and VirtualBox emulators, but very similar instructions can be used to make a version that runs on any PC. In this version, OFW is stored on a floppy disk image. The conventional BIOS boots it as if it were an operating system like DOS or Windows. OFW then "takes over" the machine, ignoring the conventional BIOS that booted it. That BIOS has already done the work of early-startup machine initialization - turning on the memory controller and configuring chipset-dependent registers.<br />
<br />
In addition to this BIOS-loaded version, there are two other ways to run OFW under QEMU:<br />
* You can build an OFW image that replaces the QEMU BIOS ROM image, entirely from code in the OFW tree - see [[Building OFW for QEMU]].<br />
* You can build an OFW image that replaces the QEMU BIOS ROM image, using OFW as a "payload" for Coreboot, so Coreboot does the early-startup stuff - see [[OFW as a Coreboot Payload]].<br />
<br />
=== Software Requirements ===<br />
<br />
* qemu-0.9.1 or VirtualBox<br />
* Open Firmware rev. >= 1051<br />
* GCC and GNU make - most versions work for builing OFW<br />
<br />
=== Getting Open Firmware Source ===<br />
<br />
$ svn co svn://openfirmware.info/openfirmware<br />
<br />
=== Building OFW ===<br />
<br />
$ cd cpu/x86/pc/biosload/<br />
$ cp config-virtualbox.fth config.fth<br />
$ cd build<br />
$ make floppyofw.img<br />
<br />
The "config-virtualbox.fth" configuration is known to work with QEMU.<br />
Other configurations may work also - but the "qemu-loaded" config<br />
option isn't what you want for this technique, because it's a subcase<br />
of the CoreBoot-payload configuration.<br />
<br />
You will use the "floppyofw.img" output file in a later step.<br />
<br />
=== Making a bootable Floppy Image ===<br />
<br />
$ ../../../Linux/forth fw.dic ../makefloppy.fth<br />
<br />
This creates a file that is a bootable floppy image with an empty<br />
FAT12 filesystem. This step only has to be done once.<br />
<br />
=== Copying OFW onto the Floppy Image ===<br />
<br />
$ mkdir flp<br />
$ sudo mount -t msdos -o loop floppy.img flp<br />
$ sudo cp floppyofw.img flp/ofw.img<br />
$ sudo umount flp<br />
<br />
Copy floppy.img to the QEMU or VirtualBox directory.<br />
<br />
=== Booting OFW from QEMU ===<br />
<br />
$ qemu -L <dir> -boot a -fda floppy.img<br />
<br />
"<dir>" is the directory that contains QEMU's BIOS and VGA BIOS files.<br />
<br />
=== Booting OFW from VirtualBox ===<br />
<br />
The following VirtualBox configuration settings work for me:<br />
<br />
OS Type = Other/Unknown<br />
Base Memory = 64 MB<br />
Video Memory = 8 MB<br />
Boot Order = Floppy, Hard Disk<br />
ACPI = Disabled<br />
IO APIC = Disabled<br />
VT-x/AMD-V = Disabled<br />
PAE/NX = Disabled<br />
Floppy Image = floppy.img<br />
Network Adapter 1 = PCnet-PCI II (host interface, <tap name>)<br />
(other settings are mostly irrelevant)<br />
<br />
=== Recompiling ===<br />
<br />
If you want to make changes and recompile OFW, you need not repeat the<br />
"makefloppy" step; you can just loopback mount the floppy image and<br />
copy the new OFW version to ofw.img .<br />
<br />
=== What is on the Floppy Image ===<br />
<br />
The floppy image is a bootable floppy with a FAT12 filesystem. Its first two<br />
sectors contain a simple bootloader program that uses BIOS INT 13 callbacks to<br />
read floppy sectors. The program scans the FAT root directory entries to find<br />
the file "ofw.img", then loads that into memory and jumps to it.<br />
<br />
When you build floppyofw.img, as a side effect it also builds bootsec.img, which<br />
is that simple bootloader. The source code (Forth-style assembly language) is in<br />
biosload/bootsec.fth .<br />
<br />
The "makefloppy.fth" program that creates the image is pretty simple; it copies<br />
bootsec.img to the output file "floppy.img", creates a couple of initially<br />
empty FAT tables, zeros the root directory area, and fills the data area with<br />
zeros.<br />
<br />
=== Making a Prototype Floppy Image with Linux Commands ===<br />
<br />
Here's a pair of Linux commands that accomplish the same thing<br />
as makefloppy.fth:<br />
<br />
Step6a $ /sbin/mkdosfs -C -f 2 -F 12 -R 2 -r 224 -s 1 -S 512 floppy.img 1440<br />
Step6b $ dd <bootsec.img of=floppy.img conv=nocreat,notrunc<br />
<br />
The arguments to mkdosfs force the filesystem layout to match the layout that<br />
is specified in the BIOS parameter block in bootsec.img.<br />
<br />
The advantage of makefloppy.fth is that it reads the filesystem layout parameters<br />
from the BPB in bootsec.img, so its guaranteed to be consistent. If bootsec.fth<br />
were edited to change the layout, the arguments to "mkdosfs" would have to change.<br />
(But there's little need to change that layout, since it's a standard floppy<br />
size.)<br />
<br />
The advantage of the Linux command sequence is that it creates a file with<br />
"holes", thus saving disk space for awhile (until something fills in the holes).<br />
<br />
=== Booting on a Real PC from a USB Key ===<br />
<br />
To build for a real PC:<br />
<br />
$ cd openfirmware/cpu/x86/biosload<br />
$ cp config-usbkey.fth config.fth<br />
$ cd build<br />
$ make<br />
<br />
That will create a file named "ofw.c32" that can be booted from a USB key that has "syslinux" installed on it. http://www.911cd.net/forums//index.php?showtopic=21902 has some tips on how to install syslinux.<br />
<br />
Your syslinux.cfg file needs a line that says:<br />
<br />
kernel ofw.c32<br />
<br />
(There is also some support in the source code / config.fth for building a version to boot via Grub, but I haven't tested that for some time, so it might be broken.)</div>Wmbhttps://openfirmware.info/index.php?title=Building_OFW_to_Load_from_BIOS&diff=401Building OFW to Load from BIOS2008-12-28T11:38:18Z<p>Wmb: formatting</p>
<hr />
<div>This page tells how to build the x86 version of Open Firmware to boot under a conventional BIOS. These instructions specifically describe a configuration that is good for running on the QEMU and VirtualBox emulators, but very similar instructions can be used to make a version that runs on any PC. In this version, OFW is stored on a floppy disk image. The conventional BIOS boots it as if it were an operating system like DOS or Windows. OFW then "takes over" the machine, ignoring the conventional BIOS that booted it. That BIOS has already done the work of early-startup machine initialization - turning on the memory controller and configuring chipset-dependent registers.<br />
<br />
In addition to this BIOS-loaded version, there are two other ways to run OFW under QEMU:<br />
* * You can build an OFW image that replaces the QEMU BIOS ROM image, entirely from code in the OFW tree - see [[Building OFW for QEMU]].<br />
* You can build an OFW image that replaces the QEMU BIOS ROM image, using OFW as a "payload" for Coreboot, so Coreboot does the early-startup stuff - see [[OFW as a Coreboot Payload]].<br />
<br />
=== Software Requirements ===<br />
<br />
* qemu-0.9.1 or VirtualBox<br />
* Open Firmware rev. >= 1051<br />
* GCC and GNU make - most versions work for builing OFW<br />
<br />
=== Getting Open Firmware Source ===<br />
<br />
$ svn co svn://openfirmware.info/openfirmware<br />
<br />
=== Building OFW ===<br />
<br />
$ cd cpu/x86/pc/biosload/<br />
$ cp config-virtualbox.fth config.fth<br />
$ cd build<br />
$ make floppyofw.img<br />
<br />
The "config-virtualbox.fth" configuration is known to work with QEMU.<br />
Other configurations may work also - but the "qemu-loaded" config<br />
option isn't what you want for this technique, because it's a subcase<br />
of the CoreBoot-payload configuration.<br />
<br />
You will use the "floppyofw.img" output file in a later step.<br />
<br />
=== Making a bootable Floppy Image ===<br />
<br />
$ ../../../Linux/forth fw.dic ../makefloppy.fth<br />
<br />
This creates a file that is a bootable floppy image with an empty<br />
FAT12 filesystem. This step only has to be done once.<br />
<br />
=== Copying OFW onto the Floppy Image ===<br />
<br />
$ mkdir flp<br />
$ sudo mount -t msdos -o loop floppy.img flp<br />
$ sudo cp floppyofw.img flp/ofw.img<br />
$ sudo umount flp<br />
<br />
Copy floppy.img to the QEMU or VirtualBox directory.<br />
<br />
=== Booting OFW from QEMU ===<br />
<br />
$ qemu -L <dir> -boot a -fda floppy.img<br />
<br />
"<dir>" is the directory that contains QEMU's BIOS and VGA BIOS files.<br />
<br />
=== Booting OFW from VirtualBox ===<br />
<br />
The following VirtualBox configuration settings work for me:<br />
<br />
OS Type = Other/Unknown<br />
Base Memory = 64 MB<br />
Video Memory = 8 MB<br />
Boot Order = Floppy, Hard Disk<br />
ACPI = Disabled<br />
IO APIC = Disabled<br />
VT-x/AMD-V = Disabled<br />
PAE/NX = Disabled<br />
Floppy Image = floppy.img<br />
Network Adapter 1 = PCnet-PCI II (host interface, <tap name>)<br />
(other settings are mostly irrelevant)<br />
<br />
=== Recompiling ===<br />
<br />
If you want to make changes and recompile OFW, you need not repeat the<br />
"makefloppy" step; you can just loopback mount the floppy image and<br />
copy the new OFW version to ofw.img .<br />
<br />
=== What is on the Floppy Image ===<br />
<br />
The floppy image is a bootable floppy with a FAT12 filesystem. Its first two<br />
sectors contain a simple bootloader program that uses BIOS INT 13 callbacks to<br />
read floppy sectors. The program scans the FAT root directory entries to find<br />
the file "ofw.img", then loads that into memory and jumps to it.<br />
<br />
When you build floppyofw.img, as a side effect it also builds bootsec.img, which<br />
is that simple bootloader. The source code (Forth-style assembly language) is in<br />
biosload/bootsec.fth .<br />
<br />
The "makefloppy.fth" program that creates the image is pretty simple; it copies<br />
bootsec.img to the output file "floppy.img", creates a couple of initially<br />
empty FAT tables, zeros the root directory area, and fills the data area with<br />
zeros.<br />
<br />
=== Making a Prototype Floppy Image with Linux Commands ===<br />
<br />
Here's a pair of Linux commands that accomplish the same thing<br />
as makefloppy.fth:<br />
<br />
Step6a $ /sbin/mkdosfs -C -f 2 -F 12 -R 2 -r 224 -s 1 -S 512 floppy.img 1440<br />
Step6b $ dd <bootsec.img of=floppy.img conv=nocreat,notrunc<br />
<br />
The arguments to mkdosfs force the filesystem layout to match the layout that<br />
is specified in the BIOS parameter block in bootsec.img.<br />
<br />
The advantage of makefloppy.fth is that it reads the filesystem layout parameters<br />
from the BPB in bootsec.img, so its guaranteed to be consistent. If bootsec.fth<br />
were edited to change the layout, the arguments to "mkdosfs" would have to change.<br />
(But there's little need to change that layout, since it's a standard floppy<br />
size.)<br />
<br />
The advantage of the Linux command sequence is that it creates a file with<br />
"holes", thus saving disk space for awhile (until something fills in the holes).<br />
<br />
=== Booting on a Real PC from a USB Key ===<br />
<br />
To build for a real PC:<br />
<br />
$ cd openfirmware/cpu/x86/biosload<br />
$ cp config-usbkey.fth config.fth<br />
$ cd build<br />
$ make<br />
<br />
That will create a file named "ofw.c32" that can be booted from a USB key that has "syslinux" installed on it. http://www.911cd.net/forums//index.php?showtopic=21902 has some tips on how to install syslinux.<br />
<br />
Your syslinux.cfg file needs a line that says:<br />
<br />
kernel ofw.c32<br />
<br />
(There is also some support in the source code / config.fth for building a version to boot via Grub, but I haven't tested that for some time, so it might be broken.)</div>Wmbhttps://openfirmware.info/index.php?title=Building_OFW_to_Load_from_BIOS&diff=400Building OFW to Load from BIOS2008-12-28T11:35:29Z<p>Wmb: Instructions for building OFW to boot under a conventional BIOS</p>
<hr />
<div>This page tells how to build the x86 version of Open Firmware to boot under a conventional BIOS. These instructions specifically describe a configuration that is good for running on the QEMU and VirtualBox emulators, but very similar instructions can be used to make a version that runs on any PC. In this version, OFW is stored on a floppy disk image. The conventional BIOS boots it as if it were an operating system like DOS or Windows. OFW then "takes over" the machine, ignoring the conventional BIOS that booted it. That BIOS has already done the work of early-startup machine initialization - turning on the memory controller and configuring chipset-dependent registers.<br />
<br />
In addition to this BIOS-loaded version, there are two other ways to run OFW under QEMU:<br />
* * You can build an OFW image that replaces the QEMU BIOS ROM image, entirely from code in the OFW tree - see [[Building OFW for QEMU]].<br />
* You can build an OFW image that replaces the QEMU BIOS ROM image, using OFW as a "payload" for Coreboot, so Coreboot does the early-startup stuff - see [[OFW as a Coreboot Payload]].<br />
<br />
=== Software Requirements ===<br />
<br />
* qemu-0.9.1 or VirtualBox<br />
* Open Firmware rev. >= 1051<br />
* GCC and GNU make - most versions work for builing OFW<br />
<br />
=== Building Open Firmware ===<br />
<br />
Get the Open Firmware source:<br />
<br />
svn co svn://openfirmware.info/openfirmware<br />
<br />
=== Build OFW ===<br />
<br />
$ cd cpu/x86/pc/biosload/<br />
$ cp config-virtualbox.fth config.fth<br />
$ cd build<br />
$ make floppyofw.img<br />
<br />
The "config-virtualbox.fth" configuration is known to work with QEMU.<br />
Other configurations may work also - but the "qemu-loaded" config<br />
option isn't what you want for this technique, because it's a subcase<br />
of the CoreBoot-payload configuration.<br />
<br />
You will use the "floppyofw.img" output file in a later step.<br />
<br />
=== Make a bootable Floppy Image ===<br />
<br />
$ ../../../Linux/forth fw.dic ../makefloppy.fth<br />
<br />
This creates a file that is a bootable floppy image with an empty<br />
FAT12 filesystem. This step only has to be done once.<br />
<br />
=== Copy OFW onto the Floppy Image ===<br />
<br />
$ mkdir flp<br />
$ sudo mount -t msdos -o loop floppy.img flp<br />
$ sudo cp floppyofw.img flp/ofw.img<br />
$ sudo umount flp<br />
<br />
Copy floppy.img to the QEMU or VirtualBox directory.<br />
<br />
=== Boot OFW from QEMU ===<br />
<br />
$ qemu -L <dir> -boot a -fda floppy.img<br />
<br />
"<dir>" is the directory that contains QEMU's BIOS and VGA BIOS files.<br />
<br />
=== Boot OFW from VirtualBox ===<br />
<br />
The following VirtualBox configuration settings work for me:<br />
<br />
OS Type = Other/Unknown<br />
Base Memory = 64 MB<br />
Video Memory = 8 MB<br />
Boot Order = Floppy, Hard Disk<br />
ACPI = Disabled<br />
IO APIC = Disabled<br />
VT-x/AMD-V = Disabled<br />
PAE/NX = Disabled<br />
Floppy Image = floppy.img<br />
Network Adapter 1 = PCnet-PCI II (host interface, <tap name>)<br />
(other settings are mostly irrelevant)<br />
<br />
=== Recompiling ===<br />
<br />
If you want to make changes and recompile OFW, you need not repeat the<br />
"makefloppy" step; you can just loopback mount the floppy image and<br />
copy the new OFW version to ofw.img .<br />
<br />
== What is on the Floppy Image ==<br />
<br />
The floppy image is a bootable floppy with a FAT12 filesystem. Its first two<br />
sectors contain a simple bootloader program that uses BIOS INT 13 callbacks to<br />
read floppy sectors. The program scans the FAT root directory entries to find<br />
the file "ofw.img", then loads that into memory and jumps to it.<br />
<br />
When you build floppyofw.img, as a side effect it also builds bootsec.img, which<br />
is that simple bootloader. The source code (Forth-style assembly language) is in<br />
biosload/bootsec.fth .<br />
<br />
The "makefloppy.fth" program that creates the image is pretty simple; it copies<br />
bootsec.img to the output file "floppy.img", creates a couple of initially<br />
empty FAT tables, zeros the root directory area, and fills the data area with<br />
zeros.<br />
<br />
== Making a Prototype Floppy Image with Linux Commands ==<br />
<br />
Here's a pair of Linux commands that accomplish the same thing<br />
as makefloppy.fth:<br />
<br />
Step6a $ /sbin/mkdosfs -C -f 2 -F 12 -R 2 -r 224 -s 1 -S 512 floppy.img 1440<br />
Step6b $ dd <bootsec.img of=floppy.img conv=nocreat,notrunc<br />
<br />
The arguments to mkdosfs force the filesystem layout to match the layout that<br />
is specified in the BIOS parameter block in bootsec.img.<br />
<br />
The advantage of makefloppy.fth is that it reads the filesystem layout parameters<br />
from the BPB in bootsec.img, so its guaranteed to be consistent. If bootsec.fth<br />
were edited to change the layout, the arguments to "mkdosfs" would have to change.<br />
(But there's little need to change that layout, since it's a standard floppy<br />
size.)<br />
<br />
The advantage of the Linux command sequence is that it creates a file with<br />
"holes", thus saving disk space for awhile (until something fills in the holes).<br />
<br />
=== Booting on a Real PC from a USB Key ===<br />
<br />
To build for a real PC:<br />
<br />
$ cd openfirmware/cpu/x86/biosload<br />
$ cp config-usbkey.fth config.fth<br />
$ cd build<br />
$ make<br />
<br />
That will create a file named "ofw.c32" that can be booted from a USB key that has "syslinux" installed on it. http://www.911cd.net/forums//index.php?showtopic=21902 has some tips on how to install syslinux.<br />
<br />
Your syslinux.cfg file needs a line that says:<br />
<br />
kernel ofw.c32<br />
<br />
(There is also some support in the source code / config.fth for building a version to boot via Grub, but I haven't tested that for some time, so it might be broken.)</div>Wmbhttps://openfirmware.info/index.php?title=Building_OFW_for_OLPC&diff=399Building OFW for OLPC2008-12-28T10:52:45Z<p>Wmb: OLPC OFW build instructions</p>
<hr />
<div>This page tells how to build the OLPC (One Laptop Per Child) version of Open Firmware. This is the version of OFW that is normally shipped on that machine. You can get precompiled ROMs from http://dev.laptop.org/pub/firmware , so you only need to recompile from source if you want to change something. See http://wiki.laptop.org/go/Firmware for version history.<br />
<br />
=== Software Requirements ===<br />
<br />
* Open Firmware source code<br />
* GCC and GNU make - most versions are okay for building OFW<br />
* IASL (Intel ASL compiler, for compiling ACPI tables) - most Linux distributions have an "iasl" package.<br />
<br />
=== Building Open Firmware ===<br />
<br />
Get the Open Firmware source:<br />
<br />
svn co svn://openfirmware.info/openfirmware<br />
<br />
Build OFW:<br />
<br />
cd openfirmware/cpu/x86/pc/olpc/build<br />
make<br />
<br />
The last line of the compilation output should say something like:<br />
<br />
--- Saving as q2e24.rom<br />
<br />
That tells you the name of the output file. You can install it in your OLPC XO computer by copying that file to a USB FLASH key, inserting the key into the XO, and typing on the XO:<br />
<br />
ok flash u:\q2e24.rom</div>Wmbhttps://openfirmware.info/index.php?title=Building_OFW_for_QEMU&diff=397Building OFW for QEMU2008-12-28T10:16:13Z<p>Wmb: Detailed instructions for using OFW with QEMU.</p>
<hr />
<div>This page tells how to build the x86 version of Open Firmware to run under the QEMU emulator. In this version, OFW replaces QEMU's normal "bios.bin" file, so QEMU boots directly into OFW, without a conventional BIOS. This version supports most of QEMU's I/O capabilities, illustrating some of the things that OFW can do. See the [[#QEMU Options / Things to Try]] section.<br />
<br />
The OFW tree contains a version of the platform-specific "early startup" code that is suitable for initializing QEMU's virtual hardware. The early-startup code for QEMU is as simple as such code can possibly be, because the QEMU core system "hardware" requires no initialization. On real hardware, you must turn on PLLs, configure bus bridges and superIO chips, detect DRAM characteristics and configure memory controllers, and do other complex chipset-dependent things in the early stages of startup. QEMU omits all that "magic" stuff that is outside of generic x86 programming models, so the only system-specific early startup code for QEMU is a simple memory sizing loop.<br />
<br />
In addition to this "direct" version, there are two other ways to run OFW under QEMU:<br />
* You can build OFW as "payload" for Coreboot, so Core boot does the early-startup stuff - see [[OFW as a Coreboot Payload]].<br />
* You can boot OFW from a conventional BIOS - see [[Building OFW to Run Under BIOS]]<br />
<br />
=== Software Requirements ===<br />
<br />
* qemu-0.9.1<br />
* Open Firmware rev. >= 1051<br />
* GCC and GNU make - OFW builds with most versions<br />
<br />
=== Getting QEMU ===<br />
Get QEMU >= 0.9.1 from http://bellard.org/qemu/download.html<br />
<br />
=== Building Open Firmware ===<br />
<br />
Get the Open Firmware source:<br />
<br />
svn co svn://openfirmware.info/openfirmware<br />
<br />
Build OFW:<br />
<br />
cd openfirmware/cpu/x86/pc/emu/build<br />
make<br />
<br />
After make is finished (it shouldn't take long) there should be a file "emuofw.rom" in the build directory. Copy this to your qemu directory.<br />
<br />
<br />
=== Run Your ROM Image ===<br />
<br />
qemu -L . -bios emuofw.rom -hda fat:.<br />
<br />
That is the basic invocation; you should get a console window with OFW running in it. OFW is using the emulated Cirrus graphics display in linear framebuffer mode, not in VGA mode.<br />
<br />
=== QEMU Options / Things to Try ===<br />
<br />
QEMU has lots of options that let you do all sorts of fun things. The following sections illustrate a few of OFW's I/O capabilities.<br />
<br />
==== Memory Size ====<br />
<br />
If you look in OFW's startup banner, you should see "128 MiB memory installed". That is QEMU's default memory size. You can change that by adding "-m NNN" to the qemu command line, for example:<br />
<br />
qemu -L . -bios emuofw.rom -hda fat:. -m 32<br />
<br />
OFW as configured will work with power-of-two size between 32 and 2048 MiB (although my QEMU installation only works up to 1024 MB). Those limits aren't inherent inheret OFW, but rather artifacts of the way this particular "port" is configured.<br />
<br />
==== Hard Disk Images ====<br />
<br />
The command line argument "-hda fat:." as shown above makes the current directory on the host system appear to OFW as an IDE hard disk with a read-only FAT filesystem. You can inspect it with:<br />
<br />
ok .partitions c<br />
ok dir c:\<br />
<br />
The device name "c" is a devalias. You can see the actual device name with:<br />
<br />
ok devalias c<br />
ok devalias<br />
<br />
Instead of that "virtual FAT filesystem", you can make use Linux tools to make a filesystem image. In this example, we'll create a 10 MByte image with a single partition and an ext2 filesystem:<br />
<br />
$ dd if=/dev/zero of=filesystem.img bs=1M count=10<br />
$ /sbin/mke2fs -F filesystem.img<br />
$ dd if=filesystem.img of=fs.img bs=512 seek=1<br />
$ rm filesystem.img<br />
$ /sbin/sfdisk -L -uS -C 10 -H 64 -S 32 fs.img <<EOF<br />
,,L,*<br />
;<br />
;<br />
;<br />
EOF<br />
$ mkdir mnt<br />
$ sudo mount -o loop,offset=512 fs.img mnt<br />
$ # Now copy some files to "mnt"<br />
$ sudo umount mnt<br />
<br />
$ qemu -L . -bios emuofw.rom -hda fs.img<br />
<br />
In the QEMU OFW console window:<br />
<br />
ok dir c:\<br />
<br />
In the recipe above, the total size (10 MiB) appears on the first "dd" line (count=10) and on the "sfdisk" line (-C 10). The sfdisk values for heads (-H 64) and sectors (-S 32) are set so that the cylinder size is 1MiB (64*32*512), making it easy to set the overall size with the cylinders (-C) argument. It is more common to use the maximum values -H 255 -S 63 in order to maximize the possible overall size, but that results in a cylinder size of just under 8M, which isn't quite as easy to work with for this example. The recipe uses two "dd" lines instead of making the image file in one step because the "mke2fs" command doesn't give you the option of skipping the first sector where the partition map has to be located.<br />
<br />
==== Serial Console ====<br />
<br />
You can tell QEMU to emulate a serial port by adding "-serial NAME" to the command line, as with:<br />
<br />
$ qemu -L . -bios emuofw.rom -hda fat:. -serial `tty`<br />
<br />
Then you can tell OFW to use the serial console with:<br />
<br />
ok com1 io<br />
<br />
QEMU has lots of options for directing the emulated serial port to various places, including real serial ports on the host system and network connections to other machines. Read the [http://bellard.org/qemu/qemu-doc.html QEMU documentation] (-serial option) for more information.<br />
<br />
You can configure OFW to use the serial port by default, instead of the graphics screen and emulated PC keyboard. To do so, uncomment the line "create serial-console" in openfirmware/cpu/x86/emu/config.fth and re-execute the "make" command. Serial consoles are convenient because it's usually easy to cut-and-paste Forth code into the window that is acting as the "terminal emulator" for the serial console; you can't paste into QEMU's graphical console.<br />
<br />
==== Networking ====<br />
<br />
OFW has an extensive network stack, supporting many protocols including TFTP, NFS, HTTP (client and server), and Telnet (client and server). Here's an example qemu command line with networking support enabled:<br />
<br />
$ qemu -L . -bios emuofw.rom -hda fat:. -net nic,model=pcnet -net tap<br />
<br />
Consult the [http://bellard.org/qemu/qemu-doc.html QEMU documentation] (the "-net" option) to learn how to configure the "tap" interface to connect through to the real network.<br />
<br />
Here are some OFW networking commands that you might want to try:<br />
<br />
ok watch-net<br />
ok debug-net<br />
ok ping yahoo.com<br />
ok undebug-net<br />
ok ping firmworks.com<br />
ok more http:\\firmworks.com\hello.fth<br />
ok fload http:\\firmworks.com\hello.fth<br />
ok telnetd<br />
telnet://10.20.0.107<br />
<br />
Now start a telnet client on some machine, connecting to the IP address shown.<br />
Quitting the telnet client restores the OFW prompt to the QEMU console.<br />
<br />
ok telnet 10.20.0.5<br />
<br />
Instead of "10.20.0.5", use the hostname or IP address of a telnet server. To exit, type Ctrl-] .<br />
<br />
ok httpd<br />
http://10.20.0.107<br />
<br />
Browse to the URL shown. Type any key on the QEMU console to exit the HTTP server. In addition to static pages, the HTTP server can do server-side scripting with Forth, and of course you do client-side scripting by serving up Javascript or Java pages. This facility has been used for an interactive embedded system with a Web interface programmed entirely in Open Firmware - a multi-headed high-speed camera for real-time analysis of golf clubs and golf swings.<br />
<br />
OFW also supports IPV6 networking, but it's not compiled into this version.<br />
<br />
You can, of course, boot operating systems over the network, using TFTP, NFS, or HTTP.<br />
<br />
==== Graphics ====<br />
<br />
OFW uses the display in linear framebuffer mode, so it can display 2D graphics. To see a simple demo:<br />
<br />
ok fload http:\\firmworks.com\testrect.fth<br />
<br />
To clear the screen afterwards:<br />
<br />
ok page<br />
<br />
OFW has a graphical menu system that is not enabled in this configuration. You can navigate it with either the mouse or the keyboard. OFW can display .BMP files.<br />
<br />
==== USB ====<br />
<br />
To make QEMU emulate a USB mass storage device, do this:<br />
<br />
$ qemu -L . -bios emuofw.rom -hda fat:. -usbdevice disk:fat:.<br />
<br />
Then, in OFW:<br />
<br />
ok probe-usb<br />
ok dir u:\<br />
<br />
"p2" is an alias for "probe-usb" for us lazy people. Since OFW tries not to do stuff "behind your back", if you plug in a new USB device, you must tell OFW to rescan the USB bus. In this case, it will have already scanned the device (it does that automatically at startup), but rescanning is a convenient way to get OFW to show you what is there. You could instead say:<br />
<br />
ok show-devs usb<br />
<br />
but "p2" is easier to type.<br />
<br />
In the qemu command, you could attach a writable disk image with, for example:<br />
<br />
$ qemu -L . -bios emuofw.rom -hda fat:. -usbdevice disk:fs.img<br />
<br />
assuming that you have created a suitable fs.img file as per the instructions above. You can't use the same writable image for both -hda and -usbdevice, but it's okay to use the same read-only image (as with the fat:<directory> syntax) for both.<br />
<br />
OFW has reasonably good support for a wide selection of USB mass storage devices - flash keys, disks, CDROMs, multi-card readers, etc. OFW also supports USB keyboards, but I haven't yet figured out how to make that work under QEMU. OFW supports some USB 2.0 network interfaces and some USB-to-serial adapters. You might be able to make those work using QEMU's ability to connect to real USB devices on the host. On real hardware, OFW supports UHCI (USB 1.1), OHCI (USB 1.1), and EHCI (USB 2.0) host controllers.<br />
<br />
==== Sound ====<br />
<br />
To enable sound support in QEMU, do this:<br />
<br />
$ qemu -L . -bios emuofw.rom -hda fat:. -soundhw sb<br />
<br />
In OFW:<br />
<br />
ok select /sound<br />
ok d# 200 d# 2000 tone<br />
ok unselect<br />
<br />
That plays a 200 Hz sine wave for 2 seconds (2000 mS). OFW can also play .wav files, but that's not included in this configuration.<br />
<br />
QEMU has a lot of options to control the sound emulation; read the documentation to get totally confused.<br />
<br />
OFW's SoundBlaster driver, as included in this configuration, is rather rudimentary. OFW has better drivers for the more common AC97 sound hardware.<br />
<br />
<br />
__NOEDITSECTION__</div>Wmbhttps://openfirmware.info/index.php?title=Open_Firmware&diff=379Open Firmware2008-12-28T08:11:08Z<p>Wmb: Updated with new information and links to version-specific build instructions</p>
<hr />
<div>== Introduction ==<br />
<br />
In 2006 the company of Open Firmware inventor Mitch Bradley, [http://firmworks.com/ Firmworks, Inc], released their Open Firmware implementation (OFW) under a BSD license. This code shares some code with SUN's OpenBOOT implementation. The open source OFW supports x86, PowerPC, and ARM architectures. Other architectures, including SPARC and MIPS, may be added as time and interest dictate.<br />
<br />
The x86 version is used on the OLPC "XO" computer. The x86 version can be configured for numerous other environments, including<br />
* Direct QEMU ROM (replacing the "bios.bin" that is supplied with QEMU<br />
* Coreboot payload<br />
* Loadable on directly on top of a conventional PC BIOS (booted from floppy or hard disk like an OS). In this configuration it can run on an arbitrary PC, or on an emulator like QEMU, VirtualBox, or VMWare.<br />
<br />
OFW can boot Linux directly from a disk file (FAT, ext2, ISO9660, or jffs2 filesystems) without the need for an intermediate bootloader like LILO or GRUB. The Linux image can be in either ELF format (as created by the first phase of the Linux kernel compilation process) or in the "bzImage" format that "wraps" the ELF image. When booting an ELF image, OFW can read the ELF symbol table so OFW's assembly language debugger can resolve kernel symbols.<br />
<br />
OFW can also boot other ELF standalone images, providing to them rudimentary "libc" capability. That facility has been used for booting, for example, Minix, ReactOS, Plan9, Inferno and SqueakNOS. The OLPC system ROM includes several such "standalone client programs", including MicroEMACS, memtest86, and NANDblaster (a facility for fast OS updates over multicast wireless).<br />
<br />
On the OLPC system, OFW emulates enough legacy BIOS "real mode INTs" to boot Windows XP. On another system, OFW supports booting Windows CE.<br />
<br />
== Download ==<br />
<br />
You can [http://tracker.coreboot.org/trac/openfirmware/browser browse the source code online].<br />
<br />
The repository is available through Subversion:<br />
<br />
You can check it out as follows:<br />
$ svn co svn://openfirmware.info/openfirmware/<br />
<br />
if you want a specific revision: <br />
$ svn co svn://openfirmware.info/openfirmware -r 35<br />
<br />
If your company installed a firewall that blocks the svn port (3690) you can also check out using the webdav frontend:<br />
<br />
$ svn co <nowiki>https://www.openfirmware.info/openfirmware-svn/ openfirmware</nowiki><br />
<br />
==Building Different Versions==<br />
<br />
* Direct QEMU ROM: see [[Building OFW for QEMU]]<br />
* Coreboot: see [[OFW as a Coreboot Payload]]<br />
* OLPC: see [[Building OFW for OLPC]]<br />
* BIOS-loaded: see [[Building OFW to Run Under BIOS]]<br />
<br />
== Mailing List ==<br />
<br />
There's an Open Firmware mailing list at:<br />
<br />
* http://www.openfirmware.info/mailman/listinfo/openfirmware.<br />
<br />
The mailing list archive is also available:<br />
<br />
* http://www.openfirmware.info/pipermail/openfirmware/</div>Wmbhttps://openfirmware.info/index.php?title=OFW_as_a_Coreboot_Payload&diff=395OFW as a Coreboot Payload2008-12-28T05:09:22Z<p>Wmb: Fixed a typo</p>
<hr />
<div>This page tells how to build Open Firmware as a Coreboot payload and run it under QEMU. You can also run Open Firmware under QEMU without Coreboot:<br />
* You can build a QEMU ROM image directly from code in the OFW tree - see [[Building OFW for QEMU]].<br />
* You can boot OFW from a conventional BIOS - see [[Building OFW to Run Under BIOS]]<br />
<br />
=== Software Requirements ===<br />
<br />
* qemu-0.9.1<br />
* Open Firmware rev. >= 1051<br />
* coreboot >= v2<br />
* GCC and GNU make - OFW builds with most versions; I'm not sure which versions Coreboot needs<br />
<br />
=== Building Open Firmware ===<br />
<br />
Download the Open Firmware source:<br />
<br />
svn co svn://openfirmware.info/openfirmware<br />
<br />
Configure OFW for Coreboot:<br />
<br />
cd openfirmware/cpu/x86/pc/biosload<br />
cp config-coreboot.fth config.fth<br />
<br />
Build OFW:<br />
<br />
cd build<br />
make<br />
<br />
After make is finished (it shouldn't take long) there should be a file "ofwlb.elf" in the same directory. Copy this to your coreboot-v[x] directory.<br />
<br />
=== Building coreboot ===<br />
Follow the instructions in the coreboot documentation, using ofwlb.elf as your payload file.<br />
<br />
=== Getting QEMU ===<br />
Get QEMU >= 0.9.1 from http://bellard.org/qemu/download.html<br />
<br />
Version 0.9.1 should "just work". It supports reasonably large ROM images, determining the emulated ROM size from the size of the image file. There was a "qemu_biossize.patch" for qemu-0.9.0, but the site that hosted that patch is defunct.<br />
<br />
=== Run Your ROM Image ===<br />
<br />
qemu -L coreboot-v3/build -hda path/to/disk.img -serial `tty` -nographic<br />
<br />
=== Ideas for Improvement ===<br />
<br />
These instructions build a rather plain OFW configuration that lacks drivers for several of QEMU's specific I/O devices (Ethernet, video, sound). Suitable drivers are in the OFW tree, and are included in the QEMU build described in [[Building OFW for QEMU]]. It would be nice to add those drivers to the configuration described herein. If the Cirrus video driver were added, qemu could be used in graphic mode.<br />
<br />
<br />
__NOEDITSECTION__</div>Wmbhttps://openfirmware.info/index.php?title=OFW_as_a_Coreboot_Payload&diff=394OFW as a Coreboot Payload2008-12-28T05:08:02Z<p>Wmb: Moved Coreboot+OFW instructions to a separate page</p>
<hr />
<div>This page tells how to build Open Firmware as a Coreboot payload and run it under QEMU. You can also run Open Firmware under QEMU without Coreboot:<br />
* You can build a QEMU ROM image directly from code in the OFW tree - see [[Building OFW for QEMU]].<br />
* You can boot OFW from a conventional BIOS - see [[Building OFW to Run Under BIOS]]<br />
<br />
=== Software Requirements ===<br />
<br />
* qemu-0.9.1<br />
* Open Firmware rev. >= 1051<br />
* coreboot >= v2<br />
* GCC and GNU make - OFW builds with most versions; I'm not sure which versions Coreboot needs<br />
<br />
=== Building Open Firmware ===<br />
<br />
You need . Most versions will work.<br />
<br />
Download the Open Firmware source:<br />
<br />
svn co svn://openfirmware.info/openfirmware<br />
<br />
Configure OFW for Coreboot:<br />
<br />
cd openfirmware/cpu/x86/pc/biosload<br />
cp config-coreboot.fth config.fth<br />
<br />
Build OFW:<br />
<br />
cd build<br />
make<br />
<br />
After make is finished (it shouldn't take long) there should be a file "ofwlb.elf" in the same directory. Copy this to your coreboot-v[x] directory.<br />
<br />
=== Building coreboot ===<br />
Follow the instructions in the coreboot documentation, using ofwlb.elf as your payload file.<br />
<br />
=== Getting QEMU ===<br />
Get QEMU >= 0.9.1 from http://bellard.org/qemu/download.html<br />
<br />
Version 0.9.1 should "just work". It supports reasonably large ROM images, determining the emulated ROM size from the size of the image file. There was a "qemu_biossize.patch" for qemu-0.9.0, but the site that hosted that patch is defunct.<br />
<br />
=== Run Your ROM Image ===<br />
<br />
qemu -L coreboot-v3/build -hda path/to/disk.img -serial `tty` -nographic<br />
<br />
=== Ideas for Improvement ===<br />
<br />
These instructions build a rather plain OFW configuration that lacks drivers for several of QEMU's specific I/O devices (Ethernet, video, sound). Suitable drivers are in the OFW tree, and are included in the QEMU build described in [[Building OFW for QEMU]]. It would be nice to add those drivers to the configuration described herein. If the Cirrus video driver were added, qemu could be used in graphic mode.<br />
<br />
<br />
__NOEDITSECTION__</div>Wmb