mirror of
https://github.com/tianocore/edk2
synced 2026-08-27 00:23:19 -04:00
IntelFsp2Pkg: Fix markdownlint errors
Fixing all markdown lint errors found by running markdownlint-cli. Verified that rendering still shows valid information. Signed-off-by: Aaron Pop <aaronpop@microsoft.com>
This commit is contained in:
parent
2d43dcfc6c
commit
f7776de02e
7 changed files with 193 additions and 96 deletions
|
|
@ -93,7 +93,7 @@
|
|||
|
||||
## options defined .pytool/Plugin/MarkdownLintCheck
|
||||
"MarkdownLintCheck": {
|
||||
"AuditOnly": True, # If True, log all errors and then mark as skipped
|
||||
"AuditOnly": False, # If True, log all errors and then mark as skipped
|
||||
"IgnoreFiles": [] # package root relative file, folder, or glob pattern to ignore
|
||||
}
|
||||
}
|
||||
|
|
|
|||
|
|
@ -2,6 +2,6 @@
|
|||
|
||||
This package provides the component to create an FSP binary.
|
||||
|
||||
Source Repository: https://github.com/tianocore/edk2/tree/master/IntelFsp2Pkg
|
||||
Source Repository: <https://github.com/tianocore/edk2/tree/master/IntelFsp2Pkg>
|
||||
|
||||
A whitepaper to describe the IntelFsp2Pkg: https://firmware.intel.com/sites/default/files/A_Tour_Beyond_BIOS_Creating_the_Intel_Firmware_Support_Package_with_the_EFI_Developer_Kit_II_%28FSP2.0%29.pdf
|
||||
A whitepaper to describe the IntelFsp2Pkg: <https://firmware.intel.com/sites/default/files/A_Tour_Beyond_BIOS_Creating_the_Intel_Firmware_Support_Package_with_the_EFI_Developer_Kit_II_%28FSP2.0%29.pdf>
|
||||
|
|
|
|||
|
|
@ -1,51 +1,70 @@
|
|||
#Name
|
||||
**ConfigEditor.py** is a python script with a GUI interface that can support changing configuration settings directly from the interface without having to modify the source.
|
||||
# Name
|
||||
|
||||
#Description
|
||||
This is a GUI interface that can be used by users who would like to change configuration settings directly from the interface without having to modify the SBL source.
|
||||
**ConfigEditor.py** is a python script with a GUI interface that can support changing configuration
|
||||
settings directly from the interface without having to modify the source.
|
||||
|
||||
## Description
|
||||
|
||||
This is a GUI interface that can be used by users who would like to change configuration settings
|
||||
directly from the interface without having to modify the SBL source.
|
||||
This tool depends on Python GUI tool kit Tkinter. It runs on both Windows and Linux.
|
||||
The user needs to load the YAML file along with DLT file for a specific board into the ConfigEditor, change the desired configuration values. Finally, generate a new configuration delta file or a config binary blob for the newly changed values to take effect. These will be the inputs to the merge tool or the stitch tool so that new config changes can be merged and stitched into the final configuration blob.
|
||||
|
||||
The user needs to load the YAML file along with DLT file for a specific board into the ConfigEditor,
|
||||
change the desired configuration values. Finally, generate a new configuration delta file or a config
|
||||
binary blob for the newly changed values to take effect. These will be the inputs to the merge tool or
|
||||
the stitch tool so that new config changes can be merged and stitched into the final configuration blob.
|
||||
|
||||
It supports the following options:
|
||||
|
||||
## 1. Open Config YAML file
|
||||
|
||||
This option loads the YAML file for a FSP UPD into the ConfigEditor to change the desired configuration values.
|
||||
|
||||
This option loads the YAML file for a VFR config data into the ConfigEditor to view the desired form values.
|
||||
|
||||
#####Example:
|
||||
```
|
||||
### Example
|
||||
|
||||

|
||||
|
||||

|
||||
```
|
||||
|
||||
## 2. Open Config BSF file
|
||||
This option loads the BSF file for a FSP UPD into the ConfigEditor to change the desired configuration values. It works as a similar fashion with Binary Configuration Tool (BCT)
|
||||
|
||||
This option loads the BSF file for a FSP UPD into the ConfigEditor to change the desired configuration
|
||||
values. It works as a similar fashion with Binary Configuration Tool (BCT)
|
||||
|
||||
## 3. Show Binary Information
|
||||
|
||||
This option loads configuration data from FD file and displays it in the ConfigEditor.
|
||||
|
||||
## 4. Save Config Data to Binary
|
||||
|
||||
This option generates a config binary blob for the newly changed values to take effect.
|
||||
|
||||
## 5. Load Config Data from Binary
|
||||
|
||||
This option reloads changed configuration from BIN file into the ConfigEditor.
|
||||
|
||||
## 6. Load Config Changes from Delta File
|
||||
|
||||
This option loads the changed configuration values from Delta file into the ConfigEditor.
|
||||
|
||||
## 7. Save Config Changes to Delta File
|
||||
|
||||
This option generates a new configuration delta file for the newly changed values to take effect.
|
||||
|
||||
## 8. Save Full Config Data to Delta File
|
||||
|
||||
This option saves all the changed configuration values into a Delta file.
|
||||
|
||||
## 9. Search feature
|
||||
|
||||
This feature helps the user to easily find any configuration item they are looking for in ConfigEditor.
|
||||
A text search box is available on the Top Right Corner of ConfigEditor. To use this feature the user should type the name or a key word of the item they want to search in the text box and then click on the "Search" button. This will display all the items which contains that particular word searched by the user.
|
||||
A text search box is available on the Top Right Corner of ConfigEditor. To use this feature the user
|
||||
should type the name or a key word of the item they want to search in the text box and then click on
|
||||
the "Search" button. This will display all the items which contains that particular word searched by the user.
|
||||
|
||||
## Running Configuration Editor:
|
||||
## Running Configuration Editor
|
||||
|
||||
**python ConfigEditor.py**
|
||||
```python
|
||||
python ConfigEditor.py
|
||||
```
|
||||
|
|
|
|||
|
|
@ -1,4 +1,5 @@
|
|||
#Name
|
||||
# Name
|
||||
|
||||
**FspDscBsf2Yaml.py** The python script that generates YAML file for
|
||||
the Boot Settings from an EDK II Platform Description (**DSC**) file
|
||||
or from a Boot Settings File (**BSF**). It is created to help
|
||||
|
|
@ -6,12 +7,14 @@ transitioning FSP Updateable Product Data (**UPD**) file format to
|
|||
new standardized YAML format so that it can be configured through
|
||||
open source tools.
|
||||
|
||||
#Synopsis
|
||||
```
|
||||
## Synopsis
|
||||
|
||||
```text
|
||||
FspDscBsf2Yaml DscFile|BsfFile YamlFile
|
||||
```
|
||||
|
||||
#Description
|
||||
## Description
|
||||
|
||||
**FspDscBsf2Yaml.py** is a script that generates configuration options from an
|
||||
**EDK II Platform Description (DSC)** file or **a Boot Settings File (BSF)** file.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,16 +1,21 @@
|
|||
#Name
|
||||
# Name
|
||||
|
||||
<!-- markdownlint-disable MD024 -->
|
||||
|
||||
**GenCfgOpt.py** The python script that generates UPD text (**.txt**) files for
|
||||
the compiler, header files for the UPD regions, and generates a Boot Settings
|
||||
File (**BSF**), all from an EDK II Platform Description (**DSC**) file.
|
||||
|
||||
#Synopsis
|
||||
```
|
||||
## Synopsis
|
||||
|
||||
```text
|
||||
GenCfgOpt UPDTXT PlatformDscFile BuildFvDir [TxtOutFile] [-D Macros]
|
||||
GenCfgOpt HEADER PlatformDscFile BuildFvDir [InputHFile] [-D Macros]
|
||||
GenCfgOpt GENBSF PlatformDscFile BuildFvDir BsfOutFile [-D Macros]
|
||||
```
|
||||
|
||||
#Description
|
||||
## Description
|
||||
|
||||
**GenCfgOpt.py** is a script that generates configuration options from an
|
||||
**EDK II Platform Description (DSC)** file. It has three functions.
|
||||
|
||||
|
|
@ -28,6 +33,7 @@ the **'build'** command; the **GENBSF** use case may be done at any time.
|
|||
The following sections explain the three use cases.
|
||||
|
||||
## 1. GenCfgOpt.py UPDTXT
|
||||
|
||||
The **UPDTXT** option creates a text file with all the UPD entries, offsets,
|
||||
size in bytes, and values. **GenCfgOpt** reads this information from the
|
||||
**[PcdsDynamicVpd.Upd]** section of the project's DSC file. The DSC file allows
|
||||
|
|
@ -36,7 +42,7 @@ introducing gaps between entries. **GenCfgOpt** fills in these gaps with UPD
|
|||
entries that have the generic names **UnusedUpdSpaceN** where N begins with 0
|
||||
and increments. The command signature for **UPDTXT** is:
|
||||
|
||||
```
|
||||
```text
|
||||
GenCfgOpt UPDTXT PlatformDscFile BuildFvDir [TxtOutFile] [-D Macros]
|
||||
```
|
||||
|
||||
|
|
@ -52,13 +58,16 @@ must follow the form ```?D <MACRO_NAME>=<VALUE>```.
|
|||
will only re-create it if the DSC was modified after it was created.
|
||||
|
||||
## 2. GenCfgOpt.py HEADER
|
||||
|
||||
The **HEADER** option creates header files in the build folder. Both header
|
||||
files define the ```_UPD_DATA_REGION``` data structures in FspUpd.h, FsptUpd.h,
|
||||
FspmUpd.h and FspsUpd.h. In these header files any undefined elements of
|
||||
structures will be added as **ReservedUpdSpaceN** beginning with N=0. The
|
||||
command signature for **HEADER** is
|
||||
|
||||
```GenCfgOpt HEADER PlatformDscFile BuildFvDir [InputHFile] [-D Macros]```
|
||||
```text
|
||||
GenCfgOpt HEADER PlatformDscFile BuildFvDir [InputHFile] [-D Macros]
|
||||
```
|
||||
|
||||
**PlatformDscFile** and **BuildFvDir** are described in the previous section.
|
||||
The optional **InputHFile** is a header file that may contain data definitions
|
||||
|
|
@ -72,29 +81,36 @@ the DSC file. The special commands begin with ```!HDR```, for header. The
|
|||
following table summarizes the two command options.
|
||||
|
||||
### HEADER
|
||||
|
||||
Use the **HEADER** command to hide specific variables in the public header file.
|
||||
In your project DSC file, use ```!HDR HEADER:{OFF}``` at the beginning of the
|
||||
section you wish to hide and ```!HDR HEADER:{ON}``` at the end.
|
||||
|
||||
### STRUCT
|
||||
|
||||
The **STRUCT** command allows you to specify a specific data type for a
|
||||
variable. You can specify a pointer to a data struct, for example. You define
|
||||
the data structure in the **InputHFile** between
|
||||
```!EXPORT EXTERNAL_BOOTLOADER_STRUCT_BEGIN``` and
|
||||
```!EXPORT EXTERNAL_BOOTLOADER_STRUCT_END```.
|
||||
|
||||
#####Example:
|
||||
```!HDR STRUCT:{MY_DATA_STRUCT*}```
|
||||
#### Example
|
||||
|
||||
```text
|
||||
!HDR STRUCT:{MY_DATA_STRUCT*}
|
||||
```
|
||||
|
||||
You then define ```MY_DATA_STRUCT``` in **InputHFile**.
|
||||
|
||||
### EMBED
|
||||
|
||||
The **EMBED** command allows you to put one or more UPD data into a specify data
|
||||
structure. You can utilize it as a group of UPD for example. You must specify a
|
||||
start and an end for the specify data structure.
|
||||
|
||||
#####Example:
|
||||
```
|
||||
#### Example
|
||||
|
||||
```text
|
||||
!HDR EMBED:{MY_DATA_STRUCT:MyDataStructure:START}
|
||||
gTokenSpaceGuid.Upd1 | 0x0020 | 0x01 | 0x00
|
||||
gTokenSpaceGuid.Upd2 | 0x0021 | 0x01 | 0x00
|
||||
|
|
@ -102,8 +118,9 @@ start and an end for the specify data structure.
|
|||
gTokenSpaceGuid.UpdN | 0x0022 | 0x01 | 0x00
|
||||
```
|
||||
|
||||
#####Result:
|
||||
```
|
||||
##### Result
|
||||
|
||||
```text
|
||||
typedef struct {
|
||||
/** Offset 0x0020
|
||||
**/
|
||||
|
|
@ -126,6 +143,7 @@ start and an end for the specify data structure.
|
|||
```
|
||||
|
||||
## 3. GenCfgOpt .py GENBSF
|
||||
|
||||
The **GENBSF** option generates a BSF from the UPD entries in a package's DSC
|
||||
file. It does this by parsing special commands found in the comments of the DSC
|
||||
file. They roughly match the keywords that define the different sections of the
|
||||
|
|
@ -141,20 +159,25 @@ relative path to where the BSF should be stored.
|
|||
Every BSF command in the DSC file begins with **!BSF** or **@Bsf**. The
|
||||
following table summarizes the options that come after **!BSF** or **@Bsf**:
|
||||
|
||||
# BSF Commands Description
|
||||
###PAGES
|
||||
## BSF Commands Description
|
||||
|
||||
### PAGES
|
||||
|
||||
**PAGES** maps abbreviations to friendly-text descriptions of the pages in a BSF.
|
||||
|
||||
#####Example:
|
||||
#### Example
|
||||
|
||||
```!BSF PAGES:{PG1:?Page 1?, PG2:?Page 2?}``` or
|
||||
|
||||
```@Bsf PAGES:{PG1:?Page 1?, PG2:?Page 2?}```
|
||||
|
||||
###PAGE
|
||||
### PAGE
|
||||
|
||||
This marks the beginning of a page. Use the abbreviation specified in **PAGES**
|
||||
command.
|
||||
|
||||
#####Example:
|
||||
#### Example
|
||||
|
||||
```!BSF PAGE:{PG1}``` or
|
||||
|
||||
```@Bsf PAGE:{PG1}```
|
||||
|
|
@ -162,32 +185,38 @@ command.
|
|||
All the entries that come after this command are assumed to be on that page,
|
||||
until the next **PAGE** command
|
||||
|
||||
###FIND
|
||||
### FIND
|
||||
|
||||
FIND maps to the BSF **Find** command. It will be placed in the **StructDef**
|
||||
region of the BSF and should come at the beginning of the UPD sections of the
|
||||
DSC, immediately before the signatures that mark the beginning of these
|
||||
sections. The content should be the plain-text equivalent of the signature. The
|
||||
signature is usually 8 characters.
|
||||
|
||||
#####Example:
|
||||
#### Example
|
||||
|
||||
```!BSF FIND:{PROJSIG1}``` or
|
||||
|
||||
```@Bsf FIND:{PROJSIG1}```
|
||||
|
||||
###BLOCK
|
||||
### BLOCK
|
||||
|
||||
The BLOCK command maps to the **BeginInfoBlock** section of the BSF. There are
|
||||
two elements: a version number and a plain-text description.
|
||||
|
||||
#####Example:
|
||||
#### Example
|
||||
|
||||
```!BSF BLOCK:{NAME:"My platform name", VER:"0.1"}``` or
|
||||
|
||||
```@Bsf BLOCK:{NAME:"My platform name", VER:"0.1"}```
|
||||
|
||||
###NAME
|
||||
### NAME
|
||||
|
||||
**NAME** gives a plain-text for a variable. This is the text label that will
|
||||
appear next to the control in **BCT**.
|
||||
|
||||
#####Example:
|
||||
#### Example
|
||||
|
||||
```!BSF NAME:{Variable 0}``` or
|
||||
|
||||
```@Bsf NAME:{Variable 0}```
|
||||
|
|
@ -195,20 +224,23 @@ appear next to the control in **BCT**.
|
|||
If the **!BSF NAME** or **@Bsf NAME** command does not appear before an entry
|
||||
in the UPD region of the DSC file, then that entry will not appear in the BSF.
|
||||
|
||||
###TYPE
|
||||
### TYPE
|
||||
|
||||
The **TYPE** command is used either by itself or with the **NAME** command. It
|
||||
is usually used by itself when defining an **EditNum** field for the BSF. You
|
||||
specify the type of data in the second parameter and the range of valid values
|
||||
in the third.
|
||||
|
||||
#####Example:
|
||||
#### Example
|
||||
|
||||
```!BSF TYPE:{EditNum, HEX, (0x00,0xFF)}``` or
|
||||
|
||||
```@Bsf TYPE:{EditNum, HEX, (0x00,0xFF)}```
|
||||
|
||||
**TYPE** appears on the same line as the **NAME** command when using a combo-box.
|
||||
|
||||
#####Example:
|
||||
#### Example
|
||||
|
||||
```!BSF NAME:{Variable 1} TYPE:{Combo}``` or
|
||||
```@Bsf NAME:{Variable 1} TYPE:{Combo}```
|
||||
|
||||
|
|
@ -216,20 +248,24 @@ There is a special **None** type that puts the variable in the **StructDef**
|
|||
region of the BSF, but doesn't put it in any **Page** section. This makes the
|
||||
variable visible to BCT, but not to the end user.
|
||||
|
||||
###HELP
|
||||
### HELP
|
||||
|
||||
The **HELP** command defines what will appear in the help text for each control
|
||||
in BCT.
|
||||
|
||||
#####Example:
|
||||
#### Example
|
||||
|
||||
```!BSF HELP:{Enable/disable LAN controller.}``` or
|
||||
|
||||
```@Bsf HELP:{Enable/disable LAN controller.}```
|
||||
|
||||
###OPTION
|
||||
### OPTION
|
||||
|
||||
The **OPTION** command allows you to custom-define combo boxes and map integer
|
||||
or hex values to friendly-text options.
|
||||
|
||||
#####Example:
|
||||
#### Example
|
||||
|
||||
```!BSF OPTION:{0:IDE, 1:AHCI, 2:RAID}```
|
||||
|
||||
```!BSF OPTION:{0x00:0 MB, 0x01:32 MB, 0x02:64 MB}```
|
||||
|
|
@ -240,25 +276,29 @@ or
|
|||
|
||||
```@Bsf OPTION:{0x00:0 MB, 0x01:32 MB, 0x02:64 MB}```
|
||||
|
||||
###FIELD
|
||||
### FIELD
|
||||
|
||||
The **FIELD** command can be used to define a section of a consolidated PCD
|
||||
such that the PCD will be displayed in several fields via BCT interface instead
|
||||
of one long entry.
|
||||
|
||||
#####Example:
|
||||
#### Example
|
||||
|
||||
```!BSF FIELD:{PcdDRAMSpeed:1}``` or
|
||||
|
||||
```@Bsf FIELD:{PcdDRAMSpeed:1}```
|
||||
|
||||
###ORDER
|
||||
### ORDER
|
||||
|
||||
The **ORDER** command can be used to adjust the display order for the BSF items.
|
||||
By default the order value for a BSF item is assigned to be the UPD item
|
||||
```(Offset * 256)```. It can be overridden by declaring **ORDER** command using
|
||||
```(Offset *256)```. It can be overridden by declaring **ORDER** command using
|
||||
format ORDER: ```{HexMajor.HexMinor}```. In this case the order value will be
|
||||
```(HexMajor*256+HexMinor)```. The item order value will be used as the sort key
|
||||
during the BSF item display.
|
||||
|
||||
#####Example:
|
||||
#### Example
|
||||
|
||||
```!BSF ORDER:{0x0040.01}``` or
|
||||
|
||||
```@Bsf ORDER:{0x0040.01}```
|
||||
|
|
@ -293,11 +333,14 @@ same line following the **!BSF** or **@Bsf** keyword or they may appear on
|
|||
separate lines to improve readability.
|
||||
|
||||
There are four alternative ways to replace current BSF commands.
|
||||
|
||||
### 1. ```# @Prompt```
|
||||
|
||||
An alternative way replacing **NAME** gives a plain-text for a
|
||||
variable. This is the text label that will appear next to the control in BCT.
|
||||
|
||||
#####Example:
|
||||
#### Example
|
||||
|
||||
```# @Prompt Variable 0```
|
||||
|
||||
The above example can replace the two methods as below.
|
||||
|
|
@ -310,10 +353,12 @@ If the ```# @Prompt``` command does not appear before an entry in the UPD region
|
|||
of the DSC file, then that entry will not appear in the BSF.
|
||||
|
||||
### 2. ```##```
|
||||
|
||||
An alternative way replacing **HELP** command defines what will appear in the
|
||||
help text for each control in BCT.
|
||||
|
||||
#####Example:
|
||||
#### Example
|
||||
|
||||
```## Enable/disable LAN controller.```
|
||||
|
||||
The above example can replace the two methods as below.
|
||||
|
|
@ -323,13 +368,15 @@ The above example can replace the two methods as below.
|
|||
```@Bsf HELP:{Enable/disable LAN controller.}```
|
||||
|
||||
### 3. ```# @ValidList```
|
||||
|
||||
An alternative way replacing **OPTION** command allows you to custom-define
|
||||
combo boxes and map integer or hex values to friendly-text options.
|
||||
|
||||
#####Example:
|
||||
#### Example
|
||||
|
||||
``` # @ValidList 0x80000003 | 0, 1, 2 | IDE, AHCI, RAID
|
||||
Error Code | Options | Descriptions
|
||||
```
|
||||
```text
|
||||
|
||||
The above example can replace the two methods as below.
|
||||
|
||||
|
|
@ -338,16 +385,17 @@ The above example can replace the two methods as below.
|
|||
```@Bsf OPTION:{0:IDE, 1:AHCI, 2:RAID}```
|
||||
|
||||
### 4. ```# @ValidRange```
|
||||
|
||||
An alternative way replace **EditNum** field for the BSF.
|
||||
|
||||
#####Example:
|
||||
#### Example
|
||||
|
||||
```# @ValidRange 0x80000001 | 0x0 ? 0xFF
|
||||
Error Code | Range
|
||||
```
|
||||
```text
|
||||
|
||||
The above example can replace the two methods as below.
|
||||
|
||||
```!BSF TYPE:{EditNum, HEX, (0x00,0xFF)}``` or
|
||||
|
||||
```@Bsf TYPE:{EditNum, HEX, (0x00,0xFF)}```
|
||||
|
||||
|
|
|
|||
|
|
@ -1,101 +1,113 @@
|
|||
# Name
|
||||
|
||||
<!-- markdownlint-disable MD024 -->
|
||||
|
||||
**_PatchFv.py_** - The python script that patches the firmware volumes (**FV**)
|
||||
with in the flash device (**FD**) file post FSP build.
|
||||
From version 0.60, script is capable of patching flash device (**FD**) directly.
|
||||
|
||||
# Synopsis
|
||||
## Synopsis
|
||||
|
||||
```
|
||||
```text
|
||||
PatchFv FvBuildDir [FvFileBaseNames:]FdFileBaseNameToPatch ["Offset, Value"]+
|
||||
| ["Offset, Value, @Comment"]+
|
||||
| ["Offset, Value, $Command"]+
|
||||
| ["Offset, Value, $Command, @Comment"]+
|
||||
```
|
||||
```
|
||||
|
||||
```text
|
||||
PatchFv FdFileDir FdFileName ["Offset, Value"]+
|
||||
| ["Offset, Value, @Comment"]+
|
||||
| ["Offset, Value, $Command"]+
|
||||
| ["Offset, Value, $Command, @Comment"]+
|
||||
```
|
||||
|
||||
# Description
|
||||
## Description
|
||||
|
||||
The **_PatchFv.py_** tool allows the developer to fix up FD images to follow the
|
||||
Intel FSP Architecture specification. It also makes the FD image relocatable.
|
||||
The tool is written in Python and uses Python 2.7 or later to run.
|
||||
Consider using the tool in a build script.
|
||||
|
||||
# FvBuildDir (Argument 1)
|
||||
## FvBuildDir (Argument 1)
|
||||
|
||||
This is the first argument that **_PatchFv.py_** requires. It is the build
|
||||
directory for all firmware volumes created during the FSP build. The path must
|
||||
be either an absolute path or a relevant path, relevant to the top level of the
|
||||
FSP tree.
|
||||
|
||||
#### Example usage:
|
||||
```
|
||||
### Example usage
|
||||
|
||||
```text
|
||||
Build\YouPlatformFspPkg\%BD_TARGET%_%VS_VERSION%%VS_X86%\FV
|
||||
```
|
||||
|
||||
The example used contains Windows batch script %VARIABLES%.
|
||||
|
||||
# FvFileBaseNames (Argument 2: Optional Part 1)
|
||||
## FvFileBaseNames (Argument 2: Optional Part 1)
|
||||
|
||||
The firmware volume file base names (**_FvFileBaseNames_**) are the independent
|
||||
FVs that are to be patched within the FD. (0 or more in the form
|
||||
**FvFileBaseNames:**) The colon **:** is used for delimiting the single
|
||||
argument and must be appended to the end of each (**_FvFileBaseNames_**).
|
||||
|
||||
#### Example usage:
|
||||
```
|
||||
### Example usage
|
||||
|
||||
```text
|
||||
STAGE1:STAGE2:MANIFEST:YOURPLATFORM
|
||||
```
|
||||
|
||||
In the example **STAGE1** is **STAGE1.Fv** in **YOURPLATFORM.fd**.
|
||||
|
||||
# FdFileNameToPatch (Argument 2: Mandatory Part 2)
|
||||
## FdFileNameToPatch (Argument 2: Mandatory Part 2)
|
||||
|
||||
Firmware device file name to patch (**_FdFileNameToPatch_**) is the base name of
|
||||
the FD file that is to be patched. (1 only, in the form **YOURPLATFORM**)
|
||||
|
||||
#### Example usage:
|
||||
```
|
||||
### Example usage
|
||||
|
||||
```text
|
||||
STAGE1:STAGE2:MANIFEST:YOURPLATFORM
|
||||
```
|
||||
|
||||
In the example **YOURPLATFORM** is from **_YOURPLATFORM.fd_**
|
||||
|
||||
# "Offset, Value[, Command][, Comment]" (Argument 3)
|
||||
## "Offset, Value\[, Command\]\[, Comment\]" (Argument 3)
|
||||
|
||||
The **_Offset_** can be a positive or negative number and represents where the
|
||||
**_Value_** to be patched is located within the FD. The **_Value_** is what
|
||||
will be written at the given **_Offset_** in the FD. Constants may be used for
|
||||
both offsets and values. Also, this argument handles expressions for both
|
||||
offsets and values using these operators:
|
||||
|
||||
```
|
||||
```text
|
||||
= - * & | ~ ( ) [ ] { } < >
|
||||
```
|
||||
|
||||
The entire argument includes the quote marks like in the example argument below:
|
||||
|
||||
```
|
||||
```text
|
||||
0xFFFFFFC0, SomeCore:__EntryPoint - [0x000000F0],@SomeCore Entry
|
||||
```
|
||||
|
||||
### Constants:
|
||||
### Constants
|
||||
|
||||
Hexadecimal (use **0x** as prefix) | Decimal
|
||||
|
||||
#### Examples:
|
||||
#### Examples
|
||||
|
||||
| **Positive Hex** | **Negative Hex** | **Positive Decimal** | **Negative Decimal** |
|
||||
| ---------------: | ---------------: | -------------------: | -------------------: |
|
||||
| 0x000000BC | 0xFFFFFFA2 | 188 | -94 |
|
||||
|
||||
```
|
||||
```text
|
||||
ModuleName:FunctionName | ModuleName:GlobalVariableName
|
||||
ModuleGuid:Offset
|
||||
```
|
||||
|
||||
### Operators:
|
||||
### Operators
|
||||
|
||||
```
|
||||
```text
|
||||
|
||||
+ Addition
|
||||
- Subtraction
|
||||
|
|
@ -109,35 +121,42 @@ ModuleGuid:Offset
|
|||
< > Convert absolute address <expr> into an image offset (expr & FSP_SIZE)
|
||||
|
||||
```
|
||||
|
||||
From version 0.60 tool allows to pass flash device file path as Argument 1 and
|
||||
flash device name as Argument 2 and rules for passing offset & value are same
|
||||
as explained in the previous sections.
|
||||
|
||||
#### Example usage:
|
||||
### Example usage
|
||||
|
||||
Argument 1
|
||||
```
|
||||
|
||||
```text
|
||||
YouPlatformFspBinPkg\
|
||||
```
|
||||
|
||||
Argument 2
|
||||
```
|
||||
|
||||
```text
|
||||
Fsp_Rebased_T
|
||||
```
|
||||
|
||||
### Special Commands:
|
||||
### Special Commands
|
||||
|
||||
Special commands must use the **$** symbol as a prefix to the command itself.
|
||||
There is only one command available at this time.
|
||||
|
||||
```
|
||||
```text
|
||||
$COPY Copy a binary block from source to destination.
|
||||
```
|
||||
|
||||
#### Example:
|
||||
#### Example
|
||||
|
||||
```
|
||||
```text
|
||||
0x94, [PlatformInit:__gPcd_BinPatch_FvRecOffset] + 0x94, [0x98], $COPY, @Sync up 2nd FSP Header
|
||||
```
|
||||
|
||||
### Comments:
|
||||
### Comments
|
||||
|
||||
Comments are allowed in the **Offset, Value [, Comment]** argument. Comments
|
||||
must use the **@** symbol as a prefix. The comment will output to the build
|
||||
window upon successful completion of patching along with the offset and value data.
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# SplitFspBin.py is a python script to support some operations on Intel FSP 1.x/2.x image.
|
||||
# SplitFspBin.py is a python script to support some operations on Intel FSP 1.x/2.x image
|
||||
|
||||
It supports:
|
||||
|
||||
|
|
@ -16,7 +16,9 @@ FSP 1.x image is not supported by split command.
|
|||
To split individual FSP component in Intel FSP 2.x image, the following
|
||||
command can be used:
|
||||
|
||||
**python SplitFspBin.py split [-h] -f FSPBINARY [-o OUTPUTDIR] [-n NAMETEMPLATE]**
|
||||
```text
|
||||
python SplitFspBin.py split [-h] -f FSPBINARY [-o OUTPUTDIR] [-n NAMETEMPLATE]
|
||||
```
|
||||
|
||||
For example:
|
||||
|
||||
|
|
@ -29,7 +31,9 @@ For example:
|
|||
To rebase one or multiple FSP components in Intel FSP 1.x/2.x image, the following
|
||||
command can be used:
|
||||
|
||||
**python SplitFspBin.py rebase [-h] -f FSPBINARY -c {t,m,s,o} [{t,m,s,o} ...] -b FSPBASE [FSPBASE ...] [-o OUTPUTDIR] [-n OUTPUTFILE]**
|
||||
```text
|
||||
python SplitFspBin.py rebase [-h] -f FSPBINARY -c {t,m,s,o} [{t,m,s,o} ...] -b FSPBASE [FSPBASE ...] [-o OUTPUTDIR] [-n OUTPUTFILE]
|
||||
```
|
||||
|
||||
For example:
|
||||
|
||||
|
|
@ -50,7 +54,9 @@ For example:
|
|||
|
||||
To generate Intel FSP 1.x/2.x C header file, the following command can be used:
|
||||
|
||||
**Python SplitFspBin.py genhdr [-h] -f FSPBINARY [-o OUTPUTDIR] [-n HFILENAME]**
|
||||
```text
|
||||
Python SplitFspBin.py genhdr [-h] -f FSPBINARY [-o OUTPUTDIR] [-n HFILENAME]
|
||||
```
|
||||
|
||||
For example:
|
||||
|
||||
|
|
@ -63,7 +69,9 @@ For example:
|
|||
|
||||
To display Intel FSP 1.x/2.x information headers, the following command can be used:
|
||||
|
||||
**Python SplitFspBin.py info [-h] -f FSPBINARY**
|
||||
```text
|
||||
Python SplitFspBin.py info [-h] -f FSPBINARY
|
||||
```
|
||||
|
||||
For example:
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue