Subject: Re: [LV] RE: Linux-VAX-- What happened to it?
To: None <linux-vax@solar.physics.montana.edu>
From: Dave Airlie <airlied@linux.ie>
List: port-vax
Date: 02/14/2003 01:22:21
Hey all,

Word of warning first Gregg, the CVS tree is a bit messy at the moment,
you've probably picked a bad time to get started on Linux/Vax ;-)

I'm currently transitioning our system from the binutils2.10+gcc.2.95.2
we've been using to binutils 2.13.2.1+gcc-2.95.2 (with NetBSD updates), so
we can do dynamic library support, however my last checkin went horribly
wrong so the toolchain is messed up ...and my access to the CVS tree is
also convoluted.. (Australia -> Ireland -> CVS in US).

Look back throught the last few days in the mailing list archives for more
detailed explanation....

Generic kernel support is bit borked at the moment, it might work but it
might not... I haven't the hardware to test it on ..

I'll try and get some time to do a SIMH HOW-TO over the weekend, it's a
bit messy (read a lot messy).. as we don't have drivers yet for the SCSI
in the SIMH, so we boot from a kernel that looks like a disk but mount the
rootfs from the network (which we do support)... only problem is SIMH uses
pcap on Linux which is not useful (it should use TUN/TAP)... so your SIMH
vax can't see the machine it is running on (it can see the rest of the
network).. so I had to make a special dummy.c for Linux to do all of this
on my laptop with no ethernet connection...

for now some quick notes:

kernel - use top of CVS
toolchain - get the one I mentioned in the list archives a couple of days
ago from http://www.skynet.ie/~airlied/vax, it is rooted in /var/tmp and
the version in CVS isn't up to date yet (in fact the toolchain in CVS is
need of surgery due to a messy checkin by me yesterday)...

Up on http://www.skynet.ie/~airlied/vax/simh
I've put some files I use here..

config.simh - config file for kernel
dummy.c - replacement dummy device driver so SIMH can talk to host PC
lvax - simh startup file
setcmdline.sh - contains command line I use...
vmlinux.dsk.simh - the vmlinux.dsk file from my /tmp that is a kernel that
can be booted like a disk.

With that at the VAX root from the website you've gotten everything I use
at the moment except the uClibc I use with shared linker,

We are still a fair bit away from a distribution type thing, I've ported
the basics of glibc 2.2.5 before, but Andy was looking after the floating
point stuff which is messy for VAX vs IEEE and we've not heard from him in
a while...

I'm probably going to in the next while build a new root filesystem using
dynamic libraries.. and it'll probably be debian based as their package
management might work for me .. (it may also be RH7.3 based as I have SRC
cds here )...

am also going to try and get Linux Test Project and gdb (again!!) going ..

Dave.

>
> Dave is working on toolchain stuff at the moment.  He's working> with
the more stable 2.4 kernel which supports:
>
>    LANCE ethernet (KA42/43/46)
>    5380 SCSI
>    SGEC ethernet (maybe - I think this is work-in-progress)
>    DZ11 serial ports
>    DELQA ethernet
>
>> Also they chose to base their root file system's kernel on the KA43
>> CPU, and associated peripherals.
>
> I don't think a "generic" kernel will work properly right now.
> But Dave is working solely with SIMH right now, so I'm sure he
> can probably give you a binary kernel for SIMH, if you don't
> want to compile a toolchain and kernel yourself.
>
>> Next up, what about using the MOP protocol to do the booting? Those
>> kernels were created with that in mind, it seems. Any suggestions for
>
> Yes.  The output from our kernel compile is a vmlinux.SYS that can be
> MOP-booted, and a vmlinux.dsk that can be dd-ed to the start of a disk
> and disk booted.  Either kernel can then NFS-mount a root fs or mount a
> local SCSI disk (on VS3100-class machines anyway - maybe VS4000/60 too -
> can't remember).
>
> There is also a simple bootloader (asbl - Andy's {Simple|SCSI|Stupid}
> Boot Loader) that can pull a kernel from within a filesystem on
> a disk that the VAX firmware supports (uses console calls to read
> the kernel, so in theory, could pull a kernel from an RA disk
> through a KDA50, for example - but the kernel itself won't be able to
> access the disk afterwards).
>
>> setting up SIMH to do that? I've got the vaguest notion of doing so,
>> and I do not even know where to begin.
>
> Dave?
>
> Later,
> Kenn


-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied@skynet.ie
pam_smb / Linux DecStation / Linux VAX / ILUG person