Converted the the word format of the documentation into markdown format
for PatchFv.py
V2: updated the commit message descripton
Cc: Jiewen Yao
Cc: Maurice Ma
Cc: Satya Yarlagadda
Cc: Satya Yarlagadda
Converted the the word format of the documentation into markdown format
for GenCfgOpt.py
Cc: Jiewen Yao
Cc: Maurice Ma
Cc: Satya Yarlagadda
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Giri P
I think the ver should reflect the spec version on which the shell was built.
I'm not sure why it would be 2.1 if built on 2.2 compliant code.
Thanks,
Michael A. Rothman
---
Let no excuse be a barrier to your success.
> On Aug 5, 2016,
Unfortunately the 'ver' command on the shell also shows up a 2.1 shell version
with the latest edk2/master.
So, we think it is rather a bug.
Regards,
Bhupesh
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Tim Lewis
> Sent: Saturday,
On 5 August 2016 at 21:24, Daniil Egranov wrote:
> Hi Ard,
>
>
>
> On 08/01/2016 09:22 AM, Ard Biesheuvel wrote:
>>
>> - indentation
>> - premature optimization of the thunking code, i.e., align function
>> prototypes
>>so we don't have to move arguments around or
Hi Ard,
On 08/01/2016 09:22 AM, Ard Biesheuvel wrote:
- indentation
- premature optimization of the thunking code, i.e., align function prototypes
so we don't have to move arguments around or duplicate them on the stack,
and perform tail calls where possible
- adhere to calling
Yes, but they are the same numbers. So I think this is probably a
The specification says (in the Shell protocol section's Related Defintiions):
#define EFI_SHELL_MAJOR_VERSION 2
#define EFI_SHELL_MINOR_VERSION 2
And, from ver.c:
ShellPrintHiiEx (
0,
Tim,
Yes, ver command would output that the version of the shell is different.
The #define below is specifically the version of the Protocol, not the version
of the spec.
It could have been a miss on the part of the committee, but that was hoe I
interpreted the non-change to the protocol
On 08/05/16 18:12, Cohen, Eugene wrote:
> We've been hit by this same kind of issue and it's really painful, especially
> as it affects shipping systems.
>
> Long term I think we need an extensible/revisioned data format so we can get
> forwards and backwards compatibility between NVRAM data
Jaben --
Are there no shell commands where the standard command-line parameters have
changed?
Tim
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Carsey,
Jaben
Sent: Friday, August 05, 2016 10:26 AM
To: Meenakshi Aggarwal
On 08/05/16 16:53, Ard Biesheuvel wrote:
> Both the ARM and the AARCH64 versions of the PrePi code (shared between
> ArmVirtQemuKernel and ArmVirtXen) 'preserve' values across a function
> call using registers that are not in fact callee saved. So fix that.
>
> Contributed-under: TianoCore
I think that that version (2.1) is correct for the version of the protocol.
The protocol API was not changed for the UEFI Shell 2.2.
That is the current version and should support the 2.2 spec.
-Jaben
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On
Reviewed-by: Jaben Carsey
> -Original Message-
> From: Zeng, Star
> Sent: Friday, August 5, 2016 2:02 AM
> To: edk2-devel@lists.01.org
> Cc: Zeng, Star ; Chan, Amy ; Ni,
> Ruiyu ; Carsey, Jaben
From: Alexei
This commit fixes a bug in the GIC v2 and v3 drivers where the GICC_EOIR
(End Of Interrupt Register) is written twice for a single interrupt.
GicV(2|3)IrqInterruptHandler() calls the Interrupt Handler and then
GicV(2|3)EndOfInterrupt() on exit:
We've been hit by this same kind of issue and it's really painful, especially
as it affects shipping systems.
Long term I think we need an extensible/revisioned data format so we can get
forwards and backwards compatibility between NVRAM data and FW.
> -Original Message-
> From:
I agree with your assessment about leaving the data structure as it is. I
just wanted to highlight it as it may impact others.
The bottom line is my development group is entirely responsible for vetting any
changes coming from the EDK2 into our product. This one slipped by us.
--Larry
Converted the the word format of the documentation into markdown format
for PatchFvUserManual
Cc: Jiewen Yao
Cc: Maurice Ma
Cc: Satya Yarlagadda
Cc: Satya Yarlagadda
Contributed-under:
The AARCH64 version of the PrePi code 'preserves' values across a function
call using registers that are not in fact callee saved. So fix that.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel
---
Both the ARM and the AARCH64 versions of the PrePi code (shared between
ArmVirtQemuKernel and ArmVirtXen) 'preserve' values across a function
call using registers that are not in fact callee saved. So fix that.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel
Hi Evan,
On 27/07/16 15:23, Leif Lindholm wrote:
Looks sensible to me.
Unless Evan has any objections?
On 27 July 2016 at 10:53, Sudeep Holla wrote:
The ACPI spec predates the AARCH64 architecture by 5 versions, so there
is no point in supporting anything below v5.0.
Hi Evan,
On 27/07/16 15:24, Leif Lindholm wrote:
Graeme/Evan?
On 27 July 2016 at 10:58, Sudeep Holla wrote:
ACPI 6.0 introduced LPI(Low Power Idle) states that provides an alternate
method to describe processor idle states.
LPI extensions leverages the processor
For X64/GCC, we use position independent code with hidden visibility
to inform the compiler that symbols references are never resolved at
runtime, which removes the need for PLTs and GOTs. However, in some
cases GCC has been reported to still emit PLT based relocations, which
we need to handle in
On 4 August 2016 at 18:01, Michael Zimmermann wrote:
> not directly related but could we add nostdinc too? At least for my platform
> that works perfectly and it prevents you from accidentally including any
> libc/libgcc/whatever headers from your toolchain.(nostdlib is
On 5 August 2016 at 16:26, Gao, Liming wrote:
> Reviewed-by: Liming Gao
>
Thanks all
Pushed as
59ceaa0a871d ArmPkg/ArmSoftFloatLib: disable LTO build for GCC
f8c51389c6db ArmPkg/CompilerIntrinsicsLib: make the default memset() weak
0667e985270b
I'm happy with these changes.
For the series:
Reviewed-by: Leif Lindholm
On 4 August 2016 at 15:42, Ard Biesheuvel wrote:
> This series addresses some issues that cause the build to be broken
> for ARM GCC5 at the moment when including
Converted the the word format of the documentation into markdown format
for PatchFvUserManual
Cc: Jiewen Yao
Cc: Maurice Ma
Cc: Satya Yarlagadda
Cc: Satya Yarlagadda
Contributed-under:
26 matches
Mail list logo