diff options
Diffstat (limited to 'README')
| -rw-r--r-- | README | 217 |
1 files changed, 17 insertions, 200 deletions
@@ -1,14 +1,12 @@ -Slimline Open Firmware for JS20
+Slimline Open Firmware - SLOF
-Copyright (C) 2004,2005 IBM Corporation
+Copyright (C) 2004, 2007 IBM Corporation
Index
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1.0 Introduction to Open Firmware
-1.1 Slimline Open Firmware
-1.2 Build process
-1.3 Load process
+1.1 Build process
2.0 Extension
3.0 Limitations
@@ -33,55 +31,8 @@ processor Instruction Set Architectures (ISAs) and buses. The full documentation of this Standard can be found in [1].
-1.1 Overview
-++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
-The Slimline Open Firmware (SLOF) is an implementation of the
-Open Firmware standard. Since the Open Firmware standard is
-quite extensive, the decision was made to keep focus on those
-parts of the standard which are required for booting Linux.
-As of today, it is possible to boot a recent Linux kernel (2.6.10)
-on a JS20 board and on a cell workstation. Booting SLOF on a
-machine requires a hardware-specific Low Level Firmware for
-doing the basic setup of the system which is not part of this
-package. The LLFW package as object code might be provided on
-a separate purposes for test purposes.
-
-The current restrictions and shortcomings regarding the
-Open Firmware Standard are listed here:
-
-+ User Interface
- - Command line editing: only the most basic command line editing
- (enter, backspace) is supported.
- - The assembler support words are not implemented. This is by design.
- - None of the administration group is provided; instead, there are some
- more minimalistic facilities.
- - There is no direct support for debugging client programs.
-+ Client Interface
- - "test" and "canon" are missing.
- - "boot", "enter", and "chain" are missing.
- - "interpret" doesn't actually do anything.
- - "set-callback" and "set-symbol-lookup" are missing.
- - "milliseconds" doesn't use anything resembling a real clock.
-+ Device Interface
- - FCode evaluator is under development and not available so-far.
- - Finding device nodes does not use the proper algorithm; instead, first
- all nodes are tried for an exact match on the full path; if that fails,
- all nodes are tried for an exact match on the short name.
- Arguments to a node are ignored. Nodes do not really have an address.
- - There is no terminal emulator. But then again, there is no graphics
- hardware either.
-
-
-As boot device currently only ATA disk is supported, by using yaboot
-as secondary boot loader. Netboot and USB boot support will not be made
-available and is not part of this package. It is possible to port external
-available secondary boot loader to the PowerPC64 architecture to support
-network boot based on existing Linux device drivers.
-
-
-
-1.2 Build process
+1.1 Build process
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Open Firmware (OF) is based on the programming language Forth.
@@ -136,65 +87,10 @@ Firmware to it's location in memory (see 1.3 Load process). Additionally a secondary boot loader or any other client application can be bound
to the code as payload.
-The Open Firmware image will be bound together with the Low Level
-Firmware to the final slof.img.
-
The Low Level Firmware (LLFW) is responsible for setting up the
system in an initial state. This task includes the setup of the
CPUs, the system memory and all the buses as well as the serial port
-itself. The current distribution does not contain a LLFW image,
-which is hardware specific and has to be implemented for the each
-board SLOF should run on. Publication of an object code only LLFW
-for the JS20 board might be available in the future.
-
-Firmware image:
-
-0x2000000 +----------+
- | LLFW |
-X +----------+
- | Loader |
-X + 0x100 +----------+
- | Vector |
-X + 0x4100 +----------+
- | |
- | OF code |
- | |
-X + 0x6100 +----------+
- | |
- | OF data |
- | |
- +----------+
-
-
-1.3 Load process
-++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
-
-This chapter describes the load process on the JS20 board.
-The whole firmware image resides in the flash. The reset is
-triggered by the service processor and both CPUs will jump into
-the LLFW code. After appropriate system setup, the LLFW will load the
-whole image into L2 cache at the link address of the image.
-The LLFW will jump into the OF loader in L2 cache, after it has
-ended it's task of doing base initialization of the system
-(e.g. probing memory and setting up the memory controller).
-The loader code will then move the system vectors, the OF
-core engine and the OF data to the location those parts are
-linked at.
-
-The current addresses and offsets are listed in the following table:
-
- | Runtime address | Link address | Offset in Image |
--------+-----------------+--------------+-----------------+
-LLFW | 0x2000000 | 0x2000000 | 0 |
-Loader | 0x200xxxx | any | + sizeof(LLFW) |
-Vector | 0x100 | 0x100 | + 0x100 |
-OFW | 0x1110000 | 0x1110000 | + 0x4000 |
-Dict | 0x1120000 | 0x1120000 | + 0x2000 |
--------+-----------------+--------------+-----------------+
-
-
-
-
+itself.
2.0 Extension
@@ -205,8 +101,6 @@ new primitive words (i.e., words implemented not by building pre-existing Forth words together, but instead implemented in
C or assembler). With this, it is possible to adapt SLOF to
the specific needs of different hardware and architectures.
-We'll also discuss how to add an extra payload, and what is
-required of the LLFW to successfully run SLOF.
To add primitives:
@@ -230,103 +124,26 @@ To add primitives: the Forth engine can be appropriately manipulated.
-To add an extra payload:
-
- It is possible to add client code (secondary boot loader, OS kernel)
- into the data section of SLOF. This will allow to execute a client
- without the need to load it from a device. Any client is required to
- be an ELF executable, and to adhere to the client interface as
- described in the standard, plus the PowerPC binding to the standard.
-
- The steps to add a new payload to SLOF are:
-
- + Add a rule in the SLOF Makefile to convert the client executable into
- a binary.
-
- - payloadbin.o: payload
- $(LD) -o $@ -r -bbinary $<
- paflof: .... payloadbin.o
- $(LD) .... payloadbin.o
-
-
- + Add in <arch>.h a line defining the entry point of the client.
- The name is generated by the linker by surrounding the input
- filename with "_binary_" and "_start".
-
- - extern char _binary_payload_start[];
-
- + Add in <arch>.in a line defining the Forth constant to access the
- start of the client.
-
- - con(PAYLOAD (type_u)_binary_payload_start)
-
- + Add in the main Forth file a colon definition to load and start
- the client.
-
- - : payload-exec payload dup load-elf-file start-elf ;
-
-
-Change Low Level Firmware:
-
- The low level firmware needs to setup the basic execution environment
- required by the rest of the system. The only link from
- LLFW to SLOF is the call to the SLOF loader, which itself is
- position independent. The last thing the LLFW should do is jump to
- the first instruction in the loader image. SLOF also has calls into
- code, that provides certain system specific information like the memory
- size or triggers for board specific actions, like reboot of the board.
- This code is currently implemented for JS20 as object code only module
- and not part of this distribution. For any different board this code
- needs to be provided.
-
-Change oco module:
-
- This file encapsulates functions supposed to be
- confidential and not made public.
- The prototype for this interface is
- type_u oco(cell p0, cell p1)
- p0 is the token and p1 the argument passed to the specific function.
- Current functions for the JS20 board are:
- Token 0: Start slave cpu
- Token 1: Reboot system
- Token 2: Halt system
- Token 3: Watchdog command
- Token 4: Get memory size
- Token 5: Enable ht apic space
- Token 6: Enable MPIC
- Token 7: Get own cpu number
- For other boards this might be different depending on the board
- specific requierements.
-
3.0 Limitations of this package
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
- - RTAS is not available in this package. The client application
- has to manage hardware on its own. It is also not possible to
- power down the machine from linux. RTAS calls can be added if
- required.
+ On a JS20 the memory setup is very static and therefore there are
+ only very few combinations of memory DIMM placement actually work.
+
+ Known booting configurations:
- - SLOF has no support for NVRAM, so it is not possible to start the
- operating system without user interaction.
+ * 4x 256 MB (filling all slots) -- only "0.5 GB" reported.
+ * 2x 1 GB, slots 3/4 -- only "0.5 GB" reported.
- - The hardware real time clock is not correctly updated after system
- shutdown. That leads to problems restoring the right system time
- after booting. One possible solution is to set the system time early
- after the OS bootup from a network time server via the NTP protocol.
+ Known failing configurations
- - It is sometimes possible, that the "other-firmware" switchback
- function does not work properly. This is due to hardware limitations.
- The work around is to issue the command to the firmware until the
- original firmware starts. (Should take at most 3 tries to reactivate
- the old firmware)
+ * 2x 256 MB, slots 3/4
+ * 2x 256 MB, slots 1/2
- - The /etc/yaboot.conf file must reside on the 3rd partiton on the 1st
- hard drive in the system. If /etc/yaboot.conf is on another partition
- in fs/main.fs the line
- s" disk:3" encode-string s" bootpath" set-chosen
- has to be change accordanly. This also can be done temporaly by typing
- "set-bootpath x", where x is the partition number.
+ On a JS20 SLOF wil always report 0.5 GB even if there is much more memory
+ available.
+ On a JS21 all memory configurations should work.
Documentation
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
|