Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 13 Oct 1995 16:01:06 -0700 (MST)
From:      Terry Lambert <terry@lambert.org>
To:        matt@lkg.dec.com (Matt Thomas)
Cc:        terry@lambert.org, hackers@freebsd.org
Subject:   Re: IPX now available
Message-ID:  <199510132301.QAA18445@phaeton.artisoft.com>
In-Reply-To: <199510131816.SAA24191@whydos.lkg.dec.com> from "Matt Thomas" at Oct 13, 95 06:16:36 pm

next in thread | previous in thread | raw e-mail | index | archive | help
[ ... ]

> Either via a smarter bootloader or a VM86 mode, calls into the BIOS
> to get configuration information should be done as well.  For instance,
> getting the information out of the EISA CMOS should the DEPCA driver
> since the DE422 config registers are write-only.

Actually, the EISA configuration is accessable from protected mode.  What
is *not* accessable about EISA from protected mode is the amount of per
slot CMOS (though thihas generally leveled out at 1k, older hardware is
not required to have a specific amount).

There is a nice book on "EISA system architecture" (shiny paperback, rag
bond pages, all white; I can get ISBN information if necessary) that
describes how to hueristically determine the amount so that BIOS calls
are totally unnecessary.

I've been thinking on EISA for some time, actually, since it seems to me
that EISA configuration is the last bastion of "DOS required" for those
boxes.


> Also, the probe needs to be done once on a per bus-type basis;
> a probe should never try to all the different bus types at once.

Agreed.  A pereference should be given to the local bus.  If an ISA
is bridged onto a PCI, it's block relocatable, but should be the
first "PCI device" probed.

I'd order it:

	ISA
	ISA bridged to PCI
	EISA
	PCI bridged to ISA
	MCA
	PCI


> For PCI, I'm beginning in favor of having the driver call a pci_match
> routine to find instances of itself instead of the currently "passive"
> method.  The passive method just doesn't lend itself to LKM.  One other
> reason I favor it is so that I could have a "generic" DC21x4X module 
> and then have various board/chip specific LKMs.  The de driver is getting
> fairly large and I'd like a method to trim out the unneeded code.

Both of these are plusses with no real minuses that I can see.

The idea of "controller/target" seems to fit well, with the "controller"
being the "generic" module and the "target" being an implementation
instance.

If one view SCSI as a bus attach, the generic SCSI code can be loaded
in the same fashion as a "controller" with each controller type as a
"target" fo the bus attach.

Then the bus can be treated seperately as "controller/target" (target/LUN)
pairings.



A lot of the disk stuff really wants to be ordered before the non-disk
devices.  I think classification of devices as "boot critical" or not
is an issue that begs the VM86() question.  If there is VM86() support
(the equivalent of Sun/PPC OpenFirmware for PC class machines), then
it's a no-brainer.  You make them loadable.  Otherwise, you must decide
what you will be booting to decide what you want to load.

For a BIOS-based boot, there's the possibility of using BIOS calls to
load the device in such a way that when you jump to the kernel, the
devices are used as if they had been loaded.

Using a VM86()/OpenFirmware based driver almost cries out for the ability
to tag segments as "initializtion,discardable" to recover the memory into
the kernel memory map after boot.

> 
> On the pci-sig mailing list, it seems many BIOS makers are putting in
> a Micro$oft configuration mode which only configurations "boot" devices
> and then expects the PnP O/S to call into the PCI BIOS to finish 

This make sense, but seems to lock out Apple, IBM, and Motorolla.  Either
there will need to be processor as well as VM86() mode emulation, or there
will need to be some serious driver writing if this becomes common.

The "OpenFirmware" mechanism for this is supposedly a FORTH program in
the ROMs so that it doesn't matter what processor is doing the "BIOS" calls.

> Only if said port address was dynamically assigned to the device,
> if the port (or memory) address is fixed then that address should
> not be released.

An important point.  Device with static address mappings must be considered
to always be present if they are installed hardware.

Removable hardware (PCMCIA), however, could in fact change this mapping
by switching between two  devices with fixed mapping addresses which
overlap, but which will never be present at the same time.

I think it's important to distinguish between devices that are physically
and virtually present when calculating address/io/IRQ/DRQ space collisions.

> Note that if there was a conflict, the configuration manager should
> have never bothered to call the attach routine.

With the caveat of virtually present but physically missing devices (above).

> > A destructive probe should be limited to a "add hardware mode".  Just like
> > Windows 95: a user triggered event or an install triggered event that does
> > not repeat each boot.
> 
> In my mind, if a user configures a device (such the probe and/or meta_attach
> is bypassed) and then the attach routine is called, the attach is allowed
> to do the equivalent of a destructive probe since it unconditionally owns
> those resources.

I think that relocatable devices will not be destructively probed because
of card services doing mapping notification.  On the outside chance, however,
that this is not the case, virtualy present devices could become quite a
problem if you make the above assumption.

> The database created by the configuration manager and filled in by the probes
> and refined by the meta_attaches must be non-volatile and independent of the
> kernel.  Note that this means that either the resource information in the
> config file disappears or config will need to able to write out a resource
> database file.

This is the function performed by the registry in Win95, and accessed
via kernel level file I/O.  I think it is imperitive to consider at least
a multistage (by bus type) two pass (by device classifiaction: boot device,
not boot device) probe sequence.

This may require the ability to dynamically relocate a relocatable device
(like a PCI SCSI controller) by stopping all outstanding I/O, detaching
it at its present location, and reattaching it at the new location.

How you would deal with this for non-disk boot devices becomes a real
issue, but I think it is sufficiently limited in scope (ie: what are you
really allowed to boot off of anyway?) that it's generally soluable.

> The boot loader will need to able to read this configuration database and
> put it into memory along side the kernel image.  Userconfig could then
> either stay in the kernel or become a separate entity.  Actually, it might
> even make sense for userconfig to become the second-stage loader since it
> will have the proper information to do it.

The use of firmware-based fallback drivers would be better.  Otherwise you
will end up with a chicken-and-egg problem to resolve.  The firmware is
guaranteed to be present, since it is the code that loads the second
stage boot image itself.  The ability to do kernel level file I/O could
leverage the two pass model (described above) with the firmware to get
you to that point.  This alleviates the need to make the boot loader
so smart that it is inconvenient to write in the first place.

The second stage boot will probably need to leave kernel accessable
routines around to allow the kernel to do firmware based I/O.  This 
would have the advantage of divocing the device and kernel architectures
from one another, if the mechanism was sufficiently general (ie: the kernel
is passed the address of a function vector list at startup to allow us
to abstract the firmware interface from its implementation).  This is
how the Motorolla "bug" firmware worked on 68K machines, and how it
currently works on their non-OpenFirmware PPC machines.

So the firmware boots the boot code, which is either a selector or a
second stage boot locator or the second stage boot code itself, and
the second stage boot contains firmware interface vectors to load
the kernel and allow the vectors to be accessed by the kernel.  The
kernel itself is unaware of the boot mechanism used to load it, so the
only thing that changes from a PPC Ultra 603/604 to an IBM RS/6000 43P
to an Apple CHRP box is the second stage boot.


					Regards,
					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510132301.QAA18445>