[OpenBIOS] Sun OBP bugs in 1.0RC1

[Peter]

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).


10) Error message:
"BAD TRAP: cpu=0 type=9 rp=fd008d8c addr=fff8910f mmu_fsr=326 rw=1
MMU sfsr=326: Invalid Address on supv data fetch at level 3
regs at fd008d8c:
psr=4900cc4 pc=f0137f58 npc=f0137fc
..."

Bug: Memory is not mapped by OBP the way SunOS expects it.  In
particular, it expects that 0xFF843000 (Syslimit) will be mapped down
to the L3 level, where it points to 0 (not actually mapped to physical
memory).  hat_findpte() is returning an invalid address on the
emulator, whereas the address of an empty PTE is returned by real
hardware.  The invalid address comes from the translation table in use
by the MMU when load_tmpptes() sets up the PTE table used by
hat_findpte().

Fix: Unknown.  The memory mapping utilized by OBP appears to be
scattered all over, and cleaning it up looks like a substantial task.
It's possible that by actually implementing obp_dumb_memunmap() and
obp_dumb_memfree() (and updating the available "memory" and
"virtual-memory" properties), it could make this problem go away.


A patch file resolving bugs 1-9 is forthcoming.