Add a new entry in CfgData_BootOption.yaml to boot from memory. The boot
device must be 7 (MEMORY), and the address of the container boot image
(CONTAINER_BOOT_SIGNATURE) can be placed at an address specified by
LBA format (i.e., use HEX prefix. EX: #0x12345678).
Example entry of CfgData_BootOption.yaml:
!expand { BOOT_OPTION_TMPL : [ 0 , 0, 0, 7, 0 , 0 , 0xFF , 1 , '#0x47A31000'] }
If the address is not predefined then it can be updated in run time from
SBL shell boot option table.
Validated by loading a container image to the memory by using 'fs load'
command in SBL shell and update the load image address in boot option table.
Signed-off-by: Biswas Arghya <arghya.biswas@intel.com>
In the Ubuntu ISO image, it has 0xF8 partition entries.
The partition library could not work as expected since
it expects the partition entries are no more than 128.
Potentially it could have more partition entries, so just
remove the check.
Signed-off-by: Guo Dong <guo.dong@intel.com>
Signed-off-by: Guo Dong <guo.dong@intel.com>
Convert the line endings stored for all text files in the repository to
LF. The majority previously used DOS-style CRLF line endings. Add a
.gitattributes file to enforce this and treat certain extensions as
never being text files.
Update PatchCheck.py to insist on LF line endings rather than CRLF.
However, its other checks fail on this commit due to lots of
pre-existing complaints that it only notices because the line endings
have changed.
Silicon/QemuSocPkg/FspBin/Patches/0001-Build-QEMU-FSP-2.0-binaries.patch
needs to be treated as binary since it contains a mixture of line
endings.
This change has implications depending on the client platform you are
using the repository from:
* Windows
The usual configuration for Git on Windows means that text files will
be checked out to the work tree with DOS-style CRLF line endings. If
that's not the case then you can configure Git to do so for the entire
machine with:
git config --global core.autocrlf true
or for just the repository with:
git config core.autocrlf true
Line endings will be normalised to LF when they are committed to the
repository. If you commit a text file with only LF line endings then it
will be converted to CRLF line endings in your work tree.
* Linux, MacOS and other Unices
The usual configuration for Git on such platforms is to check files out
of the repository with LF line endings. This is probably the right thing
for you. In the unlikely even that you are using Git on Unix but editing
or compiling on Windows for some reason then you may need to tweak your
configuration to force the use of CRLF line endings as described above.
* General
For more information see
https://docs.github.com/en/get-started/getting-started-with-git/configuring-git-to-handle-line-endings .
Fixes: https://github.com/slimbootloader/slimbootloader/issues/1400
Signed-off-by: Mike Crowe <mac@mcrowe.com>
Current SBL only looks into the primary GPT during partition detection.
If it is not valid, then MRB partition will be checked next. In some
case of the Ubuntu USB disk created, only the 2nd GPT is valid. SBL
should check both primary and secondary GPT table before moving to MBR
check. This patch added this fix.
Signed-off-by: Maurice Ma <maurice.ma@intel.com>
This will fully support PatchCheck.py.
- Remove all trailing whitespace
- Convert LF to CRLF by default
- Update EFI_D_* to DEBUG_*
- Re-enable CRLF check in PatchCheck.py
Signed-off-by: Aiden Park <aiden.park@intel.com>
This 'fs' shell command can be used for basic file system check.
Usage: fs init [device no.] [hwpart no.] [swpart no.]
fs close
fs info
fs ls [dir or file path]
- 'device no.' is from Platform Device Table.
- all 0s by default if 'fs init' has no parameters
- root dir by default if 'fs ls' has no dir or file path
Signed-off-by: Aiden Park <aiden.park@intel.com>
The FindPartitions() allocates memory for PART_BLOCK_DEVICE instance.
This allocated memory needs to be de-allocated if no more necessary
to avoid memory leak.
TBD: Current partition info needs to be cleared before going to next
boot option.
Signed-off-by: Aiden Park <aiden.park@intel.com>
