patents.google.com

GB2203869A - Determining computer resource configuration - Google Patents

  • ️Wed Oct 26 1988

1 4 -1- COMPUTER RESOURCE CONFIGURATION METHOD AND APPARATUS,

BACKGROUND OF TER TNVENTION

1. Field of the Invention

This invention relates to the field 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-the 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, pluggpd into.a slot on a motherboard such as in certain Apple II series computers. One computer may be configured with cards to run a color graphics monitor while another has cards to run a monochrome monitor. In computers that are specifically built to accept these add-on cards, it is necessary that the central processor is aware of what type of card is in each available slot.- Several methods are utilized to allow computer systems to determine their installed resource configuration at the time the computer system is powered on. In some computer systems, a system administrator must manually define to the computer system the available resources by-keying into the system resource definitions and addresses. Another method involves setting switches on the. add-on cards to identify the resources on the card to the computer.

The most pertinent prior art known to the applicant is

Texas Instrument's NuBus system. The NuBus system involves a bus with 32-bit addressing capability (4 gigabytes). By system conventionj the upper 256 megabytes of this address space is reserved for control space for cards. The control space is then divided into sixteen 16 megabyte address partitions, each assigned to one-card installed on the system. Thus, the NuBus addresss-ing scheme supports up to sixteen cards in its dynamic configuration methodology. Each.of the sixteen 16 megabyte address partitions is further divided 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 as-signed for various information about the card such as aserial number. vendor identifier, card type, part number, and address offsets for such items as the configuration register, device driver, diagnostic tools, etc. This convention of dividing address space and utilizing address offsets allows the device drivers, di agnostic tools. and other information to be placed in the remainder of the 16 megabytes of-memory and allows this information to occupy varying amounts of memory depending on the specific card type. In other words, a card requiring a relatively large amount-of device driver code and a relatively small 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 o f 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 in a read-only-memory (ROM) and is-addressable as described above. At the time 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 allo.Wing multiple resources to be defined, instead of a fixed set in addition to other departures.

P, SUMMARX OF THE TIMNTION An improved method and apparatus for automatically configuring system resources on_a computer is described. The invention involves placing a configuration read-only-memory (ROM) on each add-on card placed in the computer system. The configuration ROM is assigned a set of addresses within the addressing space of the computer system. Within this set of addresses, a format header is located at one of a set of definable addresses. -The format header contains, among other information, an offset.to a directory of system resource identities (Ids). The directory of system resource Ids contains offsets to resource lists which describe the various resources on the board. This method-offers an advantage over the prior art in allowing multiple resources to be defined to thesystem, 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 whethererrors exist on the configuration ROM, and a length field for specifying the lowest address used by the declaration ROM, in addition to the directory offset.

The bus for communication between the various cards and central processor is divided into a number of byte lanes, each lane capable of carrying data between the components of the system. The - format header contains data'describing which of the byte lanes will be used by the card. The card may use any combination of the available byte lanes. At the time the system is powered on the address of the format header on each board is determined and then the configuration and resources of the card are read by the operating system.

The length field specifies the lowest address 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 mmory.

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 provide a method of deermining the address of the format.header depending on which byte lane(s) is/are used by the card.

it is another object-Of-this invention to provide a method of determining addresses of-the configuration data depending on an offset value in the format header.

It is a-further object of this invention to provide a method of using a resource directory and resource lists to allow n resources to be defined for a given card.

1ARTEF DESCMPTION OF THE DRAWINGS 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 assigning address spacein 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 in a computer in accordance with the present invention.

Figure 4 Is a diagram illustrating a format header and its contents within the teachings of the present invention.

Figure 5 is a diagram illustrating a-resource directory and its contents as taught by thepresent invention.

Figure 6 is a diagram illustrating a resource list and its contents as taught by the present invention.

Figure 7 is a flow diagram showing a method of determin ing a configuration when a computer is started in accordance with the present invention.

Figure 8 is a flow diagram showing a method of determining whether the start of a format header has been found-in a configuration memory as taught by the present invention.

Figure 9 is a flow diagram showing a method of reading esource directories and resource lists in a configuration 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.

1 --g- T)PTATL D DESCRIPTTON OF THR PRESENT INVENTTON A method and apparatus for automatically determining the resource configuration of a computer is disclosed. In the following description, numerous specific details Are set forth to provide a thorough understanding of the present invention.

