(12) United States Patent
`Esfahani et al.
`
`US006434695B1
`(10) Patent No.:
`US 6,434,695 B1
`(45) Date of Patent:
`Aug. 13, 2002
`
`(54) COMPUTER OPERATING SYSTEM USING
`COMPRESSED ROM IMAGE IN RAM
`75) Inventors: C
`. Esfahani. S
`le. Paul
`(75) Inventors M.". º º º tºd e; Pau
`Hochsprung, ios Gatos, william M.
`Galcher. M. view.alior CA (US)
`2 * * * * *
`2
`(73) Assignee: Apple Computer, Inc., Cupertino, CA
`(US)
`Subject to any disclaimer, the term of this
`patent is extended or adjusted under 35
`U.S.C. 154(b) by 0 days.
`
`(*) Notice.
`
`OTHER PUBLICATIONS
`Developer Note, Apple Computer, Inc., Apple iMac Com
`Puter, 1998, pp. 1-75.
`B. Croft, et al., “Network Working Group Request for
`Comments (RFC) 951’’, Sep. 1985, 9 pgs.
`IEEE Computer Society, “IEEE Standard for Boot (Initial
`ization Configuration) Firmware: Core Requirements and
`Practices”, Oct. 28, 1994, 264 pgs.
`* cited by examiner
`Primary Fººminer—Jeffrey Gaffin
`Assistant Examiner–Tammara Peyton
`(74) Attorney, Agent, or Firm—Blakely, Sokoloff, Taylor &
`Zafnman LLP
`ABSTRACT
`(57)
`(21) Appl. No.: 09/220,160
`A low-level portion of the operating system of a computer
`(22) Filed:
`Dec. 23, 1998
`-
`7
`system is separated from an intermediate-level portion of the
`(51) Int. Cl.' .......................... G06F º ºf sº operating system. The low-level portion, including
`e
`711/165; 711/203; 711/206; 713/1
`only memory (ROM), while at least part of the intermediate
`(58) Field of Search ....................... 710/1, 20; 711/165,
`level portion is stored as a compressed ROM image on a disk
`711/203, 206; 713/1, 2
`or other mass storage device, which may be located remotely
`from the computer system. Upon power-up or reset of the
`computer system, the code in the ROM is executed to read
`the compressed ROM image into random access memory
`(RAM) of the computer system. The compressed image is
`
`(52) U.S. Cl. - - - - - - - - - - - - - - - - - - - - - - - - - - - -. . 733. 710/1; 7102).
`
`hardware-specific code, is stored in &l relatively small read
`
`(56)
`
`e
`References Cited
`U.S. PATENT DOCUMENTS
`
`5,109,521 A 4/1992 Culley - - - - - - - - - - - - - - - - - - - - - - - - 711/165
`
`then decompressed and executed as part of the boot
`
`sº A :: 11/1996 º al. ............ º: sequence. Once decompressed, the portion of RAM storing
`sº º jº º al". *: the intermediate-level code is write-protected in the memory
`5696.926. A - 12/1997 Culbeneal". .*11.0
`map, and the code in boot ROM is deleted from the memory
`5,836,013 A * 11/1998 Greene et al. ................. 732 map. Memory space in RAM that is allocated to the
`5,901,310 A * 5/1999 Rahman et al. ................ 713/1
`intermediate-level code but not used is returned to the
`5,940,871 A * 8/1999 Goyal et al. ......
`... 711/206
`operating system for use as part of system RAM.
`6,195,107 B1 * 2/2001 Iverson .........
`.... 345/516
`6,216,225 B1 * 4/2001 Yoo .............................. 713/2
`
`41 Claims, 11 Drawing Sheets
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`MASS STORAGE
`
`M|D-LEVEL
`OS
`(COMPRESSED)
`BOOT ||NFO
`FILE
`
`12
`
`32
`
`M|D-LEVEL
`OS
`(DECOMPRESSED)
`BOOT INFO
`FILE
`
`
`
`
`
`
`
`BOOT ROM
`
`
`
`LOW-LEVEL
`OS
`
`11
`
`31
`
`Realtime 2020
`Page 1 of 19
`
`

`

