Add implementation of ReallocatePool which is defined in the
MemoryAllocationLib header file to allow components to not
need special handling for PrePi module types.
Signed-off-by: Jeff Brasen <jbrasen@nvidia.com>
AndroidBootImgLib allows for platforms to append to kernel command
line but does not allow for the overall kernel command line to go
beyond the limit set by the image header. Address this limitation
by adding a pcd where platform can tell how many extra characters
they expect on their platform in addition to what the image header
specifies.
Signed-off-by: Ashish Singhal <ashishsingha@nvidia.com>
Reviewed-by: Abner Chang <abner.chang@amd.com>
Curently, AndroidBootImgLib expects input kernel command line
to never exceed 256 unicode characters where the image header
allows for 512 ascii characters. If image header allows 512
ascii characters, similar number of unicode characters should be
allowed at the minimum.
Signed-off-by: Ashish Singhal <ashishsingha@nvidia.com>
Reviewed-by: Abner Chang <abner.chang@amd.com>
The RealTimeClockLib class header in edk2 mistakenly declares a function
called LibRtcVirtualNotifyEvent(). No component ever calls this function
crossing module boundaries; all RealTimeClockLib instances in edk2 and
edk2-platforms are supposed to register (and do register) their
SetVirtualAddressMap() notification functions.
In particular, VirtualRealTimeClockLib *itself* doesn't even use
LibRtcVirtualNotifyEvent() -- the function is defined with an empty body,
clearly in an understandable, but misguided, attempt, to conform to the
(bogus) library interface. Remove the function.
Build-tested only (with "RiscVVirtQemu.dsc").
Cc: Abner Chang <abner.chang@amd.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Daniel Schaefer <git@danielschaefer.me>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4564
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20231012091057.108728-5-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
The RealTimeClockLib class header in edk2 mistakenly declares a function
called LibRtcVirtualNotifyEvent(). No component ever calls this function
crossing module boundaries; all RealTimeClockLib instances in edk2 and
edk2-platforms are supposed to register (and do register) their
SetVirtualAddressMap() notification functions.
In particular, TemplateRealTimeClockLib *itself* doesn't even use
LibRtcVirtualNotifyEvent() -- the function is defined with an empty body,
clearly in an understandable, but misguided, attempt, to conform to the
(bogus) library interface. Remove the function.
Build-tested only (with "EmbeddedPkg.dsc").
Cc: Abner Chang <abner.chang@amd.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Daniel Schaefer <git@danielschaefer.me>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4564
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20231012091057.108728-4-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
__FUNCTION__ is a pre-standard extension that gcc and Visual C++ among
others support, while __func__ was standardized in C99.
Since it's more standard, replace __FUNCTION__ with __func__ throughout
EmbeddedPkg.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Abner Chang <abner.chang@amd.com>
In commit c673216f53 a new input parameter is added in FfsFindSectionData.
That change breaks the build of ArmVirtPkg. In this patch
FfsFindSectionData is added back. It calls FfsFindSectionDataWithHook with
a NULL hook.
Signed-off-by: Min Xu <min.m.xu@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Commit c673216f53 introduces FFS_CHECK_SECTION_HOOK and add it as the
second input parameter in FfsFindSectionData. This change breaks the build
of ArmVirtPkg. To fix this issue, the new version of FfsFindSectionData
is renamed as FfsFindSectionDataWithHook in this patch. In the following
patch the original FfsFindSectionData will be added back.
FfsFindSectionData is renamed as FfsFindSectionDataWithHook. Accordingly
PeilessStartupLib in OvmfPkg should be updated as well. To prevent the
build from being broken, the changes in OvmfPkg are in this patch.
Signed-off-by: Min Xu <min.m.xu@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Update check for enough space to occur prior to alignment offset.
This prevents cases where EfiFreeMemoryTop < EfiFreeMemoryBottom.
Signed-off-by: Jeff Brasen <jbrasen@nvidia.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
The value of gTimeOut is from PcdGdbMaxPacketRetryCount, and this
PCD is UINT32. So change the declaratrion of gTimeOut to UINT32
to fix compile warning.
Signed-off-by: Wenyi Xie <xiewenyi2@huawei.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Add support under a pcd feature for using the new interface to pass
initrd to the linux kernel instead of via device tree.
This feature is also enabled if ACPI tables are present, and will skip
locating and installation of device tree.
Signed-off-by: Jeff Brasen <jbrasen@nvidia.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
Currently if mAndroidBootImg->UpdateDtb is not supported on the platform
the device tree updates of the initrd are not made.
Signed-off-by: Jeff Brasen <jbrasen@nvidia.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
Update AndroidBootImgBoot to use a single return point
Make sure Kernel args are freed and Image is unloaded.
Signed-off-by: Jeff Brasen <jbrasen@nvidia.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
Remove duplicate libfdt.h include statement in AndroidBootImgLib
Signed-off-by: Jeff Brasen <jbrasen@nvidia.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
Map->Operation is used to select whether a DMA region that
is being bounced has the source buffer copied to it. Except
Map->Operation isn't yet set, so the behavior is somewhat
random. Instead use the passed in Operation parameter.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
This patch fixes two issues below:
1. SCT SetTime_Func failures.
- https://github.com/pftf/RPi4/issues/164
2. Using shell time and date commands to set time can't work.
The problem is that gRT->SetTime always returns EFI_INVALID_PARAMETER
error status.
The root cause is that LibSetTime() sets RtcEpochSeconds variable with
inconsistent attributes. One is without EFI_VARIABLE_NON_VOLATILE,
the other one is with EFI_VARIABLE_NON_VOLATILE. That caused that the
variable driver returns EFI_INVALID_PARAMETER. Per UEFI spec, if a
preexisting variable is rewritten with different attributes,
SetVariable() shall not modify the variable and shall return
EFI_INVALID_PARAMETER.
Therefore, the solution is to add EFI_VARIABLE_NON_VOLATILE attribute
to the first EfiSetVariable() call to make two calls consistent.
By the way, this patch also fix a minor issue with a debug message.
Signed-off-by: Sunny Wang <sunny.wang@arm.com>
Reviewed-by: Pete Batard <pete@akeo.ie>
Tested-by: Pete Batard <pete@akeo.ie>
The message "LibGetTime: RtcEpochSeconds non volatile variable was not
found - Using compilation time epoch." can be printed a very large
number of times, causing log files to become excessively large. This is
because the RtcEpochSeconds variable only gets set if LibSetTime is
called, for example by running 'time 12:00' in the UEFI Shell.
Avoid this by setting RtcEpochSeconds to BUILD_EPOCH (EpochSeconds)
after printing the message. It's set to a volatile variable so the
message will be displayed on future boots and not hidden.
Commit 44ae214591 reduced the verbosity of
the message to DEBUG_VERBOSE. Revert it back to DEBUG_INFO so it's more
prominent now that it doesn't get printed so frequently.
Signed-off-by: Rebecca Cran <rebecca@nuviainc.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
The DEBUG message for using compilation time epoch is appearing very
frequently on DEBUG firmware builds, for example during UEFI SCT runs.
Reduce verbosity to avoid the annoying repetitive message.
Signed-off-by: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
This adds two functions IsValidTimeZone() and IsValidDaylight() to check
the time zone and daylight value from EFI time. These functions are
retrieved from the RealTimeClockRuntimeDxe module as they reduce
duplicated code in RTC modules.
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Signed-off-by: Nhi Pham <nhi@os.amperecomputing.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
EfiTimeToEpoch() calls EfiGetEpochDays() internally, which (reasonably)
returns a UINTN. But then EfiTimeToEpoch() truncates the EfiGetEpochDays()
retval to UINT32 for no good reason, effectively restricting Time->Year
under 2106.
This truncation was pointed out with a valid warning (= build error) by
VS2019.
Allow EfiTimeToEpoch() to return / propagate a UINTN value.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20201221113657.6779-3-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Addresses BZ https://bugzilla.tianocore.org/show_bug.cgi?id=2380 where
explicit casts are required for 64 to 32 bit assignment.
We can apply a straight cast for Time->Nanosecond since we already checked
for overflow.
On the other hand, we may have a frequency that is greater than UINT32_MAX
for Capabilities->Resolution. But using the frequency for the resolution
is the wrong approach anyway, since we can't actually vouch for the actual
resolution of the virtual library. Instead, play it safe by defaulting to
1 Hz, which is what a standard PC-AT CMOS RTC device would use.
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
The bounce buffering code in NonCoherentDmaLib copies data into the
bounce buffer using CopyMem(), but passes Map->HostAddress as the
source of the copy before it has been assigned its correct value.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
Reviewed-by: Andrei Warkentin <awarkentin@vmware.com>
Implement support for driving peripherals with limited DMA ranges to
NonCoherentDmaLib, by adding a device address limit, and taking it,
along with the device offset, into account when allocating or mapping
DMA buffers.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Pete Batard <pete@akeo.ie>
Acked-by: Philippe Mathieu-Daude <philmd@redhat.com>
Acked-by: Leif Lindholm <leif.lindholm@linaro.org>
While looking at encoding and line ending errors, I found this file
in fact simply points to a sourceforge page which no longer exists.
Since there is nothing more to say than "this is an import of
libfdt", let's just delete it.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
For the LoadImage() boot service, with EFI_SECURITY_VIOLATION retval,
the Image was loaded and an ImageHandle was created with a valid
EFI_LOADED_IMAGE_PROTOCOL, but the image can not be started right now.
This follows UEFI Spec.
But if the caller of LoadImage() doesn't have the option to defer
the execution of an image, we can not treat EFI_SECURITY_VIOLATION
like any other LoadImage() error, we should unload image for the
EFI_SECURITY_VIOLATION to avoid resource leak.
This patch is to do error handling for EFI_SECURITY_VIOLATION explicitly
for the callers in EmbeddedPkg which don't have the policy to defer the
execution of the image.
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Philippe Mathieu-Daude <philmd@redhat.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1992
Signed-off-by: Dandan Bi <dandan.bi@intel.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
The BaseTools build feature introduced for TianoCore#1804 / in commit
1fa6699e6c ("BaseTools: Add a checking for Sources section in INF file",
2019-06-10) logs some (non-fatal) warnings about unlisted internal header
files. List those files explicitly.
Note: header files are added in lexicographical order only if the
underlying INF file already keeps the [Sources] and [LibraryClasses]
sections in lexicographical order. Otherwise, header files are added in
rough "logical" order.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
The status code reporting functionality in PrePiLib is never invoked
so let's just remove it.
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Latest change allowed to add dependency on NvVarStoreFormattedLib
for the DXE_DRIVER modules. Although effectively it is hooked
using the 'NULL' class, extend the LIBRARY_CLASS with according
type for consistency sake.
Signed-off-by: Marcin Wojtas <mw@semihalf.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Some modules (such as FaultTolerantWriteDxe) use the FlashNvStorage
PCDs (PcdFlashNvStorageFtw*). In case the flash contents are not
mapped in memory, the module loading order of the FVB driver
may become important.
To handle above, this patch allows to hook the dependency of
desired DXE_DRIVER type module in the .DSC file via
NvVarStoreFormattedLib NULL resolution.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marcin Wojtas <mw@semihalf.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
