audk/ArmVirtPkg/Library/FdtPL011SerialPortLib/FdtPL011SerialPortLib.c

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

290 lines
8.8 KiB
C
Raw Normal View History

/** @file
Serial I/O Port library functions with base address discovered from FDT
Copyright (c) 2008 - 2010, Apple Inc. All rights reserved.<BR>
Copyright (c) 2012 - 2013, ARM Ltd. All rights reserved.<BR>
Copyright (c) 2014, Linaro Ltd. All rights reserved.<BR>
Copyright (c) 2014, Red Hat, Inc.<BR>
Copyright (c) 2015, Intel Corporation. All rights reserved.<BR>
SPDX-License-Identifier: BSD-2-Clause-Patent
**/
#include <Base.h>
#include <Library/PcdLib.h>
#include <Library/PL011UartLib.h>
#include <Library/SerialPortLib.h>
#include <Pi/PiBootMode.h>
#include <Uefi/UefiBaseType.h>
#include <Uefi/UefiMultiPhase.h>
#include <Pi/PiHob.h>
#include <Library/HobLib.h>
#include <Guid/EarlyPL011BaseAddress.h>
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>
2023-09-30 23:23:43 +02:00
STATIC UINTN mSerialBaseAddress;
STATIC RETURN_STATUS mPermanentStatus = RETURN_SUCCESS;
/**
Program hardware of Serial port
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>
2023-09-30 23:23:43 +02:00
@retval RETURN_SUCCESS If the serial port was initialized successfully by
this call, or an earlier call, to
SerialPortInitialize().
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>
2023-09-30 23:23:43 +02:00
@retval RETURN_NOT_FOUND If no PL011 base address could be found.
@return Error codes forwarded from
PL011UartInitializePort().
**/
RETURN_STATUS
EFIAPI
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>
2023-09-30 23:23:43 +02:00
SerialPortInitialize (
VOID
)
{
VOID *Hob;
RETURN_STATUS Status;
CONST EARLY_PL011_BASE_ADDRESS *UartBase;
UINTN SerialBaseAddress;
UINT64 BaudRate;
UINT32 ReceiveFifoDepth;
EFI_PARITY_TYPE Parity;
UINT8 DataBits;
EFI_STOP_BITS_TYPE StopBits;
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>
2023-09-30 23:23:43 +02:00
if (mSerialBaseAddress != 0) {
return RETURN_SUCCESS;
}
if (RETURN_ERROR (mPermanentStatus)) {
return mPermanentStatus;
}
Hob = GetFirstGuidHob (&gEarlyPL011BaseAddressGuid);
if ((Hob == NULL) || (GET_GUID_HOB_DATA_SIZE (Hob) != sizeof *UartBase)) {
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>
2023-09-30 23:23:43 +02:00
Status = RETURN_NOT_FOUND;
goto Failed;
}
UartBase = GET_GUID_HOB_DATA (Hob);
SerialBaseAddress = (UINTN)UartBase->ConsoleAddress;
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>
2023-09-30 23:23:43 +02:00
if (SerialBaseAddress == 0) {
Status = RETURN_NOT_FOUND;
goto Failed;
}
BaudRate = (UINTN)PcdGet64 (PcdUartDefaultBaudRate);
ReceiveFifoDepth = 0; // Use the default value for Fifo depth
Parity = (EFI_PARITY_TYPE)PcdGet8 (PcdUartDefaultParity);
DataBits = PcdGet8 (PcdUartDefaultDataBits);
StopBits = (EFI_STOP_BITS_TYPE)PcdGet8 (PcdUartDefaultStopBits);
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>
2023-09-30 23:23:43 +02:00
Status = PL011UartInitializePort (
SerialBaseAddress,
FixedPcdGet32 (PL011UartClkInHz),
&BaudRate,
&ReceiveFifoDepth,
&Parity,
&DataBits,
&StopBits
);
if (RETURN_ERROR (Status)) {
goto Failed;
}
mSerialBaseAddress = SerialBaseAddress;
return RETURN_SUCCESS;
Failed:
mPermanentStatus = Status;
return Status;
}
/**
Write data to serial device.
@param Buffer Point of data buffer which need to be written.
@param NumberOfBytes Number of output bytes which are cached in Buffer.
@retval 0 Write data failed.
@retval !0 Actual number of bytes written to serial device.
**/
UINTN
EFIAPI
SerialPortWrite (
IN UINT8 *Buffer,
IN UINTN NumberOfBytes
)
{
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>
2023-09-30 23:23:43 +02:00
if (!RETURN_ERROR (SerialPortInitialize ())) {
return PL011UartWrite (mSerialBaseAddress, Buffer, NumberOfBytes);
}
return 0;
}
/**
Read data from serial device and save the data in buffer.
@param Buffer Point of data buffer which need to be written.
@param NumberOfBytes Number of output bytes which are cached in Buffer.
@retval 0 Read data failed.
@retval !0 Actual number of bytes read from serial device.
**/
UINTN
EFIAPI
SerialPortRead (
OUT UINT8 *Buffer,
IN UINTN NumberOfBytes
)
{
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>
2023-09-30 23:23:43 +02:00
if (!RETURN_ERROR (SerialPortInitialize ())) {
return PL011UartRead (mSerialBaseAddress, Buffer, NumberOfBytes);
}
return 0;
}
/**
Check to see if any data is available to be read from the debug device.
@retval TRUE At least one byte of data is available to be read
@retval FALSE No data is available to be read
**/
BOOLEAN
EFIAPI
SerialPortPoll (
VOID
)
{
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>
2023-09-30 23:23:43 +02:00
if (!RETURN_ERROR (SerialPortInitialize ())) {
return PL011UartPoll (mSerialBaseAddress);
}
return FALSE;
}
/**
Sets the baud rate, receive FIFO depth, transmit/receive time out, parity,
data bits, and stop bits on a serial device.
@param BaudRate The requested baud rate. A BaudRate value of 0 will use the
device's default interface speed.
On output, the value actually set.
@param ReceiveFifoDepth The requested depth of the FIFO on the receive side of the
serial interface. A ReceiveFifoDepth value of 0 will use
the device's default FIFO depth.
On output, the value actually set.
@param Timeout The requested time out for a single character in microseconds.
This timeout applies to both the transmit and receive side of the
interface. A Timeout value of 0 will use the device's default time
out value.
On output, the value actually set.
@param Parity The type of parity to use on this serial device. A Parity value of
DefaultParity will use the device's default parity value.
On output, the value actually set.
@param DataBits The number of data bits to use on the serial device. A DataBits
value of 0 will use the device's default data bit setting.
On output, the value actually set.
@param StopBits The number of stop bits to use on this serial device. A StopBits
value of DefaultStopBits will use the device's default number of
stop bits.
On output, the value actually set.
@retval RETURN_SUCCESS The new attributes were set on the serial device.
@retval RETURN_UNSUPPORTED The serial device does not support this operation.
@retval RETURN_INVALID_PARAMETER One or more of the attributes has an unsupported value.
@retval RETURN_DEVICE_ERROR The serial device is not functioning correctly.
**/
RETURN_STATUS
EFIAPI
SerialPortSetAttributes (
IN OUT UINT64 *BaudRate,
IN OUT UINT32 *ReceiveFifoDepth,
IN OUT UINT32 *Timeout,
IN OUT EFI_PARITY_TYPE *Parity,
IN OUT UINT8 *DataBits,
IN OUT EFI_STOP_BITS_TYPE *StopBits
)
{
ArmVirtPkg/FdtPL011SerialPortLib: call PL011UartLib in all SerialPortLib APIs With the SerialDxe change in commit 4cf3f37c87ba ("MdeModulePkg SerialDxe: Process timeout consistently in SerialRead", 2017-07-18), setting EFI_SERIAL_INPUT_BUFFER_EMPTY in the "Control" output parameter, in the GetControl() SerialPortLib function, is no longer a "small optimization". Namely, due to the SerialDxe change, the GetOneKeyFromSerial() call in TerminalDxe's TerminalConInTimerHandler() can take very long if the input queue is empty, even if GetOneKeyFromSerial()'s return value causes the loop to be exited right after, in the first iteration. This issue causes a boot hang in ArmVirtQemu: with the input queue empty, TerminalConInTimerHandler() takes so long to return that, by the time it returns, there's another execution queued already (due to the associated timer event being signaled meanwhile). The boot process is stuck in the timer event handler. Therefore even the first GetOneKeyFromSerial() iteration must be prevented in TerminalConInTimerHandler() if the input queue is empty, and that requires implementing GetControl() for real. Implement the SetAttributes(), SetControl() and GetControl() APIs (of SerialPortExtLib origin) in FdtPL011SerialPortLib with calls to matching PL011UartLib functions. This follows the example of "ArmPlatformPkg/Library/PL011SerialPortLib" and also matches Star's original idea under [1]. The patch can be considered a continuation of commit ad7f6bc2e116 ("ArmVirtPkg: Use SerialDxe in MdeModulePkg instead of EmbeddedPkg", 2015-11-26), based on the mailing list threads [1] [2] [3]. [1] http://mid.mail-archive.com/1447752930-32880-12-git-send-email-star.zeng@intel.com [2] http://mid.mail-archive.com/1448243067-1880-12-git-send-email-star.zeng@intel.com [3] http://mid.mail-archive.com/b748580c-cb51-32c9-acf9-780841ef15da@redhat.com Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Heyi Guo <guoheyi@huawei.com> Cc: Star Zeng <star.zeng@intel.com> Originally-suggested-by: Star Zeng <star.zeng@intel.com> Reported-by: Brijesh Singh <brijesh.singh@amd.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
2017-08-16 12:45:59 +02:00
RETURN_STATUS Status;
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>
2023-09-30 23:23:43 +02:00
if (RETURN_ERROR (SerialPortInitialize ())) {
ArmVirtPkg/FdtPL011SerialPortLib: call PL011UartLib in all SerialPortLib APIs With the SerialDxe change in commit 4cf3f37c87ba ("MdeModulePkg SerialDxe: Process timeout consistently in SerialRead", 2017-07-18), setting EFI_SERIAL_INPUT_BUFFER_EMPTY in the "Control" output parameter, in the GetControl() SerialPortLib function, is no longer a "small optimization". Namely, due to the SerialDxe change, the GetOneKeyFromSerial() call in TerminalDxe's TerminalConInTimerHandler() can take very long if the input queue is empty, even if GetOneKeyFromSerial()'s return value causes the loop to be exited right after, in the first iteration. This issue causes a boot hang in ArmVirtQemu: with the input queue empty, TerminalConInTimerHandler() takes so long to return that, by the time it returns, there's another execution queued already (due to the associated timer event being signaled meanwhile). The boot process is stuck in the timer event handler. Therefore even the first GetOneKeyFromSerial() iteration must be prevented in TerminalConInTimerHandler() if the input queue is empty, and that requires implementing GetControl() for real. Implement the SetAttributes(), SetControl() and GetControl() APIs (of SerialPortExtLib origin) in FdtPL011SerialPortLib with calls to matching PL011UartLib functions. This follows the example of "ArmPlatformPkg/Library/PL011SerialPortLib" and also matches Star's original idea under [1]. The patch can be considered a continuation of commit ad7f6bc2e116 ("ArmVirtPkg: Use SerialDxe in MdeModulePkg instead of EmbeddedPkg", 2015-11-26), based on the mailing list threads [1] [2] [3]. [1] http://mid.mail-archive.com/1447752930-32880-12-git-send-email-star.zeng@intel.com [2] http://mid.mail-archive.com/1448243067-1880-12-git-send-email-star.zeng@intel.com [3] http://mid.mail-archive.com/b748580c-cb51-32c9-acf9-780841ef15da@redhat.com Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Heyi Guo <guoheyi@huawei.com> Cc: Star Zeng <star.zeng@intel.com> Originally-suggested-by: Star Zeng <star.zeng@intel.com> Reported-by: Brijesh Singh <brijesh.singh@amd.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
2017-08-16 12:45:59 +02:00
Status = RETURN_UNSUPPORTED;
} else {
Status = PL011UartInitializePort (
mSerialBaseAddress,
FixedPcdGet32 (PL011UartClkInHz),
BaudRate,
ReceiveFifoDepth,
Parity,
DataBits,
StopBits
);
}
return Status;
}
/**
Sets the control bits on a serial device.
@param Control Sets the bits of Control that are settable.
@retval RETURN_SUCCESS The new control bits were set on the serial device.
@retval RETURN_UNSUPPORTED The serial device does not support this operation.
@retval RETURN_DEVICE_ERROR The serial device is not functioning correctly.
**/
RETURN_STATUS
EFIAPI
SerialPortSetControl (
IN UINT32 Control
)
{
ArmVirtPkg/FdtPL011SerialPortLib: call PL011UartLib in all SerialPortLib APIs With the SerialDxe change in commit 4cf3f37c87ba ("MdeModulePkg SerialDxe: Process timeout consistently in SerialRead", 2017-07-18), setting EFI_SERIAL_INPUT_BUFFER_EMPTY in the "Control" output parameter, in the GetControl() SerialPortLib function, is no longer a "small optimization". Namely, due to the SerialDxe change, the GetOneKeyFromSerial() call in TerminalDxe's TerminalConInTimerHandler() can take very long if the input queue is empty, even if GetOneKeyFromSerial()'s return value causes the loop to be exited right after, in the first iteration. This issue causes a boot hang in ArmVirtQemu: with the input queue empty, TerminalConInTimerHandler() takes so long to return that, by the time it returns, there's another execution queued already (due to the associated timer event being signaled meanwhile). The boot process is stuck in the timer event handler. Therefore even the first GetOneKeyFromSerial() iteration must be prevented in TerminalConInTimerHandler() if the input queue is empty, and that requires implementing GetControl() for real. Implement the SetAttributes(), SetControl() and GetControl() APIs (of SerialPortExtLib origin) in FdtPL011SerialPortLib with calls to matching PL011UartLib functions. This follows the example of "ArmPlatformPkg/Library/PL011SerialPortLib" and also matches Star's original idea under [1]. The patch can be considered a continuation of commit ad7f6bc2e116 ("ArmVirtPkg: Use SerialDxe in MdeModulePkg instead of EmbeddedPkg", 2015-11-26), based on the mailing list threads [1] [2] [3]. [1] http://mid.mail-archive.com/1447752930-32880-12-git-send-email-star.zeng@intel.com [2] http://mid.mail-archive.com/1448243067-1880-12-git-send-email-star.zeng@intel.com [3] http://mid.mail-archive.com/b748580c-cb51-32c9-acf9-780841ef15da@redhat.com Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Heyi Guo <guoheyi@huawei.com> Cc: Star Zeng <star.zeng@intel.com> Originally-suggested-by: Star Zeng <star.zeng@intel.com> Reported-by: Brijesh Singh <brijesh.singh@amd.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
2017-08-16 12:45:59 +02:00
RETURN_STATUS Status;
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>
2023-09-30 23:23:43 +02:00
if (RETURN_ERROR (SerialPortInitialize ())) {
ArmVirtPkg/FdtPL011SerialPortLib: call PL011UartLib in all SerialPortLib APIs With the SerialDxe change in commit 4cf3f37c87ba ("MdeModulePkg SerialDxe: Process timeout consistently in SerialRead", 2017-07-18), setting EFI_SERIAL_INPUT_BUFFER_EMPTY in the "Control" output parameter, in the GetControl() SerialPortLib function, is no longer a "small optimization". Namely, due to the SerialDxe change, the GetOneKeyFromSerial() call in TerminalDxe's TerminalConInTimerHandler() can take very long if the input queue is empty, even if GetOneKeyFromSerial()'s return value causes the loop to be exited right after, in the first iteration. This issue causes a boot hang in ArmVirtQemu: with the input queue empty, TerminalConInTimerHandler() takes so long to return that, by the time it returns, there's another execution queued already (due to the associated timer event being signaled meanwhile). The boot process is stuck in the timer event handler. Therefore even the first GetOneKeyFromSerial() iteration must be prevented in TerminalConInTimerHandler() if the input queue is empty, and that requires implementing GetControl() for real. Implement the SetAttributes(), SetControl() and GetControl() APIs (of SerialPortExtLib origin) in FdtPL011SerialPortLib with calls to matching PL011UartLib functions. This follows the example of "ArmPlatformPkg/Library/PL011SerialPortLib" and also matches Star's original idea under [1]. The patch can be considered a continuation of commit ad7f6bc2e116 ("ArmVirtPkg: Use SerialDxe in MdeModulePkg instead of EmbeddedPkg", 2015-11-26), based on the mailing list threads [1] [2] [3]. [1] http://mid.mail-archive.com/1447752930-32880-12-git-send-email-star.zeng@intel.com [2] http://mid.mail-archive.com/1448243067-1880-12-git-send-email-star.zeng@intel.com [3] http://mid.mail-archive.com/b748580c-cb51-32c9-acf9-780841ef15da@redhat.com Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Heyi Guo <guoheyi@huawei.com> Cc: Star Zeng <star.zeng@intel.com> Originally-suggested-by: Star Zeng <star.zeng@intel.com> Reported-by: Brijesh Singh <brijesh.singh@amd.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
2017-08-16 12:45:59 +02:00
Status = RETURN_UNSUPPORTED;
} else {
Status = PL011UartSetControl (mSerialBaseAddress, Control);
}
return Status;
}
/**
Retrieve the status of the control bits on a serial device.
@param Control A pointer to return the current control signals from the serial device.
@retval RETURN_SUCCESS The control bits were read from the serial device.
@retval RETURN_UNSUPPORTED The serial device does not support this operation.
@retval RETURN_DEVICE_ERROR The serial device is not functioning correctly.
**/
RETURN_STATUS
EFIAPI
SerialPortGetControl (
OUT UINT32 *Control
)
{
ArmVirtPkg/FdtPL011SerialPortLib: call PL011UartLib in all SerialPortLib APIs With the SerialDxe change in commit 4cf3f37c87ba ("MdeModulePkg SerialDxe: Process timeout consistently in SerialRead", 2017-07-18), setting EFI_SERIAL_INPUT_BUFFER_EMPTY in the "Control" output parameter, in the GetControl() SerialPortLib function, is no longer a "small optimization". Namely, due to the SerialDxe change, the GetOneKeyFromSerial() call in TerminalDxe's TerminalConInTimerHandler() can take very long if the input queue is empty, even if GetOneKeyFromSerial()'s return value causes the loop to be exited right after, in the first iteration. This issue causes a boot hang in ArmVirtQemu: with the input queue empty, TerminalConInTimerHandler() takes so long to return that, by the time it returns, there's another execution queued already (due to the associated timer event being signaled meanwhile). The boot process is stuck in the timer event handler. Therefore even the first GetOneKeyFromSerial() iteration must be prevented in TerminalConInTimerHandler() if the input queue is empty, and that requires implementing GetControl() for real. Implement the SetAttributes(), SetControl() and GetControl() APIs (of SerialPortExtLib origin) in FdtPL011SerialPortLib with calls to matching PL011UartLib functions. This follows the example of "ArmPlatformPkg/Library/PL011SerialPortLib" and also matches Star's original idea under [1]. The patch can be considered a continuation of commit ad7f6bc2e116 ("ArmVirtPkg: Use SerialDxe in MdeModulePkg instead of EmbeddedPkg", 2015-11-26), based on the mailing list threads [1] [2] [3]. [1] http://mid.mail-archive.com/1447752930-32880-12-git-send-email-star.zeng@intel.com [2] http://mid.mail-archive.com/1448243067-1880-12-git-send-email-star.zeng@intel.com [3] http://mid.mail-archive.com/b748580c-cb51-32c9-acf9-780841ef15da@redhat.com Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Heyi Guo <guoheyi@huawei.com> Cc: Star Zeng <star.zeng@intel.com> Originally-suggested-by: Star Zeng <star.zeng@intel.com> Reported-by: Brijesh Singh <brijesh.singh@amd.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
2017-08-16 12:45:59 +02:00
RETURN_STATUS Status;
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>
2023-09-30 23:23:43 +02:00
if (RETURN_ERROR (SerialPortInitialize ())) {
ArmVirtPkg/FdtPL011SerialPortLib: call PL011UartLib in all SerialPortLib APIs With the SerialDxe change in commit 4cf3f37c87ba ("MdeModulePkg SerialDxe: Process timeout consistently in SerialRead", 2017-07-18), setting EFI_SERIAL_INPUT_BUFFER_EMPTY in the "Control" output parameter, in the GetControl() SerialPortLib function, is no longer a "small optimization". Namely, due to the SerialDxe change, the GetOneKeyFromSerial() call in TerminalDxe's TerminalConInTimerHandler() can take very long if the input queue is empty, even if GetOneKeyFromSerial()'s return value causes the loop to be exited right after, in the first iteration. This issue causes a boot hang in ArmVirtQemu: with the input queue empty, TerminalConInTimerHandler() takes so long to return that, by the time it returns, there's another execution queued already (due to the associated timer event being signaled meanwhile). The boot process is stuck in the timer event handler. Therefore even the first GetOneKeyFromSerial() iteration must be prevented in TerminalConInTimerHandler() if the input queue is empty, and that requires implementing GetControl() for real. Implement the SetAttributes(), SetControl() and GetControl() APIs (of SerialPortExtLib origin) in FdtPL011SerialPortLib with calls to matching PL011UartLib functions. This follows the example of "ArmPlatformPkg/Library/PL011SerialPortLib" and also matches Star's original idea under [1]. The patch can be considered a continuation of commit ad7f6bc2e116 ("ArmVirtPkg: Use SerialDxe in MdeModulePkg instead of EmbeddedPkg", 2015-11-26), based on the mailing list threads [1] [2] [3]. [1] http://mid.mail-archive.com/1447752930-32880-12-git-send-email-star.zeng@intel.com [2] http://mid.mail-archive.com/1448243067-1880-12-git-send-email-star.zeng@intel.com [3] http://mid.mail-archive.com/b748580c-cb51-32c9-acf9-780841ef15da@redhat.com Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Heyi Guo <guoheyi@huawei.com> Cc: Star Zeng <star.zeng@intel.com> Originally-suggested-by: Star Zeng <star.zeng@intel.com> Reported-by: Brijesh Singh <brijesh.singh@amd.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
2017-08-16 12:45:59 +02:00
Status = RETURN_UNSUPPORTED;
} else {
Status = PL011UartGetControl (mSerialBaseAddress, Control);
}
return Status;
}