http://mcosre.sourceforge.net/docs/open_firmware/of_misc.html
12/5/2007

Open Firmware: Miscellaneous

 


[Home] | [About McOS Re] | [FAQ] | [Changes] | [Progress] | [Documentation] | [Links]


 
Some Info on the OF Enigma

Open Firmware is used in the PCI Power Macs. It provides a generic way for devices to tell software (the OS) how to use them (the devices). Open Firmware also has the nifty feature of being able to do stuff like bootp and tftp, providing us with a way to get the kernel into memory. (There have been reports of partial success at getting OF to load a vmlinux.coff off of a floppy.)

Here's how you read forth code by example. Say you wanted to know everything about what the forth word "ls" did...

0 > ' ls ok
1 > . -7E2EE0 ok

-7E2EE0 is the forth execution token for "ls". The execution token is an address (32-bit, signed) of where in memory the fcode/machine-code lives. This is very reminiscent of AppleSoft Basic, where you would memorize signed decimal 16-bit "CALL" ROM routines (like the infamous CALL -151), only in hex, because the negative number is shorter, since the ROM is towards the end of memory.

Note: you can use "u." instead of "." if you want to print it as an unsigned number ($FF81D120 here). To print as a decimal number, use ".d".

OK. Now, if you wanted to "see" the forth code for "ls", you'd do:

0 > see ls

...and you would see the forth code. This is the equivalent of:

0 > -7e2ee0 (see)

or

0 > ff81d120 (see)

It's all the same thing. Now, many methods are themselves made up of other compiled fcode routines, which are indicated by a ^ followed by the negative hex address. You can use (see) to traverse nested fcode routines in this manner. If you are following a particular execution token (i.e. address), to another, to another, and end up simply with "code ^-12345678" (or whatever address), this means that a machine code routine is being called at that address. Fcode routines are frequently combined with machine code routines that handle the lower level device oriented stuff.

OF Gotchas

  • We don't appear to have a built-in disassembler in OF! Attempting to use the "dis" word just lists it out in hexadecimal! I'm assuming this unfortunate circumstance is what prompted the creation of xmon. We really got the short end of the stick with OF. OK, you say, I know the address of a routine in ROM now, so I want to boot up some OS and use my favorite disassembler. This leads to the second problem...
  • The OF memory appears to be remapped after you boot! It's probably just a matter of figuring out to where, since the contents of a given address in OF memory doesn't match what you see when you look in Linux or Mac OS. This is what leads me to believe it's getting switched out or remapped.

    PPC-Linux reclaims the 1MB of RAM used by OF at a relatively early stage in the startup process. It's done in mem_init in arch/ppc/mm/init.c, in the section starting with the comment /* free the prom's memory */ and ending with the statement prom_trashed = 1. You could put #if 0 ... #endif around this if you wanted to look at OF's memory later.