I installed 4.3-quasijarus on simh, and I managed to boot indirectly
by putting the kernel as /quasijarus0a in the netbsd root filesystem,
and then booting it from the netbsd bootloader with 'boot quasijarus0a
-a'. 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)
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, or does anybody who has installed
quasijarus0a have a session transcript? any idea what I might be
doing wrong?
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 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.
I have tried ultrix-4.3 (also from the netbsd bootloader, I don't
have ultrix/vax media to do it right), but it does not work either.
If anybody can help me with this, thanks in advance
Rico Pajarola
The following transcript shows how I boot it (first the way it
fails, then the way it works):
> VAX simulator V2.9-9
> sim> show c
> VAX simulator configuration
>
> CPU, 32768KB
> TLB, 2 units
> TLB0, 8KW
> TLB1, 8KW
> ROM, 128KB
> NVR, 1KB
> SYSD, 2 units
> SYSD0
> SYSD1
> QBA
> TTI
> TTO
> CSI
> CSO, not attached
> CLK
> PTR, address=20001F68-20001F6F, not attached
> PTP, address=20001F68-20001F6F, not attached
> LPT, address=20001F4C-20001F4F, not attached
> RQ, address=20001468-2000146B, 4 units
> RQ0, 159334KB, attached to 4.3-quasijarus0a.rd54.dsk, write enabled, RD54
> RQ1, 622932KB, attached to ../netbsd-vax/netbsd-vax.ra82.dsk, write enabled, RA82
> RQ2, 409KB, not attached, write enabled, RX50
> RQ3, 409KB, not attached, write enabled, RX50
> RL, disabled
> TS, disabled
> DZ, disabled
> sim> boot cpu
>
>
> KA655-B V5.3, VMB 2.7
> Performing normal system tests.
> 40..39..38..37..36..35..34..33..32..31..30..29..28..27..26..25..
> 24..23..22..21..20..19..18..17..16..15..14..13..12..11..10..09..
> 08..07..06..05..04..03..
> Tests completed.
> >>>boot dua0
> (BOOT/R5:0 DUA0)
>
>
>
> 2..
> -DUA0
> HALT instruction, PC: 00000C1A (MOVL (R11),SP)
> >>>boot dua1
> (BOOT/R5:0 DUA1)
>
>
>
> 2..
> -DUA1
> 1..0..
>
>
> >> NetBSD/vax boot [Aug 19 2001 05:57:49] <<
> >> Press any key to abort autoboot 3
> > boot quasijarus0a -a
> 327204+103384+130352+[29436+24084] total=0x96220
> 4.3 BSD Quasijarus UNIX #0: Sat Oct 2 22:15:38 CDT 1999
> msokolov@luthien:/usr/src/sys/GENERIC
> real mem = 33521664
> SYSPTSIZE limits number of buffers to 80
> avail mem = 31697920
> using 80 buffers containing 655360 bytes of memory
> MicroVAX 3000, ucode rev 6
> uda0 at uba0 csr 172150 vec 774, ipl 15
> uda0: version 3 model 3
> uda0: DMA burst size set to 4
> ra0 at uda0 slave 0: RD54, size = 311200 sectors
> ra1 at uda0 slave 1: vaxnetbsd, size = 1216665 sectors
> ra2 at uda0 slave 2: floppy
> ra3 at uda0 slave 3: floppy
> lp0 at uba0 csr 177514 vec 200, ipl 14
> root device? ra0
> WARNING: clock gained 14 days -- CHECK AND RESET THE DATE!
> erase ^?, kill ^U, intr ^C
> #
from this point on, it works as expected.
Ultrix 4.3 gives me:
> 466788+254256+177476+[36984+34990] total=0xecfa2
> 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
>
> dumping to dev ffffffff, offset 0
> dump machine check 80: vap 78302077 istate1 fb000c00 istate2 c070fd pc 8004eb57 psl 41f0000
> r0=78302073, r1=0, r2=0, r3=211bd0dd, r4=22, r5=80
> panic: mchk
>
> HALT instruction, PC: 8000165B (XFC)
Jonathan Engdahl:
Consider lcc, the Princeton C compiler. It's much smaller than gcc, and ANSI
compliant.
lcc's a good compiler; it has become cc in my own peculiar Ancient UNIX
environment. But my environment is on VAXes, not PDP-11s; the lcc I use
probably cannot be compiled to a core compiler binary of less than about
180KB, of which 136KB is text, and that is without any real code generators.
(For those who know lcc: I am using a slightly-hacked-up lcc 3.6; the
180KB binary includes just the symbolic and null code generators, not
the enormous one I ended up with for the VAX.)
On the other hand, it is probably easier to split lcc into overlays or
multiple passes to make it fit on a PDP-11 than to do the same to gcc;
and lcc works fine as a cross-compiler. And it's a good solid ANSI
compiler; enough so that it is a little annoying to use it on heritage
code (it grumbles, correctly, if a function returns no value and wasn't
declared void), and helpful or very painful (depending on your point of
view) when used on really old code that is sleazy about mixing types of
pointers in procedure arguments, or reusing one structure as part of another,
or the like. I had an interesting time a few months ago getting an old
version of tbl to compile cleanly and produce correct results under lcc;
the program contained some ancient constructs that are truly remarkable
to look back on, especially for those of us who started out programming
that way and learned better the hard way ...
If I were going to work with PDP-11s, I would probably use lcc as a
cross-compiler myself, after writing or snitching a code generator of
course.
Norman Wilson
Does anyone know how many of the V5, V6, V7, 2BSD, 2.11BSD, etc. filesystems are
implemented in some current unix implementations, NetBSD, Linux, etc. Seems like
that could be useful when playing with simh.
-chuck
On Mon, 6 May 2002 tuhs-request(a)minnie.tuhs.org wrote:
> From: Warren Toomey <wkt(a)minnie.tuhs.org>
>
> Sven, you might want to look at this:
> http://minnie.tuhs.org/cgi-bin/pups.cgi?article=2170
>
> From: Stuart Norris <norris(a)euler.mech.eng.usyd.edu.au>
>
> I have hacked together a version of a Unix 5th (and 6th)
> Edition filesystem for Linux. It is read only, and was written for
> Linux 2.0 on an x86 and so will require a little work to install on
> other systems and newer kernels, but it is fun to be able to mount
> old disk images.
The source code is sitting on
http://www.esc.auckland.ac.nz/People/Staff/Norris/src/u5e-0.2.tar.gz
and the INTRO file contains a description of the filesystem. I don't think
it works with current Linux kernels (I havn't touched it for a long while),
so it might be easiest to start afresh using the minix filesystem module
as a start.
Briefly, the filesystem is like
--
* Block size: 512
* General layout:
Block 0 boot block
Block 1 super block
Blocks 2 -> isize-1 inodes
Blocks isize -> fsize-1 data blocks
* Byte ordering of "short" (16 bit entities) is little endian 0 1
* Byte ordering of "long" (32 bit entities) is PDP-11 2 3 0 1
* Inode on disk: "short"
0 means non-existent
1 root dir
* Maximum number of hard links to a file: 256
* Super-block location: bytes 512-1023
* Super-block layout:
unsigned short s_isize; /* size in blocks of I list */
unsigned short s_fsize; /* size in blocks of entire volume */
unsigned short s_nfree; /* number of in core free blocks (0-100) */
unsigned short s_free[100]; /* in core free blocks */
unsigned short s_ninode; /* number of in core I nodes (0-100) */
unsigned short s_inode[100];/* in core free I nodes */
char s_flock; /* lock during free list manipulation */
char s_ilock; /* lock during I list manipulation */
char s_fmod; /* super block modified flag */
char s_ronly; /* mounted read-only flag */
unsigned long s_time; /* current date of last update */
* Inode layout:
unsigned short i_mode; /* access permissions */
unsigned char i_nlink; /* number of links to file */
unsigned char i_uid; /* owner */
unsigned char i_gid; /* group */
unsigned char i_size0; /* size of file */
unsigned short i_size1;
unsigned short i_addr[8];/* address of blocks */
unsigned long i_atime; /* time of last access */
unsigned long i_mtime; /* time of last modification */
* Regular file data blocks are organized as
if (010000 bit set)
the file is large:
i_addr[] contains indirect blocks
else
the file is small:
* Inode size 32, 16 inodes per block
* Directory entry on disk
unsigned short inode;
char name[14];
* Dir entry size 16, 32 dir entries per block
* There are no symbolic links
--
Stuart Norris s.norris(a)auckland.ac.nz
Bioengineering Institute, University of Auckland hm: +(64 9) 307 0006
http://www.esc.auckland.ac.nz/People/Staff/Norris wk: +(64 9) 373 7599 x3055
I've just obtained a box of tapes, some of which might be of interest here.
- UNIX/32V V1.0 (w/ typed Bell Labs label): one 2400' 800bpi tape
- Ultrix-32M V1.1 distribution: one 2400' dump tape
- Ultrix-32 & 32M V1.1 Sources: two 2400' 1600bpi tar tapes (2 copies each)
- BSD4.1 distribution: one 2400' 1600bpi tape
- UNIX V5 (handwritten label dated Feb 7 1977): one 2400' tape
- one 400' tape with missing identification label but a typed Bell
Labs notice
- backup of 2 RKs: V6 UNIX master and V6 UNIX additional source:
one 400' 800bpi tape
- C Release 29/9/80 (handwritten): one 2400' tape
- several backup tapes from a V7 system
- several other tapes that appear to be other UNIX system backups
I don't have a 9-track drive, so I can't say that these will be readable (or
even that they haven't been bulk-erased), but I do believe that they have at
least been stored well so far. If any of these look like they could contain
things currently missing from the archives, then I do of course want to make
them available to someone who can try to read them.
--
Kevin Schoedel
schoedel(a)kw.igs.net
Hi,
I'm currently working on an implementation of the Unix 6th Edition's
filesystem for Linux. I think earlier Unix filesystems should be very
similar to it. I would like to implement them, too, but I don't have
exact descriptions of them (for the 6th Edition I've the Lions Book;
there is not much about the actual filesystem architecture in it, but
it should be enough - together with the code ;-).
Please send me descriptions, specifications and everything else
you've about the early Unix filesystems. Also filesystem images are
very welcome as I can use them to test my implementation.
My e-mail account can only handle attachments <3000KB. Please
compress or split the files if they are bigger than 3000KB.
Thank you
Sven
>exact descriptions of them (for the 6th Edition I've the Lions Book;
>there is not much about the actual filesystem architecture in it, but
>it should be enough - together with the code ;-).
You might want to run V6 or V5 on a simulator. For one you can "see"
the filesystem and you can read the man pages, especially fs(5).
Wolfgang
> From: Mike Haertel <mike(a)ducky.net>
> To: tuhs(a)tuhs.org
> Subject: Re: [TUHS] Some tapes
> Date: Fri, 3 May 2002 01:13:55 -0700 (PDT)
>
> I'd also like to point out that the 4.1BSD distribution tape would
> be a nice addition to the TUHS archive. Right now 4.0, 4.1, and
> 4.1[abc] distributions are still missing.
These are available from Kirk McKusick on his 4-CD collection, no?
It'd be good to have them in w/the other stuff all in one place, but
it's not like they aren't available...
Arnold
I'd also like to point out that the 4.1BSD distribution tape would
be a nice addition to the TUHS archive. Right now 4.0, 4.1, and
4.1[abc] distributions are still missing.
