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
And that tag_machtype then be a different list of machines
depending upon machgroup:
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
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:
at fnet, so please use the server nearest/fastest to you...
Paul M. Antoine, Net: email@example.com
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.