United States Patent
`
`[19]
`
`[11] Patent Number:
`
`5,854,905
`
`Garncy
`
`[45] Date of Patent:
`
`*Dcc. 29, 1998
`
`USOO5854905A
`
`[54] EXTENSIBLE BIOS FOR BOOT SUPPORT
`OF ])]T‘V[(‘/‘]T,S ON ]V[U[,T[P[,E
`HIERARCHICAL BUSES
`
`[75]
`
`Inventor:
`
`John I. Carney, Aloha, Oreg.
`
`[73] Assignee:
`*
`N '
`oticez
`
`Intel Corporation, Santa Clara, Calif.
`Th‘
`'
`d
`'
`d
`1S patent issue
`on a continue pr0s-
`ecutioii application filed under 37 CFR
`l.53(_d), and is subject to the twenty year
`Patent
`ts“-11 Pf0"i5i0H5 Of 35 U~S~C~
`l54(a)(2)-
`
`,
`S91)‘ 3’ 1996
`
`[21] Appl. No; 707,333
`,
`Fflcd:
`[22]
`Int. cifi
`[51]
`U_S_ CL ................ N
`[52]
`[58] Field of Search
`
`G06F 9/24
`395/234; 395/652
`
`395/281, 652,
`395/200.51, 200.52, 651, 284. 553
`References Cited
`U.S. PATENT DOCUMENTS
`.. 711/200
`4/1991 Fogg, Jr. et al.
`.
`235/382
`9/1995 Clark
`11/1995 Bealkowski eféii.
`395/700
`
`[56]
`
`5,008,816
`5,448,045
`5,465,357
`
`5,546,585
`8/1996 Soga
`. 395/700
`
`5,680,556
`10/’l997 Begun et al.
`. 395/3'l’l
`
`395/200.01
`5,680,597 10/1997 Chang
`. 393/830
`5,689,726
`ll/l997 Lin ..
`
`,
`_
`_
`Primary Exarmner—Ayaz R. Slieikli
`A55i5mm E"'”’m”e"_Pa“1 R- Myers
`Attorney, Agent‘, or F/7rm—Blal<ely, Sokoloff, Taylor &
`Zatman LLP
`‘
`-
`ABSTRACT
`)7]
`An extensible BIOS [or a computer system to manage
`3001-up of an arbitrary number of devices connected over an
`arbitrary number of buses and bridges of varying type. The
`extensible BIOS identifies all bridges or buses connected to
`he system and then initializes each and everv bus or bridge.
`The extensible BIOS identifies boot devices as resident on
`‘:11!
`,1H,1l1‘d11w_d brldgcs and buses, and they detects and
`initializes drivers on the. identified boot devices. According
`0 ‘he Se§’1°.“.°“ fJ“dlP“:’;“y.°f "E0: b°°"“P Thin “Om,
`Elillgiieli ielszelilir b::>o)t(-Tip E1:l31fl::.1'1€):I‘lT'1:ne?(l:eI1:::l:]l3c:(,?S
`irovides that the hierarchy of buses and bridges and boot
`devices connected to them may be altered while still recog-
`nizing all boot relevant devices, buses and bridges regard-
`ess of the nature of the alteration.
`
`15 Claims, 9 Drawing Sheets
`
`PC1 3/05
`
`820
`
`d
`_
`new_e ewce £2
`
`I
`
`—>
`
`“System Bios
`
`510
`
`I
`
`”eW—eb”d9e Q, E
`
`5td_bndge_In,~;fl€ _ 5b
`
`5
`
`new bootdev
`—
`
`Q,
`
`5
`
`417
`
`boat
`
`812 _
`_~
`
`,
`
`7
`
`ed€,V_b0m«_,0
`
`826 I
`
`3
`
`K
`2
`_7®fifi£ ___ "'EfiE"j
`ROMB/'05
`830A
`:
`I1EW_E0'EV/Ce
`'
`,2 — '1
`
`new_ebr/dge
`
`, ~5a
`834 : I
`7
`T
`1 43:
`
`edev_B0at[0
`
`fig I
`
`i
`
`.
`
`,
`
`7
`
`0001
`
`Volkswagen 1009
`
`0001
`
`Volkswagen 1009
`
`

`
`U.S. Patent
`
`Dec. 29, 1998
`
`Sheet 1 of 9
`
`5,854,905
`
`Memory Address
`5PM?
`10
`
`[/0 Address Space
`20
`
`Extended
`
`Memory
`30
`
`Keyboard Contra//er
`3.5
`
`Floppy Contro//er
`A7
`
`Hard Disk Contro//er
`
`E
`
`Keyboard §_Q
`
`0002
`
`

`
`U.S. Patent
`
`Dec. 29, 1998
`
`Sheet 2 of 9
`
`5,854,905
`
`
`
`msfioom.msfidm
`
`.§.:Q»\.B>Cm>\
`
`mmE8§s§<
`
`»as«Q.
`
`an\§§....%Emsfiex
`
`S.«M5Em:
`
`mmntnsaqm
`
`%|w
`
`86.:
`
`..m\§.E8
`
`NM
`
`NSq.§§swim
`
`§mmbtnctoa
`
`0003
`
`

`
`U.S. Patent
`
`89919:2GeD
`
`Sheet 3 of 9
`
`5,854,905
`
`
`
`mBE8mmfimwoq
`
`
`
`mm>tQ«._oEm>\
`
`ElmE8«same
`
`»asSE
`
`R«M5Em}.
`
`
`
` ISmmm&%mm84EEmafimy.msssammmncfitqe
`
`mmmm§\§cGmEs
`
`Qm.E\_hmbtmukw
`
`NSmEtéswim
`
`
`
`W.ass.§\am3%?.§&-e.EsqE&.e-Esq
`
`mmw§%EElmEam332%ElmEém32.9
`
`mmEmofimkhcoummHSKmmncm.
`
`
`
`
`
`3EastEamm,%mumS.uE\mm.«mmEm:ucoummREaEm:ES3E8§§§VEQEm:
`
`
`
`
`
`
`
`0004
`
`

`
`U.S. Patent
`
`Dec. 29, 1998
`
`5,854,905
`
`System B105
`
`POST Code
`
`5_oz_2
`
`CPU, Memory and
`Northbric/ge Initia/ization
`Code £12
`
`Southbridge
`Initialization
`Code
`§2_0
`
`Boot Device ID,
`Selection and Policy
`Management Code
`
`|//deg
`Expansion
`5105 _5_9g
`
`Network
`Expans,-on
`3105 Q5
`
`0005
`
`

`
`U.S. Patent
`
`Dec. 29, 1998
`
`Sheet 5 of 9
`
`5,854,905
`
`
`
`Emcmqxmown:
`
`mm.8.3
`
`NMmosm.§§EQI
`
`Embesmz90
`
`
`
`newE8wasseam
`
`
`
`comcmsmEeéme
`
`%.was
`
`mm8.sm.84%:
`
`
`
`:o.E§._.u.£E§..:E.§<
`
`QR%S
`
`II
`
`wmo.€3.\_mEEm%.Em.%=
`
`mwwtsqqumm9.mmfimemtm.Eflmxm
`
`EmE.Em\mm8.:me8%
`
`
`
`mmEmsmmmemz\§\oqfl~E.\umm.e.EuEm
`
`mm\_mE%E|§m:
`
`3:$§\EE
`
`
`
`:o.cm.~.%.£E.mmhtqsaommm.88
`
`mm.%8I
`
`
`
`amwhen.§.tQmmlmwhenWWmung94mung
`
`
`
`«SBEmmxm§EQngmofimx§.:QEm\3.QQ\u..>mS.tQ«EQEm:
`
`
`
`
`
`0006
`
`

`
`U.S. Patent
`
`Dec. 29, 1998
`
`Sheet 6 of 9
`
`5,854,905
`
`4MWBMWA
`
`
`
`38%m§§E....%.E
`
`
`
`%mmhtmutmcmm
`
`NINW8.5%:3:
`
`Emmhtnmname
`
`mm938.3%
`
`
`
`qwmmgmgngmtmmhtm.
`
`EwfimEsq
`
`EX5/st/ng BUS 602
`
`0007
`
`

`
`U.S. Patent
`
`Dec. 29, 1998
`
`Sheet 7 of 9
`
`5,854,905
`
`Generic Bridge Header .7000
`
`FIG. Z4
`
`Partial PC! Expansion ROM Header
`
`Data structure signature, the string ”PC[R ”
`Vendor identification
`
`Device Identification
`
`Pointer to l/ita/ Product DA TA
`
`PC! data structure Re v/'5/on
`
`Class Code
`
`Description
`Expansion ROM identification byte #0
`Expansion ROM identification byte #1
`2h-J7/1 Reserved (processor architecture unique data)
`18h-19/7
`Pointer to PC] data structure
`
`value
`55/7
`
`xx
`xx
`
`Length
`1 Byte
`1 Byte
`
`0008
`
`

`
`U.S. Patent
`
`Dec. 29, 1998
`
`Sheet 8 of 9
`
`5,854,905
`
`MQ
`
`Qbgmuéum
`
`Q
`
`musmnmugmc
`
`SECa.
`
`
`
`HWwflm%.:%.%=EmSwim
`
`am
`
`
`
`9:25I;mumIEm..E~:m%.E:Em
`
`
`
`IEm.\_mEo8:>_m:
`
`0009
`
`

`
`U.S. Patent
`
`Dec. 29, 1998
`
`Sheet 9 of 9
`
`5,854,905
`
`NEW_EBRIDGE
`
`900
`
`INITIALIZE BRIDGE
`
`CONTROLLER
`
`device = 1st device
`
`/v0
`
`De vices
`
`7
`
`,5
`
`R0
`detected
`7
`
`N0
`
`9
`
`is ROM
`
`an extensible
`ROM
`
`Cali ROM. new_ edivce
`
`940
`
`Copy ROM to
`RAM
`
`Ca/i ROM.
`new_ ebridge
`
`985
`
`Call new_ ebootdev
`of system B105
`
`995
`
`FIG. 9
`
`0010
`
`

`
`5,854,905
`
`1
`EXTENSIBLE BIOS FOR BOOT SUPPORT
`OF DEVICES ON MULTIPLE
`HIERARCHICAL BUSES
`BACKGROUND OF THE INVENTION
`1. Field of the Invention
`
`The present invention relates generally to the managing of
`boot devices in computer systems, and specifically to
`extending BIOS to manage boot-up from an unlimited
`variety of hoot devices that can appear dynamically within
`a computer system.
`2. Description of Related Art
`In typical personal computer (PC) systems, the manage-
`ment of boot devices and the sequence of booting is con-
`trolled through fixed code contained within Basic Input/
`Output System (BIOS) Read-Only Memory (ROM). The
`BIOS ROM predetermines how devices can be connected in
`the particular computer system and which types of devices
`can be supported by the BIOS. Some additional expansion
`BIOS ROM code can be introduced into a computer system
`on an add-in card, but only for a limited set of boot devices:
`i.e. local hard disks, network accessed hard disks, and video
`display adapters. The system BIOS ROM assumes that the
`boot devices are always connected to the system in the same
`way, i.e. via the same hardware interface(s) located at the
`same memory I/O address range(s). This requires that hard-
`ware interfaces for boot devices be standardized and
`unchanging so that the BIOS code to control these devices
`can support them. For example, video controllers have been
`required to support VGA interfaces for many years in order
`to allow BIOS code to continue to function even though
`more efficient hardware interfaces are used by operating
`system control software. The advent of new buses and boot
`devices has required either continued support of previous
`standardized hardware interfaces or new expansion BIOS
`code that understands the new hardware interfaces. The
`
`Industry Standard Architecture (ISA) bus provided a simple
`means of connecting boot devices and thus only required
`simple software to recognize and initialize its boot devices.
`However, computer systems have advanced to a stage where
`boot devices can now be connected through a variety of
`newer and different buses, such as Peripheral Component
`Interconnect (PCI) buses. Many of these new buses allow
`interconnection to other buses through “bridge” devices.
`These bridge devices must be typically programmed ahead
`of time to allow access to other devices connected through
`the bridge. The wide variety of possible hardware connec-
`tions requires much more complex software in order to
`recognize and initialize these devices upon boot than do ISA
`bus connections. Providing this more complex software
`code in one monolithic system BIOS is typically not pos-
`sible due to storage constraints of a typical BIOS which has
`a fixed capacity.
`Further, other new buses, such as PCMCIA, allow devices
`to be connected and disconnected at any time by the end user
`of the PC and allows devices to be configured at any
`memory address range convenient
`to the software that
`controls them. Thus boot devices maybe located at different
`memory and I/O address ranges from one instance of
`boot-up to another. Additional bridge devices that can be
`connected by the end user fL1rther complicate the variety of
`hardware connections possible. Finally, other new buses,
`like the Universal Serial Bus (USB), allow attaching boot
`devices like keyboards and mice in novel ways that cannot
`be supported with previous traditional BIOS code.
`One attempted approach to supporting these new buses
`and devices involved providing only operating system sup-
`
`2
`port which occurs during run-time of the operating system
`but not providing any support through BIOS during boot-up
`before run-time of the operating system. However,
`this
`approach undesirably prohibits being able to use these
`devices as boot devices. Another attempted approach for
`supporting these new buses was to include additional code
`in the system BIOS that individually supported all possible
`hardware combinations. However,
`this approach is only
`reasonable when the number of possible connections is
`relatively small.
`Thus, there is a need to simply and efliciently account for
`all possible boot devices connected through different type
`buses and in an arbitrary connection topology. To minimize
`and simplify the code needed in the system BIOS, there
`arises a need to provide a mechanism to also carry BIOS
`code unique to a new bus along with a bridge device for
`connecting the new bus or along with a boot device on the
`new bus.
`
`SUMMARY
`
`The present invention provides an extensible BIOS in a
`computer system that can manage booting of an arbitrarily
`large number of devices connected to the computer system
`through multiple bridges of varying types for multiple buses.
`The extensible BIOS will identify a bridge that may
`newly appear on a computer system between particular
`instances of computer boots or computer resets. The exten-
`sible BIOS will also initialize the newly added bridge. The
`extensible BIOS also identifies what boot devices are
`present on a particular bus for the bridge that has been
`initialized. Once the boot devices have been identified, the
`extensible BIOS detects code for those boot devices. The
`extensible BIOS then initializes the driver code and accord-
`ing to boot device selection and priority information allows
`use of the selected boot devices during boot-up.
`The extensible BIOS provides that
`the identifying of
`bridges, initializing of bridges, boot device identification
`and driver detection can be performed recursively, such that
`every new bridge encountered is traversed to locate more
`bridges and their associated boot devices if any until the
`entire topology is accounted for.
`The extensible BIOS is composed of a number of code
`modules, each with their own code to carry out the opera-
`tions and functions of the extensible BIOS.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`FIG. 1 shows handling of I/O devices in a typical com-
`puter system.
`FIG. 2 shows the architecture of typical personal coni-
`puter system.
`FIG. 3 shows the architecture of an extended personal
`computer system which would utilize an extensible BIOS.
`FIG. 4 shows the modules of a typical current BIOS.
`FIG. 5 shows the modules of an extensible BIOS accord-
`ing to one embodiment of the present invention.
`FIG. 6 shows the modules of a generic bridge block
`according to one embodiment the present invention.
`FIG. 7 shows partial PCI expansion ROM header and PCI
`data structure as can be utilized in various embodiments of
`the present invention.
`FIG. 8 shows the interrelationship of the code modules
`and describes the working of the invention according to the
`embodiment employed in Appendices 1 and 2.
`FIG. 9 is a flowchart of the recursion methodology of
`detecting and initializing devices through the system topol-
`ogy when starting with a particular bridge.
`
`0011
`
`

`
`5,854,905
`
`3
`DETAII.ED DESCRIPTION OF THE
`INVENTION
`
`FIG. 1 illustrates how controllers for typical personal
`computer system Input/Output (I/O) devices are accessed
`through memory address spaces. Such a computer system
`usually includes a display 80, keyboard 60, a hard disk drive
`50 and a floppy disk drive 70. The memory of Intel processor
`based computer systems is typically divided into two
`address spaces. There is an I/O address space 20 that
`contains control and status registers, and then a memory
`address space 10 that handles program execution and data,
`as well as display (video) and other controllers. The con-
`trollers keyboard controller 25, floppy controller 27 and hard
`disk controller 29, for the keyboard 60, floppy 70 and hard
`disk 50, respectively, are found in the I/O address space 20
`since these devices are not memory intensive, and do not
`require constant updating. The display 80 has a video
`controller (not shown) that has some registers in I/O address
`space whereas video memory is located in memory address
`space that is usually mapped into the memory address space
`10. The display 80 may be mapped either into extended
`memory 30, which on Intel based personal computers, is
`addressed above 1 Megabyte (MB) or can be mapped into
`low memory 40 which is addressed under 1 MB.
`The Basic Input/Output System (BIOS) usually resides in
`the upper portion of low memory 40 between 640 kilobytes
`and 1 MB, but is also mapped into extended memory 30 to
`provide a starting memory address to be used upon system
`reset. Therefore,
`the smaller the BIOS component of a
`system, the greater the memory space available to code and
`data during operation of the system. The functions of the
`BIOS, relevant to boot-up, are to (1) respond to power-on/
`reset of the computer, (2) provide the reset vector that is
`mapped into the CPU’s physical memory address range, (3)
`recognize the presence of boot devices, (4) initialize the
`drivers/controllers supporting those boot devices and (5)
`provide functionality for interaction with the user for com-
`puter setup (e.g. asking the user which device to boot from
`or the order of boot-up). These functions can be achieved
`through control software and are referred to as boot relevant
`functions since they must occur prior to the loading of an
`operating system.
`FIG. 2 shows the architecture of a typical personal com-
`puter system in accordance with accepted practice. A main
`system bus 2, such as a Peripheral Component Interconnect
`(PCI) bus, connects together all the main components of a
`computer system. A CPU 12 of the computer system is
`isolated from the system bus 2 by a “Northbridge” 100
`which essentially mates the CPU for read and write access
`to memory 22 (usually RAM). The Northbridge 100 also
`mates the CPU 12 for read and write access to the system bus
`2 for interaction with I/O devices located elsewhere in the
`system.
`The system also has a “Southbridge” 200 which isolates
`the keyboard 60, the floppy 70 and the hard disk 50 from the
`system bus 2 and provides a lower cost way to connect these
`standard devices to the system bus 2 using, for example, an
`Industry Standard Architecture (ISA) bus. The Southbridge
`200 is also used in systems having high performance archi-
`tectures (such as 32-bit addressing) to free the high perfor-
`mance system bus from dealing directly with add-in devices
`such as modems or network cards, by connecting to the
`lower performance (16—bit) ISA bus 4. The lower perfor-
`mance ISA bus 4 connects directly to the modems and
`network cards that are older in design and cannot
`take
`advantage of high performance 32-bit addressing. The
`
`4
`Southbridge 200 contains controllers for the floppy 60, hard
`disk 50 and keyboard 70 as well as an ISA bus controller.
`Southbridge 200 frequently connects all the typical boot
`relevant devices such as hard drives and other bootable
`drives resident on networks through a network card 250. The
`video controller 40, is often a high performance add-in card
`connected via the system bus 2. These devices are well-
`known in the art and are described only for background. The
`present invention assumes use of existing mechanisms of
`BIOS for those devices on buses that are well known in the
`art. Mechanisms, in addition to those used previously, are
`required to implement a general extensible BIOS and also to
`provide support for new devices on new buses.
`BIOS is fixed code which is permanently stored in a ROM
`30 (or flash, EPROM etc.). Ordinarily, BIOS has two inde-
`pendent components, a system BIOS and one or more
`expansion BIOS such as the video BIOS (handling the
`display and output features of the system). The system
`BIOS, which is a feature of the motherboard,
`is most
`relevant to the present invention since several of the mecha-
`nisms of the system BIOS will be utilized in the extensible
`BIOS. The system BIOS has rudimentary mechanisms to
`recognize the video BIOS, for instance, or another expan-
`sion BIOS that exists on the bus. But the system BIOS is
`assumed to know the entire bus environment in advance of
`boot-time such that an expansion BIOS,
`if it
`is to be
`recognized, must be found on bridges and buses known to
`the system BIOS.
`the typical system BIOS will have
`For booting,
`preinstalled, hardwired code that knows about the South-
`bridge and configures it to establish the well known boot
`device interfaces such as keyboard controller, hard disk
`controller, floppy disk controller. The BIOS checks for the
`existence of a video expansion BIOS and initializes it if
`present. A memory check is then performed with the results
`thereof displayed on the video display. The system BIOS
`then checks that
`the hard disk 50 and floppy disk 70
`controllers are present at their pre-specified addresses and
`initializes their drivers. A search for additional expansion
`BIOS code is then performed. When the network card 250,
`which connects out to network disk drives, is introduced into
`a system,
`the network card 250 will
`typically be pre-
`packaged with an expansion BIOS that contains the network
`boot code. The network boot code is not typically included
`in the system BIOS. On personal computers of recent
`vintage, the boot device driver code has been limited to
`support for a keyboard, a hard disk or floppy disk that is
`already connected into the PC or that is a permanent feature
`of the computer. Thus, the BIOS knows well in advance
`what devices it is looking for, how in the system topology
`they are connected (for example, on an ISA bus) and what
`the order of boot-up will be. On a PC, the system BIOS
`usually provides a way for the user to change the boot drive
`from the hard disk back to the floppy and vice versa.
`However, the disk drives chosen must be known to the BIOS
`prior to the user changing the order, and consequently, prior
`to next boot instance. If the BIOS had to contain code that
`anticipated all of the various boot devices that could exist at
`any given boot instance,
`the BIOS would be large and
`complex, and would have to be upgraded whenever a new
`type of boot device or bus is added to a personal computer.
`Though auto-detection of disk drive parameters is known in
`the art of BIOS, auto-detection only works on drives to
`determine drive characteristics such as the number of tracks
`or number of heads. Such auto-detection, as currently
`employed, has not been able to determine presence of novel
`new disks/disk controllers on potentially novel new buses
`within a system.
`
`0012
`
`

`
`5,854,905
`
`5
`FIG. 3 illustrates a personal computer system of the type
`envisioned by the present invention. The system of FIG. 3
`includes all the components of the personal computer of
`FIG. 2. It should be understood that components common to
`FIGS. 2 and 3 not mentioned below operate in substantially
`the same way as described for FIG. 2, and thus,
`their
`description will not be repeated. An extended bridge may be
`resident on newer personal computers that wish to take
`advantage of the ability to access dynamically added or
`configured devices such as PCMCIA devices. For instance,
`PCI—bus based systems may have a PCI—to—PCI bridge that
`can connect a secondary PCI bus, (not shown) wherein the
`system BIOS of such a computer would already contain
`code to recognize the PCI-to-PCI bridge. 'Ihe system BIOS,
`in most PCI systems, already contains code providing the
`ability to program the bridge such that previously standard-
`ized boot devices resident on the secondary PCI bus can be
`recognized through the bridge. However,
`it
`is possible
`within the PCI environment to have multiple layers of or a
`hierarchy of bridges that connect to a multitude of different
`buses. These bridges may be of a type dissimilar to a PCI
`bridge. Thus over a secondary PCI bus,
`there may be a
`CardBus bridge which is a bridge to a CardBus adapter, and
`ultimately to a CardBus. The system BIOS will not typically
`contain code to enable a Card Bus bridge nor to be able to
`recognize and configure boot devices found on a CardBus.
`If the BIOS were to take account of all such possible
`dissimilar buses or bridges, it would be impractically large
`and expensive. Further, when a new bus or bridge is
`invented, an older BIOS would not contain the code to
`access them. PCI bridge recognition is made economical
`only because the system in which it operates, as described
`herein, already has a PCI bus as its primary system bus.
`Thus, the boot devices on the PCI bus appear as standardized
`devices typically found at well known memory and I/O
`address ranges which BIOS is capable of enabling.
`FIG. 3 shows an extended dissimilar bus topology. The
`extended bridge 300 mates two Point—to—Point PCMCIA
`Sockets 301 and 302 to the system bus 2. The sockets 301
`and 302 can have one or more interconnects wherein cards,
`such as the hard disk controller card 310 and bus adapter
`card 320, may be mounted. The topology of the system
`becomes arbitrarily complex by having an add-in bus 6 that
`is added through the bus adapter 320. The add-in bus 6 may
`be a Universal Serial Bus (USB), which is quite different
`from a PCI bus and requires diiferent control and status
`mechanisms. If add-in bus 6 is a USB then bus adapter 320
`would be a USB Controller. Since a BIOS for an ordinary
`PCI system is ill-equipped to interact with such a rich variety
`of buses, bridges and boot devices, the bridges will contain
`BIOS support of their own to handle configuration tasks.
`Several boot relevant devices are shown in FIG. 3 con-
`nected to the add-in bus 6 via a bridge for add-in bus 330.
`In the case where add-in bus 6 is a USB, bridge 330 could
`become a USB hub capable of interconnecting several
`additional devices. A second keyboard 75, a second hard
`disk 55 and second floppy disk 65 may all be connected to
`the system through add-in bus 330 and will need support
`from the system BIOS if they are to be used for boot-up. An
`oft-used feature of PCMCIA card sockets is the connecting,
`for example, of a third hard disk 57 via a hard disk controller
`card 310. Adding an extra hard drive with PCMCIA in this
`manner is very simple for a user and can happen frequently.
`Typically, a computer system has software to recognize the
`change in status of the socket, identify that a hard disk
`controller card has been added and provide access to the data
`on the hard disk. Such functionality however is frequently
`
`6
`only provided during the run-time of the computer system,
`after boot-up has already occurred and the operating system
`is loaded, and is not a feature/function of the system BIOS.
`The number of boot relevant devices in a system as shown
`in FIG. 3 now comes to seven. Thus a system BIOS would
`be larger (data/code) than a BIOS of a typical system with
`only 3 or so boot devices as in FIG. 2. Such a BIOS would
`be wasteful and unduly expensive, since these extra boot
`devices may not be present in the system at the next boot
`instance which means that a large portion of system BIOS is
`unused at that next instance of boot.
`
`Further, the number of boot relevant devices that can be
`present in a hierarchical structure of buses and bridges is
`virtually unlimited; FIG. 3 exemplifies only a simple hier-
`archy. One skilled in the art will readily appreciate that
`add-in buses can contain yet more bridges to connect more
`buses and consequently, connect more boot devices.
`Thus, an extensible BIOS is provided to extend the system
`BIOS itself to include code that will traverse the entire
`hierarchy of bridges and buses, initialize those bridges and
`buses, [Ind and detect boot devices within the system and
`allow boot-up of any detected boot devices. First, an over-
`view of the system BIOS as typically employed today will
`be described since the extensible BIOS in one embodiment
`extends the mechanisms of BIOS to recognize any boot
`relevant device however and wherever it is connected in
`system topology. The extensible BIOS allows system BIOS
`to recognize any type of bridge or new bus that may
`dynamically be present from one instance of boot to the
`next, without unduly expanding the system BIOS code in a
`monolithic fashion for each type of bus or bridge.
`Traditionally, plug-and-play mechanisms, while recogniz-
`ing the existence of new devices, do so only after the
`operating system is running such that the new device may
`only be used after the operating system is loaded. Windows
`’95TM (a product of Microsoft Corporation), for example,
`eliminates the use of BIOS after the operating system takes
`control post boot-up by providing native drivers to replace
`BIOS functions. But
`these mechanisms are too general-
`purpose and do not allow pre-operating system boot-up from
`devices that it only later recognizes
`FIG. 4 illustrates the code contained within a typical
`BIOS. In a typical BIOS, there are a set of routines that
`handle events after reset and power—on of the computer but
`before the invocation of an operating system (such as Disk
`Operating System (DOS)). This set of routines that boot the
`computer system prior to loading the operating system is
`known as Power—On—Self—Test (POST). Certain devices
`within the computer system must always be started and in a
`particular order to maintain functionality and accessibility
`throughout the boot-up process. For instance prior to even
`testing the memory (RAM), there is a need to invoke the
`video BIOS routines so that when the memory test does run,
`the user can monitor its progress through a display device.
`POST code 500, as shown on FIG. 4, contains several
`subroutines. First, the CPU is initialized. Next any initial-
`ization of the Northbridge takes place. The presence of a
`video expansion BIOS is detected and the video display
`controller is initialized. The memory is tested and initialized
`next with results displayed to the end user via the video
`display controller. This sequence of events occurs every time
`there is a power on, also known as a cold boot, or in some
`systems also upon a reset, also known as a warm boot. The
`CPU, memory and Northbridge initializations are grouped
`together as code block 510 in FIG. 4 since they are con-
`secutively executed. There is also code 520 to initialize the
`
`0013
`
`

`
`5,854,905
`
`7
`Southbridge, and on PCI systems, code 580 to operate a PCI
`bridge. The extensible BIOS proposed in the present inven-
`tion does not need to modify these sections of l’OS'I‘ code in
`order to initialize the system. Akeyboard will typically also
`be detected and its BIOS driver, keyboard driver code 560,
`initialized before any other expansion BIOS is detected. This
`allows the expansion BIOS to make use of the keyboard for
`user input if required. The typical BIOS will also have code
`that handles and performs boot device support operations,
`shown in FIG. 4 such as Boot Device ID, selection and
`policy management code 530. The focus of extensible BIOS
`is on (1) generic identification and initialization of bridge
`devices and buses,
`generic identification and initializa-
`tion of boot devices, and (3) attaching BIOS device drivers
`for these generic boot devices to the system BIOS for boot.
`The typical system BIOS will have several embedded
`device drivers to handle the I/O functions of particular
`well-known devices such as the hard disk or floppy. FIG. 4
`shows that there is hard disk driver code 540, floppy disk
`driver code 550, keyboard driver code 560 and system clock
`code 570. This list is only exemplary and not exhaustive of
`BIOS function so as not to obscure the invention.
`Current practice for system BIOS does allow for expan-
`sion BIOS code for video controllers and hard disk control-
`lers. FIG. 4 shows Video Expansion BIOS 590, which is a
`specialized BIOS “expansion” module, and is not in any way
`equivalent
`to the extensible BIOS provided for in the
`embodiments of the present invention. Each new device type
`may have its ow11 expansion BIOS, but the current practice
`limits the types of boot relevant devices that can have
`expansion BIOS support within the system BIOS. The
`practice for hard disk support allows for locally connected
`hard disks and network connected hard disks. FIG. 4 also
`shows Network Expansion BIOS 595 which allows BIOS to
`find networked hard disks. However,
`those are the only
`expansion BIOS opportunities possible in current practice.
`The expansion BIOS of current practice do not accommo-
`date novel controllers that may be located on dissimilar
`buses with previously non-accessible multiple boot relevant
`devices present. Such boot devices are non-accessible in that
`they are arbitrarily connected to the system and may appear
`on a bus which cannot be recursed into by the system BIOS
`for the purpose of detecting boot-up devices.
`FIG. 5 shows the extensible BIOS of an embodiment of
`the present invention. The CPU, Northbridge and Memory
`Initialization and Southbridge Initialization codes 510 and
`520, respectively, described with FIG. 4 operate in the same
`way as with the typical BIOS and will not be described
`again. The present
`invention provides for additions,’
`modifications to the system BIOS to support the extensible
`BIOS. These additions are contained in system extensible
`BIOS support 530 and a PCI extensible BIOS 521.
`System extensible BIOS support 530 includes three pro-
`cedures or code “modules”—new_ebootdev 536, Std_
`bridge_init 534 and boot 532. These modules are shown in
`Appendix 1 and are described below. The module new_
`ebootdev 536 is called when a new extensible boot device is
`identified. This procedure allows the system BIOS to deter-
`mine via its boot device policy whether a boot device will be
`used for the current instance of boot-up. The module new_
`ebootdev 536 is passed three parameters: entry, type and a
`pointer to boot device parameters. The “entry” parameter
`contains the memory address for an entry point for the new
`boot device’s I/O functions which are used to perform any
`I/O with the new boot device. The type parameter contains
`a value indicating the type of the new boot device, e.g.,
`0=bridge,
`I=hard disk, 2=floppy disk, 3=keyboard,
`4=mouse, 5=network disk, and 6=video display controller.
`
`8
`The pointer to device parameters (“device params”) con-
`tain a memory address for a block of memory filled with data
`specifically used by the new boot device’s boot I/O proce-
`dure. The “device params” memory address is passed to the
`boot I/O entry point for each I/O request. The device params
`data is used to allow the boot I/O procedure to manipulate
`the boot device and distinguish it from other boot devices on
`the same or different buses/bridges. Returning the “type”
`parameter of the new boot device allows the boot device
`policy (not shown) to determine whether to use the new boot
`device for the current instance of boot-u p. If the boot device
`will be used, the system BIOS saves the entry point and
`“device params” for use during boot I/O requests for the
`boot device.
`
`The module Std_bridge_init 534 is called internally by
`system BIOS to initialize a standard bridge, such as a PCI
`bridge as a starting point in recursing the bus and boot
`device topology. The module Std_bridge_init 534 initial-
`izes any PCI bridges known to the system BIOS. Instead of
`using monolithic code contained within the system BIOS,
`this embodiment shows that
`the same extensible BIOS
`apparatus and methodology is used. In particular, the module
`new_ebridge 524 is called for the PCI bridge. The module
`new_ebridge 524, when executed, recursively traverses the
`system topology (i.e. any and all buses, bridges and devices
`that are connected).
`The module boot 532 is a modification of the normal
`BIOS boot code module a11d allows extensible BIOS boot
`I/O procedures to be used instead of internal system BIOS
`I/O routines. These extensible BIOS boot I/O procedures
`must be used for any extensible BIOS boot devices selected
`by the system BIOS policy for this instance of system
`boot-up.
`Internal system BIOS I/O routines can only
`manipulate s