linux-mips-fnet
[Top] [All Lists]

NAPS now integrated to DECStation code... issues!

To: linux-mips@fnet.fr (Linux MIPS mailing list)
Subject: NAPS now integrated to DECStation code... issues!
From: paul@suite.sw.oz.au (Paul Antoine)
Date: Mon, 6 May 1996 22:14:32 +1000 (EST)
Organization: Softway Pty Ltd
Hi folks,

In email, Ralf says...

> Hmm,  I've fixed a whole bunch of bugs in my newest kernels so I really
> suggest to use them.  The kernel code has been reorganised compared with
> 1.3.62 and this might - at least to a certain degree - make your life
> easier though adding your patches into my kernel will be slightly more
> work.  Head.S is still not really reorganized, but we really should do
> this with your machine and the SGI stuff to come in mind.

This needs doing, but I also found other issues as I tried to integrate
the new bitags stuff into the DECStation code...

        I needed to add bitags.c from Milo (I used .26), so that I
        could add tags prior to launching the kernel.  This code
        will be generally usefull for any kernel that can be loaded
        via tftp (unless we write a tftp-capable version of Milo :-) or
        in any system with a primitive boot loader.

        Some bitags functions (for reading tags) are included in setup.c
        and should probably be in a separate file as this is a little
        clearer if nothing else...

        A lot of code still assumes gross amounts of pc-ism.  The time.c
        file is one of them... the DEC RTC is PC-compatible, but is
        addressed as a flat set of registers... we need to modify the
        functions in the feature structure to allow reading and writing
        via functions instead of the half-baked macro/function approach
        currently used in CMOS macros.

        The tags for machine hierarchy still need some work.  I propose
        the following:

                mach_group:
                                DECStation
                                ARC
                                others...

        And that tag_machtype then be a different list of machines
        depending upon machgroup:

                DECStation:
                                UNKNOWN                 0
                                DS3100                  1
                                DS5000/200              2
                                DS5000/100              3
                                DS5000/2x               7

                ARC
                                UNKNOWN                 0
                                DESKSTATION_RPC44       1
                                DESKSTATION_TYNE        2
                                ACER_PICA_61            3
                                MIPS_MAGNUM_4000        4
                                OLIVETTI_M700           4

                MIPS
                                UNKNOWN                 0

        etc.  I say this because it then lets me use the standard DEC
        machine type codes, and is notionally a better hierarchy.

        Where do I find the definition of the data in the drive_info
        structure to figure out what to put in it (apart from the
        zero I had to use to get the kernel to boot any further).

        As for the interrupt and DMA code... yuk!!!

Now one thing I've noticed is that lots of these issues ought to have
been covered in the SPARC port... but the current OS releases seem to
be incomplete with regard to SPARC code.  Is the SPARC source tree 
currently separate from the main Linux tree?? Should I get it to see 
what they've done??

The good news from all of the above is that I think the DEC code is
a lot cleaner than it was, and now does the following correctly:

        Gets the system ID from the boot prom, and uses that to
        set:
                Machine type
                CPU type & revision
                Boot prom revision level
        
        Gets the available RAM size from the boot prom (rather than
        simply assuming 8MB :-)

It also needs to be able to:

        Get default command line from boot prom environment variable
        Get default boot device from boot prom environment variable
        Get default console device from boot prom environment variable
        Lots of model-specific configuration...

...and to store them in DEC-specific tags.  This is pretty easy though,
as the new config code is now in C rather than assembler. <yay!>

All I need to do now is integrate all this into a 1.3.97 kernel and
release it all!

I also would like to hear from other owners of DECStations that have
tried my test kernel.  Please note that the pub/linux-mips directory
is now mirrored as:

        private/Incoming/ftp.softway.com.au

at fnet, so please use the server nearest/fastest to you...


Paul
_______________________________________________________________________________
Paul M. Antoine,                                        Net: paul@sw.oz.au
Softway Pty Ltd                                         WWW: www.softway.com.au
PO Box 305, Strawberry Hills, NSW 2012, Australia       Tel: +61 2 698 2322
Level 2, 79 Myrtle St, Chippendale, NSW 2008, Australia Fax: +61 2 699 9174

"It is the lack of acceptance of diversity which threatens to 
 destroy society, NOT the free expression of it." - Me.

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