Beginning Open Firmware debugging techniques, Part III: Bootstrapping an Operating System

"Beginning Open Firmware debugging techniques, Part II: Hardware Identification" and its prerequisites.

System Requirements:

An Open Firmware equipped computer. Included examples will use Apple hardware.

Well, there isn't anything here yet. All this tutorial contains at this time is the answers to the previous tutorial's Advanced Exercises.

Advanced Exercises: /memory

The available memory in OF 1.0.5 was not contiguous immediately after boot. What would be present in memory, and how large is it?

OF 1.0.5 will load itself to 0x400000 when real-base is set to -1. It is 1M is size.

A quick review of the configuration variables again:

Empty
_
hex printenv<return>

little-endian?      false               false
real-mode?          false               false
auto-boot?          false               true
diag-switch?        false               false
fcode-debug?        false               false
oem-banner?         false               false
oem-logo?           false               false
use-nvramrc?        false               false
real-base           -1                  -1
real-size           100000              100000
virt-base           -1                  -1
virt-size           100000              100000
load-base           600000              4000
pci-probe-list      -1                  -1
screen-#columns     64                  64
screen-#rows        28                  28
selftest-#megs      0                   0
boot-device         /AAPL,ROM           /AAPL,ROM
boot-file
diag-device         fd:diags            fd:diags
diag-file
input-device        ttya                ttya
output-device       ttya                ttya
oem-banner
oem-logo
nvramrc
boot-command        boot                boot
 ok
Empty
_

As discussed in the PowerPC CPU Binding for 1275-1994, real-base is defined to be the location that Open Firmware loads to, using real-size of memory. When real-base is set to -1, OF chooses where to load itself into memory from its ROM. Since this session is immediately after booting and in the OF console, the only thing in memory is OF, and therefore the 1M block at 0x4M must be Open Firmware. This is a quirk of OF 1.0.5, placing OF in the middle of the physical memory, and later versions of OF loaded itself into the last 1M of physical memory, well out of the way. Part III discusses this aspect more in-depth.

The memory in OF 3.0 on the AGP G4 has two regions in the "reg" property. Why?

Segments on PowerPC are 256M.

Neither the start nor ending address of the "available" region match the "reg" property. What would be present below the start of the available memory, and what would be present above the available memory?

Exception handlers are below 0x3000 and OF 3.0 loads in the last 1M of memory.

Advanced Exercise: split input and output

Using input, output and io, have input go to one console device and output go to another. For example, on Apple hardware with serial ports, have the output go to the monitor and the input come from the serial port. On Apple hardware without serial ports, have output go to the monitor but the input come from a telnet session.

On a Mac w/o serial:

" screen" output<return>
" enet:telnet,192.168.10.99" input<return>

will turn off the monitor as as soon as a telnet session to 192.168.10.99 is established. Output will continue, including echo, on the monitor.

Advanced exercise - memory and strings:

Repeat the process of moving a string into a buffer, using value to store the string length.

Empty
_
" testing" dup value len buffer: myBuf myBuf len move myBuf len type<return> testing ok
Empty
_

The breakdown: [graphic?]

encode the string "testing"
duplicate the length parameter return by "
move the duplicated length value into the variable len
using the original length value, create a buffer named myBuf
add the address myBuf to the stack
add the value len to the stack
the string address returned by " is bottom most on the stack
move the contents of the string address to the buffer address

At this point, the process is done. The last three words test the results:

add the address myBuf to the stack
add the value len to the stack
call type to display the string

Repeat the process of moving a string into a buffer, using over ( x1 x2 -- x1 x2 x1 ).

The use of over simplifies the process by repeating specific returned values, placing them at the top of the stack.

Advanced Exercise: controlling devices remotely

While in a telnet or serial session, send text to the display device.

For later OF versions:

myBuf len " write" " screen" open-dev $call-method<return>

For OF 1.0.5 and others that do not implement the screen alias (using a 7300 as an example):

myBuf len " write" " /chaos/control" open-dev $call-method<return>