Date: Sat, 9 Mar 1996 12:40:23 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: gibbs@freefall.freebsd.org (Justin T. Gibbs) Cc: terry@lambert.org, stable@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: The continueing 2842/eisaconf argument Message-ID: <199603091940.MAA21251@phaeton.artisoft.com> In-Reply-To: <199603090546.VAA22456@freefall.freebsd.org> from "Justin T. Gibbs" at Mar 8, 96 09:46:44 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >I don't think the major work of the probe for the VLB card is the > >scan of the EISA slot address space. It's getting the configuration > >information about the card, and that doesn't take EISA configuration > >data to do it. > > EISA configuration data (assuming you mean the stuff accessible through > BIOS calls) is not used by any driver in FreeBSD. Even if it was > accessible to FreeBSD (and there's no reason it can't be with VM86() or > having the boot blocks save off the data) it would have to be interpreted > by each individual driver in order to be of any use. So, although eisaconf > may some day provide a mechanism for accessing this data, it certainly > won't attempt processing it on its own. Every eisa card we support > provides some other way for either read/write or write only access to > the data the driver needs. The *only* reason you need the BIOS is to determine the per slot CMOS area size. Other than that, all EISA information is accessable as a memory reference from protected mode. I think the ability to access/manipulate EISA data is a lot closer than the ever-out-of-reach-VM86(). If nothing else, the ram area size *could* be passed via the boot code. > It has to be up to each driver to request and then interpret this > information if it makes sense for them to do so. Many cards could > care less about what's up in configuration space. The 3c579 is one, > the 2842 is another. If we have to support EISA devices that don't > want configuration data we can also support VLB devices that doesn't > use configuration space information with no additional complexity. > Its really a question of capability and use. I think this assumes you use real mode/VM86 BIOS calls to get the configuration data per EISA slot. That way you would have a built in stop for non-EISA cards. If you access via memory reference, as I would hope would be done, since VM86() seems too far off, then the stop isn't there. > The 2742 and the 2842 will continue to get most of the information > about the card in the exact same way regardless of the availibility > of configuration space data. You're also not talking about > stub code, but an additional probe that iterates through the slot > address space since the 2842 can't reference the eisa code in your > model since you don't want to have to have eisa0 in your config file. Excuse me. You are saying that iterating through the slot address space is the only way to detect if the card is present or not? I know it is the method that happens to be used currently. I wasn't aware that the card was otherwise undetectable. > I don't see forcing people to include eisa0 in their > config files as a problem since config will eventually die a horrible > death, and the aic7xxx lkm will export its lkm dependancy graph so > that if you don't have the eisaconf lkm in your system for some > strange reason, it gives you a nice warning message. If you can > talk about eisa configuration space, I think its fair for me to say that > config, in its present state, will go away. The use of LKM's for boot drivers requires fallback drivers (in this case, using VM86(), in other cases using OpenFirmware or PPCBug or the Mac ROMs, etc.), which don't currently exist. Further, I think they require a move to COFF or ELF format so that there can be an associated segment identification, and the fallbacks can be paged out and the memory reclaimed, once the device-specific LKM has been loaded. I think given these dependencies, I think it is also fair for me to argue for an evolutionary step in that direction. > Having an EISA config file doesn't mean that your ISA device responds > to accesses at 0xzc80 and provides an EISA ID. Correct. I never claimed this. It does provide a graph entry so that you don't screw yourself by locating one ISA card in an EISA slot over top of another by forfeiture of the ability to detect the non-relocatable resources being used by the ISA card. That's really all I'd have it used for as well. > Having the config file is simply a way of aiding the ECU > in telling you where conflicts are or restricing your configuration > settings. Once the ECU session is over, there's nothing their to > tell FreeBSD about these ISA devices. I will agree with the caveat the we are talking about the *current* ECU code. I believe the information that it does not have an EISA ID is sufficient to indicate the cards existance and the need to probe fixed cards with potentially invasive probes, at least the first time the hardware is auto-configured. This would require storing deltas and running a configuration/probe log, ala Win95, which we need anyway for Lance, Floppy Tape, PS/2 mouse, and other devices which can't be non-invasively probed 100% of the time (maybe including SIO3 vs. Mach cards). > You can switch the dip switches on your 2842 all day, and FreeBSD will > still find it. You can also move your 2742 from slot to slot all day > and FreeBSD will still find it. Relocating the card doesn't prevent > you from booting from it in either case so long as the card's bios is > enabled. Booting is a BIOS issue. I can make a 2742 not bootable > by disabling its BIOS too. It does if I relocate something over top of its address space because it didn't have a graph entry warning me it was there. This is the reasoning that was put forth for the probe order changes, which *have* caused some problems, but have overall been the *right* thing to do. > >I think that the 2842 needs to be probed later than the typical > >EISA, PCI, PCMCIA, and PnP ISA devices, like other non-relocatable > >devices. It think it needs to have an invariant configuration graph > >vector, *unlike* things which are found by the EISA probe. > > The 2742 is just as non-relocatable as the 2842. The 2742 locks out is irq > register after the first time its written to (by the EISA configuration > just after POST). This is irrelevant. EISA supports resetting this, in any case, or the card would be impossible to reconfigure with the Adaptec tools. The point is that even if an EISA space card has only one potential space utilization topology, it is intrinsically *different* from an ISA card because the slot configuration data (which is only present on real EISA and is not used currently) can be consulted to determine allowable potential topologies. > Most EISA cards can't relocate their I/O range, but the > Buslogic cards can relocate relocate their registers through a range of ISA > compatibily areas. The point is that the way you deal with registering > relocatability has to be generic so you can deal with devices that vary in > their degrees of flexibility regardless of their bus type. I agree completely. But while the per slot data provides this information for true EISA cards, it does not do so for VLB cards pretending to be EISA cards. > >I think it is incorrect to probe the thing as an EISA device (are > >there any motherboards that have EISA and VLB at the same time? > >That would be a good counter-argument...). > > Many, many EISA 486 systems have VL and EISA slots. I own one of these > systems. This is seriously damning of my idea to use the EISA tag as a negative indicator. It means that there *would* need to be probe code for VLB cards that pretend to be EISA cards. But it does not mean that the probe would have to take the form of a slot iteration. BTW: I'm curious: how does the thing avoid slot configuration conflicts in a real EISA system? How is the VLB "fake-EISA" data exported so as to not conflict with the real thing? What if I plug two of these things into two VLB slots in the same machine? > Not all EISA devices are relocatable in the same ways. I can find > plenty of EISA devices that have the same relocation deficiencies > as the 2842. This is not a valid argument. No, but all *real* EISA devices are detectably relocatable using the slot configuration data that doesn't exist for VLB devices pretending to be EISA devices. This is what I meant when I said the configuration process would have to dereference this data through the driver so that the VLB card driver could fake the information that wouldn't exist if the config attempted to access it directly without the indirection. I think this will be a bigger problem than card detection. > Not all EISA cards are relocatable after their first initialization. > We have to deal with these anyway. We can. But to deal at all, we have to have an idea of the relocatability, as noted above, and VLB cards pretending to be EISA don't give that. > No, it identifies it as an ISA device. And, some non PnP ISA cards > just like some EISA cards (EISA is not PnP BTW), allow you to dynamically > change the IRQ. So, what's your point? If we had a configuration manager > we woudn't allow flexible devices to conflict with non-flexible ones > which has absolutly nothing to do with the 2842 being probed through > eisaconf. I agree with this... my point is that EISA configuration should be autonomously seperable from the rest of the configuration. The bus attach should be on a per bus basis, and the lines shouldn't be blurred by probes that cross over allowed boundries. I think it should work on the order of SCSI bus attachment, per bus. I think it has to for the DEC Alpha AXP/PCI boxes: their ISA is bridged from the PCI, not vice versa, and I know PReP/CHRP require this, so machines based on the Motorolla chips have the same issue. I expect there to be Intel based hardware with the same issues soon (if it doesn't already exist somewhere). > >It can tell that you don't have an EISA motherboard, which is the same > >thing, by negative induction. > > Assuming EISA and VLB are mutiually exclusive which they are not. Right. I blew it here. But this is still resolvable by knowing how EISA/VLB slot address space export works. Per my "BTW" questions, above, it should be possible to use knowledge of how the conflicts are dealt with to allow detection of the thing as a VLB card. Other cards don't care about VLB vs. ISA, except in terms of giving us a hint as to why the machine is failing that we can then passs on to the user in terms of bus-on time management. > The 3c509 in eisa configuration mode must be probed through eisaconf > to be found. It is reported as an ISA device. If it *must* use the EISA probe, then I'd call it a "short EISA device". That it can also be an ISA device via rejumpering is irrelevant. It should probably be reported as an EISA device. > The 2842 is also found through eisaconf and is reported as an ISA > device. I still think this is the wrong place to probe it. > Both show up as ISA device in lsdev too since their kdc parents > are kdc_isa. Where does the 2842 get classified as an EISA device? By virtue of who makes the graph entry for it. It has to do with the wrong guy making the call. I can make generic assumptions about real EISA devices based on the per slot memory which is currently ignored, but shouldn't be (you yourself admit that the current code can't be the final code). > >> The match routines and forcing a scan of the eisa address space makes > >> no sense in a generic ISA probe (deals with non PnP hardware) configuration > >> sub-manager. > > > >I agree. Don't use the slot scan to locate the card; it isn't a > >substitute for the majority of the work done by the probe code anyway. > >Move the scan identification into an EISA-specific stub, and create > >an ISA specific stub for the non-relocatable VLB card. > > And I either make it always be in your kernel, or make it part of > "eisa0", or I duplicate it. What a waste. It's not a part of your kernel if you leave ISA out. > >I think you are stuck on using the fact that it exports EISA slot > >data to trigger the probe (the manority of which is not dependent on > >the fact that it's "EISA"). I think this is wrong, for the ordering > >reasons stated above. > > The ordering reasons don't hold water. Nothing is gained by postponing > the probe of the 2842. Its just as "relocatable" as other EISA devices > and its probe is non-invasive (and already performed by the eisaconf code). No, the problem with having an ISA (VLB) device probed by the EISA code is that the EISA code must know it's an ISA device and call a different registration mechanism for it, since EISA devices will be known to be relocatable and ISA devices not, in a future version of the device registration code. And it is caller dependent, unless you call through the device code for the registration to allow it to be device dependent. > >The VLB bus is not bridged. The agregate bus-on time for N VLB cards > >going in sequence is the issue for deciding to "tune" the VLB cards > >down. > > This as well as most tuning parameters should be left up to the user. > I don't see FreeBSD trying to modify your DRAM refresh rates. Its > counter intuitive for the user to go in and set the bus on time for > their adapter using the vendor supplied tools for this purpose > (EISA config utility for the 2742, SCSI-Select for the 2842) and > not have the OS honor them. Windows95 sets defaults, and you use the "System Properties" dialog's "Device Manager" tab to do tuning. You don't use the vendor-supplied tools, because doing so would not provide a unified control model to the user. > Your making up problems Terry. Probe order is determined by bus type. Except for the 2842. Augh. > Resource allocation is determined by the relative flexibility of devices > regardless of bus type. Yes. And bus existance is seperable for the purposes of causing a bus attach to occur, and you don't need to attach an EISA bus (or have the code taking space in the kernel) when you don't have an EISA bus on your machine. Ideally, returning to the future you pointed at, the bus attach will probe the existance of the bus, and load the code for it using VM86() based I/O, then probe the EISA controller through which it made the VM86() calls to load the probe code, and then load the controller probe for the EISA controller (again using VM86()), probe it, and if there, attach it and unload the VM86() fallback driver. Subsequent devices will be loaded through the card-specific driver. > >Precisely! > > > >Once you can manipulate the configuration space, EISA cards are as > >relocatable as ISA PnP cards! But this VLB ccard, which you lie and > >say is an EISA card by virtue of whose probe comes true, can *not* > >be relocated! > > Bullshit! ISA PnP cards can relocate their I/O area most EISA cards can't. > Some EISA cards do not allow relocation of anything after the EISA BIOS is > done. Furthermore, the data up in configuration space doesn't control the > settings of the card. You have to write to the cards own registers to do > that which FreeBSD already has the capability to do without having access > to configuration space. This goes back to providing a unified device management view. There is nothing that says that an intervening reboot might not be required for the management changes to take effect, or even to allow the use of invase probes for otherwise unidentifiable hardware. The ability to change soft configurations on a card that is soft configurable belongs, properly, in the driver for that card, with a single common configuration API shared by all drivers and a flag for whether a reboot is required, etc.. The advantage to doing this type of relocation is that it is possible to have a relocatable-without-reboot card that conflicts with either a non-relocatable-card or a relocatable-with-reboot card in its two available locations. Better to be able to put up a message about the conflict and allow the user choose to allow the configuration manager to reboot the system than to lose 2 of 3 devices to conflicts. > >You have to indirect all EISA configuration space code through the > >driver, and then call common routines for *all other drivers*, and > >for this one fake an immobile configuration space! Bletch! Talk > >about unnecessary complexity! > > This just isn't true. All devices can call the same functions to > register their resources, but it will only be at attach time that > they will know if they have to change their settings and to what. Then you must make registration variant so that the EISA code registers the card as an ISA card. This defeats the ability to seperate out (and discard) the EISA bus attach code on machines without an EISA bus, in all cases. It also defeats the ability to detect a go/no-go for EISA configuration automatically (which you would otherwise do by looking for the EISA tag). This isn't a problem now, but will be a problem if we allow bus attachment to be demand-loaded via fallback drivers to cause every running kernel to be ideally configured for the hardware it is running on (for instance, I don't want to have EISA or ISA or PCI code in an MCA machine, and I certainly want the ability to have a "pure PCI" box). > >EISA cards become relocatable within the conflict space. > > The 2842 doesn't prevent this. Requiring the EISA code to probe it prevents discarding the EISA bus attach, or only performing the bus attach when the bus exists. 8-(. > >Do you not agree that EISA cards should be relocatable by a resonable > >configuration manager that knows EISA? > > Sure. Eisaconf is already poised to do this and the 2842 will > fit right in there. The problem with "just class the 2842 as an EISA card for purposes of probe" is still the EISA bus attach, which will be mandatory for all ISA machines, since they potentially have a VLB bus, and we are changing the meaning from "EISA bus attach" to "EISA or VLB bus attach". At least we can ignore the EISA bus attach because EISA is detectable by the ROM tag... IFF VLB devices are classed as a special case of ISA, not of EISA, in all cases (including the 2842). > >Or that the 2842, a VLB card, should *not* be relocatable because > >there is no standard mechanism for handling an EISA relocation of > >a non-EISA card? > > Hey, you can change the 2842's IRQ so it will tell that to the > configuration manager. The 2742 cannot change its IRQ, and it > will tell the configuration manager that. If you can handle one > case, you can handle the other. The 2742's ability to change it's IRQ is reflected in the data from the EISA slot. For this registration to be automatic rather than dependent on the driver, it's necessary to seperate the identity of EISA and VLB cards. > Its not needed to support dynamic configuration of EISA devices. > The 2742 just like the 2842 will not be making any calls into > eisaconf to retrieve information from configuration space, so > it doesn't matter if there is or is not any configuration space > data for the 2742 or the 2842. Other drivers may have different > requirements. I think the user configuration utility (if we even consult the user on conflict resoloutions requiring a reboot, which we probably should) will need to be able to access this data based on registration class for the device. This means making the class variant based on which bus interface registered it, or setting the same flag in a per driver basis by making the registration process go through the driver to occur. Isn't this an obvious consequence of having a non-EISA card registered by EISA bus interface code? Anyway, this discussion is getting into the arcane details of design of generic configuration management, and has so moved out of the scope of general interest (I think). If we want to discuss this further, we should probably take it offline. I'm more than happy to let you control the code. I only wanted to voice my concerns that I believe it is better to spend some extra code seperating the bus identification from the probe and driver code for the 2842. I believe that it will save problems later. 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?199603091940.MAA21251>