Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!agate!dog.ee.lbl.gov!horse.ee.lbl.gov!torek
From: torek@horse.ee.lbl.gov (Chris Torek)
Newsgroups: comp.unix.bsd
Subject: Re: Problems with 4.4 BSD on SPARC
Date: 7 Sep 1993 19:30:31 GMT
Organization: Lawrence Berkeley Laboratory, Berkeley CA
Lines: 92
Message-ID: <33674@dog.ee.lbl.gov>
References: <2683vuINN1a1@sal.hal.COM>
NNTP-Posting-Host: 128.3.112.15
(Note, this has only a partial solution for the first problem, but I
thought I should post anyway.)
In article <2683vuINN1a1@sal.hal.COM> kenneth@hal.COM (Kenneth A. Smith) writes:
>Having problems getting 4.4 BSD booted single user ...
>1) With a Sun IPC, the kernel jumps into the firmware after printing
> fd at mainbus0 ioaddr 0xf7200000 not configured
>while the machine is booting.
This is due to some tricky stuff in the `fast raster console tty'
code. In order for the kernel and the PROM driver to share the
`current cursor row and column' variables, I came up with the following
FORTH code:
sprintf(buf, "' line# >body >user %x !", &fb->fb_row);
...
sprintf(buf, "' column# >body >user %x !", &fb->fb_col);
which we pass to the PROM's `interpret forth string' function. (Note
that I am *not* experienced with FORTH, and if there is a better way to
pick up the addresses of these pseudo-constants, I would not mind
hearing it.)
Anyway, it turns out that the PROM `interpret' vector comes in several
incompatible flavors. We only know about two of them:
void
rominterpret(s)
register char *s;
{
if (promvec->pv_romvec_vers < 2)
promvec->pv_fortheval.v0_eval(strlen(s), s);
else
promvec->pv_fortheval.v2_eval(s);
}
It seems there is (at least) a third variant. Until this variant's
version and call sequence are discovered, it suffices to overwrite the
rominterpret function with a `retl; nop' sequence if your PROM gives
you this problem. You can do this by mounting the BSD root file system
under SunOS, making a copy of vmunix, and using the SunOS adb (things
you type are marked with >>>; indented lines are output from the shell
or adb; comments appear before the action, in parentheses):
(save the original)
>>> % cp vmunix vmunix.dist
(get ready to patch it)
>>> % adb -w vmunix
(verify the instructions at the beginning of rominterpret())
>>> rominterpret,2?X
_rominterpret:
_rominterpret: 9de3bf90 113e0327
(replace the first instruction with `retl')
>>> rominterpret?W 81c3e008
_rominterpret: 0x9de3bf90 = 0x81c3e008
(replace the second instruction with `nop')
>>> .+4?W 01000000
_rominterpret+4: 0x113e0327 = 0x1000000
(check that the replacement worked)
>>> rominterpret,2?ai
_rominterpret: _rominterpret: jmp %o7 + 0x8
_rominterpret+4: nop
(exit adb)
>>> $q
%
The modified kernel will continue to use the fast raster console code,
but the kernel's idea of the cursor position will not stay synchronized
with the PROM's idea of the cursor position. (Callers of rominterpret()
---actually, there is only the one---must be prepared for the function
to do nothing.)
Another method, if you can recompile, is to compile a kernel without
the RCONSOLE option. This will save some space at the expense of
slow (SunOS-speed) console output.
>2) With a Sun IPX, the kernel boots multiuser ... [but soon]
>panics or hangs ...
The system was never tested on late-model IPX machines. We (LBL) got
several of these just before the release. The CPU and FPU are not one
of the types listed in my old Version 8 architecture document (this can
be seen by the `???' printed while configuring the CPU and FPU), and I
suspect the CPU is one with a particular cache bug that corrupts trap
vectors.
There is as yet no fix for this.
--
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 510 486 5427)
Berkeley, CA Domain: torek@ee.lbl.gov