`U.S. Patent
`
`Aug. 13, 2002
`
`Sheet 1 of 11
`
`US 6,434,695 B1
`
`8 |Z || |0||
`
`HHOVO
`
`Realtime 2020
`Page 2 of 19
`
`

`

`U.S. Patent
`
`Aug. 13, 2002
`
`Sheet 2 of 11
`
`US 6,434,695 B1
`
`APPLICATIONS
`
`
`
`MacOS
`(HIGH-LEVEL)
`
`22A
`
`21
`
`22
`2^
`
`MacIntosh
`TOOIBOX
`ROM
`(Mid- and low-level)
`
`HARDWARE
`
`23
`
`FIG. 2
`
`Realtime 2020
`Page 3 of 19
`
`

`

`US 6,434,695 B1
`
`| | | |
`
`Aug. 13, 2002
`
`U.S. Patent
`
`|F || L – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –J
`
`
`|| || | 92| | C|
`
`
`||
`||
`||
`|>| || ||
`
`
`|8JSP|
`
`|<_>>|
`|cw3|
`|EE.?|
`
`Sheet 3 of 11
`
`|----CD|
`
`|-C----- | | GÐC1)|
`
`FIG. 3
`
`Realtime 2020
`Page 4 of 19
`
`

`

`U.S. Patent
`
`Aug. 13, 2002
`
`Sheet 4 of 11
`
`US 6,434,695 B1
`
`13
`
`33
`
`LOAD
`
`32
`
`
`
`
`
`
`
`
`
`
`
`
`
`MASS STORAGE
`
`MaCOS
`
`M|D-LEVEL
`OS
`(COMPRESSED)
`BOOT INFO
`FILE
`
`?
`40
`
`12
`
`32
`
`
`
`
`
`MD-LEVEL
`OS
`(DECOMPRESSED)
`BOOT INFO
`FILE
`
`40
`
`BOOT ROM
`
`LOW-LEVEL
`0S
`
`
`
`
`
`
`
`11
`
`31
`
`FIG. 4
`
`Realtime 2020
`Page 5 of 19
`
`

`

`U.S. Patent
`
`Aug. 13, 2002
`
`Sheet 5 of 11
`
`US 6,434,695 B1
`
`MASS STORAGE
`
`
`
`* - - - - - - - - - - - - - - - - - - - - - |
`
`13
`
`HEADER 51
`
`
`
`TRA wrºtton
`Z
`
`
`
`
`
`53
`
`40 –
`
`BOOT INFO FILE
`
`
`
`|
`I
`
`OPEN
`1
`| | FIBMWARE|| DRIVERS
`
`H/W
`TABLES
`
`POST
`
`|
`|
`|
`
`LOW-LEVEL OS 31
`
`
`
`
`
`
`
`
`
`BOOT ROM 11
`
`FIG. 5
`
`Realtime 2020
`Page 6 of 19
`
`

`

`U.S. Patent
`
`Aug. 13, 2002
`
`Sheet 6 of 11
`
`US 6,434,695 B1
`
`POWer On/Reset
`
`601
`
`POST Executes
`
`602
`
`Open Firmware routine
`initialized and execution
`beginS, including building Of
`expanded Device Tree and
`interrupt trees
`
`603
`\ }
`
`604
`Open Firmware locates
`Boot Info file and loads into f \ }
`RAM, based On defaults
`and NVRAM settings
`
`605
`
`606
`
`607
`
`Open Firmware executes
`Forth Script of Boot Info file,
`reads Trampoline COde and
`Compressed MacROM
`image, places them into
`temporary storage locations
`in RAM
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Open Firmware transfers
`Control to Trampoline
`rOutine
`
`Trampoline routine
`decompresses MacROM
`image; reallocates unused
`memory in ROM image
`memory Space; gathers
`information about System
`from Open Firmware,
`CreateS data StructureS
`based On this information;
`rearranges Contents of
`RAM to an interim location
`
`FIG. 6A
`
`Realtime 2020
`Page 7 of 19
`
`