It will be obvious to one skilled in the art that the invention may be employed without the specific details. In other instances, well-known methods and structures have not been set forth in order not to unnecessarily obscure the present invention.

Figure 1 illustrates Texas Instrument's NuBus. the most pertinent prior art known to the Applicant. The NuBus system involves a bus with 32-bit addressing,capability (4 gigabytes) 1. The upper 256 megabytes of this address space is reserved for control space for boards The remaining 3840 megabytes is used for global memory space 2. The control space 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 addresses for various information about the card such as a serial number, vendor identifier, card type. part number. and address offsets for such items as a configuration register, device driver, diagnostic tools, etc. The method allows for offsets to information regarding only a fixed set of resources.

Referring to Figure 2, the convention for assigning address space in the pr eferred embodiment is di sclosed. The preferred embodiment is capable of addressing 4 gigabytes of memory, block 20. The lower 3840 megabytes of address space 22 (addresses 0000 0000 through EFFF FFFF hexadecimal) is used for random access-memory (RAMI, for read-only-memory (ROM), for super slot space, or is reserved for future use. The upper 256 megabytes 21 (addresses FOOO 0000 through FFFF FFFF) is used for accessing, cards and for their configuration memories. The preferred embodiment 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 Figur 2, block 24. The,preferred embodiment currently has defined'slot space for six cards, labeled 9 through E.

hexadecimal. Each card is assigned sixteen megabytes of address space 26. Referring the Figure 2, block 27, the sixteen megabytes of address space 26 assigned to each card is further divided by convention into an area for 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 remainder 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, the format header must have its first byte at address-IFnFFF FFFF hexadecimal to FnFF FFFC hexadecimal (where n is the slot number).

Figure 4 describes the format header 29 of the preferred_ embodiment. The format header 29 consists of the byte lanes field 42, a reserved field 43, a test pattern field 44, a.format field 45, a revision field 46, a cyclic redundancy check (CRC) field 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 configuration 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 configuration ROM's fields 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 addresses 105. The value of the byte lanes field, Figure 4, block 42 may be computed by setting a bit in the low n ibble of the byte lane field 42 for each byte lane used and then setting the high nibble of the byte lanes field 42 to the low nibble's complement. For example, if a,card's configuration ROM 27 used byte lanes 0, 1 and.3 when communicating with the computer, 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 nibble's complement or 0100 binary, yielding a value for the field of 0100 1011 binary or 4B hexadecimal. The format header 29 would then start at address FnFF FFFF hexadecimal,, where n is 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 must be set to hexadecimal 00. The next four bytes of the format header are a test pattern 44 used to insure that a valid byte lane value was found. The preferred embodiment, by convention, requires this field to be set to 5A932BC7 nexadecimal. These values are used by the current preferred embodiment, however, it will be obvious to one skilled in the art the values may differ in another embodiment-without departing from the spirit of the invention.

The format field 45 identifies the!configuration ROM 27 format. The current preferred'embodiment allows 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 format types are defined. The revision level field 46 identifies the current ROM revision. Currently, the preferred embodiment will accept values in-the range of 1 to 9.

The next four bytes are the cyclic redundancy check (CRC) field 47. This field contains a checksum to allow the configuration ROM 27 to be validated. It is computed by applying a 32-bit rotate-left-and-add function to the number of bytes specified by the length field 48. only bytes in byte lanes 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 contains a value specifying the number of bytes from the configuration ROM's 27 starting address to the lowest-address byte used by the configuration ROM 27. The remainder of the address space reserved for the card is then available for other uses.

The directory offset value 49 specifies the offset from its address to the address of the resource directory, Figure 5, block 50. It counts only bytes In the byte lanes being used.

Referring now to Figure 3, the directory offset value is used to determine the address of the resource directory 50 for the card. The resource directory.50 will have an address within the slot space for the card (addresses FnOO 0000 through FnFF FFFF hexadecimal, 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 contains 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 allows 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 li'9ts 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 offset pointers inthe format header. The present invention provides a well defined mechanism for independent expansion by the individual card designer.

Again referring to-Figure_3., the offset values 52 in the resource directory 50 point to resource lists 60. The contents of the resource lists 60-are further detailed in Figure 6. Each resource list 60 contains a set of references to information about a single resource. This informati6n must-include the type 61 and name of the resource 6.4. It may also include references to information regarding the resources icon 66, drivers, and :)ther 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 0 to 254. The numbers 0 to 127 are reserved for assigned entry types and the numbers in the range of 128 to 254 are available to the individual card designer as needed. The last value 69 in every list must have a value of 255 Indicating the end of the list. Associated with each identification number is an offset value giving the address_ of the information.

Figure 3 shows use of the offsets 62 in the resource lists to point to the code or data 31 associated with the entry.

The preferred embodiment requires one special resource list for all cards which will communicate with the computer called a board resource list. This resource list provides the computer with the cards indentification number, vendor information, board flags, and initialization code.

At the time the computer is started a two stage process takes place. First, each slot is checked for the presence og-.a card and if one is found the format header is read and pertinent informationfrom the format header is stored in a table. Then information about each resource is read and stored in a second table and initialization code for each slot is executed. Then, -the second stage reads pertinent information about the driver and stores the information in the second table.

Referring to Figure 7, the computer starts the automatic resource configuration process by determining a first slot to examine, block 70. A first byte lane to examine is selected, block 71. The present invention inspects byte lane 3 first because the greatest number of byte lane combinations 101 will have a format header starting-address 105 in this byte lane. A check is made to see if the beginning of the format header 29 for the card in the first slot 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 slo ti 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 for the beginning of a format header, block 72. If there were no more byte lanes to search for the current card slot, an error is recorded in a table, block 77. If there are more slots to be checked. block 74. the slot number being checked is incremented, block 79 and the process is repeated.

Referring to Figure 8, a method used by the preferred embodiment for checking if the beginning of the format header has been found is disclosed. First, the byte lanes code field is 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 fil. the beginningof the format header was not found in this byte land 89. If the byte lanes code is valid,branch 82, the test pattern field is examined, block 84, to determine whether it contains the valid test pattern. If not, block 85. the beginning of header was not found in this byte lane. Otherwise, if the valid test pattern was found branch 86, it indicates the start of header was found, block 87.

After each slot is searched for a format header 29 as described in Figures 7 and 8, slots with a valid format header 29 are examined. The resource directory 50, resource lists 60, and other information is read and d ata such as the reference type and hardware device identifiers are stored in a table.

Referring to Figure 9. the process for reading resource directories 50 and resource lists 60 is disclosed. First,. - several edits are performed. The reserved field is'examined.to insure it Is set to zero, block 90. The format field Is - examined to insure it contains a valid format code., block 91, the revision field is examined to verify it contains a valid revision level, block 92. The CRC value is examined to insure it contains the correct value, block 94. If any of the edits fail an error condition is recorded, block 99.

The address of the resource directory is determined from examining the offset value in the directory offset field of the format header, block 95. Then, for each entry in the resource directory, the resource list referenced by the offset is read and pertinent information stored in a table, block 97.

After the pertinent resource information from each resource.-__ list on each card has been read and stored, the computer has completed the automatic resource configuration process. Each card installed on the system has been identified by its identification number, vendor information, and card type and information on initialization coder device drivers, etc. 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 address space. The prior art addressing scheme requires locating 128 -)ytes of header-information 9 in a fixed location. Second, the configuration ROM 27, including the format header 29, may be located in any combination of th available_byte'lanes. The card designer is not restricted to placing the configuration ROM 27 in a fixed location a-s in the prior art. Third, any number of resources may be defined. The card designer is not limited to a set number of resources as in the prior art. Fourth, the prior art meth od determined resource type by setting bits in a resource type field. Each bit indicated a different type of resource. For example, setting bit 0 indicates a memory resoirce, setting bit 1 indicates a boot source, setting bit 2 indicates a LAN resource, setting 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 field containing a code identifying the resource type. This-field is broken into sub fields, including a flag indicating the field type, a category indicator describing the general category of the resource, a subclass indicator further dividing the general category of-the resource and driver interface information. This list of advantages is not meant to be exhaustive of the features of the present invention but rather shows by way of example some of the important improvements of the present invention over the prior art.

Thus, an improved method-of and means for automatically configuring resources on a computer system is disclosed.

-17 Utilizing a configuration ROM and a convention for defining use of address space, a method of determining resource types and other information at the time the computer system is started is disclosed.