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
Hi,
I have been working on support for AHCI controller for my ARMv8 platform.
For that I have integrated my PciEmulation code and SataControllerDxe driver code with MdeModulePkg/Bus/Ata.
But facing one issue, this is same issue reported by Jan Dabros(in To list) sometime back.
Setting PxCMD.FRE bit of command register doesn't cause PxCMD.FR to be set to '1' even after "500msec" timeout.
(As per AHCI spec 1.3 : When PxCMD.FRE is set, it causes PxCMD.FR to be set to '1' )
Is it correct to just comment out following code part from "MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AhciMode.c" file, "AhciModeInitialization" function:
As Initialization timeouts is occurring in below part of code:
//
// Enable FIS Receive DMA engine for the first D2H FIS.
//
Offset = EFI_AHCI_PORT_START + Port * EFI_AHCI_PORT_REG_WIDTH + EFI_AHCI_PORT_CMD;
AhciOrReg (PciIo, Offset, EFI_AHCI_PORT_CMD_FRE);
Status = AhciWaitMmioSet (
PciIo,
Offset,
EFI_AHCI_PORT_CMD_FR,
EFI_AHCI_PORT_CMD_FR,
EFI_AHCI_PORT_CMD_FR_CLEAR_TIMEOUT
);
if (EFI_ERROR (Status)) {
continue;
}
And if above code is commented out, then SATA stack works completely fine.
What can be the problem?
Thank you in advance for your time!
Best regards,
Shaveta
Hi folks,
We can see that in a single timer interrupt, there will be two writes to
EOIR, one in timer interrupt handler, the other in GIC IRQ handler.
The question is: does two writes to EOIR have any side effect? From GIC
specification (ARM IHI 0069B (ID121715)), we can see below text about
writing EOIR (page 205):
A write to this register must correspond to the most recent valid read
from an Interrupt
Acknowledge Register for which there has not been a priority drop and
that this identifier was read
from ICC_IAR1_EL1 while operating in the same Security state as that in
which the write occurs,
otherwise the system behavior is UNPREDICTABLE. A valid read is a read
that returns a valid interrupt
ID, that is not a special INTID.
For GICv2, we can also see below text about EOIR:
For nested interrupts, the order of writes to this register must be the
reverse of the order of interrupt
acknowledgement. Behavior is UNPREDICTABLE if:
• This ordering constraint is not maintained.
*• The value written to this register does not match an active
interrupt, or the ID of a spurious interrupt. *
• The value written to this register does not match the last valid
interrupt value read from GICC_IAR.
When we issue the 1st EOIR, the interrupt will be deactivated, so it is
not in active state anymore for the 2nd write of EOIR.
Could anyone help to confirm whether it is OK to keep the 2nd write of
EOIR? And how to explain the above paragraphs from GIC specification?
Thanks and regards.
Heyi
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: Leif Lindholm <leif.lindholm(a)linaro.org>
Reviewed-by: Ard Biesheuvel <ard.biesheu...(a)linaro.org>
Signed-off-by: Sudeep Holla <sudeep.holla(a)arm.com>
---
Platforms/ARM/Juno/ArmJuno.dsc | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Platforms/ARM/Juno/ArmJuno.dsc b/Platforms/ARM/Juno/ArmJuno.dsc
index 45d9950decba..2e9ccfbad396 100644
--- a/Platforms/ARM/Juno/ArmJuno.dsc
+++ b/Platforms/ARM/Juno/ArmJuno.dsc
@@ -174,6 +174,8 @@
gEfiMdeModulePkgTokenSpaceGuid.PcdResetOnMemoryTypeInformationChange|FALSE
gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdShellFile|{ 0x83, 0xA5, 0x04, 0x7C, 0x3E, 0x9E, 0x1C, 0x4F, 0xAD, 0x65, 0xE0, 0x52, 0x68, 0xD0, 0xB4, 0xD1 }
+ gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiExposedTableVersions|0x20
+
[PcdsPatchableInModule]
# Console Resolution (Full HD)
gEfiMdeModulePkgTokenSpaceGuid.PcdVideoHorizontalResolution|1920
--
2.7.4