mirror of
https://gitlab.com/qemu-project/openbios.git
synced 2024-02-13 08:34:06 +08:00
aac2f06b44
I've been trying to get old versions of SunOS to load under qemu. In doing so, I've encountered a number of bugs in OBP. I'm not always certain of the best fix, but I can at least provide a quick hack that will get people farther along. 1) Error message: "kmem_alloc failed, nbytes 680" Bug: obp_dumb_memalloc is a bit too dumb. It needs to pick an address if passed a null address. (According to the comment in the allocator in OpenSolaris prom_alloc.c (see <http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/psm/promif/ieee1275/sun4/prom_alloc.c>), "If virthint is zero, a suitable virt is chosen.") Quick fix: If passed a null address, start doling out addresses at 10MB and increment by size. Shortcomings: The quick fix ignores the issue of free() and doesn't remove memory from the virtual-memory/available node. After the quick fix, the boot gets farther, leading us to: 2) Error message: "Unhandled Exception 0x00000080" Bug: Trap 0 (entry 0x80 in the table, i.e. syscall_trap_4x) is undefined. This is because the SunOS bootloader installs the trap by writing code in the trap table, but the trap table is in the .text section of OpenBIOS. Thus the trap 0 handler simply jumps to "bug". Quick fix: Move the trap table to the .data section. Insert a "b entry; nop; nop; nop;" before "bug:". Shortcomings: Requires the extra "b entry" code. Allows the only VM copy of the trap table to be permanently changed. OpenBIOS should copy the read-only trap table to read-write memory (and update %tbr) upon reset/entry. 3) #2 above actually exposes another bug. The write to the read-only trap table does not cause an access violation -- instead, it silently fails. The "std" instruction at 0x403e6c in the bootloader has no effect. Bug: Uncertain. It could be a systemic bug in qemu, but it appears that the VM's MMU believes that the page is writable. That means that the VM's MMU is not having the access protection flags set for pages mapped to ROM. It thinks everything is rwx. Fix?: The VM's MMU should have the access protection flags properly set for each ROM section. This should probably be done within OpenBIOS. E.g., .text should be r-x, .data should probably be rwx, etc. This is the one fix I'm really not sure how to implement. Any suggestions? This may be a problem that only affects this bootloader, so fixing #2 above may be all that's strictly necessary. But I'm not positive that this bug doesn't have other ill effects I haven't found yet. At any rate, fixing #2 gets us still further, to: 4) Error messages: "obp_devopen(sd(0,0,0):d) = 0xffd8e270 obp_inst2pkg(fd 0xffd8e270) = 0xffd57f44 obp_getprop(0xffd57f44, device_type) (not found)" Bug: The OpenBIOS "interpose" implementation is not transparent to non-interposition-aware code (in violation of the interposition spec). The inst2pkg call in this sequence returns the phandle for /packages/misc-files, instead of the proper phandle. Quick fix: Comment out the "interpose disk-label" lines in ob_sd_open. Shortcomings: It disables disk-label. The correct fix is to fix the underlying problem with interposition, but I'm not sure exactly what it is. Could someone help? Fixing #4 gets us quite a bit further, until: 5) Error message: "Unhandled Exception 0x00000009 PC = 0xf0138b20 NPC = 0xf0138b24 Stopping execution" Bug: The instruction is trying to read from 0xfd020000+4, which is an invalid address. This address isn't mapped by OBP by default on Sun hardware, so the bootloader must be trying to (a) map this address and failing silently or (b) skipping the mapping for some reason. The instruction is hard-coded to look at this absolute address. Fix: Unknown. This may be another instance of writes silently failing, hence my interest in #3 above. It could also be a side-effect of the quick fix for #4. 6) Error message: "BAD TRAP: cpu=0 type=9 rp=fd008f0c addr=feff8008 mmu_fsr=3a6 rw=2 MMU sfsr=3a6: Invalid Address on supv data store at level 3 regs at fd008f0c: psr=4400fc7 pc=f00053f4 npc=f00053f8 ..." Bug: Real sun4m hardware registers 4 CPU-specific interrupts followed by a system-wide interrupt, regardless of the number of CPUs installed. The same is true of counters. SunOS looks at the 5th interrupt for the system-wide interrupt. OBP, since there's only one CPU, just sets up one CPU-specific interrupt followed by the system-wide interrupt, so there is no 5th interrupt. See the comment on "NCPU" at <http://stuff.mit.edu/afs/athena/astaff/project/opssrc/sys.sunos/sun4m/devaddr.h>. Fix: in obp_interrupt_init() and obp_counter_init() register 4 CPU-specific interrupts before allocating the system-wide interrupt. The kernel will then map the 5th interrupt to the system-wide interrupt. 7) Error message: "BAD TRAP: cpu=0 type=9 rp=fd008d8c addr=7ff000 mmu_fsr=126 rw=1 MMU sfsr=126: Invalid Address on supv data fetch at level 1 regs at fd008d8c: psr=4000cc4 pc=f01339a4 npc=f01339a8 ..." Bug: The command-line arguments passed to the kernel are fixed at address 0x7FF000 (CMDLINE_ADDR, passed from qemu via nv_info.cmdline), which is no longer mapped by the time the kernel looks at the boot arguments. A regular Sun boot ROM will copy this into mapped memory. Fix: Copy the string in nv_info.cmdline to a OpenBIOS global (since OpenBIOS continues to be mapped) in ob_nvram_init(). 8) Error message: "BAD TRAP: cpu=0 type=9 rp=fd008dec addr=1019000 mmu_fsr=126 rw=1 MMU sfsr=126: Invalid Address on supv data fetch at level 1 regs at fd008dec: psr=4400cc5 pc=f0131680 npc=f0131684 ..." Bug: The dumb memory allocator from bug #1 was allocating a range that the SunOS 4 kernel doesn't like. Fix: Mimic the Sun boot ROM allocator: the top of the heap should be a 0xFFEDA000 and allocations should return descending addresses. So, for example, if asking for 0x1000 bytes, the first returned pointer should be 0xFFED9000. 9) Error message: "BAD TRAP: cpu=0 type=9 rp=fd008d2c addr=b1b91000 mmu_fsr=126 rw=1 MMU sfsr=126: Invalid Address on supv data fetch at level 1 regs at fd008d2c: psr=4900cc3 pc=f0142c04 npc=f0142c08 ..." Bug: The precise underlying cause isn't clear. The bug appears due to a variation between OBP's behavior and stock Sun behavior. Fix: Add the "cache-physical?" property to the CPU node in ob_nvram_init() and bump the "mmu-nctx" property up to 4096 (from 256). git-svn-id: svn://coreboot.org/openbios/openbios-devel@114 f158a5a8-5612-0410-a976-696ce0be7e32
Welcome to OpenBIOS
-------------------
OpenBIOS is a free, portable implementation of IEEE 1275-1994
(Open Firmware). Find detailed information about OpenBIOS at
http://www.openbios.org/
What is OpenBIOS?
-----------------
OpenBIOS can replace your system firmware (BIOS) partly or completely. It
can also be used as a bootloader to create an Open Firmware compatible
interface between legacy firmware and an operating system.
This is achieved by a modular concept that consists of a portable Forth
kernel and three interfaces for user interaction, device initialization
and client (operating system) control.
While far not all possible applications of OpenBIOS are implemented yet,
a lot of functionality is already there. OpenBIOS can be used to enhance
LinuxBIOS (http://www.linuxbios.org), or be booted from any multiboot
capable bootloader to bring Open Firmware to your machine. OpenBIOS can
also be used when an operating system is already running. It provides
the needed OpenFirmware functionality to MOL (MacOnLinux) to boot MacOS
9 and X on PPC machines, as well as Linux (all supported platforms)
OpenBIOS build options
---------------------
config/scripts/switch-arch <platform> - build for specified platform
Look in config/example for
platforms.
make - build all configured binaries
make run - run unix example.
How OpenBIOS works
------------------
The OpenBIOS forth core is split into a forth kernel written in portable
C and a forth dictionary which operated on by the kernel.
When building the forth core, you get different versions of
the forth kernel:
* a unix executable program
- to execute a forth dictionary from a file. This can be used for
easily testing and developing OpenBIOS on a unix host.
- to create a dictionary file. Such a dictionary file sets up
all of the forth language. Primitives are indexed to save relocations.
The default is to create a forth dictionary forth.dict from
forth/start.fs. This file includes all of the basic forth language
constructs from forth/bootstrap.fs and starts the interpreter.
To achieve this, the hosted unix version contains a basic set of
forth words coded in C that allow creating a full dictionary.
* a varying number of target specific binaries. On x86 you can start
openbios for example from GRUB or LinuxBIOS. They are all based on
the same forth engine consisting of a dictionary scheduler, primitive
words needed to build the forth environment, 2 stacks and a simple
set of console functions. These binaries can not be started directly
in the unix host environment.
Requirements
------------
* gcc
* gnu make
* OpenBIOS FCode Utils
Download with svn co svn://openbios.org/openbios/fcode-utils
* grub or any other multiboot loader to run the multiboot
binary "openbios.multiboot" with it's module "openbios-<platform>.dict"
* xsltproc
Building & Usage
----------------
* make
this builds "openbios.multiboot", the standalone image and "openbios-unix",
the hosted image. Additionally it creates a forth dictionary
file from forth/start.fs. All generated files are written to
the absolute directory held by the variable BUILDDIR, which defaults
to obj-[platform]. Some compile time parameters can be tweaked in
include/config.h
* use "openbios-unix" to create a forth dictionary on your own:
$ obj-x86/openbios-unix -Iforth start.fs
creates the file forth.dict from forth source forth/start.fs.
* use "openbios-unix" to run a created dictionary:
$ obj-x86/openbios-unix obj-x86/openbios-unix.dict
This is useful for testing
* booting openbios
You can boot openbios i.e. in grub. Add the following lines to
your menu.lst:
title openbios
kernel (hd0,2)/boot/openbios.multiboot
module (hd0,2)/boot/openbios-x86.dict
Note: change (hd0,2) to the partition you copied the openbios image and
openbios-x86.dict to.
To boot OpenBIOS from LinuxBIOS/etherboot, you can either use
"openbios-plain.elf" or "openbios-builtin.elf":
- openbios-plain.elf is the pure kernel that loads the dictionary from a
hardcoded address in flash memory (0xfffe0000)
- openbios-builtin.elf also includes the dictionary directly so that it
can be easily used from etherboot or the LinuxBIOS builtin ELF
loader without taking care of the dictionary
CREDITS
-------
OpenBIOS was developed by Stefan Reinauer, Samuel Rydh and Patrick Mauritz.
The OpenBIOS IDE driver was written by Jens Axboe.
For license details on this piece of software, see Documentation/COPYING.
If you have patches, questions, comments, feel free to contact the OpenBIOS
mailinglist.
Regards,
the OpenBIOS team