lp://qastaging/ipxe

Related source package recipes

No recipes using this branch. (?)

Related snap packages

Related bugs

Related blueprints

6932. By Michael Brown <email address hidden> on 2025-11-05

[spcr] Accept alternative type value for a 16550-compatible UART

Some systems (observed on an AWS EC2 m7i.metal-24xl instance in
eu-south-2) use the newer "16550-compatible with parameters defined in
Generic Address Structure" type value. (There does not appear to be
any particular reason why the newer value needs to be used: the UART
is still a standard 16550 with single-byte registers.)

Accept this additional type value for a 16550-compatible UART.

Signed-off-by: Michael Brown <email address hidden>

6931. By Michael Brown <email address hidden> on 2025-11-05

[acpi] Allow acpi_ioremap() to map a port I/O address

Assume that on any platforms where port I/O is used (i.e. x86), a port
I/O address may be used directly for the combined MMIO and port I/O
accessors without requiring an explicit mapping operation.

Signed-off-by: Michael Brown <email address hidden>

6930. By Michael Brown <email address hidden> on 2025-11-05

[ioapi] Allow iounmap() to be called for port I/O addresses

Allow code using the combined MMIO and port I/O accessors to safely
call iounmap() to unmap the MMIO or port I/O region.

In the virtual offset I/O mapping API as used for UEFI, 32-bit BIOS,
and 32-bit RISC-V SBI, iounmap() is a no-op anyway. In 64-bit RISC-V
SBI, we have no concept of port I/O and so the issue is moot.

This leaves only 64-bit BIOS, where it suffices to simply do nothing
for any pages outside of the chosen MMIO virtual address range.

For symmetry, we implement the equivalent change in the very closely
related RISC-V page management code.

Signed-off-by: Michael Brown <email address hidden>

6929. By Michael Brown <email address hidden> on 2025-11-05

[spcr] Use the serial port defined by the ACPI SPCR by default

On platforms where we expect ACPI tables to exist, use the serial port
defined by the ACPI Serial Port Console Redirection (SPCR) table by
default, falling back to the fixed serial port defined at build time.

Signed-off-by: Michael Brown <email address hidden>

6928. By Michael Brown <email address hidden> on 2025-11-05

[spcr] Add support for the ACPI Serial Port Console Redirection table

The BIOS may provide an ACPI Serial Port Console Redirection (SPCR)
table to describe the serial port to be used for early boot messages.

Add support for parsing the SPCR and instantiating a 16550-based UART.
We do not currently attempt to support other types of UART, since iPXE
does not yet have drivers for other types.

Signed-off-by: Michael Brown <email address hidden>

6927. By Michael Brown <email address hidden> on 2025-11-05

[acpi] Add acpi_ioremap() to map an ACPI-described address

An ACPI Generic Address Structure (GAS) may be used to describe the
location of a peripheral such as an early boot console. Add the
relevant definitions and provide acpi_ioremap() as a helper function
to map a region described using this structure.

Signed-off-by: Michael Brown <email address hidden>

6926. By Michael Brown <email address hidden> on 2025-11-05

[uart] Make baud rate a property of the UART

Make the current baud rate (if specified) a property of the UART, to
allow the default_serial_console() function to specify the default
baud rate as well as the default UART device.

Signed-off-by: Michael Brown <email address hidden>

6925. By Michael Brown <email address hidden> on 2025-11-04

[uart] Support 16550 UARTs accessed via either MMIO or port I/O

Use the combined accessors ioread8() and iowrite8() to read and write
16550 UART registers, to allow the decision between using MMIO and
port I/O to be made at runtime.

Minimise the increase in code size for x86 by ignoring the register
shift, since this is essentially used only for non-x86 SoCs.

Signed-off-by: Michael Brown <email address hidden>

6924. By Michael Brown <email address hidden> on 2025-11-04

[ioapi] Provide combined MMIO and port I/O accessors

Some devices (such as a 16550 UART) may be accessed via either MMIO or
port I/O. This is currently forced to be a compile-time decision.
For example: we currently access a 16550 UART via port I/O on x86 and
via MMIO on any other platform.

PCI UARTs with MMIO BARs do exist but are not currently supported in
an x86 build of iPXE. Some AWS EC2 systems (observed on a c6i.metal
instance in eu-west-2) provide only a PCI MMIO UART, and it is
therefore currently impossible to get serial output from iPXE on these
instance types.

Add ioread8(), ioread16(), etc accessors that will select between MMIO
and port I/O at the point of use. For non-x86 platforms where we
currently have no port I/O support, these simply become wrappers
around the corresponding readb(), readw(), etc MMIO accessors. On
x86, we use the fairly well-known trick of treating any 16-bit address
(below 64kB) as a port I/O address.

This trick works even in the i386 BIOS build of iPXE (where virtual
addresses are offset from physical addresses by a runtime constant),
since the first 64kB of the virtual address space will correspond to
the iPXE binary itself (along with its uninitialised-data space), and
so must be RAM rather than a valid MMIO address range.

Signed-off-by: Michael Brown <email address hidden>

6923. By Michael Brown <email address hidden> on 2025-10-29

[pci] Disable decoding while setting a BAR value

Setting the base address for a 64-bit BAR requires two separate 32-bit
writes to configuration space, and so will necessarily result in the
BAR temporarily holding an invalid partially written address.

Some hypervisors (observed on an AWS EC2 c7a.medium instance in
eu-west-2) will assume that guests will write BAR values only while
decoding is disabled, and may not rebuild MMIO mappings for the guest
if the BAR registers are written while decoding is enabled. The
effect of this is that MMIO accesses are not routed through to the
device even though inspection from within the guest shows that every
single PCI configuration register has the correct value. Writes to
the device will be ignored, and reads will return the all-ones pattern
that typically indicates a nonexistent device.

With the ENA network driver now using low latency transmit queues,
this results in the transmit descriptors being lost (since the MMIO
writes to BAR2 never reach the device), which in turn causes the
device to lock up as soon as the transmit doorbell is rung for the
first time.

Fix by disabling decoding of memory and I/O cycles while setting a BAR
address (as we already do while sizing a BAR), so that the invalid
partial address can never be decoded and so that hypervisors will
rebuild MMIO mappings as expected.

Signed-off-by: Michael Brown <email address hidden>