Note : Les descriptions sont présentées dans la langue officielle dans laquelle elles ont été soumises.
~Z~06
1. Field of the Invention
This invention relates to the f~eld of automatic resource
configuration systems for computers.
2. Prior Art
Computers, and especially micro-computers, in existence
today often allow the user of the computer to configure the
resources available on ~he computer to meet his or her
particular needs. For example, a user requiring additional
memory may purchase an add-on card. The memory is, by example,
plugg~d into a slot on a motherboard such as in certain Apple II
qeries computers. One computer may be configured with cards to
run a color graphics monitor whlle another has cards to run a
monochrome monitor. In computers that axe speci~ically built to
accept these add-on cards, lt lq necessary that the central
processor is aware of what type of card i9 in each available
slot.
Several methods are ut ilized to allow computer systems to
determine theIr installed resource configuration at the time the
computer ystem i8 powered on. In Rome computer systems, a
system administrator must manually define to the computer ~ystem
the available resources by keying into the system resource
def~nitions and addresses. Another method involves setting
switches on the add-on cards to identify the resources on the
card to the computer.
Ths most pertinent prlor art known to the applicant i8
Texas ~nstrument's~ NuBus system. The NuBus system involves a
bu3 with 32-bit addressing capability (4 gigabyte-q). By ~ystem
r K
; ` I ~.2~Ç~806
l convention, the upper 256 megabyteq of thi3 address space is
reserved for control space for card~. The control space is then
divided into sixteen 16 megabyte address partitions, Pach
assigned to one card installed on the system. Thus, the NuBus
addressing scheme supports up to sixteen cards in its dynamic
configuration methodology. Each of the sixteen 16 megabyte
address par~i~ions is further dlvided into a 128 byte
configuration ROM address space and the remainder of the 16
megabytes is available as defined by the individual card.
The 128 byte configuration ROM address space has fixed
addresses assigned for various information about the card such
as a serial numberl vendor identifier, card type, part number,
and address ofsets for such items as the configuration
register, device driver, diagnostic tools, etc. Thls convention
of dividing address space and utilizing address offsets allows
the device drivers, diagnostic toola, and other information to
be placed in the remalnder of the 16 megabyteq o~ memory and
allows this information to occupy varying amounts of memory
depending on the speciflc card type. In other words, a card
requiring a relatively large amount of device driver code and a
xelatively ~mall amount of diagnostic code could utilize memory
for each of the types of code in the amount required. Another
card requiring a relatively small amount of device driver code
and a relatively large amount vf diagnostic code could utilize
memory in the proportions required for it. A fixed amount of
memory is not required for device driver code, diagnostic code,
etc.
The configuration information resides on each card in the
system ln a read-only-memory (ROM) and is addressable as
~29680~i
1 descrlbed above. At the tlme the system is started, automatic
self-configuration, system self-test, and processor booting
occurs based on the information stored in these ROMs.
As will be seen, the present invention departs from the
above convention by allowing multiple resources to be defined,
instead of a fixed set in addition ~o other departures.
` i ~2~6~06
1 ~M~RY QF T~F.I~VENTIQ~
An improved method and apparatuY for automatically
configuring system resources on a computer i3 described. The
invention involves placing a configuration read-only-memory
~ROM) on each add-on card placed in the computer system. The
conflguration ~OM is assigned a set of addres~es within the
addressing sp~ce of the computer system. Wi~hin thi~ set of
addresses, a format header is located at one of a set of
definable addresses. The format headex contain~, among other
information, an offset to a directory of ~ystem resource
identities (Ids). The directory of system resource Ids contains
offsets to resource llsts whlch describe the variou~ resources
on the board. This method offers an advantage over the prior
art in allowing multiple resource~ to be defined to the system,
instead of a fixed set.
The format header contains information such as which byte
lane(s) the card will be using, a test pattern for validating
the format header, a revision level indicator, a checksum value
for validating and determining whether errors exist on the
conflguration ROM, and a length field for specifying the lowest
address used by the declaration RO~, in addition to the
directory offset.
The bus for communication between the various cards and
central processor is divided lnto a num~er of byte lane~, each
2$ lane capabl~ of carrying data between the components of the
~y~tem. The format header contains data describing which of the
byte lanes will be u~ed by the card. The card may use any
combination of the availabl~ ~yte lanes. At the time the -~ystem
1 io powexed on the address of the format header on each board i5
determined and then the configuration and resources of the card
are read by the operating system.
The length field specifies the lowest addres3 in the
address space assigned to the card which is used by the
configuration ROM. This leaves, for other needs, the remainder
of the available memory.
It is one object of this invention to provide a method of
allowing a computer to determine its resource configuration at
the time the computer is powered on.
It is another object of this invention to provlde a method
of determining the address of the format header depending on
which byte lanets) is/are used by the card.
It is another ob~ect of this invention to provide a method
o* determining addresse~ of the configuration data depending on
an offset value in the format header.
It is a further ob~ect of this invention to provide a
method of using a re~ource directory and resource lists to allow
n resources to be deflned for a glven card.
~961~30~
1 B~l~E-nE5~ TIoN OF T~E D~a~
Figure 1 is a diagram illustrating a prior art convention
of assigning address space in a computer system.
Figure 2 is a diagram illustrating a convention of
as3igning address space in the present invention.
Figure 3 is a block diagram illustrating a method of using
offset pointers to allow n resource lists to be defined for a
card ~n a computer in accordance with the present inventlon.
.,
Figure 4 is a diagram illustrating a format header and its
oontents within the teachings of the present $nvention.
Figure 5 is a diagram illustrating a resource d~rectory and
its contents a~ taught by the present invention.
Figure 6 1~ a diagram illustrating a resource list and its
contents as taught by the present invent~on.
lS F~gure 7 is a flow diagram ~howlng a method of determining
a confiquration when a computer is started ln accordance with
the present invention.
F~igure 8 ls a flow diagram showing a method o~ determining
whether the start of a format header has been found in a
configuration memory as taught by the present invention.
:
,~;, .
1 Figure 9 is a flow diagram ~howing a method o~ reading
~esource directories and resource lists in a configuratlon
memory as disclosed in the present invention.
Figure 10 illustrates byte lanes combinations and
corresponding byte lane values and format header starting
addresses used in the preferred embodiment of the present
invention.
6~(~6
1 E~ En-n~Rlp~l~N OE ~HE PREsEN~ I~y~Io~
A method and apparatu~ for automatically determining the
re~ource configuration of a computer i~ disclosed. In the
followlng description, numerous specific details are set forth
to provide a thorough understanding of the present inventlon.
It will be obvious to one Qkilled in the art that the invention
may be employed without the pecific details. In other
instances, well-known methods and s~ructures have not been set
forth in order not to unnecessarily obscure the present
invention.
Figure 1 illustrates Texas Instrument's NuBu~, the most
pertinent prior art known to the Applicant. The NuBus ~ystem
involves a bus with 32-bit addressing capabillty (4 gigabytes)
1. The upper 256 megabytes of this address space ls reserved
for control space for boards 3. The remaining 3840 megabytes is
used for global memory space 2. The control ~pace 3 is further
divided into sixteen 16 megabyte partitions 5. Each of the 16
megabyte portions 6 are then further divided into a 128 byte
configuration read-only-memory ~ROM) 9 and an area for other
data 8.
The 128 byte configuration ROM 9 has fixed addresseY for
various information about the card such as a ~erial number,
vendor identifier, card typet part num~er, and address offsets
for such items aQ a configurat-lon register, device driver,
d1asnostic tools, etc. The method allows for off~ets to
~nformation regarding only a fixed set of resources.
~ eferring to Figure 2, the convention for asslgning address
~pace ln the preferred embodiment ls disclosed. The preferred
z~
1 embodiment is capable of addxes~in~ 4 gigabytes of memory, block
20. The lower 3840 megabytes of address space 22 (addresse~
0000 0000 through EFFF FFFF hexadecimal) is u~ed for random-
access-memory (RAM), for read-only-memory ~ROM), for super slot
space, or is reserved for future use. The upper 256 megabyte~
21 ~addresses FOOO 000~ through FFFF FFFF) i5 used for access~ng
cards and for their configuration memories. The preferred
embodlment uses a read-only-memory ~ROM) circuit as its memory
means, although it will be obvious to one skilled in the art,
alternate means may be available.
The upper 256 megabytes 21 is further divided as shown in
F~gure 2, block 24. The preferred embodiment currently has
defined slot space for six cards, labeled 9 through ~,
hexadec~mal. Each card is assigned sixteen megabytes of address
apace 26. Referri~g the Figure 2, block 27, the sixteen
magabytes of address space 26 assigned to each card is fuxther
divided by convention into an area ~or a format header 29 and an
area for other code and data 28 such as a resource directory,
resource lists, and resource code and data. This information,
collectively, makes up the configuration ROM 27. The remalnder
of the sixteen megabyte space 30 is used for other system needs.
The first byte of the format header 29 must reside in one of the
upper four bytes of the slotspace reserved for that card. That
is, ~he format header must have its ir~t byte at address FnFFF
FFFF hexadecimal to FnFF FFFC hexadecimal (where n ~s the slot
number).
Figure 4 describes the format header 29 o~ the preferred
embodiment. The format header 29 consists of the byte lanes
fleld 42, a reserved fleld 43, a te3t pattern ~ield 44, a ~ormat
1 field 45, a revision field 46, a cycllc redundancy check (CRC)
fleld 47, a length field 48, and a directory offset field 49.
The byte lanes field 42 tells the computer which of the
byte lanes on the bus to use when communicating with the card's
con~iguration ROM 27. The preferred embodiment uses a bus with
four byte lanes numbered 0 through 3. This technique allows the
card designer to place the configuration ROM 27 in any
combination of the four byte lanes, thus allowing him or her
greater flexibility in his design than prior art method which
require the configuxation ROM's fleld~ to be at fixed addresses.
Figure 10 lists the valid byte lane values 103, and byte
lane combinations 101 which may be used, and corresponding
format header starting addre3ses 105. The value of the byte
lanes field, Figure 4, block 42 may be computed by setting a bit
in the low nibble of the byte lane field 42 for each byte lane
used and then setting the high nibble of the byte lane~ field 42
to the low nibble'~ complement. For example, if a card's
configuratlon ROM 27 used byte lanes 0, 1 and 3 when
communicating with the compute.r, the low nibble of its byte
lanes field 42 would be set to 1011 binary. The high nibble
would then be set to the low nlbble's complement or Q100 binary,
yielding a value for the field of 0100 1011 binary or 4B
hexadecimal. The format header 29 would then sta~ at address
F~FF FFFF hexadecimal, where n 1.~ the slot number for the card.
Referring still to Figure 4, the second byte of the format
header~in the preferred embodiment is a reserved field 43 and
mu t be set to hexadecimal 00. The next four bytes of the
~ormat header are a test pattern 44 used to ~nsure that a valid
byte lane value was found. The preferred embod~ment, by
~29~
l convention, requires this field to be set to SA932BC7
hexadecimal. These values are used by the current preferred
embodiment, however, it will be obvious to one skilled in the
art the values may differ 1A another embodiment without
departing from the spirit of the ~nvention.
The format field 45 identifies the configuration ROM 27
format. The current preferred embodiment allow~ only one value,
01 hexadecimal, in this field. It will, however, be obvious to
one skilled in the art that more values could be assigned as
more ~ormat types are defined. The revision level f1eld 46
~denti~ies the current RO~ revision. Currently, the preferr~d
embo~iment will accept values in the range of l to 9.
The next four bytes are the cyclic redundancy check ~CRC)
field 47. This field contains a check um to allow the
con~iguration ROM 27 to be validated. It is computed by
applying a 32-bi~ rotate-left-and add function to the number of
bytes specified by the length field 48. Only ~ytes in by~e
lane~ specified by the byte lanes field 42 are used to calculate
the CRC field 47. In making the CRC computation, the value of
the CRC field 47 itself is treated as 0.
The length field 48 con~ains a value specifying the number
of bytes from the configuration ROM's 27 starti~g ~ddress to the
lowest-address byte used by the configur~tion RO~ 27. The
remainder of the address space reserve~ ~or t~e car~ is then
ava~lable for other uses.
The directory offset value 49 specifies the offset from $ts
address to the address vf the resource direetory, Figure 5,
block SO. It counts only byte3 in the byte lanes belng used.
11
6~ 6
1 Referring now to Figure 3, the directory offset value is
used to determine the address of the resource dlrectory 50 for
the card. The resource directory 50 will have an addres~ within
the slot space for the card (addresse~ FnO0 0000 through FnFF
FFFF h~xadecimal, where n is the slot number for the card,
except for the space allocated to the format header).
The contents of the resource directory 50 are shown in
Figure 5. The resource directory 50 con~ains an entry for each
resource list, listed by resource Id 51, in the card's firmware
and provides an offset 52 to each resource list, Figure 6, block
60. The preferred embodiment allow~ resource Ids 51 in the
range of 0 to 254. The range of 0 to 127 are reserved for
resource lists 60 required by the computer, while 128 to 254 may
be assigned by the individual card designer. The last entry 55
in the resource list 50 must have an identification number of
255 and an offset value of zero and indicates the end of list.
This method of allowing between 1 and 255 resource lists for a
card offers the card designer flexibility not available in Texas
Instrument's NuBus System. The Texas Instrument's NuBus system
allows a fixed number of predefined resource types to~be defined
and has offRet pointers ln the format header. The preqent
invention provides a well defined mechanism for independent
expansion by the individual card designer.
Again referring to Figure 3, the offset value~ 52 in the
resource directory S0 point to resource lists 60. The content-Q
of the resource lists 60 are further detailed ~n Figure 6. Each
resource list 60 con~ains a set of references to ~nformation
about a single resource. This information must include the type
61 and name of the resource 64. It may al~o include reference
~2
~9~ 6
1 to information regarding the resources icon 66, drivers, and
other parameters 67. The resource list 60 includes an
identification number 63 for each entry and an offset 62 to the
information. The identification numbers 63, in the preferred
embodiment, must be in the range of O to 254. The number3 0 to
127 are reserved for assigned entry types and the number-~ in the
range of 128 to 254 are available to the individual card
d2signer as needed. The last value 69 in every li5t mu5t have a
value of 255 indicating the end of the list. As~oclated with
each identif~cation number is an o~set value giving the address
of the information.
~ igure 3 shows use of the offsets 62 in the resource lists
60 to point to the code or data 31 a~sociated with the entry.
The preferred embodiment requires one special reQOurCe list
for all cards which will communicate with the computer called a
board resource list. Thi-~ resource li t providas the computer
with the cards indentification number, vendor information, board
~lags, and initlallzation code.
At the time the computer is started a two stage process
takes place. Fir~t, each slot is checked for the presence of a
card and if one is found the format header is read and pertinent
information from the ~ormat header ~s ~tored in a table. Then
informatlon about each resource 1s read and Qtored in a second
table and lnitialization code for each slot is executed. Th~n,
the second stage reads pertinent information about the driver
and stores the information in the secon~ table.
~ eferring to Figure 7, the computer starts the automatic
resource configuration process by determining a fir~t slot to
examine, block 70. A first byte lane to examine ls selected,
13
~29Ç;8(~6
1 block 71. The present invention lnspects byte lane 3 first
becau~e the greatest number of byte lane combinations 101 will
have a format header starting address 105 in this byte lane. A
check ls made to see if the beginninq of the format header 29
for the card in the first ~lot is in the first byte lane, block
72. If the beginning of the Format header was not found, branch
73, a check is made to determine if there are more byte lanes to
search for the current card ~lot, block 76. If there are, the
byte lane value is changed to the next byte lane to check, block
75, and that byte lane is checked fox the beginning of a format
header, block 72. If there were no more byte lanes to search
for the current card slot, an error i~ recorded ~D a table,
block 77. If there are more slot~ to be checked, block 74, the
slot number being checked is incremented, block 79 and the
process i~ repeated.
Referring to Figure 8, a method used by the preferred
embodiment for checking if the beginning of the format header
ha~ been found ls disclosed. First, the byte lane~ code field
i~ examined, block 80, to determine whether it contains one of
the valid byte lanes code as listed in Figure 10. If the byte
lanes code ~Is invalid, branch 81, the beginning of the format
header was not found in this byte lane 89. If the byte lanes
code $s valid, branch 82, the test pattern field i5 exami.ned,
block 84, to determine whether it contains the valid test
pattern. If not, block &5, the beginning of header was not
~ound in thi~ byte lane. Otherwise, if the valid teqt pattern
was found branch 86, it indicates the start of header was found,
block 87.
14
.
Qf~
l After each slot is searched for a format header 29 as
described in Figures 7 and 8, slots with a valld format header
29 are examined. ~he resource directory 50, resource lists 60,
and other information is read and data such a~ the reference
txpe and hardware device identifiers are stored in a table.
Referring to Figure 9, the process for reading resource
directorie~ 50 and resource lists 60 is diqclo~ed. First,
several edits are performed. The reserved field is examined to
insure it is set to zero, block 90. The format field is
~xamined to insure it contains a valid format code, block 91,
the revision field is examined to verify it contains a valid
revis~on level, block 92. The C~C value is examined to insure
it contains the correct value, block 94. If any of the edit~
fail an error condition is recorded, block 99.
lS The address of the resource directory is determlned from
examining the o~fQet value in the directory off~et field of the
format header, block 95. Then, for each entry in the resource
directory, the resource list referenced by the offset i8 read
and pertinent information stored ln a table, block 97.
2~ After the pertinent reaource information from each resource
list on each card has been read and ~tored~ the computer has
completed the automatic resource cDnfiguration process. Each
card installed on the system has been identifled by its
identification number, vendor information, and card type and
information on initialization code, device drivers, ~c. has
been determined.
The present invention offers a number of advantages over
the prior art. First, only the 20 bytes of the format header 29
need be located at a predetermined location in the addres~
~'~' ' '
~2~6~36
-
l space. The pr1or art addressing qeheme requires locating 128
bytes of header informatlon 9 in a fixed location. Second, the
configuration ROM 27, including the format header 29, may be
located in any combination of the available byte lanes. The
card deslgner is not restricted to placing the configur~tion ROM
27 in a fixed location as in the prior art. Third, any number
of resources may be defined. The card designer iQ not limited
to a set number of resources as in the prior art. Fourth, the
prior art method determined resource type by setting bits in a
resource type field. Each bit indicated a different type of
resource. For example, settlng bit O indicates a memory
resource, setting bit 1 indicates a boot source, setting bit 2
indicates a LAN resource, settlng bit 3 indicates a monitor
resource. Using this method, as more resource types are added
additional bits must be added to this field. The present
invention utilizes an eight byte fleld containing a ~ode
identifying the resource type. This fleld i~ broken into sub-
fields, including a flag indicating the field type, a category
indicator describing the general category of the re~ource, a
-~ubclass indicator further dividlng the general category of the
resource and driver interface information. This list of
a~vantages is not meant to be exhaustive of the features of the
present invention, bu~ rather shows by way of example som~ of
the important improvements of the present invention over the
prior ~rt.
-
Thus, an improved method of and means for automatieallyconfigurin~ resources on a computer system ls dis¢losed.
16
,
- ~ ' ' '
;
1 Utilizing a configuration ROM and a convention for defln1ng u~e
o~ addre~s space, a method of determ~ning resource types and
other information at the time the computer system is started i~
disclosed.
,
17
~, .