`

`U.S. Patent
`
`Aug. 13, 2002
`
`Sheet 7 of 11
`
`US 6,434,695 B1
`
`@
`
`Trampoline transfers
`Control to Hardware|nit
`Routine of MacROM image
`
`Hardwarelnit copies data
`StructureS to COrrect
`|OCations in memory, Calls
`kernel
`
`kernel fills in data Structure,
`CallS 68K emulatOr
`
`68K emulator initializes
`itself, transferS Control to
`Start|nit routine
`
`
`
`
`
`
`
`
`
`Startlnit routine begins
`exeCuting, initializing data
`Structures and ManagerS,
`booting Mac OS
`
`End
`
`FIG. 6B
`
`Realtime 2020
`Page 8 of 19
`
`

`

`U.S. Patent
`
`Aug. 13, 2002
`
`Sheet 8 of 11
`
`US 6,434,695 B1
`
`Determine debugging level
`for SubSequent mêSSageS,
`if any
`
`Determine Whether t0
`Create the read/write Debug
`MacROM image aperture
`
`Verify copyright in Boot
`ROM
`
`LOCate memory Controller
`and main memory node
`
`A||OCate RAM for RTAS and
`instantiate RTAS
`
`
`
`A||OCate RAM for a Work
`Area that Will COntain
`DeVice Tree and Other data
`StructureS
`
`AllOCate RAM for the
`MacROM image and
`deCOmpress the image from
`the BOOt Info file into that
`memory Space
`
`06
`\!/
`
`07
`\Z
`
`FIG. 7A
`
`Realtime 2020
`Page 9 of 19
`
`

`

`U.S. Patent
`
`Aug. 13, 2002
`
`Sheet 9 of 11
`
`US 6,434,695 B1
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`708
`
`09
`
`10
`
`Find and mark as available
`unused portion of MacROM
`image memory Space,
`adjust System Info record
`to acCOunt for RAM needed
`by MacROM image
`
`Determine the Offset to the
`0S NVRAM partition data
`Space
`
`Copy DeVice Tree to the
`Work Area for later Creation
`of the Name Registry; While
`Copying, Check for "special"
`nodes and proCéSS
`information from those
`nodes for later USe,
`including interrupt tree
`information
`
`
`
`Create data StructureS for
`interrupt handling based on
`information gathered in
`previous Step
`
`711
`
`FIG. 7B
`
`Realtime 2020
`Page 10 of 19
`
`

`

`U.S. Patent
`
`Aug. 13, 2002
`
`Sheet 10 of 11
`
`US 6,434,695 B1
`
`Initialize interrupt
`Controller(s)
`
`712
`
`Build memory map
`
`J13
`
`Verify MacROM image
`CheckSum
`
`Determine physical
`addresses Of data
`Structures in the Work Area
`in preparation for moving
`them to proper locations
`
`714
`
`715
`
`Command Open Firmware
`Component to quiesce
`
`U16
`
`Switch to real mode, move
`MacROM image to its
`permanent location, move
`Work Area Contents to
`interim |0CationS
`
`Transfer Control to
`MacROM image
`Hardwarelnit routine
`
`MOVe Work Area data
`Structures to permanent
`|OCation
`Transfer COntrol to Kernel
`
`
`
`7
`J.
`
`U18
`
`719
`\!/
`
`J20
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`FIG 7C
`
`Realtime 2020
`Page 11 of 19
`
`

`

`U.S. Patent
`
`Aug. 13, 2002
`
`Sheet 11 of 11
`
`US 6,434,695 B1
`
`SWitch to new address map J2
`Which excludes Boot ROM,
`Trampoline Code
`
`Modify address map SO that J22
`MacROM image in RAM is
`Write-protected
`
`
`
`
`
`
`
`End
`
`FIG. 7D
`
`Realtime 2020
`Page 12 of 19
`
`

