Hello All,
I've added some traces to narrow down the issue.
Once the NBP file downloaded, control will be given to it.
I've added some traces before StartImage() and after StartImage() call.
Following are the debug messages
// DEBUG message printed before StartImage()
// StartImage() called
wds
How can I unmount and mount a mass storage fs from UEFI shell?
In older EFI shells, I can do with "mount" command. But it just does
"mapping" in newer shell. It doesn't actually remounting the device.
Please help.
thanks
___
edk2-devel mailing list
edk
Andrew,
I think I have found an alternate fix for this XCODE5 specific
build failure. Since there appears to be a difference in the
linker behavior between MSFT/GCC/XCODE tool chains, I reviewed
the 'ld' command line options used in XCODE5 tool chain in
tools_def.txt.
There is a flag set call
Ard,
I agree that it would be good practice for a library instance to
only have the public interfaces(functions/data) that are declared
in the library class .h file.
I would be useful to have a report that showed the extra interfaces.
One additional constraint I just found with the MSFT tool ch
Reviewed-by: Andrew Fish mailto:af...@apple.com>>
> On May 23, 2017, at 4:10 PM, Michael Kinney
> wrote:
>
> https://bugzilla.tianocore.org/show_bug.cgi?id=572
>
> Fix local variable type in RegularExpressionDxe and an X64
> GAS(.S) file assembly instructon format in DebugSupportDxe.
> Both of
This patch-set requires and builds upon this submission:
https://lists.01.org/pipermail/edk2-devel/2017-May/010867.html
Leo Duran (2):
UefiCpuPkg: Add CPUID definitions for AMD.
UefiCpuPkg: Modify GetProcessorLocationByApicId() to support AMD.
UefiCpuPkg/Include/Register/Amd/Cpuid.h
Cc: Jordan Justen
Cc: Jeff Fan
Cc: Liming Gao
Cc: Brijesh Singh
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Leo Duran
---
UefiCpuPkg/Include/Register/Amd/Cpuid.h | 265 ++--
1 file changed, 256 insertions(+), 9 deletions(-)
diff --git a/
This patch-set builds requires and builds upon this submission:
https://lists.01.org/pipermail/edk2-devel/2017-May/010867.html
Leo Duran (2):
UefiCpuPkg: Add content and clean-up CPUID definitions for AMD.
UefiCpuPkg: Modify GetProcessorLocationByApicId() to support AMD.
UefiCpuPkg/Include/R
On 24 May 2017 at 13:26, dann frazier wrote:
> v2:
> * Replace -no-pie w/ -static for compat with GCC 4.9
>
For my understanding, could you elaborate on what goes wrong if you
omit -static / -no-pie?
> After Debian's toolchain switched to PIE by default, our edk2 builds began
> to fail to build
Hi Laszlo,
On 05/24/2017 08:06 AM, Laszlo Ersek wrote:
(2) please check the lines where you added (as I asked, thanks)
gEfiCallerBaseName and __FUNCTION__. On most lines, the indentation is
incorrect, relative to "DEBUG ((".
Just so I get it right this time, can you please confirm that below
On 24 May 2017 at 13:18, Kinney, Michael D wrote:
> Laszlo,
>
> I agree with the request to add 'static' to the variable declaration
> in the SecPeiDebugAgentLib. The variable name change will be retained
> because the same symbol name can still be confusing when debugging.
>
> The part that is m
v2:
* Replace -no-pie w/ -static for compat with GCC 4.9
After Debian's toolchain switched to PIE by default, our edk2 builds began
to fail to build (GCC49 w/ gcc 6.3). This patch fixes the build by forcing
off PIE for both ARM and AARCH64 builds.
Contributed-under: TianoCore Contribution Agreeme
Laszlo,
I agree with the request to add 'static' to the variable declaration
in the SecPeiDebugAgentLib. The variable name change will be retained
because the same symbol name can still be confusing when debugging.
The part that is more concerning is why this duplicate symbol reference
was not t
Reviewed-by: Michael D Kinney
Mike
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo
> Ersek
> Sent: Thursday, May 18, 2017 8:04 AM
> To: edk2-devel-01
> Cc: Kinney, Michael D ; Justen, Jordan L
>
> Subject: [edk2] [PATCH 7/8] QuarkPl
Mike or Kelly, can one of you please review this patch?
Thanks
Laszlo
On 05/18/17 17:04, Laszlo Ersek wrote:
> According to the PI spec, Volume 3,
> EFI_FIRMWARE_VOLUME_BLOCK2_PROTOCOL.EraseBlocks():
>
>> The variable argument list is a list of tuples. Each tuple describes a
>> range of LBAs to
Ray, can you please review this patch too?
Thanks,
Laszlo
On 05/18/17 17:04, Laszlo Ersek wrote:
> According to the PI spec, Volume 3,
> EFI_FIRMWARE_VOLUME_BLOCK2_PROTOCOL.EraseBlocks():
>
>> The variable argument list is a list of tuples. Each tuple describes a
>> range of LBAs to erase and co
Ray, can you please review this patch?
Thanks,
Laszlo
On 05/18/17 17:04, Laszlo Ersek wrote:
> According to the PI spec, Volume 3,
> EFI_FIRMWARE_VOLUME_BLOCK2_PROTOCOL.EraseBlocks():
>
>> The variable argument list is a list of tuples. Each tuple describes a
>> range of LBAs to erase and consis
(1) So, I don't think that splitting this driver off of AmdSevDxe is a
significant improvement, given that we still need to add AmdSevDxe to
the APRIORI DXE file, in order to clear the C bit on NonExistent and
MMIO ranges.
If Jordan thinks it is an improvement nonetheless, I don't mind the
split,
Karunakar,
Every Pool allocation has a header and a tail data structure that is outside of
the user visible data. Both these structures have signatures. The ASSERT you
are seeing is a bad signature in the header so that looks like a buffer
underflow. It could also be a use after free bug.
Head
On Thu, May 18, 2017 at 10:52:24PM +0100, Ard Biesheuvel wrote:
> On 18 May 2017 at 22:05, dann frazier wrote:
> > After Debian's toolchain switched to PIE by default, our edk2 builds began
> > to fail to build (GCC49 w/ gcc 6.3). This patch fixes the build by forcing
> > off PIE for both ARM and
cosmetic comments if a v6 is needed:
On 05/22/17 17:23, Brijesh Singh wrote:
> When SEV is enabled, the MMIO memory range must be mapped as unencrypted
> (i.e C-bit cleared).
>
> We need to clear the C-bit for MMIO GCD entries in order to cover the
> ranges that were added during the PEI phase (t
(+ Leif)
On 24 May 2017 at 01:34, Scott Telford wrote:
> Hi Ard,
>
> Firstly, this patch was meant for my edk2-staging branch, not mainline edk2 -
> sorry, forgot to edit the subject line!
>
Ah ok. In that case, do whatever you like :-)
> The issue is that, without this workaround, PCI(e) brid
comments below:
On 05/22/17 17:23, Brijesh Singh wrote:
> When SEV is enabled, use a bounce buffer to perform the DMA operation.
>
>
> Cc: Jordan Justen
> Cc: Laszlo Ersek
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Brijesh Singh
> ---
> OvmfPkg/Library/QemuFwC
comments below:
On 05/22/17 17:23, Brijesh Singh wrote:
> When SEV is enabled, the DMA must be performed on unencrypted pages.
> So when get asked to perfom FWCFG DMA read or write, we allocate a
> intermediate (bounce buffer) unencrypted buffer and use this buffer
> for DMA read or write.
>
>
>
Reviewed-by: Liming Gao
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Yonghong Zhu
> Sent: Wednesday, May 24, 2017 5:39 PM
> To: edk2-devel@lists.01.org
> Cc: Gao, Liming
> Subject: [edk2] [Patch] BaseTools: Correct if condition expressi
On 05/24/2017 08:06 AM, Laszlo Ersek wrote:
On 05/22/17 17:23, Brijesh Singh wrote:
Add Secure Encrypted Virtualization (SEV) helper library.
The library provides the routines to:
- set or clear memory encryption bit for a given memory region.
- query whether SEV is enabled.
Cc: Jordan Jus
On 24 May 2017 at 03:30, Leif Lindholm wrote:
> On Tue, May 23, 2017 at 03:36:24AM -0700, Ard Biesheuvel wrote:
>> On 22 May 2017 at 06:49, Leif Lindholm wrote:
>> > On Tue, May 02, 2017 at 11:32:02AM +0100, Ard Biesheuvel wrote:
>> >> This implements a driver that uses any SMMU compatible with t
On 05/22/17 17:23, Brijesh Singh wrote:
> Cc: Jordan Justen
> Cc: Laszlo Ersek
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Brijesh Singh
> ---
> OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgSec.c | 57
> 1 file changed, 57 insertions(+)
>
> diff --g
On 21 May 2017 at 21:05, Gao, Liming wrote:
> Reviewed-by: Liming Gao
>
Thanks. Pushed as 00b00cc57bfe0fca54c904d4dd44a263e243c88b
>>-Original Message-
>>From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
>>Sent: Friday, May 19, 2017 6:48 PM
>>To: edk2-devel@lists.01.org
>>Cc: leif
On 05/22/17 17:23, Brijesh Singh wrote:
> Add Secure Encrypted Virtualization (SEV) helper library.
> The library provides the routines to:
> - set or clear memory encryption bit for a given memory region.
> - query whether SEV is enabled.
>
>
> Cc: Jordan Justen
> Cc: Laszlo Ersek
> Contribu
On 24 May 2017 at 01:48, Laszlo Ersek wrote:
> CC Ard
>
> On 05/24/17 02:27, Kinney, Michael D wrote:
>> Andrew,
>>
>> I agree in this specific case, making the global variable static
>> should also resolve this issue.
>>
>> In general, we do not make module global variables static, so the
>> modu
On Wed, May 24, 2017 at 5:46 AM, Kinney, Michael D
wrote:
> Sergey,
>
> We also need to do a full search for use of variadic parameters to make
> sure we have a solution for all of them and update the EDK II C coding
> standard to make sure the rules for use of variadic parameters for
> maximum co
On Tue, May 23, 2017 at 03:36:24AM -0700, Ard Biesheuvel wrote:
> On 22 May 2017 at 06:49, Leif Lindholm wrote:
> > On Tue, May 02, 2017 at 11:32:02AM +0100, Ard Biesheuvel wrote:
> >> This implements a driver that uses any SMMU compatible with the generic
> >> ARM SMMU architecture to remap the l
Correct the if condition expression for DatumType == 'VOID*'. Current
this condition is not work since the DatumType is changed before we do
the value judgement.
Cc: Liming Gao
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yonghong Zhu
---
BaseTools/Source/Python/AutoGe
CC Ard
On 05/24/17 02:27, Kinney, Michael D wrote:
> Andrew,
>
> I agree in this specific case, making the global variable static
> should also resolve this issue.
>
> In general, we do not make module global variables static, so the
> module global can be shared across multiple source files in th
Hi Ard,
Firstly, this patch was meant for my edk2-staging branch, not mainline edk2 -
sorry, forgot to edit the subject line!
The issue is that, without this workaround, PCI(e) bridges and devices will be
detected multiple times during bus scanning, e.g. a bridge at bus 1 device 0
will also be
If APIC ID values are changed during AP functions execution, we need to update
new APIC ID values in local data structure accordingly.
But if APIC mode change happened during AP function execution, we do not support
APIC ID value changed.
Cc: Michael D Kinney
Cc: Eric Dong
Contributed-under: Ti
Current X2APIC is enabled in MpInitLib (used by CpuMpPei and CpuDxe) to follow
SDM suggestion. That means we only enable X2APIC if we found there are any
initial CPU ID value >= 255.
This patch is to provide one chance for platform to enable X2APIC even there is
no any initial CPU ID value >= 255.
https://bugzilla.tianocore.org/show_bug.cgi?id=575
v2:
Updated #1 comments.
Jeff Fan (2):
UefiCpuPkg/CpuCommonFeaturesLib: Support X2APIC enable
UefiCpuPkg/MpInitLib: Check APIC mode change around AP function
.../CpuCommonFeaturesLib/CpuCommonFeatures.h | 15 +
.../CpuCommonFeat
If APIC ID values are changed during AP functions execution, we need to update
new APIC ID values in local data structure accordingly.
But if APIC mode change happened during AP function execution, we do not support
APIC ID value changed.
Cc: Michael D Kinney
Cc: Eric Dong
Contributed-under: Ti
https://bugzilla.tianocore.org/show_bug.cgi?id=575
Jeff Fan (2):
UefiCpuPkg/CpuCommonFeaturesLib: Support X2APIC enable
UefiCpuPkg/MpInitLib: Check APIC mode change around AP function
.../CpuCommonFeaturesLib/CpuCommonFeatures.h | 15 +
.../CpuCommonFeaturesLib/CpuCommonFeaturesLib
Current X2APIC is enabled in MpInitLib (used by CpuMpPei and CpuDxe) to follow
SDM suggestion. That means we only enable X2APIC if we found there are any
initial CPU ID value >= 255.
This patch is to provide one chance for platform to enable X2APIC even there is
no any initial CPU ID value >= 255.
42 matches
Mail list logo