slimbootloader / slimbootloader Goto Github PK
View Code? Open in Web Editor NEWVisit http://slimbootloader.github.io for documentation
License: Other
Visit http://slimbootloader.github.io for documentation
License: Other
When there is no USB boot option in boot option list, and console input device is using USB keyboard, the keyboard does not get initialized thus does not work.
Hi,
I am interested in bootloader for ARM Cortex-M architecture. Are there plans to support it?
Reference (https://slimbootloader.github.io/how-tos/boot-windows.html) for Slimboot booting windows.
and SlimBootloaderIntegration.txt in (https://github.com/tianocore/edk2-staging/tree/UEFIPayload).
'MinnowBoard3' and 'Qemu' is supported.
Does Apollo Lake also support integration and how to integrate it?
A device entry for INT34D2
is missing under Platform/ApollolakeBoardPkg/AcpiTables/Dsdt/Platform.asl
. The ACPI entry is necessary for the intel_pmc_ipc
driver to load up automatically on Linux.
VerInfo.txt file is designed to provide customized version information for a given build. However, FspDebug and BldDebug should not be part of it since it can be always determined from current build flag.
On APL some of ACPI FADT parameter does not match SOC. For example, GPE0 block length should be 32 bytes rather than 16 bytes.
Following instructions at https://slimbootloader.github.io/how-tos/boot-acrn.html,
latest SBL could not boot to ACRN. Instead, it fell back to fast boot always.
TE image base is not calculated properly in PeCoffGetPreferredBase().
TE image has stripped header. When calculating the preferred base for TE image, the gap should be added back to match the actual TE image base.
When trying to patch CFGDATA using CfgDataTool on WHL, it failed with message below:
C:\Python27\python.exe W:\SlimBoot\SlimFork\BootloaderCorePkg\Tools\CfgDataTool.py replace -i d:\upx.bin d:\CfgData.bin -o d:\upx.bin
No CFGDATA region has been patched!
During Linux kernel boot, the following message will be printed out:
[Firmware Info]: PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] not reserved in ACPI motherboard resources
PCI: not using MMCONFIG
This prevents kernel from using MMCONFIG for PCI access.
Dear Slim boot loader team,
There is a compile issue when use Visual studio 2015, I tried to bring up an Apollo lake platform.
I found the root-cause in the HeciLib.h. (the change patch is in the attachment)
Sincerely,
Ethan Hsu
Putting iasimage.bin1234 at the root of the FAT file system, SBL OsLoader can still load it in the same way as iasimage.bin. It is expected to be failed due to mismatching file name.
When USB key board is enabled as console input, booting UP2 is halted if a user presses keyboard before USB keyboard is initialized. The assert message is the following:
====================Os Loader====================
ASSERT [OsLoader]
.../BootloaderCommonPkg/Library/XhciLib/XhciSched.c(2739): Index != TrsRing->TrbNumber
STAGE_PAYLOAD: System halted!
Pressing keyboard after USB keyboard is initialized (typically as soon as logo is shown) works as expect - which enters SBL shell.
Using the latest UEFI payload from EDKII repo, Windows boot will be stuck at the loading circle phase forever.
Issue:
The Bios.xml generated from StitchIfwi.py is referring to Stitch_PROV.bin.
But the SBL Output Stitch_Components.zip contain instead Stitch_FB.bin.
The topic has been already discussed with @mauricema in May.
When FwuImage.bin does not exist, the FWU flow will cause assertion.
Below is the log:
=================Read Capsule Image==============
BootMediumPciBase(0xE00A0000)
Init USB XHCI - Success
Enumerate Bus - Success
Found 8 USB devices on bus
Found mass storage on device 7
find boot partition
Partition type: MBR (1 logical partitions)
Find partion success
Find partition
Detected FAT on HwDev 0 Part 0
Open Capsule File 'FwuImage.bin' Status : Not Found
ASSERT_EFI_ERROR (Status = Invalid Parameter)
ASSERT [FirmwareUpdate] w:\slimboot\slimfork\BootloaderCommonPkg\Library\FullMemoryAllocationLib\FullMemoryAllocationLib.c(591): !EFI_ERROR (Status)
STAGE_PAYLOAD: System halted!
Applying QEMU FSP patch ...
Applying: Build QEMU FSP 2.0 binaries
error: gpg failed to sign the data
fatal: failed to write commit object
Traceback (most recent call last):
File "/mnt/storage/tmp/slimbootloader/BootloaderCorePkg/Tools/PrepareFspBin.py", line 193, in <module>
sys.exit(Main())
File "/mnt/storage/tmp/slimbootloader/BootloaderCorePkg/Tools/PrepareFspBin.py", line 185, in Main
BuildFspBins (qemu_repo_dir, sbl_dir, platform, target)
File "/mnt/storage/tmp/slimbootloader/BootloaderCorePkg/Tools/PrepareFspBin.py", line 141, in BuildFspBins
Fatal ('Failed to apply QEMU FSP patch !')
File "/mnt/storage/tmp/slimbootloader/BootloaderCorePkg/Tools/PrepareFspBin.py", line 21, in Fatal
raise Exception (msg)
Exception: Failed to apply QEMU FSP patch !
Traceback (most recent call last):
File "BuildLoader.py", line 1199, in <module>
main()
File "BuildLoader.py", line 1196, in main
args.func(args)
File "BuildLoader.py", line 1155, in cmd_build
Build(board).build()
File "BuildLoader.py", line 1016, in build
self.pre_build()
File "BuildLoader.py", line 901, in pre_build
raise Exception ('Failed to checkout FSP binaries !')
Exception: Failed to checkout FSP binaries !
Run "python PatchFv.py" will display:
Traceback (most recent call last):
File "W:\SlimBoot\SlimFork\BootloaderCorePkg\Tools\PatchFv.py", line 951, in
sys.exit(main())
File "W:\SlimBoot\SlimFork\BootloaderCorePkg\Tools\PatchFv.py", line 852, in main
Usage()
NameError: global name 'Usage' is not defined
On WHL with Boot Guard profile 0, if booting from SBL boot partition 1, the boot time is significantly longer than booting from boot partition 0.
With latest code, firmware update flow gets into infinite loop on APL platform.
Windows 10 installation will hard hang on Leafhill with UEFI payload.
If QEMU BoardConfig.py, if enable console as the debug output device as below:
self.DEBUG_OUTPUT_DEVICE_MASK = 0x00000007
All debug messages will be printed twice on serial port.
SBL initializes APL GFX OpRegion structure during boot. However, due to improper code execution order, the ACPI GNVS ASLB field was zeroed out during the GNVS initialization.
While booting Ubuntu 18.04 image following instructions at
https://slimbootloader.github.io/how-tos/boot-ubuntu.html, in some cases, the following assertion occurred.
====================Os Loader====================
Press any key within 2 second(s) to enter the command shell
Press any key within 1 second(s) to enter the command shell
Boot options (in HEX):
Idx|ImgType|DevType|DevNum|Flags|HwPart|FsType|SwPart|File/Lbaoffset
0| 0| USB | 0 | 0 | 0 | FAT | 0 | iasimage.bin
1| 0| SATA | 0 | 0 | 2 | FAT | 0 | iasimage.bin
2| 0| MMC | 0 | 0 | 0 | FAT | 0 | iasimage.bin
BootMediumPciBase(0x1700)
Getting boot image from SATA
Init AHCI Device E00B8000
AHCI port [2] has a [harddisk]
Try to find boot partition
Partition type: MBR (3 logical partitions)
Find partition success
BootSlot = 0x0
Init File system
Detected FAT on HwDev 2 Part 0
Open file 'iasimage.bin' failed, Status = Not Found
Try booting Linux from config file ...
Checking config.cfg
Load file config.cfg [size 0x40]: Success
Boot Menu:
Load file vmlinuz [size 8707832 bytes]: Success
Load file initrd [size 40216931 bytes]: Success
ASSERT [OsLoader] c:\workspace\opensource\slimbootloader\BootloaderCommonPkg\Library\FullMemoryAllocationLib\Pool.c(546): Tail->Signature == ((('p') | ('t' << 8)) | ((('a') | ('l' << 8)) << 16))
STAGE_PAYLOAD: System halted!
Hello,
At this moment it is important to have identical configuration between SBL and UEFI Payload for the PCIe base. As SBL knows the PCIe base why not add this to the information that is passed between SBL and UEFI Payload. There hardly isn't an effort involved and it prevent configuration issues.
Regards,
Wim
We have recently introduced Device Table concept for the OS Boot media devices. Code changes are needed in QEMU and APL in order to match this new concept.
SBL QEMU does not compile when set EXECUTE_IN_PLACE=1 in BoardConfig.py.
Per design, SBL allows to set PLT_SOURCE environment variable to search supported boards and silicons from different location. When we tried this way, the build failed because the FSP and Microcode downloading still points to the boards and silicon inside SBL rather than the new location.
Below is the failure trace
Traceback (most recent call last):
File "W:\SlimBoot\Test\SblOpen\BootloaderCorePkg\Tools\PrepareBuildComponentBin.py", line 334, in
sys.exit(Main())
File "W:\SlimBoot\Test\SblOpen\BootloaderCorePkg\Tools\PrepareBuildComponentBin.py", line 328, in Main
CopyFspBins (fsp_repo_dir, plt_dir, platform)
File "W:\SlimBoot\Test\SblOpen\BootloaderCorePkg\Tools\PrepareBuildComponentBin.py", line 118, in CopyFspBins
copy_list, fsp_tag = GetFspCopyList (platform)
File "W:\SlimBoot\Test\SblOpen\BootloaderCorePkg\Tools\PrepareBuildComponentBin.py", line 74, in GetFspCopyList
fd = open (fsp_inf, 'r')
IOError: [Errno 2] No such file or directory: 'Silicon/CoffeelakePkg/FspBin/FspBin.inf'
Traceback (most recent call last):
File "W:\SlimBoot\Test\SblOpen\BuildLoader.py", line 1238, in
main()
File "W:\SlimBoot\Test\SblOpen\BuildLoader.py", line 1235, in main
args.func(args)
File "W:\SlimBoot\Test\SblOpen\BuildLoader.py", line 1183, in cmd_build
Build(board).build()
File "W:\SlimBoot\Test\SblOpen\BuildLoader.py", line 1033, in build
self.pre_build()
File "W:\SlimBoot\Test\SblOpen\BuildLoader.py", line 917, in pre_build
raise Exception ('Failed to prepare build component binaries !')
Exception: Failed to prepare build component binaries !
Traceback (most recent call last):
File "W:\SlimBoot\Test\SblBuild.py", line 42, in
sys.exit(main())
File "W:\SlimBoot\Test\SblBuild.py", line 39, in main
raise RuntimeError("Execution failed: %s " % (build_cmd))
RuntimeError: Execution failed: ['python', 'W:\SlimBoot\Test\SblOpen\BuildLoader.py', 'build', 'cfl']
Stitching an IAS image of ~32MB including kernel and initrd, SBL failed to load it with hash verification errors. Smaller IAS image (~16MB) is just fine.
Boot process halts on STAGE_2.
Debug log as below:
...
ACPI Ret: Success
Loading Payload ID 0x49464555
Error: Unsupported
STAGE_2: System halted!
I attached the complete log file just in case.
And, on a side note, I reverted to the version before PR #198 and there wasn't an issue.
To reproduce it on APL, just enable USB KB by changing following in BoardConfig.py
self.CONSOLE_IN_DEVICE_MASK = 0x00000003
After it is done, if USB is not the 1st boot option, an assertion will be seen.
Current code does not update current firmware version in the FWST table. Read current version and update it in the Fwst ACPI table.
Fail to change the delta configuration file using the ConfigEditor.
Steps:
When SBL calls board notification ReadyToBoot and EndOfFirmware in Stage2, OsLoader will assert on APL platform.
Debug log as below:
...
Payload normal heap: 0x4000000 (0xE3A000 used)
Payload reserved heap: 0x900000 (0x0 used)
Payload stack: 0x10000 (0x1C00 used)
ASSERT [Stage2] w:\slimboot\slimfork\MdePkg\Library\BaseMemoryLibSse2\ZeroMemWrapper.c(47): Buffer != ((void *) 0)
STAGE_2: System halted!
Even after SBL initialized framebuffer correctly, the Linux kernel still failed to show console on fbdev. The screen is blank.
Open WHL/CFL CfgDataDef.dsc and click memory settings, then it shows WARNING.
WARNING: Value "8388608" is an invalid option for "TsegSize" !
Update TsegSize from 0x00800000 to 0x01000000 !
EfiUtilityMsgs.c:484:9: error: ‘strncat’ output may be truncated copying between 0 and 511 bytes from a string of length 511 [-Werror=stringop-truncation]
strncat (Line, Line2, MAX_LINE_LEN - strlen (Line) - 1);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
EfiUtilityMsgs.c:469:9: error: ‘strncat’ output may be truncated copying between 0 and 511 bytes from a string of length 511 [-Werror=stringop-truncation]
strncat (Line, Line2, MAX_LINE_LEN - strlen (Line) - 1);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
EfiUtilityMsgs.c:511:5: error: ‘strncat’ output may be truncated copying between 0 and 511 bytes from a string of length 511 [-Werror=stringop-truncation]
strncat (Line, Line2, MAX_LINE_LEN - strlen (Line) - 1);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I'm trying to write (note: since i don’t have a devboard yet, i test it in QEMU) an UEFI driver that writes/reads values in NVRAM storage, but got a problem:
Variable driver will work at emulated non-volatile variable mode!
Apparently, NVRAM is emulated by UEFI payload in RAM - and it seems to be cleaned after UEFI starts OS bootloader. Is this a QEMU-specific problem or Slimbootloader doesn't support a NVRAM storage on SPI flash/img file?
When trying to enable USB keyboard console for QEMU with Slim Bootloader, sometimes it works. But it is not reliable, and lots of error message will be printed on console in QEMU.
For example:
XhcPeiCheckUrbResult: Transfer Default Error Occur! Completecode = 0x13!
XhcPeiSetTrDequeuePointer: Set TR Dequeue Pointer Failed, Status = Device Error
XhcPeiDequeueTrbFromEndpoint: Set Dequeue Pointer Failed, Status = Device Error
XhcPeiBulkTransfer: XhcPeiDequeueTrbFromEndpoint failed
Using latest code, when booting from 2nd boot option on APL, the following assertion was seen:
ASSERT [OsLoader] w:\slimboot\slimfork\MdePkg\Library\BaseLib\LinkedList.c(267): InternalBaseLibIsListValid (ListHead)
StitchIfwi '-q' argument does not take effect. SPI QAUD mode should be enabled with '-q'. But the actually stitched image still uses SPI SINGLE mode.
For fast boot, after 119 boots, the memory training process repeats. This causes an unacceptably long boot time.
The FirmwareDevice class method ParseFsp(self) (IntelFsp2Pkg/Tools/SplitFspBin.py), called when building slim bootloader for Qemu fails to parse the built QemuFsp Fd file correctly.
The Fd (built using "python BuildLoader.py build qemu") correctly contains 3 EFI Fvs, one each to eventually be "split" into FSP_S.bin, FSP_M.bin, and FSP_T.bin. The FSP Information Headers all appear to be in the correct places within the Fd (e.g. Silicon/QemuSocPkg/FspBin/FspRel.bin) "equivalent to" each EFI Fv (S at 0x00, M at 0x15000, T at 0x37000).
Subsequent processing by postbuild in BuildLoader.py expects those 3 FSPImage files, however there are only 2 FSPImage files created by the split, with the M FSPImage improperly containing the T Fv in addition to its' M Fv.
The first indication of trouble is an alignment warning from the BPDG tool:
`VPD input data file: = Build/QemuFspPkg/RELEASE_GCC5/FV/34686CA3-34F9-4901-B82A-BA630F0714C6.txt
VPD output map file: = Build/QemuFspPkg/RELEASE_GCC5/FV/34686CA3-34F9-4901-B82A-BA630F0714C6.map
VPD output binary file: = Build/QemuFspPkg/RELEASE_GCC5/FV/34686CA3-34F9-4901-B82A-BA630F0714C6.bin
BPDG...
Build/QemuFspPkg/RELEASE_GCC5/FV/34686CA3-34F9-4901-B82A-BA630F0714C6.txt(...): warning: The offset value of PCD gQemuFspPkgTokenSpaceGuid.Reserved is not 8-byte aligned!
BPDG...
Build/QemuFspPkg/RELEASE_GCC5/FV/34686CA3-34F9-4901-B82A-BA630F0714C6.txt(...): warning: The offset value of PCD gQemuFspPkgTokenSpaceGuid.Reserved is not 8-byte aligned!
BPDG...
Build/QemuFspPkg/RELEASE_GCC5/FV/34686CA3-34F9-4901-B82A-BA630F0714C6.txt(...): warning: The offset value of PCD gQemuFspPkgTokenSpaceGuid.Reserved1 is not 8-byte aligned!
I am not sure if I need to investigate this warning "upstream" or if the BPDG tool was trying to tell me it "fixed" the alignment problem with the upstream inputs and it is OK to move forward.
Using latest SBL and lastest UEFI payload from open source, Windows boot stuck on spinning circle screen forever.
The build process (via BuildLoader.py) will spawn subprocesses to sign and assemble files. To determine the location of rsa
and nasm
, BuildLoader.py will search for OPENSSL_PATH
and NASM_PREFIX
environment variables, respectively. If not set, BuildLoader.py will initialize these environment variabels with assumed default locations. However, if openssl
or nasm
executables cannot be found, an exception will be generated when trying to spawn the associated subprocess, a traceback will be printed, and the build will halt.
Example traceback from Python when openssl
cannot be found:
Traceback (most recent call last):
File "BuildLoader.py", line 1259, in <module>
main()
File "BuildLoader.py", line 1256, in main
args.func(args)
File "BuildLoader.py", line 1204, in cmd_build
Build(board).build()
File "BuildLoader.py", line 1058, in build
self.pre_build()
File "BuildLoader.py", line 1039, in pre_build
gen_pub_key (cfg_priv_key, cfg_pub_key_file)
File "E:\Projects\tmp\slimbootloader\BootloaderCorePkg\Tools\BuildUtility.py", line 846, in gen_pub_key
x = subprocess.call([cmdline, 'rsa', '-pubout', '-text', '-out', '%s' % pub_key, '-noout', '-in', '%s' % priv_key])
File "C:\Python27\lib\subprocess.py", line 168, in call
return Popen(*popenargs, **kwargs).wait()
File "C:\Python27\lib\subprocess.py", line 390, in __init__
errread, errwrite)
File "C:\Python27\lib\subprocess.py", line 640, in _execute_child
startupinfo)
WindowsError: [Error 2] The system cannot find the file specified
Traceback when nasm
cannot be found:
Traceback (most recent call last):
File "Build.py", line 53, in <module>
ret = RunCommand(commandLine)
File "Build.py", line 21, in RunCommand
return subprocess.call(commandLine)
File "C:\Python27\lib\subprocess.py", line 168, in call
return Popen(*popenargs, **kwargs).wait()
File "C:\Python27\lib\subprocess.py", line 390, in __init__
errread, errwrite)
File "C:\Python27\lib\subprocess.py", line 640, in _execute_child
startupinfo)
WindowsError: [Error 2] The system cannot find the file specified
Traceback (most recent call last):
File "BuildLoader.py", line 1259, in <module>
main()
File "BuildLoader.py", line 1256, in main
args.func(args)
File "BuildLoader.py", line 1204, in cmd_build
Build(board).build()
File "BuildLoader.py", line 1058, in build
self.pre_build()
File "BuildLoader.py", line 1051, in pre_build
if x: raise Exception ('Failed to build reset vector !')
These tracebacks can be confusing for people who are trying to download and build the code base without following the instructions provided in the documentation. Instead, Slim Bootloader should search for the associated executables and report a friendlier error message if they cannot be found possibly instructing the user to install the required tool.
Open APL CfgDataDef.dsc using ConfigEditor.py, it shows the following items have invalid default values.
WARNING: Value "5" is an invalid option for "DevInstance" !
WARNING: Value "255" is an invalid option for "PcieRpPower2_Community" !
WARNING: Value "255" is an invalid option for "PcieRpPower3_Community" !
WARNING: Value "255" is an invalid option for "PcieRpPower4_Community" !
WARNING: Value "255" is an invalid option for "PcieRpPower5_Community" !
WARNING: Value "255" is an invalid option for "PcieRpReset4_Community" !
WARNING: Value "255" is an invalid option for "PcieRpReset5_Community" !
WARNING: Value "5" is an invalid option for "GPIO_24_Half1_AltFunc" !
WARNING: Value "5" is an invalid option for "GPIO_26_Half1_AltFunc" !
WARNING: Value "5" is an invalid option for "GPIO_31_Half1_AltFunc" !
WARNING: Value "5" is an invalid option for "GPIO_32_Half1_AltFunc" !
WARNING: Value "5" is an invalid option for "GPIO_33_Half1_AltFunc" !
SBL suggests to use VS2015. But when there are multi versions of VS (including VS2015) installed on the Windows host system, BuildLoader.py often sets up old VS version for the toolchain variable which might cause build errors all the time.
During development, we found the build did not throw error when duplicated names exist in the CFGDATA database. It makes it difficult to debug later on. We should let the build script check this and report error.
NHLT table is not integrated in ACPI table by SBL. NHLT table has audio device specific informatinon, which is needed for audio device to work on APL-UP2.
Could SBL intergrate NHLT table on APL-UP2 to support audio?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.