From owner-freebsd-current Mon Mar 11 23:27:34 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id XAA10344 for current-outgoing; Mon, 11 Mar 1996 23:27:34 -0800 (PST) Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id XAA10319 Mon, 11 Mar 1996 23:27:30 -0800 (PST) Message-Id: <199603120727.XAA10319@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: Host localhost.cdrom.com [127.0.0.1] didn't use HELO protocol To: Terry Lambert cc: stable@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: The continueing 2842/eisaconf argument In-reply-to: Your message of "Sat, 09 Mar 1996 12:40:23 MST." <199603091940.MAA21251@phaeton.artisoft.com> Date: Mon, 11 Mar 1996 23:27:29 -0800 From: "Justin T. Gibbs" Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk You'rre probably right that most people aren't that interested in this discussion, so I'll make this my last note on this subject and let the source code speak for itself when I get to writing it. >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. Okay, provide the code. 8-) >> 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. You seem to think that the eisaconf code could read the data and make any sense of it on its own. It can't. The ECU has the luxury of eisa configuration files to parse and tell it how to interpret the data. In FreeBSD, the device driver will have to know, so unless you want to compile eisa configuration files into the kernel you will always have to push eisa configuration space manipulation down into the driver (it calling the eisa configuration space manipulation API provided by eisaconf). >> 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. How else do you find them? How else do you find the 2842? >> 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. I can't parse this. I don't think AMI is going to be dropping me a new version of their ECU software anytime soon. Without the EISA ID or a "saved to disk" current configuration file, I don't think the ECU knows anything about the card. Remember that the ECU keys off the EISAID found at each slot to determine the eisa configuration file to read in so it can interpret the configuration space for the device. The ID for the last configured device is also stored up there so it can be matched to the device in the current slot. Other than the stored ID, I don't believe that there is any other data stored in a common format for the ECU to interpret... just a series of port addresses and data values to write out during initialization fothe EISA bus which could affect any of a number of different types of settings on the card. >> 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. If you can't even get to the BIOS, FreeBSD can't help you. Someone who does this ends up calling Adaptec's technical support line who in turn will refer them back to page one of the user guide where it tells you in bold print to set the ID to be the same as for the slot its in if you install it in an EISA system. This has nothing to do with this discussion since FreeBSD cannot create or fix this situation. >> 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. Only by asking the device to interpret the data for you. I can give you the same information for a 2842 and export it to eisaconf the same way the 2742 does and it doesn't matter that the 2842 never looked at configuration space. Your still thinking that eisconf can do the relocation without consulting each driver... It can't. >> 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. The configuration space doesn't tell you "all the possible places I can be set to." It tells you what registers on the card were set with what bits during boot. Nothing more. The driver still has to be the one to interpret the data. >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. How else do you find them? I'll lend you my 2842 tech ref so you can tell me another way. :-) >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? People who don't read the installation instructions get hosed. Its not unlike most PC hardware. >> 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. As I've pointed out before, it doesn't matter where the driver gets the data as long as there is a facility for it to inform the configuration manager of what capabilities it has. >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. It has to go through the driver anyway. >> 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. Sure they do. THe driver says that you can change its irq to X,Y, and Z, but that its baseaddress is fixed. This is exactly the same info that you get from the 2742. What information can't I give and why can't I? >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). This is easy to do regardless of the fact that the 2842 is treated as an eisaconf device since as far as I know, there are no VL Alpha machines. >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. When you don't have an eisabus or a 2842, the module is unloaded. >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. Again, if you don't have a 2842 or an eisa motherboard, the module is unloaded. >Requiring the EISA code to probe it prevents discarding the EISA >bus attach, or only performing the bus attach when the bus exists. 8-(. If the EISA probe turns up false, there is no 2842. How does this prevent discarding the EISA lkm after its probe? > Regards, > Terry Lambert > terry@lambert.org >--- >Any opinions in this posting are my own and not those of my present >or previous employers. -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations ===========================================