The RX path in MarvellYukonDxe uses DMA buffers allocated via
EFI_PCI_IO_PROTOCOL::AllocateBuffer(), and copies the contents of each
into a temporary buffer, whose contents are copied yet another time before
arriving at the caller of EFI_SIMPLE_NETWORK_PROTOCOL::Receive()
This is inefficient for several reasons:
- the streaming bus master DMA operations used for RX do not require the
use of buffers allocated via EFI_PCI_IO_PROTOCOL::AllocateBuffer(), which
may return uncached memory on platforms with non-coherent DMA
- EFI_PCI_IO_PROTOCOL::AllocateBuffer() performs page based allocations,
which means the UEFI memory map is modified for every packet received,
now that the improper reuse of DMA buffers has been fixed.
So drop the call to EFI_PCI_IO_PROTOCOL::AllocateBuffer(), and instead,
perform a pool allocation whose ownership is transferred from the RX ring
to the RX linked list, which removes the need for a copy.
Also, since pool allocations decay to page based allocations for sizes
that equal or exceed EFI_PAGE_SIZE, reduce MAX_SUPPORTED_PACKET_SIZE to
the Ethernet default of 1500 bytes.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
---
It builds, but does it run? I have no clue, since I don't own a Juno or
a Softiron 1000. Comments and testing appreciated. Thanks.
Drivers/Net/MarvellYukonDxe/if_msk.c | 26 ++++++--------------
Drivers/Net/MarvellYukonDxe/if_msk.h | 2 +-
2 files changed, 9 insertions(+), 19 deletions(-)
diff --git a/Drivers/Net/MarvellYukonDxe/if_msk.c b/Drivers/Net/MarvellYukonDxe/if_msk.c
index ecd716a66b55..d49c8e92a69a 100644
--- a/Drivers/Net/MarvellYukonDxe/if_msk.c
+++ b/Drivers/Net/MarvellYukonDxe/if_msk.c
@@ -595,7 +595,7 @@ msk_newbuf (
rxd = &sc_if->msk_cdata.msk_rxdesc[idx];
- Status = mPciIo->AllocateBuffer (mPciIo, AllocateAnyPages, EfiBootServicesData, EFI_SIZE_TO_PAGES (Length), &Buffer, 0);
+ Status = gBS->AllocatePool (EfiBootServicesData, Length, &Buffer);
if (EFI_ERROR (Status)) {
return Status;
}
@@ -603,8 +603,7 @@ msk_newbuf (
Status = mPciIo->Map (mPciIo, EfiPciIoOperationBusMasterWrite, Buffer, &Length, &PhysAddr, &Mapping);
if (EFI_ERROR (Status)) {
- Length = MAX_SUPPORTED_PACKET_SIZE;
- mPciIo->FreeBuffer (mPciIo, EFI_SIZE_TO_PAGES (Length), Buffer);
+ gBS->FreePool (Buffer);
return Status;
}
@@ -1630,7 +1629,7 @@ msk_txrx_dma_free (
mPciIo->Unmap (mPciIo, rxd->rx_m.DmaMapping);
// Free Rx buffers as we own these
if(rxd->rx_m.Buf != NULL) {
- mPciIo->FreeBuffer (mPciIo, EFI_SIZE_TO_PAGES (rxd->rx_m.Length), rxd->rx_m.Buf);
+ gBS->FreePool (rxd->rx_m.Buf);
rxd->rx_m.Buf = NULL;
}
gBS->SetMem (&(rxd->rx_m), sizeof (MSK_DMA_BUF), 0);
@@ -1933,23 +1932,14 @@ msk_rxeof (
if (!EFI_ERROR (Status)) {
gBS->SetMem (m_link, sizeof (MSK_LINKED_SYSTEM_BUF), 0);
m_link->Signature = RX_MBUF_SIGNATURE;
- Status = gBS->AllocatePool (EfiBootServicesData,
- len,
- (VOID**) &m_link->SystemBuf.Buf);
- if(!EFI_ERROR (Status)) {
- gBS->CopyMem (m_link->SystemBuf.Buf, m.Buf, len);
- m_link->SystemBuf.Length = len;
-
- InsertTailList (&mSoftc->ReceiveQueueHead, &m_link->Link);
- } else {
- DEBUG ((EFI_D_NET, "Marvell Yukon: failed to allocate DMA buffer. Dropping Frame\n"));
- gBS->FreePool (m_link);
- }
+ m_link->SystemBuf.Buf = m.Buf;
+ m_link->SystemBuf.Length = len;
+
+ InsertTailList (&mSoftc->ReceiveQueueHead, &m_link->Link);
} else {
DEBUG ((EFI_D_NET, "Marvell Yukon: failed to allocate receive buffer link. Dropping Frame\n"));
+ gBS->FreePool (m.Buf);
}
-
- mPciIo->FreeBuffer (mPciIo, EFI_SIZE_TO_PAGES (m.Length), m.Buf);
} while (0);
MSK_RX_INC (sc_if->msk_cdata.msk_rx_cons, MSK_RX_RING_CNT);
diff --git a/Drivers/Net/MarvellYukonDxe/if_msk.h b/Drivers/Net/MarvellYukonDxe/if_msk.h
index a5025a39ecf3..66513d3c54c1 100644
--- a/Drivers/Net/MarvellYukonDxe/if_msk.h
+++ b/Drivers/Net/MarvellYukonDxe/if_msk.h
@@ -15,7 +15,7 @@
#include <Uefi.h>
-#define MAX_SUPPORTED_PACKET_SIZE EFI_PAGE_SIZE
+#define MAX_SUPPORTED_PACKET_SIZE (1500)
EFI_STATUS mskc_probe (EFI_PCI_IO_PROTOCOL *PciIo);
--
2.7.4
This is v2 of the Celloboard driver to upload the Renesas PD720202
XHCI firmware at boot, so that both the UEFI firmware and the OS can
use the device without having to care about this firmware.
Now tested using a PD720201 with an external ROM, which contains the
same firmware. This involved ignoring the 'has external ROM' check
temporarily, allowing the builtin firmware image to be overridden with
by the image from this driver.
Ard Biesheuvel (2):
Drivers/Xhci: implement firmware download driver for Renesas PD72020x
Platforms/AMD/CelloBoard: add Renesas PD72020x firmware uploader
Drivers/Xhci/RenesasFirmwarePD720202/RenesasFirmwarePD720202.c | 386 ++++++++++++++++++++
Drivers/Xhci/RenesasFirmwarePD720202/RenesasFirmwarePD720202.inf | 43 +++
OpenPlatformPkg.dec | 3 +
Platforms/AMD/Styx/CelloBoard/CelloBoard.dsc | 4 +
Platforms/AMD/Styx/CelloBoard/CelloBoard.fdf | 10 +
5 files changed, 446 insertions(+)
create mode 100644 Drivers/Xhci/RenesasFirmwarePD720202/RenesasFirmwarePD720202.c
create mode 100644 Drivers/Xhci/RenesasFirmwarePD720202/RenesasFirmwarePD720202.inf
--
2.7.4
Hi experts,
UEFI spec says BIS (Boot Integrity Services) protocol is used to
authenticate image. However, it seems UEFI secure boot has already
covered the same function even for PXE boot. Also I can't see any
implementation of BIS in EDK2.
So is BIS a little outdated and can be completely replaced by UEFI
secure boot?
Thanks and Regards,
Heyi
This moves all platforms in OpenPlatformPkg to ArmBaseLib, which replaces
all previously existing variants of ArmLib.
I have build tested each of them, and boot tested the ones I can test
(FVP and Overdrive).
I picked up some fixes for D02/D03 along the way. These are listed first
(#1 - #4), #1 is required to fix the build, #5 is required since ArmBaseLib
no longer pulls in MemoryAllocationLib. #2 and #3 are optional, but useful
improvements nonetheless. #5 does the ArmBaseLib switch itself for D02/D03
Patches #6 to #9 replace all ArmLib references to ArmBaseLib in the remaining
platforms.
NOTE: This series combines with my armlib-cleanup branch [0], which deviates
from the v1 I sent out today. When testing these patches, please use
this branch; it will be the basis of my v2 submission once we have
confirmed that everything works as expected. This series can be found
here [1]
[0] https://git.linaro.org/people/ard.biesheuvel/uefi-next.git/shortlog/refs/he…
[1] https://git.linaro.org/uefi/OpenPlatformPkg.git/shortlog/refs/heads/armlib-…
Ard Biesheuvel (9):
Hisilicon/D0x: remove UEFI_APPLICATION BuildOptions override
Hisilicon/D0x: get rid of EDK2_SKIP_PEICORE
Hisilicon/D0x: get rid of APRIORI declarations
Hisilicon/IoInitDxe: add hidden dependency on MemoryAllocationLib to
.inf
Hisilicon/D0x: switch to ArmBaseLib
BeagleBoardPkg Omap35xxPkg: switch to ArmBaseLib
AMD/Styx: switch to ArmBaseLib
Platforms/ARM: switch to ArmBaseLib
Marvell/Armada: switch to ArmBaseLib
Chips/Hisilicon/Pv660/Drivers/IoInitDxe/IoInitDxe.inf | 1 +
Chips/Hisilicon/Pv660/Pv660.dsc.inc | 12 ------
Chips/TexasInstruments/Omap35xx/Omap35xxPkg.dsc | 2 +-
Platforms/AMD/Styx/CelloBoard/CelloBoard.dsc | 3 +-
Platforms/AMD/Styx/OverdriveBoard/OverdriveBoard.dsc | 3 +-
Platforms/ARM/Juno/ArmJuno.dsc | 7 +---
Platforms/ARM/VExpress/ArmVExpress-CTA15-A7.dsc | 3 +-
Platforms/ARM/VExpress/ArmVExpress-FVP-AArch64.dsc | 4 +-
Platforms/Hisilicon/D02/Pv660D02.dsc | 34 +++++------------
Platforms/Hisilicon/D02/Pv660D02.fdf | 11 ------
Platforms/Hisilicon/D03/D03.dsc | 39 +++++---------------
Platforms/Hisilicon/D03/D03.fdf | 11 ------
Platforms/Marvell/Armada/Armada.dsc.inc | 4 +-
Platforms/TexasInstruments/BeagleBoard/BeagleBoardPkg.dsc | 4 +-
14 files changed, 27 insertions(+), 111 deletions(-)
--
2.7.4
On ARM systems, mapping normal memory as device memory may have unintended
side effects, given that unaligned accesses or loads and stores with special
semantics (e.g., load/store exclusive) may fault or may not work as expected.
Similarly, DC ZVA instructions are only supported on normal memory, not
device memory.
So remove the EFI_MEMORY_UC attribute that we set by default on system RAM.
If any region requires this attribute, it is up to the driver to set this
attribute, and to ensure that no offending operations are performed on it.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
---
Platforms/AMD/Styx/Library/MemoryInitPei/MemoryInitPeiLib.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/Platforms/AMD/Styx/Library/MemoryInitPei/MemoryInitPeiLib.c b/Platforms/AMD/Styx/Library/MemoryInitPei/MemoryInitPeiLib.c
index 5fb63349864e..70821d1b120b 100644
--- a/Platforms/AMD/Styx/Library/MemoryInitPei/MemoryInitPeiLib.c
+++ b/Platforms/AMD/Styx/Library/MemoryInitPei/MemoryInitPeiLib.c
@@ -143,7 +143,6 @@ MemoryPeim (
EFI_RESOURCE_SYSTEM_MEMORY,
( EFI_RESOURCE_ATTRIBUTE_PRESENT |
EFI_RESOURCE_ATTRIBUTE_INITIALIZED |
- EFI_RESOURCE_ATTRIBUTE_UNCACHEABLE |
EFI_RESOURCE_ATTRIBUTE_WRITE_COMBINEABLE |
EFI_RESOURCE_ATTRIBUTE_WRITE_THROUGH_CACHEABLE |
EFI_RESOURCE_ATTRIBUTE_WRITE_BACK_CACHEABLE |
@@ -164,7 +163,6 @@ MemoryPeim (
EFI_RESOURCE_SYSTEM_MEMORY,
( EFI_RESOURCE_ATTRIBUTE_PRESENT |
EFI_RESOURCE_ATTRIBUTE_INITIALIZED |
- EFI_RESOURCE_ATTRIBUTE_UNCACHEABLE |
EFI_RESOURCE_ATTRIBUTE_WRITE_COMBINEABLE |
EFI_RESOURCE_ATTRIBUTE_WRITE_THROUGH_CACHEABLE |
EFI_RESOURCE_ATTRIBUTE_WRITE_BACK_CACHEABLE |
--
2.7.4
Hi folks,
I have some questions about ARM SBSA v3.0 and SBBR v1.0. Could anyone
please provide the answers or some ideas?
1. In SBSA it says that I/O virtualization property should be expressed
by system firmware data. Then how to express this information by ACPI?
Is only IORT table related? Or is there any examples?
2. In SBSA Section 4.1.3, page 14 as below, does the term "memory" here
also include peripheral memory mapped IO spaces? Does the term "access"
include both "read" and "write"? If write is also included, I'm afraid
there might be some critical configuration registers which will cause
unpredicted behavior or even system hang due to unintended random write.
3. In SBBR, EFI_LOAD_FILE2_PROTOCOL is a required protocol. However,it
is not used for boot in UEFI, and is mainly used for loading PCIe option
ROM in EDK2 implementation. So why is this protocol required while PCIe
is not mandatory for ARM server?
4. In SBBR, for IPv6 related protocols, it is said that they are
optional on platforms that do not support networking. The question is,
on platforms that *do* support networking, do IPv6 protocols become
mandatory? Or is it allowed for only supporting IPv4 protocols?
Thanks and regards.
Heyi
This is a completely untested but complete implementation of a firmware
uploader for the Renesas PD720202 PCIe XHCI controller. It is enabled for
Cello in patch #2 if '-D RENESAS_XHCI_FW_DIR=<dir>' is passed on the
build command line, where it expects to find the firmware image, in a
file called K2013080.mem
Ard Biesheuvel (2):
Drivers/Xhci: implement firmware download driver for Renesas PD720202
Platforms/AMD/CelloBoard: add Renesas PD720202 firmware downloader
Drivers/Xhci/RenesasFirmwarePD720202/RenesasFirmwarePD720202.c | 365 ++++++++++++++++++++
Drivers/Xhci/RenesasFirmwarePD720202/RenesasFirmwarePD720202.inf | 43 +++
OpenPlatformPkg.dec | 3 +
Platforms/AMD/Styx/CelloBoard/CelloBoard.dsc | 4 +
Platforms/AMD/Styx/CelloBoard/CelloBoard.fdf | 10 +
5 files changed, 425 insertions(+)
create mode 100644 Drivers/Xhci/RenesasFirmwarePD720202/RenesasFirmwarePD720202.c
create mode 100644 Drivers/Xhci/RenesasFirmwarePD720202/RenesasFirmwarePD720202.inf
--
2.7.4