Re: [edk2] [Patch 2/3] OvmfPkg: use new BDS and UiApp in MdeModulePkg
comments below
On 08/03/15 07:41, Ruiyu Ni wrote:
Compare to the old BDS, the new BDS separates the UI part to a standalone
application UiApp.
QemuBootOrderLib was changed to depend on the UefiBootManagerLib.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni ruiyu...@intel.com
Cc: Jordan Justen jordan.l.jus...@intel.com
Cc: Laszlo Ersek ler...@redhat.com
---
.../Library/PlatformBootManagerLib/BdsPlatform.c | 1438
.../Library/PlatformBootManagerLib/BdsPlatform.h | 246
.../Library/PlatformBootManagerLib/MemoryTest.c| 450 ++
.../PlatformBootManagerLib.inf | 80 ++
.../Library/PlatformBootManagerLib/PlatformData.c | 35 +
.../Library/PlatformBootManagerLib/QemuKernel.c| 170 +++
OvmfPkg/Library/PlatformBootManagerLib/QuietBoot.c | 673 +
OvmfPkg/Library/PlatformBootManagerLib/Strings.uni | Bin 0 - 3658 bytes
.../Library/QemuBootOrderLib/QemuBootOrderLib.c| 355 +++--
.../Library/QemuBootOrderLib/QemuBootOrderLib.inf |4 +-
OvmfPkg/OvmfPkg.dec|5 +-
OvmfPkg/OvmfPkgIa32.dsc| 28 +-
OvmfPkg/OvmfPkgIa32.fdf|3 +-
OvmfPkg/OvmfPkgIa32X64.dsc | 30 +-
OvmfPkg/OvmfPkgIa32X64.fdf |3 +-
OvmfPkg/OvmfPkgX64.dsc | 28 +-
OvmfPkg/OvmfPkgX64.fdf |3 +-
17 files changed, 3389 insertions(+), 162 deletions(-)
create mode 100644 OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
create mode 100644 OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.h
create mode 100644 OvmfPkg/Library/PlatformBootManagerLib/MemoryTest.c
create mode 100644
OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
create mode 100644 OvmfPkg/Library/PlatformBootManagerLib/PlatformData.c
create mode 100644 OvmfPkg/Library/PlatformBootManagerLib/QemuKernel.c
create mode 100644 OvmfPkg/Library/PlatformBootManagerLib/QuietBoot.c
create mode 100644 OvmfPkg/Library/PlatformBootManagerLib/Strings.uni
(quoting hunks out of context -- it's easier to review the patch like this.)
diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
index 4cb70dc..47232e6 100644
--- a/OvmfPkg/OvmfPkg.dec
+++ b/OvmfPkg/OvmfPkg.dec
@@ -1,7 +1,7 @@
## @file
# EFI/Framework Open Virtual Machine Firmware (OVMF) platform
#
-# Copyright (c) 2006 - 2013, Intel Corporation. All rights reserved.BR
+# Copyright (c) 2006 - 2015, Intel Corporation. All rights reserved.BR
#
# This program and the accompanying materials
# are licensed and made available under the terms and conditions of the BSD
License
@@ -106,6 +106,9 @@
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfLockBoxStorageBase|0x0|UINT32|0x18
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfLockBoxStorageSize|0x0|UINT32|0x19
gUefiOvmfPkgTokenSpaceGuid.PcdGuidedExtractHandlerTableSize|0x0|UINT32|0x1a
+ ## This PCD points to the file name GUID of the UEFI Shell
+ # Platform can customize the PCD to point to old EDK Shell
+ gUefiOvmfPkgTokenSpaceGuid.PcdShellFile|{ 0x83, 0xA5, 0x04, 0x7C, 0x3E,
0x9E, 0x1C, 0x4F, 0xAD, 0x65, 0xE0, 0x52, 0x68, 0xD0, 0xB4, 0xD1 }|VOID*|0x1e
(1) Can you please use 0x22 as the token value here, instead of 0x1e? I
agree that 0x1e appears free when you look at the dec file right now,
but my SMM series (posted a few weeks back) closes the 0x1e..0x20 gap
(inclusive), and the next available token is 0x22.
Other than that, this GUID seems okay, it matches our setting of
gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdShellFile (which is being
removed in this patch).
[PcdsDynamic, PcdsDynamicEx]
gUefiOvmfPkgTokenSpaceGuid.PcdEmuVariableEvent|0|UINT64|2
diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index 2bfc7aa..87d3a85 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -70,7 +70,7 @@
(2) Please configure git so that it includes section names in hunk
headers. Please see
http://thread.gmane.org/gmane.comp.bios.tianocore.devel/15486.
In my local tree, I can see that this change affects the common
[LibraryClasses] section.
UefiDecompressLib|MdePkg/Library/BaseUefiDecompressLib/BaseUefiDecompressLib.inf
UefiHiiServicesLib|MdeModulePkg/Library/UefiHiiServicesLib/UefiHiiServicesLib.inf
HiiLib|MdeModulePkg/Library/UefiHiiLib/UefiHiiLib.inf
-
GenericBdsLib|IntelFrameworkModulePkg/Library/GenericBdsLib/GenericBdsLib.inf
+
UefiBootManagerLib|MdeModulePkg/Library/UefiBootManagerLib/UefiBootManagerLib.inf
Aha, okay. So I'll have to compare the APIs called *from* OVMF between
these two.
CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibNull/DxeCapsuleLibNull.inf
DxeServicesLib|MdePkg/Library/DxeServicesLib/DxeServicesLib.inf
DxeServicesTableLib|MdePkg/Library/DxeServicesTableLib/DxeServicesTableLib.inf
@@ -114,6 +114,7 @@
[edk2] [PATCH v2 2/2] ArmPlatformPkg: PL061: fix accessing gpio value
The way of accessing PL061 GPIODATA register is wrong.
The spec said in below.
In order to write to GPIODATA, the corresponding bits in the mask,
resulting from the address bus, PADDR[9:2], must be HIGH. Otherwise
the bit values remain unchanged by the write.
Similarly, the values read from this register are determined for
each bit, by the mask bit derived from the address used to access
the data register, PADDR[9:2]. Bits that are 1 in the address mask
cause the corresponding bits in GPIODATA to be read, and bits that
are 0 in the address mask cause the corresponding bits in GPIODATA
to be read as 0, regardless of their value.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Haojian Zhuang haojian.zhu...@linaro.org
---
ArmPlatformPkg/Drivers/PL061GpioDxe/PL061Gpio.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/ArmPlatformPkg/Drivers/PL061GpioDxe/PL061Gpio.c
b/ArmPlatformPkg/Drivers/PL061GpioDxe/PL061Gpio.c
index ff05662..35418c9 100644
--- a/ArmPlatformPkg/Drivers/PL061GpioDxe/PL061Gpio.c
+++ b/ArmPlatformPkg/Drivers/PL061GpioDxe/PL061Gpio.c
@@ -125,7 +125,7 @@ Get (
}
}
- if (MmioRead8 (PL061_GPIO_DATA_REG) GPIO_PIN_MASK_HIGH_8BIT(Gpio)) {
+ if (MmioRead8 (PL061_GPIO_DATA_REG + (GPIO_PIN_MASK_HIGH_8BIT(Gpio) 2))) {
*Value = 1;
} else {
*Value = 0;
@@ -186,14 +186,14 @@ Set (
case GPIO_MODE_OUTPUT_0:
// Set the corresponding data bit to LOW for 0
- MmioAnd8 (PL061_GPIO_DATA_REG, GPIO_PIN_MASK_LOW_8BIT(Gpio));
+ MmioAnd8 (PL061_GPIO_DATA_REG + (GPIO_PIN_MASK_HIGH_8BIT(Gpio) 2),
GPIO_PIN_MASK_LOW_8BIT(Gpio));
// Set the corresponding direction bit to HIGH for output
MmioOr8 (PL061_GPIO_DIR_REG, GPIO_PIN_MASK_HIGH_8BIT(Gpio));
break;
case GPIO_MODE_OUTPUT_1:
// Set the corresponding data bit to HIGH for 1
- MmioOr8 (PL061_GPIO_DATA_REG, GPIO_PIN_MASK_HIGH_8BIT(Gpio));
+ MmioOr8 (PL061_GPIO_DATA_REG + (GPIO_PIN_MASK_HIGH_8BIT(Gpio) 2),
GPIO_PIN_MASK_HIGH_8BIT(Gpio));
// Set the corresponding direction bit to HIGH for output
MmioOr8 (PL061_GPIO_DIR_REG, GPIO_PIN_MASK_HIGH_8BIT(Gpio));
break;
--
2.1.4
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] ArmPlatformPkg: PL061: fix accessing gpio value
On Tue, 2015-08-11 at 09:42 +0200, Ard Biesheuvel wrote:
On 11 August 2015 at 09:11, Haojian Zhuang haojian.zhu...@linaro.org wrote:
The way of accessing PL061 GPIODATA register is wrong.
The spec said in below.
In order to write to GPIODATA, the corresponding bits in the mask,
resulting from the address bus, PADDR[9:2], must be HIGH. Otherwise
the bit values remain unchanged by the write.
Similarly, the values read from this register are determined for
each bit, by the mask bit derived from the address used to access
the data register, PADDR[9:2]. Bits that are 1 in the address mask
cause the corresponding bits in GPIODATA to be read, and bits that
are 0 in the address mask cause the corresponding bits in GPIODATA
to be read as 0, regardless of their value.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Haojian Zhuang haojian.zhu...@linaro.org
---
ArmPlatformPkg/Drivers/PL061GpioDxe/PL061Gpio.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/ArmPlatformPkg/Drivers/PL061GpioDxe/PL061Gpio.c
b/ArmPlatformPkg/Drivers/PL061GpioDxe/PL061Gpio.c
index ff05662..35418c9 100644
--- a/ArmPlatformPkg/Drivers/PL061GpioDxe/PL061Gpio.c
+++ b/ArmPlatformPkg/Drivers/PL061GpioDxe/PL061Gpio.c
@@ -125,7 +125,7 @@ Get (
}
}
- if (MmioRead8 (PL061_GPIO_DATA_REG) GPIO_PIN_MASK_HIGH_8BIT(Gpio)) {
+ if (MmioRead8 (PL061_GPIO_DATA_REG + (GPIO_PIN_MASK_HIGH_8BIT(Gpio)
2))) {
Hello Haojian,
I have not looked at the PL061 spec, but I noticed a pretty awful bug
in the PL061 header (ArmPlatformPkg/Include/Drivers/PL061Gpio.h):
50:#define GPIO_PIN_MASK_HIGH_8BIT(Pin)(GPIO_PIN_MASK(Pin) 0xFF)
52:#define GPIO_PIN_MASK_LOW_8BIT(Pin) ((~GPIO_PIN_MASK(Pin)) 0xFF)
I am pretty sure that the is incorrect here, since the result of
the expression can only be 0 or 1 then.
Could you perhaps fix this first, and only then figure out what you
need to get the code to work for your hardware? It looks like you are
using some kind of bit banding interface, whereas the existing code
reads/writes all GPIO values from offset 0x0 and performs its own
masking. Perhaps your approach is better, but I'd like to fix first
and then optimize.
Thanks,
Ard.
Actually this patch tried to fix both gpio input gpio output. In my
previous test, I only tested gpio input (MmioRead8()) above.
Yes, I need to replace symbol by symbol. Otherwise, my patch
can't make gpio output working well.
Since the original code is also trying to update one bit value in gpio
register, my patch is just used to make it work as expected.
Regards
Haojian
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Question about memory reservation from PrePi to DXE
Thanks a lot Andrew for the followup! I'll make a few comments: On 08/10/15 23:38, Andrew Fish wrote: On Aug 10, 2015, at 1:51 PM, Benjamin Herrenschmidt b...@kernel.crashing.org mailto:b...@kernel.crashing.org wrote: On Mon, 2015-08-10 at 20:14 +0200, Laszlo Ersek wrote: On 08/10/15 18:46, Andrew Fish wrote: Essentially, I am on a platform/architecture which feeds a flat device-tree to EDK and I need to honor the input reserved regions as they cover bits of memory either already used by the HW for various reasons or are occupied with another firmware that I'm not yet ready to kill :-) You can’t pass in an allocation, so you can only control things from the GCD point of view. See CoreInitializeMemoryServices() in https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Dxe/Gcd/Gcd.c And that is done via resource descriptor HOBs, so you can make a reserved range, or not tell the DXE core that that address range is in memory. If you want to pre-allocate a specific range with a specific EFI memory type you may need to add a DXE driver that runs 1st I'm confused. Sorry I was confusing! What is BuildMemoryAllocationHob() / EFI_HOB_TYPE_MEMORY_ALLOCATION good for, if not for passing in a memory allocation at a fixed address from PEI to DXE? Yes EFI_HOB_TYPE_MEMORY_ALLOCATION should work. I was concerned about overlaps not being covered by I realized that case should be handled. For example the DXE IPL does BuildModuleHob() for the DXE Core, and that creates a EFI_HOB_TYPE_MEMORY_ALLOCATION HOB of type EfiBootServicesCode. From a PEI perspective AllocatePages, allocates memory that is handed off to DXE, and AllocatePool allocates memory that is thrown away in DXE. Yes, we're aware of that for example in ArmVirtPkg/Library/PlatformPeiLib. It relocates the initial DTB that QEMU places initially at the zero address. The module depends on gEfiPeiMemoryDiscoveredPpiGuid (ie. permanent PEI RAM being available) and grabs the new home for the DTB with AllocatePages(). (Which ends up in PeiAllocatePages() - CoreInitializeMemoryServices() indeed doesn't look at EFI_HOB_TYPE_MEMORY_ALLOCATION, but CoreInitializeGcdServices() does, and it's called by the DXE core right after. - The PI spec's description of EFI_HOB_TYPE_MEMORY_ALLOCATION seems to imply to me that this HOB type exists exactly for pre-allocating memory during PEI. - The comments in CoreInitializeGcdServices() -- the function that traverses EFI_HOB_TYPE_MEMORY_ALLOCATION HOBs -- say, // // Walk the HOB list and allocate all memory space that is consumed by // memory allocation HOBs, and Firmware Volume HOBs. Also update the // EFI Memory Map with the memory allocation HOBs. // and later // // Add and allocate the remaining unallocated system memory to the // memory services. // If EFI_HOB_TYPE_MEMORY_ALLOCATION, without a specific AllocDescriptor GUID, cannot be used for passing a memory allocation at a fixed address from PEI to DXE, with a particular EFI_MEMORY_TYPE, then - Why does it exist? - Why does the PI spec say, The HOB consumer phase reads all memory allocation HOBs and allocates memory into the system memory map based on the following fields of EFI_HOB_MEMORY_ALLOCATION_HEADER of each memory allocation HOB: * MemoryBaseAddress * MemoryLength * MemoryType - Why does CoreInitializeGcdServices() implement the following algorithm: * for each memalloc HOB, look up the containing GCD range * in the GCD memory space map, flip the covered sub-range to allocated * if the GCD memory type that the range is being carved out of is System Memory or More Reliable, add the range to the UEFI memmap too ? ... I grepped the tree for BuildMemoryAllocationHob(). Aside from ArmVirtPkg and OvmfPkg, at least the following SEC PEI modules use it in the above sense, apparently: - BeagleBoardPkg/Sec/Cache.c: covers the ARM MMU translation table with EfiBootServicesData - CorebootModulePkg/CbSupportPei/CbSupportPei.c: covers the Coreboot payload FD (ie. itself) with EfiBootServicesData - UefiCpuPkg/CpuMpPei/CpuMpPei.c: allocates the wake up buffer by manually searching the memory resource descriptor HOBs for a suitably low big one, and covering part of it with an EfiBootServicesData memalloc HOB. Are these all wrong? (Or am I misunderstanding all of them?) I though the same thing but I can't see how anything prevents the few allocations done between CoreInitializeMemoryServices() and CoreInitializeGcdServices() from overwriting any of those reservations. It looks like by default, CoreInitializeMemoryServices() will use the remaining free space in the PHIT which will be fine, but it has the potential of going elsewhere for that initial memory pool, and when that happens, anything in the resource descriptors appears to be game”. But if you had a real PEI core then the PHIT info would
[edk2] [PATCH] ArmPlatformPkg: PL061: fix accessing gpio value
The way of accessing PL061 GPIODATA register is wrong.
The spec said in below.
In order to write to GPIODATA, the corresponding bits in the mask,
resulting from the address bus, PADDR[9:2], must be HIGH. Otherwise
the bit values remain unchanged by the write.
Similarly, the values read from this register are determined for
each bit, by the mask bit derived from the address used to access
the data register, PADDR[9:2]. Bits that are 1 in the address mask
cause the corresponding bits in GPIODATA to be read, and bits that
are 0 in the address mask cause the corresponding bits in GPIODATA
to be read as 0, regardless of their value.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Haojian Zhuang haojian.zhu...@linaro.org
---
ArmPlatformPkg/Drivers/PL061GpioDxe/PL061Gpio.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/ArmPlatformPkg/Drivers/PL061GpioDxe/PL061Gpio.c
b/ArmPlatformPkg/Drivers/PL061GpioDxe/PL061Gpio.c
index ff05662..35418c9 100644
--- a/ArmPlatformPkg/Drivers/PL061GpioDxe/PL061Gpio.c
+++ b/ArmPlatformPkg/Drivers/PL061GpioDxe/PL061Gpio.c
@@ -125,7 +125,7 @@ Get (
}
}
- if (MmioRead8 (PL061_GPIO_DATA_REG) GPIO_PIN_MASK_HIGH_8BIT(Gpio)) {
+ if (MmioRead8 (PL061_GPIO_DATA_REG + (GPIO_PIN_MASK_HIGH_8BIT(Gpio) 2))) {
*Value = 1;
} else {
*Value = 0;
@@ -186,14 +186,14 @@ Set (
case GPIO_MODE_OUTPUT_0:
// Set the corresponding data bit to LOW for 0
- MmioAnd8 (PL061_GPIO_DATA_REG, GPIO_PIN_MASK_LOW_8BIT(Gpio));
+ MmioAnd8 (PL061_GPIO_DATA_REG + (GPIO_PIN_MASK_HIGH_8BIT(Gpio) 2),
GPIO_PIN_MASK_LOW_8BIT(Gpio));
// Set the corresponding direction bit to HIGH for output
MmioOr8 (PL061_GPIO_DIR_REG, GPIO_PIN_MASK_HIGH_8BIT(Gpio));
break;
case GPIO_MODE_OUTPUT_1:
// Set the corresponding data bit to HIGH for 1
- MmioOr8 (PL061_GPIO_DATA_REG, GPIO_PIN_MASK_HIGH_8BIT(Gpio));
+ MmioOr8 (PL061_GPIO_DATA_REG + (GPIO_PIN_MASK_HIGH_8BIT(Gpio) 2),
GPIO_PIN_MASK_HIGH_8BIT(Gpio));
// Set the corresponding direction bit to HIGH for output
MmioOr8 (PL061_GPIO_DIR_REG, GPIO_PIN_MASK_HIGH_8BIT(Gpio));
break;
--
2.1.4
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] ArmPlatformPkg: PL061: fix accessing gpio value
On 11 August 2015 at 09:11, Haojian Zhuang haojian.zhu...@linaro.org wrote:
The way of accessing PL061 GPIODATA register is wrong.
The spec said in below.
In order to write to GPIODATA, the corresponding bits in the mask,
resulting from the address bus, PADDR[9:2], must be HIGH. Otherwise
the bit values remain unchanged by the write.
Similarly, the values read from this register are determined for
each bit, by the mask bit derived from the address used to access
the data register, PADDR[9:2]. Bits that are 1 in the address mask
cause the corresponding bits in GPIODATA to be read, and bits that
are 0 in the address mask cause the corresponding bits in GPIODATA
to be read as 0, regardless of their value.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Haojian Zhuang haojian.zhu...@linaro.org
---
ArmPlatformPkg/Drivers/PL061GpioDxe/PL061Gpio.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/ArmPlatformPkg/Drivers/PL061GpioDxe/PL061Gpio.c
b/ArmPlatformPkg/Drivers/PL061GpioDxe/PL061Gpio.c
index ff05662..35418c9 100644
--- a/ArmPlatformPkg/Drivers/PL061GpioDxe/PL061Gpio.c
+++ b/ArmPlatformPkg/Drivers/PL061GpioDxe/PL061Gpio.c
@@ -125,7 +125,7 @@ Get (
}
}
- if (MmioRead8 (PL061_GPIO_DATA_REG) GPIO_PIN_MASK_HIGH_8BIT(Gpio)) {
+ if (MmioRead8 (PL061_GPIO_DATA_REG + (GPIO_PIN_MASK_HIGH_8BIT(Gpio)
2))) {
Hello Haojian,
I have not looked at the PL061 spec, but I noticed a pretty awful bug
in the PL061 header (ArmPlatformPkg/Include/Drivers/PL061Gpio.h):
50:#define GPIO_PIN_MASK_HIGH_8BIT(Pin)(GPIO_PIN_MASK(Pin) 0xFF)
52:#define GPIO_PIN_MASK_LOW_8BIT(Pin) ((~GPIO_PIN_MASK(Pin)) 0xFF)
I am pretty sure that the is incorrect here, since the result of
the expression can only be 0 or 1 then.
Could you perhaps fix this first, and only then figure out what you
need to get the code to work for your hardware? It looks like you are
using some kind of bit banding interface, whereas the existing code
reads/writes all GPIO values from offset 0x0 and performs its own
masking. Perhaps your approach is better, but I'd like to fix first
and then optimize.
Thanks,
Ard.
*Value = 1;
} else {
*Value = 0;
@@ -186,14 +186,14 @@ Set (
case GPIO_MODE_OUTPUT_0:
// Set the corresponding data bit to LOW for 0
- MmioAnd8 (PL061_GPIO_DATA_REG, GPIO_PIN_MASK_LOW_8BIT(Gpio));
+ MmioAnd8 (PL061_GPIO_DATA_REG + (GPIO_PIN_MASK_HIGH_8BIT(Gpio) 2),
GPIO_PIN_MASK_LOW_8BIT(Gpio));
// Set the corresponding direction bit to HIGH for output
MmioOr8 (PL061_GPIO_DIR_REG, GPIO_PIN_MASK_HIGH_8BIT(Gpio));
break;
case GPIO_MODE_OUTPUT_1:
// Set the corresponding data bit to HIGH for 1
- MmioOr8 (PL061_GPIO_DATA_REG, GPIO_PIN_MASK_HIGH_8BIT(Gpio));
+ MmioOr8 (PL061_GPIO_DATA_REG + (GPIO_PIN_MASK_HIGH_8BIT(Gpio) 2),
GPIO_PIN_MASK_HIGH_8BIT(Gpio));
// Set the corresponding direction bit to HIGH for output
MmioOr8 (PL061_GPIO_DIR_REG, GPIO_PIN_MASK_HIGH_8BIT(Gpio));
break;
--
2.1.4
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Question about memory reservation from PrePi to DXE
On Tue, 2015-08-11 at 11:55 +0200, Laszlo Ersek wrote:
So practically:
(1) if the memory resource descriptor that the free page area of the
permanent PEI RAM comes from has enough room above the permanent PEI
RAM, then the DXE core is tentatively targeted there.
Yes and it will ignore any memory allocation hob that might have tried
to reserve some of that memory :(
(2) otherwise, if the free page area itself has enough room left, then
the DXE core is tentatively targeted there.
Which works for everybody afaik
(3) otherwise, if the memory resource descriptor that the free page area
of the permanent PEI RAM comes from has enough room under the HOB
list, then the DXE core is tentatively targeted there.
Same problem as 1)
(4) Then, with the next loop, if the highest-located memory resource
descriptor that is (a) tested, (b) big enough for the DXE core, and (c)
different from the descriptor identified above, is actually higher than
the tentative range determined above, then the DXE core goes up there.
Right, with the same problem as 1) again. Any resource allocation Hob in
that area is completely ignored.
Basically that means that memory allocation hobs only work for memory
that was *allocated* by PEI inside the PEI RAM. Anything outside of it
is fair game for that initial DXE pool, which makes it unsuitable for
example for my attempts at reserving portions of memory on each chip way
outside of my initial PEI memory area.
In OVMF (4) doesn't come into play because the = 4GB memory is added as
untested. (But, in any case, we don't pre-allocate with HOBs that high.)
And, from (1) through (3), (2) applies in OVMF; our permanent PEI RAM is
located at the top of the 4GB memory, so the above room checked in
(1) is zero.
... I added some ASSERT()s to this function, and yes, it's (2) for OVMF.
My faith in world order has been restored. Apologies for hijacking Ben's
thread temporarily, but you got me panicked for a minute.
Yeah and sadly I am still in a sore spot :-) I will need to either slice
up my resource descriptor HOBs to effectively take out the reserved
portions of memory from what I advertise to DXE...
Maybe a compromise would be to make sure the PEI memory covers the
entire resource descriptor HOB it occupies and make it the only *tested*
memory resource descriptor...
That or fix the Gcd init...
Cheers,
Ben.
Thanks
Laszlo
The DXE Core should print out some info to help you debug.
https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c
DEBUG ((DEBUG_INFO | DEBUG_LOAD, HOBLIST address in DXE = 0x%p\n,
HobStart));
DEBUG_CODE_BEGIN ();
EFI_PEI_HOB_POINTERS Hob;
for (Hob.Raw = HobStart; !END_OF_HOB_LIST(Hob); Hob.Raw =
GET_NEXT_HOB(Hob)) {
if (GET_HOB_TYPE (Hob) == EFI_HOB_TYPE_MEMORY_ALLOCATION) {
DEBUG ((DEBUG_INFO | DEBUG_LOAD, Memory Allocation 0x%08x
0x%0lx - 0x%0lx\n, \
Hob.MemoryAllocation-AllocDescriptor.MemoryType,
\
Hob.MemoryAllocation-AllocDescriptor.MemoryBaseAddress,
\
Hob.MemoryAllocation-AllocDescriptor.MemoryBaseAddress +
Hob.MemoryAllocation-AllocDescriptor.MemoryLength - 1));
}
}
for (Hob.Raw = HobStart; !END_OF_HOB_LIST(Hob); Hob.Raw =
GET_NEXT_HOB(Hob)) {
if (GET_HOB_TYPE (Hob) == EFI_HOB_TYPE_FV2) {
DEBUG ((DEBUG_INFO | DEBUG_LOAD, FV2 Hob 0x%0lx -
0x%0lx\n, Hob.FirmwareVolume2-BaseAddress,
Hob.FirmwareVolume2-BaseAddress + Hob.FirmwareVolume2-Length - 1));
} else if (GET_HOB_TYPE (Hob) == EFI_HOB_TYPE_FV) {
DEBUG ((DEBUG_INFO | DEBUG_LOAD, FV Hob0x%0lx -
0x%0lx\n, Hob.FirmwareVolume-BaseAddress,
Hob.FirmwareVolume-BaseAddress + Hob.FirmwareVolume-Length - 1));
}
}
DEBUG_CODE_END ();
Thanks,
Andrew Fish
Cheers,
Ben.
Thanks
Laszlo
(Depex TRUE, and
Apriori file to make it run 1st) and have it do:
Memory = ADDRESS_YOU_WANT_RESERVE:
Status = gBS-AllocatePages (AllocateAddress, MemoryType,
NumberOfMpages, Memory);
If the PEI code knows the ranges it can pass up a GUIDed hob that the
DXE driver uses to know the ranges, or maybe that knowledge can just end
up in the DXE driver.
Given the way the edk2 works you could all do this in a library that is
linked into the DXE Core. As long as the library has a constructor it
will be called by the DXE Core via a call to
ProcessLibraryConstructorList().
https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c
//
// Initialize the Global Coherency Domain Services
//
Status = CoreInitializeGcdServices (HobStart, MemoryBaseAddress,
MemoryLength);
ASSERT_EFI_ERROR (Status);
//
// Call constructor for all libraries
//
ProcessLibraryConstructorList (gDxeCoreImageHandle, gDxeCoreST);
PERF_END
[edk2] [PATCH v2 6/6] BaseTools: remove ARMGCC and ARMLINUXGCC toolchains
The ARMGCC and ARMLINUXGCC toolchains are specific to the ARM and
AARCH64 architectures, and overlap with the toolchain configuration
that is provided by the GCC44 - GCC49 toolchains, which are defined
for all architectures.
To reduce the maintenance burden, and make it easier to keep these
different architectures aligned, remove the ARMGCC and ARMLINUXGCC
toolchains entirely.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
BaseTools/Conf/build_rule.template | 16 +-
BaseTools/Conf/tools_def.template | 200
2 files changed, 5 insertions(+), 211 deletions(-)
diff --git a/BaseTools/Conf/build_rule.template
b/BaseTools/Conf/build_rule.template
index 1035025b668c..3637ef47414e 100644
--- a/BaseTools/Conf/build_rule.template
+++ b/BaseTools/Conf/build_rule.template
@@ -134,7 +134,7 @@
# For RVCTCYGWIN CC_FLAGS must be first to work around pathing issues
$(CC) $(CC_FLAGS) -o ${dst} $(INC) ${src}
-Command.ARMGCC, Command.ARMLINUXGCC, command.XCODE
+Command.XCODE
$(CC) $(CC_FLAGS) -o ${dst} $(INC) ${src}
[C-Code-File.COMMON.IPF]
@@ -258,7 +258,7 @@
Command.RVCT
$(SLINK) $(SLINK_FLAGS) ${dst} --via $(OBJECT_FILES_LIST)
-Command.RVCTCYGWIN, Command.ARMGCC, Command.ARMLINUXGCC
+Command.RVCTCYGWIN
# $(OBJECT_FILES_LIST) has wrong paths for cygwin
$(SLINK) $(SLINK_FLAGS) ${dst} $(OBJECT_FILES)
@@ -282,9 +282,6 @@
$(DLINK) -o ${dst} $(DLINK_FLAGS) --start-group $(DLINK_SPATH)
@$(STATIC_LIBRARY_FILES_LIST) --end-group $(DLINK2_FLAGS)
$(OBJCOPY) $(OBJCOPY_FLAGS) ${dst}
-Command.ARMGCC, Command.ARMLINUXGCC
-$(DLINK) -o ${dst} $(DLINK_FLAGS) --start-group $(DLINK_SPATH)
$(STATIC_LIBRARY_FILES) --end-group $(DLINK2_FLAGS)
-
Command.RVCT
$(DLINK) $(DLINK_FLAGS) -o ${dst} $(DLINK_SPATH) --via
$(STATIC_LIBRARY_FILES_LIST) $(DLINK2_FLAGS)
@@ -312,9 +309,6 @@
Command.GCC
$(DLINK) $(DLINK_FLAGS) --start-group $(DLINK_SPATH)
@$(STATIC_LIBRARY_FILES_LIST) --end-group $(DLINK2_FLAGS)
-Command.ARMGCC, Command.ARMLINUXGCC
-$(DLINK) $(DLINK_FLAGS) --start-group $(DLINK_SPATH)
$(STATIC_LIBRARY_FILES) --end-group $(DLINK2_FLAGS)
-
Command.RVCT
$(DLINK) $(DLINK_FLAGS) -o ${dst} $(DLINK_SPATH) --via
$(STATIC_LIBRARY_FILES_LIST) $(DLINK2_FLAGS)
@@ -333,7 +327,7 @@
OutputFile
$(DEBUG_DIR)(+)$(MODULE_NAME).efi
-Command.MSFT, Command.INTEL, Command.RVCT, Command.ARMGCC,
Command.ARMLINUXGCC
+Command.MSFT, Command.INTEL, Command.RVCT
$(GENFW) -e $(MODULE_TYPE) -o ${dst} ${src} $(GENFW_FLAGS)
$(CP) ${dst} $(OUTPUT_DIR)
$(CP) ${dst} $(BIN_DIR)(+)$(MODULE_NAME_GUID).efi
@@ -582,7 +576,7 @@
OutputFile.MSFT, OutputFile.INTEL, OutputFile.GCC
$(OUTPUT_DIR)(+)$(MODULE_NAME)hii.lib
-OutputFile.XCODE, OutputFile.RVCT, OutputFile.ARMGCC
+OutputFile.XCODE, OutputFile.RVCT
$(OUTPUT_DIR)(+)$(MODULE_NAME)hii.rc
Command.MSFT, Command.INTEL
@@ -593,7 +587,7 @@
$(GENFW) -o $(OUTPUT_DIR)(+)$(MODULE_NAME)hii.rc -g $(MODULE_GUID)
--hiibinpackage $(HII_BINARY_PACKAGES) $(GENFW_FLAGS)
$(RC) $(RC_FLAGS) $(OUTPUT_DIR)(+)$(MODULE_NAME)hii.rc ${dst}
-Command.XCODE, Command.RVCT, Command.ARMGCC, Command.ARMLINUXGCC
+Command.XCODE, Command.RVCT
GenFw -o $(OUTPUT_DIR)(+)$(MODULE_NAME)hii.rc -g $(MODULE_GUID)
--hiibinpackage $(HII_BINARY_PACKAGES)
diff --git a/BaseTools/Conf/tools_def.template
b/BaseTools/Conf/tools_def.template
index 0c41c862af83..6e2d4909b9fc 100644
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -633,18 +633,6 @@ DEFINE SOURCERY_CYGWIN_TOOLS = /cygdrive/c/Program
Files/CodeSourcery/Sourcery G
# Required to build platforms or ACPI tables:
# Microsoft ASL ACPI Compiler (asl.exe) v4.0.0
from
#
http://download.microsoft.com/download/2/c/1/2c16c7e0-96c1-40f5-81fc-3e4bf7b65496/microsoft_asl_compiler-v4-0-0.msi
-# ARMGCC -unix- Requires:
-# ARM None EABI GCC 4.6.0
-#Optional:
-# Required to build platforms or ACPI tables:
-# Intel(r) ACPI Compiler from
-# https://acpica.org/downloads
-# ARMLINUXGCC -unix- Requires:
-# ARM Linux GNU EABI GCC 4.6.0
-#Optional:
-# Required to build platforms or ACPI tables:
-# Intel(r) ACPI Compiler from
-# https://acpica.org/downloads
# RVCT-win- Requires:
# ARM C/C++ Compiler, 5.00
#Optional:
@@ -6751,194 +6739,6
[edk2] [PATCH v2 4/6] BeagleBoardPkg: fold configuration header into FD build
Since the configuration header never changes unless the board parameters
in ConfigurationHeader.dat are updated, we can take a snapshot of the
binary and add it to the FDF definition. This way, it will get emitted
by the EDK2 build system instead of having to use a separate
post-processing tool to add it to the flash image.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
BeagleBoardPkg/BeagleBoardPkg.fdf | 13 +++--
BeagleBoardPkg/ConfigurationHeader.bin | Bin 0 - 512 bytes
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/BeagleBoardPkg/BeagleBoardPkg.fdf
b/BeagleBoardPkg/BeagleBoardPkg.fdf
index a6392440e64f..fb1dc26de349 100644
--- a/BeagleBoardPkg/BeagleBoardPkg.fdf
+++ b/BeagleBoardPkg/BeagleBoardPkg.fdf
@@ -27,7 +27,7 @@
[FD.BeagleBoard_EFI]
-BaseAddress = 0x80008000|gArmTokenSpaceGuid.PcdFdBaseAddress #The base
address of the FLASH Device.
+BaseAddress = 0x80007DF8|gArmTokenSpaceGuid.PcdFdBaseAddress #The base
address of the FLASH Device.
Size = 0x000B|gArmTokenSpaceGuid.PcdFdSize #The size in
bytes of the FLASH Device
ErasePolarity = 1
BlockSize = 0x1
@@ -48,7 +48,16 @@ [FD.BeagleBoard_EFI]
# RegionType FV, DATA, or FILE
#
-0x|0x000B
+0x|0x0200
+FILE = BeagleBoardPkg/ConfigurationHeader.bin
+
+0x0200|0x0008
+DATA = {
+ 0xF8, 0xFD, 0x0A, 0x00, # image size: 0xB - 0x208 == 0xAFDF8
+ 0x00, 0x80, 0x00, 0x80# entry point: 0x80008000
+}
+
+0x0208|0x000AFDF8
gArmTokenSpaceGuid.PcdFvBaseAddress|gArmTokenSpaceGuid.PcdFvSize
FV = FVMAIN_COMPACT
diff --git a/BeagleBoardPkg/ConfigurationHeader.bin
b/BeagleBoardPkg/ConfigurationHeader.bin
new file mode 100644
index
..150b3849fc35f6526f51ce32b3ab30c9555b284f
GIT binary patch
literal 512
zcmZ3$z`zgy#K^$eBiJ=0#M93`n1SH~P$C9d63BM;2y*m=iv0%yG-;}G40yhfRT}b
z;VZtYXi_^W*`pWVq)e3GDLxFb07o*9v@B^n`Z+f11DGxD)mK0cZpm90HjKWuec
n;)04d0%?%hf({p$jG$u2j?CSqq{_^_=p9s97s7x?@$B)?bO_
literal 0
HcmV?d1
--
1.9.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] PCI Bus scanning
Hi, During PCI bus scanning, my execution hanged at ProcessOptionRom (RootBridgeDev, Mem32Base, RootBridgeDev-RomSize); So I am commented this, and it went well. Will there be any difference in PCI networking tests (ping/ifconfig/tftp), if I keep this ProcessOptionRom code commented? Thanks and Regards, Shaveta -Original Message- From: Leekha Shaveta-B20052 Sent: Saturday, August 08, 2015 10:48 PM To: 'Ye, Ting'; 'edk2-devel@lists.01.org' Subject: RE: Error on executing shell command ifconfig Does anyone tested network(ping/tftp) using E1000/NIC PCI card on Juno board? Which LAN E1000 driver(source or any link) is used and tested for Intel NIC card? Thanks and Regards, Shaveta -Original Message- From: Leekha Shaveta-B20052 Sent: Friday, August 07, 2015 10:59 AM To: 'Ye, Ting'; edk2-devel@lists.01.org Subject: RE: Error on executing shell command ifconfig Thanks Ting! I have one LanIntelE1000Dxe code and using it, but this code is not yet tested on UEFI. And as my network (ping/ifconfig) is not working, I am clueless about what exactly causing the issue. Thanks and Regards, Shaveta -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ye, Ting Sent: Friday, August 07, 2015 10:54 AM To: Leekha Shaveta-B20052; Sharma Bhupesh-B45370; edk2-devel@lists.01.org Subject: Re: [edk2] Error on executing shell command ifconfig Hi Shaveta, The upper layer drivers since SNP are available for several years and validated in multiple UEFI enabled platforms. Sorry I don't know whether you can get the UEFI Intel E1000 NIC card driver. You may search the download center in Intel.com? Hope other guys in the mailing list know. Best Regards, Ting -Original Message- From: Leekha Shaveta [mailto:shav...@freescale.com] Sent: Friday, August 07, 2015 1:18 PM To: Ye, Ting; Sharma Bhupesh; edk2-devel@lists.01.org Subject: RE: Error on executing shell command ifconfig Upper layer drivers like SNP/MNP are also taken from EDK2 and not been tested on UEFI. From where can I get the complete code of Intel E1000 NIC card driver for UEFI? Is such tested code available for use for UEFI? Thanks and Regards, Shaveta -Original Message- From: Ye, Ting [mailto:ting...@intel.com] Sent: Thursday, August 06, 2015 10:50 AM To: Leekha Shaveta-B20052; Sharma Bhupesh-B45370; edk2-devel@lists.01.org Subject: RE: Error on executing shell command ifconfig The #D and #C are zero which mean that this driver does not manage any device or child device. It looks the driver not function well. You can also double check whether upper layer drivers like SNP, MNP, etc. ever manage any devices. Best Regards, Ye Ting -Original Message- From: Leekha Shaveta [mailto:shav...@freescale.com] Sent: Thursday, August 06, 2015 12:56 PM To: Ye, Ting; Sharma Bhupesh; edk2-devel@lists.01.org Subject: RE: Error on executing shell command ifconfig Hi Ye Ting, Thanks for the reply. This driver has not been tested on UEFI, but said to be tested on edk2. On running drivers command I get following output: Shell drivers T D Y C I P F A DRV VERSION E G G #D #C DRIVER NAME IMAGE PATH === = = = === === === == 39 04040600 ? Y Y 0 0 Intel(R) PRO/1000 4.4.06 PCI-E MemoryMapped(0xB,0xFF80D000,0xFFBEA167)/FvFile(BB801A52-C90F-4EDE-91B2-82520888CBC3) It seems that E1000 driver is getting loaded properly. Correct understanding? Thanks and Regards, Shaveta -Original Message- From: Ye, Ting [mailto:ting...@intel.com] Sent: Thursday, August 06, 2015 5:56 AM To: Sharma Bhupesh-B45370; edk2-devel@lists.01.org; Leekha Shaveta-B20052 Subject: RE: Error on executing shell command ifconfig Do you know whether the LanIntelE1000Dxe works properly? You may type drivers in shell to check connecting status of UEFI network drivers. Best Regards, Ye Ting -Original Message- From: Sharma Bhupesh [mailto:bhupesh.sha...@freescale.com] Sent: Wednesday, August 05, 2015 6:43 PM To: Ye, Ting; edk2-devel@lists.01.org; Leekha Shaveta Subject: RE: Error on executing shell command ifconfig Hi Ye Ting, Thanks for your inputs. I tried adding the same as well and the following packages are now being added to the .dsc file: # # Networking stack # MdeModulePkg/Universal/Network/SnpDxe/SnpDxe.inf MdeModulePkg/Universal/Network/DpcDxe/DpcDxe.inf MdeModulePkg/Universal/Network/MnpDxe/MnpDxe.inf MdeModulePkg/Universal/Network/VlanConfigDxe/VlanConfigDxe.inf MdeModulePkg/Universal/Network/ArpDxe/ArpDxe.inf MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Dxe.inf MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Dxe.inf MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4ConfigDxe.inf MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Dxe.inf MdeModulePkg/Universal/Network/Udp4Dxe/Udp4Dxe.inf MdeModulePkg/Universal/Network/Tcp4Dxe/Tcp4Dxe.inf
Re: [edk2] Question about memory reservation from PrePi to DXE
On 08/11/15 01:01, Benjamin Herrenschmidt wrote: On Tue, 2015-08-11 at 08:08 +1000, Benjamin Herrenschmidt wrote: .../... That means that if I want to reserve memory elsewhere in the system, I need to either: - Make sure that chunk of memory is not covered by a memory resource descriptor HOB, or at least one that isn't marked somewhat reserved (I didn't look in details yet how you mark them such) Or - Make sure *all* of the memory you are trying to reserve is covered by the PHIT hob. The thing that effectively disables the maximum search (= the second loop) for OVMF is that the higher-than-PHIT-covered-memory is added as untested. And, before that maximum search is reached, the EfiFreeMemoryBottom..EfiFreeMemoryTop case matches (which you called easy and clean). Note that it would be handy if the logic could be changed a bit here, so that it only tries to look memory in higher up resource descriptors if it didn't find suitable space in the one containing the PHIT Hob, maybe under control of a Pcd. In my case, I will have several resource descriptor HOBs (representing my NUMA configuration) and I will have reserved areas in each (some chip-local space used by the HW such as on-chip controller memory space). So the memory allocations HOBs won't work, since they will only be honored in effect for memory covered by the first descriptor which will be the one containing the PHIT (I will adjust the PHIT EfiMemoryTop to cover it all). I can't send a proposed patch just yet (still need to sort out legal approval for contributing), but let me know if the idea works for you and I'll do a patch locally send it when I can. Now that I seem to understand CoreInitializeMemoryServices() -- and we independently arrived at the same conclusions about its behavior, apparently, see [1] [2] --, I believe the least intrusive solution in your use case would be hole punching, wrt. memory resource descriptor HOBs. [1] http://thread.gmane.org/gmane.comp.bios.edk2.devel/1023/focus=1103 [2] http://thread.gmane.org/gmane.comp.bios.edk2.devel/1023/focus=1124 I think I have always assumed that the DXE core would be satisfied from free permanent PEI RAM, no questions asked. Although that is the case with OVMF (marked (2) in [2]), it doesn't look unconditional in general now. The hole punching would cover your use case without having to patch CoreInitializeGcdServices(). But, I agree that the second loop (that I marked with (4) in [2]) is unexpected. So maybe a Feature PCD could gate that loop. (I'm not one to review it though, as Andrew mentioned.) ... I think that simply avoiding the maximum search would keep the following ASSERT() intact and valid (comment rewrapped here): // // If no memory regions are found that are big enough to initialize // the DXE core, then ASSERT(). // ASSERT (Length = MINIMUM_INITIAL_MEMORY_SIZE); Because, at that point, Length will have always been assigned, even without the maximum search. The strategy of the function is to keep setting Length to the next tentative value (initially to zero), and then investigate if that can actually work (and if so then stick with it). Omitting the maximum search will just leave an earlier tentative value in place (which is: the initial zero, or the value set in (1), (2), or (3)) as the final attempt, before reaching the above ASSERT(). It should be fine. Thanks! Laszlo ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 3/3] OvmfPkg/Xen: use lower case x in hex immediate value
On 08/10/15 16:00, Ard Biesheuvel wrote: CLANG chokes on the value 0XEA1 since it expects the 0x prefix to use a lower case x. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org --- OvmfPkg/Include/IndustryStandard/Xen/arch-arm/xen.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/OvmfPkg/Include/IndustryStandard/Xen/arch-arm/xen.h b/OvmfPkg/Include/IndustryStandard/Xen/arch-arm/xen.h index 655a221f6337..625a0fc99416 100644 --- a/OvmfPkg/Include/IndustryStandard/Xen/arch-arm/xen.h +++ b/OvmfPkg/Include/IndustryStandard/Xen/arch-arm/xen.h @@ -168,7 +168,7 @@ * at Documentation/devicetree/bindings/arm/xen.txt. */ -#define XEN_HYPERCALL_TAG 0XEA1 +#define XEN_HYPERCALL_TAG 0xEA1 #define uint64_aligned_t UINT64 __attribute__((aligned(8))) That's a CLANG bug actually (refer to 6.4.4.1 Integer constants: hexadecimal-prefix: one of 0x 0X ) but I find 0X terribly unreadable myself, so yeah. For this patch: Reviewed-by: Laszlo Ersek ler...@redhat.com For the other two patches in the series: Acked-by: Laszlo Ersek ler...@redhat.com Thanks Laszlo ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Status of porting acpidump to edk2 ?
On 08/11/15 05:52, Andrew Fish wrote: On Aug 10, 2015, at 7:33 PM, Shubha Ramani shubharam...@yahoo.com wrote: I know people were attempting to port acpidump from https://www.acpica.org/ to EDK2. Any success ? I need it desperately. If you look at the mailing list history jonathan.d.sm...@intel.com mailto:jonathan.d.sm...@intel.com posted a Windows port to the mailing list. I saw it. Unfortunately it wasn't a patch formatted and sent with git-format-patch / git-send-email. (Maybe that makes sense. The source code is huge; plus, according to Jonathan's repo, it's just one large commit, https://github.com/jnthsmth/edk2/commit/c0882f6bd53afd59b1d18a15bbf5a92224abfb7f.) Anyway, where should the utility live in the edk2 tree? The patch at the moment introduces a new top-level package, AcpicaPkg. That leaves it without a maintainer who could review it (or at least approve the addition). Also, for a new top level package, License.txt / Contributions.txt would be necessary. But, I think it would be best to add this toolset under MdeModulePkg/Application/. MdeModulePkg is where AcpiTableDxe lives (implementing EFI_ACPI_TABLE_PROTOCOL, and conditionally EFI_ACPI_SDT_PROTOCOL too). Code (example code or otherwise) for installing actual tables can also be found there (AcpiPlatformDxe, BootGraphicsResourceTableDxe, IScsiDxe, etc). Thanks Laszlo Thanks, Andrew Fish Thanks, Shubha Shubha D. ramanishubharam...@gmail.com shubharam...@yahoo.com ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [patch 1/2] Add TPM2 definition in trusted computing group.
1) TCG Physical Presence Interface Specification 1.30 at http://www.trustedcomputinggroup.org/resources/tcg_physical_presence_interface_specification 2) TCG EFI Protocol Specification for TPM 2.0 at http://www.trustedcomputinggroup.org/resources/tcg_efi_protocol_specification 3) Update TPM2.0 header file to include Hash Algo definition. 4) Update UEFI TCG platform header file to include more TCG event structure. Test Win8/Win10 with secure boot enabled, PCR7 shows bound. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Yao, Jiewen jiewen@intel.com CC: Zhang, Chao B chao.b.zh...@intel.com --- .../Include/IndustryStandard/TcgPhysicalPresence.h | 129 MdePkg/Include/IndustryStandard/Tpm20.h| 11 +- MdePkg/Include/IndustryStandard/UefiTcgPlatform.h | 110 ++- MdePkg/Include/Protocol/Tcg2Protocol.h | 341 + MdePkg/Include/Protocol/TrEEProtocol.h | 18 +- MdePkg/MdePkg.dec | 4 + 6 files changed, 594 insertions(+), 19 deletions(-) create mode 100644 MdePkg/Include/IndustryStandard/TcgPhysicalPresence.h create mode 100644 MdePkg/Include/Protocol/Tcg2Protocol.h diff --git a/MdePkg/Include/IndustryStandard/TcgPhysicalPresence.h b/MdePkg/Include/IndustryStandard/TcgPhysicalPresence.h new file mode 100644 index 000..80ae7d3 --- /dev/null +++ b/MdePkg/Include/IndustryStandard/TcgPhysicalPresence.h @@ -0,0 +1,129 @@ +/** @file + TCG Physical Presence definition. + +Copyright (c) 2015, Intel Corporation. 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. + +**/ + +#ifndef _TCG_PHYSICAL_PRESENCE_H_ +#define _TCG_PHYSICAL_PRESENCE_H_ + +// +// TCG PP definition for physical presence ACPI function +// +#define TCG_ACPI_FUNCTION_GET_PHYSICAL_PRESENCE_INTERFACE_VERSION 1 +#define TCG_ACPI_FUNCTION_SUBMIT_REQUEST_TO_BIOS 2 +#define TCG_ACPI_FUNCTION_GET_PENDING_REQUEST_BY_OS3 +#define TCG_ACPI_FUNCTION_GET_PLATFORM_ACTION_TO_TRANSITION_TO_BIOS4 +#define TCG_ACPI_FUNCTION_RETURN_REQUEST_RESPONSE_TO_OS5 +#define TCG_ACPI_FUNCTION_SUBMIT_PREFERRED_USER_LANGUAGE 6 +#define TCG_ACPI_FUNCTION_SUBMIT_REQUEST_TO_BIOS_2 7 +#define TCG_ACPI_FUNCTION_GET_USER_CONFIRMATION_STATUS_FOR_REQUEST 8 + +// +// TCG PP definition for TPM Operation Response to OS Environment +// +#define TCG_PP_OPERATION_RESPONSE_SUCCESS 0x0 +#define TCG_PP_OPERATION_RESPONSE_USER_ABORT 0xFFF0 +#define TCG_PP_OPERATION_RESPONSE_BIOS_FAILURE 0xFFF1 + +// +// TCG PP definition of return code for Return TPM Operation Response to OS Environment +// +#define TCG_PP_RETURN_TPM_OPERATION_RESPONSE_SUCCESS 0 +#define TCG_PP_RETURN_TPM_OPERATION_RESPONSE_FAILURE 1 + +// +// TCG PP definition of return code for Sumbit TPM Request to Pre-OS Environment +// and Sumbit TPM Request to Pre-OS Environment 2 +// +#define TCG_PP_SUBMIT_REQUEST_TO_PREOS_SUCCESS 0 +#define TCG_PP_SUBMIT_REQUEST_TO_PREOS_NOT_IMPLEMENTED 1 +#define TCG_PP_SUBMIT_REQUEST_TO_PREOS_GENERAL_FAILURE 2 +#define TCG_PP_SUBMIT_REQUEST_TO_PREOS_BLOCKED_BY_BIOS_SETTINGS 3 + +// +// TCG PP definition of return code for Get User Confirmation Status for Operation +// +#define TCG_PP_GET_USER_CONFIRMATION_NOT_IMPLEMENTED 0 +#define TCG_PP_GET_USER_CONFIRMATION_BIOS_ONLY 1 +#define TCG_PP_GET_USER_CONFIRMATION_BLOCKED_BY_BIOS_CONFIGURATION 2 +#define TCG_PP_GET_USER_CONFIRMATION_ALLOWED_AND_PPUSER_REQUIRED 3 +#define TCG_PP_GET_USER_CONFIRMATION_ALLOWED_AND_PPUSER_NOT_REQUIRED 4 + +// +// TCG PP definition of physical presence operation actions for TPM12 +// +#define TCG_PHYSICAL_PRESENCE_NO_ACTION 0 +#define TCG_PHYSICAL_PRESENCE_ENABLE 1 +#define TCG_PHYSICAL_PRESENCE_DISABLE 2 +#define TCG_PHYSICAL_PRESENCE_ACTIVATE3 +#define TCG_PHYSICAL_PRESENCE_DEACTIVATE 4 +#define TCG_PHYSICAL_PRESENCE_CLEAR 5 +#define TCG_PHYSICAL_PRESENCE_ENABLE_ACTIVATE 6 +#define TCG_PHYSICAL_PRESENCE_DEACTIVATE_DISABLE 7 +#define TCG_PHYSICAL_PRESENCE_SET_OWNER_INSTALL_TRUE
Re: [edk2] [PATCH 3/3] OvmfPkg/Xen: use lower case x in hex immediate value
On 11 August 2015 at 14:26, Laszlo Ersek ler...@redhat.com wrote: On 08/10/15 16:00, Ard Biesheuvel wrote: CLANG chokes on the value 0XEA1 since it expects the 0x prefix to use a lower case x. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org --- OvmfPkg/Include/IndustryStandard/Xen/arch-arm/xen.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/OvmfPkg/Include/IndustryStandard/Xen/arch-arm/xen.h b/OvmfPkg/Include/IndustryStandard/Xen/arch-arm/xen.h index 655a221f6337..625a0fc99416 100644 --- a/OvmfPkg/Include/IndustryStandard/Xen/arch-arm/xen.h +++ b/OvmfPkg/Include/IndustryStandard/Xen/arch-arm/xen.h @@ -168,7 +168,7 @@ * at Documentation/devicetree/bindings/arm/xen.txt. */ -#define XEN_HYPERCALL_TAG 0XEA1 +#define XEN_HYPERCALL_TAG 0xEA1 #define uint64_aligned_t UINT64 __attribute__((aligned(8))) That's a CLANG bug actually (refer to 6.4.4.1 Integer constants: hexadecimal-prefix: one of 0x 0X ) but I find 0X terribly unreadable myself, so yeah. Well, I suppose you are quoting the C standard there, but what I failed to mention is that it is actually the clang aarch64 assembler that rejects it. For this patch: Reviewed-by: Laszlo Ersek ler...@redhat.com For the other two patches in the series: Acked-by: Laszlo Ersek ler...@redhat.com Thank you Laszlo Ard. ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch 0/3] Use new BDS and UiApp for OvmfPkg
On 08/07/15 11:31, Ni, Ruiyu wrote: Laszlo, Lots of questions were raised. :) Q1. can you please tell me more about the new BDS and UiApp? What the motivation for it was, what it does? Do the GenericBdsLib functions continue to work? Q2. given that ArmVirtPkg is not being modified, it appears that GenericBdsLib is not planned (in the short/mid term at least) to be phased out The BDS in IntelFrameworkModulePkg mixed the UI part and the real BDS part together that makes platform impossible to integrate a simpler UI but still use the BDS part. That's the main reason we create the new BDS and also the core sample UiApp. Other reasons are more related to just the BDS part. The interaction between old BDS and platform is not very clear. The boot option management in old BDS is a mess. It checks whether a boot option is valid by connecting to it, which is unexpected from caller's perspective. I cannot remember all the reasons now. Overall the new BDS is much more cleaner than the old BDS. GenericBdsLib still works but I will not integrate new UEFI features to it. The goal is every platform uses new BDS and old BDS will be removed when no one cares about it. I didn't change ArmVirtPkg is because I don't know how to even bulid the package. So I just throw the OvmfPkg changes out and if someone can help we can co-work on that package to also use the new BDS. The reason I want to enable the new BDS is to prove that new BDS is feasible to not only Intel close sourced platforms but also open sourced platforms. Understood. Once we successfully move OvmfPkg over to the new BDS, we should do the same with ArmVirtPkg. Hopefully I'll understand the new BDS enough by then for assisting or writing patches. Q3. push the series to a public repo Sure. the URL is: https://github.com/niruiyu/edk2/commits/OVMF_NEWBDS There are three commits. Check it and tell me whether it fits the GIT working style:) I clone edk2 master in my local disk. Then I created a OVMF_NEWBDS branch in local and checked in the three patches locally. Then I forked a edk2 in my personal GIT repo in github. Then Then I configure my GIT to add a new remote name niruiyu pointing to my personal GIT repo in github. Then I push the OVMF_NEWBDS local branch to niruiyu. Did I do the whole thing correctly? Any unnecessary steps? Looks okay to me. I fetched your repo and am looking at the branch. Q4: A build flag to use new/old BDS Standing on my point (my reason is just to prove the new BDS's design), I am ok to use a build flag and default to use old BDS. But I am afraid that the build flag will always point to old BDS and new features enabling will only be developed and tested with old BDS. In a very near future when someone change the build flag to point to new BDS, the OVMF even cannot build. My understanding is the change only impacts boot timeout and boot order override from QEMU, and the legacy boot. I've already tested the boot timeout override. If we can prove that boot order override from QEMU and legacy boot still works, we are safe to just use the new BDS. What do you think? I started looking at the patch. I can't yet say how intrusive it is. Perhaps I'll be okay without a build time flag, not sure yet. Thanks Laszlo -Original Message- From: Laszlo Ersek [mailto:ler...@redhat.com] Sent: Tuesday, August 4, 2015 7:10 PM To: Ni, Ruiyu ruiyu...@intel.com Cc: edk2-de...@ml01.01.org; David Woodhouse dw...@infradead.org Subject: Re: [edk2] [Patch 0/3] Use new BDS and UiApp for OvmfPkg On 08/04/15 12:53, Laszlo Ersek wrote: No matter how carefully we review and test the new code, something will inevitably break, This wasn't meant as lack of trust in your code; it's just that there are many cases and corner cases in the related OVMF code, and it's quite hard to test them all. Thanks Laszlo ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Status of porting acpidump to edk2 ?
As mentioned, It's one large commit onto EDK2 as AcpicaPkg. It has only two lines of changes to the ACPICA code, and the intent was to get those two lines rolled into ACPICA if possible. I propose that this get pulled into AppPkg since the code is modelled after those apps. My approach was to port Acpidump as a standard-lib-consuming shell application. I don't know any of the licensing details -Original Message- From: Andrew Fish [mailto:af...@apple.com] Sent: Tuesday, August 11, 2015 7:05 AM To: Laszlo Ersek Cc: Shubha Ramani; Smith, Jonathan D; edk2-devel@lists.01.org Subject: Re: [edk2] Status of porting acpidump to edk2 ? On Aug 11, 2015, at 5:56 AM, Laszlo Ersek ler...@redhat.com wrote: On 08/11/15 05:52, Andrew Fish wrote: On Aug 10, 2015, at 7:33 PM, Shubha Ramani shubharam...@yahoo.com wrote: I know people were attempting to port acpidump from https://www.acpica.org/ to EDK2. Any success ? I need it desperately. If you look at the mailing list history jonathan.d.sm...@intel.com mailto:jonathan.d.sm...@intel.com posted a Windows port to the mailing list. I saw it. Unfortunately it wasn't a patch formatted and sent with git-format-patch / git-send-email. (Maybe that makes sense. The source code is huge; plus, according to Jonathan's repo, it's just one large commit, https://github.com/jnthsmth/edk2/commit/c0882f6bd53afd59b1d18a15bbf5a 92224abfb7f.) Anyway, where should the utility live in the edk2 tree? The patch at the moment introduces a new top-level package, AcpicaPkg. That leaves it without a maintainer who could review it (or at least approve the addition). Also, for a new top level package, License.txt / Contributions.txt would be necessary. It ended up as a package as it used the .DEC file to add the include paths for the existing code. [Includes] # acpica paths source/include source/include/platform source/tools/acpidump Also, I at some point we need to understand the license of the existing code, and what that means? Does it need a separate package? Can we convert it to BSD? But, I think it would be best to add this toolset under MdeModulePkg/Application/. MdeModulePkg is where AcpiTableDxe lives (implementing EFI_ACPI_TABLE_PROTOCOL, and conditionally EFI_ACPI_SDT_PROTOCOL too). Code (example code or otherwise) for installing actual tables can also be found there (AcpiPlatformDxe, BootGraphicsResourceTableDxe, IScsiDxe, etc). The current port is a Shell App, and it requires the StdLib. [Packages] StdLib/StdLib.dec MdePkg/MdePkg.dec ShellPkg/ShellPkg.dec Generally MdeModulePkg applications only depend on the MdePkg, and the MdeModulePkg. Thanks, Andrew Fish Thanks Laszlo Thanks, Andrew Fish Thanks, Shubha Shubha D. ramanishubharam...@gmail.com shubharam...@yahoo.com ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Status of porting acpidump to edk2 ?
Maybe Larry Hauch or Mike Kinney would know who to talk to about this? -Original Message- From: Andrew Fish [mailto:af...@apple.com] Sent: Tuesday, August 11, 2015 9:21 AM To: Vincent Zimmer Cc: Smith, Jonathan D Subject: Re: [edk2] Status of porting acpidump to edk2 ? On Aug 11, 2015, at 8:31 AM, Smith, Jonathan D jonathan.d.sm...@intel.com wrote: As mentioned, It's one large commit onto EDK2 as AcpicaPkg. It has only two lines of changes to the ACPICA code, and the intent was to get those two lines rolled into ACPICA if possible. I propose that this get pulled into AppPkg since the code is modelled after those apps. My approach was to port Acpidump as a standard-lib-consuming shell application. I don't know any of the licensing details Vincent, Since adding an ACPI dump command came up in the UEFI Forum meetings, and Intel lawyers came up with both sets of licenses…. Seems like a good idea to figure out a landing spot. Seems like the ACPICA website or edk2 are both options? Who is the person at Intel to figure this stuff out? Thanks, Andrew Fish -Original Message- From: Andrew Fish [mailto:af...@apple.com] Sent: Tuesday, August 11, 2015 7:05 AM To: Laszlo Ersek Cc: Shubha Ramani; Smith, Jonathan D; edk2-devel@lists.01.org Subject: Re: [edk2] Status of porting acpidump to edk2 ? On Aug 11, 2015, at 5:56 AM, Laszlo Ersek ler...@redhat.com wrote: On 08/11/15 05:52, Andrew Fish wrote: On Aug 10, 2015, at 7:33 PM, Shubha Ramani shubharam...@yahoo.com wrote: I know people were attempting to port acpidump from https://www.acpica.org/ to EDK2. Any success ? I need it desperately. If you look at the mailing list history jonathan.d.sm...@intel.com mailto:jonathan.d.sm...@intel.com posted a Windows port to the mailing list. I saw it. Unfortunately it wasn't a patch formatted and sent with git-format-patch / git-send-email. (Maybe that makes sense. The source code is huge; plus, according to Jonathan's repo, it's just one large commit, https://github.com/jnthsmth/edk2/commit/c0882f6bd53afd59b1d18a15bbf5 a 92224abfb7f.) Anyway, where should the utility live in the edk2 tree? The patch at the moment introduces a new top-level package, AcpicaPkg. That leaves it without a maintainer who could review it (or at least approve the addition). Also, for a new top level package, License.txt / Contributions.txt would be necessary. It ended up as a package as it used the .DEC file to add the include paths for the existing code. [Includes] # acpica paths source/include source/include/platform source/tools/acpidump Also, I at some point we need to understand the license of the existing code, and what that means? Does it need a separate package? Can we convert it to BSD? But, I think it would be best to add this toolset under MdeModulePkg/Application/. MdeModulePkg is where AcpiTableDxe lives (implementing EFI_ACPI_TABLE_PROTOCOL, and conditionally EFI_ACPI_SDT_PROTOCOL too). Code (example code or otherwise) for installing actual tables can also be found there (AcpiPlatformDxe, BootGraphicsResourceTableDxe, IScsiDxe, etc). The current port is a Shell App, and it requires the StdLib. [Packages] StdLib/StdLib.dec MdePkg/MdePkg.dec ShellPkg/ShellPkg.dec Generally MdeModulePkg applications only depend on the MdePkg, and the MdeModulePkg. Thanks, Andrew Fish Thanks Laszlo Thanks, Andrew Fish Thanks, Shubha Shubha D. ramanishubharam...@gmail.com shubharam...@yahoo.com ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] TianoCore and Redfish: UPnP, JSON Schema or OData CSDL?
Q: Is TianoCore going to get any additional DMF Redfish support beyond the new UEFI 2.5 REST API? Q: what about Redfish UPNP SSDP dependence? The Redfish Mockup says: Note – discovery of service endpoints will be done using UPNP’s SSDP but that’s not in the mockup. This implies that non-mocked Redfish will be using UPNP's SSDP. Will UEFI be implementing UPNP so it can support Redfish? If not, how to deal with Redfish endpoint discovery at UEFI level (in code or by user)? Q: what about non-ReSTful REST usage? Will Tianocore be implementing OData Action library to augment REST, and if not how will the non-easy things be accomplished at UEFI level? Will any schema-based Redfish dependencies be based on the JSON Schema or the ODATA CSDL Schema? The Redfish Mockup readme says: Not everything can be done easily using REST, so Redfish leverages OData Actions for procedural operations. The Redfish schema says: DSP8010 - Redfish Schema - this contains the Redfish Schema definitions. These files are normative in nature and are normatively reference by the Redfish Specification. There are two Schema formats - CSDL (OData Common Schema Definition Language format which is in XML) and JSON Schema. These Schema definitions should be functionally equivalent, thus specifying the schema in two different languages. [It appears that Microsoft's main contribution to Redfish has been addition of OData, see DMTF.org's Redfish PPTs. Bluntly, Microsoft's OData scares me, it's designed to make use of Microsoft SQL Server, instead of standards-based queries, and schema directions. Slipping it into REST is somewhat misleading and can have technology/patent/platform dependencies. I hope UEFI Forum doesn't require use of any OData technology, and uses only pure JSON, and only JSON Schema, for better cross-platform support.] Thanks, Lee RSS: http://firmwaresecurity.com/feed ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 0/5] secure boot support for ARM FVP
On 08/08/15 14:00, Ard Biesheuvel wrote: This series adds support for using the Intel BDS with ArmVExpress-FVP, and for building it with UEFI Secure Boot enabled. Note that the former is a prerequisite of the latter, since the ARM BDS has no GUI for enrolling certificates and enabling secure boot. Patch #1 removes the PlatformIntelBdsLIb dependency on BdsLib, which is ARM BDS specific. (This patch has been sent out before as an RFC, and reviewed by Laszlo, but I had to add a 'Status = EFI_SUCCESS;' to GetConsoleDevicePathFromVariable () to fix a RELEASE build error, so I dropped the R-b) Patch #2 fixes a bug in some debug code that clobbers a EFI_STATUS var in the error path that is supposed to report it to the user. Patch #3 adds quiet boot/splash screen support to our PlatformIntelBdsLib Patch #4 enables the Intel BDS build of ArmVExpress-FVP, by introducing a define 'USE_ARM_BDS' which defaults to TRUE but can be disabled on the build command line to use the Intel BDS instead. Patch #5 enables the Secure Boot build of ArmVExpress-FVP, by introducing a define 'SECURE_BOOT_ENABLE' which defaults to FALSE but can be enabled on the build command line. Ard Biesheuvel (5): ArmPlatformPkg/PlatformIntelBdsLib: remove ARM BDS dependency ArmPlatformPkg/PlatformIntelBdsLib: fix error handling ArmPlatformPkg/PlatformIntelBdsLib: add splash screen support ArmPlatformPkg/ArmVExpressPkg: add support for the Intel BDS ArmPlatformPkg/ArmVExpressPkg: enable UEFI Secure Boot ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc | 18 + ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.fdf | 20 ++ ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc | 40 ArmPlatformPkg/Library/PlatformIntelBdsLib/IntelBdsPlatform.c | 36 -- ArmPlatformPkg/Library/PlatformIntelBdsLib/IntelBdsPlatform.h | 1 - ArmPlatformPkg/Library/PlatformIntelBdsLib/PlatformIntelBdsLib.inf | 2 +- 6 files changed, 104 insertions(+), 13 deletions(-) I was Cc'd on this, but given my review load and the fact that I'm not co-maintainer for ArmPlatformPkg, I'm de-queueing the series. Tell me if that's a problem. Thanks Laszlo ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2 0/6] remove ARMGCC and ARMLINUXGCC toolchains
On 12 August 2015 at 03:34, Gao, Liming liming@intel.com wrote: Ard: I have no comments on the change in BaseTools build_rule.template and tools_def.template. Reviewed-by: Liming Gao liming@intel.com Thanks all. Committed as SVN r18207 ... r18212 -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ard Biesheuvel Sent: Tuesday, August 11, 2015 7:15 PM To: edk2-devel@lists.01.org; leif.lindh...@linaro.org; Liu, Yingke D Cc: Justen, Jordan L; Ard Biesheuvel Subject: [edk2] [PATCH v2 0/6] remove ARMGCC and ARMLINUXGCC toolchains Add one, remove two ... After adding the CLANG35 toolchain yesterday, I noticed there is quite an abundance of toolchains supported in EDK2, and in the ARM case, there is some overlap between ARMGCC/ARMLINUXGCC and the GCC4x toolchains that are defined for all architectures. Since the recent changes regarding the linker scripts and the GenFw changes to support relative AArch64 relocations, it is unsure whether these toolchains will still generate correct code. Instead of trying to find out, let's remove these altogether since the functionality they provide is also available via the GCC4x toolchains, which are kept in sync more closely with the other architectures they support. The first five patches remove any references to ARMGCC and ARMLINUXGCC from various packages, and patch #6 removes them entirely from tools_def and build_rule. Changes since v1: - added Daryl's ack to patch #1 - removed the outdated ArmVExpressInstructions.txt rather than fixing up its references to ARMGCC and ARMLINUXGCC (Leif) - instead of fixing the scripts and documentation under BeagleBoardPkg, remove the need for a build script by adding the binary configuration header to the FDF; that way we can remove the build scripts and docs entirely (Leif) Ard Biesheuvel (6): StdLib: remove mention of ARMGCC EmbeddedPkg: remove mention of ARMGCC ArmPlatformPkg: remove mention of ARMGCC and ARMLINUXGCC BeagleBoardPkg: fold configuration header into FD build BeagleBoardPkg: remove outdated build scripts and instructions BaseTools: remove ARMGCC and ARMLINUXGCC toolchains ArmPlatformPkg/ArmJunoPkg/Makefile | 4 +- ArmPlatformPkg/Documentation/ArmVExpressInstructions.txt | 169 - ArmPlatformPkg/Scripts/Makefile | 4 +- BaseTools/Conf/build_rule.template | 16 +- BaseTools/Conf/tools_def.template| 200 BeagleBoardPkg/BeagleBoardPkg.fdf| 13 +- BeagleBoardPkg/ConfigurationHeader.bin | Bin 0 - 512 bytes BeagleBoardPkg/b.bat | 68 --- BeagleBoardPkg/ba.bat| 68 --- BeagleBoardPkg/build.sh | 150 --- BeagleBoardPkg/readme.txt| 78 EmbeddedPkg/Library/GdbDebugAgent/GdbDebugAgent.c| 4 +- EmbeddedPkg/Library/GdbDebugAgent/gdbnotes.txt | 2 +- StdLib/StdLib.inc| 2 - 14 files changed, 21 insertions(+), 757 deletions(-) delete mode 100644 ArmPlatformPkg/Documentation/ArmVExpressInstructions.txt create mode 100644 BeagleBoardPkg/ConfigurationHeader.bin delete mode 100755 BeagleBoardPkg/b.bat delete mode 100755 BeagleBoardPkg/ba.bat delete mode 100755 BeagleBoardPkg/build.sh delete mode 100644 BeagleBoardPkg/readme.txt -- 1.9.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [patch 1/2] IntelFrameworkModulePkg:Refine the code in LegacyBootMaintUiLib
Reviewed-by: Qiu Shumin shumin@intel.com
-Original Message-
From: Bi, Dandan
Sent: Monday, August 10, 2015 5:32 PM
To: Dong, Eric; Qiu, Shumin; edk2-devel@lists.01.org
Subject: [patch 1/2] IntelFrameworkModulePkg:Refine the code in
LegacyBootMaintUiLib
Refine the code in LegacyBootMaintUiLib to prevent the potential risk.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi dandan...@intel.com
---
.../Library/LegacyBootMaintUiLib/LegacyBootMaintUi.c| 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git
a/IntelFrameworkModulePkg/Library/LegacyBootMaintUiLib/LegacyBootMaintUi.c
b/IntelFrameworkModulePkg/Library/LegacyBootMaintUiLib/LegacyBootMaintUi.c
index 6a76842..4ebba33 100644
--- a/IntelFrameworkModulePkg/Library/LegacyBootMaintUiLib/LegacyBootMaintUi.c
+++ b/IntelFrameworkModulePkg/Library/LegacyBootMaintUiLib/LegacyBootMai
+++ ntUi.c
@@ -142,10 +142,12 @@ OrderLegacyBootOption4SameType (
*DisBootOption = AllocatePool (BootOrderSize);
*DisBootOptionCount = 0;
*EnBootOptionCount = 0;
Index = 0;
+ ASSERT (BbsIndexArray != NULL);
+ ASSERT (DeviceTypeArray != NULL);
ASSERT (*EnBootOption != NULL);
ASSERT (*DisBootOption != NULL);
for (Index = 0; Index BootOrderSize / sizeof (UINT16); Index++) {
@@ -173,10 +175,11 @@ OrderLegacyBootOption4SameType (
// Record the corresponding Boot Option Numbers according to the DevOrder
// Record the EnBootOption and DisBootOption according to the DevOrder
//
StartPosition = BootOrderSize / sizeof (UINT16);
NewBootOption = AllocatePool (DevOrderCount * sizeof (UINT16));
+ ASSERT (NewBootOption != NULL);
while (DevOrderCount-- != 0) {
for (Index = 0; Index BootOrderSize / sizeof (UINT16); Index++) {
if (BbsIndexArray[Index] == (DevOrder[DevOrderCount] 0xFF)) {
StartPosition = MIN (StartPosition, Index);
NewBootOption[DevOrderCount] = BootOrder[Index]; @@ -1176,10 +1179,11
@@ GetLegacyOptionsOrder (
LEGACY_MENU_OPTION *OptionMenu;
UINT16 VarDevOrder;
UINTN Pos;
UINTN Bit;
UINT8 *DisMap;
+ UINTN TotalLength;
LegacyDev = NULL;
OptionMenu = NULL;
DisMap = ZeroMem (mLegacyBootOptionPrivate-MaintainMapData-DisableMap,
sizeof (mLegacyBootOptionPrivate-MaintainMapData-DisableMap));
@@ -1226,24 +1230,25 @@ GetLegacyOptionsOrder (
}
//
// Create oneof tag here for FD/HD/CD #1 #2
//
- for (Index = 0; Index OptionMenu-MenuNumber; Index++) {
-VarDevOrder = *(UINT16 *) ((UINT8 *) DevOrder + sizeof (BBS_TYPE) +
sizeof (UINT16) + Index * sizeof (UINT16));
-
+ for (Index = 0; Index OptionMenu-MenuNumber; Index++) {
+TotalLength = sizeof (BBS_TYPE) + sizeof (UINT16) + Index * sizeof
(UINT16);
+VarDevOrder = *(UINT16 *) ((UINT8 *) DevOrder + TotalLength);
+
if (0xFF00 == (VarDevOrder 0xFF00)) {
LegacyDev[Index] = 0xFF;
Pos = (VarDevOrder 0xFF) / 8;
Bit = 7 - ((VarDevOrder 0xFF) % 8);
DisMap[Pos] = (UINT8) (DisMap[Pos] | (UINT8) (1 Bit));
} else {
LegacyDev[Index] = VarDevOrder 0xFF;
}
}
- VarData += sizeof (BBS_TYPE);
+ VarData ++;
VarData += *(UINT16 *) VarData;
DevOrder = (LEGACY_DEV_ORDER_ENTRY *) VarData;
}
}
--
1.9.5.msysgit.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 0/5] secure boot support for ARM FVP
On 12 August 2015 at 01:53, Laszlo Ersek ler...@redhat.com wrote: On 08/08/15 14:00, Ard Biesheuvel wrote: This series adds support for using the Intel BDS with ArmVExpress-FVP, and for building it with UEFI Secure Boot enabled. Note that the former is a prerequisite of the latter, since the ARM BDS has no GUI for enrolling certificates and enabling secure boot. Patch #1 removes the PlatformIntelBdsLIb dependency on BdsLib, which is ARM BDS specific. (This patch has been sent out before as an RFC, and reviewed by Laszlo, but I had to add a 'Status = EFI_SUCCESS;' to GetConsoleDevicePathFromVariable () to fix a RELEASE build error, so I dropped the R-b) Patch #2 fixes a bug in some debug code that clobbers a EFI_STATUS var in the error path that is supposed to report it to the user. Patch #3 adds quiet boot/splash screen support to our PlatformIntelBdsLib Patch #4 enables the Intel BDS build of ArmVExpress-FVP, by introducing a define 'USE_ARM_BDS' which defaults to TRUE but can be disabled on the build command line to use the Intel BDS instead. Patch #5 enables the Secure Boot build of ArmVExpress-FVP, by introducing a define 'SECURE_BOOT_ENABLE' which defaults to FALSE but can be enabled on the build command line. Ard Biesheuvel (5): ArmPlatformPkg/PlatformIntelBdsLib: remove ARM BDS dependency ArmPlatformPkg/PlatformIntelBdsLib: fix error handling ArmPlatformPkg/PlatformIntelBdsLib: add splash screen support ArmPlatformPkg/ArmVExpressPkg: add support for the Intel BDS ArmPlatformPkg/ArmVExpressPkg: enable UEFI Secure Boot ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc | 18 + ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.fdf | 20 ++ ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc | 40 ArmPlatformPkg/Library/PlatformIntelBdsLib/IntelBdsPlatform.c | 36 -- ArmPlatformPkg/Library/PlatformIntelBdsLib/IntelBdsPlatform.h | 1 - ArmPlatformPkg/Library/PlatformIntelBdsLib/PlatformIntelBdsLib.inf | 2 +- 6 files changed, 104 insertions(+), 13 deletions(-) I was Cc'd on this, but given my review load and the fact that I'm not co-maintainer for ArmPlatformPkg, I'm de-queueing the series. Tell me if that's a problem. Not at all. I tend to use To: for maintainers, and Cc: more as an FYI, since you don't have any 'jurisdiction' over applying these patches anyway. Thanks, Ard. ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] BaseTools: add ARCH detection for AARCH64 and ARM
Reviewed-by: Liming Gao liming@intel.com -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ard Biesheuvel Sent: Tuesday, August 11, 2015 8:03 PM To: edk2-devel@lists.01.org; Liu, Yingke D Cc: leif.lindh...@linaro.org; Ard Biesheuvel Subject: [edk2] [PATCH] BaseTools: add ARCH detection for AARCH64 and ARM Add auto detection for the ARCH variable for AARCH64 and ARM systems. This allows us to do a native build of the BaseTools without the need to set ARCH externally. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org --- BaseTools/Source/C/GNUmakefile | 6 ++ 1 file changed, 6 insertions(+) diff --git a/BaseTools/Source/C/GNUmakefile b/BaseTools/Source/C/GNUmakefile index 6aa37e49fb9e..66baabb3f080 100644 --- a/BaseTools/Source/C/GNUmakefile +++ b/BaseTools/Source/C/GNUmakefile @@ -25,6 +25,12 @@ ifndef ARCH ifeq ($(patsubst i%86,IA32,$(uname_m)),IA32) ARCH=IA32 endif + ifneq (,$(findstring aarch64,$(uname_m))) +ARCH=AARCH64 + endif + ifneq (,$(findstring arm,$(uname_m))) +ARCH=ARM + endif ifndef ARCH $(info Could not detected ARCH from uname results) $(error ARCH is not defined!) -- 1.9.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 00/58] OvmfPkg: support SMM for better security (single VCPU, IA32)
Ping, because: On 07/25/15 01:00, Laszlo Ersek wrote: For a short introduction, jump to the last patch. Past discussions (just what I could easily find): http://thread.gmane.org/gmane.comp.bios.tianocore.devel/14243 http://thread.gmane.org/gmane.comp.bios.tianocore.devel/14243/focus=14330 The series is supposed to - *build* at every stage, using OvmfPkgIa32.dsc, with or without -D SMM_REQUIRE, - *build* at every stage, using any DSC file, without -D SMM_REQUIRE, - *work* at every stage, using any DSC file, without -D SMM_REQUIRE (ie. existing use cases don't regress). The feature being introduced (OvmfPkgIa32.dsc + -D SMM_REQUIRE) is not expected to *work* until the end of the series. In addition, using OvmfPkgIa32X64.dsc or OvmfPkgX64.dsc, the patch set even stops building after a point, *if* -D SMM_REQUIRE is passed. This is due to the unavailability of 64-bit open source components from Intel, and the build breakage is fully intentional -- it shows that the -D SMM_REQUIRE feature is build-level incomplete for OvmfPkgIa32X64.dsc and OvmfPkgX64.dsc, and marks precisely where further development is needed. ... I implemented this the last week of April and the first two weeks of May, approximately. Due to various reasons I had to set it aside at that point, and focus on other things to remain productive, but today I managed to rebase / refresh / retest the patch set, and now I'm posting it. Public branch: https://github.com/lersek/edk2/commits/smm3_v1_pub Anatomy of the series: 1 OvmfPkg: PlatformPei: clear CMOS 0xF after setting mBootMode 2 OvmfPkg: introduce -D SMM_REQUIRE and PcdSmmSmramRequire 3 MdePkg: BaseExtractGuidedSectionLib: allow forced reinit of handler table 4 OvmfPkg: set PcdBaseExtractGuidedSectionLibForceInit for SEC on SMM_REQUIRE 5 OvmfPkg: Sec: assert the build-time calculated end of the scratch buffer 6 OvmfPkg: decompress FVs on S3 resume if SMM_REQUIRE is set 7 OvmfPkg: PlatformPei: allow caching in AddReservedMemoryBaseSizeHob() 8 OvmfPkg: PlatformPei: account for TSEG size with PcdSmmSmramRequire set 9 OvmfPkg: add PEIM for providing TSEG-as-SMRAM during PEI 10 OvmfPkg: add DXE_DRIVER for providing TSEG-as-SMRAM during boot-time DXE 11 OvmfPkg: implement EFI_SMM_CONTROL2_PROTOCOL with a DXE_RUNTIME_DRIVER 12 OvmfPkg: pull in the SMM IPL and SMM core 13 OvmfPkg: pull in CpuIo2Smm driver 14 OvmfPkg: AcpiS3SaveDxe: don't fake LockBox protocol if SMM_REQUIRE 15 OvmfPkg: LockBox: -D SMM_REQUIRE excludes our fake lockbox 16 OvmfPkg: LockBox: use SMM stack with -D SMM_REQUIRE This part introduces the SMM_REQUIRE build flag, secures the special *memory* areas used by OVMF against a malicious guest OS, implements the basic SMM/SMRAM drivers, pulls in the SMM core, and switches the LockBox infrastructure to SMM / SMRAM. The organizing principle in this part is secure the special memory areas against tampering. the part above is independent of, and is needed regardless of, how we are going to import PiSmmCpuDxeSmm and the other similar drivers, and where from. Then, jumping ahead, 17 OvmfPkg: import PiSmmCpuDxeSmm from Quark_EDKII_v1.1.0/IA32FamilyCpuBasePkg 18 OvmfPkg: PiSmmCpuDxeSmm: eliminate SmmLib dependency 19 OvmfPkg: PiSmmCpuDxeSmm: eliminate CpuConfigLib linkage dependency 20 OvmfPkg: import CpuConfigLib header from Quark_EDKII_v1.1.0/IA32FamilyCpuBasePkg 21 OvmfPkg: import SocketLga775Lib header from Quark_EDKII_v1.1.0/IA32FamilyCpuBasePkg 22 OvmfPkg: import SmmCpuPlatformHookLibNull from Quark_EDKII_v1.1.0/IA32FamilyCpuBasePkg 23 OvmfPkg: resolve ReportStatusCodeLib for DXE_SMM_DRIVER modules 24 OvmfPkg: replace IA32FamilyCpuBasePkg.dec references with OvmfPkg.dec 25 OvmfPkg: replace gEfiCpuTokenSpaceGuid with gQuarkPortCpuTokenSpaceGuid 26 OvmfPkg: PiSmmCpuDxeSmm: fix namespace for PcdCpuMaxLogicalProcessorNumber 27 OvmfPkg: import PCDs from Quark_EDKII_v1.1.0/IA32FamilyCpuBasePkg 28 OvmfPkg: import three protocols from Quark_EDKII_v1.1.0/IA32FamilyCpuBasePkg 29 OvmfPkg: PiSmmCpuDxeSmm: fix warning about UINT32-to-(VOID*) conversion 30 OvmfPkg: PiSmmCpuDxeSmm: fix up pathname in include directive 31 OvmfPkg: build PiSmmCpuDxeSmm for -D SMM_REQUIRE 32 OvmfPkg: QuarkPort: drop ACPI_CPU_DATA.APState This segment ports the mammoth PiSmmCpuDxeSmm driver from the Quark distribution to OvmfPkg. Find the rationale in the first patch of the segment. Main goals: - this driver provides the central EFI_SMM_CONFIGURATION_PROTOCOL (with the SMM entry vector), - it is responsible for saving S3 data into SMRAM during normal boot, and restoring S3 state from SMRAM during S3 resume. 33 OvmfPkg: add skeleton QuarkPort/CpuS3DataDxe 34 OvmfPkg: QuarkPort/CpuS3DataDxe: fill in ACPI_CPU_DATA.StartupVector 35 OvmfPkg: QuarkPort/CpuS3DataDxe: handle IDT, GDT and MCE in ACPI_CPU_DATA 36 OvmfPkg:
Re: [edk2] [PATCH] BaseTools: add ARCH detection for AARCH64 and ARM
On 12 August 2015 at 04:52, Gao, Liming liming@intel.com wrote: Reviewed-by: Liming Gao liming@intel.com Thanks. Committed as SVN r18206 -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ard Biesheuvel Sent: Tuesday, August 11, 2015 8:03 PM To: edk2-devel@lists.01.org; Liu, Yingke D Cc: leif.lindh...@linaro.org; Ard Biesheuvel Subject: [edk2] [PATCH] BaseTools: add ARCH detection for AARCH64 and ARM Add auto detection for the ARCH variable for AARCH64 and ARM systems. This allows us to do a native build of the BaseTools without the need to set ARCH externally. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org --- BaseTools/Source/C/GNUmakefile | 6 ++ 1 file changed, 6 insertions(+) diff --git a/BaseTools/Source/C/GNUmakefile b/BaseTools/Source/C/GNUmakefile index 6aa37e49fb9e..66baabb3f080 100644 --- a/BaseTools/Source/C/GNUmakefile +++ b/BaseTools/Source/C/GNUmakefile @@ -25,6 +25,12 @@ ifndef ARCH ifeq ($(patsubst i%86,IA32,$(uname_m)),IA32) ARCH=IA32 endif + ifneq (,$(findstring aarch64,$(uname_m))) +ARCH=AARCH64 + endif + ifneq (,$(findstring arm,$(uname_m))) +ARCH=ARM + endif ifndef ARCH $(info Could not detected ARCH from uname results) $(error ARCH is not defined!) -- 1.9.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 2/2] BaseTools AARCH64: use tiny code model by default
On 08/10/15 12:27, Ard Biesheuvel wrote: The AARCH64 tiny code model produces more efficient code, since it uses relative symbol references rather than absolute references, i.e., an emitted relative reference refers to the symbol directly rather than a literal containing its 64-bit absolute address. This saves space in the binary, and reduces the number of relocation fixups that need to be applied by the PE/COFF loader. So now that we support relative relocations in GenFw, move to the tiny code model by default. Note that the large model can still be selected by individual modules by adding -mcmodel=large to the appropriate CC_FLAGS. 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 0c41c862af83..918348757767 100644 --- a/BaseTools/Conf/tools_def.template +++ b/BaseTools/Conf/tools_def.template @@ -3824,7 +3824,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 -fno-asynchronous-unwind-tables +DEFINE GCC_AARCH64_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mcmodel=tiny -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_DLINK2_FLAGS_COMMON = --script=$(EDK_TOOLS_PATH)/Scripts/GccBase.lds DEFINE GCC_IA32_X64_DLINK_COMMON = DEF(GCC_DLINK_FLAGS_COMMON) --gc-sections Since these are general flags, I'll defer to Leif, but you can add my Reviewed-by: Laszlo Ersek ler...@redhat.com ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [patch] MdeModulePkg:Use safe string functions in UiApp.
Reviewed-by: Qiu Shumin shumin@intel.com
-Original Message-
From: Bi, Dandan
Sent: Tuesday, August 11, 2015 11:07 AM
To: Dong, Eric; Qiu, Shumin; edk2-devel@lists.01.org
Subject: [patch] MdeModulePkg:Use safe string functions in UiApp.
Replace the unsafe string functions with the safe one in UiApp.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi dandan...@intel.com
---
.../Application/UiApp/BootMaint/BootOption.c | 30 ++
.../Application/UiApp/BootMaint/FormGuid.h | 2 +-
.../Application/UiApp/BootMaint/UpdatePage.c | 2 +-
.../Application/UiApp/BootMaint/Variable.c | 4 +--
.../Application/UiApp/BootMngr/BootManager.c | 6 +++--
.../Application/UiApp/DeviceMngr/DeviceManager.c | 2 +-
MdeModulePkg/Application/UiApp/FrontPage.c | 13 +-
7 files changed, 30 insertions(+), 29 deletions(-)
diff --git a/MdeModulePkg/Application/UiApp/BootMaint/BootOption.c
b/MdeModulePkg/Application/UiApp/BootMaint/BootOption.c
index fa88f63..5213e3c 100644
--- a/MdeModulePkg/Application/UiApp/BootMaint/BootOption.c
+++ b/MdeModulePkg/Application/UiApp/BootMaint/BootOption.c
@@ -784,11 +784,11 @@ BOpt_GetBootOptions (
StringSize = StrSize((UINT16*)LoadOptionPtr);
NewLoadContext-Description = AllocateZeroPool
(StrSize((UINT16*)LoadOptionPtr));
ASSERT (NewLoadContext-Description != NULL);
-StrCpy (NewLoadContext-Description, (UINT16*)LoadOptionPtr);
+StrCpyS (NewLoadContext-Description,
+ StrSize((UINT16*)LoadOptionPtr) / sizeof (UINT16),
+ (UINT16*)LoadOptionPtr);
ASSERT (NewLoadContext-Description != NULL);
NewMenuEntry-DisplayString = NewLoadContext-Description;
LoadOptionPtr += StringSize;
@@ -860,31 +860,29 @@ CHAR16 *
BOpt_AppendFileName (
IN CHAR16 *Str1,
IN CHAR16 *Str2
)
{
- UINTN Size1;
- UINTN Size2;
+ UINTN DestMax;
CHAR16 *Str;
CHAR16 *TmpStr;
CHAR16 *Ptr;
CHAR16 *LastSlash;
- Size1 = StrSize (Str1);
- Size2 = StrSize (Str2);
- Str = AllocateZeroPool (Size1 + Size2 + sizeof (CHAR16));
+ DestMax = (StrSize (Str1) + StrSize (Str2) + sizeof (CHAR16)) / sizeof
(CHAR16);
+ Str = AllocateZeroPool (DestMax * sizeof (CHAR16));
ASSERT (Str != NULL);
- TmpStr = AllocateZeroPool (Size1 + Size2 + sizeof (CHAR16));
+ TmpStr = AllocateZeroPool (DestMax * sizeof (CHAR16));
ASSERT (TmpStr != NULL);
- StrCat (Str, Str1);
+ StrCatS (Str, DestMax, Str1);
if (!((*Str == '\\') (*(Str + 1) == 0))) {
-StrCat (Str, L\\);
+StrCatS (Str, DestMax, L\\);
}
- StrCat (Str, Str2);
+ StrCatS (Str, DestMax, Str2);
Ptr = Str;
LastSlash = Str;
while (*Ptr != 0) {
if (*Ptr == '\\' *(Ptr + 1) == '.' *(Ptr + 2) == '.' *(Ptr + 3)
== L'\\') { @@ -893,27 +891,27 @@ BOpt_AppendFileName (
// DO NOT convert the .. if it is at the end of the string. This will
// break the .. behavior in changing directories.
//
//
- // Use TmpStr as a backup, as StrCpy in BaseLib does not handle copy of
two strings
+ // Use TmpStr as a backup, as StrCpyS in BaseLib does not handle
+ copy of two strings
// that overlap.
//
- StrCpy (TmpStr, Ptr + 3);
- StrCpy (LastSlash, TmpStr);
+ StrCpyS (TmpStr, DestMax, Ptr + 3);
+ StrCpyS (LastSlash, DestMax - (UINTN) (LastSlash - Str), TmpStr);
Ptr = LastSlash;
} else if (*Ptr == '\\' *(Ptr + 1) == '.' *(Ptr + 2) == '\\') {
//
// Convert a \.\ to a \
//
//
- // Use TmpStr as a backup, as StrCpy in BaseLib does not handle copy of
two strings
+ // Use TmpStr as a backup, as StrCpyS in BaseLib does not handle
+ copy of two strings
// that overlap.
//
- StrCpy (TmpStr, Ptr + 2);
- StrCpy (Ptr, TmpStr);
+ StrCpyS (TmpStr, DestMax, Ptr + 2);
+ StrCpyS (Ptr, DestMax - (UINTN) (Ptr - Str), TmpStr);
Ptr = LastSlash;
} else if (*Ptr == '\\') {
LastSlash = Ptr;
}
diff --git a/MdeModulePkg/Application/UiApp/BootMaint/FormGuid.h
b/MdeModulePkg/Application/UiApp/BootMaint/FormGuid.h
index c80d792..ab3d9c9 100644
--- a/MdeModulePkg/Application/UiApp/BootMaint/FormGuid.h
+++ b/MdeModulePkg/Application/UiApp/BootMaint/FormGuid.h
@@ -193,11 +193,11 @@ typedef struct {
///
/// This is the data structure used by File Explorer formset /// typedef
struct {
- UINT16 DescriptionData[75];
+ UINT16 DescriptionData[MAX_MENU_NUMBER];
UINT16 OptionalData[127];
UINT8 Active;
UINT8 ForceReconnect;
} FILE_EXPLORER_NV_DATA;
diff --git a/MdeModulePkg/Application/UiApp/BootMaint/UpdatePage.c
b/MdeModulePkg/Application/UiApp/BootMaint/UpdatePage.c
index d85f2ea..0e85a83 100644
--- a/MdeModulePkg/Application/UiApp/BootMaint/UpdatePage.c
+++ b/MdeModulePkg/Application/UiApp/BootMaint/UpdatePage.c
@@ -836,11 +836,11 @@ UpdateConModePage (
//
// Build
Re: [edk2] [PATCH 1/2] ArmVirtPkg: build our DEBUG Shell using the small code model
On 12 August 2015 at 01:58, Laszlo Ersek ler...@redhat.com wrote: On 08/10/15 12:27, Ard Biesheuvel wrote: The DEBUG build of the Shell exceeds 1 MB in size, which means that it cannot be built using the tiny code model. So force the use of the code model in this case. You forgot the word small. Can be fixed up at commit time. OK Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org --- ArmVirtPkg/ArmVirt.dsc.inc | 9 + 1 file changed, 9 insertions(+) diff --git a/ArmVirtPkg/ArmVirt.dsc.inc b/ArmVirtPkg/ArmVirt.dsc.inc index 7bba6eba05a8..1ff126b2f6dc 100644 --- a/ArmVirtPkg/ArmVirt.dsc.inc +++ b/ArmVirtPkg/ArmVirt.dsc.inc @@ -406,4 +406,13 @@ [Components.common] gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|0xFF gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE gEfiMdePkgTokenSpaceGuid.PcdUefiLibMaxPrintBufferSize|8000 + +BuildOptions + # + # The DEBUG target of the Shell module may well end up being over 1 MB + # in size, which exceeds the range of the AArch64 tiny code model. So + # override the code model to 'small' in this case. + # + GCC:DEBUG_*_AARCH64_CC_FLAGS = -mcmodel=small + GCC:DEBUG_*_AARCH64_DLINK_FLAGS = -z common-page-size=0x1000 } I hope all this finesse is going to work with gcc-4.8! :) GCC48 is my primary development toolchain, so that should be fine. For the record, I also tested with the new CLANG35 toolchain, which doesn't support the tiny code model, but happily accepts it as a command line parameter if it is superseded with 'small' later. I.e., after applying 2/2, we will pass -mcmodel=tiny ... -mcmodel=small to Clang, without any ill effects. Reviewed-by: Laszlo Ersek ler...@redhat.com Thanks, Ard. ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
