Mike,
As Krishna points out there are flavors of Apps. Do we want to have different
packages for different flavor of apps, or different dirs in a more generic App
package? Maybe we should define classes of UEFI Applications in the README.md
and give them a place to live.
I don't want to get
Ray,
Real HW platforms like Vlv2* and Quark* should be moved to
edk2-platforms. Virtual platforms such as Ovmf and EmulatorPkg
should stay in edk2 repo to support validation.
We should enter Tianocore BZ to move the real HW platforms.
Thanks,
Mike
> -Original Message-
> From: Ni,
Felix,
I disagree:) Sorry about that. :)
The commit you mentioned might be made by me (didn't checked).
Because I aimed to avoid calling PEI services from AP. That's a violation of PI
spec and not safe by design.
The AP calling standard services concern was raised by Andrew initially.
Thanks,
Krishna,
The reason there are applications inside MdeModulePkg/Application is that the
shell protocol was in ShellPkg when the app was developed and MdeModulePkg
cannot depend on ShellPkg (rule).
Now since shell protocol is moved to MdePkg, any apps can depend on shell
protocol. (In fact they
Mike,
It's a great idea to have another edk2-apps repo.
I have a question not quite related to this new repo but related to
edk2-platforms repo.
There are many platforms in edk2 repo as well, like Ovmf, Emulator,
Vlv2TbltDevicePkg.
What's your opinion/plan about these platforms?
>
DuetPkg depends on Legacy BIOS to provide a UEFI environment.
It was invented in the era when UEFI environment is hard to find.
Since now UEFI is very popular in PC area, we could stop the
official support of this package and remove it from the master.
And moreover, the tools only used by DuetPkg
Hi Krishna and Mike,
There might be applications which don't depend on ShellPkg or StdLib. I think
an extra repo is necessary. For example, the MicroPythonPkg (currently in
staging
branch) doesn't depend on ShellPkg and StdLib. Maybe we can consider to put it
in edk2-apps but not edk2-libc.
Kinney,
I always think there may be two kinds of apps:
1,some apps have dependency on uefi_shell(shell-lib,efi_shell_protocol,...they
usually execute under uefi_shell),I would call them "uefi_shell_application";
2,some apps have no dependency on uefi_shell(such as apps in
Leif,
I did consider the edk2-libc name. The port of Python 2.7
is in the AppPkg as well and it uses libc.
So the content of this new package is a combination of libc
And apps that use libc.
I am definitely open to alternate names. 2 options so far:
* edk2-apps
* edk2-libc
Thanks,
Mike
>
According to PI specification PEI Services table pointer is stored
right before ITD base. Starting from commit c563077a380437c1
BSP and AP have different IDT instances.
PEI Services table pointer was not initialized in the AP IDT instance.
As a result, any attempt to use functions from
On Thu, Nov 29, 2018 at 06:39:28PM +, Kinney, Michael D wrote:
> Hello,
>
> This RFC follows up on the proposal from Mark Doran to change the
> EDK II Project to an Apache 2.0 License.
>
> https://lists.01.org/pipermail/edk2-devel/2018-October/030385.html
>
>
> ** Please provide
On Thu, Nov 29, 2018 at 05:58:08PM +, Kinney, Michael D wrote:
> Hello,
>
> I would like to propose the creation of a new
> repository called edk2-apps. This repository
> would initially be used to host the following
> packages from the edk2 repository:
>
> * AppPkg
> * StdLib
> *
Would you be interested in going through this process with Phabricator, too?
Rebecca
On November 29, 2018 at 2:48:18 AM, Laszlo Ersek
(ler...@redhat.com(mailto:ler...@redhat.com)) wrote:
> On 11/29/18 02:07, Jeremiah Cox wrote:
> > I did a further experiment for you:
> >
Missed one of your suggested compiler related change in Patch 5. Have posted
patch 6.
Thanks
Ashish Singhal
-Original Message-
From: Ashish Singhal
Sent: Thursday, November 29, 2018 11:48 AM
To: 'Wu, Hao A' ; edk2-devel@lists.01.org
Subject: RE: [edk2] [PATCH v3 2/2]
Hello Hao,
Answers to your comments:
1. Patch 5 fixes the issue with accessing SD as well as eMMC files.
2. Using Private variable for controller version would mean I can only access
it in functions having an instance of the installed protocol which is not
possible in some functions for
Hello,
This RFC follows up on the proposal from Mark Doran to change the
EDK II Project to an Apache 2.0 License.
https://lists.01.org/pipermail/edk2-devel/2018-October/030385.html
** Please provide feedback on the proposal by Friday 12/7/18. **
I will be following up with pointers to
Add SDMA, ADMA2 and 26b data length support.
If V4 64 bit address mode is enabled in compatibility register,
program controller to enable V4 host mode and use appropriate
SDMA registers supporting 64 bit addresses.
If V4 64 bit address mode is enabled in compatibility register,
program
Add capability declaration for V4.x 64 bit system address support.
This would be used for host controllers working in version 4. Enable
64 bit DMA support in PCI layer if V3 or V4 64 bit support is
enabled in host capability register.
The usage of this new field does not need a guard for version
On 11/29/18 15:59, Gao, Liming wrote:
> Laszlo:
> I add my comments.
>
> Thanks
> Liming
>> -Original Message-
>> From: Laszlo Ersek [mailto:ler...@redhat.com]
>> Sent: Tuesday, November 27, 2018 10:52 PM
>> To: Ard Biesheuvel ; edk2-devel@lists.01.org
>> Cc: Gao, Liming ; Kinney,
On 11/29/18 14:12, Udit Kumar wrote:
> Thanks Laszlo,
>
>
>> I can only think of some terminal control sequences that are *not* printed to
>> the terminal when you don't enter UiApp manually. I don't understand how that
>> could cause the exact symptom you describe, but I have no better
On Wed, 28 Nov 2018 at 15:34, Ard Biesheuvel wrote:
>
> This v3 subsumes and/or supersedes
>
> [PATCH v2 00/13] ArmPkg, ArmVirtPkg: lift 40-bit IPA space limit
> [PATCH] MdePkg/ProcessorBind.h AARCH64: limit MAX_ADDRESS to 48 bits
> [PATCH v2 0/2] ArmVirtPkg: remove high peripheral space mapping
Hello,
I would like to propose the creation of a new
repository called edk2-apps. This repository
would initially be used to host the following
packages from the edk2 repository:
* AppPkg
* StdLib
* StdLibPrivateInternalFiles
These 3 packages provide support for the libc along
with
My comment is below.
1. Please don't update MemoryFence() implementation. It will impact all
consumer code. AsmLfence() is X86 specific API. You can implement the internal
function in the arch specific source file to call AsmLfence() for X86 and call
MemoryFence() for ARM. This internal
On Wed, Nov 28, 2018 at 03:33:57PM +0100, Ard Biesheuvel wrote:
> PcdPrePiCpuMemorySize is no longer used so drop the declarations from
> the package DEC file.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel
Reviewed-by: Leif Lindholm
> ---
>
On Wed, Nov 28, 2018 at 03:33:55PM +0100, Ard Biesheuvel wrote:
> Drop the reference to gEmbeddedTokenSpaceGuid.PcdPrePiCpuMemorySize
> which is never used.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel
Reviewed-by: Leif Lindholm
> ---
>
On Wed, Nov 28, 2018 at 03:33:53PM +0100, Ard Biesheuvel wrote:
> Derive the size of the GCD memory space map directly from the CPU's
> information registers rather than from the PcdPrePiCpuMemorySize PCD,
> which will be removed.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
>
On Wed, Nov 28, 2018 at 03:33:54PM +0100, Ard Biesheuvel wrote:
> Drop some PCD references that are not actually referenced from the
> PlatformPei code.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel
Reviewed-by: Leif Lindholm
> ---
>
On Wed, Nov 28, 2018 at 03:33:50PM +0100, Ard Biesheuvel wrote:
> Derive the size of the GCD memory space map directly from the CPU's
> information registers rather than from the PcdPrePiCpuMemorySize PCD,
> which will be removed.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
>
On Wed, Nov 28, 2018 at 03:33:51PM +0100, Ard Biesheuvel wrote:
> Derive the size of the GCD memory space map directly from the CPU's
> information registers rather than from the PcdPrePiCpuMemorySize PCD,
> which will be removed.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
>
On Wed, Nov 28, 2018 at 03:33:49PM +0100, Ard Biesheuvel wrote:
> In preparation of dropping PcdPrePiCpuMemorySize entirely, base the
> maximum size of the identity map on the capabilities of the CPU.
> Since that may exceed what is architecturally permitted when using
> 4 KB pages, take
On Wed, Nov 28, 2018 at 03:33:47PM +0100, Ard Biesheuvel wrote:
> Add a helper function that returns the maximum physical address space
> size as supported by the current CPU.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel
Reviewed-by: Leif Lindholm
On Wed, Nov 28, 2018 at 03:33:43PM +0100, Ard Biesheuvel wrote:
> Drop the declaration and the implementation of CreateHoblist(),
> which is not used anywhere.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel
Reviewed-by: Leif Lindholm
> ---
>
On Wed, Nov 28, 2018 at 03:33:42PM +0100, Ard Biesheuvel wrote:
> Remove this module: it is unused, and should not be used as an
> example going forward.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel
Reviewed-by: Leif Lindholm
> ---
>
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo
> Ersek
> Sent: Thursday, November 29, 2018 7:34 PM
> To: Ard Biesheuvel
> Cc: Andrew Jones ; edk2-devel@lists.01.org
> Subject: Re: [edk2] [PATCH v3 05/16] MdePkg/ProcessorBind.h
Reviewed-by: Jaben Carsey
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Ard Biesheuvel
> Sent: Thursday, November 29, 2018 4:31 AM
> To: edk2-devel@lists.01.org
> Cc: Laszlo Ersek ; Gao, Liming
> Subject: [edk2] [PATCH 6/6]
Reviewed-by: Jaben Carsey
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Ard Biesheuvel
> Sent: Thursday, November 29, 2018 4:31 AM
> To: edk2-devel@lists.01.org
> Cc: Laszlo Ersek ; Gao, Liming
> Subject: [edk2] [PATCH 4/6]
On Thu, 29 Nov 2018 at 16:15, Gao, Liming wrote:
>
> Do you verify which GCC arch? 32bit or 64bit or ARM?
>
64-bit ARM
> > -Original Message-
> > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> > Sent: Thursday, November 29, 2018 11:14 PM
> > To: Gao, Liming
> > Cc:
Reviewed-by: Jaben Carsey
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Ard Biesheuvel
> Sent: Thursday, November 29, 2018 4:31 AM
> To: edk2-devel@lists.01.org
> Cc: Laszlo Ersek ; Gao, Liming
> Subject: [edk2] [PATCH 2/6]
Reviewed-by: Jaben Carsey
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Ard Biesheuvel
> Sent: Thursday, November 29, 2018 4:31 AM
> To: edk2-devel@lists.01.org
> Cc: Laszlo Ersek ; Gao, Liming
> Subject: [edk2] [PATCH 3/6]
Do you verify which GCC arch? 32bit or 64bit or ARM?
> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Thursday, November 29, 2018 11:14 PM
> To: Gao, Liming
> Cc: edk2-devel@lists.01.org; Laszlo Ersek ; Zhu, Yonghong
> ; Feng, Bob C
>
> Subject:
On Thu, 29 Nov 2018 at 16:11, Gao, Liming wrote:
>
> Ard:
> I mean the build error. Besides, what test have you done with this patch
> set?
>
> CommonLib.c(1651): error C2220: warning treated as error - no 'object' file
> generated
> CommonLib.c(1651): warning C4133: 'function': incompatible
So, I'm actually mostly happy with this set, but this cover letter is
incorrect.
On Wed, Nov 21, 2018 at 06:14:51PM +0530, Chandni Cherukuri wrote:
> Changes since v1:
> - No code changes, posting this series again with correct patch subject
Plenty of code changes. Stopped the masking and
Ard:
I mean the build error. Besides, what test have you done with this patch set?
CommonLib.c(1651): error C2220: warning treated as error - no 'object' file
generated
CommonLib.c(1651): warning C4133: 'function': incompatible types - from 'UINTN
*' to 'UINT64 *'
NMAKE : fatal error U1077:
Laszlo:
I add my comments.
Thanks
Liming
> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Tuesday, November 27, 2018 10:52 PM
> To: Ard Biesheuvel ; edk2-devel@lists.01.org
> Cc: Gao, Liming ; Kinney, Michael D
> ; leif.lindh...@linaro.org;
>
Thanks Laszlo,
> I can only think of some terminal control sequences that are *not* printed to
> the terminal when you don't enter UiApp manually. I don't understand how that
> could cause the exact symptom you describe, but I have no better explanation.
>
> Can you try other serial
Don't use the native word size string to number parsing routines,
but instead, use the 64-bit one and cast to UINTN.
Currently, the only user is in Source/C/DevicePath/DevicePathFromText.c
which takes care to use Strtoi64 () unless it assumes the value fits
in 32-bit, so this change is a no-op
Parsing a string into an integer variable of the native word size
is not defined for the BaseTools, since the same tools may be used
to build firmware for different targets with different native word
sizes.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel
---
In the context of the BaseTools, there is no such thing as a native word
size, given that the same set of tools may be used to build a firmware
image consisting of both 32-bit and 64-bit modules.
So update StrToIpv4Address() and StrToIpv6Address() to use UINT64
types instead of UINTN types when
There should be no reason for the build tools to care about the native
word size of a particular target, so relying on a definition of MAX_UINTN
is definitely wrong, and most likely inaccurate on 32-bit build hosts.
So refactor the code in CommonLib and DevicePath so we no longer rely
on this
Replace invocations of StrHexToUintn() with StrHexToUint64(), so
that we can drop the former.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel
---
BaseTools/Source/C/DevicePath/DevicePathFromText.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
The maximum value that can be represented by the native word size
of the *target* should be irrelevant when compiling tools that
run on the build *host*. So drop the definition of MAX_UINTN, now
that we no longer use it.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard
Replace the default size limit of IsDevicePathValid() with a value
that does not depend on the native word size of the build host.
64 KB seems sufficient as the upper bound of a device path handled
by UEFI.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel
On 11/29/18 11:40, Ard Biesheuvel wrote:
> On Wed, 28 Nov 2018 at 19:41, Laszlo Ersek wrote:
>>
>> On 11/28/18 15:33, Ard Biesheuvel wrote:
>>> AArch64 supports the use of more than 48 bits for physical and/or
>>> virtual addressing, but only if the page size is set to 64 KB,
>>> which is not
On Wed, 28 Nov 2018 at 19:41, Laszlo Ersek wrote:
>
> On 11/28/18 15:33, Ard Biesheuvel wrote:
> > AArch64 supports the use of more than 48 bits for physical and/or
> > virtual addressing, but only if the page size is set to 64 KB,
> > which is not supported by UEFI. So redefine MAX_ADDRESS to
On 11/29/18 04:09, Udit Kumar wrote:
> Thanks for pointers Andrew
> But if I use emulated runtime variables or say efi=noruntime, I am getting
> same behavior.
> On device tree, I see device tree same in both cases.
>
> In case of direct boot, only user space console is corrupted whereas kernel
On 11/29/18 02:07, Jeremiah Cox wrote:
> I did a further experiment for you:
> https://github.com/lersek/edk2/pull/2
Thanks!
> I cannot rebase away my history from PRs...
> Hopefully you have a nice email trail too.
The emails are coming in nice, but I'm not universally pleased with the
Cc: Supreeth Venkatesh
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Eric Jin
---
.../EFI/Protocol/PKCS7Verify/BlackBoxTest/Guid.c | 5 +-
.../EFI/Protocol/PKCS7Verify/BlackBoxTest/Guid.h | 16 ++
.../BlackBoxTest/Pkcs7BBTestConformance.c | 303
Cc: Supreeth Venkatesh
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Eric Jin
---
.../EFI/Protocol/PKCS7Verify/BlackBoxTest/Guid.c |2 +
.../EFI/Protocol/PKCS7Verify/BlackBoxTest/Guid.h |7 +
.../PKCS7Verify/BlackBoxTest/Pkcs7BBTestData.c | 1466
As Yonghong has some other focus, change him from maintainer
to reviewer, Bob will be the new maintainer.
Cc: Bob Feng
Cc: Liming Gao
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Yonghong Zhu
---
Maintainers.txt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
59 matches
Mail list logo
