From: Fu Wei <fu.wei(a)linaro.org>
This patchset add xen_boot support into grup-mkconfig for
generating xen boot entrances automatically
Also update the docs/grub.texi for new xen_boot commands.
This patchset has been tested on Foudation model with a bug fix:
http://lists.gnu.org/archive/html/grub-devel/2016-02/msg00205.html
ChangeLog:
v6: http://lists.gnu.org/archive/html/grub-devel/2016-07/
Fix Coding style of util/grub.d/20_linux_xen.in, use soft tab.
v5: http://lists.gnu.org/archive/html/grub-devel/2016-07/msg00008.html
Update the introduction of xen_module commands in docs/grub.texi,
according to the suggestion from Julien Grall
v4: http://lists.gnu.org/archive/html/grub-devel/2016-05/
according to the XSM loading mechanism of Xen(upstreamed),
update the introduction of xen_module commands in docs/grub.texi
v3: http://lists.gnu.org/archive/html/grub-devel/2016-02/msg00314.html
reorder the patches
update the introduction of xen_module commands in docs/grub.texi
v2: http://lists.gnu.org/archive/html/grub-devel/2016-02/msg00282.html
add "--nounzip" option support in xen_module
use "feature_xen_boot" instead of "grub_xen_boot"
update the introduction of xen boot commands in docs/grub.texi
v1 :first upstream patchset:
http://lists.gnu.org/archive/html/grub-devel/2016-02/msg00264.html
Fu Wei (4):
i386,xen: Add xen_hypervisor and xen_module aliases for i386
arm64: add "--nounzip" option support in xen_module command
* util/grub.d/20_linux_xen.in: Add xen_boot command support
arm64: update the introduction of xen boot commands in docs/grub.texi
docs/grub.texi | 32 +++++++++-----------------------
grub-core/loader/arm64/xen_boot.c | 17 +++++++++++++++++
grub-core/loader/i386/xen.c | 7 +++++++
grub-core/normal/main.c | 2 +-
util/grub.d/20_linux_xen.in | 13 ++++++++++---
5 files changed, 44 insertions(+), 27 deletions(-)
--
2.5.5
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
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
The ACPI spec predates the AARCH64 architecture by 5 versions, so there
is no point in supporting anything below v5.0. So set the PCD that
controls the ACPI table generation to the appropriate value.
Based on the commit e0692789058e ("ArmVirtPkg/ArmVirtQemu: limit ACPI
support to v5.0 and higher") in the upstream TianoCore by Ard Biesheuvel
Contributed-under: TianoCore Contribution Agreement 1.0
Cc: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Cc: Leif Lindholm <leif.lindholm(a)linaro.org>
Cc: Evan Lloyd <Evan.Lloyd(a)arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla(a)arm.com>
---
Platforms/ARM/Juno/ArmJuno.dsc | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Platforms/ARM/Juno/ArmJuno.dsc b/Platforms/ARM/Juno/ArmJuno.dsc
index c51d8f2e21ab..3029999bc66f 100644
--- a/Platforms/ARM/Juno/ArmJuno.dsc
+++ b/Platforms/ARM/Juno/ArmJuno.dsc
@@ -183,6 +183,10 @@
#
gEfiMdeModulePkgTokenSpaceGuid.PcdSmbiosVersion|0x0300
gEfiMdeModulePkgTokenSpaceGuid.PcdSmbiosDocRev|0x0
+ #
+ # ACPI Table Version
+ #
+ gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiExposedTableVersions|0x20
[PcdsPatchableInModule]
# Console Resolution (Full HD)
--
2.7.4
These patches are for v4 of the MarvellYukon driver posted by Daniil Egranov
on June 16 to this mailing list.
The impetus was to get this driver to work on a SoftIron Overdrive 1000
board using the AMD Opteron-A (Seattle/Styx) SoC. On this platform, in my
testing, edk2 allocates DMA buffers with 64-bit addresses. The Marvell
Yukon driver as posted did not support 64-bit addresses, and simply
truncated any DMA address to 32-bits. After consulting with Ard Biesheuvel
and Leif Lindholm on IRC, it seemed the proper fix was to add support for
64-bit DMA. For this I went back to the original source of this driver
(FreeBSD), and brought over the appropriate code.
A couple of patches are basic fixes, but the one titled "Don't re-use DMA
buffers" changes how handling of DMA buffers works. This patch makes it
work closer to how the FreeBSD implementation works and also adds some
required DMA function calls. Its commit message is worth a read.
I don't have a Juno board to test this on, so while this does work on my
Overdrive 1000, there's a chance I broke something for other users.
Let me know!
Alan.
Alan Ott (7):
Drivers/Net/MarvellYukon: Remove ARM-specific include
Drivers/Net/MarvellYukon: Set Dual Address Cycle Attribute
Drivers/Net/MarvellYukon: Put model_name under MDEPKG_NDEBUG ifndef
Drivers/Net/MarvellYukon: Use EFI_SIZE_TO_PAGES()
Drivers/Net/MarvellYukon: Don't re-use DMA buffers
Drivers/Net/MarvellYukon: Zero allocated memory for DMA receive
buffers
Drivers/Net/MarvellYukon: Add 64-bit DMA support
Drivers/Net/MarvellYukonDxe/DeviceConfig.c | 4 +-
Drivers/Net/MarvellYukonDxe/if_msk.c | 95 +++++++++++++++++++++++-------
Drivers/Net/MarvellYukonDxe/if_mskreg.h | 17 +++++-
3 files changed, 91 insertions(+), 25 deletions(-)
--
2.5.0
The PCD PcdArmPrimaryCoreMask is of dubious value, not only because it is
unclear what the point is of masking out bits before comparing a given
MPIDR_EL1 value with a known value belonging to the primary core, but also
because the default value of 0xF03 masks out bits that belong to the actual
affinity levels.
For Styx, simply ignore the mask altogether. Since its version of
ArmPlatformPeiBootAction () records the primary MPIDR_EL1 value upon
first entry, we know its exact value, and no masking is necessary.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
---
Hello Alan,
Any chance you could try this patch, and check whether it solves the
regression you have been experiencing? I'd try it myself it it weren't
for the fact that my SPI flash programmer is broken atm.
Thanks,
Ard.
Platforms/AMD/Styx/Library/AmdStyxLib/AArch64/Helper.S | 3 ---
Platforms/AMD/Styx/Library/AmdStyxLib/AmdStyxLib.inf | 1 -
Platforms/AMD/Styx/Library/AmdStyxLib/AmdStyxLibSec.inf | 1 -
3 files changed, 5 deletions(-)
diff --git a/Platforms/AMD/Styx/Library/AmdStyxLib/AArch64/Helper.S b/Platforms/AMD/Styx/Library/AmdStyxLib/AArch64/Helper.S
index a3ac60282706..b7ec02f0e69f 100644
--- a/Platforms/AMD/Styx/Library/AmdStyxLib/AArch64/Helper.S
+++ b/Platforms/AMD/Styx/Library/AmdStyxLib/AArch64/Helper.S
@@ -58,9 +58,6 @@ ASM_FUNC(ArmGetCpuCountPerCluster)
// IN UINTN MpId
// );
ASM_FUNC(ArmPlatformIsPrimaryCore)
- MOV32 (w1, FixedPcdGet32 (PcdArmPrimaryCoreMask))
- and x0, x0, x1
-
ldr w1, PrimaryCoreMpid
cmp w0, w1
diff --git a/Platforms/AMD/Styx/Library/AmdStyxLib/AmdStyxLib.inf b/Platforms/AMD/Styx/Library/AmdStyxLib/AmdStyxLib.inf
index 4a6469ee016c..8e9169161d16 100644
--- a/Platforms/AMD/Styx/Library/AmdStyxLib/AmdStyxLib.inf
+++ b/Platforms/AMD/Styx/Library/AmdStyxLib/AmdStyxLib.inf
@@ -67,7 +67,6 @@
gAmdStyxTokenSpaceGuid.PcdTrustedFWMemorySize
[FixedPcd]
- gArmTokenSpaceGuid.PcdArmPrimaryCoreMask
gArmTokenSpaceGuid.PcdArmPrimaryCore
gArmPlatformTokenSpaceGuid.PcdCoreCount
diff --git a/Platforms/AMD/Styx/Library/AmdStyxLib/AmdStyxLibSec.inf b/Platforms/AMD/Styx/Library/AmdStyxLib/AmdStyxLibSec.inf
index 0b9b6287168d..2a2d6ffb8c64 100644
--- a/Platforms/AMD/Styx/Library/AmdStyxLib/AmdStyxLibSec.inf
+++ b/Platforms/AMD/Styx/Library/AmdStyxLib/AmdStyxLibSec.inf
@@ -62,7 +62,6 @@
gArmTokenSpaceGuid.PcdFvBaseAddress
[FixedPcd]
- gArmTokenSpaceGuid.PcdArmPrimaryCoreMask
gArmTokenSpaceGuid.PcdArmPrimaryCore
gArmPlatformTokenSpaceGuid.PcdCoreCount
--
2.7.4