[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
-----Original Message-----
From: Richard Walter [mailto:rwalter@brocade.com]
Sent: Wednesday, March 13, 2002 4:48 PM
To: 'WTX@umem.com'; pci-sig@znyx.com
Subject: RE: Multiplatform & UDI
Folks,
For multi-code image in expansion ROMs, please, please read section 6.3
of the PCI 2.2 spec. There it spells out exactly how to do this in a
standard manner.
The whole point of expansion ROMs is to provide "driver" support before
an OS is loaded. You should not put OS drivers in the expansion ROM.
OS drivers should be stored with the OS.
Why do you need driver support before the OS loads? 1) If you are
needed to monitor and/or configure the boot process (video cards, input
devices (keyboards)). Or 2) If you are the device which is used to boot
the OS (SCSI, IDE, network).
These devices need to have "drivers" loaded pre-boot that exist
independent of the OS to be booted. Some of these devices are so well
known and have institutionalized interfaces that their drivers have been
incorporated into system boot ROMs and don't need special device ROMs.
(ie: IDE, PS/2 keyboard, vanilla VGA). Other devices aren't
institutionalized yet and so need vendor supplied drivers to incorporate
that functionality. (ie: SCSI, networking, Fibre Channel).
Access to different images in expansion ROMs must be done in a standard
manner because the system ROMs that find the right image have no
knowledge of your specific device. Hence section 6.3 of the PCI spec
which details how to design multi-image ROMs so that system ROM can get
the image that it wants (and conversely, it details how a system ROM can
find the correct image it wants out of a multi-image expansion ROM).
Now, for specific answers to the questions that were originally asked:
> 1. Is there any PCI specification for cards with multi platform
capability?
> (ie: a single PCI that card can be used on PC, PowerPC, Alpha etc)
Yes. The PCI spec defines requirements that are independent of any
architecture.
> 2. If there is a BIOS software on Read Only Memory / ROM chip on the
card,
> is it possible to put multi platform software on the ROM?
Yes. See section 6.3 of PCI 2.2 on how to do this.
> 3. What is the relation between UDI project and PCI-SIG? Can UDI
support
> multi platform capability on PCI bus?
Don't know. I don't represent the PCI-SIG. From a quick (2 minute)
perusal
of the UDI web site that you had a pointer to, it looks to me that they
are
defining an interface for during OS runtime. That has didly-squat to do
with expansion ROMs in a PCI device. (Although I'm a hardware guy, not
an
OS expert, so you can give this answer as much (or little) credance as
you'd
like... :) )
> 4. Is there any software that make it easier to write multi platform /
> multi CPU BIOS for a PCI card?
Yes. Open Firmware is a platform independent standard for dealing with
device specific option ROM code, so you only need to write your code
once
for it to work on many different platforms (which does not include
legacy
x86 BIOS, however). Look for Open Firmware vendors for more info.
> 5. Is there any "Platform specific" PCI card that cann't be used on
system
> with non X86 CPU?
Almost surely there are. However, this is not due to PCI limitations,
but
because the card vendor has decided to not write an option ROM image for
anything but x86 BIOS (or has decided to not write an OS driver for
anything
but Windows).
> 6. There are several PowerPC based motherboards such as APPLE, BEBOX,
> AMIGA ONE, PEGASOS etc. Is there any guarantee that PCI card for one
> PowerPC board will be compatible with other PowerPC board?
Again, for hardware compatibility, I think that you're probably on safe
ground that it will work. Software is another matter.
Let's say you want to pick a SCSI card for some given system and some
OS.
The vendor of the card may or may not have written an expansion ROM
image
for your system firmware. The vendor may or may not have written a
driver
for your OS.
This means that there are 4 options:
1) No expansion firmware, No OS driver.
You're hosed. The card will not work at all in this system.
2) No expansion firmware, Yes OS driver.
You can't boot from a disk attached to this card, but once the
OS is
up and running, it should be able to see disks attached for data
storage.
3) Yes expansion firmware, No OS driver.
This is weird. You might be able to boot from a disk attached
to
this card, but you might not be able to read anything from it once
you're
up. This heavily depends on the sofware model of the OS and whether it
can
call back into firmware during run time. (NT, for example, doesn't).
Also,
during the boot there comes a time when the interface between the OS
loader
and the card will be transferred from the system firmware to the OS
driver
and if there is no OS driver then that transferral might stop the boot
process in its tracks.
4) Yes expansion firmware, Yes OS driver.
This is fine. You can boot from the device and access things
during
run time.
I've been making a very clear distinction between OS runtime drivers and
expansion ROMs on PCI cards. The one time that this clear division
might be
violated is during hot-insertion. At that point, it might be reasonable
that the OS might want to run some initialization out of the option ROM
on
that card prior to loading the OS driver for that card. However, that
is
heavily OS dependent and it seems equally reasonable to put the burdon
on
the OS driver to determine if an option ROM executed or not and do the
equivalent initialization in this situation such that the option ROM may
not
have been executed. This is highly OS dependent.
Sincerely,
-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 10:28 AM
To: pci-sig@znyx.com
Subject: RE: Multiplatform & UDI
Hi,
I would like to tell you a technique that can be used to read
multi-platform ROM if you are a board original designer.
1. PCI board Configuration ROM address is at 0x30 in Configuration
Space. It contains the system memory address that cover all ROM space.
Any software reading operation addressed to the space will get the ROM
address. It doesn't involve any driver's job.
2. Setting up a new PLATFORM register in your board register area that
may be another small memory space defined by BARx area in PCI board
configuration space;
3. When reading ROM operation starts, the board provides ROM contents
for different platform based on the PLATFORM register value that should
be initialized by your board driver to set platform type. Where and when
to set up the PLATFORM register is a question to driver writer and
varies from platform to platform.
4. So every platform will get its unique ROM without any confusion after
the PLATFORM register is correctly set.
Weng
-----Original Message-----
From: no spam [mailto:nomorespamx@lycos.com]
Sent: Friday, March 08, 2002 7:49 PM
To: pci-sig@znyx.com
Subject: Multiplatform & UDI
Hi
I want to ask about multi platform capability of
PCI cards (multi CPU type):
1. Is there any PCI specification for cards with
multi platform capability?
(ie: a single PCI that card can be used on PC, PowerPC, Alpha etc)
2. If there is a BIOS software on Read Only Memory
/ ROM chip on the card, is it possible to put
multi platform software on the ROM?
3. What is the relation between UDI project and
PCI-SIG? Can UDI support multi platform capability
on PCI bus?
http://www.project-udi.org
4. Is there any software that make it easier to write
multi platform / multi CPU BIOS for a PCI card?
5. Is there any "Platform specific" PCI card that
cann't be used on system with non X86 CPU?
6. There are several PowerPC based motherboards such
as APPLE, BEBOX, AMIGA ONE, PEGASOS etc. Is there any
guarantee that PCI card for one PowerPC board will
be compatible with other PowerPC board?
Thank you.
2,000,000,000 Web Pages--you only need 1. Save time with My Lycos.
http://my.lycos.com