`

`US 6,434,695 B1
`
`1
`COMPUTER OPERATING SYSTEM USING
`COMPRESSED ROM IMAGE IN RAM
`
`FIELD OF THE INVENTION
`
`The present invention pertains to the field of computer
`operating systems. More particularly, the present invention
`relates to facilitating the debugging and upgrading of a
`computer operating system.
`BACKGROUND OF THE INVENTION
`
`The Macintosh line of computer systems from Apple
`Computer, Inc. of Cupertino, Calif., is a well-known line of
`computer systems. The Macintosh computer’s permanent
`read-only memory (ROM), historically called the Macintosh
`ToolBox ROM, has traditionally been structured as one
`monolithic ROM, which contained both low-level and high-
`level operating system (OS) code. That is,
`the ToolBox
`ROM contained the routines needed by the computer at
`power-up time (e.g., hardware knowledge,
`initialization,
`diagnostics, drivers, etc.), as well as a significant amount of
`higher-level OS code. Examples of hardware-specific soft-
`ware are drivers, feature tables, diagnostics, and hardware
`initialization code. Examples of the higher-level software
`are high level managers, experts and other higher level
`software, such as QuickDraw, Small Computer Systems
`Interface (SCSI) Manager, etc. This combining of high-level
`and low-level OS code resulted from the fact that, when the
`first Macintosh computers were designed, ROM was
`cheaper than random access memory (RAM), and the avail-
`able disk space (which was fioppy-based) was at a premium.
`Because the higher-level code was not expected to change
`substantially, it was logical from an economic and perfor-
`mance standpoint to include as much higher-level code as
`possible in the ROM along with the start-up code.
`As a result of the expanding set of Macintosh OS features,
`however, some of the higher-level code (and hardware-
`specific code not explicitly needed before booting) has
`expanded beyond the practical limits provided by ROMs.
`The size of the ToolBox ROM code in recent Macintosh
`
`machines has been approximately 4 Megabytes. The archi-
`tecture of the Macintosh OS has evolved to the point where
`the ROM could be augmented and modified by System
`Software, such as the System file or the Enabler (a smaller
`file which can override the System file). In this way, the
`functionality of the ROM could be spread out among the
`ROM, Enabler and the disk-based System Software.
`However, this intertwining of hardware and software code
`spread out from ROM to disk makes the production of new,
`improved computer systems more difficult and time con-
`suming.
`Using the traditional approach, designing a major new
`computer system or making even a minor revision to com-
`puter hardware typically entails having to modify the ROM,
`the Enabler, and/or the System Software. That is, if even just
`a small, hardware-specific part of the ROM has to be
`changed to accommodate a hardware change,
`the entire
`ROM would have to be rebuilt. Once the ROM rebuilding
`occurs, substantial time and expense is required to rigor-
`ously test it and the companion system software. Patches to
`the firmware and software tend to be complicated, adding to
`the need for testing. The new System build needs to be tested
`on many different platforms running different versions of the
`OS, to make sure it correctly ran on the large number of
`different hardware and software combinations. Each new
`
`release over the years has built upon the old ones and added
`more complexity to the coding and demands on testing
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`2
`engineers. Thus, it is desirable to have a way to increase
`reliability and to reduce time to market, development costs,
`and manufacturing costs for computer systems.
`
`SUMMARY OF THE INVENTION
`
`A method and apparatus for use in booting a computer
`system are provided. The method includes loading a com-
`pressed image of a first portion of the OS of the computer
`system into a storage device of the computer system, which
`may be RAM, for example. The compressed image of the
`first portion of the OS is then decompressed and executed as
`part of the boot sequence of the computer system.
`In particular embodiments, the first portion of the oper-
`ating system may include an intermediate-level portion of
`the operating system, while a second, low-level portion of
`the operating system containing hardware specific aspects
`are stored in read-only memory. The process of transferring
`the first portion from non-volatile storage to volatile storage
`and decompressing the first portion may be initiated by the
`low-level portion stored in the read-only memory. Once
`decompressed, the portion of memory storing the first por-
`tion of the operating system may be write-protected, and this
`read-only memory portion may be mapped out of the
`address space of RAM used by the operating system.
`Other features of the present invention will be apparent
`from the accompanying drawings and from the detailed
`description which follows.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`The present invention is illustrated by way of example
`and not
`limitation in the figures of the accompanying
`drawings, in which like references indicate similar elements
`and in which:
`
`FIG. 1 is a block diagram of a computer system.
`FIG. 2 illustrates the structure of a Macintosh operating
`system (OS).
`FIG. 3 illustrates the structure of an improved OS that has
`separate high-level, intermediate-level, and low-level por-
`tions.
`
`FIG. 4 illustrates an aspect of a boot sequence of the
`improved OS, in which a compressed ROM image is read
`into RAM.
`
`FIG. 5 illustrates components of a Boot Info File and
`contents of the Boot ROM.
`
`FIGS. 6A and 6B collectively are a flow diagram illus-
`trating a boot sequence associated with the improved OS.
`FIGS. 7A, 7B, 7C, and 7D collectively are a flow diagram
`illustrating operation of the Trampoline code.
`
`DETAILED DESCRIPTION
`
`Acomputer OS using a compressed ROM image in RAM
`is described. In brief, the low-level portion of an OS of a
`computer is designed to be separate from the intermediate-
`level portion of the OS. The low-level portion, which
`includes hardware-specific code,
`is stored in a relatively
`small Boot ROM, while at least part of the intermediate-
`level portion is stored as a compressed ROM image on a disk
`or other mass storage device. The mass storage device may
`be located remotely from the computer system, such as in a
`file server. Upon power-up or reset of the computer system,
`the code in the boot ROM is executed to read the com-
`
`pressed ROM image into RAM, i.e., system memory, of the
`computer system. The compressed image is then decom-
`pressed and executed as part of the boot sequence.
`
`Realtime 2020
`
`Page 13 of 19
`
`Realtime 2020
`Page 13 of 19
`
`

`

