U.S. patent application number 12/756437 was filed with the patent office on 2010-12-16 for parametric build of uefi firmware.
Invention is credited to Stephen E. Jones, Eugene Khoruzhenko.
Application Number | 20100318961 12/756437 |
Document ID | / |
Family ID | 43307414 |
Filed Date | 2010-12-16 |
United States Patent
Application |
20100318961 |
Kind Code |
A1 |
Khoruzhenko; Eugene ; et
al. |
December 16, 2010 |
Parametric Build of UEFI Firmware
Abstract
Methods, systems, apparatuses and program products are disclosed
for providing parametric driven build of Unified Extensible
Firmware Interface based Personal Computer firmware, typically but
not essentially as BIOS. Provision is made for source databases
providing for multiple configurations, variants, revisions and
levels of capabilities including on non-hierarchical bases.
Inventors: |
Khoruzhenko; Eugene;
(Redmond, VA) ; Jones; Stephen E.; (Bellevue,
WA) |
Correspondence
Address: |
Phoenix Technologies Ltd.;ATTN: Legal Dept.
915 Murphy Ranch Road
Milpitas
CA
95035
US
|
Family ID: |
43307414 |
Appl. No.: |
12/756437 |
Filed: |
April 8, 2010 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
61268562 |
Jun 13, 2009 |
|
|
|
Current U.S.
Class: |
717/107 ;
717/121 |
Current CPC
Class: |
G06F 9/4411
20130101 |
Class at
Publication: |
717/107 ;
717/121 |
International
Class: |
G06F 9/44 20060101
G06F009/44 |
Claims
1. A method for building a plurality of firmware components to
execute a sequence of instructions in a device comprising a
computer, the method comprising: through the use of a build utility
program invoked in a build directory, scanning parent directories
of the build directory to locate a build file having a plurality of
module version specifications; creating an EFI (extensible firmware
interface) configurator file that provides information for
identifying a plurality of selected modules for building from a
plurality of versions of modules specified by the plurality of
module version specifications; and performing a build responsive to
a reading of the EFI configurator file.
2. The method of claim 1 wherein: the EFI (extensible firmware
interface) configurator provides for UEFI (unified extensible
firmware interface) capabilities.
3. The method of claim 1 wherein: the EFI (extensible firmware
interface) configurator file is created responsive to contents of
module definition files for a plurality of versions of
subdirectories comprising Kernel, Executive and System files.
4. The method of claim 1 further comprising: conditionally
including drivers in the firmware components responsive to build
condition parameter in a DXE.DSC (driver execution environment
description).
5. A computer program product comprising: at least one
computer-readable medium having instructions encoded therein, the
instructions when executed by a device comprising a computer cause
the device to operate to implement the method of claim 1.
6. The computer program product of claim 5 wherein: the device
further operates to implement the method of claim 2.
7. A method comprising: an act of modulating a signal onto an
electro-magnetic carrier wave impressed into a tangible medium, or
of demodulating the signal from the electro-magnetic carrier wave,
the signal having instructions encoded therein, the instructions
when executed by a device comprising a computer cause the device to
operate to implement the method of claim 1.
8. The method of claim 7 wherein: the device further operates to
implement the method of claim 2.
9. An electronic device comprising: a controller; and a memory
having instructions encoded therein, the instructions when executed
by the controller cause said electronic device to operate for
running an sequence of instructions by steps that implement the
method of claim 1.
10. The electronic device of claim 9 wherein: the electronic device
further operates to implement the method of claim 2.
Description
RELATED APPLICATIONS
[0001] This application claims priority to U.S. Provisional
application for a patent No. 61/268,562 entitled INNOVATIONS IN
SECURECORE TIANO 2.0 filed Jun. 13, 2009 inventor Stephen E. Jones
and which is incorporated in its entirety by this reference.
FIELD OF THE INVENTION
[0002] The present invention generally relates to personal
computers and devices sharing similar architectures and, more
particularly relates to a system and corresponding or related
method for parametric driven build of Unified Extensible Firmware
Interface based Personal Computer firmware. Similar processes and
entities within comparable computing apparatuses also fall within
the general scope of the invention.
BACKGROUND OF THE INVENTION
[0003] Modernly, the use of PCs (personal computers), including
so-called laptop and notebook computers, is increasingly common and
the computers themselves are ever more powerful and complex.
Hardware development continues at great rates resulting in families
of PCs that share parts and partial configurations yet have
evolving capabilities and legion configurations. A persistent
problem is the management of needed changes and enhancements to
firmwares as new versions of hardware and entirely new hardware
subsystems are phased in--while simultaneously avoiding excessive
duplication of effort across families of related, but different,
computer products. This leads to a need for capabilities above and
beyond those found in previously developed source and build
management systems.
[0004] Firmware development for PCs presents substantially
different problems (requiring substantially different solutions)
from software development. Previously developed software
development solutions either have systems programs to handle
routine programming minutiae and/or comprise systems program(s)
that can rely on firmware features to largely hide hardware
dependencies. Different again is development for embedded
firmware--that firmware typically supports only a very few hardware
configurations and/or versions, as contrasted with the very many of
each found in PC firmware.
[0005] Intel Corporation first defined EFI (Extensible Firmware
Interface) as the programming interface exposed by firmware to O/S
(operating system); former comparable firmwares were not
sufficiently portable nor scalable to Intel's CPU (Central
Processor Unit) IA64 (Intel Architecture for 64 bit widths)
architecture. A first implementation of the EFI interface became
known as Tiano, which Intel Corporation offered under license via a
web site. The UEFI (Unified EFI) Forum, a trade group, secured
architectural control over derivatives of EFI under a new
name--UEFI, with a right to support and extend. The UEFI Forum
specifies and documents the UEFI interface.
[0006] The PIWG (Platform Initialization Working Group) of the UEFI
Forum provides a common internal framework for Silicon and platform
drivers, so that a common understanding of the roles and methods
used by Silicon and platform drivers is developed by implementers
of UEFI firmware stacks together with the providers of the Silicon
and platform drivers. Silicon and platform drivers are each
well-known in the PC firmware arts.
[0007] The UEFI and related standards provide richness, but fail to
sufficiently address significant specific areas of concern
including at least:
Quality of board bring-up user experience Quality of BIOS (Basic
Input-Output System) customization experience Duration of system
bootloading and platform initialization time Level of reliability
Level of compatibility with Intel's Foundation Core (also known as
Foundation for short and a discrete part of Tiano) Scope for
platform innovation by BIOS vendors and partners and customers
thereof.
[0008] These attributes are described in a version of SCT
(SECURECORE Tiano.TM.) System Overview document published by
Phoenix.RTM. Technologies Ltd. (herein "Phoenix"). Adequately
addressing all of these areas of concern requires innovation above
and beyond what is described in UEFI and PIWG standards and related
documents. However, innovation needs to be at least substantially
backwards compatible with those same standards so as not to lose
benefits arising out of compliance therewith.
[0009] However, mere compliance is insufficient. One of the things
needed is a way of supporting the UEFI and PIWG standards (and
their future versions) while at the same time providing an
infrastructure for firmware that can be used for proprietary
innovation, going beyond the standards. Ultimately, these
innovations may themselves become official or de facto standards in
the industry, as Phoenix's channel is broad.
[0010] The standard packaging for the source codes of the Tiano
firmware (released under a TianoCore.org label), includes relevant
source code and facilitates methods for compiling, linking and for
merging the firmware programs together so that the resulting binary
codes may be used to produce firmware comprising run-time
instruction codes for a ROM (read-only memory) or its functional
equivalent. The standard packaging and methods have proven
insufficiently capable and flexible. These are improved upon as
described below.
[0011] A significant advantage of embodiments of the invention over
previously developed solutions is that it becomes possible to
provide for multiple types of chipsets (also Silicon), platforms
(also product families), hardware levels (especially improved,
significantly revised and novel subsystems), and firmware revision
levels (especially levels of deficiency and fault remedies) without
forcing a hierarchical approach to be used and without the
significant downside of that alternative.
SUMMARY OF THE INVENTION
[0012] The present invention provides a method for packaging,
compiling, linking, and merging programs that embodies the
invention. In addition program products and other means for
exploiting the invention are presented.
[0013] According to an aspect of the present invention an
embodiment of the invention may provide a method for building
firmware components with the use of a build utility program that
scans parent directories to locate a build file with multiple
module version specifications; creating an EFI (extensible firmware
interface) configurator file specific to those specification and
performing a build responsive thereto.
[0014] According to a further aspect of the invention a DXE.DSC
(driver execution environment description) capability is
provided.
[0015] According to a still further aspect of the invention the EFI
(extensible firmware interface) configurator file is created
responsive to contents of module definition files for a plurality
of versions of subdirectories comprising Kernel, Executive and
System files
[0016] Program products and programs transmitted by Internet and
similar means that provide for the method are also disclosed.
BRIEF DESCRIPTION OF THE DRAWINGS
[0017] The aforementioned and related advantages and features of
the present invention will become better understood and appreciated
upon review of the following detailed description of the invention,
taken in conjunction with the following drawings, which are
incorporated in and constitute a part of the specification,
illustrate an embodiment of the invention and wherein like numerals
represent like elements, and in which:
[0018] FIG. 1 is a schematic block diagram of an electronic device
configured as a target device into which firmware generated using
the present invention may be loaded and utilized;
[0019] FIG. 2 shows an organization of a EDK1 source tree with
corresponding Directory Organization.
[0020] FIG. 3 shows an SCT2 directory tree organization according
to an embodiment of the invention.
[0021] FIG. 4 depicts an exemplary Project Definition File
illustrating use of MODULE statements according to an embodiment of
the invention.
[0022] FIG. 5 is a flowchart that shows a method according to an
embodiment of the invention that implements the exemplary features
of FIGS. 3 and 4
[0023] FIG. 6 shows a sample output Project.env file.
[0024] FIG. 7 shows an excerpt of a System Dxe.DSC file.
[0025] FIG. 8 shows how an exemplary embodiment of the invention
may be encoded onto a computer medium or media; and
[0026] FIG. 9 shows how an exemplary embodiment of the invention
may be encoded, transmitted, received and decoded using
electro-magnetic waves.
DETAILED DESCRIPTION OF THE INVENTION
[0027] The numerous components shown in the drawings are presented
to provide a person of ordinary skill in the art a thorough,
enabling disclosure of the present invention. The description of
well-known components is not included within this description so as
not to obscure the disclosure or take away or otherwise reduce the
novelty of the present invention and the main benefits provided
thereby.
[0028] Embodiments of the disclosure presented herein provide
methods, systems, and computer-readable media for providing and
utilizing a means for packaging, compiling, linking, and merging
programs that embodies the invention. In addition program products
and other means for exploiting the invention are presented.
[0029] Referring now to the drawings, in which like numerals
represent like elements throughout the several figures, aspects of
an exemplary operating environment and the implementations provided
herein will be described. FIG. 1 is a schematic block diagram of an
electronic device configured to implement the firmware target
system operational functionality according to the present
invention.
[0030] FIG. 1 shows a computer 10 that is operative to provide an
EFI/UEFI firmware environment to provide a DXE (Driver Execution
Environment) phase and/or a BDS (Boot Device Selection) phase. DXE
and BDS are well known in the UEFI arts. The computer 10 typically
includes a baseboard (not shown in FIG. 1), or motherboard form of
printed circuit board to which a multitude of components or devices
are connected by way of a system bus or other electrical
communication path. In one illustrative embodiment, a CPU (central
processing unit) 12 operates in conjunction with a chipset 50. The
CPU 12 is a standard central processor that performs, inter alia,
arithmetic and logical operations necessary for the operation of
the computer.
[0031] Chipset 50 may include a Northbridge 14 and a Southbridge
32. The Northbridge 14 may be attached to CPU 12 by a FSB (Front
Side Bus) 13 and typically provides an interface between the CPU 12
and the remainder of the computer 10. The Northbridge 14 may also
provide an interface to a RAM (random access memory) 16 the main
memory for the computer 10 and, possibly, to other devices such as
an on-board graphics adapter (not shown in FIG. 1).
[0032] The Northbridge 14 is connected to a Southbridge 32 by a DMI
(direct media interface) 18. The Southbridge 32 may be responsible
for controlling many of the input/output functions of the computer
10 such as USB (universal serial bus), sound adapters, Ethernet
controllers and one or more GPIO (general purpose input/output)
port (None shown in FIG. 1). In one embodiment, a bus comprises a
PCI (peripheral component interconnect) bus circuit 22 to which a
disk storage subsystem 66 (often abbreviated to "disk") or other
storage devices for storing an operating system and application
programs may be attached.
[0033] The Southbridge 32 may also provide SMM (system management
mode) circuits and power management circuitry. A peripheral
interface 30 may also be provided by the Southbridge 32 for
connecting a SuperI/O (Super input-output) device 60. Southbridge
32 may also incorporate a timer circuit for generating timer
circuit interrupts typically at periodic intervals.
[0034] As known to those skilled in the art, an O/S (operating
system) such as may be stored on disk 66 comprises a set of
programs that control operations of a computer and allocation of
resources. An application program is software that runs on top of
(is loaded and directed by) the O/S software and uses computer
resources made available through the O/S to perform application
specific tasks desired by a user of the computer 10.
[0035] Disk 66 may also provide non-volatile storage for the
computer 10. Although the description of computer-readable media
contained herein refers to a mass storage device, such as a hard
disk or CD-ROM (Compact-Disc-ROM) drive, it should be appreciated
by those skilled in the art that computer-readable media can be any
available media that can be accessed by the computer 10. By way of
example, and not limitation, computer-readable media may comprise
computer storage media and communication media. Computer storage
media includes volatile and non-volatile, removable and
non-removable media implemented in a method or technology for
storage of information such as computer-readable instructions, data
structures, program modules or other data. Computer storage media
includes, but is not limited to, RAM, ROM, EPROM (Erasable,
programmable ROM), EEPROM (Electrically EPROM), serial EEPROM,
Flash memory or other solid state memory technology, CD-ROM, DVD
(Digital Versatile Disk), or other optical storage, magnetic
cassettes, magnetic tape, magnetic disk storage or other magnetic
storage devices well-known in the art, or any other medium which
can be used to store the desired information and which can be
accessed by the computer.
[0036] The peripheral interface 30 may also connect a computer
storage media such as a ROM (not shown) or, more typically, a flash
memory such as a NVRAM (non-volatile random access semiconductor
memory) 33 for storing UEFI platform firmware 34 that includes
program code containing the basic routines that help to start up
the computer 10 and to transfer information between elements within
the computer 10. The UEFI firmware 34 is compatible with the UEFI
Specification.
[0037] It should be appreciated that the computer 10 may comprise
other types of computing devices, including hand-held computers,
embedded computer systems, personal digital assistants, and other
types of computing devices known to those skilled in the art. It is
also contemplated that the computer 10 may not include all of the
components shown in FIG. 1, may include other components that are
not explicitly shown in FIG. 1, or may utilize an architecture
different from that shown in FIG. 1.
[0038] In an exemplary embodiment of the invention, Phoenix's SCT2
(SECURECORE Tiano version 2) uses build time paradigms derived in
large part from the previously developed EDK1 (EFI Development Kit
version 1), which is the previously developed and heretofore
standardized form of packaging for the firmware of type
TianoCore.org, discussed above. EDK1 includes respective source
code and methods for compiling, linking, and merging the relevant
software and firmware instruction codes together so that the
resulting binary information entities may be used to program a ROM
such as may typically be used in a targeted hardware configuration
at run time.
[0039] Such innovations may typically include means for
componentizing pieces of the software and firmware instruction
codes so that a large structure is presented with elements or
packages that are simplified for the product consumer or user. The
way that, for example, a product user may define what is produced
by the source code is also different in SCT2 as contrasted with
EDK1, and notably so through an innovation of project files with a
parametric build capability. Each driver program (mostly DXE device
drivers) represented therein may have compile-time parameters that
may be specified in the build, thus facilitating and promoting
product user control over various discrete policies (typically
fine-grained discrete policies) that may be embodied in each
driver. Additionally, overall system policies involving multiple
drivers are facilitated.
[0040] Moreover, as contrasted with EDK1, SCT2 simplifies EFI
Platform module concepts, as expressed in hundreds (or even
thousands) of source files, by introducing a Board-level module
that may be used by a product user for customization. In such an
embodiment, Platform modules are typically relegated to platform
class definitions that support multiple Board modules. These SDK
(so-called software development kit, but relating also to firmware)
innovations facilitate significant improvement as to productivity
(both during board bring-up and during customization processes),
and enable third parties to develop solutions that may be used by
Phoenix customers and/or other product users.
[0041] The ways in which Tiano-based EFI is augmented with these
innovations is new and historically unparalleled thus providing
significant new advantages.
[0042] FIG. 2 shows a prior art organization of an
Intel-architected EDK1 source tree as embodied as to a
corresponding Directory Organization.
[0043] In FIG. 2, the Foundation, consisting of code necessary to
locate and load drivers into memory in the run time environment, is
located entirely within its own directory, which is simply named
"Foundation". Intel Corporation maintains this code as creators and
owners of the basic fundamental part of the EFI architecture.
Accordingly, Intel supplies patches thereto from time to time.
Whenever patches are applied, they are (must be) applied in situ,
that is over the top of any and all existing Foundation folder
files. Although such patches primarily correct defects in the
Foundation itself, they might not always be entirely backwards
compatible. Consequently, patches are supplied on a per-tree basis,
and all projects within the tree must entirely accept (or, rarely,
entirely reject) all of the subject patches.
[0044] In the EDK1 Sample directory there are subdirectories
supporting potential or realizable product user (so-called
customer) adaptation, this is especially the case within the
Platform directory, and within which subdirectories are typically
created for each project to be supported by the build tree.
[0045] Moreover, the EDK1 Universal directory contains the system's
standard components that have general applicability to all, or
almost all, projects. Examples include the disk component, which
typically contains multiple drivers supporting disk I/O (block
input-output and related file systems) and a feature commonly known
as DxeIpl (for Driver execution environment initial program
loader), which launches the DXE (Driver execution environment)
runtime component.
[0046] In contrast, FIG. 3 represents a typical SCT2 directory tree
organization according to an embodiment of the invention and which
provides an exemplary illustration of innovative SCT2 Code
Organization. As depicted, in such a tree of build files a
plurality of logical components (such as Foundation, Kernel,
Exec(executive), System, Platform, Board, Project) is presented and
each contains a further layer of subdirectories (herein enumerated
000, 001, 002, et seq) each supporting versioning of the respective
component.
[0047] Thus, as a newer version of each component is created, it
may be assigned a new version number in local sequence. This
thereby allows more than one version (or logical revision) of a
component to be available in the selected tree. This innovation
makes it possible for a project file (shown as
Projects\ProjectName\000\Project.def in FIG. 3) to specify the
modules and their respective versions to be included on a project
basis. As the customer or product user has a development tree that
matures, so earlier projects that may be using correspondingly
earlier versions of the Foundation, Kernel, Executive, System, or
Silicon drivers may continued to be maintained through revision.
This may occur all while newer projects may refer to more recent
releases of those same (or equivalent or corresponding)
components.
[0048] The exemplary SCT 2.0 source tree consists of the versioned
modules. Any directory that has the 3-digit numeric subdirectories
is a module. The numeric subdirectories store different revisions
of the module's source code; they should start from 000 and
increment as the new module revisions are created. Also, because
even the build itself is versioned, it is possible for the SCT
framework to support dissimilar builds, including those not based
on EDK I, on a project-by-project basis.
[0049] In order that project-based build may be achieved without
modification to the EDK1 source itself (which is prohibited if
compatibility and conformity is required) a novel top-level
directory is created. In the exemplary embodiment of the invention,
this new top-level directory is herein called "Projects", and
whereat each project to be defined is assigned its own respective
subdirectory. Within a given project's subdirectory hierarchy,
further versioning (and version naming) subdirectories are created,
thus providing a means for supporting multiple releases of a
particular project within one single directory tree.
[0050] The selected versioned directory (for example 000--a
directory mapped to a first version) is known as the project
directory. It contains the necessary files to define a given
project that is to produce a binary target image. In the exemplary
embodiment of the invention, the Project.def file within this
directory may be a text file that contains the project definition
statements that drive the build, such as that shown in FIG. 4.
[0051] FIG. 4 is an exemplary Project Definition File illustrating
use of MODULE statements. In FIG. 4, MODULE statements are depicted
that may be used to declare the components within an exemplary SCT2
build tree. It is intended that these are to be included in the
exemplary build, and also specify locations of pertinent EDK1 build
automation files.
[0052] In an exemplary embodiment of the invention the build
process is controlled by the project file (named PROJECT.DEF),
which configures the build with the Definition Language statements.
The nature and purpose of the Definition Language is to define
configuration objects used by a utility program to create the
output files used in other phases of the build. Such output files
may include: a Project.h file for #define statements included for C
language source program; a Project.inc file for symbol definitions
included in Assembly language source program; a Project.env file
for symbol definitions, as may be used in INF and DSC files and/or
a Cmdb.bin file for a kernel CM (Configuration Manager) database
used for BIOS runtime configuration and/or reconfiguration.
[0053] The project file may be processed by an SCTPROJ utility from
a top level downwards, so that statements placed towards the end of
the file will typically override definitions placed further from
the end of the file. Within the project file the first module to
include is the module named "Build"; it may contains some
overarching definitions, such as a version number of the
recommended and tested development suite used. One such development
suite is the popular Visual Studio product. The order of the
modules specified in the project file may typically follow their
respective architectural position. For example in the sequence:
Foundation, Kernel, Executive, and System. Thus subsequent modules
may augment or override objects created in preceding modules. In a
similar manner, Core modules are typically followed by the Silicon,
Platform, Board, and other modules in that particular order.
[0054] Still referring to FIG. 4, an exemplary MODULE statement in
a .DEF might be of the form: MODULE ModuleName, ModuleVersion,
[Parameter]
[0055] Here, MODULE is a keyword. The second lexeme is the Module
name, followed by the required version number and an optional
special parameter.
[0056] In an embodiment of the invention, the special parameter is
interpreted as according whether the parameter contains
underscores. If there are underscores then SCTPROJ creates an
equate: Parameter=ModulePath. This may be done so as to create the
additional symbols for the module path, which may be required, for
example, by third-party code.
[0057] Conversely, if underscores are absent from the parameter,
then SCTPROJ creates a additional path equate similar to the above
described path, but with an "SCT_PATH_" prefix:
SCT_PATH_Parameter=ModulePath.
[0058] MODULE declarations enable the SCTPROJ tool to find the
specified versioned modules in the current source tree and create
the necessary path symbols used by ProcessDSC for processing INF
and DSC files. SCTPROJ may also look for a Build folder and
MODULE.DEF file in the module's own root directory. The content of
the MODULE.DEF file may thus be included in processing of the
PROJECT.DEF file, thereby facilitating overrides as described
above. The Module's Build folder contains the standard Pei.dsc,
Dxe.dsc, and Library.dsc files that have INF file entries for the
components included in the module. When SCTPROJ processes a MODULE
statement, it may add these DSC files as "!include" entries into
the corresponding temporary files: ProjectPei.dsc, ProjectDxe.dsc,
and ProjectLib.dsc. In this way, these project level DSC files are
auto-generated in the project's Temp folder and are included by the
main Build.dsc located in the core Build folder. The main Build.dsc
file is pointed to by the project's MAKEFILE to be passed to a
ProcessDSC utility.
[0059] FIG. 5 is a flowchart that shows a method according to an
embodiment of the invention that implements the exemplary features
prescribed in FIGS. 3 and 4 above. At Ref. 5100 entry is made to a
function for building a firmware (or firmware and software) image
according to an embodiment of the invention.
[0060] At Ref. 5110, a build utility program with an exemplary name
of PHMAKE is invoked such as via a DOS (Disk Operating System)
prompt or through an integrated environment, with the project
directory being the current working directory. Build utility
programs are well-known in the firmware or software build arts;
some types of build utility programs are colloquially (or sometimes
formally) known as "Make programs". To invoke a build utility
program in a particular directory is a term of art for initiating
and running a build utility program that has specific knowledge of
how to locate a most-significant, or current project, directory
upon which many or most aspects of the build particulars are
derived. The current working directory is an exemplary embodiment
of the current project directory concept. A current project
directory may be a focal point of a multiplicity of versions of
build versions derived from an instance of build-time
parameterization. Such terminologies are well-known in the firmware
or software build arts, as appropriate.
[0061] At Ref. 5120, a PHMAKE.EXE program to implement the PHMAKE
function scans its own parent directories for a configurator file
herein called PHMAKE.CFG. This PHMAKE.CFG file provides directives
to PHMAKE that allow it to identify name and version of the build
files to be used in the present build.
[0062] At Ref. 5130, the PHMAKE.EXE program runs a MAKEFILE located
in the Build directory, passing it symbols specifying (1) the
project's name and version, (2) the location of the build files,
and (3) the build tree's root directory name (in the example this
is C:\SCT.) MAKEFILE is well-known in the art. The MAKEFILE in turn
invokes, supervises and runs the top-level build, including running
a utility program, SCTPROJ.EXE, to process the respective
Project.def file.
[0063] At Ref. 5140, the SCTPROJ.EXE program attempts to access
MODULE.DEF files, located in each of the component directories
specified by the MODULE statements in the project file. Whenever
and wherever relevant MODULE.DEF files are found, their statements,
consisting of Option and Config definitions are processed by
SCTPROJ.EXE. These Option and Config definitions act to specify
default values for the build options later each used by their
respective component.
[0064] At Ref. 5150, the SCTPROJ.EXE program parses the Project.def
file to produce a Project.h file in a temporary (temp\) directory
within the project directory that typically contains #define
statements associated with each Option declaration (for example
Parametric Build uses this build product.) A Project.inc file is
also created for input into build of Assembly Language
programs.
[0065] Next, at Ref. 5160, a Project.env file is created; this is
necessarily compatible with the EDK1 Config.env file. FIG. 6
(below) shows a sample output Project.env file, illustrating how
the MODULE and Option statements are transformed into declarations
in the Project.env file.
[0066] Still referring to FIG. 5, at Ref. 5170, the PHMAKE.EXE
program continues to read the MAKEFILE after SCTPROJ.EXE completes
its processing, causing the EDK1 compatible MAKEFILE to receive
control in substantially the same manner as with previously
developed build systems and with the information needed to
parameterize the build and to locate the needed build
components.
[0067] At Ref. 5180, the remainder of the build proceeds using EDK1
build tools. This may include DSC (description files) as described
below in connection with FIG. 8. At Ref. 5190 the method ends.
[0068] FIG. 6 shows a sample output Project.env file that has been
methodically produced by the exemplary SCTPROJ.EXE build
utility.
[0069] FIG. 7 shows an excerpt of a System Dxe.DSC (driver
execution environment description) file, showing use of a
BUILD_CONDITION parameter.
[0070] Build parameters, such as OPTION_DEBUG_SERIAL_DXE, are used
to render conditional the inclusion of drivers in the build, using
the EDK's DSC file system. In previously developed (non-enhanced)
EDK1 style builds, a BUILD.DSC file in the platform tip directory
containing a list of drivers to be included in the build, is read
by the EDK1 build tool PROCESSDSC.EXE.
[0071] In contrast, in an enhanced build according to an embodiment
of the invention, individual statements are replaced with !INCLUDE
statements that refer to standardized DSC files in the respective
module directories and which have corresponding BUILD_CONDITION
parameters. This causes PROCESS.DSC to include only those files
wherein the respective parameters in the manufactured Config.env
file evaluate to TRUE. FIG. 7 shows an excerpt of the System's
Dxe.DSC file, illustrating how certain drivers may be conditionally
included in the build in the context of the present exemplary
description.
[0072] With regards to FIG. 8, computer instructions to be
incorporated into an electronic device 10 may be distributed as
manufactured firmware and/or software computer products 510 using a
variety of possible media 530 having the instructions recorded
thereon such as by using a storage recorder 520. Often in products
as complex as those that deploy the invention, more than one medium
may be used, both in distribution and in manufacturing relevant
product. Only one medium is shown in FIG. 8 for clarity but more
than one medium may be used and a single computer product may be
divided among a plurality of media.
[0073] FIG. 9 shows how an exemplary embodiment of the invention
may be encoded, transmitted, received and decoded using
electro-magnetic waves.
[0074] With regard to FIG. 9, additionally, and especially since
the rise in Internet usage, computer products 610 may be
distributed by encoding them into signals modulated as a wave. The
resulting waveforms may then be transmitted by a transmitter 640,
propagated as tangible modulated electro-magnetic carrier waves 650
and received by a receiver 660. Upon reception they may be
demodulated and the signal decoded into a further version or copy
of the computer product 611 in a memory or other storage device
that is part of a second electronic device 11 and typically similar
in nature to electronic device 10.
[0075] Other topologies and/or devices could also be used to
construct alternative embodiments of the invention. The embodiments
described above are exemplary rather than limiting and the bounds
of the invention should be determined from the claims. Although
preferred embodiments of the present invention have been described
in detail hereinabove, it should be clearly understood that many
variations and/or modifications of the basic inventive concepts
herein taught which may appear to those skilled in the present art
will still fall within the spirit and scope of the present
invention, as defined in the appended claims.
* * * * *