On Jul 21, 2014, at 10:48 PM, Varad Gautam <[email protected]> wrote:
> Hi, I'm working on the BeagleBoneBlack port for UEFI. I am using the
> PrePi as the entry point, and need some help with the call to
> DecompressFirstFv().
>
> I figure that FwVol.c:FfsAnyFvFindFirstFile() loops through each FV it
> gets from the FV HOB and searches for
> `EFI_FV_FILETYPE_FIRMWARE_VOLUME_IMAGE`, but I don't understand the
> difference between searching for 'Next Volume' and 'Next File of the
> type FIRMWARE_VOLUME_IMAGE'.
>
> Are we assuming a definite layout of the FD for this to work?
>
The lingo is:
FD - This is the FLASH Device and can include a set of FVs and other data
regions.
FV - A simple Flash File system that contains files, but no directories.
File - A file has a name (GUID), a well known type, and consists of a
collection of sections. A section can encapsulate other sections. Section
extraction is the process used to unwrap the encapsulate sections.
So the Next Volume is looking for another FV.
One of the supported file types in an FV is
EFI_FV_FILETYPE_FIRMWARE_VOLUME_IMAGE. So an FV can contain a file that is an
FV. It is not uncommon for an FV to contain a compressed FV as a file. The code
to turn on memory and do the decompression is in the outer FV and the FV in the
file is decompressed and copied into memory.
This is just following the FV architecture defined in the PI 1.3 spec
(http://www.uefi.org/specsandtesttools)
https://svn.code.sf.net/p/edk2/code/trunk/edk2/MdePkg/Include/Pi/PiFirmwareFile.h
///
/// File Types Definitions
///
#define EFI_FV_FILETYPE_ALL 0x00
#define EFI_FV_FILETYPE_RAW 0x01
#define EFI_FV_FILETYPE_FREEFORM 0x02
#define EFI_FV_FILETYPE_SECURITY_CORE 0x03
#define EFI_FV_FILETYPE_PEI_CORE 0x04
#define EFI_FV_FILETYPE_DXE_CORE 0x05
#define EFI_FV_FILETYPE_PEIM 0x06
#define EFI_FV_FILETYPE_DRIVER 0x07
#define EFI_FV_FILETYPE_COMBINED_PEIM_DRIVER 0x08
#define EFI_FV_FILETYPE_APPLICATION 0x09
#define EFI_FV_FILETYPE_SMM 0x0A
#define EFI_FV_FILETYPE_FIRMWARE_VOLUME_IMAGE 0x0B
#define EFI_FV_FILETYPE_COMBINED_SMM_DXE 0x0C
#define EFI_FV_FILETYPE_SMM_CORE 0x0D
#define EFI_FV_FILETYPE_OEM_MIN 0xc0
#define EFI_FV_FILETYPE_OEM_MAX 0xdf
#define EFI_FV_FILETYPE_DEBUG_MIN 0xe0
#define EFI_FV_FILETYPE_DEBUG_MAX 0xef
#define EFI_FV_FILETYPE_FFS_MIN 0xf0
#define EFI_FV_FILETYPE_FFS_MAX 0xff
#define EFI_FV_FILETYPE_FFS_PAD 0xf0
Thanks,
Andrew Fish
PS Another example of this logic is the DXE Dispatcher that can load
EFI_FV_FILETYPE_FIRMWARE_VOLUME_IMAGE from an FV that it discovers. The file
can even have a Depex, so the FV is not dispatched until the dependencies are
met.
https://svn.code.sf.net/p/edk2/code/trunk/edk2/MdeModulePkg/Core/Dxe/Dispatcher/Dispatcher.c
search for EFI_SECTION_DXE_DEPEX.
> Thanks,
> Varad
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> edk2-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/edk2-devel