`25
`
`3
`FIG. 1 illustrates a computer system 1 in which the
`present invention may be implemented. Note that while FIG.
`1 illustrates the major components of a computer system, it
`is not intended to represent any particular architecture or
`manner of interconnecting the component; such details are
`not germane to the present invention. The computer system
`of FIG. 1 may be, for example, an Apple Macintosh
`computer, such as an Apple iMac computer. As shown, the
`computer system 1 of FIG. 1 includes a microprocessor 10,
`a read-only memory (ROM) 11, random access memory
`(RAM) 12, each connected to a bus system 18. The bus
`system 18 may include one or more buses connected to each
`other through various bridges, controllers and/or adapters,
`such as are well-known in the art. For example, the bus
`system may include a “system bus” that is connected
`through an adapter to one or more expansion buses, such as
`a Peripheral Component Interconnect (PCI) bus, or the like.
`Also coupled to the bus system 18 are a mass storage device
`13, a display device 14, a keyboard 15, a pointing device 16,
`a communication device 17, and non-volatile RAM
`20
`(NVRAM) 20. A cache memory 19 is coupled to the
`microprocessor 10.
`Microprocessor 10 may be any device capable of execut
`ing software instructions and controlling operation of the
`computer system, such as a “G3” PowerPC processor, for
`example, or an x86 class microprocessor. ROM 11 may be
`a non-programmable ROM, or it may be a programmable
`ROM (PROM), such as electrically erasable PROM
`(EEPROM), Flash memory, etc. Mass storage device 13 may
`include any device for storing suitable large volumes of data,
`such as a magnetic disk or tape, magneto-optical (MO)
`storage device, or any variety of Digital Versatile Disk
`(DVD) or compact disk ROM (CD-ROM) storage. Display
`device 14 may be any device suitable for displaying
`alphanumeric, graphical and/or video data to a user, such as
`a cathode ray tube (CRT), a liquid crystal display (LCD), or
`the like, and associated controllers. Pointing device 16 may
`be any device suitable for enabling a user to position a cursor
`or pointer on display device 17, such as a mouse, trackball,
`touchpad, stylus with light pen, voice recognition hardware
`and/or software, etc. Communication device 17 may be any
`device suitable for or enabling the computer system 1 to
`communicate data with a remote processing system over a
`communication link, such as a conventional telephone
`modem, a cable television modem, an Integrated Services
`Digital Network (ISDN) adapter, a Digital Subscriber Line
`(xDSL) adapter, a network interface card (NIC), an Ethernet
`adapter, etc.
`It will be apparent from this description that aspects of the
`present invention may be embodied, at least in part, in
`software. That is, the technique may be carried out in a
`computer system in response to its microprocessor executing
`sequences of instructions contained in a memory, such as
`ROM 11, RAM 12, mass storage device 13, cache 19, or a
`remote storage device. In various embodiments, hardwired
`circuitry may be used in place of, or in combination with,
`software instructions to implement the present invention.
`Thus, the technique is not limited to any specific combina
`tion of hardware circuitry and software, nor to any particular
`source for the instructions executed by a computer system.
`In addition, throughout this description, various functions
`and operations are described as being performed by or
`caused by software code (or other similar phrasing) to
`simplify description. However, those skilled in the art will
`recognize that what is meant by such expressions is that the
`functions result from execution of the code by a processor,
`such as microprocessor 10.
`
`4
`Refer now to FIG. 2, which illustrates the structure of a
`traditional Macintosh OS. The OS 22 provides an interface
`between the hardware 23 of the computer system and the
`software applications 21. The OS includes the so-called
`MacOS 22A, which is the high-level portion of the OS 22.
`In this context, “high-level” refers to the portion of the OS
`22 which is least hardware-specific and has the greatest
`degree of abstraction. Traditionally, this file would reside on
`disk or other mass storage device and would typically be the
`last portion of the OS22 to be invoked during the boot
`process. The (traditional Macintosh) OS22 also includes the
`so-called ToolBox ROM code 22B. The ToolBox ROM code
`22B is firmware that resides in a ROM. The ToolBox ROM
`code 22B represents the middle- or intermediate-level and
`low-level portions of the OS22. In this context, “low-level”
`refers to the portion of the OS which is most hardware
`specific and has the smallest degree of abstraction. The
`middle-level portion has degrees of hardware-dependence
`and abstraction lower than those of the high-level OS22A
`and greater than those of the low-level OS.
`As noted above, the ToolBox ROM code 22B has grown
`in size substantially over the years, with the introduction of
`new OS features and hardware. In recent Macintosh models,
`the size of the ToolBox ROM code has been approximately
`four Megabytes. Further, the intertwining of hardware
`specific code with higher-level code has complicated debug
`ging and upgrading processes. Thus, it is desirable to pro
`vide an improved OS which overcomes these and other
`problems.
`Toward that end, various details provided in this descrip
`tion are specific to Macintosh computer systems. Note,
`however, that the concepts of the present invention are not
`limited to application to a Macintosh platform. For example,
`these concepts may also be applied to x86 processor based
`computer systems, as well as other types of computing
`platforms.
`
`Overview of the Improved OS
`The present invention addresses the above-noted prob
`lems by providing an improved OS in which the hardware
`specific and higher level system software code are separated
`into logically distinct pieces, as illustrated in FIG. 3. The
`low-level portion 31 of the improved OS 30 contains the
`hardware-specific components needed to boot, while a
`separate, mid-level portion 32, contains boot-time ToolBox
`routines and components that are common to many Macin
`tosh computers. With this approach, the hardware-specific
`code is isolated and the ToolBox and system software code
`can be made abstract and generic. The highest-level portion,
`the MacOS 33, is also separate from the mid-level portion 32
`and the low-level portion 31 and, as with prior Macintosh
`computers, may reside on a disk or other mass storage
`medium.
`The benefits of this approach include the following: When
`hardware changes are needed, only the hardware-specific
`code has to be modified, greatly decreasing the turnaround
`time for new products and software product releases, and
`reducing testing time and expenses. The higher-level Tool
`Box and System Software seldom needs to change. This
`approach further provides high confidence that the higher
`level software has not been changed when creating a new
`build as a result of changing the hardware-dependent code.
`Changing the higher-level software less frequently simpli
`fies testing and reduces the time to develop system software
`and fix bugs. In addition, the memory footprint may be
`reduced, since fewer patches may be required as the higher
`
`US 6,434,695 B1
`
`10
`
`15
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`Realtime 2020
`Page 14 of 19
`
`

`

