RE: Multiplatform & UDI

["Weng Tianxiang" <WTX@umem.com>]

Hi Richard,
1. The special register is not used in my later email. 
2. No software is used to write the register. Instead to use hardware
jump.
3. My scheme is useful when OS cannot recognize the 2h-17h in page 207
of PCI section 6.3. It doesn't define the value for all OS in PCI 2.2. I
don't know if they are really defined. If the field is defined well for
all target OS, my method has no merit. If not, my scheme is the only one
that can work.

Weng

-----Original Message-----
From: Richard Walter [mailto:rwalter@brocade.com] 
Sent: Thursday, March 14, 2002 4:51 PM
To: 'WTX@umem.com'; pci-sig@znyx.com
Subject: RE: Multiplatform & UDI


Weng,

Yes, your scheme of using a special register to select which one of many
images actually appears through BAR 0x30 does not violate the PCI spec.
You're essentially building a custom structure on top of the standard
expansion ROM access method.

However, it adds no additional functionality over what section 6.3
already provides.

It requires additional hardware to support the extra special register
and it's use when accessing BAR 0x30.

And, (worst of all) is completely and totally useless in a generic
system because it will never be used.

Why will it not be used?  Because in order to access your special
selection register, you will need special software running on the host
(because your special selection register is not defined in the spec so
no general PCI software will attempt to use it.)  Where does this
special software come from?

If this is running pre-OS, then the only way to get that special
software is from an expansion ROM.  But we're trying to read the
expansion ROM so we can't use the code in the expansion ROM to access
the expansion ROM itself.

If this is running within an OS, then this special software is
essentially driver code that was loaded from the OS location by the OS.
But if you're already running an OS driver why would you be accessing
the expansion ROM to get an OS driver?

Also, the expansion ROM should NEVER contain OS drivers.  OS drivers
should be stored with the OS and loaded by the OS.  Why?  Because the OS
defines a standard method for loading drivers.  And no general OS looks
for PCI expansion ROMs to load drivers from.

So, in summary, your suggestion has no merits and has additional costs.
Why would anyone implement that?

-Richard Walter
Senior Hardware Engineer
Brocade Communications Systems
rwalter@brocade.com
Note: I speak for myself, not for Brocade Communications.


-----Original Message-----
From: Weng Tianxiang [mailto:WTX@umem.com]
Sent: Wednesday, March 13, 2002 5:08 PM
To: pci-sig@znyx.com
Subject: RE: Multiplatform & UDI



Hi Richard,
My answer to the question 2. has no errors at all and totally comply to
section 6.3.

1. All image is to be set up just like PCI 2.0 Section 6.3. 
2. The largest ROM size to return when reading 0x30 (Configuration
space)(by writing all '1' first) is the ROM largest unit size, not total
ROM size. 
3. The memory address to return when reading 0x30 (Configuration
space)(not follow writing all '1' first) is the ROM unit start address. 
4. Jumps can be used to specify which OS is to be used;

If so arranged, the ROM read from system is always the ROM unit that
fits for the OS.

If doing so, not only it saves logic in hardware, but also saves
software additional work.

Weng