ArmVirtPkg/FdtPL011SerialPortLib: initialize implicitly

FdtPL011SerialPortLib claims that it's usable from the DXE_CORE. That's
not correct: the DXE_CORE calls DEBUG() and ASSERT() before it calls
ProcessLibraryConstructorList(). Via the BaseDebugLibSerialPort instance,
those DEBUG() and ASSERT() calls result in SerialPortWrite() calls, before
ProcessLibraryConstructorList() called either our constructor
FdtPL011SerialPortLibInitialize(), or BaseDebugLibSerialPortConstructor().

(And even if the DXE_CORE called the latter function early enough, it
would just invoke our SerialPortInitialize() function -- which does
nothing.)

This means that the earliest DXE_CORE debug messages are lost.

Rename FdtPL011SerialPortLibInitialize() to SerialPortInitialize(), so
that the same initialization occur through the constructor and the public
SerialPortInitialize() library API.

Turn SerialPortInitialize() calls after the first one into no-ops.

Our SerialPortLib APIs already use (mSerialBaseAddress != 0) to track
initialization. Rework those checks to actually initialize the library if
that hasn't happened yet.

The following new lines appear in the log:

> CoreInitializeMemoryServices:
>   BaseAddress - 0x48000000 Length - 0xF8000000 MinimalMemorySizeNeeded - 0x38C8000
> InstallProtocolInterface: [EfiLoadedImageProtocol] 46EFC3E0
> ProtectUefiImageCommon - 0x46EFC3E0
>   - 0x0000000046EB2000 - 0x0000000000068000

(0x46EB2000 is the load address of the DXE Core.)

Reported-by: Oliver Smith-Denny <osde@linux.microsoft.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>

0 files changed, 0 insertions, 0 deletions