`25
`
`5
`level software is consolidated and unchanged. Running an
`OS other than the MacOS, such as Rhapsody, becomes
`simpler. Also, costs tend to be reduced. Today, RAM and
`disk space are inexpensive, have high capacity, and are fast
`compared to the ROM, RAM and disk in the original
`Macintosh.
`Referring now to FIG. 4, in the improved OS, the low
`level (hardware-specific) OS code 31 resides in firmware, in
`order to handle start-up activities of the computer system.
`This code fits into one, relatively small ROM, referred to as
`the Boot ROM 11. Thus, Boot ROM 11 includes all of the
`hardware-specific code and tables needed to start up the
`computer as well as to boot the OS and provide common
`hardware access services the OS might require. Note that the
`Boot ROM code is not specific to the MacOS or to any other
`OS. All higher-level software resides elsewhere, as will now
`be described.
`Prior to start-up, the mid-level portion 32 of OS 30 (which
`corresponds to part of the ToolBox ROM of earlier Macin
`tosh computers) resides in compressed form in a file 40,
`referred to as Boot Info file 40. Except for certain modifi
`cations described below, the Boot Info file 40 generally
`conforms to the “Open Firmware” standard, i.e., Institute of
`Electrical and Electronics Engineers (IEEE) Standard
`1275–1994, “Standard for Boot (Initialization,
`Configuration) Firmware: Core Requirements and
`Practices,” hereinafter simply “Open Firmware”, which is
`incorporated herein by reference. The improved OS
`architecture, according to one embodiment, uses a modified
`version of Open Firmware which contains several changes
`from the earlier versions found in the first and second
`generation PCI Macintosh computers: In particular, the
`Open Firmware is capable of reliably reading files from
`block devices; builds a new Device Tree that holds essen
`tially every facet of hardware information needed by an OS;
`and contains code that mimics the StartSearch code (the
`code which searches for suitable boot device) in the ToolBox
`ROM and provides a Mac-like user interface during start-up.
`Subsequent references to “Open Firmware” in this descrip
`tion refer to this modified version, unless stated otherwise.
`Boot Info file 40 may be initially stored on a disk or other
`mass storage device 13, which may be a component of
`computer system 1 or it may be remotely located, such as in
`a network server. During start-up, the Boot Info file 40 is
`loaded into RAM 12, and the compressed mid-level OS 32
`is decompressed. Hence, the mid-level OS 32 is essentially
`a compressed ROM image. The mid-level OS 32 is inserted
`into the memory map of the computer system as if it were
`firmware in ROM. That is, the ROM image can be write
`protected in the memory map.
`Thus, the improved OS 30 loads the ROM Image 32 into
`RAM 12, and marks it as read-only. In one embodiment, the
`ROM image is approximately four Megabytes in size—the
`ROM image includes much of the earlier ToolBox ROM
`55
`code—however, not all of this memory space is used.
`Consequently, the portion that is not used is eventually
`returned to the Mac OS 33 during boot up, for use as part of
`system RAM 12. Note that a consequence of having the
`ROM image in RAM is that it is possible to have a memory
`map alias to the ROM image that allows changes. As a
`result, the improved OS (with an appropriate version of
`debugging software, such as Apple MacsBug) supports
`setting break-points in the “ROM’.
`One difference between the improved OS 30 and the
`traditional Macintosh ToolBox ROM code is the inclusion in
`the ROM image of all code that supports any hardware that
`
`35
`
`40
`
`45
`
`50
`
`60
`
`65
`
`US 6,434,695 B1
`
`10
`
`15
`
`20
`
`30
`
`6
`is expected (or likely) to be used, and the addition of
`run-time checks that determine which such code is to be
`used, given the hardware actually installed. Thus, with the
`improved OS, a single ROM Image may be used to support
`many existing and future computer systems having a variety
`of different hardware configurations. When an upgrade or
`modification to the hardware is made, the appropriate soft
`ware can be written and integrated into the existing ROM
`Image, so that it determines the correct code path at boot
`time or run-time. New versions of the ROM Image can
`provide support for systems that use previous versions.
`The high-level portion 33 of the Macintosh OS, i.e., the
`MacOS System Software (the components in the System
`Folder) can remain largely unchanged. However, some
`changes may be desirable to support the improved OS. For
`example, in one embodiment of the improved OS, the
`StartSearch functionality is moved to the Open Firmware
`code. Consequently, in such an embodiment, the Startup
`Disk control panel may require changes to inform Open
`Firmware of the user-selected startup volume.
`One aspect of the improved OS is the ability to support
`varying hardware implementations, including the lack of
`some of the traditional Macintosh Input/Output (I/O) ports.
`Some components may be changed to make more informed
`decisions on the selection of default behavior. For example,
`Open Transport may no longer default to selection of the
`“Printer Port” (using LocalTalk).
`Referring now to FIG. 5, the low-level OS portion 31 and
`the Boot Info file 40 are illustrated in greater detail. The
`low-level portion 31 stored in Boot ROM 11 contains the
`code needed to start up the computer, initialize and examine
`the hardware, provide a Device Tree (per Open Firmware) to
`describe the hardware, provide hardware access services,
`and transfer control to the OS. In one embodiment, the
`components of the low-level portion 31 include:
`code for performing Power-On Self Test (POST), includ
`ing code for performing diagnostics, generating a boot
`beep and an error beep;
`Open Firmware code;
`hardware-specific Mac OS drivers (“ndrv's”) that are
`needed at boot time (drivers needed at boot time,
`e.g.,video drivers, network drivers, or disk drivers, are
`loaded from the Device Tree);
`HardwareInit code (i.e., the lowest-level code for initial
`izing the CPU, RAM, clock, system bus, etc.) without
`Mac OS-specific code;
`code for performing Run-Time Abstraction Services
`(RTAS). Certain hardware devices differ from machine
`to machine, but provide similar functions. RTAS pro
`vides such functions, including functions for accessing
`the real-time clock, NVRAM 20, restart, shutdown, and
`PCI configuration cycles. The I/O primitives for these
`functions in the ROM Image make use of RTAS.
`The POST code is the code executed when the computer
`first boots. This encompasses many of the traditional Mac
`ROM operations and is based on the HardwareInit code used
`in prior Macintosh OSs. The operations include setup and
`initialization of the microprocessor 10 and ASICs in the
`computer system 1.
`RTAS can be thought of as a Basic Input/Output System
`(BIOS). In particular, RTAS is the code that handles hard
`ware accesses needed by an OS. RTAS allows multiple OSs
`to obtain hardware services without having to know the
`specifics and handles things such as NVRAM (containing
`parameter RAM), time services (e.g., the real time clock),
`and other hardware-unique services (for example, PCd con
`
`Realtime 2020
`Page 15 of 19
`
`

`

`US 6,434,695 B1
`
`10
`
`15
`
`20
`
`30
`
`35
`
`40
`
`25
`
`7
`figuration cycles, power management, and the code needed
`to restart and shutdown). RTAS is instantiated in RAM
`wherever the OS asks it to be located, and persists after the
`OS boots. RTAS also allows for the provision of cache
`control functions.
`The Boot Info file 40 will now be described in greater
`detail. The Boot Info file 40 may be stored in the System
`Folder of the start-up volume. Alternatively, the Boot Info
`file 40 may be provided by a network server using, for
`example, the Bootstrap Protocol (Bootp), which is described
`in B. Croft et al., Network Working Group Request for
`Comments (RFC) 951, September 1985. Referring to FIG. 5,
`the Boot Info file 40 includes Open Firmware-specific Mac
`OS code 52, referred to as the “Trampoline code”; an Open
`Firmware header 51, which includes a Forth script that
`performs operations necessary to the start-up of the OS,
`including validation tests and transfer of control to the
`Trampoline code; and a compressed ROM Image 53, which
`represents the mid-level portion 32 of the OS 30. The
`purpose of the header 51 is, generally, to specify the loca
`tions of the other components of the Boot Info file 40. The
`purpose of the Trampoline code 53 generally is to handle the
`transition between the Open Firmware code in the Boot Rom
`11 and the ROM Image 52, as will be described in greater
`detail below.
`In one embodiment, the ROM image 53 includes the
`following components:
`the kernel of the OS;
`the 68K Emulator (code which enables other code
`designed for an older 68K processor to run on a later
`processor, such as the G3);
`higher-level software common to all Macintosh comput
`ers that is needed at boot time, including, for example:
`StartInit code (one-time hardware initialization code);
`and ToolBox routines, including QuickDraw; Apple
`Desktop Bus (ADB) Manager; Universal Serial Bus
`(USB) Manager (and mouse/keyboard drivers); SCSI
`Manager; ATA/IDE Manager; and provisions for net
`work booting; and
`software common to many Macintosh computers that is
`needed at boot time, such as: software for controlling
`ADB, power, clock, NVRAM, timers, interrupts, serial
`ports, USB, and SCSI.
`Note that in alternative embodiments of the OS 30, some
`or all of the above mentioned components of the ROM
`image 53 may be provided as separate, compressed ele
`45
`ments. These separate elements may be embodied in sepa
`rate Boot Info files or in a single Boot Info file. This
`approach would allow the OS components that are required
`for a given machine to be individually selected, decom
`pressed as part of the ROM image, and used as part of the
`OS 30, while unnecessary components could be ign