RE: Claiming 1M when using 8K

["B. P. Lame" <blame@prolog.com>]

On Wednesday, 16 April, 1997 08:24, Bob Huebner[SMTP:BOBHU@Attachmate.com] wrote:
> We have designed a PCI Adapter that requires 8K of memory space and 16 
> bytes of I/O space for a PC-based application.
> When the memory and I/O BARs are programmed to take 8K and 64 bytes 
> and the bits are set to allow them to be placed
> 'anywhere in memory', we have observed one BIOS that puts the 8K 
> memory space below the 1Meg limit.
> 
> Since this presents the problem of a possible conflict with Legacy ISA 
> adapters, we are now thinking of claiming 1M for
> both the I/O and memory BARs to force them into 'upper memory' and 
> prevent any possibility of a conflict with an ISA
> device. We have confirmed the BIOS in question now puts the memory 
> resource in upper memory.
> 
> The questions I have are:
> 
> 1. Why would any PCI add-in card want to be 'anywhere in memory' when 
> it allows the possibility of a conflict with a Legacy
> ISA Adapter?

Making your add-in device capable of being placed 'anywhere in memory' allows the greatest configurability.  

For PC's, the nature of PCI and ISA Plug&Play allows an endless possibility for conflict with many devices.  The burden of system resource arbitration and conflict free allocation has been placed on the BIOS and/or OS vendors.  If your device's memory and/or I/O space requirements are available without conflict below 1M, I see no reason why the BIOS or PnP OS should not place them there.  PnP compliant ISA devices should receive priority in resource allocation since they generally have less configuration options than PCI devices.  If the user has one or more non PnP compliant ISA devices, he is responsible for using the BIOS or OS Setup options to reserve resources for those devices so that they will not be allocated to other PnP or PCI devices.  If a conflict is detected during system configuration, the BIOS or OS should notify the user and allow manual resource arbitration and allocation.  If the BIOS or OS assigns conflicting resources between PnP and/or PCI devices, then it is non-compliant and the vendor should be notified.  If the BIOS or OS assigns conflicting resources between ISA and PnP or PCI devices and provides no method of resolving the conflict (assuming it can be), then it is faulty (though it may be PnP and PCI compliant) and the vendor should be notified.  

If you intend to provide driver support for your add-in device, you must ensure that your device drivers will work properly with the device in any possible configuration.  It might be nice as far a tech support is concerned if your device driver can gracefully notify the user if there appears to be a malfunction or resource conflict.  

> 2. Is there any possible problem with each card claiming 2M from the 
> 32G PCI pool? The maximum number of adapters
> we can put in a system is 16 (using expansion chassis).

I'm not sure.
 
> Seems like it would have been a better solution to have the bits in 
> the PCI BARs mean:
> 	Below 1M
> 	Above 1M - instead of anywhere
> Then, I wouldn't need to claim more memory than I'm using to force it 
> above 1M and eliminate the ISA conflict possibility.

Like I said, it's not your responsibility to worry about resource conflicts.  If the BIOS places your device below 1M, you should assume it's because that area is available.  

As to why the spec is the way it is, consider that some people view ISA as a convenient, low-cost way of attaching simple and/or slow peripherals and would like it to coexist with PCI.  On the other hand, ISA can be very limiting and some people would like it to go away because they don't need it.  And that the PCI spec was written by people from both these groups.

> Also, the PLX 9050 we are using has a fixed resource size of 64 bytes 
> for its configuration registers, so we can not 'force'
> this to be in upper memory and are at the mercy of the BIOS being 
> smart enough not to create a lower memory conflict.

You're not exactly at the mercy of the BIOS vendor.  No vendor wants to get a reputation for being incompatible and non-compliant.  The squeaky wheel gets the grease.

> Any feedback is appreciated.
> 
> Thanks,
> Bob Huebner
> 
> Mgr. H/W Development
> Attachmate Corporation
> 3617 131st Ave. S.E.
> Bellevue, WA 98006
> 
> email: bobhu@atm.com
> 
> tel.: (206) 649-6535
> fax: (206) 649-6200

-- 
Brooks Lame'
Engineer
Pro-Log Corporation
blame@prolog.com
408.646.3631
2H	7