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.
ChangeLog:
v7: http://lists.gnu.org/archive/html/grub-devel/2017-05/
Delete patch 0001(v6) which is wrong.
Improve the commit message of 0002(v6).
Use "machine" variable instead of "feature_xen_boot" mechanism to
determine which xen boot commands we should use.
Update the introduction of xen_module commands in docs/grub.texi,
emphasize xen_hypervisor and xen_module are only for AArch64.
v6: http://lists.gnu.org/archive/html/grub-devel/2016-07/msg00034.html
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 (3):
arm64: add "--nounzip" option support in xen_module command
* util/grub.d/20_linux_xen.in: Add xen_boot command support for
aarch64
arm64: update the introduction of xen boot commands in docs/grub.texi
docs/grub.texi | 38 +++++++++++++-------------------------
grub-core/loader/arm64/xen_boot.c | 17 +++++++++++++++++
util/grub.d/20_linux_xen.in | 13 ++++++++++---
3 files changed, 40 insertions(+), 28 deletions(-)
--
2.9.3
Hi,
I'm getting Alignment Fault when running UEFI image on Juno R0 board which is caused by VariableRuntimeDxe driver's Reclaim() function calling
//
// Copy variable store header.
//
CopyMem (ValidBuffer, VariableStoreHeader, sizeof (VARIABLE_STORE_HEADER));
in edk2\MdeModulePkg\Universal\Variable\RuntimeDxe\Variable.c.
The code above copies 28 bytes of data from NOR flash memory region @0xBFC0048 using __memcpy() from
edk2\MdePkg\Library\BaseMemoryLibOptDxe\AArch64\CopyMem.S using unaligned memory accesses, causing Alignment fault for flash region which is mapped as device memory.
The fix involves switching to generic baseMemoryLib and for ArmJuno.dsc is listed below:
MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf {
<LibraryClasses>
NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
+ BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf
}
and is similar to the following commits for Hisilicon/D02/D03/D05:
Hisilicon/D02: flash related drivers switch to use generic BaseMemoryLib:
https://git.linaro.org/uefi/OpenPlatformPkg.git/commit/Platforms/Hisilicon/…
Hisilicon/D03: flash related drivers switch to use generic BaseMemoryLib:
https://git.linaro.org/uefi/OpenPlatformPkg.git/commit/Platforms/Hisilicon/…
Hisilicon/D05: flash related drivers switch to use generic BaseMemoryLib:
https://git.linaro.org/uefi/OpenPlatformPkg.git/commit/Platforms/Hisilicon/…
Alexei.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hi all,
In linaro-aspen project,we have had a problem in Android fastboot module
of the UEFI. Unfortunately the USB interfaces on our board can't work in
device mode, we can't update and debug the system via the USB port in
Android fastboot.Therefor, we tried to implement the data transmission
with TCP/IP protocol.But we have no idea about whether the plan is
effective or not.
#1.Could you please give us some advises about that plan?
#2.Are there any platforms that have ever implemented TCP/IP transport
in UEFI fastboot module?How can I get the reference code?
#3.I checked the source code of UEFI and found there are several NetWork
drivers in MdeModulePkg/Universal/Network/ folder. Do you know which
platform that have used these drivers successfully?
#4.The last and most important,if we could implemented the TCP/IP
transport in UEFI fastboot module, does the Google fastboot tool on the
Host side could support update and debug the board via TCP/IP transport?
Thank you.
Best regards,
Wengang
Support the feature that BIOS get boot option from BMC and set
it to the first boot order.
The feature works dependding on this patch and the OPP patch
"Hisilicon/D03/D05: get boot option from BMC" both be added.
And it have a limitation, only set the boot order by type, can't by
the specfic devices.
example: there have 4 ethernet ports at D05 board, it can only be booted
from the ethernet port, but which port can not be defined. so it try from
the first port to the end.
so is there any solution? expect your comments.
Signed-off-by: Huang ming <huangming23(a)linaro.org>
Signed-off-by: Chenhui Sun <chenhui.sun(a)linaro.org>
---
.../Universal/BdsDxe/BdsEntry.c | 44 ++++++++++++----------
1 file changed, 24 insertions(+), 20 deletions(-)
diff --git a/IntelFrameworkModulePkg/Universal/BdsDxe/BdsEntry.c b/IntelFrameworkModulePkg/Universal/BdsDxe/BdsEntry.c
index bf81de4..ee51055 100644
--- a/IntelFrameworkModulePkg/Universal/BdsDxe/BdsEntry.c
+++ b/IntelFrameworkModulePkg/Universal/BdsDxe/BdsEntry.c
@@ -36,7 +36,6 @@ EFI_BDS_ARCH_PROTOCOL gBds = {
BdsEntry
};
-UINT16 *mBootNext = NULL;
///
/// The read-only variables defined in UEFI Spec.
@@ -123,6 +122,9 @@ BdsBootDeviceSelect (
BOOLEAN BootNextExist;
LIST_ENTRY *LinkBootNext;
EFI_EVENT ConnectConInEvent;
+ UINTN BootNextSize;
+ UINT16 *BootNext = NULL;
+ UINT16 Index;
//
// Got the latest boot option
@@ -154,7 +156,16 @@ BdsBootDeviceSelect (
}
}
- if (mBootNext != NULL) {
+ //
+ // Check if we have the boot next option
+ //
+ BootNext = BdsLibGetVariableAndSize (
+ L"BootNext",
+ &gEfiGlobalVariableGuid,
+ &BootNextSize
+ );
+
+ if (BootNext != NULL) {
//
// Indicate we have the boot next variable, so this time
// boot will always have this boot option
@@ -179,17 +190,19 @@ BdsBootDeviceSelect (
//
// Add the boot next boot option
//
- UnicodeSPrint (Buffer, sizeof (Buffer), L"Boot%04x", *mBootNext);
- BootOption = BdsLibVariableToOption (&BootLists, Buffer);
+ for (Index = 0; Index < (BootNextSize/sizeof(UINT16)); Index++) {
+ UnicodeSPrint (Buffer, sizeof (Buffer), L"Boot%04x", BootNext[Index]);
+ BootOption = BdsLibVariableToOption (&BootLists, Buffer);
- //
- // If fail to get boot option from variable, just return and do nothing.
- //
- if (BootOption == NULL) {
- return;
- }
+ //
+ // If fail to get boot option from variable, just return and do nothing.
+ //
+ if (BootOption == NULL) {
+ return;
+ }
- BootOption->BootCurrent = *mBootNext;
+ BootOption->BootCurrent = BootNext[Index];
+ }
}
//
// Parse the boot order to get boot option
@@ -528,7 +541,6 @@ BdsEntry (
{
LIST_ENTRY DriverOptionList;
LIST_ENTRY BootOptionList;
- UINTN BootNextSize;
CHAR16 *FirmwareVendor;
EFI_STATUS Status;
UINT16 BootTimeOut;
@@ -638,14 +650,6 @@ BdsEntry (
if (!IsListEmpty (&DriverOptionList)) {
BdsLibLoadDrivers (&DriverOptionList);
}
- //
- // Check if we have the boot next option
- //
- mBootNext = BdsLibGetVariableAndSize (
- L"BootNext",
- &gEfiGlobalVariableGuid,
- &BootNextSize
- );
//
// Setup some platform policy here
--
1.9.1
Hi,
I submit a second version of a patchset with the ComPhy library upgrade.
v1 was thoruoghly cleaned-up, so that every remark could be answered -
it occurred to be quite huge amount of work:) Anyway, now the code
looks more like a proper edk2 one, without redundancies, etc. The details
can be found in a changelog below.
The commits are also available in the github:
https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/commits/opp…
Under the tag one can also find an initial version of 10G link
support in Pp2Dxe driver, which allowed to validate SFI ComPhy.
It will be submitted soon, along with other network changes.
Any remarks or comments will be very welcome.
Best regards,
Marcin
Changelog:
v1 -> v2
* Improve commit message in first patch
* Split first patch to three new:
- Fix lane assignment
- Rename to KR to SFI
- Update .dsc to the newest changes around serdes
* Add 'Reviewed-by' in patch 4
* Remove redundancy in Gx_SETy registers description - use
common offsets and masks, improve naming
* Improve comments
* Use Mmio... functions instead of custom ones
* Make setting parameters more readable
* Last patch - rename PCD, clean-up whitespaces, fix comment.
Marcin Wojtas (8):
Platforms/Marvell: ComPhyLib: Cleanup and fix SerDes lanes assignment
Platforms/Marvell: ComPhyLib: Rename KR to SFI
Platforms/Marvell: Update SerDes types on A70x0 development board
Platforms/Marvell: ComPhyLib: Mark failing lane as unconnected
Platforms/Marvell: ComPhyLib: Configure analog parameters for SATA
Platforms/Marvell: ComPhyLib: Configure analog parameters for PCIE
Platforms/Marvell: ComPhyLib: Add missing SFI and RXAUI configuration
Platforms/Marvell: ComPhyLib: Move devices description to MvHwDescLib
Documentation/Marvell/PortingGuide/ComPhy.txt | 64 +-
Platforms/Marvell/Armada/Armada70x0.dsc | 13 +-
Platforms/Marvell/Include/Library/MvComPhyLib.h | 5 +
Platforms/Marvell/Include/Library/MvHwDescLib.h | 38 +
Platforms/Marvell/Library/ComPhyLib/ComPhyCp110.c | 851 +++++++++++++++++++++-
Platforms/Marvell/Library/ComPhyLib/ComPhyLib.c | 97 ++-
Platforms/Marvell/Library/ComPhyLib/ComPhyLib.h | 273 +++++--
Platforms/Marvell/Library/ComPhyLib/ComPhyLib.inf | 26 +-
Platforms/Marvell/Marvell.dec | 28 +-
9 files changed, 1174 insertions(+), 221 deletions(-)
--
1.8.3.1
Hi all,
I have started the prototyping of moving the existing OpenPlatformPkg
ports into edk2-platforms (and edk2-non-osi).
Doing some due dilligence, I've spotted that the "Contributed-under: "
tag has been left out from some commits. Clearly, most of those were
mine (oops), so let me just formally state that:
b9ac9979d4ddc4da77fa41a99dbbf68d26520a22
1c90ac121061b221a83bc052a7e22371d0da3c01
2146aa238a2b687a4a8ed408ca784f5b70321444
979db78c884e538626a3d026996eb348a84c6787
were indeed Contributed-under: TianoCore Contribution Agreement 1.0
Ard, could you confirm the same for:
084445120e94910025e02fe66ac528a3f4cc303a
df47cec139b01f9491d7e9608d832dd0c34fa363
and Ryan for:
50babddd0cb440742bf4d0341f319239317eba5d
?
Ard, there are also some missing Reviewed-by - do you agree with me
that this is not an issue (they are all implicitly reviewed by either
you or me), just something to be more careful of in future?
Regards,
Leif