I've assembled some notes from old manuals and other sources
on the formats used for on-disk file systems through the
Seventh Edition:
http://www.cita.utoronto.ca/~norman/old-unix/old-fs.html
Additional notes, comments on style, and whatnot are welcome.
(It may be sensible to send anything in the last two categories
directly to me, rather than to the whole list.)
There were ports of PCC to the 8086, Z8000, and 68000 done by
MIT's Laboratory for Computer Science. This might be a more
historically correct place to start.
I will be out of the office starting 05/25/2002 and will not return until 06/06/2002.
I will respond to your message when I return. I will be on vacation. My manager, Venkat Jituri has my contact information. For Equity Research issues, contact Chris Fumai.
--
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
I recently discovered your excellent site (was pre-Lions src just recently
made available?), which prompted me to send the following mail out to my
colleagues in Solaris Kernel Development. (Apologies in advance if you find
this annoying, superfluous or disrespectful -- I thought some might find
it interesting, if stupid.) If there are other kernel implementors of
AT&T-derived UNIX lurking here, it would be enlightening to know what a
similar comparison yields on your baby. (It should go without saying that
the implementation of each mentioned function has virtually no resemblance
to its V3 forebear.) And of course, my burning question: has none of us
changed "/* stat codes */" in proc.h?)
------8<---------------------
Subject: Memorial Day in uts
To: kernel(a)eng.sun.com
All,
This Memorial Day, take a moment to remember the source code that has
served in our kernel since its inception. To this end, wander by
http://minnie.tuhs.org/UnixTree/, and pause for a moment to commemorate
these brave functions from the 101st Tapeborne -- all of which have
served continuously since August, 1973:
bflush() falloc() newproc() sched()
bread() getblk() nodev() signal()
brelse() getf() nulldev() stty()
bwrite() gtty() panic() suser()
clock() issig() printf() swtch()
closef() mmread() psig() timeout()
core() mmwrite() psignal() ufalloc()
Their compatriot structure fields include:
av_back b_flags p_flag u_cdir
av_forw b_forw p_ppid
b_back c_arg (*) p_stat
b_blkno c_func (*) p_wchan
(*) c_func and c_arg are notable for having survived a bonwick scorched-earth
rewrite of callouts circa 1997 -- unclear if this makes them eligible for
the Purple Heart, or if they should be considered acquited war criminals.
As for constants, B_DONE, B_ERROR, FREAD, FWRITE, and SSLEEP have all had the
same numerical value since they enlisted in 1973. And a moment of silence
is certainly due to this line in proc.h -- a line which has not changed
so much as a character since 1973:
/* stat codes */
And to the code ripped out in the line of duty, we say only: "We Have Not
Forgotten." (Of course, we usually follow that up with "Never Again.")
- Bryan
----------------------------------------------------------------------------
Bryan Cantrill, Solaris Kernel Development. bmc(a)eng.sun.com (650) 786-3652
I wrote:
> the uVAX unhalt is simply an RFI: on real hardware it knows that
> this RFI is an unhalt and lights the RUN LED because the SSC chip compares
> instruction fetch addresses against the halt range and detects the unhalt
Of course I meant REI. I was mixing VAX and PowerPC in my head again... That's
what happens when you try to work on too many architectures at the same time.
MS
Rico Pajarola <rp(a)servium.ch> wrote:
> At this point, I am at the simh prompt (">"). I think simh catches
> the halt instruction and goes to the simh prompt when it encounters
> one. I have a VAX 4000/300 at home (unfortunately it doesn't run
> any of the older unixes), and when it halts, I get the >>> prompt
> (differs from simh).
The 4000/300 works like any other uVAX (VAX processor implemented in a single
IC) in this respect: a halt is a special exception that works like regular VAX
macrocode exceptions except that it saves the PC and the PSL in special IPRs
rather than on the stack (so that it doesn't depend on a stack), vectors to the
hardwired ROM address 20040000 rather than through SCB (so that it doesn't
depend on SCB), and MAPEN is cleared (so that it goes to the physical address
20040000 in the ROM rather than whatever that address may be virtually). The
CPU board firmware than displays the halt message and the >>> prompt as
prescribed by the VAX Architecture (DEC STD 032-0). KA650/655 works exactly the
same way.
While I haven't played with simh and don't intend to in the near future (due to
my general lack of interest in emulators), thus I don't claim to be right here,
but from your session logs it appears that simh is not doing the above uVAX
halt exception but instead it handles halts like an 11/780, by "physically"
stopping all instruction execution. That is fine and dandy, the 11/780 way is
certainly cooler, but the problem is it ain't a KA655 any more, and one should
not expect the KA655 boot ROM to work right then (and IMAO it has no right to
report the KA655 SID code either).
> I am pretty sure that I have configured simh correctly, I verified
> this by installing netbsd on the same setup, and it boots ok.
When I took a cursory look at SIMH/VAX, which consisted only of glancing at its
brief documentation, I read that the KA655 ROM image it comes with is not the
real one but hacked to work with the poor emulator. This suggests to me that
you are able to boot some OSes because Bob has gutted the (quite complicated)
KA655 console and boot logic to the bare minimum he had emulated. I wouldn't be
surprised if he hacked out the KA655 diagnostic executive almost entirely, so
that on "power-up" one goes through an absolutely minimal init sequence without
a single halt/unhalt cycle occuring (of which on a real KA655 several occur on
every power-up during diagnostics), gets to the >>> prompt, and then when
booting, runs VMB, unhalts once (the SIMH probably doesn't even know that it
unhalts, as the uVAX unhalt is simply an RFI: on real hardware it knows that
this RFI is an unhalt and lights the RUN LED because the SSC chip compares
instruction fetch addresses against the halt range and detects the unhalt, but
I doubt that SIMH emulates this), and then it all goes well (cross your fingers
three times!) never goes through a proper KA655 halt/unhalt again. But if
something goes wrong in the boot and VMB's error handler gets invoked, SIMH's
very poor man's emulation is not prepared for it.
> My only problem seems to be getting the bootblocks right. I have
> heard that someone managed to install quasijarus0a on simh, so it
> must be me somehow screwing the bootblocks.
But the rub is that because of SIMH talking the KA655 talk but not walking the
KA655 walk, you can't see what exactly is the problem with your bootblocks:
VMB's error messages aren't displayed.
MS
is there anybody who has successfully installed 4.3-quasijarus on
simh, who could tell me how to install the bootblocks (I am not
completely sure that I got the disklabel right). The exact incantation
of installboot and the output of disklabel would be very helpful.
Rico Pajarola
From: Gunther Schadow <gunther(a)aurora.regenstrief.org>
>>>
>>> 2..
>>>-DUA0
>>>HALT instruction, PC: 00000C1A (MOVL (R11),SP)
>
>this suspiciously looks as if the HALT is from SIMH not from the
>VAX it simulates. There are two halt levels in SIMH, one being
>the VAX halting and going into VAX console mode, the other being
>SIMH halting. Are you absolutely sure that you have a proper
>VAX console with SIMH? You should get normal VAX console
>behavior, try a few commands and see whether you're on the right
>page.
At this point, I am at the simh prompt (">"). I think simh catches
the halt instruction and goes to the simh prompt when it encounters
one. I have a VAX 4000/300 at home (unfortunately it doesn't run
any of the older unixes), and when it halts, I get the >>> prompt
(differs from simh).
>Also, be sure you have it all configured right, that you have
>the right devices defined and properly associated with files
>on the hosting OS etc.
I am pretty sure that I have configured simh correctly, I verified
this by installing netbsd on the same setup, and it boots ok.
My only problem seems to be getting the bootblocks right. I have
heard that someone managed to install quasijarus0a on simh, so it
must be me somehow screwing the bootblocks.
>> This seems like a simh problem, or, more probably since you can boot That Other
>> OS successfully, a problem with your installation of 4.3BSD-Quasijarus0a masked
>> by a simh problem.
the problem is with the bootloader only, quasijarus0a runs well once booted using
the netbsd bootloader.
>I would agree. What other system can you boot on SIMH?
only netbsd and quasijarus0a (I don't have any vms media).
thanks for your help
Rico Pajarola
Rico Pajarola <rp(a)servium.ch> wrote:
> I installed 4.3-quasijarus on simh [...]
> I have been unable to boot it directly from it's 'own'
> filesystem.
>
> here's what I see, complete transcript at the end
> > >>>boot dua0
> > (BOOT/R5:0 DUA0)
> >
> >
> >
> > 2..
> > -DUA0
> > HALT instruction, PC: 00000C1A (MOVL (R11),SP)
My ability to help you here will be limited because you are using simh rather
than a real VAX. The real KA655 console ROM does not issue halt messages like
the above, its halt message have a different form (the one prescribed by DEC
STD 032-0, VAX Architecture Standard). The last message above does not exist on
any real VAX made by DEC.
> that's obviously not what I want. I tried all combinations of
> installboot and disklabel -B I can think of, both in netbsd and
> quasijarus, and all lead to the same result.
>
> Can anybody tell me the exact incantations necessary to install
> the bootblocks for quasijarus0a [...]
This seems like a simh problem, or, more probably since you can boot That Other
OS successfully, a problem with your installation of 4.3BSD-Quasijarus0a masked
by a simh problem. You've got a halt inside VMB that happened after VMB had
successfully opened the boot device but before it accepted a valid bootblock.
What happens on a real KA655 is as follows: the console copies VMB from the
EPROM to RAM and transfers control to it, which is accompanied by the display
of 2.. on the console and on the CPU module LEDs. At that point the VAX is
unhalted, i.e., the RUN indicator on the front panel lights up. VMB thus runs
as user code and tries to perform the bootstrap. As VMB successfully opens the
boot device using its built-in drivers, it displays the device name in VMS
format on the console. Then if it finds and accepts a valid bootblock it
displays 1.. on the console and on the CPU module LEDs. Finally it transfers
control to the bootblock accompanied by 0.. display. If something goes wrong
and VMB gives up, it prints its own error message on the console and then
executes a HALT instruction to return to the console prompt. The HALT
instruction halts the VAX (the RUN indicator on the front panel goes out) and
invokes the console, which prints the halt message followed by the >>> prompt
as prescribed by DEC STD 032-0.
It looks like you are seeing VMB fail for some reason and halt, giving you the
(not compliant with DEC STD 032-0) halt message from simh. However, you are not
seeing VMB's error message which on a real KA655 will always appear before the
halt message from the console. This is a simh problem, it obviously does not
fully and properly emulate the real KA655 here. I cannot help you past this
point as I only support real VAX hardware. There is probably something wrong
with your bootblock as your emulated VAX's VMB is not accepting it while
accepting the one on DUA1 from That Other OS, but your poor emulator prevents
you from seeing what the problem is.
> So far I have not been able to boot any other VAX operating system
> from the TUHS archive, the netbsd bootloader cannot load ultrix32m,
> 32v and 3bsd.
I don't know / don't care much about That Other OS and its bootloader, but the
format of the VAX unix/vmunix kernel image and its boot interface has remained
absolutely unchanged from 32V through 4.3BSD-Quasijarus0a inclusive (but see
below about VAX model support). DEC has extended the boot interface in Ultrix,
but it's completely backward compatible: as the Ultrix bootloader starts the
kernel with a calls instruction, it passes one argument (calls $1) whereas
traditional Bell/Berkeley UNIX had zero (calls $0). A traditional kernel will
simply ignore this argument, while the Ultrix kernels checks for its presence
(thanks to the wonderful VAX architecture and its procedure call standard that
allows a procedure to determine its argument count) and lives without it if
it's absent. (That argument is a pointer to a structure with useful info,
however, and I plan to adopt this extension in 4.3BSD-Quasijarus1.)
> I have not yet had time to try any of the other 4.x
> bsds, but I assume they'd have the same problem as quasijarus0a.
4.3BSD-Quasijarus0 was the first release to support KA650/655, so don't bother
trying earlier ones. (Although you could try 4.3-Reno if that's what you like.)
> I don't
> have ultrix/vax media to do it right
You can get the complete TK50 distribution (tape images) of Ultrix V4.00 for
VAX on my FTP site ivan.Harhan.ORG in /pub/UNIX/thirdparty/Ultrix-32. I have
full sources for it there too.
> Ultrix 4.3 gives me:
> > 466788+254256+177476+[36984+34990] total=0xecfa2
OK, so the kernel has been loaded successfully.
> > machine check 82: vap 82000004 istate1 7c000c00 istate2 c070fe pc 80001c61 psl 41f0008
> > r0=8000000c, r1=8000167c, r2=0, r3=211bd0dd, r4=0, r5=dd274
> > panic: mchk
Since Ultrix V4.3 perfectly supports the KA655 CPU, this again must be a case
of simh misemulating it.
My advice to you is to get a real VAX.
MS
P.S. You may want to subscribe to the Quasijarus mailing list, send a request
to quasijarus-request(a)ifctfvax.Harhan.ORG.
