Re: [PATCH 2/5] MdePkg HobLib: Add BuildFv3Hob API

[Laszlo Ersek <lersek@redhat.com>]

Hi Star,

On 10/04/17 16:21, Star Zeng wrote:
> Add BuildFv3Hob API in HobLib.h and implement the API
> in HobLib instances PeiHobLib, DxeHobLib and DxeCoreHobLib.
> 
> Cc: Liming Gao <liming.gao@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Star Zeng <star.zeng@intel.com>
> ---
>  MdePkg/Include/Library/HobLib.h       | 34 ++++++++++++++++++++--
>  MdePkg/Library/DxeCoreHobLib/HobLib.c | 35 ++++++++++++++++++++++-
>  MdePkg/Library/DxeHobLib/HobLib.c     | 32 +++++++++++++++++++++
>  MdePkg/Library/PeiHobLib/HobLib.c     | 54 ++++++++++++++++++++++++++++++++++-
>  4 files changed, 151 insertions(+), 4 deletions(-)
> 
> diff --git a/MdePkg/Include/Library/HobLib.h b/MdePkg/Include/Library/HobLib.h
> index fc48703826c5..6f1f7b3f5f20 100644
> --- a/MdePkg/Include/Library/HobLib.h
> +++ b/MdePkg/Include/Library/HobLib.h
> @@ -6,9 +6,9 @@
>    defined in the PI Specification.
>    A HOB is a Hand-Off Block, defined in the Framework architecture, that
>    allows the PEI phase to pass information to the DXE phase. HOBs are position
> -  independent and can be relocated easily to different memory memory locations.
> +  independent and can be relocated easily to different memory locations.
>  
> -Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.<BR>
> +Copyright (c) 2006 - 2017, Intel Corporation. All rights reserved.<BR>
>  This program and the accompanying materials
>  are licensed and made available under the terms and conditions of the BSD License
>  which accompanies this distribution.  The full text of the license may be found at
> @@ -343,6 +343,36 @@ BuildFv2Hob (
>    );
>  
>  /**
> +  Builds a EFI_HOB_TYPE_FV3 HOB.
> +
> +  This function builds a EFI_HOB_TYPE_FV3 HOB.
> +  It can only be invoked during PEI phase;
> +  for DXE phase, it will ASSERT() since PEI HOB is read-only for DXE phase.
> +
> +  If there is no additional space for HOB creation, then ASSERT().
> +  If the FvImage buffer is not at its required alignment, then ASSERT().
> +
> +  @param BaseAddress            The base address of the Firmware Volume.
> +  @param Length                 The size of the Firmware Volume in bytes.
> +  @param AuthenticationStatus   The authentication status.
> +  @param ExtractedFv            TRUE if the FV was extracted as a file within another firmware volume.
> +                                FALSE otherwise.
> +  @param FvName                 The name of the Firmware Volume. Valid only if IsExtractedFv is TRUE
> +  @param FileName               The name of the file. Valid only if IsExtractedFv is TRUE
> +
> +**/
> +VOID
> +EFIAPI
> +BuildFv3Hob (
> +  IN          EFI_PHYSICAL_ADDRESS        BaseAddress,
> +  IN          UINT64                      Length,
> +  IN          UINT32                      AuthenticationStatus,
> +  IN          BOOLEAN                     ExtractedFv,
> +  IN CONST    EFI_GUID                    *FvName, OPTIONAL
> +  IN CONST    EFI_GUID                    *FileName OPTIONAL
> +  );
> +
> +/**
>    Builds a Capsule Volume HOB.
>  
>    This function builds a Capsule Volume HOB.

do we need to copy the implementation(s) of this function to other
instances of HobLib?

edk2 has the following HobLib instances:

1 ArmVirtPkg/Library/ArmVirtDxeHobLib/ArmVirtDxeHobLib.inf
2 EmbeddedPkg/Library/PrePiHobLib/PrePiHobLib.inf
3 IntelFrameworkPkg/Library/PeiHobLibFramework/PeiHobLibFramework.inf
4 MdePkg/Library/DxeCoreHobLib/DxeCoreHobLib.inf
5 MdePkg/Library/DxeHobLib/DxeHobLib.inf
6 MdePkg/Library/PeiHobLib/PeiHobLib.inf

Instances #4 through #6 are extended in this patch; instance #3 is
extended in the next patch.

Instances #1 and #2 are not changed. Is that OK? (For example, some of
the ArmVirt platforms use instance #1 for all DXE and "later" modules.
Some other ArmVirt platforms use instance #2.)

Thanks,
Laszlo