-
Notifications
You must be signed in to change notification settings - Fork 345
Shell FAQ
Shell questions
Yes, it is possible. Please check the ULA for the EBC compiler. http://software.intel.com/sites/products/documentation/EULA/Intel_SW_Dev_Products_EULA.pdf I believe that has the specific details on driver/app support. There are no known technical issues with using EBC for Shell Applications or UEFI Applications. This is mainly a validation issue. Another issue is that the UEFI 2.3 Specification Section 2.6.2 item (19), states that the EBC interpreter is only required if a platform intends to support EBC drivers in containers for add in devices. This means that the EBC interpreter is optional and may not be available on all platforms. As a result, a Shell Application or UEFI Application that is compiled for EBC may not be able to run on all platforms. Intel® C Compiler for EFI Byte Code Product In-Depth
Yes, the shell can invoke nested instances of the shell and shell scripts can also invoke nested instances of other scripts
No, Shell scripts can exist anywhere within a Fat file system on any media. If they are not in the CWD then the path to a script can be specified.
Yes, can boot to shell and load with shell’s load command—can be a BDS option or others.
No, but it is in Preboot time and after Architecture protocols.
We provide a way from the enabling perspective by using a GUIDed section extraction and EDK II has tools to recognize a GUIDed section. This would enable Compression, Encryption and Signing. There are sources for tools in BaseTools CRC32 and LZMA compression. By looking a these examples a signing tool can also be used.
It is done at Build time, but it is possible to sign at boot time. For PEI and DXE signature checks it is possible as long as they are build with the appropriate architecture (E.g. 32 bit fore PEI and X64 for DXE)
The mechanism is in the PI Spec. The concept is that for every driver there is a dependency expression - UEFI Drivers implied dependence on architecture protocols and DXE Services. The PEI and DXE dispatcher is responsible for checking each driver's dependency and determines whether to dispatch/execute each driver as it finds it in the flash device. If the driver's dependency expression does not evaluate to TRUE it will set that driver aside and continue to the next driver in the flash device. It is possible some drivers may not get dispatched.
The code will access the flash as little as possible because of the performance. For example, in PEI there is use of Cache memory if a driver's dependency is not TRUE.
No eviction mode and set a side temp memory. PEI core will allocate memory.
There is another method called an a priori file. There can be one per Firmware volume. This will tell the dispatcher what order to dispatch list drivers in the order they need to dispatch them. This is a manual order. It does not need to be in any specific place in the FV. If it in the FV the dispatcher will find it.
You need to update the Nt32Pkg.dsc and the Nt32Pkg.fdf with the following:
Nt32Pkg.dsc
1) At the end in the [LibraryClasses.common.UEFI_APPLICATION] section add the following:
ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf FileHandleLib|ShellPkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf SortLib|ShellPkg/Library/UefiSortLib/UefiSortLib.inf ShellCEntryLib|ShellPkg/Library/UefiShellCEntryLib/UefiShellCEntryLib.inf PathLib|ShellPkg/Library/BasePathLib/BasePathLib.inf
2) At the end in the [PcdsFixedAtBuild] Section add the following:
3) At the end in the [Components.IA32] Section add the following:
ShellPkg/Application/Shell/Shell.inf { <LibraryClasses> NULL|ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2CommandsLib.inf NULL|ShellPkg/Library/UefiShellLevel1CommandsLib/UefiShellLevel1CommandsLib.inf NULL|ShellPkg/Library/UefiShellLevel3CommandsLib/UefiShellLevel3CommandsLib.inf FileHandleLib|ShellPkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf ShellCommandLib|ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.inf SortLib|ShellPkg/Library/UefiSortLib/UefiSortLib.inf HandleParsingLib|ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.inf ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf ShellCEntryLib|ShellPkg/Library/UefiShellCEntryLib/UefiShellCEntryLib.inf PathLib|ShellPkg/Library/BasePathLib/BasePathLib.inf !ifndef $(NO_SHELL_PROFILES) NULL|ShellPkg/Library/UefiShellDriver1CommandsLib/UefiShellDriver1CommandsLib.inf NULL|ShellPkg/Library/UefiShellInstall1CommandsLib/UefiShellInstall1CommandsLib.inf NULL|ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.inf NULL|ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1CommandsLib.inf !endif <PcdsFeatureFlag> gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE }
Nt32Pkg.fdf
4) Add the following at the end of the # DXE Phase modules in the Nt32Pkg.fdf file
INF ShellPkg/Application/Shell/Shell.inf
5) Comment out by adding "#" at the begining of the line the EFI EDK shell 1.0 in the FILE section of the Nt32Pkg.fdf file
#FILE APPLICATION = PCD(gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdShellFile) { # SECTION PE32 = EdkShellBinPkg/FullShell/Ia32/Shell_Full.efi # }
Home
Getting Started with EDK II
Build Instructions
EDK II Platforms
EDK II Documents
EDK II Release Planning
Reporting Issues
Reporting Security Issues
Community Information
Inclusive Language
Additional Projects & Tasks
Training
Community Support
Community Virtual Meetings
GHSA GitHub Security Advisories Proceess (Draft)