Re: [edk2] [PATCH] ArmPlatformPkg/Bds: Use HandleProtocol to get SNP instance
Reviewed-By: Olivier Martin olivier.mar...@arm.com
-Original Message-
From: Heyi Guo [mailto:heyi@linaro.org]
Sent: 16 July 2015 09:35
To: edk2-devel@lists.sourceforge.net
Cc: Heyi Guo; Olivier Martin; Leif Lindholm
Subject: [edk2] [PATCH] ArmPlatformPkg/Bds: Use HandleProtocol to get
SNP instance
LocateProtocol only gets the 1st SNP instance and this will be wrong in a
system with multiple SNP instances installed. Use HandleProtocol instead.
Cc: Olivier Martin olivier.mar...@arm.com
Cc: Leif Lindholm leif.lindh...@linaro.org
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Heyi Guo heyi@linaro.org
---
ArmPlatformPkg/Bds/BootOptionSupport.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ArmPlatformPkg/Bds/BootOptionSupport.c
b/ArmPlatformPkg/Bds/BootOptionSupport.c
index f50f13f..27faf00 100644
--- a/ArmPlatformPkg/Bds/BootOptionSupport.c
+++ b/ArmPlatformPkg/Bds/BootOptionSupport.c
@@ -667,7 +667,7 @@ BdsLoadOptionPxeList (
// Allocate BDS Supported Device structure
SupportedDevice =
(BDS_SUPPORTED_DEVICE*)AllocatePool(sizeof(BDS_SUPPORTED_DEVICE));
- Status = gBS-LocateProtocol (gEfiSimpleNetworkProtocolGuid, NULL,
(VOID **)SimpleNet);
+ Status = gBS-HandleProtocol (HandleBuffer[Index],
+ gEfiSimpleNetworkProtocolGuid, (VOID **)SimpleNet);
if (!EFI_ERROR(Status)) {
Mac = SimpleNet-Mode-CurrentAddress;
UnicodeSPrint
(DeviceDescription,BOOT_DEVICE_DESCRIPTION_MAX,LMAC Address:
%02x:%02x:%02x:%02x:%02x:%02x, Mac-Addr[0], Mac-Addr[1], Mac-
Addr[2], Mac-Addr[3], Mac-Addr[4], Mac-Addr[5]);
--
2.1.4
-- 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.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered
in England Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England Wales, Company No: 2548782
--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
[edk2] [PATCH 3/4] StdLib/LibC: Provide missing ARM symbols
From: Harry Liebel harry.lie...@arm.com
Provide missing functionality by using files from LLVM.
Changes made:
- Formatting changes (tabs to spaces, DOS line endings etc).
- Simplified 'int_endianness.h' to work for our case.
- Added LLVM licence to the individual files.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Harry Liebel harry.lie...@arm.com
Reviewed-by: Olivier Martin olivier.mar...@arm.com
---
StdLib/LibC/LibC.inf | 2 +
StdLib/LibC/Main/Arm/fixunsdfsi.c | 74 +
StdLib/LibC/Main/Arm/floatunsidf.c| 71 +
StdLib/LibC/Main/Arm/fp_lib.h | 282 ++
StdLib/LibC/Main/Arm/int_endianness.h | 71 +
StdLib/LibC/Main/Arm/int_lib.h| 105 +
StdLib/LibC/Main/Arm/int_types.h | 170
StdLib/LibC/Main/Arm/int_util.h | 68
8 files changed, 843 insertions(+)
create mode 100644 StdLib/LibC/Main/Arm/fixunsdfsi.c
create mode 100644 StdLib/LibC/Main/Arm/floatunsidf.c
create mode 100644 StdLib/LibC/Main/Arm/fp_lib.h
create mode 100644 StdLib/LibC/Main/Arm/int_endianness.h
create mode 100644 StdLib/LibC/Main/Arm/int_lib.h
create mode 100644 StdLib/LibC/Main/Arm/int_types.h
create mode 100644 StdLib/LibC/Main/Arm/int_util.h
diff --git a/StdLib/LibC/LibC.inf b/StdLib/LibC/LibC.inf
index d8704db..e44d8a8 100644
--- a/StdLib/LibC/LibC.inf
+++ b/StdLib/LibC/LibC.inf
@@ -85,6 +85,8 @@
Main/Ipf/FpuRmode.s
[Sources.ARM]
+ Main/Arm/fixunsdfsi.c
+ Main/Arm/floatunsidf.c
Main/Arm/flt_rounds.c
[Binaries.IA32]
diff --git a/StdLib/LibC/Main/Arm/fixunsdfsi.c
b/StdLib/LibC/Main/Arm/fixunsdfsi.c
new file mode 100644
index 000..a63d220
--- /dev/null
+++ b/StdLib/LibC/Main/Arm/fixunsdfsi.c
@@ -0,0 +1,74 @@
+/**
+University of Illinois/NCSA
+Open Source License
+
+Copyright (c) 2009-2014 by the contributors listed in CREDITS.TXT
+
+All rights reserved.
+
+Developed by:
+
+LLVM Team
+
+University of Illinois at Urbana-Champaign
+
+http://llvm.org
+
+Permission is hereby granted, free of charge, to any person obtaining a copy of
+this software and associated documentation files (the Software), to deal with
+the Software without restriction, including without limitation the rights to
+use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies
+of the Software, and to permit persons to whom the Software is furnished to do
+so, subject to the following conditions:
+
+* Redistributions of source code must retain the above copyright notice,
+ this list of conditions and the following disclaimers.
+
+* Redistributions in binary form must reproduce the above copyright notice,
+ this list of conditions and the following disclaimers in the
+ documentation and/or other materials provided with the distribution.
+
+* Neither the names of the LLVM Team, University of Illinois at
+ Urbana-Champaign, nor the names of its contributors may be used to
+ endorse or promote products derived from this Software without specific
+ prior written permission.
+
+THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS
+FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+CONTRIBUTORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS WITH THE
+SOFTWARE.
+**/
+
+#include int_lib.h
+
+/* Returns: convert a to a unsigned int, rounding toward zero.
+ * Negative values all become zero.
+ */
+
+/* Assumption: double is a IEEE 64 bit floating point type
+ * su_int is a 32 bit integral type
+ * value in double is representable in su_int or is negative
+ * (no range checking performed)
+ */
+
+/* seee |
*/
+
+ARM_EABI_FNALIAS(d2uiz, fixunsdfsi)
+
+COMPILER_RT_ABI su_int
+__fixunsdfsi(double a)
+{
+double_bits fb;
+fb.f = a;
+int e = ((fb.u.s.high 0x7FF0) 20) - 1023;
+if (e 0 || (fb.u.s.high 0x8000))
+return 0;
+return (
+0x8000u |
+((fb.u.s.high 0x000F) 11) |
+(fb.u.s.low 21)
+ ) (31 - e);
+}
diff --git a/StdLib/LibC/Main/Arm/floatunsidf.c
b/StdLib/LibC/Main/Arm/floatunsidf.c
new file mode 100644
index 000..5f5fb1e
--- /dev/null
+++ b/StdLib/LibC/Main/Arm/floatunsidf.c
@@ -0,0 +1,71 @@
+/**
+University of Illinois/NCSA
+Open Source License
+
+Copyright (c) 2009-2014 by the contributors listed in CREDITS.TXT
+
+All rights reserved.
+
+Developed by:
+
+LLVM Team
+
+University of Illinois at Urbana-Champaign
+
+http://llvm.org
+
+Permission is hereby granted
[edk2] [PATCH 4/4] StdLib: Add support for AArch64
From: Brendan Jackman brendan.jack...@arm.com - Use some files from ARM version. - Use NetBSD software floating point library to provide floating point operations not handled directly by hardware floating point enabled GCC compiler. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Harry Liebel harry.lie...@arm.com Reviewed-by: Olivier Martin olivier.mar...@arm.com --- StdLib/Include/Aarch64/arm-gcc.h| 110 + StdLib/Include/Aarch64/machine/ansi.h | 106 StdLib/Include/Aarch64/machine/bswap.h | 13 + StdLib/Include/Aarch64/machine/byte_swap.h | 63 + StdLib/Include/Aarch64/machine/endian.h | 3 + StdLib/Include/Aarch64/machine/endian_machdep.h | 3 + StdLib/Include/Aarch64/machine/fenv.h | 39 +++ StdLib/Include/Aarch64/machine/float.h | 59 + StdLib/Include/Aarch64/machine/ieee.h | 31 +++ StdLib/Include/Aarch64/machine/ieeefp.h | 45 StdLib/Include/Aarch64/machine/int_const.h | 63 + StdLib/Include/Aarch64/machine/int_limits.h | 127 ++ StdLib/Include/Aarch64/machine/int_mwgwtypes.h | 82 ++ StdLib/Include/Aarch64/machine/int_types.h | 61 + StdLib/Include/Aarch64/machine/limits.h | 100 StdLib/Include/Aarch64/machine/math.h | 3 + StdLib/Include/Aarch64/machine/param.h | 124 ++ StdLib/Include/Aarch64/machine/signal.h | 22 ++ StdLib/Include/Aarch64/machine/types.h | 82 ++ StdLib/Include/Aarch64/milieu.h | 52 StdLib/Include/Aarch64/softfloat.h | 316 StdLib/LibC/LibC.inf| 3 + StdLib/LibC/Softfloat/Softfloat.inf | 11 +- StdLib/LibC/gdtoa/gdtoa.inf | 4 + StdLib/StdLib.dec | 3 + StdLib/StdLib.dsc | 2 +- StdLib/StdLib.inc | 3 + 27 files changed, 1528 insertions(+), 2 deletions(-) create mode 100644 StdLib/Include/Aarch64/arm-gcc.h create mode 100644 StdLib/Include/Aarch64/machine/ansi.h create mode 100644 StdLib/Include/Aarch64/machine/bswap.h create mode 100644 StdLib/Include/Aarch64/machine/byte_swap.h create mode 100644 StdLib/Include/Aarch64/machine/endian.h create mode 100644 StdLib/Include/Aarch64/machine/endian_machdep.h create mode 100644 StdLib/Include/Aarch64/machine/fenv.h create mode 100644 StdLib/Include/Aarch64/machine/float.h create mode 100644 StdLib/Include/Aarch64/machine/ieee.h create mode 100644 StdLib/Include/Aarch64/machine/ieeefp.h create mode 100644 StdLib/Include/Aarch64/machine/int_const.h create mode 100644 StdLib/Include/Aarch64/machine/int_limits.h create mode 100644 StdLib/Include/Aarch64/machine/int_mwgwtypes.h create mode 100644 StdLib/Include/Aarch64/machine/int_types.h create mode 100644 StdLib/Include/Aarch64/machine/limits.h create mode 100644 StdLib/Include/Aarch64/machine/math.h create mode 100644 StdLib/Include/Aarch64/machine/param.h create mode 100644 StdLib/Include/Aarch64/machine/signal.h create mode 100644 StdLib/Include/Aarch64/machine/types.h create mode 100644 StdLib/Include/Aarch64/milieu.h create mode 100644 StdLib/Include/Aarch64/softfloat.h diff --git a/StdLib/Include/Aarch64/arm-gcc.h b/StdLib/Include/Aarch64/arm-gcc.h new file mode 100644 index 000..ef0014b --- /dev/null +++ b/StdLib/Include/Aarch64/arm-gcc.h @@ -0,0 +1,110 @@ +/** @file + + Copyright (c) 2014, ARM Limited. All rights reserved. + + This program and the accompanying materials + are licensed and made available under the terms and conditions of the BSD License + which accompanies this distribution. The full text of the license may be found at + http://opensource.org/licenses/bsd-license.php + + THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN AS IS BASIS, + WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED. + +**/ + +/* $NetBSD: arm-gcc.h,v 1.4 2013/01/26 07:08:14 matt Exp $ */ + +/* +--- +One of the macros `BIGENDIAN' or `LITTLEENDIAN' must be defined. +--- +*/ +#define LITTLEENDIAN + +/* +--- +The macro `BITS64' can be defined to indicate that 64-bit integer types are +supported by the compiler. +--- +*/ +#define BITS64 + +/* +--- +Each of the following `typedef's defines the most convenient type that holds +integers of at least as many bits as specified. For example, `uint8' should +be the most convenient type that can hold unsigned integers of as many as +8 bits
[edk2] [PATCH 0/4] StdLib: Add ARM SoftFloat AArch64 supports
This patchset adds support for ARM SoftFloat. ARM Hardware floating point is disabled when building UEFI Firmware. Software Floating point is required to get full StdLib support. This support also adds AArch64 support. Contributed-under: TianoCore Contribution Agreement 1.0 Reviewed-by: Olivier Martin olivier.mar...@arm.com Brendan Jackman (1): StdLib: Add support for AArch64 Harry Liebel (2): StdLib/LibC: Add software floating point library from NetBSD StdLib/LibC: Provide missing ARM symbols Olivier Martin (1): StdLib: Added BaseStackLib for ARM architectures StdLib/Include/Aarch64/arm-gcc.h | 110 + StdLib/Include/Aarch64/machine/ansi.h | 106 + StdLib/Include/Aarch64/machine/bswap.h | 13 + StdLib/Include/Aarch64/machine/byte_swap.h | 63 + StdLib/Include/Aarch64/machine/endian.h|3 + StdLib/Include/Aarch64/machine/endian_machdep.h|3 + StdLib/Include/Aarch64/machine/fenv.h | 39 + StdLib/Include/Aarch64/machine/float.h | 59 + StdLib/Include/Aarch64/machine/ieee.h | 31 + StdLib/Include/Aarch64/machine/ieeefp.h| 45 + StdLib/Include/Aarch64/machine/int_const.h | 63 + StdLib/Include/Aarch64/machine/int_limits.h| 127 + StdLib/Include/Aarch64/machine/int_mwgwtypes.h | 82 + StdLib/Include/Aarch64/machine/int_types.h | 61 + StdLib/Include/Aarch64/machine/limits.h| 100 + StdLib/Include/Aarch64/machine/math.h |3 + StdLib/Include/Aarch64/machine/param.h | 124 + StdLib/Include/Aarch64/machine/signal.h| 22 + StdLib/Include/Aarch64/machine/types.h | 82 + StdLib/Include/Aarch64/milieu.h| 52 + StdLib/Include/Aarch64/softfloat.h | 316 ++ StdLib/Include/Arm/arm-gcc.h | 114 + StdLib/Include/Arm/machine/fenv.h | 55 + StdLib/Include/Arm/machine/ieeefp.h| 58 + StdLib/Include/Arm/milieu.h| 38 + StdLib/Include/Arm/softfloat.h | 316 ++ StdLib/Include/ieeefp.h| 46 + StdLib/LibC/LibC.inf |5 + StdLib/LibC/Main/Arm/fixunsdfsi.c | 74 + StdLib/LibC/Main/Arm/floatunsidf.c | 71 + StdLib/LibC/Main/Arm/fp_lib.h | 282 + StdLib/LibC/Main/Arm/int_endianness.h | 71 + StdLib/LibC/Main/Arm/int_lib.h | 105 + StdLib/LibC/Main/Arm/int_types.h | 170 + StdLib/LibC/Main/Arm/int_util.h| 68 + StdLib/LibC/Softfloat/Arm/__aeabi_dcmpeq.c | 37 + StdLib/LibC/Softfloat/Arm/__aeabi_dcmpge.c | 35 + StdLib/LibC/Softfloat/Arm/__aeabi_dcmpgt.c | 37 + StdLib/LibC/Softfloat/Arm/__aeabi_dcmple.c | 37 + StdLib/LibC/Softfloat/Arm/__aeabi_dcmplt.c | 37 + StdLib/LibC/Softfloat/Arm/__aeabi_dcmpun.c | 42 + StdLib/LibC/Softfloat/Arm/__aeabi_fcmpeq.c | 37 + StdLib/LibC/Softfloat/Arm/__aeabi_fcmpge.c | 37 + StdLib/LibC/Softfloat/Arm/__aeabi_fcmpgt.c | 37 + StdLib/LibC/Softfloat/Arm/__aeabi_fcmple.c | 37 + StdLib/LibC/Softfloat/Arm/__aeabi_fcmplt.c | 37 + StdLib/LibC/Softfloat/Arm/__aeabi_fcmpun.c | 42 + StdLib/LibC/Softfloat/Makefile.inc | 42 + StdLib/LibC/Softfloat/README.NetBSD|8 + StdLib/LibC/Softfloat/README.txt | 39 + StdLib/LibC/Softfloat/Softfloat.inf| 74 + StdLib/LibC/Softfloat/bits32/softfloat-macros | 648 +++ StdLib/LibC/Softfloat/bits32/softfloat.c | 2355 StdLib/LibC/Softfloat/bits64/softfloat-macros | 745 +++ StdLib/LibC/Softfloat/bits64/softfloat.c | 5602 StdLib/LibC/Softfloat/eqdf2.c | 38 + StdLib/LibC/Softfloat/eqsf2.c | 38 + StdLib/LibC/Softfloat/eqtf2.c | 40 + StdLib/LibC/Softfloat/fpgetmask.c | 55 + StdLib/LibC/Softfloat/fpgetround.c | 55 + StdLib/LibC/Softfloat/fpgetsticky.c| 55 + StdLib/LibC/Softfloat/fpsetmask.c | 60 + StdLib/LibC/Softfloat/fpsetround.c | 60 + StdLib/LibC/Softfloat/fpsetsticky.c| 60 + StdLib/LibC/Softfloat/gedf2.c | 38 + StdLib/LibC/Softfloat/gesf2.c | 38 + StdLib/LibC/Softfloat/getf2.c | 40 + StdLib/LibC/Softfloat/gexf2.c | 39 + StdLib/LibC/Softfloat/gtdf2.c | 36 + StdLib/LibC/Softfloat/gtsf2.c | 36 + StdLib/LibC/Softfloat/gttf2.c | 40 + StdLib/LibC/Softfloat/gtxf2.c
[edk2] [PATCH 1/4] StdLib: Added BaseStackLib for ARM architectures
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Olivier Martin olivier.mar...@arm.com Reviewed-by: Ronald Cron ronald.c...@arm.com --- StdLib/StdLib.inc | 6 ++ 1 file changed, 6 insertions(+) diff --git a/StdLib/StdLib.inc b/StdLib/StdLib.inc index 1b7fcf0..391c7c9 100644 --- a/StdLib/StdLib.inc +++ b/StdLib/StdLib.inc @@ -73,9 +73,15 @@ [LibraryClasses.ARM] NULL|ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib.inf + # Add support for GCC stack protector + NULL|MdePkg/Library/BaseStackCheckLib/BaseStackCheckLib.inf + [LibraryClasses.AArch64] NULL|ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib.inf + # Add support for GCC stack protector + NULL|MdePkg/Library/BaseStackCheckLib/BaseStackCheckLib.inf + [Components] # BaseLib and BaseMemoryLib need to be built with the /GL- switch when using the Microsoft # tool chain. This is required so that the library functions can be resolved during -- 2.1.1 -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
[edk2] [PATCH 2/2] MdeModulePkg/EhciDxe: Do not process a same URB twice
After changing the USB stack to make it synchronous at initialization,
we were checking if there was a pending interrupt when the USB interrupt
was initialized for a specific device.
At the first enumeration, all the connected USB devices are initialized.
USB device drivers initialize their USB interrupt and process the completed
URBs. There was no way to check if a URB was in process because before
there was a single periodic task to process these URBs.
Note: this change is only required when using the temporary hack to make
the USB stack synchronous.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Olivier Martin olivier.mar...@arm.com
---
MdeModulePkg/Bus/Pci/EhciDxe/EhciSched.c | 9 +
MdeModulePkg/Bus/Pci/EhciDxe/EhciUrb.c | 1 +
MdeModulePkg/Bus/Pci/EhciDxe/EhciUrb.h | 3 ++-
3 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/MdeModulePkg/Bus/Pci/EhciDxe/EhciSched.c
b/MdeModulePkg/Bus/Pci/EhciDxe/EhciSched.c
index 5594e66..cc6e77e 100644
--- a/MdeModulePkg/Bus/Pci/EhciDxe/EhciSched.c
+++ b/MdeModulePkg/Bus/Pci/EhciDxe/EhciSched.c
@@ -573,6 +573,12 @@ EhcCheckUrbResult (
ASSERT ((Ehc != NULL) (Urb != NULL) (Urb-Qh != NULL));
+ // The URB is already being processed, we do not want the callback to be
+ // called twice for the same URB
+ if (Urb-InProgress) {
+return FALSE;
+ }
+
Finished= TRUE;
Urb-Completed = 0;
@@ -992,6 +998,9 @@ EhcMonitorAsyncRequests (
continue;
}
+// Mark the URB as 'in-progress' to prevent the URB to be processed twice.
+Urb-InProgress = TRUE;
+
//
// Flush any PCI posted write transactions from a PCI host
// bridge to system memory.
diff --git a/MdeModulePkg/Bus/Pci/EhciDxe/EhciUrb.c
b/MdeModulePkg/Bus/Pci/EhciDxe/EhciUrb.c
index 6afb327..1ad37d5 100644
--- a/MdeModulePkg/Bus/Pci/EhciDxe/EhciUrb.c
+++ b/MdeModulePkg/Bus/Pci/EhciDxe/EhciUrb.c
@@ -600,6 +600,7 @@ EhcCreateUrb (
Urb-DataLen= DataLen;
Urb-Callback = Callback;
Urb-Context= Context;
+ Urb-InProgress = FALSE;
PciIo = Ehc-PciIo;
Urb-Qh = EhcCreateQh (Ehc, Urb-Ep);
diff --git a/MdeModulePkg/Bus/Pci/EhciDxe/EhciUrb.h
b/MdeModulePkg/Bus/Pci/EhciDxe/EhciUrb.h
index 02e9af8..0c80e76 100644
--- a/MdeModulePkg/Bus/Pci/EhciDxe/EhciUrb.h
+++ b/MdeModulePkg/Bus/Pci/EhciDxe/EhciUrb.h
@@ -232,7 +232,8 @@ struct _URB {
// Transaction result
//
UINT32 Result;
- UINTN Completed;// completed data length
+ BOOLEAN InProgress; // defined when the URB is
being processed
+ UINTN Completed;// Length of the data being
processed
UINT8 DataToggle;
};
--
2.1.1
--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
[edk2] [PATCH 1/2] MdeModulePkg/Usb: Force the USB initialization to be synchronous
The USB stack uses BS.SignalEvent and Timer event to initialize the USB stack. It means a USB device initialization might not be completed when returning from BS.ConnectController(). This behaviour is not compliant with the UEFI spec. This change is only a _temporary hack_ as it forces the enumeration of the entire USB bus when the USB Root Hub is initialized which makes this solution non optimal. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Olivier Martin olivier.mar...@arm.com --- MdeModulePkg/Bus/Pci/EhciDxe/Ehci.c | 6 ++ MdeModulePkg/Bus/Usb/UsbBusDxe/UsbHub.c | 11 +-- 2 files changed, 15 insertions(+), 2 deletions(-) mode change 100644 = 100755 MdeModulePkg/Bus/Pci/EhciDxe/Ehci.c mode change 100644 = 100755 MdeModulePkg/Bus/Usb/UsbBusDxe/UsbHub.c diff --git a/MdeModulePkg/Bus/Pci/EhciDxe/Ehci.c b/MdeModulePkg/Bus/Pci/EhciDxe/Ehci.c old mode 100644 new mode 100755 index 315f2cb..edde95f --- a/MdeModulePkg/Bus/Pci/EhciDxe/Ehci.c +++ b/MdeModulePkg/Bus/Pci/EhciDxe/Ehci.c @@ -1095,6 +1095,12 @@ EhcAsyncInterruptTransfer ( EhcLinkQhToPeriod (Ehc, Urb-Qh); InsertHeadList (Ehc-AsyncIntTransfers, Urb-UrbList); + // ARM: Force an asynchonous transfer after waiting an interval + // Polling interval is in milliseconds while BS.Stall except + // Microseconds. + gBS-Stall (PollingInterval * 1000); + EhcMonitorAsyncRequests (Ehc-PollTimer, Ehc); + ON_EXIT: Ehc-PciIo-Flush (Ehc-PciIo); gBS-RestoreTPL (OldTpl); diff --git a/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbHub.c b/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbHub.c old mode 100644 new mode 100755 index e3752d1..be07a74 --- a/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbHub.c +++ b/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbHub.c @@ -668,7 +668,10 @@ UsbOnHubInterrupt ( } CopyMem (HubIf-ChangeMap, Data, DataLength); - gBS-SignalEvent (HubIf-HubNotify); + + //ARM: We do not use BS.SignalEvent in order to initialize the new device immediately + //gBS-SignalEvent (HubIf-HubNotify); + UsbHubEnumeration (HubIf-HubNotify, HubIf); return EFI_SUCCESS; } @@ -1112,7 +1115,11 @@ UsbRootHubInit ( // It should signal the event immediately here, or device detection // by bus enumeration might be delayed by the timer interval. // - gBS-SignalEvent (HubIf-HubNotify); + + //ARM: We invoke the function directly to ensure the enumeration is + // done immediately. + //gBS-SignalEvent (HubIf-HubNotify); + UsbRootHubEnumeration (NULL, HubIf); Status = gBS-SetTimer ( HubIf-HubNotify, -- 2.1.1 -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
[edk2] [PATCH 0/2] [Bug Workaround] Fix USB stack when calling ConnectController with a USB device Device Path
The current USB stack is broken when you call BS.ConnectController() with a USB device Device Path for instance like PciRoot(0)/PCI(31,2)/USB(1,0)/USB(3,0) The issue is not new and has probably always existed. What the UEFI specification says about EFI_DRIVER_BINDING_PROTOCOL.Start(): If the driver specified by This is a bus driver that is capable of creating one child handle at a time and RemainingDevicePath is not NULL and does not begin with the End of Device Path node, then an attempt is made to create the device handle for the child device specified by RemainingDevicePath. Depending on the bus type, all of the child devices may need to be discovered and enumerated, but at most only the device handle for the one child specified by RemainingDevicePath shall be created. Source: 10.1 EFI Driver Binding Protocol (UEFI spec 2.5) With the current USB stack implementation, BS.ConnectController() would return EFI_SUCCESS without having connecting 'USB(3,0)'. The reason is the USB stack initialization is based on Timer Event. The initialization and the creation of USB(3,0) device node would happen asynchronously. The reason why the issue has not been highlighted earlier is because people tend to 'connect' all the drivers when they start the Intel BDS. These initializations take time. And it is likely all the timer based initialization are completed by the end of ConnectAllControllers(). The design choice I made for the ARM BDS is to only start the required devices (ie: the console devices). This USB issue appears straight away in this use case. My workaround is to replace gBS-SignalEvent() by direct calls to the functions that should have replied to these events. The patch is not perfect. I was told USB Hub are not enumerated correctly. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Olivier Martin olivier.mar...@arm.com Olivier Martin (2): MdeModulePkg/Usb: Force the USB initialization to be synchronous MdeModulePkg/EhciDxe: Do not process a same URB twice MdeModulePkg/Bus/Pci/EhciDxe/Ehci.c | 6 ++ MdeModulePkg/Bus/Pci/EhciDxe/EhciSched.c | 9 + MdeModulePkg/Bus/Pci/EhciDxe/EhciUrb.c | 1 + MdeModulePkg/Bus/Pci/EhciDxe/EhciUrb.h | 3 ++- MdeModulePkg/Bus/Usb/UsbBusDxe/UsbHub.c | 11 +-- 5 files changed, 27 insertions(+), 3 deletions(-) mode change 100644 = 100755 MdeModulePkg/Bus/Pci/EhciDxe/Ehci.c mode change 100644 = 100755 MdeModulePkg/Bus/Usb/UsbBusDxe/UsbHub.c -- 2.1.1 -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
[edk2] [PATCH 1/2] MdeModulePkg/Usb: Force the USB initialization to be synchronous
The USB stack uses BS.SignalEvent and Timer event to initialize the USB stack. It means a USB device initialization might not be completed when returning from BS.ConnectController(). This behaviour is not compliant with the UEFI spec. This change is only a _temporary hack_ as it forces the enumeration of the entire USB bus when the USB Root Hub is initialized which makes this solution non optimal. Change-Id: I7d569f0cff9bd7780f9949a6cad93fd1eb669f5b --- MdeModulePkg/Bus/Pci/EhciDxe/Ehci.c | 6 ++ MdeModulePkg/Bus/Usb/UsbBusDxe/UsbHub.c | 11 +-- 2 files changed, 15 insertions(+), 2 deletions(-) mode change 100644 = 100755 MdeModulePkg/Bus/Pci/EhciDxe/Ehci.c mode change 100644 = 100755 MdeModulePkg/Bus/Usb/UsbBusDxe/UsbHub.c diff --git a/MdeModulePkg/Bus/Pci/EhciDxe/Ehci.c b/MdeModulePkg/Bus/Pci/EhciDxe/Ehci.c old mode 100644 new mode 100755 index 315f2cb..edde95f --- a/MdeModulePkg/Bus/Pci/EhciDxe/Ehci.c +++ b/MdeModulePkg/Bus/Pci/EhciDxe/Ehci.c @@ -1095,6 +1095,12 @@ EhcAsyncInterruptTransfer ( EhcLinkQhToPeriod (Ehc, Urb-Qh); InsertHeadList (Ehc-AsyncIntTransfers, Urb-UrbList); + // ARM: Force an asynchonous transfer after waiting an interval + // Polling interval is in milliseconds while BS.Stall except + // Microseconds. + gBS-Stall (PollingInterval * 1000); + EhcMonitorAsyncRequests (Ehc-PollTimer, Ehc); + ON_EXIT: Ehc-PciIo-Flush (Ehc-PciIo); gBS-RestoreTPL (OldTpl); diff --git a/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbHub.c b/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbHub.c old mode 100644 new mode 100755 index e3752d1..be07a74 --- a/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbHub.c +++ b/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbHub.c @@ -668,7 +668,10 @@ UsbOnHubInterrupt ( } CopyMem (HubIf-ChangeMap, Data, DataLength); - gBS-SignalEvent (HubIf-HubNotify); + + //ARM: We do not use BS.SignalEvent in order to initialize the new device immediately + //gBS-SignalEvent (HubIf-HubNotify); + UsbHubEnumeration (HubIf-HubNotify, HubIf); return EFI_SUCCESS; } @@ -1112,7 +1115,11 @@ UsbRootHubInit ( // It should signal the event immediately here, or device detection // by bus enumeration might be delayed by the timer interval. // - gBS-SignalEvent (HubIf-HubNotify); + + //ARM: We invoke the function directly to ensure the enumeration is + // done immediately. + //gBS-SignalEvent (HubIf-HubNotify); + UsbRootHubEnumeration (NULL, HubIf); Status = gBS-SetTimer ( HubIf-HubNotify, -- 2.1.1 -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
[edk2] [PATCH 2/2] MdeModulePkg/EhciDxe: Do not process a same URB twice
After changing the USB stack to make it synchronous at initialization,
we were checking if there was a pending interrupt when the USB interrupt
was initialized for a specific device.
At the first enumeration, all the connected USB devices are initialized.
USB device drivers initialize their USB interrupt and process the completed
URBs. There was no way to check if a URB was in process because before
there was a single periodic task to process these URBs.
Note: this change is only required when using the temporary hack to make
the USB stack synchronous.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Olivier Martin olivier.mar...@arm.com
---
MdeModulePkg/Bus/Pci/EhciDxe/EhciSched.c | 9 +
MdeModulePkg/Bus/Pci/EhciDxe/EhciUrb.c | 1 +
MdeModulePkg/Bus/Pci/EhciDxe/EhciUrb.h | 3 ++-
3 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/MdeModulePkg/Bus/Pci/EhciDxe/EhciSched.c
b/MdeModulePkg/Bus/Pci/EhciDxe/EhciSched.c
index 5594e66..cc6e77e 100644
--- a/MdeModulePkg/Bus/Pci/EhciDxe/EhciSched.c
+++ b/MdeModulePkg/Bus/Pci/EhciDxe/EhciSched.c
@@ -573,6 +573,12 @@ EhcCheckUrbResult (
ASSERT ((Ehc != NULL) (Urb != NULL) (Urb-Qh != NULL));
+ // The URB is already being processed, we do not want the callback to be
+ // called twice for the same URB
+ if (Urb-InProgress) {
+return FALSE;
+ }
+
Finished= TRUE;
Urb-Completed = 0;
@@ -992,6 +998,9 @@ EhcMonitorAsyncRequests (
continue;
}
+// Mark the URB as 'in-progress' to prevent the URB to be processed twice.
+Urb-InProgress = TRUE;
+
//
// Flush any PCI posted write transactions from a PCI host
// bridge to system memory.
diff --git a/MdeModulePkg/Bus/Pci/EhciDxe/EhciUrb.c
b/MdeModulePkg/Bus/Pci/EhciDxe/EhciUrb.c
index 6afb327..1ad37d5 100644
--- a/MdeModulePkg/Bus/Pci/EhciDxe/EhciUrb.c
+++ b/MdeModulePkg/Bus/Pci/EhciDxe/EhciUrb.c
@@ -600,6 +600,7 @@ EhcCreateUrb (
Urb-DataLen= DataLen;
Urb-Callback = Callback;
Urb-Context= Context;
+ Urb-InProgress = FALSE;
PciIo = Ehc-PciIo;
Urb-Qh = EhcCreateQh (Ehc, Urb-Ep);
diff --git a/MdeModulePkg/Bus/Pci/EhciDxe/EhciUrb.h
b/MdeModulePkg/Bus/Pci/EhciDxe/EhciUrb.h
index 02e9af8..0c80e76 100644
--- a/MdeModulePkg/Bus/Pci/EhciDxe/EhciUrb.h
+++ b/MdeModulePkg/Bus/Pci/EhciDxe/EhciUrb.h
@@ -232,7 +232,8 @@ struct _URB {
// Transaction result
//
UINT32 Result;
- UINTN Completed;// completed data length
+ BOOLEAN InProgress; // defined when the URB is
being processed
+ UINTN Completed;// Length of the data being
processed
UINT8 DataToggle;
};
--
2.1.1
--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
[edk2] Farewell - last days at ARM Ltd
For people who does not know me I have been the EDK2 maintainer of the ARM Packages for the last 4 years. I took over the excellent work Andrew Fish and Eugene Cohen started few years before. This week was my last week at ARM - my last day would be on Friday 17th (UK time). I have been learning a lot thanks to the UEFI community. Being the ARM maintainer has been a great opportunity. I also had the chance to go to few conferences to discuss and present my work and meet few of you as part of my job. I have been asked last week what is the new exciting place that makes me leave ARM. The answer is my own future start-up... I love challenges and I think this one is definitely one of the highest one I could find. It is actually quite scary but I am quite excited! I could potentially have kept my role of EDK2 ARM maintainer with me but I would prefer to give the task to Leif Lindholm who has been a co-maintainer for almost two months. So I could fully focus on my new adventure. Leif has been seating not far from me in the ARM office. We have also had regular meetings about UEFI. He has been at ARM Ltd longer than me and been involved in different Open Source projects. He has also been working on UEFI for Linaro for few (three?) years now. I have been trying to publish as much work as I can on the work I have done on UEFI for the last 5 years and half at ARM Ltd in the last two weeks. Unfortunately, I am not sure I will have time to publish everything. But I will do my best to publish the most important bits... Unfortunately, it is still too early to share more details about my future product, so I created a quick website (and found a neutral name) last week-end to allow people to follow the adventure: http://labapart.com/ (can either be pronounced as Lab apart or Lab à Part). If you would like to contact me, email me here: olivier.martin...@gmail.com and/or linkedin me: http://www.linkedin.com/in/olivierm. Cheers, Olivier -- 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. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2548782 -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] [PATCH] ShellPkg: Add optional 'tftp' EFI Shell command.
I have just sent a new version that add a comment to say why we used
BS.AllocatePage() and not AllocatePool().
And I have also replaced Print() by ShellPrintEx().
Let me know if you are still happy with these new changes.
-Original Message-
From: Carsey, Jaben [mailto:jaben.car...@intel.com]
Sent: 15 July 2015 15:18
To: Olivier Martin; Qiu, Shumin
Cc: edk2-devel@lists.sourceforge.net; Ronald Cron; Ronald Cron; Carsey,
Jaben
Subject: RE: [PATCH] ShellPkg: Add optional 'tftp' EFI Shell command.
Reviewed-by: Jaben carsey jaben.car...@intel.com
-Original Message-
From: Olivier Martin [mailto:olivier.mar...@arm.com]
Sent: Wednesday, July 15, 2015 2:32 AM
To: Carsey, Jaben; Qiu, Shumin
Cc: edk2-devel@lists.sourceforge.net; Ronald Cron; Ronald Cron
Subject: RE: [PATCH] ShellPkg: Add optional 'tftp' EFI Shell command.
Importance: High
Thanks Jaben for the quick feedback. I replied in line.
-Original Message-
From: Carsey, Jaben [mailto:jaben.car...@intel.com]
Sent: 15 July 2015 00:07
To: Olivier Martin; Qiu, Shumin
Cc: edk2-devel@lists.sourceforge.net; Ronald Cron; Ronald Cron; Carsey,
Jaben
Subject: RE: [PATCH] ShellPkg: Add optional 'tftp' EFI Shell command.
Generally good. 2 questions below.
-Original Message-
From: Olivier Martin [mailto:olivier.mar...@arm.com]
Sent: Tuesday, July 14, 2015 8:47 AM
To: Carsey, Jaben; Qiu, Shumin
Cc: edk2-devel@lists.sourceforge.net; Ronald Cron; Ronald Cron
Subject: [PATCH] ShellPkg: Add optional 'tftp' EFI Shell command.
Importance: High
From: Ronald Cron ronald.c...@arm.com
This 'tftp' command allows to download a file from a TFTP server.
A specific network interface can be chosen in case there are multiple
interfaces.
Change-Id: I07887ac2c3eeb52b871f493582f7612c41398f09
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ronald Cron ronald.c...@arm.com
Reviewed-by: Olivier Martin olivier.mar...@arm.com
---
ShellPkg/Include/Guid/ShellLibHiiGuid.h| 7 +
ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c| 875
+
.../UefiShellTftpCommandLib.c | 97 +++
.../UefiShellTftpCommandLib.h | 63 ++
.../UefiShellTftpCommandLib.inf| 61 ++
.../UefiShellTftpCommandLib.uni| Bin 0 - 8748 bytes
ShellPkg/ShellPkg.dec | 1 +
ShellPkg/ShellPkg.dsc | 3 +
8 files changed, 1107 insertions(+)
create mode 100644 ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c
create mode 100644
ShellPkg/Library/UefiShellTftpCommandLib/UefiShellTftpCommandLib.c
create mode 100644
ShellPkg/Library/UefiShellTftpCommandLib/UefiShellTftpCommandLib.h
create mode 100644
ShellPkg/Library/UefiShellTftpCommandLib/UefiShellTftpCommandLib.inf
create mode 100644
ShellPkg/Library/UefiShellTftpCommandLib/UefiShellTftpCommandLib.uni
diff --git a/ShellPkg/Include/Guid/ShellLibHiiGuid.h
b/ShellPkg/Include/Guid/ShellLibHiiGuid.h
index dc694f2..62c2e72 100644
--- a/ShellPkg/Include/Guid/ShellLibHiiGuid.h
+++ b/ShellPkg/Include/Guid/ShellLibHiiGuid.h
@@ -54,6 +54,12 @@
{ \
0xf3d301bb, 0xf4a5, 0x45a8, { 0xb0, 0xb7, 0xfa, 0x99, 0x9c, 0x62,
0x37, 0xae } \
}
+#define SHELL_TFTP_HII_GUID \
+ { \
+0x738a9314, 0x82c1, 0x4592, { 0x8f, 0xf7, 0xc1, 0xbd, 0xf1, 0xb2,
+0x0e,
0xd4 } \
+ }
+
+
#define SHELL_BCFG_HII_GUID \
{ \
0x5f5f605d, 0x1583, 0x4a2d, {0xa6, 0xb2, 0xeb, 0x12, 0xda, 0xb4,
0xa2,
0xb6 } \
@@ -67,6 +73,7 @@ extern EFI_GUID gShellLevel1HiiGuid; extern
EFI_GUID gShellLevel2HiiGuid; extern EFI_GUID gShellLevel3HiiGuid;
extern EFI_GUID gShellNetwork1HiiGuid;
+extern EFI_GUID gShellTftpHiiGuid;
extern EFI_GUID gShellBcfgHiiGuid;
#endif
diff --git a/ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c
b/ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c
new file mode 100644
index 000..84401d8
--- /dev/null
+++ b/ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c
@@ -0,0 +1,875 @@
+/** @file
+ The implementation for the 'tftp' Shell command.
+
+ Copyright (c) 2015, ARM Ltd. All rights reserved.BR
+
+ This program and the accompanying materials are licensed and made
+ available under the terms and conditions of the BSD
License
+ which accompanies this distribution. The full text of the license
+ may be
found at
+ http://opensource.org/licenses/bsd-license.php.
+
+ THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN AS
IS
BASIS,
+ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
EXPRESS OR IMPLIED.
+**/
+
+#include UefiShellTftpCommandLib.h
+
+/*
+ Constant strings and definitions related to the message indicating
[edk2] [PATCH V2] ShellPkg: Add optional 'tftp' EFI Shell command.
From: Ronald Cron ronald.c...@arm.com
This 'tftp' command allows to download a file from a TFTP server.
A specific network interface can be chosen in case there are multiple
interfaces.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ronald Cron ronald.c...@arm.com
Reviewed-by: Olivier Martin olivier.mar...@arm.com
---
ShellPkg/Include/Guid/ShellLibHiiGuid.h| 7 +
ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c| 880 +
.../UefiShellTftpCommandLib.c | 97 +++
.../UefiShellTftpCommandLib.h | 63 ++
.../UefiShellTftpCommandLib.inf| 61 ++
.../UefiShellTftpCommandLib.uni| Bin 0 - 8748 bytes
ShellPkg/ShellPkg.dec | 1 +
ShellPkg/ShellPkg.dsc | 3 +
8 files changed, 1112 insertions(+)
create mode 100644 ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c
create mode 100644
ShellPkg/Library/UefiShellTftpCommandLib/UefiShellTftpCommandLib.c
create mode 100644
ShellPkg/Library/UefiShellTftpCommandLib/UefiShellTftpCommandLib.h
create mode 100644
ShellPkg/Library/UefiShellTftpCommandLib/UefiShellTftpCommandLib.inf
create mode 100644
ShellPkg/Library/UefiShellTftpCommandLib/UefiShellTftpCommandLib.uni
diff --git a/ShellPkg/Include/Guid/ShellLibHiiGuid.h
b/ShellPkg/Include/Guid/ShellLibHiiGuid.h
index dc694f2..62c2e72 100644
--- a/ShellPkg/Include/Guid/ShellLibHiiGuid.h
+++ b/ShellPkg/Include/Guid/ShellLibHiiGuid.h
@@ -54,6 +54,12 @@
{ \
0xf3d301bb, 0xf4a5, 0x45a8, { 0xb0, 0xb7, 0xfa, 0x99, 0x9c, 0x62, 0x37,
0xae } \
}
+#define SHELL_TFTP_HII_GUID \
+ { \
+0x738a9314, 0x82c1, 0x4592, { 0x8f, 0xf7, 0xc1, 0xbd, 0xf1, 0xb2, 0x0e,
0xd4 } \
+ }
+
+
#define SHELL_BCFG_HII_GUID \
{ \
0x5f5f605d, 0x1583, 0x4a2d, {0xa6, 0xb2, 0xeb, 0x12, 0xda, 0xb4, 0xa2,
0xb6 } \
@@ -67,6 +73,7 @@ extern EFI_GUID gShellLevel1HiiGuid;
extern EFI_GUID gShellLevel2HiiGuid;
extern EFI_GUID gShellLevel3HiiGuid;
extern EFI_GUID gShellNetwork1HiiGuid;
+extern EFI_GUID gShellTftpHiiGuid;
extern EFI_GUID gShellBcfgHiiGuid;
#endif
diff --git a/ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c
b/ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c
new file mode 100644
index 000..b872afd
--- /dev/null
+++ b/ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c
@@ -0,0 +1,880 @@
+/** @file
+ The implementation for the 'tftp' Shell command.
+
+ Copyright (c) 2015, ARM Ltd. All rights reserved.BR
+
+ This program and the accompanying materials
+ are licensed and made available under the terms and conditions of the BSD
License
+ which accompanies this distribution. The full text of the license may be
found at
+ http://opensource.org/licenses/bsd-license.php.
+
+ THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN AS IS BASIS,
+ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+**/
+
+#include UefiShellTftpCommandLib.h
+
+/*
+ Constant strings and definitions related to the message indicating the
amount of
+ progress in the dowloading of a TFTP file.
+*/
+
+// Frame for the progression slider
+STATIC CONST CHAR16 mTftpProgressFrame[] = L[
];
+
+// Number of steps in the progression slider
+#define TFTP_PROGRESS_SLIDER_STEPS ((sizeof (mTftpProgressFrame) / sizeof
(CHAR16)) - 3)
+
+// Size in number of characters plus one (final zero) of the message to
+// indicate the progress of a TFTP download. The format is [(progress slider:
+// 40 characters)] (nb of KBytes downloaded so far: 7 characters) Kb. There
+// are thus the number of characters in mTftpProgressFrame[] plus 11 characters
+// (2 // spaces, Kb and seven characters for the number of KBytes).
+#define TFTP_PROGRESS_MESSAGE_SIZE ((sizeof (mTftpProgressFrame) / sizeof
(CHAR16)) + 12)
+
+// String to delete the TFTP progress message to be able to update it :
+// (TFTP_PROGRESS_MESSAGE_SIZE-1) '\b'
+STATIC CONST CHAR16 mTftpProgressDelete[] =
L\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b;
+
+STATIC BOOLEAN StringToUint16 (
+ IN CONST CHAR16 *ValueStr,
+ OUT UINT16*Value
+ );
+
+STATIC EFI_STATUS GetNicName (
+ IN EFI_HANDLE ControllerHandle,
+ IN UINTN Index,
+ OUT CHAR16 *NicName
+ );
+
+STATIC EFI_STATUS CreateServiceChildAndOpenProtocol (
+ IN EFI_HANDLE ControllerHandle,
+ IN EFI_GUID*ServiceBindingProtocolGuid,
+ IN EFI_GUID*ProtocolGuid,
+ OUT EFI_HANDLE *ChildHandle,
+ OUT VOID**Interface
+ );
+
+STATIC VOID CloseProtocolAndDestroyServiceChild (
+ IN EFI_HANDLE ControllerHandle,
+ IN EFI_GUID*ServiceBindingProtocolGuid,
+ IN EFI_GUID*ProtocolGuid,
+ IN EFI_HANDLE ChildHandle
+ );
+
+STATIC EFI_STATUS GetFileSize (
+ IN EFI_MTFTP4_PROTOCOL *Mtftp4,
+ IN CONST CHAR8 *FilePath,
+ OUT UINTN
[edk2] [PATCH V2 04/10] ArmPkg/BdsLib: Remove Linux loader from BdsLib
This change removes the embedded Linux Loder from BdsLib. BdsLib becomes OS agnostic. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Olivier Martin olivier.mar...@arm.com Reviewed-by: Ronald Cron ronald.c...@arm.com --- ArmPkg/Include/Library/BdsLib.h| 37 -- ArmPkg/Library/BdsLib/AArch64/BdsLinuxLoader.c | 355 - .../Library/BdsLib/AArch64/BdsLinuxLoaderHelper.S | 58 --- ArmPkg/Library/BdsLib/Arm/BdsLinuxAtag.c | 173 --- ArmPkg/Library/BdsLib/Arm/BdsLinuxLoader.c | 323 ArmPkg/Library/BdsLib/BdsHelper.c | 178 +-- ArmPkg/Library/BdsLib/BdsInternal.h| 13 - ArmPkg/Library/BdsLib/BdsLib.inf | 38 -- ArmPkg/Library/BdsLib/BdsLinuxFdt.c| 572 - ArmPkg/Library/BdsLib/BdsLinuxLoader.h | 156 -- ArmPlatformPkg/Bds/Bds.inf | 4 + ArmPlatformPkg/Bds/BootOption.c| 35 +- 12 files changed, 8 insertions(+), 1934 deletions(-) delete mode 100644 ArmPkg/Library/BdsLib/AArch64/BdsLinuxLoader.c delete mode 100644 ArmPkg/Library/BdsLib/AArch64/BdsLinuxLoaderHelper.S delete mode 100644 ArmPkg/Library/BdsLib/Arm/BdsLinuxAtag.c delete mode 100644 ArmPkg/Library/BdsLib/Arm/BdsLinuxLoader.c delete mode 100644 ArmPkg/Library/BdsLib/BdsLinuxFdt.c delete mode 100644 ArmPkg/Library/BdsLib/BdsLinuxLoader.h diff --git a/ArmPkg/Include/Library/BdsLib.h b/ArmPkg/Include/Library/BdsLib.h index 3d9e195..c58f47e 100644 --- a/ArmPkg/Include/Library/BdsLib.h +++ b/ArmPkg/Include/Library/BdsLib.h @@ -138,43 +138,6 @@ BootOptionAllocateBootIndex ( ); /** - Start a Linux kernel from a Device Path - - @param LinuxKernel Device Path to the Linux Kernel - @param ParametersLinux kernel arguments - - @retval EFI_SUCCESS All drivers have been connected - @retval EFI_NOT_FOUND The Linux kernel Device Path has not been found - @retval EFI_OUT_OF_RESOURCES There is not enough resource memory to store the matching results. - -**/ -EFI_STATUS -BdsBootLinuxAtag ( - IN EFI_DEVICE_PATH_PROTOCOL* LinuxKernelDevicePath, - IN EFI_DEVICE_PATH_PROTOCOL* InitrdDevicePath, - IN CONST CHAR8* Arguments - ); - -/** - Start a Linux kernel from a Device Path - - @param[in] LinuxKernelDevicePath Device Path to the Linux Kernel - @param[in] InitrdDevicePath Device Path to the Initrd - @param[in] Arguments Linux kernel arguments - - @retval EFI_SUCCESS All drivers have been connected - @retval EFI_NOT_FOUND The Linux kernel Device Path has not been found - @retval EFI_OUT_OF_RESOURCES There is not enough resource memory to store the matching results. - -**/ -EFI_STATUS -BdsBootLinuxFdt ( - IN EFI_DEVICE_PATH_PROTOCOL* LinuxKernelDevicePath, - IN EFI_DEVICE_PATH_PROTOCOL* InitrdDevicePath, - IN CONST CHAR8* Arguments - ); - -/** Start an EFI Application from a Device Path @param ParentImageHandle Handle of the calling image diff --git a/ArmPkg/Library/BdsLib/AArch64/BdsLinuxLoader.c b/ArmPkg/Library/BdsLib/AArch64/BdsLinuxLoader.c deleted file mode 100644 index 7651597..000 --- a/ArmPkg/Library/BdsLib/AArch64/BdsLinuxLoader.c +++ /dev/null @@ -1,355 +0,0 @@ -/** @file -* -* Copyright (c) 2011-2014, ARM Limited. All rights reserved. -* -* This program and the accompanying materials -* are licensed and made available under the terms and conditions of the BSD License -* which accompanies this distribution. The full text of the license may be found at -* http://opensource.org/licenses/bsd-license.php -* -* THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN AS IS BASIS, -* WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED. -* -**/ -#include Library/ArmGicLib.h -#include Ppi/ArmMpCoreInfo.h -#include Library/IoLib.h -#include Guid/Fdt.h -#include libfdt.h - -#include BdsInternal.h -#include BdsLinuxLoader.h - -/* - Linux kernel booting: Look at the doc in the Kernel source : -Documentation/arm64/booting.txt - The kernel image must be placed at the start of the memory to be used by the - kernel (2MB aligned) + 0x8. - - The Device tree blob is expected to be under 2MB and be within the first 512MB - of kernel memory and be 2MB aligned. - - A Flattened Device Tree (FDT) used to boot linux needs to be updated before - the kernel is started. It needs to indicate how secondary cores are brought up - and where they are waiting before loading Linux. The FDT also needs to hold - the correct kernel command line and filesystem RAM-disk information. - At the moment we do not fully support generating this FDT information at - runtime. A prepared FDT should be provided at boot. FDT is the only supported - method for booting the AArch64 Linux kernel. - - Linux does not use any runtime services at this time
[edk2] [PATCH V2 09/10] ArmPlatformPkg/Bds: Added support for booting legacy kernel from BDS
When PcdBdsLinuxSupport is enabled, users can create boot
entries for the legacy EFI Linux loader.
The ARM BDS detects if the image is a EFI image if not
then it assumes it is a legacy Linux kernel (a kernel
without EFI Stub).
If the Boot Manager did not manage to load the binary
(it could happen when the binary is on the network or
not present on the media yet).
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Olivier Martin olivier.mar...@arm.com
Reviewed-by: Ronald Cron ronald.c...@arm.com
---
ArmPlatformPkg/ArmPlatformPkg.dec | 3 +
ArmPlatformPkg/Bds/Bds.inf| 4 +
ArmPlatformPkg/Bds/BdsHelper.c| 9 ---
ArmPlatformPkg/Bds/BdsInternal.h | 26 --
ArmPlatformPkg/Bds/BootLinux.c| 124 +
ArmPlatformPkg/Bds/BootMenu.c | 161 +-
6 files changed, 274 insertions(+), 53 deletions(-)
create mode 100644 ArmPlatformPkg/Bds/BootLinux.c
diff --git a/ArmPlatformPkg/ArmPlatformPkg.dec
b/ArmPlatformPkg/ArmPlatformPkg.dec
index be0919b..45aeaee 100644
--- a/ArmPlatformPkg/ArmPlatformPkg.dec
+++ b/ArmPlatformPkg/ArmPlatformPkg.dec
@@ -61,6 +61,9 @@
# we assume the OS will handle the FrameBuffer from the UEFI GOP information.
gArmPlatformTokenSpaceGuid.PcdGopDisableOnExitBootServices|FALSE|BOOLEAN|0x003D
+ # Enable Legacy Linux support in the BDS
+ gArmPlatformTokenSpaceGuid.PcdBdsLinuxSupport|TRUE|BOOLEAN|0x002E
+
[PcdsFixedAtBuild.common]
gArmPlatformTokenSpaceGuid.PcdCoreCount|1|UINT32|0x0039
gArmPlatformTokenSpaceGuid.PcdClusterCount|1|UINT32|0x0038
diff --git a/ArmPlatformPkg/Bds/Bds.inf b/ArmPlatformPkg/Bds/Bds.inf
index 3b6ffc3..06e8d91 100644
--- a/ArmPlatformPkg/Bds/Bds.inf
+++ b/ArmPlatformPkg/Bds/Bds.inf
@@ -27,6 +27,7 @@
[Sources]
Bds.c
BdsHelper.c
+ BootLinux.c
BootMenu.c
BootOption.c
BootOptionSupport.c
@@ -72,6 +73,9 @@
gEfiDhcp4ServiceBindingProtocolGuid
gEfiMtftp4ServiceBindingProtocolGuid
+[FeaturePcd]
+ gArmPlatformTokenSpaceGuid.PcdBdsLinuxSupport
+
[Pcd]
gArmPlatformTokenSpaceGuid.PcdFirmwareVendor
gArmPlatformTokenSpaceGuid.PcdDefaultBootDescription
diff --git a/ArmPlatformPkg/Bds/BdsHelper.c b/ArmPlatformPkg/Bds/BdsHelper.c
index b3003e9..732292c 100644
--- a/ArmPlatformPkg/Bds/BdsHelper.c
+++ b/ArmPlatformPkg/Bds/BdsHelper.c
@@ -256,15 +256,6 @@ GetHIInputBoolean (
}
}
-BOOLEAN
-HasFilePathEfiExtension (
- IN CHAR16* FilePath
- )
-{
- return (StrCmp (FilePath + (StrSize (FilePath) / sizeof (CHAR16)) - 5,
L.EFI) == 0) ||
- (StrCmp (FilePath + (StrSize (FilePath) / sizeof (CHAR16)) - 5,
L.efi) == 0);
-}
-
// Return the last non end-type Device Path Node from a Device Path
EFI_DEVICE_PATH*
GetLastDevicePathNode (
diff --git a/ArmPlatformPkg/Bds/BdsInternal.h b/ArmPlatformPkg/Bds/BdsInternal.h
index fe4fd79..ddf5308 100644
--- a/ArmPlatformPkg/Bds/BdsInternal.h
+++ b/ArmPlatformPkg/Bds/BdsInternal.h
@@ -1,6 +1,6 @@
/** @file
*
-* Copyright (c) 2011-2014, ARM Limited. All rights reserved.
+* Copyright (c) 2011-2015, ARM Limited. All rights reserved.
*
* This program and the accompanying materials
* are licensed and made available under the terms and conditions of the BSD
License
@@ -79,6 +79,12 @@ typedef struct _BDS_LOAD_OPTION_SUPPORT {
#define LOAD_OPTION_ENTRY_FROM_LINK(a) BASE_CR(a, BDS_LOAD_OPTION_ENTRY, Link)
#define LOAD_OPTION_FROM_LINK(a)((BDS_LOAD_OPTION_ENTRY*)BASE_CR(a,
BDS_LOAD_OPTION_ENTRY, Link))-BdsLoadOption
+// GUID of the EFI Linux Loader
+extern CONST EFI_GUID mLinuxLoaderAppGuid;
+
+// Device path of the EFI Linux Loader in the Firmware Volume
+extern EFI_DEVICE_PATH* mLinuxLoaderDevicePath;
+
EFI_STATUS
BootDeviceListSupportedInit (
IN OUT LIST_ENTRY *SupportedDeviceList
@@ -141,11 +147,6 @@ GetHIInputBoolean (
OUT BOOLEAN *Value
);
-BOOLEAN
-HasFilePathEfiExtension (
- IN CHAR16* FilePath
- );
-
EFI_DEVICE_PATH*
GetLastDevicePathNode (
IN EFI_DEVICE_PATH* DevicePath
@@ -260,4 +261,17 @@ EmptyCallbackFunction (
IN VOID *Context
);
+/**
+ * This function check if the DevicePath defines an EFI binary
+ *
+ * This function is used when the BDS support Linux loader to
+ * detect if the binary is an EFI application or potentially a
+ * Linux kernel.
+ */
+EFI_STATUS
+IsEfiBinary (
+ IN EFI_DEVICE_PATH* DevicePath,
+ OUT BOOLEAN *EfiBinary
+ );
+
#endif /* _BDSINTERNAL_H_ */
diff --git a/ArmPlatformPkg/Bds/BootLinux.c b/ArmPlatformPkg/Bds/BootLinux.c
new file mode 100644
index 000..0445e89
--- /dev/null
+++ b/ArmPlatformPkg/Bds/BootLinux.c
@@ -0,0 +1,124 @@
+/** @file
+*
+* Copyright (c) 2011 - 2015, ARM Limited. All rights reserved.
+*
+* This program and the accompanying materials
+* are licensed and made available under the terms and conditions of the BSD
License
+* which accompanies this distribution. The full text of the license may be
found at
+* http://opensource.org
[edk2] [PATCH V2 05/10] ArmPlatformPkg/Bds: Remove Linux specific boot path
Since the embedded Linux Loader has been removed from BdsLib
there is no more Linux specific boot option.
All the boot options are now expected to be arguments for
EFI applications.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Olivier Martin olivier.mar...@arm.com
Reviewed-by: Ronald Cron ronald.c...@arm.com
---
ArmPlatformPkg/Bds/Bds.c | 36 +---
ArmPlatformPkg/Bds/Bds.inf | 7 +-
ArmPlatformPkg/Bds/BdsInternal.h | 45 -
ArmPlatformPkg/Bds/BootMenu.c | 358 ++---
ArmPlatformPkg/Bds/BootOption.c| 100 ++---
ArmPlatformPkg/Bds/BootOptionSupport.c | 111 --
6 files changed, 93 insertions(+), 564 deletions(-)
diff --git a/ArmPlatformPkg/Bds/Bds.c b/ArmPlatformPkg/Bds/Bds.c
index 1fab439..3ee866c 100644
--- a/ArmPlatformPkg/Bds/Bds.c
+++ b/ArmPlatformPkg/Bds/Bds.c
@@ -220,12 +220,6 @@ DefineDefaultBootEntries (
EFI_STATUS Status;
EFI_DEVICE_PATH_FROM_TEXT_PROTOCOL* EfiDevicePathFromTextProtocol;
EFI_DEVICE_PATH*BootDevicePath;
- UINT8* OptionalData;
- UINTN OptionalDataSize;
- ARM_BDS_LOADER_ARGUMENTS* BootArguments;
- ARM_BDS_LOADER_TYPE BootType;
- EFI_DEVICE_PATH*InitrdPath;
- UINTN InitrdSize;
UINTN CmdLineSize;
UINTN CmdLineAsciiSize;
CHAR16* DefaultBootArgument;
@@ -269,8 +263,6 @@ DefineDefaultBootEntries (
// Create the entry is the Default values are correct
if (BootDevicePath != NULL) {
- BootType = (ARM_BDS_LOADER_TYPE)PcdGet32 (PcdDefaultBootType);
-
// We do not support NULL pointer
ASSERT (PcdGetPtr (PcdDefaultBootArgument) != NULL);
@@ -308,33 +300,11 @@ DefineDefaultBootEntries (
AsciiStrToUnicodeStr (AsciiDefaultBootArgument, DefaultBootArgument);
}
- if ((BootType == BDS_LOADER_KERNEL_LINUX_ATAG) || (BootType ==
BDS_LOADER_KERNEL_LINUX_FDT)) {
-InitrdPath = EfiDevicePathFromTextProtocol-ConvertTextToDevicePath
((CHAR16*)PcdGetPtr(PcdDefaultBootInitrdPath));
-InitrdSize = GetDevicePathSize (InitrdPath);
-
-OptionalDataSize = sizeof(ARM_BDS_LOADER_ARGUMENTS) + CmdLineAsciiSize
+ InitrdSize;
-BootArguments = (ARM_BDS_LOADER_ARGUMENTS*)AllocatePool
(OptionalDataSize);
-if (BootArguments == NULL) {
- return EFI_OUT_OF_RESOURCES;
-}
-BootArguments-LinuxArguments.CmdLineSize = CmdLineAsciiSize;
-BootArguments-LinuxArguments.InitrdSize = InitrdSize;
-
-CopyMem ((VOID*)(BootArguments + 1), AsciiDefaultBootArgument,
CmdLineAsciiSize);
-CopyMem ((VOID*)((UINTN)(BootArguments + 1) + CmdLineAsciiSize),
InitrdPath, InitrdSize);
-
-OptionalData = (UINT8*)BootArguments;
- } else {
-OptionalData = (UINT8*)DefaultBootArgument;
-OptionalDataSize = CmdLineSize;
- }
-
BootOptionCreate (LOAD_OPTION_ACTIVE | LOAD_OPTION_CATEGORY_BOOT,
-(CHAR16*)PcdGetPtr(PcdDefaultBootDescription),
+(CHAR16*)PcdGetPtr (PcdDefaultBootDescription),
BootDevicePath,
-BootType,
-OptionalData,
-OptionalDataSize,
+(UINT8 *)DefaultBootArgument, // OptionalData
+CmdLineSize, // OptionalDataSize
BdsLoadOption
);
FreePool (BdsLoadOption);
diff --git a/ArmPlatformPkg/Bds/Bds.inf b/ArmPlatformPkg/Bds/Bds.inf
index 9639f14..3b6ffc3 100644
--- a/ArmPlatformPkg/Bds/Bds.inf
+++ b/ArmPlatformPkg/Bds/Bds.inf
@@ -24,7 +24,7 @@
ENTRY_POINT= BdsInitialize
-[Sources.common]
+[Sources]
Bds.c
BdsHelper.c
BootMenu.c
@@ -44,12 +44,11 @@
[LibraryClasses]
BdsLib
- TimerLib
- PerformanceLib
UefiBootServicesTableLib
DxeServicesTableLib
UefiDriverEntryPoint
DebugLib
+ PerformanceLib
PrintLib
BaseLib
FdtLib
@@ -77,9 +76,7 @@
gArmPlatformTokenSpaceGuid.PcdFirmwareVendor
gArmPlatformTokenSpaceGuid.PcdDefaultBootDescription
gArmPlatformTokenSpaceGuid.PcdDefaultBootDevicePath
- gArmPlatformTokenSpaceGuid.PcdDefaultBootInitrdPath
gArmPlatformTokenSpaceGuid.PcdDefaultBootArgument
- gArmPlatformTokenSpaceGuid.PcdDefaultBootType
gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut
gArmPlatformTokenSpaceGuid.PcdDefaultConInPaths
gArmPlatformTokenSpaceGuid.PcdDefaultConOutPaths
diff --git a/ArmPlatformPkg/Bds/BdsInternal.h b/ArmPlatformPkg/Bds/BdsInternal.h
index 1cb154e..fe4fd79 100644
--- a/ArmPlatformPkg/Bds/BdsInternal.h
+++ b/ArmPlatformPkg/Bds/BdsInternal.h
@@ -38,46 +38,10 @@
#define BOOT_DEVICE_OPTION_MAX300
#define BOOT_DEVICE_ADDRESS_MAX (sizeof(L0x))
-#define ARM_BDS_OPTIONAL_DATA_SIGNATURE SIGNATURE_32('a', 'b', 'o', 'd')
-
-#define
Re: [edk2] [PATCH 6/8] ArmPlatformPkg/Bds: Added support for booting legacy kernel from BDS
Yes, that’s correct that was the patch is doing. I will update the comment and
send a V2 as per Laszlo’s comments.
From: Ryan Harkin [mailto:ryan.har...@linaro.org]
Sent: 13 July 2015 18:17
To: Olivier Martin
Cc: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] [PATCH 6/8] ArmPlatformPkg/Bds: Added support for booting
legacy kernel from BDS
On 13 July 2015 at 17:36, Olivier Martin
olivier.mar...@arm.commailto:olivier.mar...@arm.com wrote:
When PcdBdsLinuxSupport is enabled, users can create boot
entries for the legacy EFI Linux loader if it exists into
the firmware.
Surely this is only true if the kernel doesn't have an EFI header? If it has
an EFI header, it will be forced to use the EFI loader.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Olivier Martin
olivier.mar...@arm.commailto:olivier.mar...@arm.com
Reviewed-by: Ronald Cron ronald.c...@arm.commailto:ronald.c...@arm.com
---
ArmPlatformPkg/ArmPlatformPkg.dec | 3 +
ArmPlatformPkg/Bds/Bds.inf| 4 +
ArmPlatformPkg/Bds/BdsHelper.c| 9 ---
ArmPlatformPkg/Bds/BdsInternal.h | 26 --
ArmPlatformPkg/Bds/BootLinux.c| 124 +
ArmPlatformPkg/Bds/BootMenu.c | 161 +-
6 files changed, 274 insertions(+), 53 deletions(-)
create mode 100644 ArmPlatformPkg/Bds/BootLinux.c
diff --git a/ArmPlatformPkg/ArmPlatformPkg.dec
b/ArmPlatformPkg/ArmPlatformPkg.dec
index be0919b..45aeaee 100644
--- a/ArmPlatformPkg/ArmPlatformPkg.dec
+++ b/ArmPlatformPkg/ArmPlatformPkg.dec
@@ -61,6 +61,9 @@
# we assume the OS will handle the FrameBuffer from the UEFI GOP information.
gArmPlatformTokenSpaceGuid.PcdGopDisableOnExitBootServices|FALSE|BOOLEAN|0x003D
+ # Enable Legacy Linux support in the BDS
+ gArmPlatformTokenSpaceGuid.PcdBdsLinuxSupport|TRUE|BOOLEAN|0x002E
+
[PcdsFixedAtBuild.common]
gArmPlatformTokenSpaceGuid.PcdCoreCount|1|UINT32|0x0039
gArmPlatformTokenSpaceGuid.PcdClusterCount|1|UINT32|0x0038
diff --git a/ArmPlatformPkg/Bds/Bds.inf b/ArmPlatformPkg/Bds/Bds.inf
index 3b6ffc3..06e8d91 100644
--- a/ArmPlatformPkg/Bds/Bds.inf
+++ b/ArmPlatformPkg/Bds/Bds.inf
@@ -27,6 +27,7 @@
[Sources]
Bds.c
BdsHelper.c
+ BootLinux.c
BootMenu.c
BootOption.c
BootOptionSupport.c
@@ -72,6 +73,9 @@
gEfiDhcp4ServiceBindingProtocolGuid
gEfiMtftp4ServiceBindingProtocolGuid
+[FeaturePcd]
+ gArmPlatformTokenSpaceGuid.PcdBdsLinuxSupport
+
[Pcd]
gArmPlatformTokenSpaceGuid.PcdFirmwareVendor
gArmPlatformTokenSpaceGuid.PcdDefaultBootDescription
diff --git a/ArmPlatformPkg/Bds/BdsHelper.c b/ArmPlatformPkg/Bds/BdsHelper.c
index b3003e9..732292c 100644
--- a/ArmPlatformPkg/Bds/BdsHelper.c
+++ b/ArmPlatformPkg/Bds/BdsHelper.c
@@ -256,15 +256,6 @@ GetHIInputBoolean (
}
}
-BOOLEAN
-HasFilePathEfiExtension (
- IN CHAR16* FilePath
- )
-{
- return (StrCmp (FilePath + (StrSize (FilePath) / sizeof (CHAR16)) - 5,
L.EFI) == 0) ||
- (StrCmp (FilePath + (StrSize (FilePath) / sizeof (CHAR16)) - 5,
L.efi) == 0);
-}
-
// Return the last non end-type Device Path Node from a Device Path
EFI_DEVICE_PATH*
GetLastDevicePathNode (
diff --git a/ArmPlatformPkg/Bds/BdsInternal.h b/ArmPlatformPkg/Bds/BdsInternal.h
index fe4fd79..ddf5308 100644
--- a/ArmPlatformPkg/Bds/BdsInternal.h
+++ b/ArmPlatformPkg/Bds/BdsInternal.h
@@ -1,6 +1,6 @@
/** @file
*
-* Copyright (c) 2011-2014, ARM Limited. All rights reserved.
+* Copyright (c) 2011-2015, ARM Limited. All rights reserved.
*
* This program and the accompanying materials
* are licensed and made available under the terms and conditions of the BSD
License
@@ -79,6 +79,12 @@ typedef struct _BDS_LOAD_OPTION_SUPPORT {
#define LOAD_OPTION_ENTRY_FROM_LINK(a) BASE_CR(a, BDS_LOAD_OPTION_ENTRY, Link)
#define LOAD_OPTION_FROM_LINK(a)((BDS_LOAD_OPTION_ENTRY*)BASE_CR(a,
BDS_LOAD_OPTION_ENTRY, Link))-BdsLoadOption
+// GUID of the EFI Linux Loader
+extern CONST EFI_GUID mLinuxLoaderAppGuid;
+
+// Device path of the EFI Linux Loader in the Firmware Volume
+extern EFI_DEVICE_PATH* mLinuxLoaderDevicePath;
+
EFI_STATUS
BootDeviceListSupportedInit (
IN OUT LIST_ENTRY *SupportedDeviceList
@@ -141,11 +147,6 @@ GetHIInputBoolean (
OUT BOOLEAN *Value
);
-BOOLEAN
-HasFilePathEfiExtension (
- IN CHAR16* FilePath
- );
-
EFI_DEVICE_PATH*
GetLastDevicePathNode (
IN EFI_DEVICE_PATH* DevicePath
@@ -260,4 +261,17 @@ EmptyCallbackFunction (
IN VOID *Context
);
+/**
+ * This function check if the DevicePath defines an EFI binary
+ *
+ * This function is used when the BDS support Linux loader to
+ * detect if the binary is an EFI application or potentially a
+ * Linux kernel.
+ */
+EFI_STATUS
+IsEfiBinary (
+ IN EFI_DEVICE_PATH* DevicePath,
+ OUT BOOLEAN *EfiBinary
+ );
+
#endif /* _BDSINTERNAL_H_ */
diff --git a/ArmPlatformPkg/Bds/BootLinux.c b/ArmPlatformPkg/Bds/BootLinux.c
new file mode 100644
index 000..0445e89
[edk2] [PATCH V2 06/10] ArmPlatformPkg: Remove Linux specific boot path
PcdDefaultBootType has been removed when the embedded Linux Loader has been removed from BdsLib. The boot arguments (defined by PcdDefaultBootArgument) are now always targetting EFI applications. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Olivier Martin olivier.mar...@arm.com Reviewed-by: Ronald Cron ronald.c...@arm.com --- ArmPlatformPkg/ArmJunoPkg/ArmJuno.dsc | 1 - ArmPlatformPkg/ArmRealViewEbPkg/ArmRealViewEb.dsc.inc | 1 - ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA15-A7.dsc | 3 --- ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA9x4.dsc | 3 --- ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc | 2 -- ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15.dsc | 3 --- ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15_MPCore.dsc | 3 --- ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A9x4.dsc| 3 --- .../ArmVExpressPkg/ArmVExpress-RTSM-AEMv8Ax4-foundation.dsc| 1 - ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-AEMv8Ax4.dsc| 1 - ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc | 3 --- BeagleBoardPkg/BeagleBoardPkg.dsc | 7 --- 12 files changed, 31 deletions(-) diff --git a/ArmPlatformPkg/ArmJunoPkg/ArmJuno.dsc b/ArmPlatformPkg/ArmJunoPkg/ArmJuno.dsc index b5b959a..9860cf0 100644 --- a/ArmPlatformPkg/ArmJunoPkg/ArmJuno.dsc +++ b/ArmPlatformPkg/ArmJunoPkg/ArmJuno.dsc @@ -151,7 +151,6 @@ # Support the Linux EFI stub by default gArmPlatformTokenSpaceGuid.PcdDefaultBootArgument|Lconsole=ttyAMA0,115200 earlycon=pl011,0x7ff8 root=/dev/sda1 rootwait verbose debug - gArmPlatformTokenSpaceGuid.PcdDefaultBootType|0 # Use the serial console (ConIn ConOut) and the Graphic driver (ConOut) gArmPlatformTokenSpaceGuid.PcdDefaultConOutPaths|LVenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(115200,8,N,1)/VenPcAnsi();VenHw(CE660500-824D-11E0-AC72-0002A5D5C51B) diff --git a/ArmPlatformPkg/ArmRealViewEbPkg/ArmRealViewEb.dsc.inc b/ArmPlatformPkg/ArmRealViewEbPkg/ArmRealViewEb.dsc.inc index 6232791..9445ce2 100644 --- a/ArmPlatformPkg/ArmRealViewEbPkg/ArmRealViewEb.dsc.inc +++ b/ArmPlatformPkg/ArmRealViewEbPkg/ArmRealViewEb.dsc.inc @@ -316,7 +316,6 @@ # # ARM OS Loader # - gArmTokenSpaceGuid.PcdArmMachineType|827 gArmPlatformTokenSpaceGuid.PcdDefaultBootDescription|LSemiHosting gArmPlatformTokenSpaceGuid.PcdDefaultBootDevicePath|LFv(14801114-DA6A-4113-985B-DC876337A15E)/LinuxLoader.efi gArmPlatformTokenSpaceGuid.PcdDefaultBootArgument|LVenHw(C5B9C74A-6D72-4719-99AB-C59F199091EB)/zImage-RTSM -a 827 -c \console=ttyAMA0,38400n8\ diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA15-A7.dsc b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA15-A7.dsc index 3b693c2..50bb556 100644 --- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA15-A7.dsc +++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA15-A7.dsc @@ -181,12 +181,9 @@ # # ARM OS Loader # - # Versatile Express machine type (ARM VERSATILE EXPRESS = 2272) required for ARM Linux: - gArmTokenSpaceGuid.PcdArmMachineType|2272 gArmPlatformTokenSpaceGuid.PcdDefaultBootDescription|LLinux from NorFlash gArmPlatformTokenSpaceGuid.PcdDefaultBootDevicePath|LVenHw(1F15DA3C-37FF-4070-B471-BB4AF12A724A)/Image gArmPlatformTokenSpaceGuid.PcdDefaultBootArgument|console=ttyAMA0,38400 earlyprintk debug verbose - gArmPlatformTokenSpaceGuid.PcdDefaultBootType|2 # Use the serial console (ConIn ConOut) and the Graphic driver (ConOut) # PL111 - CLCD diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA9x4.dsc b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA9x4.dsc index baa5478..18cc978 100644 --- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA9x4.dsc +++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA9x4.dsc @@ -180,11 +180,8 @@ # # ARM OS Loader # - # Versatile Express machine type (ARM VERSATILE EXPRESS = 2272) required for ARM Linux: - gArmTokenSpaceGuid.PcdArmMachineType|2272 gArmPlatformTokenSpaceGuid.PcdDefaultBootDescription|LNorFlash gArmPlatformTokenSpaceGuid.PcdDefaultBootDevicePath|LVenHw(1F15DA3C-37FF-4070-B471-BB4AF12A724A)/Image - gArmPlatformTokenSpaceGuid.PcdDefaultBootType|1 # Use the serial console (ConIn ConOut) and the Graphic driver (ConOut) gArmPlatformTokenSpaceGuid.PcdDefaultConOutPaths|LVenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenPcAnsi();VenHw(407B4008-BF5B-11DF-9547-CF16E0D72085) diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc index bfdc96b..1b6134f 100644 --- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc +++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc @@ -177,8 +177,6 @@ gArmPlatformTokenSpaceGuid.PcdDefaultBootDevicePath|LVenHw(C5B9C74A-6D72-4719-99AB-C59F199091EB)/Image
[edk2] [PATCH V2 03/10] ArmPlatformPkg: Add the LinuxLoader.efi EFI application
From: Ronald Cron ronald.c...@arm.com Add the legacy Linux Loader EFI application to the ARM development platforms. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ronald Cron ronald.c...@arm.com Reviewed-by: Olivier Martin olivier.mar...@arm.com --- ArmPlatformPkg/ArmJunoPkg/ArmJuno.fdf | 1 + ArmPlatformPkg/ArmPlatformPkg-2ndstage.dsc | 12 ArmPlatformPkg/ArmPlatformPkg-2ndstage.fdf | 4 +++- ArmPlatformPkg/ArmPlatformPkg.dsc | 13 + ArmPlatformPkg/ArmPlatformPkg.fdf | 4 +++- .../ArmRealViewEbPkg/ArmRealViewEb-RTSM-MPCore.fdf | 4 +++- .../ArmRealViewEbPkg/ArmRealViewEb-RTSM-UniCore.fdf | 5 - ArmPlatformPkg/ArmRealViewEbPkg/ArmRealViewEb.dsc.inc | 17 +++-- ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA15-A7.dsc | 2 +- ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA15-A7.fdf | 3 +++ ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA9x4.dsc| 2 +- ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA9x4.fdf| 3 +++ .../ArmVExpressPkg/ArmVExpress-FVP-AArch64.fdf | 3 +++ ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15.dsc | 2 +- ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15.fdf | 3 +++ .../ArmVExpressPkg/ArmVExpress-RTSM-A15_MPCore.dsc | 2 +- .../ArmVExpressPkg/ArmVExpress-RTSM-A15_MPCore.fdf | 3 +++ ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A9x4.dsc | 3 ++- ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A9x4.fdf | 3 +++ .../ArmVExpress-RTSM-AEMv8Ax4-foundation.fdf| 3 +++ .../ArmVExpressPkg/ArmVExpress-RTSM-AEMv8Ax4.fdf| 3 +++ ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc | 5 - BeagleBoardPkg/BeagleBoardPkg.dsc | 14 +- BeagleBoardPkg/BeagleBoardPkg.fdf | 3 +++ 24 files changed, 104 insertions(+), 13 deletions(-) diff --git a/ArmPlatformPkg/ArmJunoPkg/ArmJuno.fdf b/ArmPlatformPkg/ArmJunoPkg/ArmJuno.fdf index 2dbf0e6..db70609 100644 --- a/ArmPlatformPkg/ArmJunoPkg/ArmJuno.fdf +++ b/ArmPlatformPkg/ArmJunoPkg/ArmJuno.fdf @@ -191,6 +191,7 @@ FvNameGuid = B73FE497-B92E-416e-8326-45AD0D270092 # UEFI applications # INF ShellBinPkg/UefiShell/UefiShell.inf + INF ArmPkg/Application/LinuxLoader/LinuxLoader.inf # # Juno platform driver diff --git a/ArmPlatformPkg/ArmPlatformPkg-2ndstage.dsc b/ArmPlatformPkg/ArmPlatformPkg-2ndstage.dsc index 4cfb913..76415fe 100644 --- a/ArmPlatformPkg/ArmPlatformPkg-2ndstage.dsc +++ b/ArmPlatformPkg/ArmPlatformPkg-2ndstage.dsc @@ -89,6 +89,11 @@ # Networking Requirements for ArmPlatformPkg/Bds NetLib|MdeModulePkg/Library/DxeNetLib/DxeNetLib.inf + # These libraries are used by the dynamic EFI Shell commands + ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf + FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf + SortLib|MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf + # EBL Related Libraries EblCmdLib|ArmPlatformPkg/Library/EblCmdLib/EblCmdLib.inf EfiFileLib|EmbeddedPkg/Library/EfiFileLib/EfiFileLib.inf @@ -298,6 +303,11 @@ gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiLoaderCode|20 gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiLoaderData|0 + # We want to use the Shell Libraries but don't want it to initialise + # automatically. We initialise the libraries when the command is called by the + # Shell. + gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE + # # ARM Pcds # @@ -369,3 +379,5 @@ MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf ArmPlatformPkg/Bds/Bds.inf + # Legacy Linux Loader + ArmPkg/Application/LinuxLoader/LinuxLoader.inf diff --git a/ArmPlatformPkg/ArmPlatformPkg-2ndstage.fdf b/ArmPlatformPkg/ArmPlatformPkg-2ndstage.fdf index 86a94c1..9c35ebb 100644 --- a/ArmPlatformPkg/ArmPlatformPkg-2ndstage.fdf +++ b/ArmPlatformPkg/ArmPlatformPkg-2ndstage.fdf @@ -1,5 +1,5 @@ # -# Copyright (c) 2011-2014, ARM Limited. All rights reserved. +# Copyright (c) 2011-2015, ARM Limited. All rights reserved. # # This program and the accompanying materials # are licensed and made available under the terms and conditions of the BSD License @@ -129,6 +129,8 @@ FvNameGuid = 5eda4200-2c5f-43cb-9da3-0baf74b1b30c INF MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf INF ArmPlatformPkg/Bds/Bds.inf + # Legacy Linux Loader + INF ArmPkg/Application/LinuxLoader/LinuxLoader.inf [FV.FVMAIN_COMPACT] FvAlignment= 8 diff --git a/ArmPlatformPkg/ArmPlatformPkg.dsc b/ArmPlatformPkg/ArmPlatformPkg.dsc index f9f217c..0147146 100644 --- a/ArmPlatformPkg/ArmPlatformPkg.dsc +++ b/ArmPlatformPkg/ArmPlatformPkg.dsc @@ -88,6 +88,11 @@ # Networking Requirements for ArmPlatformPkg/Bds NetLib|MdeModulePkg/Library/DxeNetLib/DxeNetLib.inf + # These libraries are used by the dynamic EFI Shell commands + ShellLib|ShellPkg/Library/UefiShellLib
[edk2] [PATCH V2 01/10] ArmPkg/BdsLib: Replaced BdsLoadApplication() by LocateEfiApplicationInFv()
Replaced the function BdsLoadApplication() by two explicit
functions that load the EFI application either by its GUID
or its Name.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Olivier Martin olivier.mar...@arm.com
Reviewed-by: Ronald Cron ronald.c...@arm.com
---
ArmPkg/Include/Library/BdsLib.h | 52 ---
ArmPkg/Library/BdsLib/BdsAppLoader.c | 283 ---
ArmPlatformPkg/Bds/Bds.inf | 3 +
ArmPlatformPkg/Bds/BootMenu.c| 24 ++-
4 files changed, 250 insertions(+), 112 deletions(-)
diff --git a/ArmPkg/Include/Library/BdsLib.h b/ArmPkg/Include/Library/BdsLib.h
index c6416db..3d9e195 100644
--- a/ArmPkg/Include/Library/BdsLib.h
+++ b/ArmPkg/Include/Library/BdsLib.h
@@ -193,24 +193,6 @@ BdsStartEfiApplication (
IN VOID* LoadOptions
);
-/**
- Start an EFI Application from any Firmware Volume
-
- @param EfiAppEFI Application Name
-
- @retval EFI_SUCCESS All drivers have been connected
- @retval EFI_NOT_FOUND The Linux kernel Device Path has not been found
- @retval EFI_OUT_OF_RESOURCES There is not enough resource memory to store
the matching results.
-
-**/
-EFI_STATUS
-BdsLoadApplication (
- IN EFI_HANDLE ParentImageHandle,
- IN CHAR16* EfiApp,
- IN UINTN LoadOptionsSize,
- IN VOID* LoadOptions
- );
-
EFI_STATUS
BdsLoadImage (
IN EFI_DEVICE_PATH *DevicePath,
@@ -227,4 +209,38 @@ ShutdownUefiBootServices (
VOID
);
+/**
+ Locate an EFI application in a the Firmware Volumes by its name
+
+ @param EfiAppGuidGuid of the EFI Application into the Firmware
Volume
+ @param DevicePathEFI Device Path of the EFI application
+
+ @return EFI_SUCCESS The function completed successfully.
+ @return EFI_NOT_FOUND The protocol could not be located.
+ @return EFI_OUT_OF_RESOURCES There are not enough resources to find the
protocol.
+
+**/
+EFI_STATUS
+LocateEfiApplicationInFvByName (
+ IN CONST CHAR16* EfiAppName,
+ OUT EFI_DEVICE_PATH **DevicePath
+ );
+
+/**
+ Locate an EFI application in a the Firmware Volumes by its GUID
+
+ @param EfiAppGuidGuid of the EFI Application into the Firmware
Volume
+ @param DevicePathEFI Device Path of the EFI application
+
+ @return EFI_SUCCESS The function completed successfully.
+ @return EFI_NOT_FOUND The protocol could not be located.
+ @return EFI_OUT_OF_RESOURCES There are not enough resources to find the
protocol.
+
+**/
+EFI_STATUS
+LocateEfiApplicationInFvByGuid (
+ IN CONST EFI_GUID*EfiAppGuid,
+ OUT EFI_DEVICE_PATH **DevicePath
+ );
+
#endif
diff --git a/ArmPkg/Library/BdsLib/BdsAppLoader.c
b/ArmPkg/Library/BdsLib/BdsAppLoader.c
index 2b88bf1..1f208f8 100644
--- a/ArmPkg/Library/BdsLib/BdsAppLoader.c
+++ b/ArmPkg/Library/BdsLib/BdsAppLoader.c
@@ -1,6 +1,6 @@
/** @file
*
-* Copyright (c) 2011-2012, ARM Limited. All rights reserved.
+* Copyright (c) 2011-2015, ARM Limited. All rights reserved.
*
* This program and the accompanying materials
* are licensed and made available under the terms and conditions of the BSD
License
@@ -14,18 +14,23 @@
#include BdsInternal.h
-//#include Library/DxeServicesLib.h
+/**
+ Locate an EFI application in a the Firmware Volumes by its Name
+
+ @param EfiAppGuidGuid of the EFI Application into the Firmware
Volume
+ @param DevicePathEFI Device Path of the EFI application
+
+ @return EFI_SUCCESS The function completed successfully.
+ @return EFI_NOT_FOUND The protocol could not be located.
+ @return EFI_OUT_OF_RESOURCES There are not enough resources to find the
protocol.
-STATIC
+**/
EFI_STATUS
-BdsLoadFileFromFirmwareVolume (
- IN EFI_HANDLE FvHandle,
- IN CHAR16*FilePath,
- IN EFI_FV_FILETYPE FileTypeFilter,
- OUT EFI_DEVICE_PATH **EfiAppDevicePath
+LocateEfiApplicationInFvByName (
+ IN CONST CHAR16* EfiAppName,
+ OUT EFI_DEVICE_PATH **DevicePath
)
{
- EFI_FIRMWARE_VOLUME2_PROTOCOL *FvProtocol;
VOID *Key;
EFI_STATUSStatus, FileStatus;
EFI_GUID NameGuid;
@@ -37,108 +42,212 @@ BdsLoadFileFromFirmwareVolume (
UINT32Authentication;
EFI_DEVICE_PATH *FvDevicePath;
MEDIA_FW_VOL_FILEPATH_DEVICE_PATHFileDevicePath;
+ EFI_HANDLE*HandleBuffer;
+ UINTN NumberOfHandles;
+ UINTN Index;
+ EFI_FIRMWARE_VOLUME2_PROTOCOL *FvInstance;
- Status = gBS-HandleProtocol (FvHandle,gEfiFirmwareVolume2ProtocolGuid,
(VOID **)FvProtocol);
- if (EFI_ERROR(Status)) {
-return Status;
- }
+ ASSERT (DevicePath != NULL);
// Length of FilePath
[edk2] [PATCH V2 02/10] EmbeddedPkg/AndroidFastboot: Use Linux Loader instead of BdsLib
Android FastBoot EFI application was using the Linux Loader
from BdsLib. This change makes use of the EFI Linux Loader
application.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Olivier Martin olivier.mar...@arm.com
Reviewed-by: Ronald Cron ronald.c...@arm.com
---
.../AndroidFastboot/AndroidFastbootApp.inf | 3 +-
.../AndroidFastboot/Arm/BootAndroidBootImg.c | 48 +++---
2 files changed, 44 insertions(+), 7 deletions(-)
diff --git a/EmbeddedPkg/Application/AndroidFastboot/AndroidFastbootApp.inf
b/EmbeddedPkg/Application/AndroidFastboot/AndroidFastbootApp.inf
index ab9354c..ca17af8 100644
--- a/EmbeddedPkg/Application/AndroidFastboot/AndroidFastbootApp.inf
+++ b/EmbeddedPkg/Application/AndroidFastboot/AndroidFastbootApp.inf
@@ -1,6 +1,6 @@
#/** @file
#
-# Copyright (c) 2013-2014, ARM Ltd. All rights reserved.BR
+# Copyright (c) 2013-2015, ARM Ltd. All rights reserved.BR
#
# This program and the accompanying materials
# are licensed and made available under the terms and conditions of the BSD
License
@@ -39,6 +39,7 @@
PrintLib
UefiApplicationEntryPoint
UefiBootServicesTableLib
+ UefiLib
UefiRuntimeServicesTableLib
[Protocols]
diff --git a/EmbeddedPkg/Application/AndroidFastboot/Arm/BootAndroidBootImg.c
b/EmbeddedPkg/Application/AndroidFastboot/Arm/BootAndroidBootImg.c
index 7e9ad88..3053cf0 100644
--- a/EmbeddedPkg/Application/AndroidFastboot/Arm/BootAndroidBootImg.c
+++ b/EmbeddedPkg/Application/AndroidFastboot/Arm/BootAndroidBootImg.c
@@ -1,6 +1,6 @@
/** @file
- Copyright (c) 2013-2014, ARM Ltd. All rights reserved.BR
+ Copyright (c) 2013-2015, ARM Ltd. All rights reserved.BR
This program and the accompanying materials
are licensed and made available under the terms and conditions of the BSD
License
@@ -18,9 +18,16 @@
#include Library/BdsLib.h
#include Library/DevicePathLib.h
+#include Library/UefiBootServicesTableLib.h
+#include Library/UefiLib.h
#include Guid/ArmGlobalVariableHob.h
+#define LINUX_LOADER_COMMAND_LINE L%s -f %s -c %s
+
+// This GUID is defined in the INGF file of ArmPkg/Application/LinuxLoader
+CONST EFI_GUID mLinuxLoaderAppGuid = { 0x701f54f2, 0x0d70, 0x4b89, { 0xbc,
0x0a, 0xd9, 0xca, 0x25, 0x37, 0x90, 0x59 }};
+
// Device Path representing an image in memory
#pragma pack(1)
typedef struct {
@@ -64,6 +71,10 @@ BootAndroidBootImg (
UINTN RamdiskSize;
MEMORY_DEVICE_PATH KernelDevicePath;
MEMORY_DEVICE_PATH* RamdiskDevicePath;
+ CHAR16* KernelDevicePathTxt;
+ CHAR16* RamdiskDevicePathTxt;
+ EFI_DEVICE_PATH*LinuxLoaderDevicePath;
+ CHAR16* LoadOptions;
Status = ParseAndroidBootImg (
Buffer,
@@ -92,20 +103,45 @@ BootAndroidBootImg (
RamdiskDevicePath-Node1.EndingAddress = ((EFI_PHYSICAL_ADDRESS)(UINTN)
Ramdisk) + RamdiskSize;
}
- Status = BdsBootLinuxFdt (
- (EFI_DEVICE_PATH_PROTOCOL *) KernelDevicePath,
- (EFI_DEVICE_PATH_PROTOCOL *) RamdiskDevicePath,
- KernelArgs
- );
+ //
+ // Boot Linux using the Legacy Linux Loader
+ //
+
+ Status = LocateEfiApplicationInFvByGuid (mLinuxLoaderAppGuid,
LinuxLoaderDevicePath);
+ if (EFI_ERROR (Status)) {
+Print (LCouldn't Boot Linux: %d\n, Status);
+return EFI_DEVICE_ERROR;
+ }
+
+ KernelDevicePathTxt = ConvertDevicePathToText ((EFI_DEVICE_PATH_PROTOCOL *)
KernelDevicePath, FALSE, FALSE);
+ if (KernelDevicePathTxt == NULL) {
+return EFI_OUT_OF_RESOURCES;
+ }
+
+ RamdiskDevicePathTxt = ConvertDevicePathToText ((EFI_DEVICE_PATH_PROTOCOL *)
RamdiskDevicePath, FALSE, FALSE);
+ if (RamdiskDevicePathTxt == NULL) {
+return EFI_OUT_OF_RESOURCES;
+ }
+
+ // Initialize Legacy Linux loader command line
+ LoadOptions = CatSPrint (NULL, LINUX_LOADER_COMMAND_LINE,
KernelDevicePathTxt, RamdiskDevicePathTxt, KernelArgs);
+ if (LoadOptions == NULL) {
+return EFI_OUT_OF_RESOURCES;
+ }
+
+ Status = BdsStartEfiApplication (gImageHandle, LinuxLoaderDevicePath,
StrSize (LoadOptions), LoadOptions);
if (EFI_ERROR (Status)) {
DEBUG ((EFI_D_ERROR, Couldn't Boot Linux: %d\n, Status));
return EFI_DEVICE_ERROR;
}
if (RamdiskDevicePath) {
+FreePool (RamdiskDevicePathTxt);
FreePool (RamdiskDevicePath);
}
+ FreePool (KernelDevicePathTxt);
+
// If we got here we do a confused face because BootLinuxFdt returned,
// reporting success.
DEBUG ((EFI_D_ERROR, WARNING: BdsBootLinuxFdt returned EFI_SUCCESS.\n));
--
2.1.1
--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud
[edk2] [PATCH V2 08/10] ArmPkg: Remove PCD declarations linked to the ARM BDS Linux Loader
The Linux Loader has been removed from ARM BDS. These PCDs are not needed anymore. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Olivier Martin olivier.mar...@arm.com Reviewed-by: Ronald Cron ronald.c...@arm.com --- ArmPkg/ArmPkg.dec | 1 - ArmPlatformPkg/ArmPlatformPkg.dec | 6 -- 2 files changed, 7 deletions(-) diff --git a/ArmPkg/ArmPkg.dec b/ArmPkg/ArmPkg.dec index b30de91..da0c8a9 100644 --- a/ArmPkg/ArmPkg.dec +++ b/ArmPkg/ArmPkg.dec @@ -115,7 +115,6 @@ # # BdsLib # - gArmTokenSpaceGuid.PcdArmMachineType|0|UINT32|0x001E # The compressed Linux kernel is expected to be under 128MB from the beginning of the System Memory gArmTokenSpaceGuid.PcdArmLinuxKernelMaxOffset|0x0800|UINT32|0x001F # Maximum file size for TFTP servers that do not support 'tsize' extension diff --git a/ArmPlatformPkg/ArmPlatformPkg.dec b/ArmPlatformPkg/ArmPlatformPkg.dec index cd67aee..be0919b 100644 --- a/ArmPlatformPkg/ArmPlatformPkg.dec +++ b/ArmPlatformPkg/ArmPlatformPkg.dec @@ -129,13 +129,7 @@ gArmPlatformTokenSpaceGuid.PcdFirmwareVendor|ARM Platform|VOID*|0x0019 gArmPlatformTokenSpaceGuid.PcdDefaultBootDescription|LDefault Boot Device|VOID*|0x000C gArmPlatformTokenSpaceGuid.PcdDefaultBootDevicePath|L|VOID*|0x000D - gArmPlatformTokenSpaceGuid.PcdDefaultBootInitrdPath|L|VOID*|0x000E gArmPlatformTokenSpaceGuid.PcdDefaultBootArgument|L|VOID*|0x00F - # PcdDefaultBootType define the type of the binary pointed by PcdDefaultBootDevicePath: - # - 0 = an EFI application - # - 1 = a Linux kernel with ATAG support - # - 2 = a Linux kernel with FDT support - gArmPlatformTokenSpaceGuid.PcdDefaultBootType|0|UINT32|0x0010 gArmPlatformTokenSpaceGuid.PcdDefaultConInPaths|L|VOID*|0x001B gArmPlatformTokenSpaceGuid.PcdDefaultConOutPaths|L|VOID*|0x001C -- 2.1.1 -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
[edk2] [PATCH V2 00/10] ArmPlatformPkg: Remove embedded Linux Loader from ARM BDS
ARM BDS contains an embedded Linux Loader. This support was to allow booting legacy linux loader (Linux without EFI Stub) on ARM platforms. This patchset replace the embedded legacy Linux loader by the use of the EFI Linux Loader located in ArmPkg/Application/LinuxLoader when the firmware engineer enables PcdBdsLinuxSupport in the ARM BDS. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Olivier Martin olivier.mar...@arm.com Reviewed-by: Ronald Cron ronald.c...@arm.com Cc: Laszlo Ersek ler...@redhat.com Cc: Ard Biesheuvel ard.biesheu...@linaro.org Olivier Martin (9): ArmPkg/BdsLib: Replaced BdsLoadApplication() by LocateEfiApplicationInFv() EmbeddedPkg/AndroidFastboot: Use Linux Loader instead of BdsLib ArmPkg/BdsLib: Remove Linux loader from BdsLib ArmPlatformPkg/Bds: Remove Linux specific boot path ArmPlatformPkg: Remove Linux specific boot path ArmVirtPkg/ArmVirtQemu.dsc: Remove Linux specific boot path ArmPkg: Remove PCD declarations linked to the ARM BDS Linux Loader ArmPlatformPkg/Bds: Added support for booting legacy kernel from BDS ArmPlatformPkg: Use LinuxLoader.efi for the default boot entry Ronald Cron (1): ArmPlatformPkg: Add the LinuxLoader.efi EFI application ArmPkg/ArmPkg.dec | 1 - ArmPkg/Include/Library/BdsLib.h| 89 ++-- ArmPkg/Library/BdsLib/AArch64/BdsLinuxLoader.c | 355 - .../Library/BdsLib/AArch64/BdsLinuxLoaderHelper.S | 58 --- ArmPkg/Library/BdsLib/Arm/BdsLinuxAtag.c | 173 --- ArmPkg/Library/BdsLib/Arm/BdsLinuxLoader.c | 323 ArmPkg/Library/BdsLib/BdsAppLoader.c | 283 ++ ArmPkg/Library/BdsLib/BdsHelper.c | 178 +-- ArmPkg/Library/BdsLib/BdsInternal.h| 13 - ArmPkg/Library/BdsLib/BdsLib.inf | 38 -- ArmPkg/Library/BdsLib/BdsLinuxFdt.c| 572 - ArmPkg/Library/BdsLib/BdsLinuxLoader.h | 156 -- ArmPlatformPkg/ArmJunoPkg/ArmJuno.dsc | 6 +- ArmPlatformPkg/ArmJunoPkg/ArmJuno.fdf | 1 + ArmPlatformPkg/ArmPlatformPkg-2ndstage.dsc | 12 + ArmPlatformPkg/ArmPlatformPkg-2ndstage.fdf | 4 +- ArmPlatformPkg/ArmPlatformPkg.dec | 9 +- ArmPlatformPkg/ArmPlatformPkg.dsc | 13 + ArmPlatformPkg/ArmPlatformPkg.fdf | 4 +- .../ArmRealViewEbPkg/ArmRealViewEb-RTSM-MPCore.fdf | 4 +- .../ArmRealViewEb-RTSM-UniCore.fdf | 5 +- .../ArmRealViewEbPkg/ArmRealViewEb.dsc.inc | 18 +- .../ArmVExpressPkg/ArmVExpress-CTA15-A7.dsc| 7 +- .../ArmVExpressPkg/ArmVExpress-CTA15-A7.fdf| 3 + .../ArmVExpressPkg/ArmVExpress-CTA9x4.dsc | 8 +- .../ArmVExpressPkg/ArmVExpress-CTA9x4.fdf | 3 + .../ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc | 7 +- .../ArmVExpressPkg/ArmVExpress-FVP-AArch64.fdf | 3 + .../ArmVExpressPkg/ArmVExpress-RTSM-A15.dsc| 6 +- .../ArmVExpressPkg/ArmVExpress-RTSM-A15.fdf| 3 + .../ArmVExpressPkg/ArmVExpress-RTSM-A15_MPCore.dsc | 8 +- .../ArmVExpressPkg/ArmVExpress-RTSM-A15_MPCore.fdf | 3 + .../ArmVExpressPkg/ArmVExpress-RTSM-A9x4.dsc | 6 +- .../ArmVExpressPkg/ArmVExpress-RTSM-A9x4.fdf | 3 + .../ArmVExpress-RTSM-AEMv8Ax4-foundation.dsc | 1 - .../ArmVExpress-RTSM-AEMv8Ax4-foundation.fdf | 3 + .../ArmVExpressPkg/ArmVExpress-RTSM-AEMv8Ax4.dsc | 1 - .../ArmVExpressPkg/ArmVExpress-RTSM-AEMv8Ax4.fdf | 3 + ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc | 8 +- ArmPlatformPkg/Bds/Bds.c | 36 +- ArmPlatformPkg/Bds/Bds.inf | 18 +- ArmPlatformPkg/Bds/BdsHelper.c | 9 - ArmPlatformPkg/Bds/BdsInternal.h | 71 +-- ArmPlatformPkg/Bds/BootLinux.c | 124 + ArmPlatformPkg/Bds/BootMenu.c | 385 +- ArmPlatformPkg/Bds/BootOption.c| 131 + ArmPlatformPkg/Bds/BootOptionSupport.c | 111 ArmVirtPkg/ArmVirtQemu.dsc | 1 - BeagleBoardPkg/BeagleBoardPkg.dsc | 21 +- BeagleBoardPkg/BeagleBoardPkg.fdf | 3 + .../AndroidFastboot/AndroidFastbootApp.inf | 3 +- .../AndroidFastboot/Arm/BootAndroidBootImg.c | 48 +- 52 files changed, 702 insertions(+), 2650 deletions(-) delete mode 100644 ArmPkg/Library/BdsLib/AArch64/BdsLinuxLoader.c delete mode 100644 ArmPkg/Library/BdsLib/AArch64/BdsLinuxLoaderHelper.S delete mode 100644 ArmPkg/Library/BdsLib/Arm/BdsLinuxAtag.c delete mode 100644 ArmPkg/Library/BdsLib/Arm/BdsLinuxLoader.c delete mode 100644 ArmPkg/Library/BdsLib/BdsLinuxFdt.c delete mode 100644 ArmPkg/Library/BdsLib/BdsLinuxLoader.h create mode 100644 ArmPlatformPkg/Bds/BootLinux.c -- 2.1.1
[edk2] [BUG] NetworkPkg/UefiPxeBcDxe, MdeModulePkg/Netwrk/UefiPxeBcDxe: EfiPxeBcDhcp() should not return EFI_ALREADY_STARTED
From the UEFI specification, it is not expected EfiPxeBcDhcp() to return EFI_ALREADY_STARTED. But in the current implementation, EfiPxeBcDhcp() may return EFI_ALREADY_STARTED if the DHCP configuration has already been started. If I had to fix the issue, I would probably make this function returns EFI_SUCCESS if the DHCP has already been configured (ie: return EFI_ALREADY_STARTED). -- 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. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2548782 -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] [PATCH] MdePkg/ImageAuthentication.h: Fixed ARM toolchain error
Any feedback on this simple change? -Original Message- From: Olivier Martin [mailto:olivier.mar...@arm.com] Sent: 06 July 2015 16:47 To: michael.d.kin...@intel.com; liming@intel.com Cc: edk2-devel@lists.sourceforge.net; Olivier Martin Subject: [PATCH] MdePkg/ImageAuthentication.h: Fixed ARM toolchain error ARM Toolchain raised the error: last line of file ends without a newline Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Olivier Martin olivier.mar...@arm.com --- MdePkg/Include/Guid/ImageAuthentication.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/MdePkg/Include/Guid/ImageAuthentication.h b/MdePkg/Include/Guid/ImageAuthentication.h index 621a94f..c321383 100644 --- a/MdePkg/Include/Guid/ImageAuthentication.h +++ b/MdePkg/Include/Guid/ImageAuthentication.h @@ -349,4 +349,5 @@ extern EFI_GUID gEfiCertX509Sha384Guid; extern EFI_GUID gEfiCertX509Sha512Guid; extern EFI_GUID gEfiCertPkcs7Guid; -#endif \ No newline at end of file +#endif + -- 2.1.1 -- 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. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2548782 -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] [PATCH] ShellPkg: Increase PcdShellFileOperationSize
Ooops, I actually I have just realized I sent the patch to the wrong maintainer. On 14/07/15 15:39, Leif Lindholm wrote: On Tue, Jul 14, 2015 at 02:59:00PM +0100, Olivier Martin wrote: From: Brendan Jackman brendan.jack...@arm.com This improves performance for dumb filesystem drivers as block sizes tend to be more 4Kb size than 1000bit OK, so serious nitpicking, but: 4KB and 1000 bytes. Change those, and Reviewed-by: Leif Lindholm leif.lindh...@linaro.org size. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Brendan Jackman brendan.jack...@arm.com Reviewed-by: Olivier Martin olivier.mar...@arm.com --- ShellPkg/ShellPkg.dec | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ShellPkg/ShellPkg.dec b/ShellPkg/ShellPkg.dec index 32c0aff..b2f6326 100644 --- a/ShellPkg/ShellPkg.dec +++ b/ShellPkg/ShellPkg.dec @@ -100,7 +100,7 @@ gEfiShellPkgTokenSpaceGuid.PcdShellMapNameLength|50|UINT8|0x0009 ## This determines how many bytes are read out of files at a time for file operations (type, copy, etc...) - gEfiShellPkgTokenSpaceGuid.PcdShellFileOperationSize|1000|UINT32|0x000A + gEfiShellPkgTokenSpaceGuid.PcdShellFileOperationSize|0x1000|UINT32|0x000A [PcdsFixedAtBuild, PcdsPatchableInModule, PcdsDynamic, PcdsDynamicEx] ## This flag is used to control the protocols produced by the shell -- 2.1.1 -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel -- 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. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2548782 -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
[edk2] [PATCH] StdLib: Added BaseStackLib for ARM architectures
Stack protection support is required when building with ARM/AArch64 GCC. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Olivier Martin olivier.mar...@arm.com --- StdLib/StdLib.inc | 6 ++ 1 file changed, 6 insertions(+) diff --git a/StdLib/StdLib.inc b/StdLib/StdLib.inc index 51aeefa..7ee2e0a 100644 --- a/StdLib/StdLib.inc +++ b/StdLib/StdLib.inc @@ -74,10 +74,16 @@ NULL|ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib.inf NULL|StdLib/LibC/Softfloat/Softfloat.inf + # Add support for GCC stack protector + NULL|MdePkg/Library/BaseStackCheckLib/BaseStackCheckLib.inf + [LibraryClasses.AARCH64] # Use the softfloat library to cover missing hardfloat operations. NULL|StdLib/LibC/Softfloat/Softfloat.inf + # Add support for GCC stack protector + NULL|MdePkg/Library/BaseStackCheckLib/BaseStackCheckLib.inf + [Components] # BaseLib and BaseMemoryLib need to be built with the /GL- switch when using the Microsoft # tool chain. This is required so that the library functions can be resolved during -- 2.1.1 -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
[edk2] [PATCH] ShellPkg: Add optional 'tftp' EFI Shell command.
From: Ronald Cron ronald.c...@arm.com
This 'tftp' command allows to download a file from
a TFTP server.
A specific network interface can be chosen in case
there are multiple interfaces.
Change-Id: I07887ac2c3eeb52b871f493582f7612c41398f09
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ronald Cron ronald.c...@arm.com
Reviewed-by: Olivier Martin olivier.mar...@arm.com
---
ShellPkg/Include/Guid/ShellLibHiiGuid.h| 7 +
ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c| 875 +
.../UefiShellTftpCommandLib.c | 97 +++
.../UefiShellTftpCommandLib.h | 63 ++
.../UefiShellTftpCommandLib.inf| 61 ++
.../UefiShellTftpCommandLib.uni| Bin 0 - 8748 bytes
ShellPkg/ShellPkg.dec | 1 +
ShellPkg/ShellPkg.dsc | 3 +
8 files changed, 1107 insertions(+)
create mode 100644 ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c
create mode 100644
ShellPkg/Library/UefiShellTftpCommandLib/UefiShellTftpCommandLib.c
create mode 100644
ShellPkg/Library/UefiShellTftpCommandLib/UefiShellTftpCommandLib.h
create mode 100644
ShellPkg/Library/UefiShellTftpCommandLib/UefiShellTftpCommandLib.inf
create mode 100644
ShellPkg/Library/UefiShellTftpCommandLib/UefiShellTftpCommandLib.uni
diff --git a/ShellPkg/Include/Guid/ShellLibHiiGuid.h
b/ShellPkg/Include/Guid/ShellLibHiiGuid.h
index dc694f2..62c2e72 100644
--- a/ShellPkg/Include/Guid/ShellLibHiiGuid.h
+++ b/ShellPkg/Include/Guid/ShellLibHiiGuid.h
@@ -54,6 +54,12 @@
{ \
0xf3d301bb, 0xf4a5, 0x45a8, { 0xb0, 0xb7, 0xfa, 0x99, 0x9c, 0x62, 0x37,
0xae } \
}
+#define SHELL_TFTP_HII_GUID \
+ { \
+0x738a9314, 0x82c1, 0x4592, { 0x8f, 0xf7, 0xc1, 0xbd, 0xf1, 0xb2, 0x0e,
0xd4 } \
+ }
+
+
#define SHELL_BCFG_HII_GUID \
{ \
0x5f5f605d, 0x1583, 0x4a2d, {0xa6, 0xb2, 0xeb, 0x12, 0xda, 0xb4, 0xa2,
0xb6 } \
@@ -67,6 +73,7 @@ extern EFI_GUID gShellLevel1HiiGuid;
extern EFI_GUID gShellLevel2HiiGuid;
extern EFI_GUID gShellLevel3HiiGuid;
extern EFI_GUID gShellNetwork1HiiGuid;
+extern EFI_GUID gShellTftpHiiGuid;
extern EFI_GUID gShellBcfgHiiGuid;
#endif
diff --git a/ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c
b/ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c
new file mode 100644
index 000..84401d8
--- /dev/null
+++ b/ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c
@@ -0,0 +1,875 @@
+/** @file
+ The implementation for the 'tftp' Shell command.
+
+ Copyright (c) 2015, ARM Ltd. All rights reserved.BR
+
+ This program and the accompanying materials
+ are licensed and made available under the terms and conditions of the BSD
License
+ which accompanies this distribution. The full text of the license may be
found at
+ http://opensource.org/licenses/bsd-license.php.
+
+ THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN AS IS BASIS,
+ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+**/
+
+#include UefiShellTftpCommandLib.h
+
+/*
+ Constant strings and definitions related to the message indicating the
amount of
+ progress in the dowloading of a TFTP file.
+*/
+
+// Frame for the progression slider
+STATIC CONST CHAR16 mTftpProgressFrame[] = L[
];
+
+// Number of steps in the progression slider
+#define TFTP_PROGRESS_SLIDER_STEPS ((sizeof (mTftpProgressFrame) / sizeof
(CHAR16)) - 3)
+
+// Size in number of characters plus one (final zero) of the message to
+// indicate the progress of a TFTP download. The format is [(progress slider:
+// 40 characters)] (nb of KBytes downloaded so far: 7 characters) Kb. There
+// are thus the number of characters in mTftpProgressFrame[] plus 11 characters
+// (2 // spaces, Kb and seven characters for the number of KBytes).
+#define TFTP_PROGRESS_MESSAGE_SIZE ((sizeof (mTftpProgressFrame) / sizeof
(CHAR16)) + 12)
+
+// String to delete the TFTP progress message to be able to update it :
+// (TFTP_PROGRESS_MESSAGE_SIZE-1) '\b'
+STATIC CONST CHAR16 mTftpProgressDelete[] =
L\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b;
+
+STATIC BOOLEAN StringToUint16 (
+ IN CONST CHAR16 *ValueStr,
+ OUT UINT16*Value
+ );
+
+STATIC EFI_STATUS GetNicName (
+ IN EFI_HANDLE ControllerHandle,
+ IN UINTN Index,
+ OUT CHAR16 *NicName
+ );
+
+STATIC EFI_STATUS CreateServiceChildAndOpenProtocol (
+ IN EFI_HANDLE ControllerHandle,
+ IN EFI_GUID*ServiceBindingProtocolGuid,
+ IN EFI_GUID*ProtocolGuid,
+ OUT EFI_HANDLE *ChildHandle,
+ OUT VOID**Interface
+ );
+
+STATIC VOID CloseProtocolAndDestroyServiceChild (
+ IN EFI_HANDLE ControllerHandle,
+ IN EFI_GUID*ServiceBindingProtocolGuid,
+ IN EFI_GUID*ProtocolGuid,
+ IN EFI_HANDLE ChildHandle
+ );
+
+STATIC EFI_STATUS GetFileSize (
+ IN EFI_MTFTP4_PROTOCOL *Mtftp4,
+ IN CONST
[edk2] [PATCH] ShellPkg: Increase PcdShellFileOperationSize
From: Brendan Jackman brendan.jack...@arm.com This improves performance for dumb filesystem drivers as block sizes tend to be more 4Kb size than 1000bit size. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Brendan Jackman brendan.jack...@arm.com Reviewed-by: Olivier Martin olivier.mar...@arm.com --- ShellPkg/ShellPkg.dec | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ShellPkg/ShellPkg.dec b/ShellPkg/ShellPkg.dec index 32c0aff..b2f6326 100644 --- a/ShellPkg/ShellPkg.dec +++ b/ShellPkg/ShellPkg.dec @@ -100,7 +100,7 @@ gEfiShellPkgTokenSpaceGuid.PcdShellMapNameLength|50|UINT8|0x0009 ## This determines how many bytes are read out of files at a time for file operations (type, copy, etc...) - gEfiShellPkgTokenSpaceGuid.PcdShellFileOperationSize|1000|UINT32|0x000A + gEfiShellPkgTokenSpaceGuid.PcdShellFileOperationSize|0x1000|UINT32|0x000A [PcdsFixedAtBuild, PcdsPatchableInModule, PcdsDynamic, PcdsDynamicEx] ## This flag is used to control the protocols produced by the shell -- 2.1.1 -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] [PATCH] BaseTools/GenFw: Added AArch64 page-relative relocations
Sorry, I am bit slow today... Sorry again to ask clarification but what do you
mean by: So my position is that the first hunk should be dropped, and
instead, the patch should ensure that these relocations are only encountered in
binaries that have sufficient section alignment, and error out otherwise.
Would you like me to remove this condition if (ImageContext-Machine ==
EFI_IMAGE_MACHINE_AARCH64) {...}
And move this condition into each relocations that need to be page relative?
When you say because we know they should be loaded at a certain alignment
that is not communicated via its metadata. I had the impression and AndrewF
also confirmed my impression is the alignment is part of the PE/COFF headers.
Have a look at PE_COFF_LOADER_IMAGE_CONTEXT.SectionAlignment in
BaseTools/Source/C/Common/PeCoffLib.h and
https://msdn.microsoft.com/en-gb/library/ms809762.aspx.
-Original Message-
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
Sent: 10 July 2015 17:27
To: Olivier Martin
Cc: Leif Lindholm; edk2-devel@lists.sourceforge.net; Harry Liebel
Subject: Re: [PATCH] BaseTools/GenFw: Added AArch64 page-relative
relocations
On 10 July 2015 at 18:13, Olivier Martin olivier.mar...@arm.com wrote:
-Original Message-
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
Sent: 08 July 2015 18:50
To: Olivier Martin
Cc: Leif Lindholm; edk2-devel@lists.sourceforge.net; Harry Liebel
Subject: Re: [PATCH] BaseTools/GenFw: Added AArch64 page-relative
relocations
On 8 July 2015 at 16:57, Olivier Martin olivier.mar...@arm.com wrote:
When EDK2 is built for the small memory model with AArch64 LLVM,
some page-relative relocations (R_AARCH64_ADR_PREL_PG_HI21 and
its
R_AARCH64_LDST(16|32|64|128)_ABS_LO12_NC companions) that
were
not
supported before by EDK2 BaseTools are now needed.
This change adds support for these relocations in BaseTools.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Harry Liebel harry.lie...@arm.com
Reviewed-by: Olivier Martin olivier.mar...@arm.com
I think all the relocation arithmetic looks fine.
I do have a concern about the consequences of using the small C model
in this way: nothing in the metadata of the resulting PE/COFF images
reflects that the 4 KB alignment needs to be preserved in order to
successfully execute them, so you are essentially producing corrupt
images. Every PE/COFF loader needs to be modified (including the ones
in GRUB and shim, for instance) to prevent such images from being
loaded in an incorrect way. (I know that most PE/COFF loaders use
AllocatePages() which aligns these binaries at 4 KB implicitly, but
this is not
mandatory)
So the correct way to do this would be to only use the small C model
when this alignment can be guaranteed, i.e., .text and .data are both
aligned at 4 KB. With the latest GenFw changes in place (which sets
PE/COFF section alignment to the largest ELF input section alignment
it encounters), the small C model works correctly since the PE/COFF
loaders adhere to the PE/COFF section alignment. As a bonus, the ELF
and PE/COFF images will be laid out identically in memory, so all the
recalculation arithmetic becomes unnecessary (although it probably
makes sense to perform some checks
here)
If I add support in 'MdePkg/Library/BasePeCoffLib' to prevent the image
loading if the .text sections are not aligned on 4K when these page-relative
relocations are used, would you consider this patchset?
In practical this error should never be exposed as AllocatePages() allocate
the buffer on a 4K boundary.
The downside, of course, is that 4 KB alignment for both .text and
.data wastes a lot of space: 3.5 KB only for the padding between the
PE/COFF header and the start of .text, and 2 KB on average between .text
and .data.
Due to the compression of non-XIP binaries, this is not such a
penalty, but for XIP it is prohibitive (even if these typically don't
have a .data section)
I am going to have a look at GenFv to figure out if there is some way
to work around this, i.e., drop the PE/COFF headers or move them in
some way.
In the mean time, I think this patch is good except the first hunk.
The small model relocation arithmetic can be merged separately, I
think, and the logic and policies around how and when to relocate
PE/COFF images can be addressed in a followup patch.
Sorry, I am not sure to understand which part of the patch you would like
me to split...
My general point is that such relocations should only be allowed if the
section
alignment is at least 4 KB. This results in bigger files generally, so I have
already implemented support in GenFw for smaller file alignment if the
section alignment is = 4 KB (this is allowed by the PE/COFF spec) Next step
is
to massage GenFv to allow such images if it manages to place it such that the
section
[edk2] [PATCH 3/8] ArmPlatformPkg: Add the LinuxLoader.efi EFI application
From: Ronald Cron ronald.c...@arm.com Add the legacy Linux Loader EFI application to the ARM development platforms. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ronald Cron ronald.c...@arm.com Reviewed-by: Olivier Martin olivier.mar...@arm.com --- ArmPlatformPkg/ArmJunoPkg/ArmJuno.fdf | 1 + ArmPlatformPkg/ArmPlatformPkg-2ndstage.dsc | 12 ArmPlatformPkg/ArmPlatformPkg-2ndstage.fdf | 4 +++- ArmPlatformPkg/ArmPlatformPkg.dsc | 13 + ArmPlatformPkg/ArmPlatformPkg.fdf | 4 +++- .../ArmRealViewEbPkg/ArmRealViewEb-RTSM-MPCore.fdf | 4 +++- .../ArmRealViewEbPkg/ArmRealViewEb-RTSM-UniCore.fdf | 5 - ArmPlatformPkg/ArmRealViewEbPkg/ArmRealViewEb.dsc.inc | 17 +++-- ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA15-A7.dsc | 2 +- ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA15-A7.fdf | 3 +++ ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA9x4.dsc| 2 +- ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA9x4.fdf| 3 +++ .../ArmVExpressPkg/ArmVExpress-FVP-AArch64.fdf | 3 +++ ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15.dsc | 2 +- ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15.fdf | 3 +++ .../ArmVExpressPkg/ArmVExpress-RTSM-A15_MPCore.dsc | 2 +- .../ArmVExpressPkg/ArmVExpress-RTSM-A15_MPCore.fdf | 3 +++ ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A9x4.dsc | 3 ++- ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A9x4.fdf | 3 +++ .../ArmVExpress-RTSM-AEMv8Ax4-foundation.fdf| 3 +++ .../ArmVExpressPkg/ArmVExpress-RTSM-AEMv8Ax4.fdf| 3 +++ ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc | 5 - BeagleBoardPkg/BeagleBoardPkg.dsc | 14 +- BeagleBoardPkg/BeagleBoardPkg.fdf | 3 +++ 24 files changed, 104 insertions(+), 13 deletions(-) diff --git a/ArmPlatformPkg/ArmJunoPkg/ArmJuno.fdf b/ArmPlatformPkg/ArmJunoPkg/ArmJuno.fdf index 2dbf0e6..db70609 100644 --- a/ArmPlatformPkg/ArmJunoPkg/ArmJuno.fdf +++ b/ArmPlatformPkg/ArmJunoPkg/ArmJuno.fdf @@ -191,6 +191,7 @@ FvNameGuid = B73FE497-B92E-416e-8326-45AD0D270092 # UEFI applications # INF ShellBinPkg/UefiShell/UefiShell.inf + INF ArmPkg/Application/LinuxLoader/LinuxLoader.inf # # Juno platform driver diff --git a/ArmPlatformPkg/ArmPlatformPkg-2ndstage.dsc b/ArmPlatformPkg/ArmPlatformPkg-2ndstage.dsc index 4cfb913..76415fe 100644 --- a/ArmPlatformPkg/ArmPlatformPkg-2ndstage.dsc +++ b/ArmPlatformPkg/ArmPlatformPkg-2ndstage.dsc @@ -89,6 +89,11 @@ # Networking Requirements for ArmPlatformPkg/Bds NetLib|MdeModulePkg/Library/DxeNetLib/DxeNetLib.inf + # These libraries are used by the dynamic EFI Shell commands + ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf + FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf + SortLib|MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf + # EBL Related Libraries EblCmdLib|ArmPlatformPkg/Library/EblCmdLib/EblCmdLib.inf EfiFileLib|EmbeddedPkg/Library/EfiFileLib/EfiFileLib.inf @@ -298,6 +303,11 @@ gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiLoaderCode|20 gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiLoaderData|0 + # We want to use the Shell Libraries but don't want it to initialise + # automatically. We initialise the libraries when the command is called by the + # Shell. + gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE + # # ARM Pcds # @@ -369,3 +379,5 @@ MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf ArmPlatformPkg/Bds/Bds.inf + # Legacy Linux Loader + ArmPkg/Application/LinuxLoader/LinuxLoader.inf diff --git a/ArmPlatformPkg/ArmPlatformPkg-2ndstage.fdf b/ArmPlatformPkg/ArmPlatformPkg-2ndstage.fdf index 86a94c1..9c35ebb 100644 --- a/ArmPlatformPkg/ArmPlatformPkg-2ndstage.fdf +++ b/ArmPlatformPkg/ArmPlatformPkg-2ndstage.fdf @@ -1,5 +1,5 @@ # -# Copyright (c) 2011-2014, ARM Limited. All rights reserved. +# Copyright (c) 2011-2015, ARM Limited. All rights reserved. # # This program and the accompanying materials # are licensed and made available under the terms and conditions of the BSD License @@ -129,6 +129,8 @@ FvNameGuid = 5eda4200-2c5f-43cb-9da3-0baf74b1b30c INF MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf INF ArmPlatformPkg/Bds/Bds.inf + # Legacy Linux Loader + INF ArmPkg/Application/LinuxLoader/LinuxLoader.inf [FV.FVMAIN_COMPACT] FvAlignment= 8 diff --git a/ArmPlatformPkg/ArmPlatformPkg.dsc b/ArmPlatformPkg/ArmPlatformPkg.dsc index f9f217c..0147146 100644 --- a/ArmPlatformPkg/ArmPlatformPkg.dsc +++ b/ArmPlatformPkg/ArmPlatformPkg.dsc @@ -88,6 +88,11 @@ # Networking Requirements for ArmPlatformPkg/Bds NetLib|MdeModulePkg/Library/DxeNetLib/DxeNetLib.inf + # These libraries are used by the dynamic EFI Shell commands + ShellLib|ShellPkg/Library/UefiShellLib
[edk2] [PATCH 6/8] ArmPlatformPkg/Bds: Added support for booting legacy kernel from BDS
When PcdBdsLinuxSupport is enabled, users can create boot
entries for the legacy EFI Linux loader.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Olivier Martin olivier.mar...@arm.com
Reviewed-by: Ronald Cron ronald.c...@arm.com
---
ArmPlatformPkg/ArmPlatformPkg.dec | 3 +
ArmPlatformPkg/Bds/Bds.inf| 4 +
ArmPlatformPkg/Bds/BdsHelper.c| 9 ---
ArmPlatformPkg/Bds/BdsInternal.h | 26 --
ArmPlatformPkg/Bds/BootLinux.c| 124 +
ArmPlatformPkg/Bds/BootMenu.c | 161 +-
6 files changed, 274 insertions(+), 53 deletions(-)
create mode 100644 ArmPlatformPkg/Bds/BootLinux.c
diff --git a/ArmPlatformPkg/ArmPlatformPkg.dec
b/ArmPlatformPkg/ArmPlatformPkg.dec
index be0919b..45aeaee 100644
--- a/ArmPlatformPkg/ArmPlatformPkg.dec
+++ b/ArmPlatformPkg/ArmPlatformPkg.dec
@@ -61,6 +61,9 @@
# we assume the OS will handle the FrameBuffer from the UEFI GOP information.
gArmPlatformTokenSpaceGuid.PcdGopDisableOnExitBootServices|FALSE|BOOLEAN|0x003D
+ # Enable Legacy Linux support in the BDS
+ gArmPlatformTokenSpaceGuid.PcdBdsLinuxSupport|TRUE|BOOLEAN|0x002E
+
[PcdsFixedAtBuild.common]
gArmPlatformTokenSpaceGuid.PcdCoreCount|1|UINT32|0x0039
gArmPlatformTokenSpaceGuid.PcdClusterCount|1|UINT32|0x0038
diff --git a/ArmPlatformPkg/Bds/Bds.inf b/ArmPlatformPkg/Bds/Bds.inf
index 3b6ffc3..06e8d91 100644
--- a/ArmPlatformPkg/Bds/Bds.inf
+++ b/ArmPlatformPkg/Bds/Bds.inf
@@ -27,6 +27,7 @@
[Sources]
Bds.c
BdsHelper.c
+ BootLinux.c
BootMenu.c
BootOption.c
BootOptionSupport.c
@@ -72,6 +73,9 @@
gEfiDhcp4ServiceBindingProtocolGuid
gEfiMtftp4ServiceBindingProtocolGuid
+[FeaturePcd]
+ gArmPlatformTokenSpaceGuid.PcdBdsLinuxSupport
+
[Pcd]
gArmPlatformTokenSpaceGuid.PcdFirmwareVendor
gArmPlatformTokenSpaceGuid.PcdDefaultBootDescription
diff --git a/ArmPlatformPkg/Bds/BdsHelper.c b/ArmPlatformPkg/Bds/BdsHelper.c
index b3003e9..732292c 100644
--- a/ArmPlatformPkg/Bds/BdsHelper.c
+++ b/ArmPlatformPkg/Bds/BdsHelper.c
@@ -256,15 +256,6 @@ GetHIInputBoolean (
}
}
-BOOLEAN
-HasFilePathEfiExtension (
- IN CHAR16* FilePath
- )
-{
- return (StrCmp (FilePath + (StrSize (FilePath) / sizeof (CHAR16)) - 5,
L.EFI) == 0) ||
- (StrCmp (FilePath + (StrSize (FilePath) / sizeof (CHAR16)) - 5,
L.efi) == 0);
-}
-
// Return the last non end-type Device Path Node from a Device Path
EFI_DEVICE_PATH*
GetLastDevicePathNode (
diff --git a/ArmPlatformPkg/Bds/BdsInternal.h b/ArmPlatformPkg/Bds/BdsInternal.h
index fe4fd79..ddf5308 100644
--- a/ArmPlatformPkg/Bds/BdsInternal.h
+++ b/ArmPlatformPkg/Bds/BdsInternal.h
@@ -1,6 +1,6 @@
/** @file
*
-* Copyright (c) 2011-2014, ARM Limited. All rights reserved.
+* Copyright (c) 2011-2015, ARM Limited. All rights reserved.
*
* This program and the accompanying materials
* are licensed and made available under the terms and conditions of the BSD
License
@@ -79,6 +79,12 @@ typedef struct _BDS_LOAD_OPTION_SUPPORT {
#define LOAD_OPTION_ENTRY_FROM_LINK(a) BASE_CR(a, BDS_LOAD_OPTION_ENTRY, Link)
#define LOAD_OPTION_FROM_LINK(a)((BDS_LOAD_OPTION_ENTRY*)BASE_CR(a,
BDS_LOAD_OPTION_ENTRY, Link))-BdsLoadOption
+// GUID of the EFI Linux Loader
+extern CONST EFI_GUID mLinuxLoaderAppGuid;
+
+// Device path of the EFI Linux Loader in the Firmware Volume
+extern EFI_DEVICE_PATH* mLinuxLoaderDevicePath;
+
EFI_STATUS
BootDeviceListSupportedInit (
IN OUT LIST_ENTRY *SupportedDeviceList
@@ -141,11 +147,6 @@ GetHIInputBoolean (
OUT BOOLEAN *Value
);
-BOOLEAN
-HasFilePathEfiExtension (
- IN CHAR16* FilePath
- );
-
EFI_DEVICE_PATH*
GetLastDevicePathNode (
IN EFI_DEVICE_PATH* DevicePath
@@ -260,4 +261,17 @@ EmptyCallbackFunction (
IN VOID *Context
);
+/**
+ * This function check if the DevicePath defines an EFI binary
+ *
+ * This function is used when the BDS support Linux loader to
+ * detect if the binary is an EFI application or potentially a
+ * Linux kernel.
+ */
+EFI_STATUS
+IsEfiBinary (
+ IN EFI_DEVICE_PATH* DevicePath,
+ OUT BOOLEAN *EfiBinary
+ );
+
#endif /* _BDSINTERNAL_H_ */
diff --git a/ArmPlatformPkg/Bds/BootLinux.c b/ArmPlatformPkg/Bds/BootLinux.c
new file mode 100644
index 000..0445e89
--- /dev/null
+++ b/ArmPlatformPkg/Bds/BootLinux.c
@@ -0,0 +1,124 @@
+/** @file
+*
+* Copyright (c) 2011 - 2015, ARM Limited. All rights reserved.
+*
+* This program and the accompanying materials
+* are licensed and made available under the terms and conditions of the BSD
License
+* which accompanies this distribution. The full text of the license may be
found at
+* http://opensource.org/licenses/bsd-license.php
+*
+* THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN AS IS BASIS,
+* WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR
IMPLIED.
+*
+**/
+
+#include BdsInternal.h
+
+// This GUID is defined in the INGF file of ArmPkg
[edk2] [PATCH 7/8] ArmPlatformPkg: Use LinuxLoader.efi for the default boot entry
There are still ARM/AArch64 Linux kernels that do not support EFI Stub. By using the EFI Linux loader as the default option we can boot any Linux kernel from UEFI as Linux kernel with EFI stub can also be booted with the legacy way. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Olivier Martin olivier.mar...@arm.com Reviewed-by: Ronald Cron ronald.c...@arm.com --- ArmPlatformPkg/ArmJunoPkg/ArmJuno.dsc | 5 ++--- ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA15-A7.dsc| 4 ++-- ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA9x4.dsc | 5 +++-- ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc | 5 ++--- ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15.dsc| 3 ++- ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15_MPCore.dsc | 5 +++-- 6 files changed, 14 insertions(+), 13 deletions(-) diff --git a/ArmPlatformPkg/ArmJunoPkg/ArmJuno.dsc b/ArmPlatformPkg/ArmJunoPkg/ArmJuno.dsc index 9860cf0..09ec5b3 100644 --- a/ArmPlatformPkg/ArmJunoPkg/ArmJuno.dsc +++ b/ArmPlatformPkg/ArmJunoPkg/ArmJuno.dsc @@ -146,10 +146,9 @@ # # ARM OS Loader # - gArmPlatformTokenSpaceGuid.PcdDefaultBootDescription|LLinux from NOR Flash - gArmPlatformTokenSpaceGuid.PcdDefaultBootDevicePath|LVenHw(E7223039-5836-41E1-B542-D7EC736C5E59)/Image - # Support the Linux EFI stub by default + gArmPlatformTokenSpaceGuid.PcdDefaultBootDescription|LEFI Linux from NOR Flash + gArmPlatformTokenSpaceGuid.PcdDefaultBootDevicePath|LVenHw(E7223039-5836-41E1-B542-D7EC736C5E59)/Image gArmPlatformTokenSpaceGuid.PcdDefaultBootArgument|Lconsole=ttyAMA0,115200 earlycon=pl011,0x7ff8 root=/dev/sda1 rootwait verbose debug # Use the serial console (ConIn ConOut) and the Graphic driver (ConOut) diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA15-A7.dsc b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA15-A7.dsc index 50bb556..c1e3513 100644 --- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA15-A7.dsc +++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA15-A7.dsc @@ -182,8 +182,8 @@ # ARM OS Loader # gArmPlatformTokenSpaceGuid.PcdDefaultBootDescription|LLinux from NorFlash - gArmPlatformTokenSpaceGuid.PcdDefaultBootDevicePath|LVenHw(1F15DA3C-37FF-4070-B471-BB4AF12A724A)/Image - gArmPlatformTokenSpaceGuid.PcdDefaultBootArgument|console=ttyAMA0,38400 earlyprintk debug verbose + gArmPlatformTokenSpaceGuid.PcdDefaultBootDevicePath|LFv(73DCB643-3862-4904-9076-A94AF1890243)/LinuxLoader.efi + gArmPlatformTokenSpaceGuid.PcdDefaultBootArgument|LVenHw(E7223039-5836-41E1-B542-D7EC736C5E59)/kernel -c \console=ttyAMA0,38400 earlyprintk debug verbose\ # Use the serial console (ConIn ConOut) and the Graphic driver (ConOut) # PL111 - CLCD diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA9x4.dsc b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA9x4.dsc index 18cc978..b7a43fc 100644 --- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA9x4.dsc +++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA9x4.dsc @@ -180,8 +180,9 @@ # # ARM OS Loader # - gArmPlatformTokenSpaceGuid.PcdDefaultBootDescription|LNorFlash - gArmPlatformTokenSpaceGuid.PcdDefaultBootDevicePath|LVenHw(1F15DA3C-37FF-4070-B471-BB4AF12A724A)/Image + gArmPlatformTokenSpaceGuid.PcdDefaultBootDescription|LLinux from NorFlash + gArmPlatformTokenSpaceGuid.PcdDefaultBootDevicePath|LFv(1A9B3625-5286-4FA6-AF5F-8EABC481F3CC)/LinuxLoader.efi + gArmPlatformTokenSpaceGuid.PcdDefaultBootArgument|LVenHw(E7223039-5836-41E1-B542-D7EC736C5E59)/kernel -c \console=ttyAMA0,38400 earlyprintk debug verbose\ # Use the serial console (ConIn ConOut) and the Graphic driver (ConOut) gArmPlatformTokenSpaceGuid.PcdDefaultConOutPaths|LVenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenPcAnsi();VenHw(407B4008-BF5B-11DF-9547-CF16E0D72085) diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc index 1b6134f..119ba3a 100644 --- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc +++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc @@ -174,9 +174,8 @@ # ARM OS Loader # gArmPlatformTokenSpaceGuid.PcdDefaultBootDescription|LLinux from SemiHosting - gArmPlatformTokenSpaceGuid.PcdDefaultBootDevicePath|LVenHw(C5B9C74A-6D72-4719-99AB-C59F199091EB)/Image - gArmPlatformTokenSpaceGuid.PcdDefaultBootInitrdPath|LVenHw(C5B9C74A-6D72-4719-99AB-C59F199091EB)/filesystem.cpio.gz - gArmPlatformTokenSpaceGuid.PcdDefaultBootArgument|Lconsole=ttyAMA0 earlycon=pl011,0x1c09 debug user_debug=31 loglevel=9 + gArmPlatformTokenSpaceGuid.PcdDefaultBootDevicePath|LFv(87940482-FC81-41C3-87E6-399CF85AC8A0)/LinuxLoader.efi + gArmPlatformTokenSpaceGuid.PcdDefaultBootArgument|LVenHw(C5B9C74A-6D72-4719-99AB-C59F199091EB)/Image -f VenHw(C5B9C74A-6D72-4719-99AB-C59F199091EB)/filesystem.cpio.gz -c \console=ttyAMA0 earlycon=pl011,0x1c09 debug user_debug=31 loglevel=9\ # Use
[edk2] [PATCH 4/8] ArmPkg/BdsLib: Remove Linux loader from BdsLib
This change removes the embedded Linux Loder from BdsLib. BdsLib becomes OS agnostic. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Olivier Martin olivier.mar...@arm.com Reviewed-by: Ronald Cron ronald.c...@arm.com --- ArmPkg/Include/Library/BdsLib.h| 37 -- ArmPkg/Library/BdsLib/AArch64/BdsLinuxLoader.c | 355 - .../Library/BdsLib/AArch64/BdsLinuxLoaderHelper.S | 58 --- ArmPkg/Library/BdsLib/Arm/BdsLinuxAtag.c | 173 --- ArmPkg/Library/BdsLib/Arm/BdsLinuxLoader.c | 323 ArmPkg/Library/BdsLib/BdsHelper.c | 178 +-- ArmPkg/Library/BdsLib/BdsInternal.h| 13 - ArmPkg/Library/BdsLib/BdsLib.inf | 38 -- ArmPkg/Library/BdsLib/BdsLinuxFdt.c| 572 - ArmPkg/Library/BdsLib/BdsLinuxLoader.h | 156 -- ArmPlatformPkg/Bds/Bds.inf | 4 + ArmPlatformPkg/Bds/BootOption.c| 35 +- 12 files changed, 8 insertions(+), 1934 deletions(-) delete mode 100644 ArmPkg/Library/BdsLib/AArch64/BdsLinuxLoader.c delete mode 100644 ArmPkg/Library/BdsLib/AArch64/BdsLinuxLoaderHelper.S delete mode 100644 ArmPkg/Library/BdsLib/Arm/BdsLinuxAtag.c delete mode 100644 ArmPkg/Library/BdsLib/Arm/BdsLinuxLoader.c delete mode 100644 ArmPkg/Library/BdsLib/BdsLinuxFdt.c delete mode 100644 ArmPkg/Library/BdsLib/BdsLinuxLoader.h diff --git a/ArmPkg/Include/Library/BdsLib.h b/ArmPkg/Include/Library/BdsLib.h index 3d9e195..c58f47e 100644 --- a/ArmPkg/Include/Library/BdsLib.h +++ b/ArmPkg/Include/Library/BdsLib.h @@ -138,43 +138,6 @@ BootOptionAllocateBootIndex ( ); /** - Start a Linux kernel from a Device Path - - @param LinuxKernel Device Path to the Linux Kernel - @param ParametersLinux kernel arguments - - @retval EFI_SUCCESS All drivers have been connected - @retval EFI_NOT_FOUND The Linux kernel Device Path has not been found - @retval EFI_OUT_OF_RESOURCES There is not enough resource memory to store the matching results. - -**/ -EFI_STATUS -BdsBootLinuxAtag ( - IN EFI_DEVICE_PATH_PROTOCOL* LinuxKernelDevicePath, - IN EFI_DEVICE_PATH_PROTOCOL* InitrdDevicePath, - IN CONST CHAR8* Arguments - ); - -/** - Start a Linux kernel from a Device Path - - @param[in] LinuxKernelDevicePath Device Path to the Linux Kernel - @param[in] InitrdDevicePath Device Path to the Initrd - @param[in] Arguments Linux kernel arguments - - @retval EFI_SUCCESS All drivers have been connected - @retval EFI_NOT_FOUND The Linux kernel Device Path has not been found - @retval EFI_OUT_OF_RESOURCES There is not enough resource memory to store the matching results. - -**/ -EFI_STATUS -BdsBootLinuxFdt ( - IN EFI_DEVICE_PATH_PROTOCOL* LinuxKernelDevicePath, - IN EFI_DEVICE_PATH_PROTOCOL* InitrdDevicePath, - IN CONST CHAR8* Arguments - ); - -/** Start an EFI Application from a Device Path @param ParentImageHandle Handle of the calling image diff --git a/ArmPkg/Library/BdsLib/AArch64/BdsLinuxLoader.c b/ArmPkg/Library/BdsLib/AArch64/BdsLinuxLoader.c deleted file mode 100644 index 7651597..000 --- a/ArmPkg/Library/BdsLib/AArch64/BdsLinuxLoader.c +++ /dev/null @@ -1,355 +0,0 @@ -/** @file -* -* Copyright (c) 2011-2014, ARM Limited. All rights reserved. -* -* This program and the accompanying materials -* are licensed and made available under the terms and conditions of the BSD License -* which accompanies this distribution. The full text of the license may be found at -* http://opensource.org/licenses/bsd-license.php -* -* THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN AS IS BASIS, -* WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED. -* -**/ -#include Library/ArmGicLib.h -#include Ppi/ArmMpCoreInfo.h -#include Library/IoLib.h -#include Guid/Fdt.h -#include libfdt.h - -#include BdsInternal.h -#include BdsLinuxLoader.h - -/* - Linux kernel booting: Look at the doc in the Kernel source : -Documentation/arm64/booting.txt - The kernel image must be placed at the start of the memory to be used by the - kernel (2MB aligned) + 0x8. - - The Device tree blob is expected to be under 2MB and be within the first 512MB - of kernel memory and be 2MB aligned. - - A Flattened Device Tree (FDT) used to boot linux needs to be updated before - the kernel is started. It needs to indicate how secondary cores are brought up - and where they are waiting before loading Linux. The FDT also needs to hold - the correct kernel command line and filesystem RAM-disk information. - At the moment we do not fully support generating this FDT information at - runtime. A prepared FDT should be provided at boot. FDT is the only supported - method for booting the AArch64 Linux kernel. - - Linux does not use any runtime services at this time
[edk2] [PATCH 8/8] ArmVirtPkg/ArmVirtQemu.dsc: Remove Linux specific boot path
PcdDefaultBootType has been removed when the embedded Linux Loader has been removed from BdsLib. The boot arguments (defined by PcdDefaultBootArgument) are now always targetting EFI applications. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Olivier Martin olivier.mar...@arm.com Reviewed-by: Ronald Cron ronald.c...@arm.com --- ArmVirtPkg/ArmVirtQemu.dsc | 1 - 1 file changed, 1 deletion(-) diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc index fbc2b12..0d4f4b0 100644 --- a/ArmVirtPkg/ArmVirtQemu.dsc +++ b/ArmVirtPkg/ArmVirtQemu.dsc @@ -133,7 +133,6 @@ gArmPlatformTokenSpaceGuid.PcdDefaultBootDescription|LLinux (EFI stub) on virtio31:hd0:part0 gArmPlatformTokenSpaceGuid.PcdDefaultBootDevicePath|LVenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A)/HD(1,MBR,0x,0x3F,0x19FC0)/Image gArmPlatformTokenSpaceGuid.PcdDefaultBootArgument|root=/dev/vda2 console=ttyAMA0 earlycon uefi_debug - gArmPlatformTokenSpaceGuid.PcdDefaultBootType|0 # # Settings for ARM BDS -- use the serial console (ConIn ConOut). -- 2.1.1 -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
[edk2] [PATCH 7/8] ArmPlatformPkg: Use LinuxLoader.efi for the default boot entry
There are still ARM/AArch64 Linux kernels that do not support EFI Stub. By using the EFI Linux loader as the default option we can boot any Linux kernel from UEFI as Linux kernel with EFI stub can also be booted with the legacy way. Change-Id: I23aa84ae46c3fbad72380c4bab92ec86fbca0c24 --- ArmPlatformPkg/ArmJunoPkg/ArmJuno.dsc | 5 ++--- ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA15-A7.dsc| 4 ++-- ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA9x4.dsc | 5 +++-- ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc | 5 ++--- ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15.dsc| 3 ++- ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15_MPCore.dsc | 5 +++-- 6 files changed, 14 insertions(+), 13 deletions(-) diff --git a/ArmPlatformPkg/ArmJunoPkg/ArmJuno.dsc b/ArmPlatformPkg/ArmJunoPkg/ArmJuno.dsc index 9860cf0..09ec5b3 100644 --- a/ArmPlatformPkg/ArmJunoPkg/ArmJuno.dsc +++ b/ArmPlatformPkg/ArmJunoPkg/ArmJuno.dsc @@ -146,10 +146,9 @@ # # ARM OS Loader # - gArmPlatformTokenSpaceGuid.PcdDefaultBootDescription|LLinux from NOR Flash - gArmPlatformTokenSpaceGuid.PcdDefaultBootDevicePath|LVenHw(E7223039-5836-41E1-B542-D7EC736C5E59)/Image - # Support the Linux EFI stub by default + gArmPlatformTokenSpaceGuid.PcdDefaultBootDescription|LEFI Linux from NOR Flash + gArmPlatformTokenSpaceGuid.PcdDefaultBootDevicePath|LVenHw(E7223039-5836-41E1-B542-D7EC736C5E59)/Image gArmPlatformTokenSpaceGuid.PcdDefaultBootArgument|Lconsole=ttyAMA0,115200 earlycon=pl011,0x7ff8 root=/dev/sda1 rootwait verbose debug # Use the serial console (ConIn ConOut) and the Graphic driver (ConOut) diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA15-A7.dsc b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA15-A7.dsc index 50bb556..c1e3513 100644 --- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA15-A7.dsc +++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA15-A7.dsc @@ -182,8 +182,8 @@ # ARM OS Loader # gArmPlatformTokenSpaceGuid.PcdDefaultBootDescription|LLinux from NorFlash - gArmPlatformTokenSpaceGuid.PcdDefaultBootDevicePath|LVenHw(1F15DA3C-37FF-4070-B471-BB4AF12A724A)/Image - gArmPlatformTokenSpaceGuid.PcdDefaultBootArgument|console=ttyAMA0,38400 earlyprintk debug verbose + gArmPlatformTokenSpaceGuid.PcdDefaultBootDevicePath|LFv(73DCB643-3862-4904-9076-A94AF1890243)/LinuxLoader.efi + gArmPlatformTokenSpaceGuid.PcdDefaultBootArgument|LVenHw(E7223039-5836-41E1-B542-D7EC736C5E59)/kernel -c \console=ttyAMA0,38400 earlyprintk debug verbose\ # Use the serial console (ConIn ConOut) and the Graphic driver (ConOut) # PL111 - CLCD diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA9x4.dsc b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA9x4.dsc index 18cc978..b7a43fc 100644 --- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA9x4.dsc +++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA9x4.dsc @@ -180,8 +180,9 @@ # # ARM OS Loader # - gArmPlatformTokenSpaceGuid.PcdDefaultBootDescription|LNorFlash - gArmPlatformTokenSpaceGuid.PcdDefaultBootDevicePath|LVenHw(1F15DA3C-37FF-4070-B471-BB4AF12A724A)/Image + gArmPlatformTokenSpaceGuid.PcdDefaultBootDescription|LLinux from NorFlash + gArmPlatformTokenSpaceGuid.PcdDefaultBootDevicePath|LFv(1A9B3625-5286-4FA6-AF5F-8EABC481F3CC)/LinuxLoader.efi + gArmPlatformTokenSpaceGuid.PcdDefaultBootArgument|LVenHw(E7223039-5836-41E1-B542-D7EC736C5E59)/kernel -c \console=ttyAMA0,38400 earlyprintk debug verbose\ # Use the serial console (ConIn ConOut) and the Graphic driver (ConOut) gArmPlatformTokenSpaceGuid.PcdDefaultConOutPaths|LVenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenPcAnsi();VenHw(407B4008-BF5B-11DF-9547-CF16E0D72085) diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc index 1b6134f..119ba3a 100644 --- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc +++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc @@ -174,9 +174,8 @@ # ARM OS Loader # gArmPlatformTokenSpaceGuid.PcdDefaultBootDescription|LLinux from SemiHosting - gArmPlatformTokenSpaceGuid.PcdDefaultBootDevicePath|LVenHw(C5B9C74A-6D72-4719-99AB-C59F199091EB)/Image - gArmPlatformTokenSpaceGuid.PcdDefaultBootInitrdPath|LVenHw(C5B9C74A-6D72-4719-99AB-C59F199091EB)/filesystem.cpio.gz - gArmPlatformTokenSpaceGuid.PcdDefaultBootArgument|Lconsole=ttyAMA0 earlycon=pl011,0x1c09 debug user_debug=31 loglevel=9 + gArmPlatformTokenSpaceGuid.PcdDefaultBootDevicePath|LFv(87940482-FC81-41C3-87E6-399CF85AC8A0)/LinuxLoader.efi + gArmPlatformTokenSpaceGuid.PcdDefaultBootArgument|LVenHw(C5B9C74A-6D72-4719-99AB-C59F199091EB)/Image -f VenHw(C5B9C74A-6D72-4719-99AB-C59F199091EB)/filesystem.cpio.gz -c \console=ttyAMA0 earlycon=pl011,0x1c09 debug user_debug=31 loglevel=9\ # Use the serial console (ConIn ConOut) and the Graphic driver (ConOut)
[edk2] [PATCH 1/8] ArmPkg/BdsLib: Replaced BdsLoadApplication() by LocateEfiApplicationInFv()
Change-Id: I34777219b14393759f57dc660bd386da0542376a
---
ArmPkg/Include/Library/BdsLib.h | 52 ---
ArmPkg/Library/BdsLib/BdsAppLoader.c | 283 ---
ArmPlatformPkg/Bds/Bds.inf | 3 +
ArmPlatformPkg/Bds/BootMenu.c| 24 ++-
4 files changed, 250 insertions(+), 112 deletions(-)
diff --git a/ArmPkg/Include/Library/BdsLib.h b/ArmPkg/Include/Library/BdsLib.h
index c6416db..3d9e195 100644
--- a/ArmPkg/Include/Library/BdsLib.h
+++ b/ArmPkg/Include/Library/BdsLib.h
@@ -193,24 +193,6 @@ BdsStartEfiApplication (
IN VOID* LoadOptions
);
-/**
- Start an EFI Application from any Firmware Volume
-
- @param EfiAppEFI Application Name
-
- @retval EFI_SUCCESS All drivers have been connected
- @retval EFI_NOT_FOUND The Linux kernel Device Path has not been found
- @retval EFI_OUT_OF_RESOURCES There is not enough resource memory to store
the matching results.
-
-**/
-EFI_STATUS
-BdsLoadApplication (
- IN EFI_HANDLE ParentImageHandle,
- IN CHAR16* EfiApp,
- IN UINTN LoadOptionsSize,
- IN VOID* LoadOptions
- );
-
EFI_STATUS
BdsLoadImage (
IN EFI_DEVICE_PATH *DevicePath,
@@ -227,4 +209,38 @@ ShutdownUefiBootServices (
VOID
);
+/**
+ Locate an EFI application in a the Firmware Volumes by its name
+
+ @param EfiAppGuidGuid of the EFI Application into the Firmware
Volume
+ @param DevicePathEFI Device Path of the EFI application
+
+ @return EFI_SUCCESS The function completed successfully.
+ @return EFI_NOT_FOUND The protocol could not be located.
+ @return EFI_OUT_OF_RESOURCES There are not enough resources to find the
protocol.
+
+**/
+EFI_STATUS
+LocateEfiApplicationInFvByName (
+ IN CONST CHAR16* EfiAppName,
+ OUT EFI_DEVICE_PATH **DevicePath
+ );
+
+/**
+ Locate an EFI application in a the Firmware Volumes by its GUID
+
+ @param EfiAppGuidGuid of the EFI Application into the Firmware
Volume
+ @param DevicePathEFI Device Path of the EFI application
+
+ @return EFI_SUCCESS The function completed successfully.
+ @return EFI_NOT_FOUND The protocol could not be located.
+ @return EFI_OUT_OF_RESOURCES There are not enough resources to find the
protocol.
+
+**/
+EFI_STATUS
+LocateEfiApplicationInFvByGuid (
+ IN CONST EFI_GUID*EfiAppGuid,
+ OUT EFI_DEVICE_PATH **DevicePath
+ );
+
#endif
diff --git a/ArmPkg/Library/BdsLib/BdsAppLoader.c
b/ArmPkg/Library/BdsLib/BdsAppLoader.c
index 2b88bf1..1f208f8 100644
--- a/ArmPkg/Library/BdsLib/BdsAppLoader.c
+++ b/ArmPkg/Library/BdsLib/BdsAppLoader.c
@@ -1,6 +1,6 @@
/** @file
*
-* Copyright (c) 2011-2012, ARM Limited. All rights reserved.
+* Copyright (c) 2011-2015, ARM Limited. All rights reserved.
*
* This program and the accompanying materials
* are licensed and made available under the terms and conditions of the BSD
License
@@ -14,18 +14,23 @@
#include BdsInternal.h
-//#include Library/DxeServicesLib.h
+/**
+ Locate an EFI application in a the Firmware Volumes by its Name
+
+ @param EfiAppGuidGuid of the EFI Application into the Firmware
Volume
+ @param DevicePathEFI Device Path of the EFI application
+
+ @return EFI_SUCCESS The function completed successfully.
+ @return EFI_NOT_FOUND The protocol could not be located.
+ @return EFI_OUT_OF_RESOURCES There are not enough resources to find the
protocol.
-STATIC
+**/
EFI_STATUS
-BdsLoadFileFromFirmwareVolume (
- IN EFI_HANDLE FvHandle,
- IN CHAR16*FilePath,
- IN EFI_FV_FILETYPE FileTypeFilter,
- OUT EFI_DEVICE_PATH **EfiAppDevicePath
+LocateEfiApplicationInFvByName (
+ IN CONST CHAR16* EfiAppName,
+ OUT EFI_DEVICE_PATH **DevicePath
)
{
- EFI_FIRMWARE_VOLUME2_PROTOCOL *FvProtocol;
VOID *Key;
EFI_STATUSStatus, FileStatus;
EFI_GUID NameGuid;
@@ -37,108 +42,212 @@ BdsLoadFileFromFirmwareVolume (
UINT32Authentication;
EFI_DEVICE_PATH *FvDevicePath;
MEDIA_FW_VOL_FILEPATH_DEVICE_PATHFileDevicePath;
+ EFI_HANDLE*HandleBuffer;
+ UINTN NumberOfHandles;
+ UINTN Index;
+ EFI_FIRMWARE_VOLUME2_PROTOCOL *FvInstance;
- Status = gBS-HandleProtocol (FvHandle,gEfiFirmwareVolume2ProtocolGuid,
(VOID **)FvProtocol);
- if (EFI_ERROR(Status)) {
-return Status;
- }
+ ASSERT (DevicePath != NULL);
// Length of FilePath
- UiStringLen = StrLen (FilePath);
-
- // Allocate Key
- Key = AllocatePool (FvProtocol-KeySize);
- ASSERT (Key != NULL);
- ZeroMem (Key, FvProtocol-KeySize);
+ UiStringLen = StrLen (EfiAppName);
+
+ // Locate all the Firmware
[edk2] [PATCH 2/8] EmbeddedPkg/AndroidFastboot: Use Linux Loader instead of BdsLib
Android FastBoot EFI application was using the Linux Loader
from BdsLib. This change makes use of the EFI Linux Loader
application.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Olivier Martin olivier.mar...@arm.com
Reviewed-by: Ronald Cron ronald.c...@arm.com
---
.../AndroidFastboot/AndroidFastbootApp.inf | 3 +-
.../AndroidFastboot/Arm/BootAndroidBootImg.c | 48 +++---
2 files changed, 44 insertions(+), 7 deletions(-)
diff --git a/EmbeddedPkg/Application/AndroidFastboot/AndroidFastbootApp.inf
b/EmbeddedPkg/Application/AndroidFastboot/AndroidFastbootApp.inf
index ab9354c..ca17af8 100644
--- a/EmbeddedPkg/Application/AndroidFastboot/AndroidFastbootApp.inf
+++ b/EmbeddedPkg/Application/AndroidFastboot/AndroidFastbootApp.inf
@@ -1,6 +1,6 @@
#/** @file
#
-# Copyright (c) 2013-2014, ARM Ltd. All rights reserved.BR
+# Copyright (c) 2013-2015, ARM Ltd. All rights reserved.BR
#
# This program and the accompanying materials
# are licensed and made available under the terms and conditions of the BSD
License
@@ -39,6 +39,7 @@
PrintLib
UefiApplicationEntryPoint
UefiBootServicesTableLib
+ UefiLib
UefiRuntimeServicesTableLib
[Protocols]
diff --git a/EmbeddedPkg/Application/AndroidFastboot/Arm/BootAndroidBootImg.c
b/EmbeddedPkg/Application/AndroidFastboot/Arm/BootAndroidBootImg.c
index 7e9ad88..3053cf0 100644
--- a/EmbeddedPkg/Application/AndroidFastboot/Arm/BootAndroidBootImg.c
+++ b/EmbeddedPkg/Application/AndroidFastboot/Arm/BootAndroidBootImg.c
@@ -1,6 +1,6 @@
/** @file
- Copyright (c) 2013-2014, ARM Ltd. All rights reserved.BR
+ Copyright (c) 2013-2015, ARM Ltd. All rights reserved.BR
This program and the accompanying materials
are licensed and made available under the terms and conditions of the BSD
License
@@ -18,9 +18,16 @@
#include Library/BdsLib.h
#include Library/DevicePathLib.h
+#include Library/UefiBootServicesTableLib.h
+#include Library/UefiLib.h
#include Guid/ArmGlobalVariableHob.h
+#define LINUX_LOADER_COMMAND_LINE L%s -f %s -c %s
+
+// This GUID is defined in the INGF file of ArmPkg/Application/LinuxLoader
+CONST EFI_GUID mLinuxLoaderAppGuid = { 0x701f54f2, 0x0d70, 0x4b89, { 0xbc,
0x0a, 0xd9, 0xca, 0x25, 0x37, 0x90, 0x59 }};
+
// Device Path representing an image in memory
#pragma pack(1)
typedef struct {
@@ -64,6 +71,10 @@ BootAndroidBootImg (
UINTN RamdiskSize;
MEMORY_DEVICE_PATH KernelDevicePath;
MEMORY_DEVICE_PATH* RamdiskDevicePath;
+ CHAR16* KernelDevicePathTxt;
+ CHAR16* RamdiskDevicePathTxt;
+ EFI_DEVICE_PATH*LinuxLoaderDevicePath;
+ CHAR16* LoadOptions;
Status = ParseAndroidBootImg (
Buffer,
@@ -92,20 +103,45 @@ BootAndroidBootImg (
RamdiskDevicePath-Node1.EndingAddress = ((EFI_PHYSICAL_ADDRESS)(UINTN)
Ramdisk) + RamdiskSize;
}
- Status = BdsBootLinuxFdt (
- (EFI_DEVICE_PATH_PROTOCOL *) KernelDevicePath,
- (EFI_DEVICE_PATH_PROTOCOL *) RamdiskDevicePath,
- KernelArgs
- );
+ //
+ // Boot Linux using the Legacy Linux Loader
+ //
+
+ Status = LocateEfiApplicationInFvByGuid (mLinuxLoaderAppGuid,
LinuxLoaderDevicePath);
+ if (EFI_ERROR (Status)) {
+Print (LCouldn't Boot Linux: %d\n, Status);
+return EFI_DEVICE_ERROR;
+ }
+
+ KernelDevicePathTxt = ConvertDevicePathToText ((EFI_DEVICE_PATH_PROTOCOL *)
KernelDevicePath, FALSE, FALSE);
+ if (KernelDevicePathTxt == NULL) {
+return EFI_OUT_OF_RESOURCES;
+ }
+
+ RamdiskDevicePathTxt = ConvertDevicePathToText ((EFI_DEVICE_PATH_PROTOCOL *)
RamdiskDevicePath, FALSE, FALSE);
+ if (RamdiskDevicePathTxt == NULL) {
+return EFI_OUT_OF_RESOURCES;
+ }
+
+ // Initialize Legacy Linux loader command line
+ LoadOptions = CatSPrint (NULL, LINUX_LOADER_COMMAND_LINE,
KernelDevicePathTxt, RamdiskDevicePathTxt, KernelArgs);
+ if (LoadOptions == NULL) {
+return EFI_OUT_OF_RESOURCES;
+ }
+
+ Status = BdsStartEfiApplication (gImageHandle, LinuxLoaderDevicePath,
StrSize (LoadOptions), LoadOptions);
if (EFI_ERROR (Status)) {
DEBUG ((EFI_D_ERROR, Couldn't Boot Linux: %d\n, Status));
return EFI_DEVICE_ERROR;
}
if (RamdiskDevicePath) {
+FreePool (RamdiskDevicePathTxt);
FreePool (RamdiskDevicePath);
}
+ FreePool (KernelDevicePathTxt);
+
// If we got here we do a confused face because BootLinuxFdt returned,
// reporting success.
DEBUG ((EFI_D_ERROR, WARNING: BdsBootLinuxFdt returned EFI_SUCCESS.\n));
--
2.1.1
--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud
[edk2] [PATCH 6/8] ArmPlatformPkg/Bds: Added support for booting legacy kernel from BDS
When PcdBdsLinuxSupport is enabled, users can create boot
entries for the legacy EFI Linux loader if it exists into
the firmware.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Olivier Martin olivier.mar...@arm.com
Reviewed-by: Ronald Cron ronald.c...@arm.com
---
ArmPlatformPkg/ArmPlatformPkg.dec | 3 +
ArmPlatformPkg/Bds/Bds.inf| 4 +
ArmPlatformPkg/Bds/BdsHelper.c| 9 ---
ArmPlatformPkg/Bds/BdsInternal.h | 26 --
ArmPlatformPkg/Bds/BootLinux.c| 124 +
ArmPlatformPkg/Bds/BootMenu.c | 161 +-
6 files changed, 274 insertions(+), 53 deletions(-)
create mode 100644 ArmPlatformPkg/Bds/BootLinux.c
diff --git a/ArmPlatformPkg/ArmPlatformPkg.dec
b/ArmPlatformPkg/ArmPlatformPkg.dec
index be0919b..45aeaee 100644
--- a/ArmPlatformPkg/ArmPlatformPkg.dec
+++ b/ArmPlatformPkg/ArmPlatformPkg.dec
@@ -61,6 +61,9 @@
# we assume the OS will handle the FrameBuffer from the UEFI GOP information.
gArmPlatformTokenSpaceGuid.PcdGopDisableOnExitBootServices|FALSE|BOOLEAN|0x003D
+ # Enable Legacy Linux support in the BDS
+ gArmPlatformTokenSpaceGuid.PcdBdsLinuxSupport|TRUE|BOOLEAN|0x002E
+
[PcdsFixedAtBuild.common]
gArmPlatformTokenSpaceGuid.PcdCoreCount|1|UINT32|0x0039
gArmPlatformTokenSpaceGuid.PcdClusterCount|1|UINT32|0x0038
diff --git a/ArmPlatformPkg/Bds/Bds.inf b/ArmPlatformPkg/Bds/Bds.inf
index 3b6ffc3..06e8d91 100644
--- a/ArmPlatformPkg/Bds/Bds.inf
+++ b/ArmPlatformPkg/Bds/Bds.inf
@@ -27,6 +27,7 @@
[Sources]
Bds.c
BdsHelper.c
+ BootLinux.c
BootMenu.c
BootOption.c
BootOptionSupport.c
@@ -72,6 +73,9 @@
gEfiDhcp4ServiceBindingProtocolGuid
gEfiMtftp4ServiceBindingProtocolGuid
+[FeaturePcd]
+ gArmPlatformTokenSpaceGuid.PcdBdsLinuxSupport
+
[Pcd]
gArmPlatformTokenSpaceGuid.PcdFirmwareVendor
gArmPlatformTokenSpaceGuid.PcdDefaultBootDescription
diff --git a/ArmPlatformPkg/Bds/BdsHelper.c b/ArmPlatformPkg/Bds/BdsHelper.c
index b3003e9..732292c 100644
--- a/ArmPlatformPkg/Bds/BdsHelper.c
+++ b/ArmPlatformPkg/Bds/BdsHelper.c
@@ -256,15 +256,6 @@ GetHIInputBoolean (
}
}
-BOOLEAN
-HasFilePathEfiExtension (
- IN CHAR16* FilePath
- )
-{
- return (StrCmp (FilePath + (StrSize (FilePath) / sizeof (CHAR16)) - 5,
L.EFI) == 0) ||
- (StrCmp (FilePath + (StrSize (FilePath) / sizeof (CHAR16)) - 5,
L.efi) == 0);
-}
-
// Return the last non end-type Device Path Node from a Device Path
EFI_DEVICE_PATH*
GetLastDevicePathNode (
diff --git a/ArmPlatformPkg/Bds/BdsInternal.h b/ArmPlatformPkg/Bds/BdsInternal.h
index fe4fd79..ddf5308 100644
--- a/ArmPlatformPkg/Bds/BdsInternal.h
+++ b/ArmPlatformPkg/Bds/BdsInternal.h
@@ -1,6 +1,6 @@
/** @file
*
-* Copyright (c) 2011-2014, ARM Limited. All rights reserved.
+* Copyright (c) 2011-2015, ARM Limited. All rights reserved.
*
* This program and the accompanying materials
* are licensed and made available under the terms and conditions of the BSD
License
@@ -79,6 +79,12 @@ typedef struct _BDS_LOAD_OPTION_SUPPORT {
#define LOAD_OPTION_ENTRY_FROM_LINK(a) BASE_CR(a, BDS_LOAD_OPTION_ENTRY, Link)
#define LOAD_OPTION_FROM_LINK(a)((BDS_LOAD_OPTION_ENTRY*)BASE_CR(a,
BDS_LOAD_OPTION_ENTRY, Link))-BdsLoadOption
+// GUID of the EFI Linux Loader
+extern CONST EFI_GUID mLinuxLoaderAppGuid;
+
+// Device path of the EFI Linux Loader in the Firmware Volume
+extern EFI_DEVICE_PATH* mLinuxLoaderDevicePath;
+
EFI_STATUS
BootDeviceListSupportedInit (
IN OUT LIST_ENTRY *SupportedDeviceList
@@ -141,11 +147,6 @@ GetHIInputBoolean (
OUT BOOLEAN *Value
);
-BOOLEAN
-HasFilePathEfiExtension (
- IN CHAR16* FilePath
- );
-
EFI_DEVICE_PATH*
GetLastDevicePathNode (
IN EFI_DEVICE_PATH* DevicePath
@@ -260,4 +261,17 @@ EmptyCallbackFunction (
IN VOID *Context
);
+/**
+ * This function check if the DevicePath defines an EFI binary
+ *
+ * This function is used when the BDS support Linux loader to
+ * detect if the binary is an EFI application or potentially a
+ * Linux kernel.
+ */
+EFI_STATUS
+IsEfiBinary (
+ IN EFI_DEVICE_PATH* DevicePath,
+ OUT BOOLEAN *EfiBinary
+ );
+
#endif /* _BDSINTERNAL_H_ */
diff --git a/ArmPlatformPkg/Bds/BootLinux.c b/ArmPlatformPkg/Bds/BootLinux.c
new file mode 100644
index 000..0445e89
--- /dev/null
+++ b/ArmPlatformPkg/Bds/BootLinux.c
@@ -0,0 +1,124 @@
+/** @file
+*
+* Copyright (c) 2011 - 2015, ARM Limited. All rights reserved.
+*
+* This program and the accompanying materials
+* are licensed and made available under the terms and conditions of the BSD
License
+* which accompanies this distribution. The full text of the license may be
found at
+* http://opensource.org/licenses/bsd-license.php
+*
+* THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN AS IS BASIS,
+* WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR
IMPLIED.
+*
+**/
+
+#include BdsInternal.h
+
+// This GUID is defined
[edk2] [PATCH 3/8] ArmPlatformPkg: Add the LinuxLoader.efi EFI application
From: Ronald Cron ronald.c...@arm.com Add the legacy Linux Loader EFI application to the ARM development platform firmware. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ronald Cron ronald.c...@arm.com Reviewed-by: Olivier Martin olivier.mar...@arm.com --- ArmPlatformPkg/ArmJunoPkg/ArmJuno.fdf | 1 + ArmPlatformPkg/ArmPlatformPkg-2ndstage.dsc | 12 ArmPlatformPkg/ArmPlatformPkg-2ndstage.fdf | 4 +++- ArmPlatformPkg/ArmPlatformPkg.dsc | 13 + ArmPlatformPkg/ArmPlatformPkg.fdf | 4 +++- .../ArmRealViewEbPkg/ArmRealViewEb-RTSM-MPCore.fdf | 4 +++- .../ArmRealViewEbPkg/ArmRealViewEb-RTSM-UniCore.fdf | 5 - ArmPlatformPkg/ArmRealViewEbPkg/ArmRealViewEb.dsc.inc | 17 +++-- ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA15-A7.dsc | 2 +- ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA15-A7.fdf | 3 +++ ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA9x4.dsc| 2 +- ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA9x4.fdf| 3 +++ .../ArmVExpressPkg/ArmVExpress-FVP-AArch64.fdf | 3 +++ ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15.dsc | 2 +- ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15.fdf | 3 +++ .../ArmVExpressPkg/ArmVExpress-RTSM-A15_MPCore.dsc | 2 +- .../ArmVExpressPkg/ArmVExpress-RTSM-A15_MPCore.fdf | 3 +++ ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A9x4.dsc | 3 ++- ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A9x4.fdf | 3 +++ .../ArmVExpress-RTSM-AEMv8Ax4-foundation.fdf| 3 +++ .../ArmVExpressPkg/ArmVExpress-RTSM-AEMv8Ax4.fdf| 3 +++ ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc | 5 - BeagleBoardPkg/BeagleBoardPkg.dsc | 14 +- BeagleBoardPkg/BeagleBoardPkg.fdf | 3 +++ 24 files changed, 104 insertions(+), 13 deletions(-) diff --git a/ArmPlatformPkg/ArmJunoPkg/ArmJuno.fdf b/ArmPlatformPkg/ArmJunoPkg/ArmJuno.fdf index 2dbf0e6..db70609 100644 --- a/ArmPlatformPkg/ArmJunoPkg/ArmJuno.fdf +++ b/ArmPlatformPkg/ArmJunoPkg/ArmJuno.fdf @@ -191,6 +191,7 @@ FvNameGuid = B73FE497-B92E-416e-8326-45AD0D270092 # UEFI applications # INF ShellBinPkg/UefiShell/UefiShell.inf + INF ArmPkg/Application/LinuxLoader/LinuxLoader.inf # # Juno platform driver diff --git a/ArmPlatformPkg/ArmPlatformPkg-2ndstage.dsc b/ArmPlatformPkg/ArmPlatformPkg-2ndstage.dsc index 4cfb913..76415fe 100644 --- a/ArmPlatformPkg/ArmPlatformPkg-2ndstage.dsc +++ b/ArmPlatformPkg/ArmPlatformPkg-2ndstage.dsc @@ -89,6 +89,11 @@ # Networking Requirements for ArmPlatformPkg/Bds NetLib|MdeModulePkg/Library/DxeNetLib/DxeNetLib.inf + # These libraries are used by the dynamic EFI Shell commands + ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf + FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf + SortLib|MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf + # EBL Related Libraries EblCmdLib|ArmPlatformPkg/Library/EblCmdLib/EblCmdLib.inf EfiFileLib|EmbeddedPkg/Library/EfiFileLib/EfiFileLib.inf @@ -298,6 +303,11 @@ gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiLoaderCode|20 gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiLoaderData|0 + # We want to use the Shell Libraries but don't want it to initialise + # automatically. We initialise the libraries when the command is called by the + # Shell. + gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE + # # ARM Pcds # @@ -369,3 +379,5 @@ MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf ArmPlatformPkg/Bds/Bds.inf + # Legacy Linux Loader + ArmPkg/Application/LinuxLoader/LinuxLoader.inf diff --git a/ArmPlatformPkg/ArmPlatformPkg-2ndstage.fdf b/ArmPlatformPkg/ArmPlatformPkg-2ndstage.fdf index 86a94c1..9c35ebb 100644 --- a/ArmPlatformPkg/ArmPlatformPkg-2ndstage.fdf +++ b/ArmPlatformPkg/ArmPlatformPkg-2ndstage.fdf @@ -1,5 +1,5 @@ # -# Copyright (c) 2011-2014, ARM Limited. All rights reserved. +# Copyright (c) 2011-2015, ARM Limited. All rights reserved. # # This program and the accompanying materials # are licensed and made available under the terms and conditions of the BSD License @@ -129,6 +129,8 @@ FvNameGuid = 5eda4200-2c5f-43cb-9da3-0baf74b1b30c INF MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf INF ArmPlatformPkg/Bds/Bds.inf + # Legacy Linux Loader + INF ArmPkg/Application/LinuxLoader/LinuxLoader.inf [FV.FVMAIN_COMPACT] FvAlignment= 8 diff --git a/ArmPlatformPkg/ArmPlatformPkg.dsc b/ArmPlatformPkg/ArmPlatformPkg.dsc index f9f217c..0147146 100644 --- a/ArmPlatformPkg/ArmPlatformPkg.dsc +++ b/ArmPlatformPkg/ArmPlatformPkg.dsc @@ -88,6 +88,11 @@ # Networking Requirements for ArmPlatformPkg/Bds NetLib|MdeModulePkg/Library/DxeNetLib/DxeNetLib.inf + # These libraries are used by the dynamic EFI Shell commands + ShellLib|ShellPkg/Library/UefiShellLib
[edk2] [PATCH 2/8] EmbeddedPkg/AndroidFastboot: Use Linux Loader instead of BdsLib
Change-Id: I8b8596c9457e079227cc00d3f7eff8cc0319cedd
---
.../AndroidFastboot/AndroidFastbootApp.inf | 3 +-
.../AndroidFastboot/Arm/BootAndroidBootImg.c | 48 +++---
2 files changed, 44 insertions(+), 7 deletions(-)
diff --git a/EmbeddedPkg/Application/AndroidFastboot/AndroidFastbootApp.inf
b/EmbeddedPkg/Application/AndroidFastboot/AndroidFastbootApp.inf
index ab9354c..ca17af8 100644
--- a/EmbeddedPkg/Application/AndroidFastboot/AndroidFastbootApp.inf
+++ b/EmbeddedPkg/Application/AndroidFastboot/AndroidFastbootApp.inf
@@ -1,6 +1,6 @@
#/** @file
#
-# Copyright (c) 2013-2014, ARM Ltd. All rights reserved.BR
+# Copyright (c) 2013-2015, ARM Ltd. All rights reserved.BR
#
# This program and the accompanying materials
# are licensed and made available under the terms and conditions of the BSD
License
@@ -39,6 +39,7 @@
PrintLib
UefiApplicationEntryPoint
UefiBootServicesTableLib
+ UefiLib
UefiRuntimeServicesTableLib
[Protocols]
diff --git a/EmbeddedPkg/Application/AndroidFastboot/Arm/BootAndroidBootImg.c
b/EmbeddedPkg/Application/AndroidFastboot/Arm/BootAndroidBootImg.c
index 7e9ad88..3053cf0 100644
--- a/EmbeddedPkg/Application/AndroidFastboot/Arm/BootAndroidBootImg.c
+++ b/EmbeddedPkg/Application/AndroidFastboot/Arm/BootAndroidBootImg.c
@@ -1,6 +1,6 @@
/** @file
- Copyright (c) 2013-2014, ARM Ltd. All rights reserved.BR
+ Copyright (c) 2013-2015, ARM Ltd. All rights reserved.BR
This program and the accompanying materials
are licensed and made available under the terms and conditions of the BSD
License
@@ -18,9 +18,16 @@
#include Library/BdsLib.h
#include Library/DevicePathLib.h
+#include Library/UefiBootServicesTableLib.h
+#include Library/UefiLib.h
#include Guid/ArmGlobalVariableHob.h
+#define LINUX_LOADER_COMMAND_LINE L%s -f %s -c %s
+
+// This GUID is defined in the INGF file of ArmPkg/Application/LinuxLoader
+CONST EFI_GUID mLinuxLoaderAppGuid = { 0x701f54f2, 0x0d70, 0x4b89, { 0xbc,
0x0a, 0xd9, 0xca, 0x25, 0x37, 0x90, 0x59 }};
+
// Device Path representing an image in memory
#pragma pack(1)
typedef struct {
@@ -64,6 +71,10 @@ BootAndroidBootImg (
UINTN RamdiskSize;
MEMORY_DEVICE_PATH KernelDevicePath;
MEMORY_DEVICE_PATH* RamdiskDevicePath;
+ CHAR16* KernelDevicePathTxt;
+ CHAR16* RamdiskDevicePathTxt;
+ EFI_DEVICE_PATH*LinuxLoaderDevicePath;
+ CHAR16* LoadOptions;
Status = ParseAndroidBootImg (
Buffer,
@@ -92,20 +103,45 @@ BootAndroidBootImg (
RamdiskDevicePath-Node1.EndingAddress = ((EFI_PHYSICAL_ADDRESS)(UINTN)
Ramdisk) + RamdiskSize;
}
- Status = BdsBootLinuxFdt (
- (EFI_DEVICE_PATH_PROTOCOL *) KernelDevicePath,
- (EFI_DEVICE_PATH_PROTOCOL *) RamdiskDevicePath,
- KernelArgs
- );
+ //
+ // Boot Linux using the Legacy Linux Loader
+ //
+
+ Status = LocateEfiApplicationInFvByGuid (mLinuxLoaderAppGuid,
LinuxLoaderDevicePath);
+ if (EFI_ERROR (Status)) {
+Print (LCouldn't Boot Linux: %d\n, Status);
+return EFI_DEVICE_ERROR;
+ }
+
+ KernelDevicePathTxt = ConvertDevicePathToText ((EFI_DEVICE_PATH_PROTOCOL *)
KernelDevicePath, FALSE, FALSE);
+ if (KernelDevicePathTxt == NULL) {
+return EFI_OUT_OF_RESOURCES;
+ }
+
+ RamdiskDevicePathTxt = ConvertDevicePathToText ((EFI_DEVICE_PATH_PROTOCOL *)
RamdiskDevicePath, FALSE, FALSE);
+ if (RamdiskDevicePathTxt == NULL) {
+return EFI_OUT_OF_RESOURCES;
+ }
+
+ // Initialize Legacy Linux loader command line
+ LoadOptions = CatSPrint (NULL, LINUX_LOADER_COMMAND_LINE,
KernelDevicePathTxt, RamdiskDevicePathTxt, KernelArgs);
+ if (LoadOptions == NULL) {
+return EFI_OUT_OF_RESOURCES;
+ }
+
+ Status = BdsStartEfiApplication (gImageHandle, LinuxLoaderDevicePath,
StrSize (LoadOptions), LoadOptions);
if (EFI_ERROR (Status)) {
DEBUG ((EFI_D_ERROR, Couldn't Boot Linux: %d\n, Status));
return EFI_DEVICE_ERROR;
}
if (RamdiskDevicePath) {
+FreePool (RamdiskDevicePathTxt);
FreePool (RamdiskDevicePath);
}
+ FreePool (KernelDevicePathTxt);
+
// If we got here we do a confused face because BootLinuxFdt returned,
// reporting success.
DEBUG ((EFI_D_ERROR, WARNING: BdsBootLinuxFdt returned EFI_SUCCESS.\n));
--
2.1.1
--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
[edk2] [PATCH 5/8] ArmPlatformPkg/Bds: Remove Linux specific boot path
Change-Id: Id055d77ee78729dcfd692d956e9b5ebc7b930611 --- ArmPkg/ArmPkg.dec | 1 - ArmPlatformPkg/ArmJunoPkg/ArmJuno.dsc | 1 - ArmPlatformPkg/ArmPlatformPkg.dec | 6 - .../ArmRealViewEbPkg/ArmRealViewEb.dsc.inc | 1 - .../ArmVExpressPkg/ArmVExpress-CTA15-A7.dsc| 3 - .../ArmVExpressPkg/ArmVExpress-CTA9x4.dsc | 3 - .../ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc | 2 - .../ArmVExpressPkg/ArmVExpress-RTSM-A15.dsc| 3 - .../ArmVExpressPkg/ArmVExpress-RTSM-A15_MPCore.dsc | 3 - .../ArmVExpressPkg/ArmVExpress-RTSM-A9x4.dsc | 3 - .../ArmVExpress-RTSM-AEMv8Ax4-foundation.dsc | 1 - .../ArmVExpressPkg/ArmVExpress-RTSM-AEMv8Ax4.dsc | 1 - ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc | 3 - ArmPlatformPkg/Bds/Bds.c | 36 +-- ArmPlatformPkg/Bds/Bds.inf | 7 +- ArmPlatformPkg/Bds/BdsInternal.h | 45 --- ArmPlatformPkg/Bds/BootMenu.c | 358 - ArmPlatformPkg/Bds/BootOption.c| 100 ++ ArmPlatformPkg/Bds/BootOptionSupport.c | 111 --- BeagleBoardPkg/BeagleBoardPkg.dsc | 7 - 20 files changed, 93 insertions(+), 602 deletions(-) diff --git a/ArmPkg/ArmPkg.dec b/ArmPkg/ArmPkg.dec index b30de91..da0c8a9 100644 --- a/ArmPkg/ArmPkg.dec +++ b/ArmPkg/ArmPkg.dec @@ -115,7 +115,6 @@ # # BdsLib # - gArmTokenSpaceGuid.PcdArmMachineType|0|UINT32|0x001E # The compressed Linux kernel is expected to be under 128MB from the beginning of the System Memory gArmTokenSpaceGuid.PcdArmLinuxKernelMaxOffset|0x0800|UINT32|0x001F # Maximum file size for TFTP servers that do not support 'tsize' extension diff --git a/ArmPlatformPkg/ArmJunoPkg/ArmJuno.dsc b/ArmPlatformPkg/ArmJunoPkg/ArmJuno.dsc index b5b959a..9860cf0 100644 --- a/ArmPlatformPkg/ArmJunoPkg/ArmJuno.dsc +++ b/ArmPlatformPkg/ArmJunoPkg/ArmJuno.dsc @@ -151,7 +151,6 @@ # Support the Linux EFI stub by default gArmPlatformTokenSpaceGuid.PcdDefaultBootArgument|Lconsole=ttyAMA0,115200 earlycon=pl011,0x7ff8 root=/dev/sda1 rootwait verbose debug - gArmPlatformTokenSpaceGuid.PcdDefaultBootType|0 # Use the serial console (ConIn ConOut) and the Graphic driver (ConOut) gArmPlatformTokenSpaceGuid.PcdDefaultConOutPaths|LVenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(115200,8,N,1)/VenPcAnsi();VenHw(CE660500-824D-11E0-AC72-0002A5D5C51B) diff --git a/ArmPlatformPkg/ArmPlatformPkg.dec b/ArmPlatformPkg/ArmPlatformPkg.dec index cd67aee..be0919b 100644 --- a/ArmPlatformPkg/ArmPlatformPkg.dec +++ b/ArmPlatformPkg/ArmPlatformPkg.dec @@ -129,13 +129,7 @@ gArmPlatformTokenSpaceGuid.PcdFirmwareVendor|ARM Platform|VOID*|0x0019 gArmPlatformTokenSpaceGuid.PcdDefaultBootDescription|LDefault Boot Device|VOID*|0x000C gArmPlatformTokenSpaceGuid.PcdDefaultBootDevicePath|L|VOID*|0x000D - gArmPlatformTokenSpaceGuid.PcdDefaultBootInitrdPath|L|VOID*|0x000E gArmPlatformTokenSpaceGuid.PcdDefaultBootArgument|L|VOID*|0x00F - # PcdDefaultBootType define the type of the binary pointed by PcdDefaultBootDevicePath: - # - 0 = an EFI application - # - 1 = a Linux kernel with ATAG support - # - 2 = a Linux kernel with FDT support - gArmPlatformTokenSpaceGuid.PcdDefaultBootType|0|UINT32|0x0010 gArmPlatformTokenSpaceGuid.PcdDefaultConInPaths|L|VOID*|0x001B gArmPlatformTokenSpaceGuid.PcdDefaultConOutPaths|L|VOID*|0x001C diff --git a/ArmPlatformPkg/ArmRealViewEbPkg/ArmRealViewEb.dsc.inc b/ArmPlatformPkg/ArmRealViewEbPkg/ArmRealViewEb.dsc.inc index 6232791..9445ce2 100644 --- a/ArmPlatformPkg/ArmRealViewEbPkg/ArmRealViewEb.dsc.inc +++ b/ArmPlatformPkg/ArmRealViewEbPkg/ArmRealViewEb.dsc.inc @@ -316,7 +316,6 @@ # # ARM OS Loader # - gArmTokenSpaceGuid.PcdArmMachineType|827 gArmPlatformTokenSpaceGuid.PcdDefaultBootDescription|LSemiHosting gArmPlatformTokenSpaceGuid.PcdDefaultBootDevicePath|LFv(14801114-DA6A-4113-985B-DC876337A15E)/LinuxLoader.efi gArmPlatformTokenSpaceGuid.PcdDefaultBootArgument|LVenHw(C5B9C74A-6D72-4719-99AB-C59F199091EB)/zImage-RTSM -a 827 -c \console=ttyAMA0,38400n8\ diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA15-A7.dsc b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA15-A7.dsc index 3b693c2..50bb556 100644 --- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA15-A7.dsc +++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA15-A7.dsc @@ -181,12 +181,9 @@ # # ARM OS Loader # - # Versatile Express machine type (ARM VERSATILE EXPRESS = 2272) required for ARM Linux: - gArmTokenSpaceGuid.PcdArmMachineType|2272 gArmPlatformTokenSpaceGuid.PcdDefaultBootDescription|LLinux from NorFlash gArmPlatformTokenSpaceGuid.PcdDefaultBootDevicePath|LVenHw(1F15DA3C-37FF-4070-B471-BB4AF12A724A)/Image
[edk2] [PATCH 4/8] ArmPkg/BdsLib: Remove Linux loader from BdsLib
Change-Id: Ieb50d812dccdf0f105b7a0848349a5010b67097c --- ArmPkg/Include/Library/BdsLib.h| 37 -- ArmPkg/Library/BdsLib/AArch64/BdsLinuxLoader.c | 355 - .../Library/BdsLib/AArch64/BdsLinuxLoaderHelper.S | 58 --- ArmPkg/Library/BdsLib/Arm/BdsLinuxAtag.c | 173 --- ArmPkg/Library/BdsLib/Arm/BdsLinuxLoader.c | 323 ArmPkg/Library/BdsLib/BdsHelper.c | 178 +-- ArmPkg/Library/BdsLib/BdsInternal.h| 13 - ArmPkg/Library/BdsLib/BdsLib.inf | 38 -- ArmPkg/Library/BdsLib/BdsLinuxFdt.c| 572 - ArmPkg/Library/BdsLib/BdsLinuxLoader.h | 156 -- ArmPlatformPkg/Bds/Bds.inf | 4 + ArmPlatformPkg/Bds/BootOption.c| 35 +- 12 files changed, 8 insertions(+), 1934 deletions(-) delete mode 100644 ArmPkg/Library/BdsLib/AArch64/BdsLinuxLoader.c delete mode 100644 ArmPkg/Library/BdsLib/AArch64/BdsLinuxLoaderHelper.S delete mode 100644 ArmPkg/Library/BdsLib/Arm/BdsLinuxAtag.c delete mode 100644 ArmPkg/Library/BdsLib/Arm/BdsLinuxLoader.c delete mode 100644 ArmPkg/Library/BdsLib/BdsLinuxFdt.c delete mode 100644 ArmPkg/Library/BdsLib/BdsLinuxLoader.h diff --git a/ArmPkg/Include/Library/BdsLib.h b/ArmPkg/Include/Library/BdsLib.h index 3d9e195..c58f47e 100644 --- a/ArmPkg/Include/Library/BdsLib.h +++ b/ArmPkg/Include/Library/BdsLib.h @@ -138,43 +138,6 @@ BootOptionAllocateBootIndex ( ); /** - Start a Linux kernel from a Device Path - - @param LinuxKernel Device Path to the Linux Kernel - @param ParametersLinux kernel arguments - - @retval EFI_SUCCESS All drivers have been connected - @retval EFI_NOT_FOUND The Linux kernel Device Path has not been found - @retval EFI_OUT_OF_RESOURCES There is not enough resource memory to store the matching results. - -**/ -EFI_STATUS -BdsBootLinuxAtag ( - IN EFI_DEVICE_PATH_PROTOCOL* LinuxKernelDevicePath, - IN EFI_DEVICE_PATH_PROTOCOL* InitrdDevicePath, - IN CONST CHAR8* Arguments - ); - -/** - Start a Linux kernel from a Device Path - - @param[in] LinuxKernelDevicePath Device Path to the Linux Kernel - @param[in] InitrdDevicePath Device Path to the Initrd - @param[in] Arguments Linux kernel arguments - - @retval EFI_SUCCESS All drivers have been connected - @retval EFI_NOT_FOUND The Linux kernel Device Path has not been found - @retval EFI_OUT_OF_RESOURCES There is not enough resource memory to store the matching results. - -**/ -EFI_STATUS -BdsBootLinuxFdt ( - IN EFI_DEVICE_PATH_PROTOCOL* LinuxKernelDevicePath, - IN EFI_DEVICE_PATH_PROTOCOL* InitrdDevicePath, - IN CONST CHAR8* Arguments - ); - -/** Start an EFI Application from a Device Path @param ParentImageHandle Handle of the calling image diff --git a/ArmPkg/Library/BdsLib/AArch64/BdsLinuxLoader.c b/ArmPkg/Library/BdsLib/AArch64/BdsLinuxLoader.c deleted file mode 100644 index 7651597..000 --- a/ArmPkg/Library/BdsLib/AArch64/BdsLinuxLoader.c +++ /dev/null @@ -1,355 +0,0 @@ -/** @file -* -* Copyright (c) 2011-2014, ARM Limited. All rights reserved. -* -* This program and the accompanying materials -* are licensed and made available under the terms and conditions of the BSD License -* which accompanies this distribution. The full text of the license may be found at -* http://opensource.org/licenses/bsd-license.php -* -* THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN AS IS BASIS, -* WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED. -* -**/ -#include Library/ArmGicLib.h -#include Ppi/ArmMpCoreInfo.h -#include Library/IoLib.h -#include Guid/Fdt.h -#include libfdt.h - -#include BdsInternal.h -#include BdsLinuxLoader.h - -/* - Linux kernel booting: Look at the doc in the Kernel source : -Documentation/arm64/booting.txt - The kernel image must be placed at the start of the memory to be used by the - kernel (2MB aligned) + 0x8. - - The Device tree blob is expected to be under 2MB and be within the first 512MB - of kernel memory and be 2MB aligned. - - A Flattened Device Tree (FDT) used to boot linux needs to be updated before - the kernel is started. It needs to indicate how secondary cores are brought up - and where they are waiting before loading Linux. The FDT also needs to hold - the correct kernel command line and filesystem RAM-disk information. - At the moment we do not fully support generating this FDT information at - runtime. A prepared FDT should be provided at boot. FDT is the only supported - method for booting the AArch64 Linux kernel. - - Linux does not use any runtime services at this time, so we can let it - overwrite UEFI. -*/ - - -#define LINUX_ALIGN_VAL (0x08) // 2MB + 0x8 mask -#define LINUX_ALIGN_MASK (0x1F) // Bottom 21bits -#define
[edk2] [PATCH 5/8] ArmPlatformPkg/Bds: Remove Linux specific boot path
Since the embedded Linux Loader has been removed from BdsLib there is no more Linux specific boot option. All the boot options are now expected to be arguments for EFI applications. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Olivier Martin olivier.mar...@arm.com Reviewed-by: Ronald Cron ronald.c...@arm.com --- ArmPkg/ArmPkg.dec | 1 - ArmPlatformPkg/ArmJunoPkg/ArmJuno.dsc | 1 - ArmPlatformPkg/ArmPlatformPkg.dec | 6 - .../ArmRealViewEbPkg/ArmRealViewEb.dsc.inc | 1 - .../ArmVExpressPkg/ArmVExpress-CTA15-A7.dsc| 3 - .../ArmVExpressPkg/ArmVExpress-CTA9x4.dsc | 3 - .../ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc | 2 - .../ArmVExpressPkg/ArmVExpress-RTSM-A15.dsc| 3 - .../ArmVExpressPkg/ArmVExpress-RTSM-A15_MPCore.dsc | 3 - .../ArmVExpressPkg/ArmVExpress-RTSM-A9x4.dsc | 3 - .../ArmVExpress-RTSM-AEMv8Ax4-foundation.dsc | 1 - .../ArmVExpressPkg/ArmVExpress-RTSM-AEMv8Ax4.dsc | 1 - ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc | 3 - ArmPlatformPkg/Bds/Bds.c | 36 +-- ArmPlatformPkg/Bds/Bds.inf | 7 +- ArmPlatformPkg/Bds/BdsInternal.h | 45 --- ArmPlatformPkg/Bds/BootMenu.c | 358 - ArmPlatformPkg/Bds/BootOption.c| 100 ++ ArmPlatformPkg/Bds/BootOptionSupport.c | 111 --- BeagleBoardPkg/BeagleBoardPkg.dsc | 7 - 20 files changed, 93 insertions(+), 602 deletions(-) diff --git a/ArmPkg/ArmPkg.dec b/ArmPkg/ArmPkg.dec index b30de91..da0c8a9 100644 --- a/ArmPkg/ArmPkg.dec +++ b/ArmPkg/ArmPkg.dec @@ -115,7 +115,6 @@ # # BdsLib # - gArmTokenSpaceGuid.PcdArmMachineType|0|UINT32|0x001E # The compressed Linux kernel is expected to be under 128MB from the beginning of the System Memory gArmTokenSpaceGuid.PcdArmLinuxKernelMaxOffset|0x0800|UINT32|0x001F # Maximum file size for TFTP servers that do not support 'tsize' extension diff --git a/ArmPlatformPkg/ArmJunoPkg/ArmJuno.dsc b/ArmPlatformPkg/ArmJunoPkg/ArmJuno.dsc index b5b959a..9860cf0 100644 --- a/ArmPlatformPkg/ArmJunoPkg/ArmJuno.dsc +++ b/ArmPlatformPkg/ArmJunoPkg/ArmJuno.dsc @@ -151,7 +151,6 @@ # Support the Linux EFI stub by default gArmPlatformTokenSpaceGuid.PcdDefaultBootArgument|Lconsole=ttyAMA0,115200 earlycon=pl011,0x7ff8 root=/dev/sda1 rootwait verbose debug - gArmPlatformTokenSpaceGuid.PcdDefaultBootType|0 # Use the serial console (ConIn ConOut) and the Graphic driver (ConOut) gArmPlatformTokenSpaceGuid.PcdDefaultConOutPaths|LVenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(115200,8,N,1)/VenPcAnsi();VenHw(CE660500-824D-11E0-AC72-0002A5D5C51B) diff --git a/ArmPlatformPkg/ArmPlatformPkg.dec b/ArmPlatformPkg/ArmPlatformPkg.dec index cd67aee..be0919b 100644 --- a/ArmPlatformPkg/ArmPlatformPkg.dec +++ b/ArmPlatformPkg/ArmPlatformPkg.dec @@ -129,13 +129,7 @@ gArmPlatformTokenSpaceGuid.PcdFirmwareVendor|ARM Platform|VOID*|0x0019 gArmPlatformTokenSpaceGuid.PcdDefaultBootDescription|LDefault Boot Device|VOID*|0x000C gArmPlatformTokenSpaceGuid.PcdDefaultBootDevicePath|L|VOID*|0x000D - gArmPlatformTokenSpaceGuid.PcdDefaultBootInitrdPath|L|VOID*|0x000E gArmPlatformTokenSpaceGuid.PcdDefaultBootArgument|L|VOID*|0x00F - # PcdDefaultBootType define the type of the binary pointed by PcdDefaultBootDevicePath: - # - 0 = an EFI application - # - 1 = a Linux kernel with ATAG support - # - 2 = a Linux kernel with FDT support - gArmPlatformTokenSpaceGuid.PcdDefaultBootType|0|UINT32|0x0010 gArmPlatformTokenSpaceGuid.PcdDefaultConInPaths|L|VOID*|0x001B gArmPlatformTokenSpaceGuid.PcdDefaultConOutPaths|L|VOID*|0x001C diff --git a/ArmPlatformPkg/ArmRealViewEbPkg/ArmRealViewEb.dsc.inc b/ArmPlatformPkg/ArmRealViewEbPkg/ArmRealViewEb.dsc.inc index 6232791..9445ce2 100644 --- a/ArmPlatformPkg/ArmRealViewEbPkg/ArmRealViewEb.dsc.inc +++ b/ArmPlatformPkg/ArmRealViewEbPkg/ArmRealViewEb.dsc.inc @@ -316,7 +316,6 @@ # # ARM OS Loader # - gArmTokenSpaceGuid.PcdArmMachineType|827 gArmPlatformTokenSpaceGuid.PcdDefaultBootDescription|LSemiHosting gArmPlatformTokenSpaceGuid.PcdDefaultBootDevicePath|LFv(14801114-DA6A-4113-985B-DC876337A15E)/LinuxLoader.efi gArmPlatformTokenSpaceGuid.PcdDefaultBootArgument|LVenHw(C5B9C74A-6D72-4719-99AB-C59F199091EB)/zImage-RTSM -a 827 -c \console=ttyAMA0,38400n8\ diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA15-A7.dsc b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA15-A7.dsc index 3b693c2..50bb556 100644 --- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA15-A7.dsc +++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA15-A7.dsc @@ -181,12 +181,9 @@ # # ARM OS Loader # - # Versatile Express machine type (ARM VERSATILE EXPRESS = 2272) required for ARM Linux
[edk2] [PATCH 1/8] ArmPkg/BdsLib: Replaced BdsLoadApplication() by LocateEfiApplicationInFv(Name|Guid)()
Replaced the function BdsLoadApplication() by two explicit
functions that load the EFI application either by its GUID
or its Name.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Olivier Martin olivier.mar...@arm.com
Reviewed-by: Ronald Cron ronald.c...@arm.com
---
ArmPkg/Include/Library/BdsLib.h | 52 ---
ArmPkg/Library/BdsLib/BdsAppLoader.c | 283 ---
ArmPlatformPkg/Bds/Bds.inf | 3 +
ArmPlatformPkg/Bds/BootMenu.c| 24 ++-
4 files changed, 250 insertions(+), 112 deletions(-)
diff --git a/ArmPkg/Include/Library/BdsLib.h b/ArmPkg/Include/Library/BdsLib.h
index c6416db..3d9e195 100644
--- a/ArmPkg/Include/Library/BdsLib.h
+++ b/ArmPkg/Include/Library/BdsLib.h
@@ -193,24 +193,6 @@ BdsStartEfiApplication (
IN VOID* LoadOptions
);
-/**
- Start an EFI Application from any Firmware Volume
-
- @param EfiAppEFI Application Name
-
- @retval EFI_SUCCESS All drivers have been connected
- @retval EFI_NOT_FOUND The Linux kernel Device Path has not been found
- @retval EFI_OUT_OF_RESOURCES There is not enough resource memory to store
the matching results.
-
-**/
-EFI_STATUS
-BdsLoadApplication (
- IN EFI_HANDLE ParentImageHandle,
- IN CHAR16* EfiApp,
- IN UINTN LoadOptionsSize,
- IN VOID* LoadOptions
- );
-
EFI_STATUS
BdsLoadImage (
IN EFI_DEVICE_PATH *DevicePath,
@@ -227,4 +209,38 @@ ShutdownUefiBootServices (
VOID
);
+/**
+ Locate an EFI application in a the Firmware Volumes by its name
+
+ @param EfiAppGuidGuid of the EFI Application into the Firmware
Volume
+ @param DevicePathEFI Device Path of the EFI application
+
+ @return EFI_SUCCESS The function completed successfully.
+ @return EFI_NOT_FOUND The protocol could not be located.
+ @return EFI_OUT_OF_RESOURCES There are not enough resources to find the
protocol.
+
+**/
+EFI_STATUS
+LocateEfiApplicationInFvByName (
+ IN CONST CHAR16* EfiAppName,
+ OUT EFI_DEVICE_PATH **DevicePath
+ );
+
+/**
+ Locate an EFI application in a the Firmware Volumes by its GUID
+
+ @param EfiAppGuidGuid of the EFI Application into the Firmware
Volume
+ @param DevicePathEFI Device Path of the EFI application
+
+ @return EFI_SUCCESS The function completed successfully.
+ @return EFI_NOT_FOUND The protocol could not be located.
+ @return EFI_OUT_OF_RESOURCES There are not enough resources to find the
protocol.
+
+**/
+EFI_STATUS
+LocateEfiApplicationInFvByGuid (
+ IN CONST EFI_GUID*EfiAppGuid,
+ OUT EFI_DEVICE_PATH **DevicePath
+ );
+
#endif
diff --git a/ArmPkg/Library/BdsLib/BdsAppLoader.c
b/ArmPkg/Library/BdsLib/BdsAppLoader.c
index 2b88bf1..1f208f8 100644
--- a/ArmPkg/Library/BdsLib/BdsAppLoader.c
+++ b/ArmPkg/Library/BdsLib/BdsAppLoader.c
@@ -1,6 +1,6 @@
/** @file
*
-* Copyright (c) 2011-2012, ARM Limited. All rights reserved.
+* Copyright (c) 2011-2015, ARM Limited. All rights reserved.
*
* This program and the accompanying materials
* are licensed and made available under the terms and conditions of the BSD
License
@@ -14,18 +14,23 @@
#include BdsInternal.h
-//#include Library/DxeServicesLib.h
+/**
+ Locate an EFI application in a the Firmware Volumes by its Name
+
+ @param EfiAppGuidGuid of the EFI Application into the Firmware
Volume
+ @param DevicePathEFI Device Path of the EFI application
+
+ @return EFI_SUCCESS The function completed successfully.
+ @return EFI_NOT_FOUND The protocol could not be located.
+ @return EFI_OUT_OF_RESOURCES There are not enough resources to find the
protocol.
-STATIC
+**/
EFI_STATUS
-BdsLoadFileFromFirmwareVolume (
- IN EFI_HANDLE FvHandle,
- IN CHAR16*FilePath,
- IN EFI_FV_FILETYPE FileTypeFilter,
- OUT EFI_DEVICE_PATH **EfiAppDevicePath
+LocateEfiApplicationInFvByName (
+ IN CONST CHAR16* EfiAppName,
+ OUT EFI_DEVICE_PATH **DevicePath
)
{
- EFI_FIRMWARE_VOLUME2_PROTOCOL *FvProtocol;
VOID *Key;
EFI_STATUSStatus, FileStatus;
EFI_GUID NameGuid;
@@ -37,108 +42,212 @@ BdsLoadFileFromFirmwareVolume (
UINT32Authentication;
EFI_DEVICE_PATH *FvDevicePath;
MEDIA_FW_VOL_FILEPATH_DEVICE_PATHFileDevicePath;
+ EFI_HANDLE*HandleBuffer;
+ UINTN NumberOfHandles;
+ UINTN Index;
+ EFI_FIRMWARE_VOLUME2_PROTOCOL *FvInstance;
- Status = gBS-HandleProtocol (FvHandle,gEfiFirmwareVolume2ProtocolGuid,
(VOID **)FvProtocol);
- if (EFI_ERROR(Status)) {
-return Status;
- }
+ ASSERT (DevicePath != NULL);
// Length of FilePath
[edk2] [PATCH 0/8] ArmPlatformPkg: Remove embedded Linux Loader from ARM BDS
ARM BDS contains an embedded Linux Loader. This support was to allow booting legacy linux loader (Linux without EFI Stub) on ARM platforms. This patchset replace the embedded legacy Linux loader by the use of the EFI Linux Loader located in ArmPkg/Application/LinuxLoader when the firmware engineer enables PcdBdsLinuxSupport in the ARM BDS. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Olivier Martin olivier.mar...@arm.com Reviewed-by: Ronald Cron ronald.c...@arm.com Cc: Laszlo Ersek ler...@redhat.com Cc: Ard Biesheuvel ard.biesheu...@linaro.org Olivier Martin (7): ArmPkg/BdsLib: Replaced BdsLoadApplication() by LocateEfiApplicationInFv() EmbeddedPkg/AndroidFastboot: Use Linux Loader instead of BdsLib ArmPkg/BdsLib: Remove Linux loader from BdsLib ArmPlatformPkg/Bds: Remove Linux specific boot path ArmPlatformPkg/Bds: Added support for booting legacy kernel from BDS ArmPlatformPkg: Use LinuxLoader.efi for the default boot entry ArmVirtPkg/ArmVirtQemu.dsc: Remove Linux specific boot path Ronald Cron (1): ArmPlatformPkg: Add the LinuxLoader.efi EFI application ArmPkg/ArmPkg.dec | 1 - ArmPkg/Include/Library/BdsLib.h| 89 ++-- ArmPkg/Library/BdsLib/AArch64/BdsLinuxLoader.c | 355 - .../Library/BdsLib/AArch64/BdsLinuxLoaderHelper.S | 58 --- ArmPkg/Library/BdsLib/Arm/BdsLinuxAtag.c | 173 --- ArmPkg/Library/BdsLib/Arm/BdsLinuxLoader.c | 323 ArmPkg/Library/BdsLib/BdsAppLoader.c | 283 ++ ArmPkg/Library/BdsLib/BdsHelper.c | 178 +-- ArmPkg/Library/BdsLib/BdsInternal.h| 13 - ArmPkg/Library/BdsLib/BdsLib.inf | 38 -- ArmPkg/Library/BdsLib/BdsLinuxFdt.c| 572 - ArmPkg/Library/BdsLib/BdsLinuxLoader.h | 156 -- ArmPlatformPkg/ArmJunoPkg/ArmJuno.dsc | 6 +- ArmPlatformPkg/ArmJunoPkg/ArmJuno.fdf | 1 + ArmPlatformPkg/ArmPlatformPkg-2ndstage.dsc | 12 + ArmPlatformPkg/ArmPlatformPkg-2ndstage.fdf | 4 +- ArmPlatformPkg/ArmPlatformPkg.dec | 9 +- ArmPlatformPkg/ArmPlatformPkg.dsc | 13 + ArmPlatformPkg/ArmPlatformPkg.fdf | 4 +- .../ArmRealViewEbPkg/ArmRealViewEb-RTSM-MPCore.fdf | 4 +- .../ArmRealViewEb-RTSM-UniCore.fdf | 5 +- .../ArmRealViewEbPkg/ArmRealViewEb.dsc.inc | 18 +- .../ArmVExpressPkg/ArmVExpress-CTA15-A7.dsc| 7 +- .../ArmVExpressPkg/ArmVExpress-CTA15-A7.fdf| 3 + .../ArmVExpressPkg/ArmVExpress-CTA9x4.dsc | 8 +- .../ArmVExpressPkg/ArmVExpress-CTA9x4.fdf | 3 + .../ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc | 7 +- .../ArmVExpressPkg/ArmVExpress-FVP-AArch64.fdf | 3 + .../ArmVExpressPkg/ArmVExpress-RTSM-A15.dsc| 6 +- .../ArmVExpressPkg/ArmVExpress-RTSM-A15.fdf| 3 + .../ArmVExpressPkg/ArmVExpress-RTSM-A15_MPCore.dsc | 8 +- .../ArmVExpressPkg/ArmVExpress-RTSM-A15_MPCore.fdf | 3 + .../ArmVExpressPkg/ArmVExpress-RTSM-A9x4.dsc | 6 +- .../ArmVExpressPkg/ArmVExpress-RTSM-A9x4.fdf | 3 + .../ArmVExpress-RTSM-AEMv8Ax4-foundation.dsc | 1 - .../ArmVExpress-RTSM-AEMv8Ax4-foundation.fdf | 3 + .../ArmVExpressPkg/ArmVExpress-RTSM-AEMv8Ax4.dsc | 1 - .../ArmVExpressPkg/ArmVExpress-RTSM-AEMv8Ax4.fdf | 3 + ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc | 8 +- ArmPlatformPkg/Bds/Bds.c | 36 +- ArmPlatformPkg/Bds/Bds.inf | 18 +- ArmPlatformPkg/Bds/BdsHelper.c | 9 - ArmPlatformPkg/Bds/BdsInternal.h | 71 +-- ArmPlatformPkg/Bds/BootLinux.c | 124 + ArmPlatformPkg/Bds/BootMenu.c | 385 +- ArmPlatformPkg/Bds/BootOption.c| 131 + ArmPlatformPkg/Bds/BootOptionSupport.c | 111 ArmVirtPkg/ArmVirtQemu.dsc | 1 - BeagleBoardPkg/BeagleBoardPkg.dsc | 21 +- BeagleBoardPkg/BeagleBoardPkg.fdf | 3 + .../AndroidFastboot/AndroidFastbootApp.inf | 3 +- .../AndroidFastboot/Arm/BootAndroidBootImg.c | 48 +- 52 files changed, 702 insertions(+), 2650 deletions(-) delete mode 100644 ArmPkg/Library/BdsLib/AArch64/BdsLinuxLoader.c delete mode 100644 ArmPkg/Library/BdsLib/AArch64/BdsLinuxLoaderHelper.S delete mode 100644 ArmPkg/Library/BdsLib/Arm/BdsLinuxAtag.c delete mode 100644 ArmPkg/Library/BdsLib/Arm/BdsLinuxLoader.c delete mode 100644 ArmPkg/Library/BdsLib/BdsLinuxFdt.c delete mode 100644 ArmPkg/Library/BdsLib/BdsLinuxLoader.h create mode 100644 ArmPlatformPkg/Bds/BootLinux.c -- 2.1.1 -- Don't Limit Your Business. Reach for the Cloud
Re: [edk2] [PATCH 1/3] ArmPlatformPkg/ArmVExpressPkg: add ArmPlatformSysConfigLib for runtime
Thanks for confirming the explanation.
I was initially thinking to ask you for a new patchset to fix the coding style.
But the original version (ie:
ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSysConfigLib) has the same
coding style issue.
Reviewed-By: Olivier Martin olivier.mar...@arm.com
I pushed the patchset in SVN rev17925-17927. Thanks for the contribution :-)
-Original Message-
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
Sent: 09 July 2015 18:30
To: Olivier Martin
Cc: edk2-devel@lists.sourceforge.net; ryan.har...@linaro.org;
leif.lindh...@linaro.org
Subject: Re: [PATCH 1/3] ArmPlatformPkg/ArmVExpressPkg: add
ArmPlatformSysConfigLib for runtime
On 9 July 2015 at 19:21, Olivier Martin olivier.mar...@arm.com wrote:
I can see few coding style issue in this patch - mainly missing space between
function name and '('.
Out of curiosity why you do not convert the base address of the System
Register when we switch to Runtime - like in
ArmPlatformPkg/Library/PL031RealTimeClockLib/PL031RealTimeClockLib.c?
Doing that we could reset the board from Linux using UEFI Runtime Services.
Are you worry by a race condition when the System Registers are accessed by
Linux and UEFI firmware in the same time?
Indeed. The system register block is a multi-function device that is described
by a single node in the device tree, and Linux binds a single driver to it.
Ideally, runtime MMIO regions should be disjoint from MMIO owned by the kernel,
since there is no coordination possible at all between the firmware and the OS..
Perhaps in this particular case, we could get away with it, but I think it is a
pattern that we want to discourage, so it does not belong in a reference
implementation.
--
Ard.
-Original Message-
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
Sent: 06 July 2015 19:26
To: edk2-devel@lists.sourceforge.net; ryan.har...@linaro.org; Olivier Martin;
leif.lindh...@linaro.org
Cc: Ard Biesheuvel
Subject: [PATCH 1/3] ArmPlatformPkg/ArmVExpressPkg: add
ArmPlatformSysConfigLib for runtime
This adds a ArmPlatformSysConfigLib implementation that is usable by
DXE_RUNTIME_DRIVER modules. Since the system registers that this library
encapsulates are not usable at runtime, this driver allows access to those
registers only at boot time.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
ArmPlatformPkg/ArmVExpressPkg/Library/{ArmVExpressSysConfigLib/ArmVExpressSysConfig.c
= ArmVExpressSysConfigRuntimeLib/ArmVExpressSysConfigRuntimeLib.c}|
10 ++
ArmPlatformPkg/ArmVExpressPkg/Library/{ArmVExpressSysConfigLib/ArmVExpressSysConfigLib.inf
= ArmVExpressSysConfigRuntimeLib/ArmVExpressSysConfigRuntimeLib.inf} | 12
+++-
2 files changed, 17 insertions(+), 5 deletions(-)
diff --git
a/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSysConfigLib/ArmVExpressSysConfig.c
b/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSysConfigRuntimeLib/ArmVExpressSysConfigRuntimeLib.c
similarity index 93%
copy from
ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSysConfigLib/ArmVExpressSysConfig.c
copy to
ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSysConfigRuntimeLib/ArmVExpressSysConfigRuntimeLib.c
index 6dfbacd11762..1f915e3b0225 100644
---
a/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSysConfigLib/ArmVExpressSysConfig.c
+++ b/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSysConfigRuntimeL
+++ ib/ArmVExpressSysConfigRuntimeLib.c
@@ -19,6 +19,9 @@
#include Library/ArmPlatformSysConfigLib.h
#include ArmPlatform.h
+#include Uefi.h
+#include Library/UefiRuntimeLib.h
+
//
// SYS_CFGCTRL Bits
//
@@ -72,6 +75,10 @@ AccessSysCfgRegister ( {
UINT32 SysCfgCtrl;
+ if (EfiAtRuntime ()) {
+return RETURN_UNSUPPORTED;
+ }
+
// Clear the COMPLETE bit
MmioAnd32(ARM_VE_SYS_CFGSTAT_REG, ~SYS_CFGSTAT_COMPLETE);
@@ -229,6 +236,9 @@ ArmPlatformSysConfigSetDevice (
switch(Function) {
case SYS_CFG_SCC:
#ifdef ARM_VE_SCC_BASE
+if (EfiAtRuntime ()) {
+ return RETURN_UNSUPPORTED;
+}
MmioWrite32 ((ARM_VE_SCC_BASE + (Device * 4)),Value);
return RETURN_SUCCESS;
#else
diff --git
a/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSysConfigLib/ArmVExpressSysConfigLib.inf
b/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSysConfigRuntimeLib/ArmVExpressSysConfigRuntimeLib.inf
similarity index 65%
copy from
ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSysConfigLib/ArmVExpressSysConfigLib.inf
copy to
ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSysConfigRuntimeLib/ArmVExpressSysConfigRuntimeLib.inf
index b89455a421c3..988250d930cb 100644
---
a/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSysConfigLib/ArmVExpressSysConfigLib.inf
+++ b/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSysConfigRuntimeL
+++ ib
Re: [edk2] [PATCH] OvmfPkg/VirtioLib: Ensure VirtioFlush() is not blocked
Thanks Lazlo, I had this issue with the ARM FVP Models and its Virtio support
(see:
http://infocenter.arm.com/help/topic/com.arm.doc.dui0834a/Chunk446462681.html).
I do not remember which model version. I am happy to abandon this patch until I
track down the model version and an action is taken by the ARM model team to
fix it.
-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com]
Sent: 09 July 2015 18:30
To: Olivier Martin
Cc: jordan.l.jus...@intel.com; edk2-devel@lists.sourceforge.net
Subject: Re: [PATCH] OvmfPkg/VirtioLib: Ensure VirtioFlush() is not blocked
On 07/09/15 18:47, Olivier Martin wrote:
.. in case the platform does not received the used buffer from the
device, VirtioFlush() returns EFI_TIMEOUT.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Olivier Martin olivier.mar...@arm.com
---
OvmfPkg/Include/Library/VirtioLib.h | 3 +++
OvmfPkg/Library/VirtioLib/VirtioLib.c | 16 ++--
2 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/OvmfPkg/Include/Library/VirtioLib.h
b/OvmfPkg/Include/Library/VirtioLib.h
index 36527a5..62f6811 100644
--- a/OvmfPkg/Include/Library/VirtioLib.h
+++ b/OvmfPkg/Include/Library/VirtioLib.h
@@ -170,6 +170,9 @@ VirtioAppendDesc (
@return Error code from VirtIo-SetQueueNotify() if it fails.
+ @retval EFI_TIMEOUT If it did not received the used buffer from the device
+ in approximatively less than 10ms
+
@retval EFI_SUCCESS Otherwise, the host processed all descriptors.
**/
diff --git a/OvmfPkg/Library/VirtioLib/VirtioLib.c
b/OvmfPkg/Library/VirtioLib/VirtioLib.c
index 54cf225..566f596 100644
--- a/OvmfPkg/Library/VirtioLib/VirtioLib.c
+++ b/OvmfPkg/Library/VirtioLib/VirtioLib.c
@@ -3,7 +3,7 @@
Utility functions used by virtio device drivers.
Copyright (C) 2012, Red Hat, Inc.
- Portion of Copyright (C) 2013, ARM Ltd.
+ Portion of Copyright (C) 2013-2014, ARM Ltd.
This program and the accompanying materials are licensed and made available
under the terms and conditions of the BSD License which accompanies
this @@ -252,6 +252,9 @@ VirtioAppendDesc (
@return Error code from VirtIo-SetQueueNotify() if it fails.
+ @retval EFI_TIMEOUT If it did not received the used buffer from the device
+ in approximatively less than 10ms
+
@retval EFI_SUCCESS Otherwise, the host processed all descriptors.
**/
@@ -267,6 +270,7 @@ VirtioFlush (
UINT16 NextAvailIdx;
EFI_STATUS Status;
UINTN PollPeriodUsecs;
+ UINTN Timeout;
//
// virtio-0.9.5, 2.4.1.2 Updating the Available Ring @@ -304,16
+308,24 @@ VirtioFlush (
// Keep slowing down until we reach a poll period of slightly above 1 ms.
//
PollPeriodUsecs = 1;
+ Timeout = 0;
MemoryFence();
- while (*Ring-Used.Idx != NextAvailIdx) {
+ while ((*Ring-Used.Idx != NextAvailIdx) (Timeout 10)) {
gBS-Stall (PollPeriodUsecs); // calls
AcpiTimerLib::MicroSecondDelay
if (PollPeriodUsecs 1024) {
PollPeriodUsecs *= 2;
+} else {
+ Timeout++;
}
MemoryFence();
}
MemoryFence();
+
+ if (Timeout == 10) {
+return EFI_TIMEOUT;
+ }
+
return EFI_SUCCESS;
}
I think if this ever happens, that's a bug in the host / hypervisor.
Under what conditions are you seeing this as necessary?
VirtioFlush() blocks infinitely on purpose in this loop. The protocol does not
define any circumstances for timeout. The communicating peers are not connected
by a fragile network link, they are connected by host memory. Whenever you time
out, that's an arbitrary decision; it might even misfire dependent on host load.
If you think this is really necessary, then please introduce an integer PCD.
The default value of the PCD (probably 0) should preserve existing behavior.
The PCD should be then overridden by downstreams (by directly editing the
appropriate DSC file). Alternatively, if you have a specific host platform in
mind that necessitates this change (and for which the value 10 also seems
right), then please introduce a new build flag as well (in the affected
DSC(s)). People who build for that platform can then hardcode that flag in
their build scripts.
There are two users of VirtioFlush(): the virtio-blk and virtio-scsi drivers.
Both check for (and propagate) any errors returned by
VirtioFlush() correctly. Any timeout error would reach the outermost callers
(the respective protocol users) just fine. So those parts of the tree need not
be fixed up, I agree. Still, this patch would work around a host bug, as far as
I understand, and the actual timeout looks arbitrary, so it should be off by
default, and controllable without modifying the C source.
The commit message (and the PCD's comment) should also identify the host
platform that requires this as precisely as possible.
... Obviously, it is *also* possible
Re: [edk2] [PATCH] BaseTools/GenFw: Added AArch64 page-relative relocations
-Original Message-
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
Sent: 08 July 2015 18:50
To: Olivier Martin
Cc: Leif Lindholm; edk2-devel@lists.sourceforge.net; Harry Liebel
Subject: Re: [PATCH] BaseTools/GenFw: Added AArch64 page-relative
relocations
On 8 July 2015 at 16:57, Olivier Martin olivier.mar...@arm.com wrote:
When EDK2 is built for the small memory model with AArch64 LLVM, some
page-relative relocations (R_AARCH64_ADR_PREL_PG_HI21 and its
R_AARCH64_LDST(16|32|64|128)_ABS_LO12_NC companions) that were
not
supported before by EDK2 BaseTools are now needed.
This change adds support for these relocations in BaseTools.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Harry Liebel harry.lie...@arm.com
Reviewed-by: Olivier Martin olivier.mar...@arm.com
I think all the relocation arithmetic looks fine.
I do have a concern about the consequences of using the small C model in
this way: nothing in the metadata of the resulting PE/COFF images reflects
that the 4 KB alignment needs to be preserved in order to successfully
execute them, so you are essentially producing corrupt images. Every
PE/COFF loader needs to be modified (including the ones in GRUB and shim,
for instance) to prevent such images from being loaded in an incorrect way. (I
know that most PE/COFF loaders use
AllocatePages() which aligns these binaries at 4 KB implicitly, but this is
not
mandatory)
So the correct way to do this would be to only use the small C model when
this alignment can be guaranteed, i.e., .text and .data are both aligned at 4
KB. With the latest GenFw changes in place (which sets PE/COFF section
alignment to the largest ELF input section alignment it encounters), the small
C model works correctly since the PE/COFF loaders adhere to the PE/COFF
section alignment. As a bonus, the ELF and PE/COFF images will be laid out
identically in memory, so all the recalculation arithmetic becomes
unnecessary (although it probably makes sense to perform some checks
here)
If I add support in 'MdePkg/Library/BasePeCoffLib' to prevent the image loading
if the .text sections are not aligned on 4K when these page-relative
relocations are used, would you consider this patchset?
In practical this error should never be exposed as AllocatePages() allocate the
buffer on a 4K boundary.
The downside, of course, is that 4 KB alignment for both .text and .data
wastes a lot of space: 3.5 KB only for the padding between the PE/COFF
header and the start of .text, and 2 KB on average between .text and .data.
Due to the compression of non-XIP binaries, this is not such a penalty, but
for
XIP it is prohibitive (even if these typically don't have a .data section)
I am going to have a look at GenFv to figure out if there is some way to work
around this, i.e., drop the PE/COFF headers or move them in some way.
In the mean time, I think this patch is good except the first hunk.
The small model relocation arithmetic can be merged separately, I think, and
the logic and policies around how and when to relocate PE/COFF images can
be addressed in a followup patch.
Sorry, I am not sure to understand which part of the patch you would like me to
split...
--
Ard.
---
BaseTools/Source/C/Common/BasePeCoff.c | 14 +++
BaseTools/Source/C/Common/PeCoffLib.h | 13 +++
BaseTools/Source/C/Common/PeCoffLoaderEx.c | 58 +++
BaseTools/Source/C/GenFw/Elf64Convert.c| 159
+++--
BaseTools/Source/C/GenFw/elf_common.h | 4 +
5 files changed, 215 insertions(+), 33 deletions(-)
diff --git a/BaseTools/Source/C/Common/BasePeCoff.c
b/BaseTools/Source/C/Common/BasePeCoff.c
index afb45df..e1401f2 100644
--- a/BaseTools/Source/C/Common/BasePeCoff.c
+++ b/BaseTools/Source/C/Common/BasePeCoff.c
@@ -715,6 +715,20 @@ Returns:
RelocBaseEnd = (EFI_IMAGE_BASE_RELOCATION *) ((UINTN) RelocBase
+ (UINTN) RelocDir-Size - 1);
}
+ // In order for page relative code relocations to work on AArch64 we
need to
+ // ensure that any address adjustment to images are 4k page aligned.
The page
+ // relative relocations are processed at build time as we do not have
enough
+ // information at runtime to recalculate them.
+ // The PE/COFF Base relocation types do not have a matching type to
describe
+ // page relative relocations so we do not know if they may be present in
the
+ // images. We must assume they are present and ensure the image is
properly
+ // aligned to keep these relocations valid.
+ if (ImageContext-Machine == EFI_IMAGE_MACHINE_AARCH64) {
+if ((Adjust 0xfff) != 0x0) {
+ return RETURN_LOAD_ERROR;
+}
+ }
+
//
// Run the relocation information and apply the fixups
//
diff --git a/BaseTools/Source/C/Common/PeCoffLib.h
b/BaseTools/Source/C/Common/PeCoffLib.h
index b56dd75..2f8feb7 100644
--- a/BaseTools
Re: [edk2] [PATCH] BaseTools: aarch64: add -fno-asynchronous-unwind-tables to gcc cflags
The change has been committed into SVN rev17905. -Original Message- From: Linaro-uefi [mailto:linaro-uefi-boun...@lists.linaro.org] On Behalf Of Olivier Martin Sent: 09 July 2015 17:24 To: Leif Lindholm; edk2-devel@lists.sourceforge.net Cc: yingke.d@intel.com; linaro-u...@lists.linaro.org Subject: Re: [Linaro-uefi] [PATCH] BaseTools: aarch64: add -fno-asynchronous-unwind-tables to gcc cflags Reviewed-By: Olivier Martin olivier.mar...@arm.com -Original Message- From: Leif Lindholm [mailto:leif.lindh...@linaro.org] Sent: 09 July 2015 14:48 To: edk2-devel@lists.sourceforge.net Cc: yingke.d@intel.com; Olivier Martin; linaro-u...@lists.linaro.org Subject: [PATCH] BaseTools: aarch64: add -fno-asynchronous-unwind-tables to gcc cflags Some toolchains, at least Fedora GCC, generate inline unwind tables in object files. These confuses GenFw to no end, leading to build failures: GenFw: ERROR 3000: Invalid WriteSections64(): ... unsupported ELF EM_AARCH64 relocation 0x105. GenFw: ERROR 3000: Invalid WriteSections64(): ... unsupported ELF EM_AARCH64 relocation 0x0. I am aware of no current use of these tables, so explicitly disable their generation for aarch64. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Leif Lindholm leif.lindh...@linaro.org --- BaseTools/Conf/tools_def.template | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/BaseTools/Conf/tools_def.template b/BaseTools/Conf/tools_def.template index 7edd759..8e5750e 100644 --- a/BaseTools/Conf/tools_def.template +++ b/BaseTools/Conf/tools_def.template @@ -3818,7 +3818,7 @@ DEFINE GCC_IA32_CC_FLAGS = DEF(GCC_ALL_CC_FLAGS) -m32 -malign-double - DEFINE GCC_X64_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mno-red-zone -Wno-address -mno-stack-arg-probe DEFINE GCC_IPF_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -minline-int-divide-min-latency DEFINE GCC_ARM_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mword-relocations -mlittle-endian -mabi=aapcs -mapcs -fno-short-enums -save-temps -fsigned-char -ffunction-sections -fdata-sections -fomit-frame-pointer -Wno-address -mthumb -mfloat-abi=soft -DEFINE GCC_AARCH64_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mcmodel=large -mlittle-endian -fno-short-enums -save-temps -fverbose-asm -fsigned-char -ffunction-sections -fdata-sections -fomit-frame-pointer -fno-builtin -Wno-address +DEFINE GCC_AARCH64_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mcmodel=large -mlittle-endian -fno-short-enums -save-temps -fverbose-asm -fsigned-char -ffunction-sections -fdata-sections -fomit-frame-pointer -fno-builtin -Wno-address -fno-asynchronous-unwind-tables DEFINE GCC_DLINK_FLAGS_COMMON = -nostdlib --pie DEFINE GCC_IA32_X64_DLINK_COMMON = DEF(GCC_DLINK_FLAGS_COMMON) --gc-sections DEFINE GCC_ARM_AARCH64_DLINK_COMMON= --emit-relocs -nostdlib --gc-sections -u $(IMAGE_ENTRY_POINT) -e $(IMAGE_ENTRY_POINT) -Map $(DEST_DIR_DEBUG)/$(BASE_NAME).map -- 2.1.4 -- 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. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2548782 ___ Linaro-uefi mailing list linaro-u...@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-uefi -- 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. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2548782 -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] [PATCH 1/3] ArmPlatformPkg/ArmVExpressPkg: add ArmPlatformSysConfigLib for runtime
I can see few coding style issue in this patch - mainly missing space between
function name and '('.
Out of curiosity why you do not convert the base address of the System Register
when we switch to Runtime - like in
ArmPlatformPkg/Library/PL031RealTimeClockLib/PL031RealTimeClockLib.c?
Doing that we could reset the board from Linux using UEFI Runtime Services.
Are you worry by a race condition when the System Registers are accessed by
Linux and UEFI firmware in the same time?
-Original Message-
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
Sent: 06 July 2015 19:26
To: edk2-devel@lists.sourceforge.net; ryan.har...@linaro.org; Olivier Martin;
leif.lindh...@linaro.org
Cc: Ard Biesheuvel
Subject: [PATCH 1/3] ArmPlatformPkg/ArmVExpressPkg: add ArmPlatformSysConfigLib
for runtime
This adds a ArmPlatformSysConfigLib implementation that is usable by
DXE_RUNTIME_DRIVER modules. Since the system registers that this library
encapsulates are not usable at runtime, this driver allows access to those
registers only at boot time.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
ArmPlatformPkg/ArmVExpressPkg/Library/{ArmVExpressSysConfigLib/ArmVExpressSysConfig.c
= ArmVExpressSysConfigRuntimeLib/ArmVExpressSysConfigRuntimeLib.c}|
10 ++
ArmPlatformPkg/ArmVExpressPkg/Library/{ArmVExpressSysConfigLib/ArmVExpressSysConfigLib.inf
= ArmVExpressSysConfigRuntimeLib/ArmVExpressSysConfigRuntimeLib.inf} | 12
+++-
2 files changed, 17 insertions(+), 5 deletions(-)
diff --git
a/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSysConfigLib/ArmVExpressSysConfig.c
b/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSysConfigRuntimeLib/ArmVExpressSysConfigRuntimeLib.c
similarity index 93%
copy from
ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSysConfigLib/ArmVExpressSysConfig.c
copy to
ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSysConfigRuntimeLib/ArmVExpressSysConfigRuntimeLib.c
index 6dfbacd11762..1f915e3b0225 100644
---
a/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSysConfigLib/ArmVExpressSysConfig.c
+++ b/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSysConfigRuntimeL
+++ ib/ArmVExpressSysConfigRuntimeLib.c
@@ -19,6 +19,9 @@
#include Library/ArmPlatformSysConfigLib.h
#include ArmPlatform.h
+#include Uefi.h
+#include Library/UefiRuntimeLib.h
+
//
// SYS_CFGCTRL Bits
//
@@ -72,6 +75,10 @@ AccessSysCfgRegister ( {
UINT32 SysCfgCtrl;
+ if (EfiAtRuntime ()) {
+return RETURN_UNSUPPORTED;
+ }
+
// Clear the COMPLETE bit
MmioAnd32(ARM_VE_SYS_CFGSTAT_REG, ~SYS_CFGSTAT_COMPLETE);
@@ -229,6 +236,9 @@ ArmPlatformSysConfigSetDevice (
switch(Function) {
case SYS_CFG_SCC:
#ifdef ARM_VE_SCC_BASE
+if (EfiAtRuntime ()) {
+ return RETURN_UNSUPPORTED;
+}
MmioWrite32 ((ARM_VE_SCC_BASE + (Device * 4)),Value);
return RETURN_SUCCESS;
#else
diff --git
a/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSysConfigLib/ArmVExpressSysConfigLib.inf
b/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSysConfigRuntimeLib/ArmVExpressSysConfigRuntimeLib.inf
similarity index 65%
copy from
ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSysConfigLib/ArmVExpressSysConfigLib.inf
copy to
ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSysConfigRuntimeLib/ArmVExpressSysConfigRuntimeLib.inf
index b89455a421c3..988250d930cb 100644
---
a/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSysConfigLib/ArmVExpressSysConfigLib.inf
+++ b/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSysConfigRuntimeL
+++ ib/ArmVExpressSysConfigRuntimeLib.inf
@@ -1,8 +1,9 @@
#/** @file
#
-# Component description file for ArmVExpressSysConfigLib module
+# Component description file for ArmVExpressSysConfigRuntimeLib module
#
# Copyright (c) 2011-2012, ARM Ltd. All rights reserved.BR
+# Copyright (c) 2015, Linaro Ltd. All rights reserved.BR
#
# This program and the accompanying materials # are licensed and made
available under the terms and conditions of the BSD License @@ -16,14 +17,14 @@
[Defines]
INF_VERSION= 0x00010005
- BASE_NAME = ArmVExpressSysConfigLib
- FILE_GUID = a05b5cc0-82d2-11e0-82cb-0002a5d5c51b
+ BASE_NAME = ArmVExpressSysConfigRuntimeLib
+ FILE_GUID = 6275b819-615c-4a36-814a-c1f330b4e5d9
MODULE_TYPE= BASE
VERSION_STRING = 1.0
- LIBRARY_CLASS = ArmPlatformSysConfigLib|SEC DXE_DRIVER
+ LIBRARY_CLASS = ArmPlatformSysConfigLib|DXE_RUNTIME_DRIVER
[Sources.common]
- ArmVExpressSysConfig.c
+ ArmVExpressSysConfigRuntimeLib.c
[Packages]
MdePkg/MdePkg.dec
@@ -33,3 +34,4 @@ [Packages]
[LibraryClasses]
BaseLib
IoLib
+ UefiRuntimeLib
--
1.9.1
-- IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged
Re: [edk2] [PATCH 3/3] ArmVExpressPkg: use PSCI for system reset only on AARCH64 platforms
Reviewed-By: Olivier Martin olivier.mar...@arm.com -Original Message- From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] Sent: 06 July 2015 19:26 To: edk2-devel@lists.sourceforge.net; ryan.har...@linaro.org; Olivier Martin; leif.lindh...@linaro.org Cc: Ard Biesheuvel Subject: [PATCH 3/3] ArmVExpressPkg: use PSCI for system reset only on AARCH64 platforms The PSCI specification covers both ARM and AARCH64, however, the ARM Trusted Firmware (ATF) reference implementation is only available for AARCH64, and PSCI firmware is not widely available for ARM platforms. So use the EfiResetSystemLib implementation that uses PSCI calls only on AARCH64, and revert to the Versatile Express-specific system register interface (which is only available during boot time) on ARM platforms. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org --- ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc | 1 + 1 file changed, 1 insertion(+) diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc index 706861d5e2ec..d9e06781d2a5 100644 --- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc +++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc @@ -223,6 +223,7 @@ [LibraryClasses.common.DXE_RUNTIME_DRIVER] CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibNull/DxeCapsuleLibNull.inf ArmPlatformSysConfigLib|ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSysConfigRuntimeLib/ArmVExpressSysConfigRuntimeLib.inf +[LibraryClasses.AARCH64.DXE_RUNTIME_DRIVER] # # PSCI support in EL3 may not be available if we are not running under a PSCI # compliant secure firmware, but since the default VExpress EfiResetSystemLib -- 1.9.1 -- 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. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2548782 -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] [PATCH 2/3] ArmVExpressPkg: use ArmVExpressSysConfigRuntimeLib by default
Reviewed-By: Olivier Martin olivier.mar...@arm.com -Original Message- From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] Sent: 06 July 2015 19:26 To: edk2-devel@lists.sourceforge.net; ryan.har...@linaro.org; Olivier Martin; leif.lindh...@linaro.org Cc: Ard Biesheuvel Subject: [PATCH 2/3] ArmVExpressPkg: use ArmVExpressSysConfigRuntimeLib by default Instead of using a NULL implementation of ArmPlatformSysConfigLib for DXE_RUNTIME_DRIVER modules, which prevents them from accessing system control registers even at boot time, use the new implementation that only switches into a non-functional mode at runtime, and operates as before otherwise. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org --- ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc index 1ca9b2de6550..706861d5e2ec 100644 --- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc +++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc @@ -221,7 +221,7 @@ [LibraryClasses.common.DXE_RUNTIME_DRIVER] MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf ReportStatusCodeLib|IntelFrameworkModulePkg/Library/DxeReportStatusCodeLibFramework/DxeReportStatusCodeLib.inf CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibNull/DxeCapsuleLibNull.inf - ArmPlatformSysConfigLib|ArmPlatformPkg/Library/ArmPlatformSysConfigLibNull/ArmPlatformSysConfigLibNull.inf + + ArmPlatformSysConfigLib|ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpr + essSysConfigRuntimeLib/ArmVExpressSysConfigRuntimeLib.inf # # PSCI support in EL3 may not be available if we are not running under a PSCI -- 1.9.1 -- 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. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2548782 -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] [PATCH] MdeModulePkg/Core/Pei: Fix empty loop warning
I have been trying to duplicate this issue using the '-pedantic' options of
LLVM and GCC and I cannot reproduce this issue - even if it still present in
the code.
Feng, are you happy with my initial patch - the one that aligns the code with
the EDK2 coding style?
From: Andrew Fish [mailto:af...@apple.com]
Sent: 16 January 2014 00:03
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] [PATCH] MdeModulePkg/Core/Pei: Fix empty loop warning
Olivier,
Xcode 5 does not warn by default on that construct. Would it be possible to
post the warning to the mailing list? clang is good about letting you know
which diagnostic warning is failing, and the compiler flag associated with that
warning.
for.c:8:23: warning: comparison of unsigned expression 0 is always false
[-Wtautological-compare]
for (i=0; i10 || i 0; i++);
~ ^ ~
1 warning generated.
Thanks,
Andrew Fish
On Jan 15, 2014, at 3:53 PM, Olivier Martin
olivier.mar...@arm.commailto:olivier.mar...@arm.com wrote:
Hi Feng,
the toolchain was LLVM. But my colleague who raised the issue said there were
many other cases.
Thanks,
Olivier
From: Tian, Feng [feng.t...@intel.commailto:feng.t...@intel.com]
Sent: 15 January 2014 23:34
To: edk2-devel@lists.sourceforge.netmailto:edk2-devel@lists.sourceforge.net;
Dong, Eric
Subject: Re: [edk2] [PATCH] MdeModulePkg/Core/Pei: Fix empty loop warning
Hi, Olivier
Could you let me know which toolchains would raise warning on such usage?
I have a little curious why it doesn't happen at CpuDeadLoop() of MdePkg
BaseLib.
CpuDeadLoop() {
...
for (Index = 0; Index == 0;);
}
Thanks
Feng
From: Olivier Martin [mailto:olivier.mar...@arm.com]
Sent: Wednesday, January 15, 2014 20:29
To: Dong, Eric
Cc: edk2-devel@lists.sourceforge.netmailto:edk2-devel@lists.sourceforge.net
Subject: [edk2] [PATCH] MdeModulePkg/Core/Pei: Fix empty loop warning
Dear MdeModulePkg maintainers,
Please see the attached patch that fix the PeiCore code to comply with the EDK2
Coding Standard - some toolchains raise a warning on empty loop.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Olivier Martin
olivier.mar...@arm.commailto:olivier.mar...@arm.commailto:olivier.mar...@arm.com
Regards,
Olivier
-- 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.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered
in England Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England Wales, Company No: 2548782
--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.netmailto:edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
-- 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.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered
in England Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England Wales, Company No: 2548782
--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] [PATCH] MdeModulePkg/FvSimpleFileSystemDxe: Support file opening with no '.efi'
Can you try without using EFI Shell? If you check at the code of FvSimpleFileSystemOpen(), there is no way it works. I am guessing EFI Shell try to open the file with and without '.EFI' extension. And actually, after searching quickly in ShellPkg, you can find: /** Find a file by searching the CWD and then the path with a variable set of file extensions. If the file is not found it will append each extension in the list in the order provided and return the first one that is successful. If FileName is NULL, then ASSERT. If FileExtension is NULL, then behavior is identical to ShellFindFilePath. If the return value is not NULL then the memory must be caller freed. @param[in] FileName Filename string. @param[in] FileExtension Semi-colon delimeted list of possible extensions. @retval NULL The file was not found. @retval !NULL The path to the file. **/ CHAR16 * EFIAPI ShellFindFilePathEx ( IN CONST CHAR16 *FileName, IN CONST CHAR16 *FileExtension ) -Original Message- From: Tian, Feng [mailto:feng.t...@intel.com] Sent: 09 July 2015 09:39 To: Olivier Martin Cc: edk2-devel@lists.sourceforge.net; Tian, Feng Subject: RE: [PATCH] MdeModulePkg/FvSimpleFileSystemDxe: Support file opening with no '.efi' Hi, Martin I tested old code behavior on NT32 platform by adding MdeModulePkg/Application/VariableInfo/VariableInfo.inf MdeModulePkg\Universal\FvSimpleFileSystemDxe\FvSimpleFileSystemDxe.inf to DSCFDF files. Under shell, the application VariableInfo could run by enter VariableInfo or VariableInfo.efi cmd. Do I misunderstand something? Thanks Feng -Original Message- From: Olivier Martin [mailto:olivier.mar...@arm.com] Sent: Thursday, July 09, 2015 00:32 To: Tian, Feng Cc: edk2-devel@lists.sourceforge.net Subject: RE: [PATCH] MdeModulePkg/FvSimpleFileSystemDxe: Support file opening with no '.efi' You are saying If user enter Shell or Shell.efi, it should run for both cases. But it is actually the case I am trying to solve with this patch :-) FvSimpleFileSystemOpen() was only checking if there was strict equality between the given name and the name exposed by FvSimpleFileSystemDxe (ie: the name with .EFI). It means if you try to open the file Shell (the name you gave in the UI section) it would not work. -Original Message- From: Tian, Feng [mailto:feng.t...@intel.com] Sent: 08 July 2015 06:38 To: Olivier Martin Cc: edk2-devel@lists.sourceforge.net; Tian, Feng Subject: RE: [PATCH] MdeModulePkg/FvSimpleFileSystemDxe: Support file opening with no '.efi' Hi, Martin I am a little confused by your description on the issue. EDKII build system puts $BASE_NAME string to UI section and generate $BASE_NAME.efi file name at build directory. The FvSimpleFileSystem driver adds .efi postfix to string gotten from each UI section for all executable file types. So my understanding is these two strings are identical and should not bring confusion. And why it's not possible to open an EFI application without the .efi extension? If user enter Shell or Shell.efi, it should run for both cases. Thanks Feng -Original Message- From: Olivier Martin [mailto:olivier.mar...@arm.com] Sent: Tuesday, July 07, 2015 00:17 To: Tian, Feng Cc: edk2-devel@lists.sourceforge.net; Olivier Martin; Olivier Martin Subject: [PATCH] MdeModulePkg/FvSimpleFileSystemDxe: Support file opening with no '.efi' FvSimpleFileSystem adds '.efi' to the EFI application and drivers filenames even through this extension is not present in the real filename of the EFI module. In the current behaviour, it would not be possible to open an EFI application using FvSimpleFileSystem if the extension has been omitted in the given filename. It can be create some confusion if someone wants to try to open a file with the real application name (eg: 'Shell'). This patch adds support to try again to look for the file with the extension if it had failed to find it without the extension. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Olivier Martin olivier.mar...@arm.com --- .../FvSimpleFileSystemDxe/FvSimpleFileSystem.c | 62 +- 1 file changed, 50 insertions(+), 12 deletions(-) diff --git a/MdeModulePkg/Universal/FvSimpleFileSystemDxe/FvSimpleFileSystem.c b/MdeModulePkg/Universal/FvSimpleFileSystemDxe/FvSimpleFileSystem.c index b0e7dc3..c6137ac 100644 --- a/MdeModulePkg/Universal/FvSimpleFileSystemDxe/FvSimpleFileSystem.c +++ b/MdeModulePkg/Universal/FvSimpleFileSystemDxe/FvSimpleFileSystem.c @@ -483,6 +483,10 @@ FvSimpleFileSystemOpen ( FV_FILESYSTEM_FILE *NewFile; FV_FILESYSTEM_FILE_INFO *FvFileInfo; LIST_ENTRY *FvFileInfoLink; + EFI_STATUS Status; + UINTN FileNameLength; + UINTN NewFileNameLength; + CHAR16 *FileNameWithExtension; // // Check for a valid mode
Re: [edk2] [PATCH] BaseTools/GCC: allow unused but set variables
About the build infrastructure. An option would be to investigate solution like travis-ci (https://travis-ci.com/). The little I know about travis-ci is it is free for open-source project, it can follow your github project and report if it builds or not (as soon as your build does not take more than 10-15min). When you send github 'push-request' it can also say if you break the build. The build script is part of your repository (*.travis.yml), so everyone can contribute to it. -Original Message- From: Laszlo Ersek [mailto:ler...@redhat.com] Sent: 08 July 2015 20:02 To: Bill Paul Cc: edk2-devel@lists.sourceforge.net; Scott Duplichan; Olivier Martin; leif.lindh...@linaro.org; jordan.l.jus...@intel.com Subject: Re: [edk2] [PATCH] BaseTools/GCC: allow unused but set variables On 07/08/15 20:15, Bill Paul wrote: Of all the gin joints in all the towns in all the world, Laszlo Ersek had to walk into mine at 09:17:08 on Wednesday 08 July 2015 and say: In the above pattern, ASSERT_EFI_ERROR() is not necessarily used for error handling. You are absolutely right: it's not. It's being used as a panic(). Good point! I guess I've always used ASSERT() in the sense of PANIC_UNLESS(). [...] There is also DEBUG(). You will find several instances of the following construction: int SomeInterestingValue; /* Populate SomeInterestingValue */ SomeInterestingValue = GetSomeInterestingStatus (handle); /* SomeInterestingValue is never referenced again */ DEBUG(EFI_D_INFO, INTERESTING VALUE IS: %d\n, SomeInterestingValue); DEBUG() is also disabled when MDEPKG_NDEBUG is enabled, which creates the same problem. What would be the correct way to handle this case? Honestly, I don't know. I only concern myself with the case when even DEBUG_VERBOSE is enabled (PcdDebugPrintErrorLevel == 0x8040004F). The case when I have to look at debug messages and analyze behavior is the *norm*, not the exception (even if OVMF is not at fault -- the user may have passed wrong QEMU options, for example). It's an incredible chore when a user reports behavior he doesn't understand or expect, and I first have to ask him to reproduce on a DEBUG_VERBOSE build, and that he send me *that* log. Usually he has no access to such a build, cannot build one himself, so I get to build it for him. Blech. (I think Gerd's packages do enable DEBUG_VERBOSE, but I'm not sure.) It should be noted that once in a while I run into this sort of thing in VxWorks as well, only it's often the other way around. We typically have DEBUG()-style messages turned off by default, and sometimes there are debug messages that refer to variables which no longer exist in the code. (The variables were removed but the debug messages were never updated to match.) SeaBIOS employs the following trick to avoid this: all CONFIG_ flags are checked in regular if() statements, not in #if macros. That is, any elmination happens during compilation / optimization / linking, not in preprocessing. This allows the compiler to catch such errors even when a CONFIG_ option is predominantly false (or predominantly true). Right. I do agree with you that the optimal solution would be a build farm where all developers could test-build against all supported compilers. I doubt it's ever going to happen. Given that UEFI firmware is supposed to be the standard for a large number of commercially available computer platforms, I find your lack of faith... disturbing. My lack of faith is based on experience :) We've been complaining about this for ages on the list. I think it is safe to assume that the primary participant that has legal access to all supported Microsoft toolchains is Intel. As described (and provided!) by Scott, gcc-for-Windows is almost trivially available (all supported gcc versions). It seems to follow that Intel should operate such a build farm. Based on how long we've been whining about this, I don't think it's going to happen any time soon. Lastly, yesterday I actually spent some time updating the mingw-gcc-build.py to support binutils 2.25 and GCC 4.9.3, and I ran into this exact issue. I had to add -Wno-unused-but-set-variable to the UNIXGCC instances of CC_FLAGS in tools_def.template in order to get the OVMF build to work. But along the way, I noticed about a dozen instances of this anti-pattern. There are at least as many cases that stem from DEBUG() rather than ASSERT() or ASSERT_EFI_ERROR(). However I also found at least one legitimate error case of a useless set but never used variable too (i.e. a case that didn't involve conditional compilation effects). This means that now that GCC has been muzzled to disguise intentional abuses of this pattern, some unintentional abuses are now being hidden too. Optimally, we shouldn't conflate the different (deeper) reasons this warning gets emitted for. Unfortunately, it's not practical even for me to build OVMF in all possible
Re: [edk2] [PATCH] MdeModulePkg/FvSimpleFileSystemDxe: Support file opening with no '.efi'
I would say if should be done by the callee because this behaviour is only specific to FvSimpleFileSystemDxe. In fact it is FvSimpleFileSystemDxe who lies about the real name of the application. That's why I think it should be done by this driver :-) -Original Message- From: Tian, Feng [mailto:feng.t...@intel.com] Sent: 09 July 2015 10:09 To: Olivier Martin Cc: edk2-devel@lists.sourceforge.net; Tian, Feng Subject: RE: [PATCH] MdeModulePkg/FvSimpleFileSystemDxe: Support file opening with no '.efi' Martin, Got your point now. Do you think such behavior (extension matching) should be done in caller or callee? From ShellPkg implementation, it's done by caller. But if you vote the callee to do this, I am also ok with your patch:). Reveiwed-by: Feng Tian feng.t...@intel.com Thanks Feng -Original Message- From: Olivier Martin [mailto:olivier.mar...@arm.com] Sent: Thursday, July 09, 2015 16:53 To: Tian, Feng Cc: edk2-devel@lists.sourceforge.net Subject: RE: [PATCH] MdeModulePkg/FvSimpleFileSystemDxe: Support file opening with no '.efi' Can you try without using EFI Shell? If you check at the code of FvSimpleFileSystemOpen(), there is no way it works. I am guessing EFI Shell try to open the file with and without '.EFI' extension. And actually, after searching quickly in ShellPkg, you can find: /** Find a file by searching the CWD and then the path with a variable set of file extensions. If the file is not found it will append each extension in the list in the order provided and return the first one that is successful. If FileName is NULL, then ASSERT. If FileExtension is NULL, then behavior is identical to ShellFindFilePath. If the return value is not NULL then the memory must be caller freed. @param[in] FileName Filename string. @param[in] FileExtension Semi-colon delimeted list of possible extensions. @retval NULL The file was not found. @retval !NULL The path to the file. **/ CHAR16 * EFIAPI ShellFindFilePathEx ( IN CONST CHAR16 *FileName, IN CONST CHAR16 *FileExtension ) -Original Message- From: Tian, Feng [mailto:feng.t...@intel.com] Sent: 09 July 2015 09:39 To: Olivier Martin Cc: edk2-devel@lists.sourceforge.net; Tian, Feng Subject: RE: [PATCH] MdeModulePkg/FvSimpleFileSystemDxe: Support file opening with no '.efi' Hi, Martin I tested old code behavior on NT32 platform by adding MdeModulePkg/Application/VariableInfo/VariableInfo.inf MdeModulePkg\Universal\FvSimpleFileSystemDxe\FvSimpleFileSystemDxe.inf to DSCFDF files. Under shell, the application VariableInfo could run by enter VariableInfo or VariableInfo.efi cmd. Do I misunderstand something? Thanks Feng -Original Message- From: Olivier Martin [mailto:olivier.mar...@arm.com] Sent: Thursday, July 09, 2015 00:32 To: Tian, Feng Cc: edk2-devel@lists.sourceforge.net Subject: RE: [PATCH] MdeModulePkg/FvSimpleFileSystemDxe: Support file opening with no '.efi' You are saying If user enter Shell or Shell.efi, it should run for both cases. But it is actually the case I am trying to solve with this patch :-) FvSimpleFileSystemOpen() was only checking if there was strict equality between the given name and the name exposed by FvSimpleFileSystemDxe (ie: the name with .EFI). It means if you try to open the file Shell (the name you gave in the UI section) it would not work. -Original Message- From: Tian, Feng [mailto:feng.t...@intel.com] Sent: 08 July 2015 06:38 To: Olivier Martin Cc: edk2-devel@lists.sourceforge.net; Tian, Feng Subject: RE: [PATCH] MdeModulePkg/FvSimpleFileSystemDxe: Support file opening with no '.efi' Hi, Martin I am a little confused by your description on the issue. EDKII build system puts $BASE_NAME string to UI section and generate $BASE_NAME.efi file name at build directory. The FvSimpleFileSystem driver adds .efi postfix to string gotten from each UI section for all executable file types. So my understanding is these two strings are identical and should not bring confusion. And why it's not possible to open an EFI application without the .efi extension? If user enter Shell or Shell.efi, it should run for both cases. Thanks Feng -Original Message- From: Olivier Martin [mailto:olivier.mar...@arm.com] Sent: Tuesday, July 07, 2015 00:17 To: Tian, Feng Cc: edk2-devel@lists.sourceforge.net; Olivier Martin; Olivier Martin Subject: [PATCH] MdeModulePkg/FvSimpleFileSystemDxe: Support file opening with no '.efi' FvSimpleFileSystem adds '.efi' to the EFI application and drivers filenames even through this extension is not present in the real filename of the EFI module. In the current behaviour, it would not be possible to open an EFI application using FvSimpleFileSystem if the extension has been omitted in the given filename. It can be create some confusion if someone wants to try to open a file with the real application name (eg: 'Shell'). This patch adds support to try
[edk2] [PATCH] OvmfPkg/VirtioLib: Ensure VirtioFlush() is not blocked
.. in case the platform does not received the used buffer from the
device, VirtioFlush() returns EFI_TIMEOUT.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Olivier Martin olivier.mar...@arm.com
---
OvmfPkg/Include/Library/VirtioLib.h | 3 +++
OvmfPkg/Library/VirtioLib/VirtioLib.c | 16 ++--
2 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/OvmfPkg/Include/Library/VirtioLib.h
b/OvmfPkg/Include/Library/VirtioLib.h
index 36527a5..62f6811 100644
--- a/OvmfPkg/Include/Library/VirtioLib.h
+++ b/OvmfPkg/Include/Library/VirtioLib.h
@@ -170,6 +170,9 @@ VirtioAppendDesc (
@return Error code from VirtIo-SetQueueNotify() if it fails.
+ @retval EFI_TIMEOUT If it did not received the used buffer from the device
+ in approximatively less than 10ms
+
@retval EFI_SUCCESS Otherwise, the host processed all descriptors.
**/
diff --git a/OvmfPkg/Library/VirtioLib/VirtioLib.c
b/OvmfPkg/Library/VirtioLib/VirtioLib.c
index 54cf225..566f596 100644
--- a/OvmfPkg/Library/VirtioLib/VirtioLib.c
+++ b/OvmfPkg/Library/VirtioLib/VirtioLib.c
@@ -3,7 +3,7 @@
Utility functions used by virtio device drivers.
Copyright (C) 2012, Red Hat, Inc.
- Portion of Copyright (C) 2013, ARM Ltd.
+ Portion of Copyright (C) 2013-2014, ARM Ltd.
This program and the accompanying materials are licensed and made available
under the terms and conditions of the BSD License which accompanies this
@@ -252,6 +252,9 @@ VirtioAppendDesc (
@return Error code from VirtIo-SetQueueNotify() if it fails.
+ @retval EFI_TIMEOUT If it did not received the used buffer from the device
+ in approximatively less than 10ms
+
@retval EFI_SUCCESS Otherwise, the host processed all descriptors.
**/
@@ -267,6 +270,7 @@ VirtioFlush (
UINT16 NextAvailIdx;
EFI_STATUS Status;
UINTN PollPeriodUsecs;
+ UINTN Timeout;
//
// virtio-0.9.5, 2.4.1.2 Updating the Available Ring
@@ -304,16 +308,24 @@ VirtioFlush (
// Keep slowing down until we reach a poll period of slightly above 1 ms.
//
PollPeriodUsecs = 1;
+ Timeout = 0;
MemoryFence();
- while (*Ring-Used.Idx != NextAvailIdx) {
+ while ((*Ring-Used.Idx != NextAvailIdx) (Timeout 10)) {
gBS-Stall (PollPeriodUsecs); // calls AcpiTimerLib::MicroSecondDelay
if (PollPeriodUsecs 1024) {
PollPeriodUsecs *= 2;
+} else {
+ Timeout++;
}
MemoryFence();
}
MemoryFence();
+
+ if (Timeout == 10) {
+return EFI_TIMEOUT;
+ }
+
return EFI_SUCCESS;
}
--
2.1.1
--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] [PATCH v2 4/7] ArmPlatformPkg: Remove Ip4ConfigDxe module from ArmPlatformPkg.
Same comment as Ard... At least, it would be nice to see Ip4ConfigDxe driver is deprecated in UEFI 2.5, so we will not support original Ip4Config Protocol, which is replace by Ip4Config2 Protocol integrated in Ip4Dxe driver. -Original Message- From: jiaxinwu [mailto:jiaxin...@intel.com] Sent: 08 July 2015 07:25 To: edk2-devel@lists.sourceforge.net Cc: Olivier Martin; Leif Lindholm Subject: [PATCH v2 4/7] ArmPlatformPkg: Remove Ip4ConfigDxe module from ArmPlatformPkg. Version2 update with a proper commit message. Cc: Olivier Martin olivier.mar...@arm.com Cc: Leif Lindholm leif.lindh...@linaro.org Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: jiaxinwu jiaxin...@intel.com --- ArmPlatformPkg/ArmJunoPkg/ArmJuno.fdf | 1 - ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA15-A7.fdf| 1 - ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA9x4.fdf | 1 - ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15.fdf| 1 - ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15_MPCore.fdf | 1 - ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc | 1 - 6 files changed, 6 deletions(-) diff --git a/ArmPlatformPkg/ArmJunoPkg/ArmJuno.fdf b/ArmPlatformPkg/ArmJunoPkg/ArmJuno.fdf index 5c15fda..9a0de9a 100644 --- a/ArmPlatformPkg/ArmJunoPkg/ArmJuno.fdf +++ b/ArmPlatformPkg/ArmJunoPkg/ArmJuno.fdf @@ -173,11 +173,10 @@ READ_LOCK_STATUS = TRUE # Networking stack # INF MdeModulePkg/Universal/Network/DpcDxe/DpcDxe.inf INF MdeModulePkg/Universal/Network/ArpDxe/ArpDxe.inf INF MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Dxe.inf - INF MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4ConfigDxe.inf INF MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Dxe.inf INF MdeModulePkg/Universal/Network/MnpDxe/MnpDxe.inf INF MdeModulePkg/Universal/Network/VlanConfigDxe/VlanConfigDxe.inf INF MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Dxe.inf INF MdeModulePkg/Universal/Network/Tcp4Dxe/Tcp4Dxe.inf diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA15-A7.fdf b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA15-A7.fdf index 893fb86..1e91734 100644 --- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA15-A7.fdf +++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA15-A7.fdf @@ -147,11 +147,10 @@ READ_LOCK_STATUS = TRUE # Networking stack # INF MdeModulePkg/Universal/Network/DpcDxe/DpcDxe.inf INF MdeModulePkg/Universal/Network/ArpDxe/ArpDxe.inf INF MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Dxe.inf - INF MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4ConfigDxe.inf INF MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Dxe.inf INF MdeModulePkg/Universal/Network/MnpDxe/MnpDxe.inf INF MdeModulePkg/Universal/Network/VlanConfigDxe/VlanConfigDxe.inf INF MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Dxe.inf INF MdeModulePkg/Universal/Network/Tcp4Dxe/Tcp4Dxe.inf diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA9x4.fdf b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA9x4.fdf index 6ee0b06..b80db3c 100644 --- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA9x4.fdf +++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA9x4.fdf @@ -216,11 +216,10 @@ READ_LOCK_STATUS = TRUE # Networking stack # INF MdeModulePkg/Universal/Network/DpcDxe/DpcDxe.inf INF MdeModulePkg/Universal/Network/ArpDxe/ArpDxe.inf INF MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Dxe.inf - INF MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4ConfigDxe.inf INF MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Dxe.inf INF MdeModulePkg/Universal/Network/MnpDxe/MnpDxe.inf INF MdeModulePkg/Universal/Network/VlanConfigDxe/VlanConfigDxe.inf INF MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Dxe.inf INF MdeModulePkg/Universal/Network/Tcp4Dxe/Tcp4Dxe.inf diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15.fdf b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15.fdf index 8994196..4301e23 100644 --- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15.fdf +++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15.fdf @@ -137,11 +137,10 @@ READ_LOCK_STATUS = TRUE # Networking stack # INF MdeModulePkg/Universal/Network/DpcDxe/DpcDxe.inf INF MdeModulePkg/Universal/Network/ArpDxe/ArpDxe.inf INF MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Dxe.inf - INF MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4ConfigDxe.inf INF MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Dxe.inf INF MdeModulePkg/Universal/Network/MnpDxe/MnpDxe.inf INF MdeModulePkg/Universal/Network/VlanConfigDxe/VlanConfigDxe.inf INF MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Dxe.inf INF MdeModulePkg/Universal/Network/Tcp4Dxe/Tcp4Dxe.inf diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15_MPCore.fdf b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15_MPCore.fdf index 3d54f9a..515d8f4 100644 --- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15_MPCore.fdf +++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15_MPCore.fdf @@ -137,11
Re: [edk2] [PATCH] BaseTools/GCC: allow unused but set variables
For ARM architectures, I only disable this flag for RELEASE build:
$ grep -r unused-but-set-variable Conf/tools_def.txt
DEFINE GCC46_IA32_CC_FLAGS = DEF(GCC45_IA32_CC_FLAGS) -Wno-address
-Wno-unused-but-set-variable
DEFINE GCC46_X64_CC_FLAGS= DEF(GCC45_X64_CC_FLAGS) -Wno-address
-Wno-unused-but-set-variable
RELEASE_GCC46_ARM_CC_FLAGS = DEF(GCC46_ARM_CC_FLAGS)
-Wno-unused-but-set-variable
RELEASE_GCC47_ARM_CC_FLAGS = DEF(GCC47_ARM_CC_FLAGS)
-Wno-unused-but-set-variable
RELEASE_GCC47_AARCH64_CC_FLAGS = DEF(GCC47_AARCH64_CC_FLAGS)
-Wno-unused-but-set-variable
RELEASE_GCC48_ARM_CC_FLAGS = DEF(GCC48_ARM_CC_FLAGS)
-Wno-unused-but-set-variable
RELEASE_GCC48_AARCH64_CC_FLAGS = DEF(GCC48_AARCH64_CC_FLAGS)
-Wno-unused-but-set-variable
RELEASE_GCC49_ARM_CC_FLAGS = DEF(GCC49_ARM_CC_FLAGS)
-Wno-unused-but-set-variable
RELEASE_GCC49_AARCH64_CC_FLAGS = DEF(GCC49_AARCH64_CC_FLAGS)
-Wno-unused-but-set-variable
-Original Message-
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
Sent: 08 July 2015 14:24
To: edk2-devel@lists.sourceforge.net; ler...@redhat.com; Olivier Martin;
leif.lindh...@linaro.org; jordan.l.jus...@intel.com
Cc: roy.fr...@linaro.org; Ard Biesheuvel
Subject: [PATCH] BaseTools/GCC: allow unused but set variables
This fixes a recurring problem where patches that have only been tested on MS
toolchains break the build on GCC because they use variables that are only
written but never read.
However, there is a valid pattern where this may happen as well.
For instance,
Status = SomeFunc (OutVar);
ASSERT_EFI_ERROR (Status);
if (Outvar == ... ) { ... }
// Status never referenced again
may never access Status again at all in RELEASE builds, since the
ASSERT_EFI_ERROR () macro evaluates to nothing in that case.
So let's allow this pattern, by passing the appropriate GCC command line option.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
BaseTools/Conf/tools_def.template | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/BaseTools/Conf/tools_def.template
b/BaseTools/Conf/tools_def.template
index 7edd7590956b..15d8db04232f 100644
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -3813,7 +3813,7 @@ NOOPT_DDK3790xASL_IPF_DLINK_FLAGS= /NOLOGO
/NODEFAULTLIB /LTCG /DLL /OPT:REF
DEBUG_*_*_OBJCOPY_ADDDEBUGFLAG =
--add-gnu-debuglink=$(DEBUG_DIR)/$(MODULE_NAME).debug
RELEASE_*_*_OBJCOPY_ADDDEBUGFLAG =
-DEFINE GCC_ALL_CC_FLAGS= -g -Os -fshort-wchar -fno-strict-aliasing
-Wall -Werror -Wno-array-bounds -c -include AutoGen.h
+DEFINE GCC_ALL_CC_FLAGS= -g -Os -fshort-wchar -fno-strict-aliasing
-Wall -Werror -Wno-array-bounds -c -include AutoGen.h
-Wno-error=unused-but-set-variable
DEFINE GCC_IA32_CC_FLAGS = DEF(GCC_ALL_CC_FLAGS) -m32 -malign-double
-freorder-blocks -freorder-blocks-and-partition -O2 -mno-stack-arg-probe
DEFINE GCC_X64_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mno-red-zone
-Wno-address -mno-stack-arg-probe
DEFINE GCC_IPF_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS)
-minline-int-divide-min-latency
--
1.9.1
-- 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.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered
in England Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England Wales, Company No: 2548782
--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
[edk2] [PATCH] BaseTools/GenFw: Added AArch64 page-relative relocations
When EDK2 is built for the small memory model with AArch64 LLVM,
some page-relative relocations (R_AARCH64_ADR_PREL_PG_HI21 and its
R_AARCH64_LDST(16|32|64|128)_ABS_LO12_NC companions) that were not
supported before by EDK2 BaseTools are now needed.
This change adds support for these relocations in BaseTools.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Harry Liebel harry.lie...@arm.com
Reviewed-by: Olivier Martin olivier.mar...@arm.com
---
BaseTools/Source/C/Common/BasePeCoff.c | 14 +++
BaseTools/Source/C/Common/PeCoffLib.h | 13 +++
BaseTools/Source/C/Common/PeCoffLoaderEx.c | 58 +++
BaseTools/Source/C/GenFw/Elf64Convert.c| 159 +++--
BaseTools/Source/C/GenFw/elf_common.h | 4 +
5 files changed, 215 insertions(+), 33 deletions(-)
diff --git a/BaseTools/Source/C/Common/BasePeCoff.c
b/BaseTools/Source/C/Common/BasePeCoff.c
index afb45df..e1401f2 100644
--- a/BaseTools/Source/C/Common/BasePeCoff.c
+++ b/BaseTools/Source/C/Common/BasePeCoff.c
@@ -715,6 +715,20 @@ Returns:
RelocBaseEnd = (EFI_IMAGE_BASE_RELOCATION *) ((UINTN) RelocBase + (UINTN)
RelocDir-Size - 1);
}
+ // In order for page relative code relocations to work on AArch64 we need to
+ // ensure that any address adjustment to images are 4k page aligned. The page
+ // relative relocations are processed at build time as we do not have enough
+ // information at runtime to recalculate them.
+ // The PE/COFF Base relocation types do not have a matching type to describe
+ // page relative relocations so we do not know if they may be present in the
+ // images. We must assume they are present and ensure the image is properly
+ // aligned to keep these relocations valid.
+ if (ImageContext-Machine == EFI_IMAGE_MACHINE_AARCH64) {
+if ((Adjust 0xfff) != 0x0) {
+ return RETURN_LOAD_ERROR;
+}
+ }
+
//
// Run the relocation information and apply the fixups
//
diff --git a/BaseTools/Source/C/Common/PeCoffLib.h
b/BaseTools/Source/C/Common/PeCoffLib.h
index b56dd75..2f8feb7 100644
--- a/BaseTools/Source/C/Common/PeCoffLib.h
+++ b/BaseTools/Source/C/Common/PeCoffLib.h
@@ -205,6 +205,19 @@ ThumbMovwMovtImmediatePatch (
IN UINT32 Address
);
+/**
+ Update AArch64 instruction immediate address data.
+
+ @param Instruction Pointer to AArch64 instruction to update
+ @param Address New addres to patch into the instruction
+
+**/
+RETURN_STATUS
+EFIAPI
+Aarch64ImmediatePatch (
+ IN OUT UINT32 *Instruction,
+ IN INT32 Val
+ );
#endif
diff --git a/BaseTools/Source/C/Common/PeCoffLoaderEx.c
b/BaseTools/Source/C/Common/PeCoffLoaderEx.c
index b7b7227..3864391 100644
--- a/BaseTools/Source/C/Common/PeCoffLoaderEx.c
+++ b/BaseTools/Source/C/Common/PeCoffLoaderEx.c
@@ -466,6 +466,64 @@ PeCoffLoaderRelocateArmImage (
return RETURN_SUCCESS;
}
+
+/**
+ Update AArch64 instruction immediate address data.
+
+ @param Instruction Pointer to AArch64 instruction to update
+ @param Value New value to patch into the instruction. Signed value
+to preserve sign extension where needed. Some
+instructions can have positive and negative values.
+
+**/
+// The values below are used to match instructions based on the architecture
encoding
+// Don't support shifted imm12 for ADD instructions. Set as 0 in MASK and INST
+#define AARCH64_ADD_MASK 0x1FC0
+#define AARCH64_ADD_INST 0x1100
+#define AARCH64_ADD_IMM0x003FFC00
+#define IS_AARCH64_ADD(x) ((x AARCH64_ADD_MASK) == AARCH64_ADD_INST)
+#define AARCH64_ADRP_MASK 0x9f00
+#define AARCH64_ADRP_INST 0x9000
+#define AARCH64_ADRP_IMM 0x60E0
+#define IS_AARCH64_ADRP(x) ((x AARCH64_ADRP_MASK) == AARCH64_ADRP_INST)
+#define AARCH64_LDST_MASK 0x3b00
+#define AARCH64_LDST_INST 0x3900
+#define AARCH64_LDST_IMM 0x003FFC00
+#define IS_AARCH64_LDST(x) ((x AARCH64_LDST_MASK) == AARCH64_LDST_INST)
+
+RETURN_STATUS
+EFIAPI
+Aarch64ImmediatePatch (
+ IN OUT UINT32 *Instruction,
+ IN INT32 Value
+ )
+{
+ UINT32Patch;
+ RETURN_STATUS Status;
+
+ Status = RETURN_UNSUPPORTED;
+
+ // Disassemble and update the instruction
+ if (IS_AARCH64_ADD (*Instruction)) {
+Patch = Value 10;
+*Instruction = (*Instruction ~AARCH64_ADD_IMM) | Patch;
+Status = RETURN_SUCCESS;
+ } else if (IS_AARCH64_ADRP (*Instruction)) {
+Patch = ((Value 0x3) 29) | (((Value 0x1C) 2) 5);
+*Instruction = (*Instruction ~AARCH64_ADRP_IMM) | Patch;
+Status = RETURN_SUCCESS;
+ } else if (IS_AARCH64_LDST (*Instruction)) {
+// Relocation types LDST8,16,32,64,128 specify different bitsizes.
+// The Calling function knows the relocation type and has already masked
and
+// scaled the address as needed.
+Patch = Value 10;
+*Instruction = (*Instruction ~AARCH64_LDST_IMM) | Patch;
+Status
Re: [edk2] 'ArmPlatformPkg/ArmVExpressDxe: Change FDT default file names' breaks the build
That's a fair comment. I will revert the patch. Sorry for the inconvenience.
-Original Message-
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
Sent: 07 July 2015 22:08
To: edk2-devel@lists.sourceforge.net; Olivier Martin
Subject: 'ArmPlatformPkg/ArmVExpressDxe: Change FDT default file names' breaks
the build
Hi Olivier,
Your patch 'ArmPlatformPkg/ArmVExpressDxe: Change FDT default file names' has
broken the FVP build in a non-trivial way:
This part of the FDF:
!ifdef $(DTB_DIR)
#
# Embed flattened device tree (FDT) images for all known
# variants of this platform
#
FILE RAW = PCD (gArmVExpressTokenSpaceGuid.PcdFdtFvpBaseAEMv8x4GicV2) {
$(DTB_DIR)/fvp-base-gicv2-psci.dtb
}
FILE RAW = PCD (gArmVExpressTokenSpaceGuid.PcdFdtFvpBaseAEMv8x4GicV2Legacy) {
$(DTB_DIR)/fvp-base-gicv2legacy-psci.dtb
}
FILE RAW = PCD (gArmVExpressTokenSpaceGuid.PcdFdtFvpBaseAEMv8x4GicV3) {
$(DTB_DIR)/fvp-base-gicv3-psci.dtb
}
FILE RAW = PCD (gArmVExpressTokenSpaceGuid.PcdFdtFvpFoundationGicV2) {
$(DTB_DIR)/fvp-foundation-gicv2-psci.dtb
}
FILE RAW = PCD (gArmVExpressTokenSpaceGuid.PcdFdtFvpFoundationGicV2Legacy) {
$(DTB_DIR)/fvp-foundation-gicv2legacy-psci.dtb
}
FILE RAW = PCD (gArmVExpressTokenSpaceGuid.PcdFdtFvpFoundationGicV3) {
$(DTB_DIR)/fvp-foundation-gicv3-psci.dtb
}
!endif
now generates build failures when DTB_DIR is set, and there is no easy fix
since the PCDs were removed and the underlying functionality as well.
Since the patch has not been sent to the list for review, may I propose that
you revert it? Then we can discuss an approach for the underlying issue rather
than paper over the problems it has created.
Thanks,
Ard.
-- 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.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered
in England Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England Wales, Company No: 2548782
--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] [PATCH] MdeModulePkg/FvSimpleFileSystemDxe: Support file opening with no '.efi'
You are saying If user enter Shell or Shell.efi, it should run for both
cases.
But it is actually the case I am trying to solve with this patch :-)
FvSimpleFileSystemOpen() was only checking if there was strict equality between
the given name and the name exposed by FvSimpleFileSystemDxe (ie: the name with
.EFI).
It means if you try to open the file Shell (the name you gave in the UI
section) it would not work.
-Original Message-
From: Tian, Feng [mailto:feng.t...@intel.com]
Sent: 08 July 2015 06:38
To: Olivier Martin
Cc: edk2-devel@lists.sourceforge.net; Tian, Feng
Subject: RE: [PATCH] MdeModulePkg/FvSimpleFileSystemDxe: Support file opening
with no '.efi'
Hi, Martin
I am a little confused by your description on the issue.
EDKII build system puts $BASE_NAME string to UI section and generate
$BASE_NAME.efi file name at build directory. The FvSimpleFileSystem driver adds
.efi postfix to string gotten from each UI section for all executable file
types. So my understanding is these two strings are identical and should not
bring confusion.
And why it's not possible to open an EFI application without the .efi
extension? If user enter Shell or Shell.efi, it should run for both cases.
Thanks
Feng
-Original Message-
From: Olivier Martin [mailto:olivier.mar...@arm.com]
Sent: Tuesday, July 07, 2015 00:17
To: Tian, Feng
Cc: edk2-devel@lists.sourceforge.net; Olivier Martin; Olivier Martin
Subject: [PATCH] MdeModulePkg/FvSimpleFileSystemDxe: Support file opening with
no '.efi'
FvSimpleFileSystem adds '.efi' to the EFI application and drivers filenames
even through this extension is not present in the real filename of the EFI
module.
In the current behaviour, it would not be possible to open an EFI application
using FvSimpleFileSystem if the extension has been omitted in the given
filename.
It can be create some confusion if someone wants to try to open a file with the
real application name (eg: 'Shell').
This patch adds support to try again to look for the file with the extension if
it had failed to find it without the extension.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Olivier Martin olivier.mar...@arm.com
---
.../FvSimpleFileSystemDxe/FvSimpleFileSystem.c | 62 +-
1 file changed, 50 insertions(+), 12 deletions(-)
diff --git a/MdeModulePkg/Universal/FvSimpleFileSystemDxe/FvSimpleFileSystem.c
b/MdeModulePkg/Universal/FvSimpleFileSystemDxe/FvSimpleFileSystem.c
index b0e7dc3..c6137ac 100644
--- a/MdeModulePkg/Universal/FvSimpleFileSystemDxe/FvSimpleFileSystem.c
+++ b/MdeModulePkg/Universal/FvSimpleFileSystemDxe/FvSimpleFileSystem.c
@@ -483,6 +483,10 @@ FvSimpleFileSystemOpen (
FV_FILESYSTEM_FILE *NewFile;
FV_FILESYSTEM_FILE_INFO *FvFileInfo;
LIST_ENTRY *FvFileInfoLink;
+ EFI_STATUS Status;
+ UINTN FileNameLength;
+ UINTN NewFileNameLength;
+ CHAR16 *FileNameWithExtension;
//
// Check for a valid mode
@@ -531,26 +535,60 @@ FvSimpleFileSystemOpen (
//
// Do a linear search for a file in the FV with a matching filename
//
+ Status = EFI_NOT_FOUND;
+ FvFileInfo = NULL;
for (FvFileInfoLink = GetFirstNode (Instance-FileInfoHead);
!IsNull (Instance-FileInfoHead, FvFileInfoLink);
FvFileInfoLink = GetNextNode (Instance-FileInfoHead, FvFileInfoLink))
{
FvFileInfo = FVFS_FILE_INFO_FROM_LINK (FvFileInfoLink);
if (mUnicodeCollation-StriColl (mUnicodeCollation,
FvFileInfo-FileInfo.FileName[0], FileName) == 0) {
- NewFile = AllocateZeroPool (sizeof (FV_FILESYSTEM_FILE));
- if (NewFile == NULL) {
-return EFI_OUT_OF_RESOURCES;
- }
+ Status = EFI_SUCCESS;
+ break;
+}
+ }
- NewFile-Signature = FVFS_FILE_SIGNATURE;
- NewFile-Instance = Instance;
- NewFile-FvFileInfo = FvFileInfo;
- CopyMem (NewFile-FileProtocol, mFileSystemTemplate, sizeof
(mFileSystemTemplate));
- InitializeListHead (NewFile-Link);
- InsertHeadList (Instance-FileHead, NewFile-Link);
+ // If the file has not been found check if the filename exists with
+ an extension // in case there was no extension present.
+ // FvFileSystem adds a 'virtual' extension '.EFI' to EFI applications
+ and drivers // present in the Firmware Volume if (Status ==
+ EFI_NOT_FOUND) {
+FileNameLength = StrLen (FileName);
+
+// Does the filename already contain the '.EFI' extension?
+if (mUnicodeCollation-StriColl (mUnicodeCollation, FileName +
FileNameLength - 4, L.efi) != 0) {
+ // No, there was no extension. So add one and search again for the file
+ // NewFileNameLength = FileNameLength + 1 + 4 = (Number of non-null
character) + (file extension) + (a null character)
+ NewFileNameLength = FileNameLength + 1 + 4;
+ FileNameWithExtension = AllocateCopyPool (NewFileNameLength * 2,
FileName);
+ StrCatS
[edk2] [PATCH] ArmVirtPkg/ArmVirt.dsc.inc: Fixed BuildOptions
The linker script is specific to GCC toolchain. So, this script will not work with other linkers (eg: ARM Toolchain Linker, Microsoft Linker, etc). Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Olivier Martin olivier.mar...@arm.com --- ArmVirtPkg/ArmVirt.dsc.inc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ArmVirtPkg/ArmVirt.dsc.inc b/ArmVirtPkg/ArmVirt.dsc.inc index 8893dfa..16d7ea6 100644 --- a/ArmVirtPkg/ArmVirt.dsc.inc +++ b/ArmVirtPkg/ArmVirt.dsc.inc @@ -17,7 +17,7 @@ DEFINE DEBUG_PRINT_ERROR_LEVEL = 0x804F [BuildOptions.AARCH64.EDKII.DXE_RUNTIME_DRIVER] - *_*_AARCH64_DLINK_FLAGS = --script=$(EDK_TOOLS_PATH)/Scripts/gcc-aarch64-64K-align-ld-script + GCC:*_*_AARCH64_DLINK_FLAGS = --script=$(EDK_TOOLS_PATH)/Scripts/gcc-aarch64-64K-align-ld-script [LibraryClasses.common] !if $(TARGET) == RELEASE -- 2.1.1 -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] [Patch 4/7] ArmPlatformPkg: Remove Ip4ConfigDxe module from ArmPlatformPkg.
Reviewed-By: Olivier Martin olivier.mar...@arm.com -Original Message- From: jiaxinwu [mailto:jiaxin...@intel.com] Sent: 07 July 2015 02:28 To: edk2-devel@lists.sourceforge.net Subject: [edk2] [Patch 4/7] ArmPlatformPkg: Remove Ip4ConfigDxe module from ArmPlatformPkg. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: jiaxinwu jiaxin...@intel.com --- ArmPlatformPkg/ArmJunoPkg/ArmJuno.fdf | 1 - ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA15-A7.fdf| 1 - ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA9x4.fdf | 1 - ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15.fdf| 1 - ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15_MPCore.fdf | 1 - ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc | 1 - 6 files changed, 6 deletions(-) diff --git a/ArmPlatformPkg/ArmJunoPkg/ArmJuno.fdf b/ArmPlatformPkg/ArmJunoPkg/ArmJuno.fdf index 5c15fda..9a0de9a 100644 --- a/ArmPlatformPkg/ArmJunoPkg/ArmJuno.fdf +++ b/ArmPlatformPkg/ArmJunoPkg/ArmJuno.fdf @@ -173,11 +173,10 @@ READ_LOCK_STATUS = TRUE # Networking stack # INF MdeModulePkg/Universal/Network/DpcDxe/DpcDxe.inf INF MdeModulePkg/Universal/Network/ArpDxe/ArpDxe.inf INF MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Dxe.inf - INF MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4ConfigDxe.inf INF MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Dxe.inf INF MdeModulePkg/Universal/Network/MnpDxe/MnpDxe.inf INF MdeModulePkg/Universal/Network/VlanConfigDxe/VlanConfigDxe.inf INF MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Dxe.inf INF MdeModulePkg/Universal/Network/Tcp4Dxe/Tcp4Dxe.inf diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA15-A7.fdf b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA15-A7.fdf index 893fb86..1e91734 100644 --- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA15-A7.fdf +++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA15-A7.fdf @@ -147,11 +147,10 @@ READ_LOCK_STATUS = TRUE # Networking stack # INF MdeModulePkg/Universal/Network/DpcDxe/DpcDxe.inf INF MdeModulePkg/Universal/Network/ArpDxe/ArpDxe.inf INF MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Dxe.inf - INF MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4ConfigDxe.inf INF MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Dxe.inf INF MdeModulePkg/Universal/Network/MnpDxe/MnpDxe.inf INF MdeModulePkg/Universal/Network/VlanConfigDxe/VlanConfigDxe.inf INF MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Dxe.inf INF MdeModulePkg/Universal/Network/Tcp4Dxe/Tcp4Dxe.inf diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA9x4.fdf b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA9x4.fdf index 6ee0b06..b80db3c 100644 --- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA9x4.fdf +++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA9x4.fdf @@ -216,11 +216,10 @@ READ_LOCK_STATUS = TRUE # Networking stack # INF MdeModulePkg/Universal/Network/DpcDxe/DpcDxe.inf INF MdeModulePkg/Universal/Network/ArpDxe/ArpDxe.inf INF MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Dxe.inf - INF MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4ConfigDxe.inf INF MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Dxe.inf INF MdeModulePkg/Universal/Network/MnpDxe/MnpDxe.inf INF MdeModulePkg/Universal/Network/VlanConfigDxe/VlanConfigDxe.inf INF MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Dxe.inf INF MdeModulePkg/Universal/Network/Tcp4Dxe/Tcp4Dxe.inf diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15.fdf b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15.fdf index 8994196..4301e23 100644 --- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15.fdf +++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15.fdf @@ -137,11 +137,10 @@ READ_LOCK_STATUS = TRUE # Networking stack # INF MdeModulePkg/Universal/Network/DpcDxe/DpcDxe.inf INF MdeModulePkg/Universal/Network/ArpDxe/ArpDxe.inf INF MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Dxe.inf - INF MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4ConfigDxe.inf INF MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Dxe.inf INF MdeModulePkg/Universal/Network/MnpDxe/MnpDxe.inf INF MdeModulePkg/Universal/Network/VlanConfigDxe/VlanConfigDxe.inf INF MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Dxe.inf INF MdeModulePkg/Universal/Network/Tcp4Dxe/Tcp4Dxe.inf diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15_MPCore.fdf b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15_MPCore.fdf index 3d54f9a..515d8f4 100644 --- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15_MPCore.fdf +++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15_MPCore.fdf @@ -137,11 +137,10 @@ READ_LOCK_STATUS = TRUE # Networking stack # INF MdeModulePkg/Universal/Network/DpcDxe/DpcDxe.inf INF MdeModulePkg/Universal/Network/ArpDxe/ArpDxe.inf INF MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Dxe.inf - INF MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4ConfigDxe.inf INF MdeModulePkg/Universal/Network
Re: [edk2] [Patch 5/7] ArmVirtPkg: Remove Ip4ConfigDxe module from ArmVirtPkg.
Reviewed-By: Olivier Martin olivier.mar...@arm.com -Original Message- From: jiaxinwu [mailto:jiaxin...@intel.com] Sent: 07 July 2015 02:28 To: edk2-devel@lists.sourceforge.net Subject: [edk2] [Patch 5/7] ArmVirtPkg: Remove Ip4ConfigDxe module from ArmVirtPkg. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: jiaxinwu jiaxin...@intel.com --- ArmVirtPkg/ArmVirt.dsc.inc | 1 - ArmVirtPkg/ArmVirtQemu.fdf | 1 - 2 files changed, 2 deletions(-) diff --git a/ArmVirtPkg/ArmVirt.dsc.inc b/ArmVirtPkg/ArmVirt.dsc.inc index 7ec0de4..6f47d8e 100644 --- a/ArmVirtPkg/ArmVirt.dsc.inc +++ b/ArmVirtPkg/ArmVirt.dsc.inc @@ -364,11 +364,10 @@ # Networking stack # MdeModulePkg/Universal/Network/DpcDxe/DpcDxe.inf MdeModulePkg/Universal/Network/ArpDxe/ArpDxe.inf MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Dxe.inf - MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4ConfigDxe.inf MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Dxe.inf MdeModulePkg/Universal/Network/MnpDxe/MnpDxe.inf MdeModulePkg/Universal/Network/VlanConfigDxe/VlanConfigDxe.inf MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Dxe.inf MdeModulePkg/Universal/Network/Tcp4Dxe/Tcp4Dxe.inf diff --git a/ArmVirtPkg/ArmVirtQemu.fdf b/ArmVirtPkg/ArmVirtQemu.fdf index e822fdf..4448018 100644 --- a/ArmVirtPkg/ArmVirtQemu.fdf +++ b/ArmVirtPkg/ArmVirtQemu.fdf @@ -181,11 +181,10 @@ READ_LOCK_STATUS = TRUE # Networking stack # INF MdeModulePkg/Universal/Network/DpcDxe/DpcDxe.inf INF MdeModulePkg/Universal/Network/ArpDxe/ArpDxe.inf INF MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Dxe.inf - INF MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4ConfigDxe.inf INF MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Dxe.inf INF MdeModulePkg/Universal/Network/MnpDxe/MnpDxe.inf INF MdeModulePkg/Universal/Network/VlanConfigDxe/VlanConfigDxe.inf INF MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Dxe.inf INF MdeModulePkg/Universal/Network/Tcp4Dxe/Tcp4Dxe.inf -- 1.9.5.msysgit.1 -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel -- 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. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2548782 -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] [PATCH 1/2] BaseTools: AArch64: use explicit linker scripts
It happens for me from times to times. I use the command: ` svn propedit -r N --revprop` to edit the commit message of patch already pushed into SVN. -Original Message- From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] Sent: 06 July 2015 19:05 To: Cohen, Eugene Cc: edk2-devel@lists.sourceforge.net; ler...@redhat.com; Olivier Martin; af...@apple.com; jiewen@intel.com; yingke.d@intel.com; matt.flem...@intel.com Subject: Re: [PATCH 1/2] BaseTools: AArch64: use explicit linker scripts On 29 June 2015 at 23:22, Cohen, Eugene eug...@hp.com wrote: Reviewed-by: Eugene Cohen eug...@hp.com Hello Eugene, These patches have now been merged. Unfortunately, I failed to add your R-b: this was unintentional, but there is little I can about it now. Thanks again for the review, Regards, Ard. -Original Message- From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] Sent: Monday, June 29, 2015 12:37 PM To: edk2-devel@lists.sourceforge.net; ler...@redhat.com; olivier.mar...@arm.com; af...@apple.com; Cohen, Eugene; jiewen@intel.com Cc: yingke.d@intel.com; matt.flem...@intel.com; Ard Biesheuvel Subject: [PATCH 1/2] BaseTools: AArch64: use explicit linker scripts Instead of relying on the builtin linker script of GNU ld, which may vary based on binutils version (which is not tightly coupled to the GCC version) and linker command line options, introduce a linker script for AArch64 to be used by all GCC/binutils versions. The script is laid out such that two ELF sections .text and .data are created that map onto the PE/COFF ones with the same names. By aligning .data to the minimum alignment of .text, and by not adding any additional padding -which is what LD's builtin linker script does- the relative offset between .text and .data is retained after the PE/COFF conversion. This should prevent problems with debuggers and other tooling that are ELF based. Also provided is an overlay linker script that increases the alignment of .text and .data to 64 KB. This is intended for DXE_RUNTIME_DRIVER modules, to make them compatible with the newly introduced Properties Table feature. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org --- BaseTools/Conf/tools_def.template | 23 +++- BaseTools/Scripts/gcc-aarch64-64K-align-ld-script | 4 ++ BaseTools/Scripts/gcc-aarch64-ld-script | 39 3 files changed, 56 insertions(+), 10 deletions(-) diff --git a/BaseTools/Conf/tools_def.template b/BaseTools/Conf/tools_def.template index 88ec2e138dbc..7edd7590956b 100644 --- a/BaseTools/Conf/tools_def.template +++ b/BaseTools/Conf/tools_def.template @@ -3821,9 +3821,12 @@ DEFINE GCC_ARM_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mword-relocations -m DEFINE GCC_AARCH64_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mcmodel=large -mlittle-endian -fno-short-enums -save-temps -fverbose-asm -fsigned-char -ffunction-sections -fdata-sections -fomit-frame-pointer -fno-builtin -Wno-address DEFINE GCC_DLINK_FLAGS_COMMON = -nostdlib --pie DEFINE GCC_IA32_X64_DLINK_COMMON = DEF(GCC_DLINK_FLAGS_COMMON) --gc-sections -DEFINE GCC_ARM_AARCH64_DLINK_COMMON= -Ttext=0x0 --emit-relocs -nostdlib --gc-sections -u $(IMAGE_ENTRY_POINT) -e $(IMAGE_ENTRY_POINT) -Map $(DEST_DIR_DEBUG)/$(BASE_NAME).map +DEFINE GCC_ARM_AARCH64_DLINK_COMMON= --emit-relocs -nostdlib --gc-sections -u $(IMAGE_ENTRY_POINT) -e $(IMAGE_ENTRY_POINT) -Map $(DEST_DIR_DEBUG)/$(BASE_NAME).map +DEFINE GCC_ARM_DLINK_FLAGS = DEF(GCC_ARM_AARCH64_DLINK_COMMON) -Ttext=0x0 +DEFINE GCC_AARCH64_DLINK_FLAGS = DEF(GCC_ARM_AARCH64_DLINK_COMMON) --script=$(EDK_TOOLS_PATH)/Scripts/gcc-aarch64-ld-script DEFINE GCC_IA32_X64_ASLDLINK_FLAGS = DEF(GCC_IA32_X64_DLINK_COMMON) --entry _ReferenceAcpiTable -u $(IMAGE_ENTRY_POINT) -DEFINE GCC_ARM_AARCH64_ASLDLINK_FLAGS = DEF(GCC_ARM_AARCH64_DLINK_COMMON) --entry ReferenceAcpiTable -u $(IMAGE_ENTRY_POINT) +DEFINE GCC_ARM_ASLDLINK_FLAGS = DEF(GCC_ARM_DLINK_FLAGS) --entry ReferenceAcpiTable -u $(IMAGE_ENTRY_POINT) +DEFINE GCC_AARCH64_ASLDLINK_FLAGS = DEF(GCC_AARCH64_DLINK_FLAGS) +--entry ReferenceAcpiTable -u $(IMAGE_ENTRY_POINT) DEFINE GCC_IA32_X64_DLINK_FLAGS= DEF(GCC_IA32_X64_DLINK_COMMON) --entry _$(IMAGE_ENTRY_POINT) --file-alignment 0x20 --section-alignment 0x20 -Map $(DEST_DIR_DEBUG)/$(BASE_NAME).map DEFINE GCC_IPF_DLINK_FLAGS = -nostdlib -O2 --gc-sections --dll -static --entry $(IMAGE_ENTRY_POINT) --undefined $(IMAGE_ENTRY_POINT) -Map $(DEST_DIR_DEBUG)/$(BASE_NAME).map DEFINE GCC_IPF_OBJCOPY_FLAGS = -I elf64-ia64-little -O efi-bsdrv-ia64 @@ -3866,8 +3869,8 @@ DEFINE GCC46_X64_DLINK_FLAGS = DEF(GCC45_X64_DLINK_FLAGS) DEFINE GCC46_ASM_FLAGS = DEF(GCC45_ASM_FLAGS) DEFINE GCC46_ARM_ASM_FLAGS = $(ARCHASM_FLAGS) $(PLATFORM_FLAGS) DEF(GCC_ASM_FLAGS
Re: [edk2] [PATCH] ArmVirtPkg: adapt ArmVirtXen build to system memory end global variable
Sorry for that, I have got ArmVirtQemu.dsc in my CI but I have not got yet ArmVirtXen.dsc :-/ -Original Message- From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] Sent: 06 July 2015 21:25 To: edk2-devel@lists.sourceforge.net; Olivier Martin; ler...@redhat.com Cc: Ard Biesheuvel Subject: [PATCH] ArmVirtPkg: adapt ArmVirtXen build to system memory end global variable This fixes the ArmVirtXen build that was broken by r17835, which adds a global variable mSystemMemoryEnd which is shared between a module and a library it depends on. Add the same global variable to the relocatable PrePi used by ArmVirtXen. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org --- This fixes the build for ArmVirtXen, although I would have preferred a different approach for r17835 in the first place, i.e., a clean interface rather than a global which is declared as an extern in random places. -- Ard. ArmVirtPkg/PrePi/AArch64/ModuleEntryPoint.S | 4 ArmVirtPkg/PrePi/PrePi.h| 2 ++ 2 files changed, 6 insertions(+) diff --git a/ArmVirtPkg/PrePi/AArch64/ModuleEntryPoint.S b/ArmVirtPkg/PrePi/AArch64/ModuleEntryPoint.S index 568d0086d662..0adaf44c9ed9 100644 --- a/ArmVirtPkg/PrePi/AArch64/ModuleEntryPoint.S +++ b/ArmVirtPkg/PrePi/AArch64/ModuleEntryPoint.S @@ -25,8 +25,10 @@ GCC_ASM_IMPORT(ArmReadMpidr) GCC_ASM_IMPORT(ArmPlatformPeiBootAction) GCC_ASM_IMPORT(ArmPlatformStackSet) GCC_ASM_EXPORT(_ModuleEntryPoint) +GCC_ASM_EXPORT(mSystemMemoryEnd) StartupAddr:.8byte ASM_PFX(CEntryPoint) +mSystemMemoryEnd: .8byte 0 ASM_PFX(_ModuleEntryPoint): // @@ -80,6 +82,8 @@ _SetupStackPosition: ldr x2, PcdGet64 (PcdSystemMemorySize) sub x2, x2, #1 add x1, x1, x2 // x1 = SystemMemoryTop = PcdSystemMemoryBase + PcdSystemMemorySize + adr x2, mSystemMemoryEnd + str x1, [x2] // Calculate Top of the Firmware Device ldr x2, PcdGet64 (PcdFdBaseAddress) diff --git a/ArmVirtPkg/PrePi/PrePi.h b/ArmVirtPkg/PrePi/PrePi.h index 517429fab9a4..15b91e49c9bd 100644 --- a/ArmVirtPkg/PrePi/PrePi.h +++ b/ArmVirtPkg/PrePi/PrePi.h @@ -29,6 +29,8 @@ #define SerialPrint(txt) SerialPortWrite (txt, AsciiStrLen(txt)+1); +extern UINT64 mSystemMemoryEnd; + RETURN_STATUS EFIAPI TimerConstructor ( -- 1.9.1 -- 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. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2548782 -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
[edk2] [PATCH] MdePkg/AArch64: use GCC_ASM_EXPORT to export functions
This ensures the .type directive is used to mark them as function symbols Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Olivier Martin olivier.mar...@arm.com --- MdePkg/Library/BaseCpuLib/AArch64/CpuFlushTlb.S | 2 +- MdePkg/Library/BaseCpuLib/AArch64/CpuSleep.S| 2 +- MdePkg/Library/BaseLib/AArch64/CpuBreakpoint.S | 2 +- MdePkg/Library/BaseLib/AArch64/DisableInterrupts.S | 2 +- MdePkg/Library/BaseLib/AArch64/EnableInterrupts.S | 2 +- MdePkg/Library/BaseLib/AArch64/GetInterruptsState.S | 2 +- MdePkg/Library/BaseLib/AArch64/SetJumpLongJump.S| 4 ++-- MdePkg/Library/BaseLib/AArch64/SwitchStack.S| 4 ++-- 8 files changed, 10 insertions(+), 10 deletions(-) diff --git a/MdePkg/Library/BaseCpuLib/AArch64/CpuFlushTlb.S b/MdePkg/Library/BaseCpuLib/AArch64/CpuFlushTlb.S index 8e12bdd..ea01a5d 100644 --- a/MdePkg/Library/BaseCpuLib/AArch64/CpuFlushTlb.S +++ b/MdePkg/Library/BaseCpuLib/AArch64/CpuFlushTlb.S @@ -17,7 +17,7 @@ .text .p2align 2 -ASM_GLOBAL ASM_PFX(CpuFlushTlb) +GCC_ASM_EXPORT(CpuFlushTlb) #/** # Flushes all the Translation Lookaside Buffers(TLB) entries in a CPU. diff --git a/MdePkg/Library/BaseCpuLib/AArch64/CpuSleep.S b/MdePkg/Library/BaseCpuLib/AArch64/CpuSleep.S index 86c3e63..316ac65 100644 --- a/MdePkg/Library/BaseCpuLib/AArch64/CpuSleep.S +++ b/MdePkg/Library/BaseCpuLib/AArch64/CpuSleep.S @@ -17,7 +17,7 @@ .text .align 3 -ASM_GLOBAL ASM_PFX(CpuSleep) +GCC_ASM_EXPORT(CpuSleep) #/** # Places the CPU in a sleep state until an interrupt is received. diff --git a/MdePkg/Library/BaseLib/AArch64/CpuBreakpoint.S b/MdePkg/Library/BaseLib/AArch64/CpuBreakpoint.S index df89abe..29b6669 100644 --- a/MdePkg/Library/BaseLib/AArch64/CpuBreakpoint.S +++ b/MdePkg/Library/BaseLib/AArch64/CpuBreakpoint.S @@ -17,7 +17,7 @@ .text .p2align 2 -ASM_GLOBAL ASM_PFX(CpuBreakpoint) +GCC_ASM_EXPORT(CpuBreakpoint) #/** # Generates a breakpoint on the CPU. diff --git a/MdePkg/Library/BaseLib/AArch64/DisableInterrupts.S b/MdePkg/Library/BaseLib/AArch64/DisableInterrupts.S index b80a7b4..943cc44 100644 --- a/MdePkg/Library/BaseLib/AArch64/DisableInterrupts.S +++ b/MdePkg/Library/BaseLib/AArch64/DisableInterrupts.S @@ -17,7 +17,7 @@ .text .p2align 2 -ASM_GLOBAL ASM_PFX(DisableInterrupts) +GCC_ASM_EXPORT(DisableInterrupts) #/** # Disables CPU interrupts. diff --git a/MdePkg/Library/BaseLib/AArch64/EnableInterrupts.S b/MdePkg/Library/BaseLib/AArch64/EnableInterrupts.S index 289739c..a423102 100644 --- a/MdePkg/Library/BaseLib/AArch64/EnableInterrupts.S +++ b/MdePkg/Library/BaseLib/AArch64/EnableInterrupts.S @@ -17,7 +17,7 @@ .text .p2align 2 -ASM_GLOBAL ASM_PFX(EnableInterrupts) +GCC_ASM_EXPORT(EnableInterrupts) #/** diff --git a/MdePkg/Library/BaseLib/AArch64/GetInterruptsState.S b/MdePkg/Library/BaseLib/AArch64/GetInterruptsState.S index 5a971f5..037f59a 100644 --- a/MdePkg/Library/BaseLib/AArch64/GetInterruptsState.S +++ b/MdePkg/Library/BaseLib/AArch64/GetInterruptsState.S @@ -17,7 +17,7 @@ .text .p2align 2 -ASM_GLOBAL ASM_PFX(GetInterruptState) +GCC_ASM_EXPORT(GetInterruptState) #/** # Retrieves the current CPU interrupt state. diff --git a/MdePkg/Library/BaseLib/AArch64/SetJumpLongJump.S b/MdePkg/Library/BaseLib/AArch64/SetJumpLongJump.S index dbc5adb..704996d 100644 --- a/MdePkg/Library/BaseLib/AArch64/SetJumpLongJump.S +++ b/MdePkg/Library/BaseLib/AArch64/SetJumpLongJump.S @@ -13,8 +13,8 @@ .text .p2align 3 -ASM_GLOBAL ASM_PFX(SetJump) -ASM_GLOBAL ASM_PFX(InternalLongJump) +GCC_ASM_EXPORT(SetJump) +GCC_ASM_EXPORT(InternalLongJump) #define GPR_LAYOUT \ REG_PAIR (x19, x20, 0); \ diff --git a/MdePkg/Library/BaseLib/AArch64/SwitchStack.S b/MdePkg/Library/BaseLib/AArch64/SwitchStack.S index 207a569..2bce9c9 100644 --- a/MdePkg/Library/BaseLib/AArch64/SwitchStack.S +++ b/MdePkg/Library/BaseLib/AArch64/SwitchStack.S @@ -16,8 +16,8 @@ .text .align 5 -ASM_GLOBAL ASM_PFX(InternalSwitchStackAsm) -ASM_GLOBAL ASM_PFX(CpuPause) +GCC_ASM_EXPORT(InternalSwitchStackAsm) +GCC_ASM_EXPORT(CpuPause) /** // -- 2.1.1 -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] [PATCH 2/2] ArmVirtPkg: use correct ASM decoration for non-function global symbols
Reviewed-By: Olivier Martin olivier.mar...@arm.com -Original Message- From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] Sent: 07 July 2015 14:36 To: edk2-devel@lists.sourceforge.net; Olivier Martin; ler...@redhat.com Cc: leif.lindh...@linaro.org; Ard Biesheuvel Subject: [PATCH 2/2] ArmVirtPkg: use correct ASM decoration for non-function global symbols This fixes the declaration and definition of mSystemMemoryEnd so that it is correctly annotated as a non-function symbol. Also adds the ASM_PFX prefix, which is empty on AARCH64 but should be included for correctness. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org --- ArmVirtPkg/PrePi/AArch64/ModuleEntryPoint.S | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/ArmVirtPkg/PrePi/AArch64/ModuleEntryPoint.S b/ArmVirtPkg/PrePi/AArch64/ModuleEntryPoint.S index 0adaf44c9ed9..f0cf865b3c93 100644 --- a/ArmVirtPkg/PrePi/AArch64/ModuleEntryPoint.S +++ b/ArmVirtPkg/PrePi/AArch64/ModuleEntryPoint.S @@ -25,10 +25,10 @@ GCC_ASM_IMPORT(ArmReadMpidr) GCC_ASM_IMPORT(ArmPlatformPeiBootAction) GCC_ASM_IMPORT(ArmPlatformStackSet) GCC_ASM_EXPORT(_ModuleEntryPoint) -GCC_ASM_EXPORT(mSystemMemoryEnd) +ASM_GLOBAL ASM_PFX(mSystemMemoryEnd) -StartupAddr:.8byte ASM_PFX(CEntryPoint) -mSystemMemoryEnd: .8byte 0 +StartupAddr: .8byte ASM_PFX(CEntryPoint) +ASM_PFX(mSystemMemoryEnd):.8byte 0 ASM_PFX(_ModuleEntryPoint): // -- 1.9.1 -- 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. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2548782 -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] [PATCH 1/2] ArmPlatformPkg: use correct ASM decoration for non-function global symbols
Reviewed-By: Olivier Martin olivier.mar...@arm.com Thanks Ard for catching this error! -Original Message- From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] Sent: 07 July 2015 14:36 To: edk2-devel@lists.sourceforge.net; Olivier Martin; ler...@redhat.com Cc: leif.lindh...@linaro.org; Ard Biesheuvel Subject: [PATCH 1/2] ArmPlatformPkg: use correct ASM decoration for non-function global symbols This fixes the declaration and definition of mSystemMemoryEnd so that it is correctly annotated as a non-function symbol. Also adds the ASM_PFX prefix, which is empty on AARCH64 but should be included for correctness. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org --- ArmPlatformPkg/PrePi/AArch64/ModuleEntryPoint.S | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/ArmPlatformPkg/PrePi/AArch64/ModuleEntryPoint.S b/ArmPlatformPkg/PrePi/AArch64/ModuleEntryPoint.S index 2c4a7e5324e9..0d0e3e17c170 100644 --- a/ArmPlatformPkg/PrePi/AArch64/ModuleEntryPoint.S +++ b/ArmPlatformPkg/PrePi/AArch64/ModuleEntryPoint.S @@ -24,10 +24,10 @@ GCC_ASM_IMPORT(ArmReadMpidr) GCC_ASM_IMPORT(ArmPlatformPeiBootAction) GCC_ASM_IMPORT(ArmPlatformStackSet) GCC_ASM_EXPORT(_ModuleEntryPoint) -GCC_ASM_EXPORT(mSystemMemoryEnd) +ASM_GLOBAL ASM_PFX(mSystemMemoryEnd) -StartupAddr: .8byte ASM_PFX(CEntryPoint) -mSystemMemoryEnd: .8byte 0 +StartupAddr: .8byte ASM_PFX(CEntryPoint) +ASM_PFX(mSystemMemoryEnd):.8byte 0 ASM_PFX(_ModuleEntryPoint): // Do early platform specific actions -- 1.9.1 -- 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. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2548782 -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] [PATCH 1/6] MdePkg/BasePeCoffLib: remove redundant PeCoffLoaderEx.c for AARCH64
Reviewed-By: Olivier Martin olivier.mar...@arm.com
Harry had to do a similar clean-up when he added support for LLVM:
https://github.com/ARM-software/edk2/commit/54cb35d53e691a856381efa2c0756d7bd7e2347a
-Original Message-
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
Sent: 03 July 2015 10:40
To: edk2-devel@lists.sourceforge.net; michael.d.kin...@intel.com;
jiewen@intel.com; liming@intel.com; jordan.l.jus...@intel.com
Cc: ler...@redhat.com; Olivier Martin; Ard Biesheuvel
Subject: [PATCH 1/6] MdePkg/BasePeCoffLib: remove redundant PeCoffLoaderEx.c
for AARCH64
The AARCH64 specific implementations of PeCoffLoaderRelocateImageEx and
PeHotRelocateImageEx only handle EFI_IMAGE_REL_BASED_DIR64 relocations.
Since these are already handled by the respective callers, this is essentially
dead code and can be removed.
So add IMAGE_FILE_MACHINE_ARM64 support to the list of supported machines of
the generic version, and use it for AARCH64 as well.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
MdePkg/Library/BasePeCoffLib/AArch64/PeCoffLoaderEx.c | 127
MdePkg/Library/BasePeCoffLib/BasePeCoffLib.inf| 5 +-
MdePkg/Library/BasePeCoffLib/PeCoffLoaderEx.c | 4 +-
3 files changed, 3 insertions(+), 133 deletions(-)
diff --git a/MdePkg/Library/BasePeCoffLib/AArch64/PeCoffLoaderEx.c
b/MdePkg/Library/BasePeCoffLib/AArch64/PeCoffLoaderEx.c
deleted file mode 100644
index 7e4b4db45328..
--- a/MdePkg/Library/BasePeCoffLib/AArch64/PeCoffLoaderEx.c
+++ /dev/null
@@ -1,127 +0,0 @@
-/** @file
- Specific relocation fixups for ARM architecture.
-
- Copyright (c) 2006 - 2009, Intel Corporation. All rights reserved.BR
- Portions copyright (c) 2008 - 2010, Apple Inc. All rights reserved.BR
- Portions copyright (c) 2011 - 2013, ARM Ltd. All rights reserved.BR
-
- This program and the accompanying materials
- are licensed and made available under the terms and conditions of the BSD
License
- which accompanies this distribution. The full text of the license may be
found at
- http://opensource.org/licenses/bsd-license.php.
-
- THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN AS IS BASIS,
- WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
-
-**/
-
-#include BasePeCoffLibInternals.h
-#include Library/BaseLib.h
-
-// Note: Currently only large memory model is supported by UEFI relocation
code.
-
-/**
- Performs an AARCH64-based specific relocation fixup and is a no-op on other
- instruction sets.
-
- @param Reloc The pointer to the relocation record.
- @param Fixup The pointer to the address to fix up.
- @param FixupData The pointer to a buffer to log the fixups.
- @param Adjust The offset to adjust the fixup.
-
- @return Status code.
-
-**/
-RETURN_STATUS
-PeCoffLoaderRelocateImageEx (
- IN UINT16 *Reloc,
- IN OUT CHAR8 *Fixup,
- IN OUT CHAR8 **FixupData,
- IN UINT64 Adjust
- )
-{
- UINT64 *Fixup64;
-
- switch ((*Reloc) 12) {
-
-case EFI_IMAGE_REL_BASED_DIR64:
- Fixup64 = (UINT64 *) Fixup;
- *Fixup64 = *Fixup64 + (UINT64) Adjust;
- if (*FixupData != NULL) {
-*FixupData = ALIGN_POINTER(*FixupData, sizeof(UINT64));
-*(UINT64 *)(*FixupData) = *Fixup64;
-*FixupData = *FixupData + sizeof(UINT64);
- }
- break;
-
-default:
- return RETURN_UNSUPPORTED;
- }
-
- return RETURN_SUCCESS;
-}
-
-/**
- Returns TRUE if the machine type of PE/COFF image is supported. Supported
- does not mean the image can be executed it means the PE/COFF loader supports
- loading and relocating of the image type. It's up to the caller to support
- the entry point.
-
- @param Machine Machine type from the PE Header.
-
- @return TRUE if this PE/COFF loader can load the image
-
-**/
-BOOLEAN
-PeCoffLoaderImageFormatSupported (
- IN UINT16 Machine
- )
-{
- if ((Machine == IMAGE_FILE_MACHINE_ARM64) || (Machine ==
IMAGE_FILE_MACHINE_EBC)) {
-return TRUE;
- }
-
- return FALSE;
-}
-
-/**
- Performs an ARM-based specific re-relocation fixup and is a no-op on other
- instruction sets. This is used to re-relocated the image into the EFI virtual
- space for runtime calls.
-
- @param Reloc The pointer to the relocation record.
- @param Fixup The pointer to the address to fix up.
- @param FixupData The pointer to a buffer to log the fixups.
- @param Adjust The offset to adjust the fixup.
-
- @return Status code.
-
-**/
-RETURN_STATUS
-PeHotRelocateImageEx (
- IN UINT16 *Reloc,
- IN OUT CHAR8 *Fixup,
- IN OUT CHAR8 **FixupData,
- IN UINT64 Adjust
- )
-{
- UINT64 *Fixup64;
-
- switch ((*Reloc) 12) {
- case EFI_IMAGE_REL_BASED_DIR64:
-Fixup64 = (UINT64 *) Fixup;
-*FixupData = ALIGN_POINTER (*FixupData, sizeof (UINT64));
-if (*(UINT64 *) (*FixupData) == *Fixup64
Re: [edk2] [PATCH] MdeModulePkg/PartitionDxe: Fix media probe
Are you still debating on my simple patch I sent 3 months ago that definitely fixes an issue? From: Ni, Ruiyu [mailto:ruiyu...@intel.com] Sent: 06 May 2015 03:37 To: Olivier Martin; edk2-devel@lists.sourceforge.net Cc: Ronald Cron Subject: RE: [PATCH] MdeModulePkg/PartitionDxe: Fix media probe Martin, I agree that your patch works. Just wanted to figure out a better patch. But I haven't got chance to do the investigation yet. Thanks, Ray From: Olivier Martin [mailto:olivier.mar...@arm.com] Sent: Tuesday, May 5, 2015 10:46 PM To: edk2-devel@lists.sourceforge.netmailto:edk2-devel@lists.sourceforge.net; Ni, Ruiyu Cc: Ronald Cron Subject: RE: [PATCH] MdeModulePkg/PartitionDxe: Fix media probe Any update on this patch? From: Olivier Martin [mailto:olivier.mar...@arm.com] Sent: 02 April 2015 10:44 To: Ni, Ruiyu; edk2-devel@lists.sourceforge.netmailto:edk2-devel@lists.sourceforge.net Cc: Ronald Cron Subject: Re: [edk2] [PATCH] MdeModulePkg/PartitionDxe: Fix media probe It is likely your change will not test if there is a present media by reading no byte. I think Ronald's change (original patch) is better. From: Ni, Ruiyu [mailto:ruiyu...@intel.com] Sent: 02 April 2015 05:33 To: edk2-devel@lists.sourceforge.netmailto:edk2-devel@lists.sourceforge.net; Olivier Martin Cc: Ronald Cron Subject: RE: [PATCH] MdeModulePkg/PartitionDxe: Fix media probe Martin, Please check the attached patch. Can it solve your issue? Thanks, Ray From: Tian, Feng [mailto:feng.t...@intel.com] Sent: Thursday, April 2, 2015 9:37 AM To: Olivier Martin Cc: Ronald Cron; edk2-devel@lists.sourceforge.netmailto:edk2-devel@lists.sourceforge.net Subject: Re: [edk2] [PATCH] MdeModulePkg/PartitionDxe: Fix media probe Thanks, Martin I think it's a bug and our test coverage may be not enough as it doesn't get exposed before. Will double confirm with Partition owner and get back to you if we have conclusion. Thanks Feng From: Olivier Martin [mailto:olivier.mar...@arm.com] Sent: Wednesday, April 1, 2015 11:23 PM To: Tian, Feng Cc: Ronald Cron; edk2-devel@lists.sourceforge.netmailto:edk2-devel@lists.sourceforge.net Subject: [PATCH] MdeModulePkg/PartitionDxe: Fix media probe Dear MdeModulePkg maintainer, Please find the attached patch that should fix the following issue: The call in ProbeMediaStatus() to the ReadDisk() function of the EFI_DISK_IO_PROTOCOL interface implemented in DiskIoDxe/DiskIo.c crashed in DiskIo2ReadWriteDisk() because of the NULL value of the destination buffer pointer. Pass the address of a buffer in the stack instead of a NULL pointer. In addition to avoiding the crash, that way, the media probe does not depend anymore on the way the EFI_DISK_IO_PROTOCOL implementation deals with a NULL value of the destination buffer pointer as the UEFI specification does not specify the expected behaviour. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ronald Cron ronald.c...@arm.commailto:ronald.c...@arm.com Reviewed-by: Olivier Martin olivier.mar...@arm.commailto:olivier.mar...@arm.com Regards, Olivier -- 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. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2548782 -- 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. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2548782 -- 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. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2548782 -- 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
[edk2] [PATCH] MdeModulePkg/FvSimpleFileSystemDxe: Support file opening with no '.efi'
FvSimpleFileSystem adds '.efi' to the EFI application and drivers
filenames even through this extension is not present in the real
filename of the EFI module.
In the current behaviour, it would not be possible to open an EFI
application using FvSimpleFileSystem if the extension has been omitted
in the given filename.
It can be create some confusion if someone wants to try to
open a file with the real application name (eg: 'Shell').
This patch adds support to try again to look for the file with the
extension if it had failed to find it without the extension.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Olivier Martin olivier.mar...@arm.com
---
.../FvSimpleFileSystemDxe/FvSimpleFileSystem.c | 62 +-
1 file changed, 50 insertions(+), 12 deletions(-)
diff --git a/MdeModulePkg/Universal/FvSimpleFileSystemDxe/FvSimpleFileSystem.c
b/MdeModulePkg/Universal/FvSimpleFileSystemDxe/FvSimpleFileSystem.c
index b0e7dc3..c6137ac 100644
--- a/MdeModulePkg/Universal/FvSimpleFileSystemDxe/FvSimpleFileSystem.c
+++ b/MdeModulePkg/Universal/FvSimpleFileSystemDxe/FvSimpleFileSystem.c
@@ -483,6 +483,10 @@ FvSimpleFileSystemOpen (
FV_FILESYSTEM_FILE *NewFile;
FV_FILESYSTEM_FILE_INFO *FvFileInfo;
LIST_ENTRY *FvFileInfoLink;
+ EFI_STATUS Status;
+ UINTN FileNameLength;
+ UINTN NewFileNameLength;
+ CHAR16 *FileNameWithExtension;
//
// Check for a valid mode
@@ -531,26 +535,60 @@ FvSimpleFileSystemOpen (
//
// Do a linear search for a file in the FV with a matching filename
//
+ Status = EFI_NOT_FOUND;
+ FvFileInfo = NULL;
for (FvFileInfoLink = GetFirstNode (Instance-FileInfoHead);
!IsNull (Instance-FileInfoHead, FvFileInfoLink);
FvFileInfoLink = GetNextNode (Instance-FileInfoHead, FvFileInfoLink))
{
FvFileInfo = FVFS_FILE_INFO_FROM_LINK (FvFileInfoLink);
if (mUnicodeCollation-StriColl (mUnicodeCollation,
FvFileInfo-FileInfo.FileName[0], FileName) == 0) {
- NewFile = AllocateZeroPool (sizeof (FV_FILESYSTEM_FILE));
- if (NewFile == NULL) {
-return EFI_OUT_OF_RESOURCES;
- }
+ Status = EFI_SUCCESS;
+ break;
+}
+ }
- NewFile-Signature = FVFS_FILE_SIGNATURE;
- NewFile-Instance = Instance;
- NewFile-FvFileInfo = FvFileInfo;
- CopyMem (NewFile-FileProtocol, mFileSystemTemplate, sizeof
(mFileSystemTemplate));
- InitializeListHead (NewFile-Link);
- InsertHeadList (Instance-FileHead, NewFile-Link);
+ // If the file has not been found check if the filename exists with an
extension
+ // in case there was no extension present.
+ // FvFileSystem adds a 'virtual' extension '.EFI' to EFI applications and
drivers
+ // present in the Firmware Volume
+ if (Status == EFI_NOT_FOUND) {
+FileNameLength = StrLen (FileName);
+
+// Does the filename already contain the '.EFI' extension?
+if (mUnicodeCollation-StriColl (mUnicodeCollation, FileName +
FileNameLength - 4, L.efi) != 0) {
+ // No, there was no extension. So add one and search again for the file
+ // NewFileNameLength = FileNameLength + 1 + 4 = (Number of non-null
character) + (file extension) + (a null character)
+ NewFileNameLength = FileNameLength + 1 + 4;
+ FileNameWithExtension = AllocateCopyPool (NewFileNameLength * 2,
FileName);
+ StrCatS (FileNameWithExtension, NewFileNameLength, L.EFI);
+
+ for (FvFileInfoLink = GetFirstNode (Instance-FileInfoHead);
+ !IsNull (Instance-FileInfoHead, FvFileInfoLink);
+ FvFileInfoLink = GetNextNode (Instance-FileInfoHead,
FvFileInfoLink)) {
+FvFileInfo = FVFS_FILE_INFO_FROM_LINK (FvFileInfoLink);
+if (mUnicodeCollation-StriColl (mUnicodeCollation,
FvFileInfo-FileInfo.FileName[0], FileNameWithExtension) == 0) {
+ Status = EFI_SUCCESS;
+ break;
+}
+ }
+}
+ }
- *NewHandle = NewFile-FileProtocol;
- return EFI_SUCCESS;
+ if (!EFI_ERROR (Status)) {
+NewFile = AllocateZeroPool (sizeof (FV_FILESYSTEM_FILE));
+if (NewFile == NULL) {
+ return EFI_OUT_OF_RESOURCES;
}
+
+NewFile-Signature = FVFS_FILE_SIGNATURE;
+NewFile-Instance = Instance;
+NewFile-FvFileInfo = FvFileInfo;
+CopyMem (NewFile-FileProtocol, mFileSystemTemplate, sizeof
(mFileSystemTemplate));
+InitializeListHead (NewFile-Link);
+InsertHeadList (Instance-FileHead, NewFile-Link);
+
+*NewHandle = NewFile-FileProtocol;
+return EFI_SUCCESS;
}
return EFI_NOT_FOUND;
--
2.1.1
--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https
Re: [edk2] [PATCH] ArmPlatformPkg/ArmVExpressPkg: use 64 KB section alignment for runtime drivers
Reviewed-by: Olivier Martin olivier.mar...@arm.com -Original Message- From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] Sent: 06 July 2015 17:40 To: edk2-devel@lists.sourceforge.net; Olivier Martin Cc: leif.lindh...@linaro.org; Ard Biesheuvel Subject: [PATCH] ArmPlatformPkg/ArmVExpressPkg: use 64 KB section alignment for runtime drivers This adds the 64 KB alignment overlay linker script to the linker command line of DXE_RUNTIME_DRIVER modules built for AARCH64. This makes these modules compatible with the new Properties Table feature by aligning the .text and .data sections to 64 KB. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org --- ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc | 3 +++ 1 file changed, 3 insertions(+) diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc index 4d8adcc3e348..1ca9b2de6550 100644 --- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc +++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc @@ -12,6 +12,9 @@ # # +[BuildOptions.AARCH64.EDKII.DXE_RUNTIME_DRIVER] + *_*_AARCH64_DLINK_FLAGS = +--script=$(EDK_TOOLS_PATH)/Scripts/gcc-aarch64-64K-align-ld-script + [LibraryClasses.common] !if $(TARGET) == RELEASE DebugLib|MdePkg/Library/BaseDebugLibNull/BaseDebugLibNull.inf -- 1.9.1 -- 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. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2548782 -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] [PATCH 1/2] BaseTools: AArch64: use explicit linker scripts
Reviewed-By: Olivier Martin olivier.mar...@arm.com -Original Message- From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] Sent: 29 June 2015 19:37 To: edk2-devel@lists.sourceforge.net; ler...@redhat.com; Olivier Martin; af...@apple.com; eug...@hp.com; jiewen@intel.com Cc: yingke.d@intel.com; matt.flem...@intel.com; Ard Biesheuvel Subject: [PATCH 1/2] BaseTools: AArch64: use explicit linker scripts Instead of relying on the builtin linker script of GNU ld, which may vary based on binutils version (which is not tightly coupled to the GCC version) and linker command line options, introduce a linker script for AArch64 to be used by all GCC/binutils versions. The script is laid out such that two ELF sections .text and .data are created that map onto the PE/COFF ones with the same names. By aligning .data to the minimum alignment of .text, and by not adding any additional padding -which is what LD's builtin linker script does- the relative offset between .text and .data is retained after the PE/COFF conversion. This should prevent problems with debuggers and other tooling that are ELF based. Also provided is an overlay linker script that increases the alignment of .text and .data to 64 KB. This is intended for DXE_RUNTIME_DRIVER modules, to make them compatible with the newly introduced Properties Table feature. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org --- BaseTools/Conf/tools_def.template | 23 +++- BaseTools/Scripts/gcc-aarch64-64K-align-ld-script | 4 ++ BaseTools/Scripts/gcc-aarch64-ld-script | 39 3 files changed, 56 insertions(+), 10 deletions(-) diff --git a/BaseTools/Conf/tools_def.template b/BaseTools/Conf/tools_def.template index 88ec2e138dbc..7edd7590956b 100644 --- a/BaseTools/Conf/tools_def.template +++ b/BaseTools/Conf/tools_def.template @@ -3821,9 +3821,12 @@ DEFINE GCC_ARM_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mword-relocations -m DEFINE GCC_AARCH64_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mcmodel=large -mlittle-endian -fno-short-enums -save-temps -fverbose-asm -fsigned-char -ffunction-sections -fdata-sections -fomit-frame-pointer -fno-builtin -Wno-address DEFINE GCC_DLINK_FLAGS_COMMON = -nostdlib --pie DEFINE GCC_IA32_X64_DLINK_COMMON = DEF(GCC_DLINK_FLAGS_COMMON) --gc-sections -DEFINE GCC_ARM_AARCH64_DLINK_COMMON= -Ttext=0x0 --emit-relocs -nostdlib --gc-sections -u $(IMAGE_ENTRY_POINT) -e $(IMAGE_ENTRY_POINT) -Map $(DEST_DIR_DEBUG)/$(BASE_NAME).map +DEFINE GCC_ARM_AARCH64_DLINK_COMMON= --emit-relocs -nostdlib --gc-sections -u $(IMAGE_ENTRY_POINT) -e $(IMAGE_ENTRY_POINT) -Map $(DEST_DIR_DEBUG)/$(BASE_NAME).map +DEFINE GCC_ARM_DLINK_FLAGS = DEF(GCC_ARM_AARCH64_DLINK_COMMON) -Ttext=0x0 +DEFINE GCC_AARCH64_DLINK_FLAGS = DEF(GCC_ARM_AARCH64_DLINK_COMMON) --script=$(EDK_TOOLS_PATH)/Scripts/gcc-aarch64-ld-script DEFINE GCC_IA32_X64_ASLDLINK_FLAGS = DEF(GCC_IA32_X64_DLINK_COMMON) --entry _ReferenceAcpiTable -u $(IMAGE_ENTRY_POINT) -DEFINE GCC_ARM_AARCH64_ASLDLINK_FLAGS = DEF(GCC_ARM_AARCH64_DLINK_COMMON) --entry ReferenceAcpiTable -u $(IMAGE_ENTRY_POINT) +DEFINE GCC_ARM_ASLDLINK_FLAGS = DEF(GCC_ARM_DLINK_FLAGS) --entry ReferenceAcpiTable -u $(IMAGE_ENTRY_POINT) +DEFINE GCC_AARCH64_ASLDLINK_FLAGS = DEF(GCC_AARCH64_DLINK_FLAGS) +--entry ReferenceAcpiTable -u $(IMAGE_ENTRY_POINT) DEFINE GCC_IA32_X64_DLINK_FLAGS= DEF(GCC_IA32_X64_DLINK_COMMON) --entry _$(IMAGE_ENTRY_POINT) --file-alignment 0x20 --section-alignment 0x20 -Map $(DEST_DIR_DEBUG)/$(BASE_NAME).map DEFINE GCC_IPF_DLINK_FLAGS = -nostdlib -O2 --gc-sections --dll -static --entry $(IMAGE_ENTRY_POINT) --undefined $(IMAGE_ENTRY_POINT) -Map $(DEST_DIR_DEBUG)/$(BASE_NAME).map DEFINE GCC_IPF_OBJCOPY_FLAGS = -I elf64-ia64-little -O efi-bsdrv-ia64 @@ -3866,8 +3869,8 @@ DEFINE GCC46_X64_DLINK_FLAGS = DEF(GCC45_X64_DLINK_FLAGS) DEFINE GCC46_ASM_FLAGS = DEF(GCC45_ASM_FLAGS) DEFINE GCC46_ARM_ASM_FLAGS = $(ARCHASM_FLAGS) $(PLATFORM_FLAGS) DEF(GCC_ASM_FLAGS) -mlittle-endian DEFINE GCC46_ARM_CC_FLAGS= $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) DEF(GCC44_ALL_CC_FLAGS) DEF(GCC_ARM_CC_FLAGS) -fstack-protector -DEFINE GCC46_ARM_DLINK_FLAGS = DEF(GCC_ARM_AARCH64_DLINK_COMMON) --oformat=elf32-littlearm -DEFINE GCC46_ARM_ASLDLINK_FLAGS = DEF(GCC_ARM_AARCH64_ASLDLINK_FLAGS) --oformat=elf32-littlearm +DEFINE GCC46_ARM_DLINK_FLAGS = DEF(GCC_ARM_DLINK_FLAGS) --oformat=elf32-littlearm +DEFINE GCC46_ARM_ASLDLINK_FLAGS = DEF(GCC_ARM_ASLDLINK_FLAGS) --oformat=elf32-littlearm DEFINE GCC47_IA32_CC_FLAGS = DEF(GCC46_IA32_CC_FLAGS) DEFINE GCC47_X64_CC_FLAGS= DEF(GCC46_X64_CC_FLAGS) @@ -3881,9 +3884,9 @@ DEFINE GCC47_AARCH64_ASM_FLAGS = $(ARCHASM_FLAGS) $(PLATFORM_FLAGS) DEF(GC DEFINE GCC47_ARM_CC_FLAGS= DEF(GCC46_ARM_CC_FLAGS
Re: [edk2] [PATCH 2/2] ArmVirtPkg: build runtime drivers with 64 KB section alignment
Reviewed-By: Olivier Martin olivier.mar...@arm.com -Original Message- From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] Sent: 29 June 2015 19:37 To: edk2-devel@lists.sourceforge.net; ler...@redhat.com; Olivier Martin; af...@apple.com; eug...@hp.com; jiewen@intel.com Cc: yingke.d@intel.com; matt.flem...@intel.com; Ard Biesheuvel Subject: [PATCH 2/2] ArmVirtPkg: build runtime drivers with 64 KB section alignment This adds the 64 KB alignment overlay linker script to the linker command line of DXE_RUNTIME_DRIVER modules. This makes these modules compatible with the new Properties Table feature by aligning the .text and .data sections to 64 KB. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org --- ArmVirtPkg/ArmVirt.dsc.inc | 3 +++ 1 files changed, 3 insertions(+) diff --git a/ArmVirtPkg/ArmVirt.dsc.inc b/ArmVirtPkg/ArmVirt.dsc.inc index c6e684fd8512..f3f29d70917e 100644 --- a/ArmVirtPkg/ArmVirt.dsc.inc +++ b/ArmVirtPkg/ArmVirt.dsc.inc @@ -15,6 +15,9 @@ [Defines] DEFINE DEBUG_PRINT_ERROR_LEVEL = 0x804F +[BuildOptions.AARCH64.EDKII.DXE_RUNTIME_DRIVER] + *_*_AARCH64_DLINK_FLAGS = +--script=$(EDK_TOOLS_PATH)/Scripts/gcc-aarch64-64K-align-ld-script + [LibraryClasses.common] !if $(TARGET) == RELEASE DebugLib|MdePkg/Library/BaseDebugLibNull/BaseDebugLibNull.inf diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc index 374cf7a9ee02..cded653a2c96 100644 --- a/ArmVirtPkg/ArmVirtQemu.dsc +++ b/ArmVirtPkg/ArmVirtQemu.dsc @@ -78,7 +78,6 @@ [BuildOptions] GCC:*_*_ARM_PLATFORM_FLAGS == -mcpu=cortex-a15 -I$(WORKSPACE)/ArmVirtPkg/Include *_*_AARCH64_PLATFORM_FLAGS == -I$(WORKSPACE)/ArmVirtPkg/Include - # # Pcd Section - list of all EDK II PCD Entries defined by this Platform -- 1.9.1 -- 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. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2548782 -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
[edk2] [PATCH] MdePkg/ImageAuthentication.h: Fixed ARM toolchain error
ARM Toolchain raised the error: last line of file ends without a newline Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Olivier Martin olivier.mar...@arm.com --- MdePkg/Include/Guid/ImageAuthentication.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/MdePkg/Include/Guid/ImageAuthentication.h b/MdePkg/Include/Guid/ImageAuthentication.h index 621a94f..c321383 100644 --- a/MdePkg/Include/Guid/ImageAuthentication.h +++ b/MdePkg/Include/Guid/ImageAuthentication.h @@ -349,4 +349,5 @@ extern EFI_GUID gEfiCertX509Sha384Guid; extern EFI_GUID gEfiCertX509Sha512Guid; extern EFI_GUID gEfiCertPkcs7Guid; -#endif \ No newline at end of file +#endif + -- 2.1.1 -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] Questions regarding XHCI
I am guessing your question is to make the USB XHCI controller memory mapped device instead of relying on the PCI IO protocol. There were some discussions on the EDK2 mailing-list few years ago about disconnecting the USB Host controller DXE driver from PCI IO driver. The UEFI spec does not mandate to use USB Host controller over PCI Bus. The idea was to create a new (UEFI) protocol that would abstract the hardware transport protocol as we did for the VirtIo devices. At the moment we are creating fake PCI bus to workaround this limitation. But it is not the right approach. Contributions are welcome! From: Badola Nikhil [mailto:nikhil.bad...@freescale.com] Sent: 29 June 2015 13:14 To: edk2-devel@lists.sourceforge.net Subject: [edk2] Questions regarding XHCI Could anyone please help me with below queries regarding USB XHCI controller as platform device rather than as PCI device : - Has anyone tested USB stack for XHCI controller as platform device after modifying exiting XhciDxe/* or writing new host controller driver ? - Which protocol would it consume in this case? Regards, Nikhil -- 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. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2548782 -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] [PATCH] ArmPlatformPkg: Allow PcdFirmwareVersionString to be a dynamic PCD
Reviewed-By: Olivier Martin olivier.mar...@arm.com -Original Message- From: El-Haj-Mahmoud, Samer [mailto:samer.el-haj-mahm...@hp.com] Sent: 01 July 2015 15:26 To: edk2-devel@lists.sourceforge.net Cc: Olivier Martin Subject: RE: [PATCH] ArmPlatformPkg: Allow PcdFirmwareVersionString to be a dynamic PCD Oliver, Can you please help review this ? -Original Message- From: El-Haj-Mahmoud, Samer Sent: Sunday, June 28, 2015 11:42 AM To: edk2-devel@lists.sourceforge.net Cc: olivier.mar...@arm.com Subject: RE: [PATCH] ArmPlatformPkg: Allow PcdFirmwareVersionString to be a dynamic PCD PcdFirmwareVersionString is defined in MdeModulePkg to be either fixed or dynamic, but is restricted in ArmPlatformPkg drivers to FixedPcd. Changed to remove the FixedPcd restrictions to allow platforms to chose the correct type in their DSC files. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Samer El-Haj-Mahmoud samer.el-haj-mahm...@hp.com --- ArmPlatformPkg/PrePi/PeiMPCore.inf | 4 +++- ArmPlatformPkg/PrePi/PeiUniCore.inf | 4 +++- ArmPlatformPkg/Sec/Sec.inf | 5 - 3 files changed, 10 insertions(+), 3 deletions(-) diff --git a/ArmPlatformPkg/PrePi/PeiMPCore.inf b/ArmPlatformPkg/PrePi/PeiMPCore.inf index ad996c5..ac1f8d0 100755 --- a/ArmPlatformPkg/PrePi/PeiMPCore.inf +++ b/ArmPlatformPkg/PrePi/PeiMPCore.inf @@ -1,5 +1,6 @@ #/** @file # +# (C) Copyright 2015 Hewlett-Packard Development Company, L.P.BR # Copyright (c) 2011-2014, ARM Ltd. All rights reserved.BR # # This program and the accompanying materials @@ -73,9 +74,10 @@ gEmbeddedTokenSpaceGuid.PcdPrePiProduceMemoryTypeInformationHob gArmPlatformTokenSpaceGuid.PcdSendSgiToBringUpSecondaryCores -[FixedPcd] +[Pcd] gEfiMdeModulePkgTokenSpaceGuid.PcdFirmwareVersionString +[FixedPcd] gArmTokenSpaceGuid.PcdVFPEnabled gArmTokenSpaceGuid.PcdFdBaseAddress diff --git a/ArmPlatformPkg/PrePi/PeiUniCore.inf b/ArmPlatformPkg/PrePi/PeiUniCore.inf index f892573..c566390 100755 --- a/ArmPlatformPkg/PrePi/PeiUniCore.inf +++ b/ArmPlatformPkg/PrePi/PeiUniCore.inf @@ -1,5 +1,6 @@ #/** @file # +# (C) Copyright 2015 Hewlett-Packard Development Company, L.P.BR # Copyright (c) 2011-2014, ARM Ltd. All rights reserved.BR # # This program and the accompanying materials @@ -72,9 +73,10 @@ gEmbeddedTokenSpaceGuid.PcdPrePiProduceMemoryTypeInformationHob gArmPlatformTokenSpaceGuid.PcdSendSgiToBringUpSecondaryCores -[FixedPcd] +[Pcd] gEfiMdeModulePkgTokenSpaceGuid.PcdFirmwareVersionString +[FixedPcd] gArmTokenSpaceGuid.PcdVFPEnabled gArmTokenSpaceGuid.PcdFdBaseAddress diff --git a/ArmPlatformPkg/Sec/Sec.inf b/ArmPlatformPkg/Sec/Sec.inf index 27e64c7..7c6e7ff 100644 --- a/ArmPlatformPkg/Sec/Sec.inf +++ b/ArmPlatformPkg/Sec/Sec.inf @@ -1,6 +1,7 @@ #/** @file # SEC - Reset vector code that jumps to C and starts the PEI phase # +# (C) Copyright 2015 Hewlett-Packard Development Company, L.P.BR # Copyright (c) 2011-2013, ARM Limited. All rights reserved. # # This program and the accompanying materials @@ -55,9 +56,11 @@ PrintLib SerialPortLib -[FixedPcd.common] +[Pcd] gEfiMdeModulePkgTokenSpaceGuid.PcdFirmwareVersionString +[FixedPcd.common] + gArmTokenSpaceGuid.PcdTrustzoneSupport gArmTokenSpaceGuid.PcdVFPEnabled -- 1.9.5.msysgit.0 -- 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. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2548782 -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] [PATCH] ArmVirtPkg: signal EndOxDxe event in PlatformBsdInit
I think this patch should move to IntelFrameworkModulePkg/Universal/BdsDxe. It
is a PI specification requirement to signal gEfiEndOfDxeEventGroupGuid at the
end of the DXE phase.
-Original Message-
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
Sent: 24 June 2015 11:25
To: edk2-devel@lists.sourceforge.net; ler...@redhat.com; Olivier Martin
Cc: leif.lindh...@linaro.org; roy.fr...@linaro.org; Ard Biesheuvel
Subject: [PATCH] ArmVirtPkg: signal EndOxDxe event in PlatformBsdInit
Currently, the ArmVirtPkg platforms fail to signal the end-of-DXE event
'gEfiEndOfDxeEventGroupGuid' when entering the BDS phase, which results in some
loss of functionality, i.e., variable reclaim in the VariableDxe drivers, and
the splitting of the memory regions that is part of the recently added UEFI 2.5
properties table feature.
This patch adds signalling of the event to PlatformBdsInit() of the
PlatformBdsLib instance for the Intel BDS. Note that the ARM BDS does signal
the event, so this looks like a convenient place to put it.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
.../Library/PlatformIntelBdsLib/IntelBdsPlatform.c | 35 ++
.../PlatformIntelBdsLib/PlatformIntelBdsLib.inf| 1 +
2 files changed, 36 insertions(+)
diff --git a/ArmVirtPkg/Library/PlatformIntelBdsLib/IntelBdsPlatform.c
b/ArmVirtPkg/Library/PlatformIntelBdsLib/IntelBdsPlatform.c
index 499cce5dcde6..0e60409cdc73 100644
--- a/ArmVirtPkg/Library/PlatformIntelBdsLib/IntelBdsPlatform.c
+++ b/ArmVirtPkg/Library/PlatformIntelBdsLib/IntelBdsPlatform.c
@@ -24,6 +24,7 @@
#include Protocol/GraphicsOutput.h
#include Protocol/PciIo.h
#include Protocol/PciRootBridgeIo.h
+#include Guid/EventGroup.h
#include IntelBdsPlatform.h
@@ -118,6 +119,23 @@ STATIC PLATFORM_USB_KEYBOARD mUsbKeyboard = {
}
};
+/**
+ An empty function to pass error checking of CreateEventEx ().
+
+ @param Event Event whose notification function is being
invoked.
+ @param Context Pointer to the notification function's context,
+which is implementation-dependent.
+
+**/
+VOID
+EFIAPI
+EmptyCallbackFunction (
+ IN EFI_EVENTEvent,
+ IN VOID *Context
+ )
+{
+ return;
+}
//
// BDS Platform Functions
@@ -133,6 +151,23 @@ PlatformBdsInit (
VOID
)
{
+ EFI_EVENT EndOfDxeEvent;
+ EFI_STATUS Status;
+
+ //
+ // Signal EndOfDxe PI Event
+ //
+ Status = gBS-CreateEventEx (
+ EVT_NOTIFY_SIGNAL,
+ TPL_NOTIFY,
+ EmptyCallbackFunction,
+ NULL,
+ gEfiEndOfDxeEventGroupGuid,
+ EndOfDxeEvent
+ );
+ if (!EFI_ERROR (Status)) {
+gBS-SignalEvent (EndOfDxeEvent);
+ }
}
diff --git a/ArmVirtPkg/Library/PlatformIntelBdsLib/PlatformIntelBdsLib.inf
b/ArmVirtPkg/Library/PlatformIntelBdsLib/PlatformIntelBdsLib.inf
index d8f892642c2e..d9982167e81d 100644
--- a/ArmVirtPkg/Library/PlatformIntelBdsLib/PlatformIntelBdsLib.inf
+++ b/ArmVirtPkg/Library/PlatformIntelBdsLib/PlatformIntelBdsLib.inf
@@ -65,6 +65,7 @@ [Guids]
gEfiFileInfoGuid
gEfiFileSystemInfoGuid
gEfiFileSystemVolumeLabelInfoIdGuid
+ gEfiEndOfDxeEventGroupGuid
[Protocols]
gEfiDevicePathProtocolGuid
--
1.9.1
-- 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.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered
in England Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England Wales, Company No: 2548782
--
Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based network management software that monitors
network devices and physical virtual servers, alerts via email sms
for fault. Monitor 25 devices for free with no restriction. Download now
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] [PATCH] BaseTools for AArch64 GCC: Ensure that the correlation .text and .data is consistent between ELF and PE-COFF so the debugger sees global variables correctly
Actually, we had support for LLVM internally for a while (it is actually not
confidential as I published the code beginning of this year:
https://github.com/ARM-software/edk2/tree/armcc6).
And we also had to force the 4K alignment for the PEI binaries (see
https://github.com/ARM-software/edk2/commit/55cebbc5bf6fc3770e78b2b3dc706c0a22f2620a).
I did not want to push the code into SVM as I have got concerns about the size
of the UEFI firmware if all the XIP PEI binaries have to be 4K aligned in the
UEFI firmware.
I wanted to do more investigation to see whether:
- it really consume more space (by using padding between the 4K aligned PEI
modules) in the UEFI Firmware
- there was a way (probably through BaseTools) to play with the relocation
offset to prevent these huge paddings
-Original Message-
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
Sent: 22 June 2015 20:28
To: edk2-devel@lists.sourceforge.net; Olivier Martin
Cc: Cohen, Eugene
Subject: Re: [edk2] [PATCH] BaseTools for AArch64 GCC: Ensure that the
correlation .text and .data is consistent between ELF and PE-COFF so the
debugger sees global variables correctly
On 22 June 2015 at 19:26, Olivier Martin olivier.mar...@arm.com wrote:
So I am guessing it is fined to keep 0x260 used by the X64 linker script -
and so reuse the existing GCC ld script. Debuger scripts would need to be
updated to refect this change.
If I compare the results with and without Eugene's patch:
Without:
/work/gcc-linaro-4.9-2015.02-3-x86_64_arm-linux-gnueabihf/bin/arm-linu
x-gnueabihf-readelf -S
Build/ArmJuno-default/DEBUG_GCC49/AARCH64/ArmPkg/Drivers/TimerDxe/Time
rDxe/DEBUG/ArmTimerDxe.dll There are 23 section headers, starting at
offset 0x317a0:
Section Headers:
[Nr] Name Type Address Offset
Size EntSize Flags Link Info Align
[ 0] NULL
0 0 0
[ 1] .text PROGBITS 0001
4468 AX 0 0 8
[ 2] .rela.textRELA 00031d60
24d8 0018 21 1 8
[ 3] .rodata PROGBITS 4468 00014468
18c8 A 0 0 8
[ 4] .data PROGBITS 00015d30 00015d30
0190 WA 0 0 8
[ 5] .rela.dataRELA 00034238
0408 0018 21 4 8
[ 6] .bss NOBITS 00015ec0 00015ec0
0048 WA 0 0 8
(...)
With:
-
/work/gcc-linaro-4.9-2015.02-3-x86_64_arm-linux-gnueabihf/bin/arm-linu
x-gnueabihf-readelf -S
Build/ArmJuno/DEBUG_GCC49/AARCH64/ArmPkg/Drivers/TimerDxe/TimerDxe/DEB
UG/ArmTimerDxe.dll There are 20 section headers, starting at offset
0x317b0:
Section Headers:
[Nr] Name Type Address Offset
Size EntSize Flags Link Info Align
[ 0] NULL
0 0 0
[ 1] .text PROGBITS 0001
4480 AX 0 0 8
[ 2] .rela.textRELA 00031cb0
24d8 0018 18 1 8
[ 3] .data PROGBITS 4480 00014480
1aa0 WA 0 0 8
[ 4] .rela.dataRELA 00034188
0408 0018 18 3 8
(...)
Some regions have disappeared such as .comment (ok!), but also .bss and
.rodata (which I am more concerned).
I have the impression the linker script combine these regions into .data (I
confirm the size of these 3 regions is equal to 0x1aa0). It means it would
change the PE/COFF binary. We can lose in memory protection if we decide
later to make the '.rodata' section a ReadOnly region.
I also do not understand why we have .rela.text between .text and .data
sections. I would expect this section to be present after .data if your
script was working as expected.
I have been spending some time investigating this myself. I agree that
-Ttext=0x0 seems to be redundant, so we should be able to reuse the
X86 script. However, there are some other considerations:
- the x86 script puts .rodata in .data, which is something I would prefer to
avoid since we are moving towards stricter permissions, and putting .rodata in
.data strips it from its constness (I don't think we're quite there yet
Re: [edk2] PXE with manual TFTP server and filename options
The ARM BDS (ArmPlatformPkg/Bds) support booting from TFTP. As Andrew said, TFTP is more a developer solution than a deployment solution. From: Andrew Fish [mailto:af...@apple.com] Sent: 23 June 2015 07:54 To: edk2-devel@lists.sourceforge.net Cc: Olivier Martin Subject: Re: [edk2] PXE with manual TFTP server and filename options On Jun 22, 2015, at 11:29 PM, Radha Mohan mohun...@gmail.commailto:mohun...@gmail.com wrote: On Mon, Jun 22, 2015 at 10:49 PM, Andrew Fish af...@apple.commailto:af...@apple.com wrote: On Jun 22, 2015, at 10:26 PM, Radha Mohan mohun...@gmail.commailto:mohun...@gmail.com wrote: On Mon, Jun 22, 2015 at 10:19 PM, Ye, Ting ting...@intel.commailto:ting...@intel.com wrote: We use DHCP options to configure such information for PXE boot in UEFI network stack. Right, this is true when intel was the only platform..but now with other architectures coming into fray..i think there should be more flexibility.. There are lots of options for network booting in UEFI. PXE iSCSI HTTP (New in UEFI 2.5) You can produce an EFI_LOAD_FILE_PROTOCOL and boot how every you want. The only thing missing in UEFI is a standard way to boot from a hardcoded TFTP address and file. This is generally not a useful generic thing, it is more of a developer thing. So it is usually just implemented as a shell command. Or it is the boot loader that gets returned by the PXE server. PXE is most sought after way (wonder why). In a network with mix of x86 and arm servers, it would be a pain to manage pxe boot. One needs to have special rules in dhcpd config to separate out the 2 archs. I believe the present way is the TFTP server points to a netboot or pxelinux efi binary (from syslinux) and then it uses NFS to do the installation. So if this binary is arch specific it will pose a problem in multi-arch environment. Now if I want to launch a different binary I have to go edit the dhcpd.conf (only if I manage the network). I understand its kind of developer thing. But having an option for developers to enter the server and file name is a more straight case in my opinion if you are making a good software. I don’t understand you point. Having a static IP and hard coded filename in 100,000 clients or servers is a “better” solution? What happens if the static IP address of the server changes? We just moved offices and all our static IPs changed. Or if the filename needs to get changed? The HTTP boot solves a lot of problems with needing control of the DNS servers, It can require some complexity on the backend, but that complexity has known solutions (there are really popular cat videos on the internet and such). As I pointed you can make a custom BDS today that supports booting from a server with a static IP address, and TFTP filename via load file. It is not really a good scalable solution to have static IP address, and magic filenames configured in every client, so that is why it did not make it into the UEFI spec. Thanks, Andrew Fish This library can download a file from a TFTP remote using the PXE Protocols. The same way an OS loader can use UEFI services to load more info. https://svn.code.sf.net/p/edk2/code/trunk/edk2/EmbeddedPkg/Library/EfiFileLib/EfiFileLib.c Thanks, Andrew Fish Best Regards, Ye Ting -Original Message- From: Leekha Shaveta [mailto:shav...@freescale.com] Sent: Tuesday, June 23, 2015 1:15 PM To: edk2-devel@lists.sourceforge.netmailto:edk2-devel@lists.sourceforge.net Cc: Olivier Martin Subject: Re: [edk2] PXE with manual TFTP server and filename options Hi, Then how tftp and PXE boot flow works in UEFI network stack? How to provide server ip address and file to get from remote location? Thanks and Regards, Shaveta -Original Message- From: Ye, Ting [mailto:ting...@intel.com] Sent: Tuesday, June 23, 2015 8:48 AM To: edk2-devel@lists.sourceforge.netmailto:edk2-devel@lists.sourceforge.net Subject: Re: [edk2] PXE with manual TFTP server and filename options This is not supported by UEFI network stack as I known. Best Regards, Ye Ting -Original Message- From: Radha Mohan [mailto:mohun...@gmail.com] Sent: Tuesday, June 23, 2015 9:12 AM To: edk2-devel@lists.sourceforge.netmailto:edk2-devel@lists.sourceforge.net Subject: [edk2] PXE with manual TFTP server and filename options Hi, I am looking to do PXE boot with an option to manually enter a TFTP server ip address and filename from the prompt. This option can help in having a multiple installation of distros at different locations. Is this something that is already available or on the cards ? regards, Radha Mohan -- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical virtual servers, alerts via email sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk
Re: [edk2] [PATCH] BaseTools for AArch64 GCC: Ensure that the correlation .text and .data is consistent between ELF and PE-COFF so the debugger sees global variables correctly
So I am guessing it is fined to keep 0x260 used by the X64 linker script - and
so reuse the existing GCC ld script. Debuger scripts would need to be updated
to refect this change.
If I compare the results with and without Eugene's patch:
Without:
/work/gcc-linaro-4.9-2015.02-3-x86_64_arm-linux-gnueabihf/bin/arm-linux-gnueabihf-readelf
-S
Build/ArmJuno-default/DEBUG_GCC49/AARCH64/ArmPkg/Drivers/TimerDxe/TimerDxe/DEBUG/ArmTimerDxe.dll
There are 23 section headers, starting at offset 0x317a0:
Section Headers:
[Nr] Name Type Address Offset
Size EntSize Flags Link Info Align
[ 0] NULL
0 0 0
[ 1] .text PROGBITS 0001
4468 AX 0 0 8
[ 2] .rela.textRELA 00031d60
24d8 0018 21 1 8
[ 3] .rodata PROGBITS 4468 00014468
18c8 A 0 0 8
[ 4] .data PROGBITS 00015d30 00015d30
0190 WA 0 0 8
[ 5] .rela.dataRELA 00034238
0408 0018 21 4 8
[ 6] .bss NOBITS 00015ec0 00015ec0
0048 WA 0 0 8
(...)
With:
-
/work/gcc-linaro-4.9-2015.02-3-x86_64_arm-linux-gnueabihf/bin/arm-linux-gnueabihf-readelf
-S
Build/ArmJuno/DEBUG_GCC49/AARCH64/ArmPkg/Drivers/TimerDxe/TimerDxe/DEBUG/ArmTimerDxe.dll
There are 20 section headers, starting at offset 0x317b0:
Section Headers:
[Nr] Name Type Address Offset
Size EntSize Flags Link Info Align
[ 0] NULL
0 0 0
[ 1] .text PROGBITS 0001
4480 AX 0 0 8
[ 2] .rela.textRELA 00031cb0
24d8 0018 18 1 8
[ 3] .data PROGBITS 4480 00014480
1aa0 WA 0 0 8
[ 4] .rela.dataRELA 00034188
0408 0018 18 3 8
(...)
Some regions have disappeared such as .comment (ok!), but also .bss and .rodata
(which I am more concerned).
I have the impression the linker script combine these regions into .data (I
confirm the size of these 3 regions is equal to 0x1aa0). It means it would
change the PE/COFF binary. We can lose in memory protection if we decide later
to make the '.rodata' section a ReadOnly region.
I also do not understand why we have .rela.text between .text and .data
sections. I would expect this section to be present after .data if your script
was working as expected.
-Original Message-
From: Olivier Martin [mailto:olivier.mar...@arm.com]
Sent: 22 June 2015 17:43
To: Cohen, Eugene; edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] [PATCH] BaseTools for AArch64 GCC: Ensure that the
correlation .text and .data is consistent between ELF and PE-COFF so the
debugger sees global variables correctly
The text section at zero is there because GNU toolchain used to make this
section at 0x8000(? - I am not sure of the value but it was not zero).
So the debugging script would not even work for debugging the code section.
I have just checked with the latest Linaro GCC toolchain and I have not managed
to duplicate the issue. Both AArch32 and AArch64 GNU toolchains generate text
section at 0x0 by default.
-Original Message-
From: Cohen, Eugene [mailto:eug...@hp.com]
Sent: 18 June 2015 14:57
To: edk2-devel@lists.sourceforge.net; Olivier Martin
Subject: RE: [edk2] [PATCH] BaseTools for AArch64 GCC: Ensure that the
correlation .text and .data is consistent between ELF and PE-COFF so the
debugger sees global variables correctly
I would still prefer to use the existing GCC ld script if possible
instead of rolling our own. Since the existing one does not have the
64 KB gap between the RX and RW segments, and it probably also dodges
the 'Multiple sections' error.
Sure, I'm fine with that so long as it works.
So perhaps Olivier can explain where the -Ttext=0x0 comes from? It
looks like everything works fine without it ...
Olivier, do you know if the text at zero is required or can we adopt the X86
placement in BaseTools/Scripts/gcc-arm-ld-script?
Eugene
-Original Message-
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
Sent
Re: [edk2] [PATCH] BaseTools for AArch64 GCC: Ensure that the correlation .text and .data is consistent between ELF and PE-COFF so the debugger sees global variables correctly
The text section at zero is there because GNU toolchain used to make this section at 0x8000(? - I am not sure of the value but it was not zero). So the debugging script would not even work for debugging the code section. I have just checked with the latest Linaro GCC toolchain and I have not managed to duplicate the issue. Both AArch32 and AArch64 GNU toolchains generate text section at 0x0 by default. -Original Message- From: Cohen, Eugene [mailto:eug...@hp.com] Sent: 18 June 2015 14:57 To: edk2-devel@lists.sourceforge.net; Olivier Martin Subject: RE: [edk2] [PATCH] BaseTools for AArch64 GCC: Ensure that the correlation .text and .data is consistent between ELF and PE-COFF so the debugger sees global variables correctly I would still prefer to use the existing GCC ld script if possible instead of rolling our own. Since the existing one does not have the 64 KB gap between the RX and RW segments, and it probably also dodges the 'Multiple sections' error. Sure, I'm fine with that so long as it works. So perhaps Olivier can explain where the -Ttext=0x0 comes from? It looks like everything works fine without it ... Olivier, do you know if the text at zero is required or can we adopt the X86 placement in BaseTools/Scripts/gcc-arm-ld-script? Eugene -Original Message- From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] Sent: Wednesday, June 17, 2015 10:48 PM To: edk2-devel@lists.sourceforge.net Subject: Re: [edk2] [PATCH] BaseTools for AArch64 GCC: Ensure that the correlation .text and .data is consistent between ELF and PE-COFF so the debugger sees global variables correctly On 18 June 2015 at 00:01, Cohen, Eugene eug...@hp.com wrote: Thanks for the great feedback -- you made me do more homework than I was expecting which is not a bad thing. Since we understand the problem and the fix, I think it's time to get Olivier's review and approval to move forward. I would still prefer to use the existing GCC ld script if possible instead of rolling our own. Since the existing one does not have the 64 KB gap between the RX and RW segments, and it probably also dodges the 'Multiple sections' error. So perhaps Olivier can explain where the -Ttext=0x0 comes from? It looks like everything works fine without it ... -- Ard. -Original Message- From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] Sent: Tuesday, June 16, 2015 2:51 PM To: edk2-devel@lists.sourceforge.net; Olivier Martin Subject: Re: [edk2] [PATCH] BaseTools for AArch64 GCC: Ensure that the correlation .text and .data is consistent between ELF and PE-COFF so the debugger sees global variables correctly On 16 June 2015 at 22:32, Cohen, Eugene eug...@hp.com wrote: OK. so does that mean we are using a builtin linker script for AArch64? That sounds fragile to me ... Apparently we are using the builtin script. I learned that this can be queried with the -verbose switch for ld and have attached it. It includes this interesting alignment mechanism: /* Adjust the address for the data segment. We want to adjust up to the same address within the page on the next page up. */ . = ALIGN(CONSTANT (MAXPAGESIZE)) + (. (CONSTANT (MAXPAGESIZE) - 1)); MAXPAGESIZE doesn't appear to be well documented but I can see patches to ld that show this being increased to 64KB which is consistent with my objdump output before the change. So I think this is the offending line in the original script since it shifted data out in ELF even though the PE-COFF converter packed it tightly, accounting for the section alignment requirements from ELF. Could you please look at the X64 approach, and compare it to yours? It's really a question for the developer originating -Ttext=0x0 - maybe Olivier? I don't have the history on how the GCC linker configuration for edk2 came to be. Perhaps you could share some numbers or other details to get a feel for what exactly goes on here. I think I described in this in my email titled AArch64 Debugger Global Variable Correlation Issues - I gave the ELF dump showing data shifted out by 64KB. Strangely, this was shifted out not to the next 64KB aligned boundary but to 0x1 beyond the last .test/.rodata section - I'm not sure why but perhaps somebody with more GNU ld experience can figure out why. That is *precisely* what the expression above aims to achieve. It wants to preserve the relative alignment of all the sections, but make sure that there is a 64 KB aligned boundary in between so that the two regions can always be mapped with different permissions even on a 64K pagesize OS. I.e., the expression aligns to the next boundary, and then adds the unaligned fraction of ., which effectively just adds MAXPAGESIZE unless . is already 64K aligned (if I am not mistaken). This matches your observation, right? I assume MAXPAGESIZE is a build time constant for ld, so there is not a lot of wiggle room here unless we
Re: [edk2] Query UEFI : PCIE Driver for Armv8 platform
Yes, the patch is taken from source code that has been tested on x86 with EDK1.
From: Leekha Shaveta [shav...@freescale.com]
Sent: 18 June 2015 05:09
To: Olivier Martin; Laszlo Ersek
Cc: edk2-devel@lists.sourceforge.net; Andrew Fish; Ruchika Gupta
Subject: RE: [edk2] Query UEFI : PCIE Driver for Armv8 platform
Thanks for the patch Olivier!
As you said that this patch is not tested, is it taken from some tested
reference? As it’s a huge untested patch :)
Regards,
Shaveta
-Original Message-
From: Olivier Martin [mailto:olivier.mar...@arm.com]
Sent: Wednesday, June 17, 2015 9:51 PM
To: Laszlo Ersek
Cc: edk2-devel@lists.sourceforge.net; Leekha Shaveta-B20052; Andrew Fish; Gupta
Ruchika-R66431
Subject: RE: [edk2] Query UEFI : PCIE Driver for Armv8 platform
Ahah, I knew this hidden link would make some people happy!
Hmm, I think the driver was on one of my old hard disk. I have just tried to
see if I can redo the work again. It took me a couple of hours :-/ Anyway, I
sent the patch. It builds with GCC49. But as I said I have not tested it.
-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com]
Sent: 16 June 2015 20:01
To: Olivier Martin
Cc: edk2-devel@lists.sourceforge.net; Leekha Shaveta; Andrew Fish; Ruchika Gupta
Subject: Re: [edk2] Query UEFI : PCIE Driver for Armv8 platform
On 06/16/15 20:01, Olivier Martin wrote:
Sources for the E1000 EFI driver exists
The sources are for EDK1. They can be downloaded here:
http://tianocore.sourceforge.net/wiki/EDK
I think I had ported this driver to EDK2 in the past for fun - I did
not have the opportunity to test it. I do not remember to have any
difficulties to port it.
Very interesting! I wonder then why the PROEFI driver is now proprietary and
wrapped into a draconian license. (It's not even redistributable in intact
binary form IIRC.)
Do you have your edk2 port of the edk1 E1000 driver still around? That would be
a great addition to OVMF: at the moment we have a builtin virtio-net driver,
but for Windows guests, the emulated E1000 NIC seems to be the default choice.
(For example, the virtio-win driver ISO is then not needed during guest
installation, because Windows has a builtin
E1000 driver.)
iPXE does have a UEFI driver oprom for the E1000, but (a) sometimes you don't
want to use iPXE, (b) for ARM virtual machines, iPXE is not available.
QEMU already provides PCIe emulation for the virt machine type, and
ArmVirtPkg knows how to use it, so -- thinking of (upcoming?) Windows-on-ARM
guests -- an open source E1000 driver that builds as part of ArmVirtPkg would
be very cool.
Summary:
- OvmfPkg could PXE-boot off E1000 without iPXE
- ArmVirtPkg could PXE-boot off E1000 (as only E1000 option)
- some users prefer E1000 in VMs that run Windows
Thanks
Laszlo
-Original Message-
From: Leekha Shaveta [mailto:shav...@freescale.com]
Sent: 08 June 2015 07:59
To: Andrew Fish; edk2-devel@lists.sourceforge.net
Cc: Olivier Martin; Ruchika Gupta
Subject: RE: [edk2] Query UEFI : PCIE Driver for Armv8 platform
Thanks Andrew!
Is there some PCI NIC card or E1000 driver (PCI device driver) written on top
of PCI bus driver, any references?
One is Intel's e1000 driver, which is proprietary and is requested by the -D
E1000_ENABLE build flag.
I have seen in logs that some libraries are referred like:
NetLib|MdeModulePkg/Library/DxeNetLib/
IpIoLib|MdeModulePkg/Library/DxeIpIoLib/
UdpIoLib|MdeModulePkg/Library/DxeUdpIoLib/
DpcLib|MdeModulePkg/Library/DxeDpcLib/
Are these required for PCI NIC driver?
Thanks and regards,
Shaveta
-Original Message-
From: Andrew Fish [mailto:af...@apple.com]
Sent: Friday, June 05, 2015 10:50 PM
To: Leekha Shaveta-B20052
Cc: edk2-devel@lists.sourceforge.net; olivier.mar...@arm.com
Subject: Re: [edk2] Query UEFI : PCIE Driver for Armv8 platform
On Jun 5, 2015, at 4:23 AM, Leekha Shaveta shav...@freescale.com wrote:
Thanks Andrew!
Few more Doubts :
How ACPI is defining PCI resources?
What are these PCI resources and their functions? Are these resources
are like some regions in PCI Express space”
Leekha you need to think about it from the hardware point of view….
The PCI root bridge sits on the CPU bus and it produces PCI. So that PCI root
bridge has to be configured to forward transactions.
From the firmware point of view you are configuring the chip to decode memory
addresses and resources to forward them to PCI.
From an OS (or generic PCI bus driver) you are defining the resource pool
that is available to config PCI devices. So assign bus numbers, and populate
BARs.
?
As I was referring ArmJunoPkg for PCI Host Bridge implementation. And found
this ACPI configuration used:
RESOURCE_CONFIGURATION Configuration = {
{{ACPI_ADDRESS_SPACE_DESCRIPTOR, 0x2B, ACPI_ADDRESS_SPACE_TYPE_IO , 0, 0,
0, 0, 0, 0, 0},
{ACPI_ADDRESS_SPACE_DESCRIPTOR, 0x2B
Re: [edk2] today's build failures
What about removing toolchains that are not supported anymore? Like DDK3790? Or are we waiting for tools_def.txt to reach 10,000 lines (it is only 7212 lines at the moment). -Original Message- From: Gao, Liming [mailto:liming@intel.com] Sent: 17 June 2015 11:04 To: edk2-devel@lists.sourceforge.net Subject: Re: [edk2] today's build failures Scott: Thanks for this full report. For the first, this failure should exist since _DEBUG_PRINT is added in DebugLib.h. It exists for several months. No people reports it. Seemly, there is no users to use the old DDK3790 chain. So, I think you can remove this test from your validation scope. Thanks Liming -Original Message- From: Scott Duplichan [mailto:sc...@notabs.org] Sent: Wednesday, June 17, 2015 1:26 PM To: edk2-devel@lists.sourceforge.net Subject: [edk2] today's build failures Here is a Windows batch file for automating edk2 builds using different tool chains and other options. It doesn't test every valid combination and project, but its test of 416 build combinations is more thorough than what developers are doing today. https://sourceforge.net/projects/edk2developertoolsforwindows/files/Additional%20Tools/buildall/ A compressed log file for a recent edk2 revision is included. Here is a summary of build fails found in that log file: 1) build.exe -p D:\edk2build\edk2\OvmfPkg\OvmfPkgX64.dsc -b DEBUG -t DDK3790 -n 16 -a X64 -DSECURE_BOOT_ENABLE -DFD_SIZE_2MB d:\edk2build\edk2\MdePkg\Include\Library\DebugLib.h(264) : error C2010: '.' : unexpected in macro formal parameter list cause: OpensslLib.inf undefines _MSC_VER, which is needed by DebugLib.h 2) build.exe -p D:\edk2build\edk2\OvmfPkg\OvmfPkgX64.dsc -b DEBUG -t VS2005x86 -n 16 -a X64 -DSECURE_BOOT_ENABLE -DFD_SIZE_2MB d:\edk2build\edk2\OvmfPkg\Library\XenHypercallLib\X86XenHypercall.c(38) : warning C4244: 'return' : conversion from 'int' to 'BOOLEAN', possible loss of data cause: known limitation of VS2005 3) build.exe -p D:\edk2build\edk2\AppPkg\AppPkg.dsc -b DEBUG -t DDK3790 -n 16 -a X64 d:\edk2build\edk2\StdLib\LibC\Uefi\Devices\Console\daConsole.c(305) : warning C4244: '=' : conversion from 'int' to 'wchar_t', possible loss of data cause: known limitation of DDK3790 compiler 4) build.exe -p D:\edk2build\edk2\AppPkg\AppPkg.dsc -b NOOPT -t VS2010x86 -n 16 -a IA32 d:\edk2build\edk2\stdlib\bsdsocketlib\ns_addr.c(84) : warning C4706: assignment within conditional expression cause: Microsoft warning not available for gcc 5) build.exe -p D:\edk2build\edk2\AppPkg\AppPkg.dsc -b DEBUG -t VS2013x86 -n 16 -a IA32 LibGdtoa.lib(strtod.obj) : error LNK2001: unresolved external symbol __dtoui3 cause: (see 2014 discussion) 6) build.exe -p D:\edk2build\edk2\IntelFspPkg\IntelFspPkg.dsc -b DEBUG -t DDK3790 -n 16 -a IA32 LINK : fatal error LNK1000: Internal error during LIB::Search cause: bug in old tool chain? 7) build.exe -p D:\edk2build\edk2\DuetPkg\DuetPkgIA32.dsc -b DEBUG -t VS2005x86 -n 16 -a IA32 d:\edk2build\edk2\MdeModulePkg\Universal\SetupBrowserDxe\Presentation.c(1923) : warning C4244: 'return' : conversion from 'int' to 'BOOLEAN', possible loss of data cause: limitation of older Microsoft tool chains 8) build.exe -p D:\edk2build\edk2\EmulatorPkg\EmulatorPkg.dsc -b RELEASE -t VS2005x86 -n 16 -a IA32 d:\edk2build\edk2\EmulatorPkg\CpuRuntimeDxe\MpService.c(67) : warning C4244: 'return' : conversion from 'int' to 'BOOLEAN', possible loss of data cause: limitation of older Microsoft tool chains 9) build.exe -p D:\edk2build\edk2\Nt32Pkg\Nt32Pkg.dsc -b RELEASE -t VS2005x86 -n 16 -a X64 -DSECURE_BOOT_ENABLE C:\Program Files (x86)\Windows Kits\8.1\include\um\winnt.h(2935) : warning C4163: '__cpuidex' : not available as an intrinsic function cause: limitation of older Microsoft tool chains Thanks, Scott -- ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel -- ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel -- 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. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2548782 --
Re: [edk2] Query UEFI : PCIE Driver for Armv8 platform
Ahah, I knew this hidden link would make some people happy!
Hmm, I think the driver was on one of my old hard disk. I have just tried to
see if I can redo the work again. It took me a couple of hours :-/
Anyway, I sent the patch. It builds with GCC49. But as I said I have not tested
it.
-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com]
Sent: 16 June 2015 20:01
To: Olivier Martin
Cc: edk2-devel@lists.sourceforge.net; Leekha Shaveta; Andrew Fish; Ruchika Gupta
Subject: Re: [edk2] Query UEFI : PCIE Driver for Armv8 platform
On 06/16/15 20:01, Olivier Martin wrote:
Sources for the E1000 EFI driver exists
The sources are for EDK1. They can be downloaded here:
http://tianocore.sourceforge.net/wiki/EDK
I think I had ported this driver to EDK2 in the past for fun - I did
not have the opportunity to test it. I do not remember to have any
difficulties to port it.
Very interesting! I wonder then why the PROEFI driver is now proprietary and
wrapped into a draconian license. (It's not even redistributable in intact
binary form IIRC.)
Do you have your edk2 port of the edk1 E1000 driver still around? That would be
a great addition to OVMF: at the moment we have a builtin virtio-net driver,
but for Windows guests, the emulated E1000 NIC seems to be the default choice.
(For example, the virtio-win driver ISO is then not needed during guest
installation, because Windows has a builtin
E1000 driver.)
iPXE does have a UEFI driver oprom for the E1000, but (a) sometimes you don't
want to use iPXE, (b) for ARM virtual machines, iPXE is not available.
QEMU already provides PCIe emulation for the virt machine type, and
ArmVirtPkg knows how to use it, so -- thinking of (upcoming?) Windows-on-ARM
guests -- an open source E1000 driver that builds as part of ArmVirtPkg would
be very cool.
Summary:
- OvmfPkg could PXE-boot off E1000 without iPXE
- ArmVirtPkg could PXE-boot off E1000 (as only E1000 option)
- some users prefer E1000 in VMs that run Windows
Thanks
Laszlo
-Original Message-
From: Leekha Shaveta [mailto:shav...@freescale.com]
Sent: 08 June 2015 07:59
To: Andrew Fish; edk2-devel@lists.sourceforge.net
Cc: Olivier Martin; Ruchika Gupta
Subject: RE: [edk2] Query UEFI : PCIE Driver for Armv8 platform
Thanks Andrew!
Is there some PCI NIC card or E1000 driver (PCI device driver) written on top
of PCI bus driver, any references?
One is Intel's e1000 driver, which is proprietary and is requested by the -D
E1000_ENABLE build flag.
I have seen in logs that some libraries are referred like:
NetLib|MdeModulePkg/Library/DxeNetLib/
IpIoLib|MdeModulePkg/Library/DxeIpIoLib/
UdpIoLib|MdeModulePkg/Library/DxeUdpIoLib/
DpcLib|MdeModulePkg/Library/DxeDpcLib/
Are these required for PCI NIC driver?
Thanks and regards,
Shaveta
-Original Message-
From: Andrew Fish [mailto:af...@apple.com]
Sent: Friday, June 05, 2015 10:50 PM
To: Leekha Shaveta-B20052
Cc: edk2-devel@lists.sourceforge.net; olivier.mar...@arm.com
Subject: Re: [edk2] Query UEFI : PCIE Driver for Armv8 platform
On Jun 5, 2015, at 4:23 AM, Leekha Shaveta shav...@freescale.com wrote:
Thanks Andrew!
Few more Doubts :
How ACPI is defining PCI resources?
What are these PCI resources and their functions? Are these resources
are like some regions in PCI Express space”
Leekha you need to think about it from the hardware point of view….
The PCI root bridge sits on the CPU bus and it produces PCI. So that PCI root
bridge has to be configured to forward transactions.
From the firmware point of view you are configuring the chip to decode memory
addresses and resources to forward them to PCI.
From an OS (or generic PCI bus driver) you are defining the resource pool
that is available to config PCI devices. So assign bus numbers, and populate
BARs.
?
As I was referring ArmJunoPkg for PCI Host Bridge implementation. And found
this ACPI configuration used:
RESOURCE_CONFIGURATION Configuration = {
{{ACPI_ADDRESS_SPACE_DESCRIPTOR, 0x2B, ACPI_ADDRESS_SPACE_TYPE_IO , 0, 0,
0, 0, 0, 0, 0},
{ACPI_ADDRESS_SPACE_DESCRIPTOR, 0x2B, ACPI_ADDRESS_SPACE_TYPE_MEM, 0, 0,
32, 0, 0, 0, 0},
{ACPI_ADDRESS_SPACE_DESCRIPTOR, 0x2B, ACPI_ADDRESS_SPACE_TYPE_MEM, 0, 6,
32, 0, 0, 0, 0},
{ACPI_ADDRESS_SPACE_DESCRIPTOR, 0x2B, ACPI_ADDRESS_SPACE_TYPE_MEM, 0, 0,
64, 0, 0, 0, 0},
{ACPI_ADDRESS_SPACE_DESCRIPTOR, 0x2B, ACPI_ADDRESS_SPACE_TYPE_MEM, 0, 6,
64, 0, 0, 0, 0},
{ACPI_ADDRESS_SPACE_DESCRIPTOR, 0x2B, ACPI_ADDRESS_SPACE_TYPE_BUS, 0, 0,
0, 0, 255, 0, 255}},
{ACPI_END_TAG_DESCRIPTOR, 0}
};
Hi Olivier,
Can you please help in understanding this resource configuration ?
Here you seem to be specifying one IO, 4 Mem and 1 Bus space. Why 6 of them
and how do they differ?
On which basis 6 resources are given here?
These are the basic resource types supported by PCI.
I/O so the inb outb instructions on X86 (IO BAR) 32-bit Prefetch and
non
Re: [edk2] some queries in EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL implementation
From: Leekha Shaveta [mailto:shav...@freescale.com] Sent: 16 June 2015 12:59 To: edk2-devel@lists.sourceforge.net; Olivier Martin Cc: Deepak Chauhan; Konda Ravi Subject: RE: [edk2] some queries in EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL implementation Thanks Olivier! Please find my doubts and replies in-lined. Thanks and Regards, Shaveta From: Olivier Martin [mailto:olivier.mar...@arm.com] Sent: Tuesday, June 16, 2015 4:53 PM To: edk2-devel@lists.sourceforge.netmailto:edk2-devel@lists.sourceforge.net Cc: Chauhan Deepak-B10991; Theja Ravi-B11286 Subject: Re: [edk2] some queries in EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL implementation PCI bus contains three type of memory: - PCI Configuration Space - PCI I/O Space - PCI Memory Space RootBridgeIoMemWrite () writes to 'PCI Memory Space'. I would say the description matches your interpretation if you assume 'PCI controller' is the same as what you named '(PCI) devices'. [Shaveta]: True! As config space is also mapped to memory in PCI 3.0 ? and we can get same registers in memory also? [Olivier] PCI Config Space is also present in your CPU Memory Map when using PCI 3.0. Your (PCI) device is attached to a PCI root bridge (what you names as 'PCI 3.0 controller'). You can potentially have more than one PCI controller on your platform. RootBridgeIoIoRead () reads to 'PCI I/O Space'. [Shaveta] What is this PCI IO space? And how PCI controller's registers can be read from PCI IO space? [Olivier] PCI I/O space: https://en.wikipedia.org/wiki/Conventional_PCI#PCI_address_spaces PCI I/O space is not supported on ARM architectures. BAR means 'Base Address Register'. They are actually read from the PCI configuration space but they point to the different PCI I/O Mem spaces. [Shaveta] Yes in PCI 3.0, all BARs are in PCI config space. But in PCI bus implementation in MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c For example In function: EFI_STATUS EFIAPI PciIoPollIo ( IN EFI_PCI_IO_PROTOCOL*This, IN EFI_PCI_IO_PROTOCOL_WIDTH Width, IN UINT8 BarIndex, IN UINT64 Offset, IN UINT64 Mask, IN UINT64 Value, IN UINT64 Delay, OUT UINT64 *Result ) Status = PciIoIoRead (This, Width, BarIndex, Offset, 1, Result); Why PciIoIoRead is used to read the BAR ? Or is it actually reading the IO space specified in this given BAR? [Olivier] BAR represents PCI I/O or Memory space. PciIoRead() does not read the BAR but PciIoRead() uses the BAR. You have different types of BAR. BAR for I/O Space, BAR for PCI 32bit Memory, BAR for PCI 64bit prefetechable Memory, etc From: Leekha Shaveta [mailto:shav...@freescale.com] Sent: 16 June 2015 11:50 To: edk2-devel@lists.sourceforge.netmailto:edk2-devel@lists.sourceforge.net Cc: Deepak Chauhan; Konda Ravi Subject: [edk2] some queries in EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL implementation Hi, I was implementing EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL protocol for PCI 3.0 controlller, I have few more basic queries like: (1)In function: EFI_STATUS EFIAPI RootBridgeIoMemWrite ( IN EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL*This, IN EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL_WIDTH Width, IN UINT64 Address, IN UINTN Count, IN VOID *Buffer ); The description says: Enables a PCI driver to access PCI controller registers in the PCI root bridge memory space. The Mem.Read(), and Mem.Write() functions enable a driver to access PCI controller registers in the PCI root bridge memory space. What does this mean? I thought that Mem.Read/Mem.Write means reading memory space that is kept/allocated to various memory devices. But this description seems to say different. (2)Similarly Enables a PCI driver to access PCI controller registers in the PCI root bridge I/O space. For function: EFI_STATUS EFIAPI RootBridgeIoIoRead ( IN EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL*This, IN EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL_WIDTH Width, IN UINT64 UserAddress, IN UINTN Count, OUTVOID *UserBuffer ); What is this PCI root bridge I/O and Memory space? As I have seen that these Mem.Read/mem.Write and Io.Read/Io.Write functions have been used by PCI Bus driver for reading BarIndex at various stages. Aren't all BAR registers in PCI configuration space? Kindly help in clearing these doubts. Thanks and Regards, Shaveta -- 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
Re: [edk2] Query UEFI : PCIE Driver for Armv8 platform
Sources for the E1000 EFI driver exists
The sources are for EDK1. They can be downloaded here:
http://tianocore.sourceforge.net/wiki/EDK
I think I had ported this driver to EDK2 in the past for fun - I did not have
the opportunity to test it. I do not remember to have any difficulties to port
it.
-Original Message-
From: Leekha Shaveta [mailto:shav...@freescale.com]
Sent: 08 June 2015 07:59
To: Andrew Fish; edk2-devel@lists.sourceforge.net
Cc: Olivier Martin; Ruchika Gupta
Subject: RE: [edk2] Query UEFI : PCIE Driver for Armv8 platform
Thanks Andrew!
Is there some PCI NIC card or E1000 driver (PCI device driver) written on top
of PCI bus driver, any references?
One is Intel's e1000 driver, which is proprietary and is requested by the -D
E1000_ENABLE build flag.
I have seen in logs that some libraries are referred like:
NetLib|MdeModulePkg/Library/DxeNetLib/
IpIoLib|MdeModulePkg/Library/DxeIpIoLib/
UdpIoLib|MdeModulePkg/Library/DxeUdpIoLib/
DpcLib|MdeModulePkg/Library/DxeDpcLib/
Are these required for PCI NIC driver?
Thanks and regards,
Shaveta
-Original Message-
From: Andrew Fish [mailto:af...@apple.com]
Sent: Friday, June 05, 2015 10:50 PM
To: Leekha Shaveta-B20052
Cc: edk2-devel@lists.sourceforge.net; olivier.mar...@arm.com
Subject: Re: [edk2] Query UEFI : PCIE Driver for Armv8 platform
On Jun 5, 2015, at 4:23 AM, Leekha Shaveta shav...@freescale.com wrote:
Thanks Andrew!
Few more Doubts :
How ACPI is defining PCI resources?
What are these PCI resources and their functions? Are these resources
are like some regions in PCI Express space”
Leekha you need to think about it from the hardware point of view….
The PCI root bridge sits on the CPU bus and it produces PCI. So that PCI root
bridge has to be configured to forward transactions.
From the firmware point of view you are configuring the chip to decode memory
addresses and resources to forward them to PCI.
From an OS (or generic PCI bus driver) you are defining the resource pool that
is available to config PCI devices. So assign bus numbers, and populate BARs.
?
As I was referring ArmJunoPkg for PCI Host Bridge implementation. And found
this ACPI configuration used:
RESOURCE_CONFIGURATION Configuration = {
{{ACPI_ADDRESS_SPACE_DESCRIPTOR, 0x2B, ACPI_ADDRESS_SPACE_TYPE_IO , 0, 0, 0,
0, 0, 0, 0},
{ACPI_ADDRESS_SPACE_DESCRIPTOR, 0x2B, ACPI_ADDRESS_SPACE_TYPE_MEM, 0, 0,
32, 0, 0, 0, 0},
{ACPI_ADDRESS_SPACE_DESCRIPTOR, 0x2B, ACPI_ADDRESS_SPACE_TYPE_MEM, 0, 6,
32, 0, 0, 0, 0},
{ACPI_ADDRESS_SPACE_DESCRIPTOR, 0x2B, ACPI_ADDRESS_SPACE_TYPE_MEM, 0, 0,
64, 0, 0, 0, 0},
{ACPI_ADDRESS_SPACE_DESCRIPTOR, 0x2B, ACPI_ADDRESS_SPACE_TYPE_MEM, 0, 6,
64, 0, 0, 0, 0},
{ACPI_ADDRESS_SPACE_DESCRIPTOR, 0x2B, ACPI_ADDRESS_SPACE_TYPE_BUS, 0, 0,
0, 0, 255, 0, 255}},
{ACPI_END_TAG_DESCRIPTOR, 0}
};
Hi Olivier,
Can you please help in understanding this resource configuration ?
Here you seem to be specifying one IO, 4 Mem and 1 Bus space. Why 6 of them
and how do they differ?
On which basis 6 resources are given here?
These are the basic resource types supported by PCI.
I/O so the inb outb instructions on X86 (IO BAR) 32-bit Prefetch and
non-Prefetch memory (Memory BAR) 64-bit Prefetch and non-Prefetch memory
(Memory BAR) PCI Bus numbers. (Bus Number)
Thanks,
Andrew Fish
Thanks and Regards,
Shaveta
-- 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.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered
in England Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England Wales, Company No: 2548782
--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] Proposal of Git Repo Layout for EDKII project
Most EDK2 users uses MS Windows host machine GUI tool. I am not sure 'git subtree' that is not part of the default git tool fits with the EDK2 community requirements. Having a main/unique EDK2 repository is not incompatible with the inclusion of third-party/private components in your development environment. In my working tree, I have: - EDK2 as a git repository - SctPkg as a git repository - Some private platforms as separate git repository If really you want to get a set of EDK2 and third-party/private components nothing prevent you to create a branch based on 'master' that would add your external components as git submodules. -Original Message- From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] Sent: 08 June 2015 10:09 To: edk2-devel@lists.sourceforge.net Subject: Re: [edk2] Proposal of Git Repo Layout for EDKII project On 5 June 2015 at 18:59, Gao, Liming liming@intel.com wrote: Thanks for your all comments. Those gives me more concept of Git. I want to clarify my usage model. My daily work bases on internal project to develop features for external and internal packages both. So, I expect I have one git repo (one GIT URL) to get all required packages (internal and external), then base on it to pull the update, create patch, review patch, and push my changes for internal and external. I also hope I can use Git advantage usage for EDKII and my internal project. But, I find no obvious way to support this usage. Submodule is a little complex. Repo tool is not easy to be used in Windows. And, even if we use Repo tool, we still need to separate internal Package as single Repo, then combine them one by one into EDKII as my internal project. git filter-branch can split Package from EDKII Repo. But, this ways need script to update code. And, I am not sure whether I can base on filter-branch to push my changes. After compare them, I think submodule is the simplest way to support my usage model. So, I propose to separate Package as Repo, keep Package Repo as upstream Repo and EDKII Repo as read only. If Package Repo is read only, EDKII Repo is upstream Repo, it will bring a little burden for me. But, it is also an acceptable solution. Git submodules may be the simplest way to support /your/ particular use case, but I think the pushback in this thread against it comes mostly from people who have actually used git submodules, so I suggest we take those comments seriously. It seems that you are already in the situation where you need to push your changes to multiple repositories at the same time, and those repositories are not tightly coupled. I don't think this applies to many of us, so it doesn't seem fair to me to force others to adopt that mode of development while not strictly necessary. I think the subtree approach is reasonable, where we have a single read-write core EDK2 repo (probably just the existing one at GitHub) and use some automation to keep a collection of subtree mirrors in sync. As Roy has confirmed, git subtree is repeatable, i.e., it produces the exact same commit IDs when invoked several times, so the subtree repositories would be stable as well. For submitting your patches, note that git format-patch supports src-prefix and dst-prefix options, which perhaps we may use to convert your subtree patches to core patches? I haven't tried it myself but it looks promising. Last, I don't understand why GIT not smoothly supports my usage model, because it is just designed for Linux project? Git was obviously not designed for maintaining a mix of open and closed source software. Mind you, I don't think there is anything wrong with that, it just wasn't on any of the Git developers' radar. -- Ard. -Original Message- From: Roy Franz [mailto:roy.fr...@linaro.org] Sent: Friday, June 5, 2015 12:34 AM To: edk2-devel@lists.sourceforge.net Subject: Re: [edk2] Proposal of Git Repo Layout for EDKII project On Thu, Jun 4, 2015 at 8:58 AM, Brian J. Johnson bjohn...@sgi.com wrote: On 06/03/2015 08:53 PM, Jordan Justen wrote: Yet another idea that I've considered is trying to leverage git subtree. My idea was that the unified EDK II would remain the main upstream. I would setup an automated process to split each package off using git subtree, and push the separate repos. ... I never got the time to investigate if git subtree could work as required, but this text from the help page seems promising: split Extract a new, synthetic project history from the history of the prefix subtree. The new history includes only the commits (including merges) that affected prefix, and each of those commits now has the contents of prefix at the root of the project instead of in a subdirectory. Thus, the newly created history is suitable for export as a separate git repository. I experimented with git subtree a couple years ago for managing a project composed of multiple
Re: [edk2] [PATCH] ArmVirtPkg: increase memory preallocations for secure build
Reviewed-By: Olivier Martin olivier.mar...@arm.com -Original Message- From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] Sent: 16 June 2015 10:44 To: edk2-devel@lists.sourceforge.net; ler...@redhat.com Cc: Olivier Martin; roy.fr...@linaro.org; Ard Biesheuvel Subject: [PATCH] ArmVirtPkg: increase memory preallocations for secure build This is a followup to r17554 (ArmVirtPkg: increase memory preallocations to reduce region count) that increases the sizes of the preallocated regions to account for the footprint of the crypto and authentication libraries. This is only done if secure boot is enabled at build time, to prevent imposing a larger minimum RAM size on non-secure builds. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org --- ArmVirtPkg/ArmVirt.dsc.inc | 6 ++ 1 file changed, 6 insertions(+) diff --git a/ArmVirtPkg/ArmVirt.dsc.inc b/ArmVirtPkg/ArmVirt.dsc.inc index 9c737712d45f..c6e684fd8512 100644 --- a/ArmVirtPkg/ArmVirt.dsc.inc +++ b/ArmVirtPkg/ArmVirt.dsc.inc @@ -329,9 +329,15 @@ [PcdsFixedAtBuild.common] gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiACPIReclaimMemory|0 gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiACPIMemoryNVS|0 gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiReservedMemoryType|0 +!if $(SECURE_BOOT_ENABLE) == TRUE + gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiRuntimeServicesData|600 + gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiRuntimeServicesCode|400 + gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiBootServicesCode|1500 +!else gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiRuntimeServicesData|300 gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiRuntimeServicesCode|150 gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiBootServicesCode|1000 +!endif gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiBootServicesData|2 gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiLoaderCode|20 gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiLoaderData|0 -- 1.9.1 -- 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. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2548782 -- ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] some queries in EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL implementation
PCI bus contains three type of memory: - PCI Configuration Space - PCI I/O Space - PCI Memory Space RootBridgeIoMemWrite () writes to 'PCI Memory Space'. I would say the description matches your interpretation if you assume 'PCI controller' is the same as what you named '(PCI) devices'. Your (PCI) device is attached to a PCI root bridge (what you names as 'PCI 3.0 controller'). You can potentially have more than one PCI controller on your platform. RootBridgeIoIoRead () reads to 'PCI I/O Space'. BAR means 'Base Address Register'. They are actually read from the PCI configuration space but they point to the different PCI I/O Mem spaces. You have different types of BAR. BAR for I/O Space, BAR for PCI 32bit Memory, BAR for PCI 64bit prefetechable Memory, etc From: Leekha Shaveta [mailto:shav...@freescale.com] Sent: 16 June 2015 11:50 To: edk2-devel@lists.sourceforge.net Cc: Deepak Chauhan; Konda Ravi Subject: [edk2] some queries in EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL implementation Hi, I was implementing EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL protocol for PCI 3.0 controlller, I have few more basic queries like: (1)In function: EFI_STATUS EFIAPI RootBridgeIoMemWrite ( IN EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL*This, IN EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL_WIDTH Width, IN UINT64 Address, IN UINTN Count, IN VOID *Buffer ); The description says: Enables a PCI driver to access PCI controller registers in the PCI root bridge memory space. The Mem.Read(), and Mem.Write() functions enable a driver to access PCI controller registers in the PCI root bridge memory space. What does this mean? I thought that Mem.Read/Mem.Write means reading memory space that is kept/allocated to various memory devices. But this description seems to say different. (2)Similarly Enables a PCI driver to access PCI controller registers in the PCI root bridge I/O space. For function: EFI_STATUS EFIAPI RootBridgeIoIoRead ( IN EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL*This, IN EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL_WIDTH Width, IN UINT64 UserAddress, IN UINTN Count, OUTVOID *UserBuffer ); What is this PCI root bridge I/O and Memory space? As I have seen that these Mem.Read/mem.Write and Io.Read/Io.Write functions have been used by PCI Bus driver for reading BarIndex at various stages. Aren't all BAR registers in PCI configuration space? Kindly help in clearing these doubts. Thanks and Regards, Shaveta -- 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. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2548782 -- ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] AARCH64: Timer Dxe
Sorry for the delay I was on holiday. 1. PPI and SGI are registered in the same way. 2. Juno Rev1 support is upstream (ArmPlatformPkg/ArmJunoPkg). It uses ARMv8 Generic Timer and BootDelay works. If it does not work I am guessing it is due to some security misconfiguration. You Secure World (likely to be ARM Trusted Firmware) should configure your timer interrupt as Non-Secure. -Original Message- From: Sharma Bhupesh [mailto:bhupesh.sha...@freescale.com] Sent: 10 June 2015 11:31 To: edk2-devel@lists.sourceforge.net; Olivier Martin Subject: AARCH64: Timer Dxe Hi Olivier, 1. I am looking at the 'ArmPkg/Drivers/TimerDxe/TimerDxe.c' DXE driver and seeing how the timer interrupts are registered: // Install secure and Non-secure interrupt handlers // Note: Because it is not possible to determine the security state of the // CPU dynamically, we just install interrupt handler for both sec and non-sec // timer PPI Status = gInterrupt-RegisterInterruptSource (gInterrupt, PcdGet32 (PcdArmArchTimerVirtIntrNum), TimerInterruptHandler); ASSERT_EFI_ERROR (Status); Status = gInterrupt-RegisterInterruptSource (gInterrupt, PcdGet32 (PcdArmArchTimerHypIntrNum), TimerInterruptHandler); ASSERT_EFI_ERROR (Status); Status = gInterrupt-RegisterInterruptSource (gInterrupt, PcdGet32 (PcdArmArchTimerSecIntrNum), TimerInterruptHandler); ASSERT_EFI_ERROR (Status); Status = gInterrupt-RegisterInterruptSource (gInterrupt, PcdGet32 (PcdArmArchTimerIntrNum), TimerInterruptHandler); ASSERT_EFI_ERROR (Status); I wanted to understand how the Interrupt registration changes for PPI or SPI interrupt sources. As usually the Virtual, Hypervisor, Physical and Physical Non-Secure interrupts are PPI does the PPI number need to be defined as the PCD values in the same way as linux. The Linux gicv3 documentation says (Documentation/devicetree/bindings/arm/gic-v3.txt): SPI interrupts are in the range [0-987]. PPI interrupts are in the range [0-15]. 2. Also one related question is whether on Juno Rev1, you are able to get the BootDelay to work via timer based events? If yes, can you please share if you achieve this by using the ARMv8 generic timer or the SP804 timer. Regards, Bhupesh -- 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. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2548782 -- ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] SCT build error
I am wondering if it is the space in C:\Program Files (x86)\Microsoft Visual Studio 12.0\Vc\bin\nmake.exe that creates the confusion. This command line might work better: C:\Program Files (x86)\Microsoft Visual Studio 12.0\Vc\bin\nmake.exe /no logo tbuild From: Meenakshi Aggarwal [mailto:meenakshi.aggar...@freescale.com] Sent: 11 June 2015 12:31 To: edk2-devel@lists.sourceforge.net Subject: [edk2] SCT build error Hi All, I am trying to build SCT and facing following error: : error 7000: Failed to start command C:\Program Files (x86)\Microsoft Visual Studio 12.0\Vc\bin\nmake.exe /no logo tbuild [c:\test\Build\UefiSct\DEBUG_VS2013x86\X64\EdkCompatibilityPkg\Foundation\Efi\Protocol\EfiProtocolLib] Any idea will be of great help. Thanks regards Meenakshi Aggarwal -- 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. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2548782 -- ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] [PATCH 2/2] Maintainers.txt: Assigned new maintainers for ArmVirtPkg
My plan is actually to move all the ARM related wikipages from sourceforge wiki to EDK2 SVN repository using the markdown format (http://en.wikipedia.org/wiki/Markdown). The idea is: - Avoid to duplicate information (we could potentially merge the Sourceforge wiki, Linaro wiki and other sources) - Easy to write maintain - everyone can contribute. They only need to send a patch for the documentation - Forcing the documentation by rejecting a patch because it would require some documentation. -Original Message- From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] Sent: 29 May 2015 07:34 To: Laszlo Ersek Cc: Olivier Martin; edk2-devel@lists.sourceforge.net Subject: Re: [PATCH 2/2] Maintainers.txt: Assigned new maintainers for ArmVirtPkg On 29 May 2015 at 00:35, Laszlo Ersek ler...@redhat.com wrote: On 05/28/15 18:01, Ard Biesheuvel wrote: On 28 May 2015 at 17:40, Olivier Martin olivier.mar...@arm.com wrote: Added Laszlo Ersek and Ard Biesheuvel as maintainers for ArmVirtPkg. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Olivier Martin olivier.mar...@arm.com Thanks for the confidence. Reviewed-by: Ard Biesheuvel ard.biesheu...@linaro.org The wiki page doesn't exist yet (obviously), but the link also does not redirect to an empty placeholder page. I pushed an initial, minimal, article. That looks fine, thanks. IMO there is not necessarily a need to inflate it with duplicated info from the Linaro wiki. Thanks, Ard. Who is in charge of assigning edit permissions etc? --- Maintainers.txt | 5 + 1 file changed, 5 insertions(+) diff --git a/Maintainers.txt b/Maintainers.txt index 1ec28e8..160decd 100644 --- a/Maintainers.txt +++ b/Maintainers.txt @@ -58,6 +58,11 @@ ArmPlatformPkg W: https://github.com/tianocore/tianocore.github.io/wiki/ArmPlatformPkg M: Olivier Martin olivier.mar...@arm.com +ArmVirtPkg +W: https://github.com/tianocore/tianocore.github.io/wiki/ArmVirtPkg +M: Laszlo Ersek ler...@redhat.com +M: Ard Biesheuvel ard.biesheu...@linaro.org + BaseTools W: https://github.com/tianocore/tianocore.github.io/wiki/BaseTools M: Yingke D Liu yingke.d@intel.com -- 2.1.1 -- 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. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2548782 -- ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
[edk2] [PATCH] Add a co-maintainer for the ARM packages
Leif Lindholm will help me to review and commit the ARM-related patches. Leif Lindholm is an ARM Ltd assignee to Linaro. It means he is an ARM Ltd employee fully committed to Linaro. We actually seat next to each other that might help for the patch review. This change will be effective after: - Leif will accept this changed by adding his 'Reviewed-By' - I will submit the change in SVN I will actually be on holiday for the next 2 weeks. Olivier Martin (1): Maintainers.txt: Added Leif Lindholm as a co-maintainer Maintainers.txt | 5 + 1 file changed, 5 insertions(+) -- 2.1.1 -- ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
[edk2] [PATCH] Maintainers.txt: Added Leif Lindholm as a co-maintainer
Leif becomes a co-maintainer for the ARM Packages. Change-Id: Ia5380dabb993ab262285aed2c9ac12bfc19c2697 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Olivier Martin olivier.mar...@arm.com --- Maintainers.txt | 5 + 1 file changed, 5 insertions(+) diff --git a/Maintainers.txt b/Maintainers.txt index 160decd..cb4c2a7 100644 --- a/Maintainers.txt +++ b/Maintainers.txt @@ -53,10 +53,12 @@ M: Daryl Mcdaniel daryl.mcdan...@intel.com ArmPkg W: https://github.com/tianocore/tianocore.github.io/wiki/ArmPkg M: Olivier Martin olivier.mar...@arm.com +M: Leif Lindholm leif.lindh...@linaro.org ArmPlatformPkg W: https://github.com/tianocore/tianocore.github.io/wiki/ArmPlatformPkg M: Olivier Martin olivier.mar...@arm.com +M: Leif Lindholm leif.lindh...@linaro.org ArmVirtPkg W: https://github.com/tianocore/tianocore.github.io/wiki/ArmVirtPkg @@ -70,6 +72,7 @@ M: Yingke D Liu yingke.d@intel.com BeagleBoardPkg W: https://github.com/tianocore/tianocore.github.io/wiki/BeagleBoardPkg M: Olivier Martin olivier.mar...@arm.com +M: Leif Lindholm leif.lindh...@linaro.org CorebootModulePkg, CorebootPayloadPkg W: https://github.com/tianocore/tianocore.github.io/wiki/Coreboot_UEFI_payload @@ -98,6 +101,7 @@ S: Obsolete (Use ShellPkg ShellBinPkg instead) EmbeddedPkg W: https://github.com/tianocore/tianocore.github.io/wiki/EmbeddedPkg M: Olivier Martin olivier.mar...@arm.com +M: Leif Lindholm leif.lindh...@linaro.org EmulatorPkg W: https://github.com/tianocore/tianocore.github.io/wiki/EmulatorPkg @@ -146,6 +150,7 @@ M: Ruiyu Ni ruiyu...@intel.com Omap35xxPkg W: https://github.com/tianocore/tianocore.github.io/wiki/Omap35xxPkg M: Olivier Martin olivier.mar...@arm.com +M: Leif Lindholm leif.lindh...@linaro.org OptionRomPkg W: https://github.com/tianocore/tianocore.github.io/wiki/OptionRomPkg -- 2.1.1 -- ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] [PATCH] ArmPlatformPkg: Fix boot on FVP with ArmPlatformPkg SEC at EL3
For the community information, I commented Eugene's patch into Github (https://github.com/tianocore/edk2/pull/10) 3 days ago. As I told Eugene there is no chance his pull-request would be accepted as EDK2 project is not supported through github. But once I would be happy with his patch I would be happy to commit them into SVN. To come back on the current discussion about code review. Github is not the prefect tool to review patches because it is difficult to compare changes between pull-request (or at least it was not last time I tried). But email code review is not better on this point neither. And Gerrit do it pretty well. From: Cohen, Eugene [mailto:eug...@hp.com] Sent: 16 May 2015 16:03 To: edk2-devel@lists.sourceforge.net Subject: [edk2] [PATCH] ArmPlatformPkg: Fix boot on FVP with ArmPlatformPkg SEC at EL3 Olivier (or if you prefer Dear ArmPkg and ArmPlatformPkg maintainer), Here are three patches (in addition to the one I sent earlier) to fix issues I encountered booting the FVP Base platform using SEC from ArmPlatformPkg instead of Trusted Firmware. This boot path is still one where SEC runs at EL3 and the remaining boot stages run at EL2/EL1. As a preface to these patch sets I should add that I'm unclear about the structure of the ARM platforms. From a directory naming perspective I see an ArmVExpressPkg which supports an FVP-AArch64 platform but I don't know whether this platform is intended to support both the FVP_Base platforms as well as the FVP_VE (Versatile Express) platforms. There are significant differences between these platforms, for example the GIC revision, the memory maps and peripherals are all different. As such it's not clear whether I'm making changes in the right place but that being said I am able to boot to the EFI Shell after these few fixes. Olivier, please advise what the proper way is to handle Versatile Express and Base platform differences. The fixes break down as follows: 1. The intent on the FVP is to use main memory at 0x88000 but a PCD value causes PEI and the DXE core to be loaded at a a sub-4GB address. This patch brings all of the DRAM usage into the same area. 2. The architectural timer was not advancing because the FVP Reference Counter, which feeds the processor's timer, must be started by EL3 firmware on the FVP Base platforms 3. Interrupts were not being delivered to the core because EL3 firmware must clear the ProcessorSleep bit in the GICv3 redistributor. I've been trying to use the github development model for this so I've created a pull request with these changes for your convenience: https://github.com/tianocore/edk2/pull/10 . This tool has a significantly better code review capability than what is possible on a mailing list. (My next efforts will be around extending EL3 into DXE to support SMM-style initialization but that's a future subject.) Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Eugene Cohen eug...@hp.commailto:eug...@hp.com -- 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. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2548782 -- ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] [PATCH 1/7] ArmPkg: reduce sysreg access count in GIC revision probe
Reviewed-By: Olivier Martin olivier.mar...@arm.com
On 29/05/15 13:33, Ard Biesheuvel wrote:
Accesses to system registers are disproportionately heavy-weight
when executed under virtualization, since each one involves two
world switches (from guest to host and back again).
So change the sequence that enables the GIC SRE interface so that
it performs only a single sysreg read to test whether the SRE
interface is enabled already, and only performs a write and an
additional read if that turns out not to be the case.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
ArmPkg/Drivers/ArmGic/AArch64/ArmGicArchLib.c | 10 --
ArmPkg/Drivers/ArmGic/Arm/ArmGicArchLib.c | 10 --
2 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/ArmPkg/Drivers/ArmGic/AArch64/ArmGicArchLib.c
b/ArmPkg/Drivers/ArmGic/AArch64/ArmGicArchLib.c
index 9da69b2131e3..88fa4621e613 100644
--- a/ArmPkg/Drivers/ArmGic/AArch64/ArmGicArchLib.c
+++ b/ArmPkg/Drivers/ArmGic/AArch64/ArmGicArchLib.c
@@ -23,6 +23,8 @@ ArmGicGetSupportedArchRevision (
VOID
)
{
+ UINT32IccSre;
+
// Ideally we would like to use the GICC IIDR Architecture version here,
but
// this does not seem to be very reliable as the implementation could
easily
// get it wrong. It is more reliable to check if the GICv3 System Register
@@ -37,8 +39,12 @@ ArmGicGetSupportedArchRevision (
// Note: We do not need to set ICC_SRE_EL2.Enable because the OS is
started
// at the same exception level.
// It is the OS responsibility to set this bit.
-ArmGicV3SetControlSystemRegisterEnable
(ArmGicV3GetControlSystemRegisterEnable () | ICC_SRE_EL2_SRE);
-if (ArmGicV3GetControlSystemRegisterEnable () ICC_SRE_EL2_SRE) {
+IccSre = ArmGicV3GetControlSystemRegisterEnable ();
+if (!(IccSre ICC_SRE_EL2_SRE)) {
+ ArmGicV3SetControlSystemRegisterEnable (IccSre | ICC_SRE_EL2_SRE);
+ IccSre = ArmGicV3GetControlSystemRegisterEnable ();
+}
+if (IccSre ICC_SRE_EL2_SRE) {
return ARM_GIC_ARCH_REVISION_3;
}
}
diff --git a/ArmPkg/Drivers/ArmGic/Arm/ArmGicArchLib.c
b/ArmPkg/Drivers/ArmGic/Arm/ArmGicArchLib.c
index f360a405833d..9ef56efeaa7b 100644
--- a/ArmPkg/Drivers/ArmGic/Arm/ArmGicArchLib.c
+++ b/ArmPkg/Drivers/ArmGic/Arm/ArmGicArchLib.c
@@ -23,6 +23,8 @@ ArmGicGetSupportedArchRevision (
VOID
)
{
+ UINT32IccSre;
+
// Ideally we would like to use the GICC IIDR Architecture version here,
but
// this does not seem to be very reliable as the implementation could
easily
// get it wrong. It is more reliable to check if the GICv3 System Register
@@ -37,8 +39,12 @@ ArmGicGetSupportedArchRevision (
// Note: We do not need to set ICC_SRE_EL2.Enable because the OS is
started
// at the same exception level.
// It is the OS responsibility to set this bit.
-ArmGicV3SetControlSystemRegisterEnable
(ArmGicV3GetControlSystemRegisterEnable () | ICC_SRE_EL2_SRE);
-if (ArmGicV3GetControlSystemRegisterEnable () ICC_SRE_EL2_SRE) {
+IccSre = ArmGicV3GetControlSystemRegisterEnable ();
+if (!(IccSre ICC_SRE_EL2_SRE)) {
+ ArmGicV3SetControlSystemRegisterEnable (IccSre| ICC_SRE_EL2_SRE);
+ IccSre = ArmGicV3GetControlSystemRegisterEnable ();
+}
+if (IccSre ICC_SRE_EL2_SRE) {
return ARM_GIC_ARCH_REVISION_3;
}
}
-- 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.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered
in England Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England Wales, Company No: 2548782
--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
