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