The Raspberry Pi platform with Secure Boot enabled currently fails to build
with error:

  Module type [DXE_RUNTIME_DRIVER] is not supported by library instance
  [/home/appveyor/projects/rpi4/edk2/MdePkg/Library/DxeRngLib/DxeRngLib.inf]

Add the missing class to fix this issue.

Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>
Reviewed-by: Andrei Warkentin <awarkentin@vmware.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>

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>

These can be used, for instance, to automate the population of an SMBIOS
Type 0 BIOS Release Date when building a UEFI firmware (which is how we
plan to use these macros for the Raspberry Pi platform).

These macros should work for any compiler that follows ISO/IEC 9899, but
we add a check for the compiler we have tested to be on the safe side.

Note that we decided against adding a #error or #warn for compilers that
haven't been validated, as we don't want to introduce breakage for people
who may already be using the header with something else than gcc, MSVC or
Clang. Instead, we expect those to send a patch that adds their compiler
to the list, once they have tested the macros there.

Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>

ACPI 6.3 added a 16-bit SPE overflow Interrupt field, replacing
2 of the 3 reserved bytes that are defined at the end of the
GICC structure for 6.0.

Add a new macro to initialise the new field.

Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>

As per the Microsoft Debug Port Table 2 (DBG2) documentation, that
can be found online, we are missing 2 serial interface types for
Arm DCC and Bcm2835 (the latter being used with the Raspberry Pi).

These same types are present in DebugPort2Table.h so add them to
SerialPortConsoleRedirectionTable.h too.

Note that we followed the same idiosyncrasies as DebugPort2Table
for naming these new macros.

Signed-off-by: Pete Batard <pete@akeo.ie>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Liming Gao <liming.gao@intel.com>

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2266

Similar to what we now do for OVMF, we need to consider the possibility
that PlatformBootManagerWaitCallback () may be called with a
PcdPlatformBootTimeOut that was set to zero, in which case the call should
simply return.

We also change the initial timeout variable name to make the code explicit.

Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Message-Id: <20191014150311.16740-3-pete@akeo.ie>

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2266

Independently of how we decide to address other aspects of the regression
introduced with commit 2de1f61, it doesn't
make much sense to call for a progress update if PcdPlatformBootTimeOut is
zero.

PcdPlatformBootTimeOut 0, which is the cause of the bug (division by zero)
should be considered to indicate that a platform is not interested in
displaying a progress report, so we alter PlatformBootManagerWaitCallback
to behave that way.

We also change one variable name to make the code more explicit.

Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Message-Id: <20191014150311.16740-2-pete@akeo.ie>

The existing loop is set to call PlatformBootManagerWaitCallback every
second except the last one. We believe this is a mistake as it prevents
the called code from performing timeout expiration tasks such as, for
instance, ensuring that the last segment of a progress bar is displayed
before continuing (which is a current issue for the RPi3 platform).

Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>

The header files are used but missing in INF, which causes
warning message when building them.

Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>

The new sources are a copy of the RVCT version.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>

The new source is a port of the RVCT version.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>

We could have reused memmove.asm for ARM, but we would still need to add
an implemention for ARM64, so we use the same source for both archs.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>

None of the .c/.h in Arm/ are used any more => remove them.
Also merge the CC flags for MSFT ARM and ARM64, since these are the
only archs we support for this package.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>

LibGetTime():
- Two variables were used for the epoch, where only one should have been [*].
- Also harmonize variable name to match the one used in LibSetTime.
LibSetTime():
- Address possible underflows if time is set to start of epoch.
- Ensure that time being read does actually match time that was manually
  set (plus the time elapsed since), by subtracting number of seconds
  since reset.

[*] This fixes a build breakage, since one of these variables was set but
    never used, triggering a compiler diagnostic at some optimization levels.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>

This is designed to be used on platforms where a a real RTC is not
available and relies on an RtcEpochSeconds variable having been set or,
if that is not the case, falls back to using the epoch embedded at
compilation time.

Note that, in order to keep things simple for the setting of the
compilation time variable, only GCC environments with UNIX-like shells
and where a 'date' command is available are meant to be supported for
now.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>

This option, which is used in VS2015 and earlier toolchains, was missing
for VS2017. Applying it greatly reduces the size of generated binaries.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Liming Gao <liming.gao@intel.com>

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Liming Gao <liming.gao@intel.com>

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Liming Gao <liming.gao@intel.com>

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Liming Gao <liming.gao@intel.com>

Build options for ARM64 are the same as for ARM, except for /BASE:0
which is removed from DLINK flags to avoid LNK1355 error:
invalid base address 0x0; ARM64 image cannot have base address below 4GB

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Liming Gao <liming.gao@intel.com>

We need to explicitly call the built-in __va_start() for ARM64, otherwise
the variable parameters are not properly enqueued for the next function
calls.
Also do the same for ARM, as as it doesn't harm us.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Liming Gao <liming.gao@intel.com>

Required GCC assembly files are converted for the MSFT assembler

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Liming Gao <liming.gao@intel.com>

We disable the exact same warnings as IA32 and X64.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Liming Gao <liming.gao@intel.com>

We duplicate the Assembly-Code-File section from build_rule.template
because --convert-hex cannot be used with the MSFT ARM assembler.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Liming Gao <liming.gao@intel.com>

VA_START, VA_END and VA_COPY are the same as the generic macros.
VA_ARG was reverse engineered from MS ARM assembly output.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Liming Gao <liming.gao@intel.com>

Introduce CRT assembly replacements for __rt_sdiv, __rt_udiv,
__rt_udiv64, __rt_sdiv64, __rt_srsh (by reusing the RVCT code)
as well as memcpy and memset.
For MSFT compatibility, some of the code needs to be explicitly
forced to ARM, and the /oldit assembly flag needs to be added.
Also, while RVCT_ASM_EXPORT macro invocations have been removed,
the replacement code is designed to be as close as possible to
the one that would have been generated if using the macros.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>

Most of the RVCT assembly can be reused as is for MSFT except
for CpuBreakpoint.asm, which we need to force to Arm mode.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Liming Gao <liming.gao@intel.com>

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Liming Gao <liming.gao@intel.com>

* Introduce a generic Debugger Configuration protocol.
* Add private configuration data in the EBC Debugger and make it
  register the Debugger Configuration protocol on initialization.
* Add a shell application that uses the protocol above to access
  the private data in order to configure the EBC debugger.

Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Pete Batard <pete@akeo.ie>
reviewed-by: Jiewen Yao <jiewen.yao@intel.com>

VM related defs are now in EbcVmTest.h, and opocode related definitions in
Ebc.h.
Because it is used by both the EBC Debugger and driver,
EbcDebugSignalException() sees its definition factorized in
EbcDebuggerHook.h.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>

* This patch introduces EbcDebuggerHook.c/h and inserts the required
  EBCDebugger references into the existing EBC source files.
* With all the hooks defined to their empty version in EbcDebuggerHook.c
  the existing EBC VM behaviour is left unaffected.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>