[Top] [All Lists]

Re: DECstation porters unite !

Subject: Re: DECstation porters unite !
From: Harald Koerfgen <>
Date: Mon, 19 Jan 1998 09:07:11 +0100
Organization: Ford Motor Company
References: <199801181225.NAA01041@jordan.numerik>
Fellow DECstation hackers

Michael Engel wrote:
> Hi,
> due to the overwhelming amount of requests regardings the DECstation port
> during the last few weeks ;-), we should do something to get the port further
> along.

Glad to see that there are other people working on the DECstation port.
I began to feel lonely ;-).

> I will set up a mirror site of Paul's DECstation information pages on Monday
> and would like to ask all people who have DECstation patches to upload the
> patches to in /incoming.

I have done some work on the port lately. You can download a snapshot of
my work from

This is a diff against the linux- source tree from Paul.
> We should try to find out what the biggest problems in the current
> state of the port are. Areas that IMHO need work are:
> - Interrupt handling

I have completely rewritten the interrupt handler itself. The code for
initializing the tables in there definitely needs some more work. Have a
look at decstation.c to get the idea.

> - MMU setup and handling

Rudimentary MMU support is also there, very rudimentary. This is just
enough to get through buffer_init(). The kernel is now dying in the
attempt to return from the first syscall in kernel_thread(...) at the
end of main(...) in init/main.c. I am getting a kuseg miss with a
BAD_VADDR of 0x00000000, which looks like a NULL pointer dereference. I
haven't yet been able to find the reason cause using the prom_printf
routine in exception handling code seems to be a bad idea :-(. Actually
I am working on a primitive debugging console via serial port.

> - of course, device drivers:
>   o Ethernet (Lance 7990) - should be able to derived from the Sparc port,
>     major difference is that the Lance has a separate memory area in at
>     least the DS[23]100 and 5000/200 and isn't able to do DMA.

This is true for the DS[23]100 and the 5000/200. The 5000/25, 5000/1xx
and 5000/2x0 DECstations have DMA support for the Lance, the NCR53C94
and even the Z8530 chips.

>   o SCSI in DS[23]100 - the DEC SII chipset. Documented in the DS3100
>     functional specs
>   o SCSI in almost (?) all other DECstations - NCR53C94. Is this chip
>     documented ?

See other replies.

>   o Console drivers (I got some of these working with the DZ11) - a DZ11
>     compatible UART in DS[23]100 and 5000/200, a Zilog 8530 in at least the
>     Personal DECstations and the DS5000/1xx.

And the 5000/2x0.

>     Support for the DS[23]100 frame buffer also exists.
>     We should also examine the differences between the various REX- and
>     non-REX firmware versions in the various DECstations.
>   o TurboChannel support - probing for cards etc. and support for the most
>     important TC options - PMAG-[AB]* graphics adapters, ethernet and SCSI
>     controllers (which are simply TC versions of the Lance and NCR53C94).
>     Well, we also have a nice 24-bit i860-accelerated graphics board here ;-)

Mee too ;-).

> [So you say that's almost everything - hmmm, maybe you're right ;-)]
> Probably it is also a good idea to make a list of the hardware that is
> available for testing kernels.
> I have a DS2100, a 5000/25, a 5000/120 and a 5000/200 and can get
> access to 5000/33's, 3100's and 5000/240's at University.

I have a 5000/133 and a 5000/240.
> I would personally also like to support the first-generation TurboChannel
> AXP machines (3000/[34567]00) as the Alpha developers don't seem to be
> interested in these ... but I still don't have such a machine :-(.

>From what I have been able to find out, these are very similar to the
DECstation 5000/240 and are quite well documented.
> regards,
>         Michael Engel   (


<Prev in Thread] Current Thread [Next in Thread>