Hello all,
The commit, fa848a4048943251fc057fe8d6c5a82e01d2ffb6 adds the support for
HTTP Boot usage in home environment. Would anyone out here please help me the
procedure to verify this?
Best Regards,
Naveen
___
edk2-devel mailing list
edk2-deve
Hi Jannis,
The ESC is a scan code predefined in the DisplayEngineDxe driver, display
engine use these keys to make itself workable. Details about scan code see
below:
SCAN_CODE_TO_SCREEN_OPERATION gScanCodeToOperation[] = {
{
SCAN_UP, // arrow up operation
UiUp,
},
{
SCAN
Hello Naveen,
You can refer to the below wiki page for the detailed HTTP home environment
usage:
https://github.com/tianocore/tianocore.github.io/wiki/HTTP-Boot
Thanks,
Jiaxin
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Santhapur Nave
Hi Jiaxin,
Thanks for your prompt reply.
I've verified like the same and got the expected output.
Many Thanks,
Naveen
From: Wu, Jiaxin [jiaxin...@intel.com]
Sent: Monday, March 20, 2017 1:25 PM
To: Santhapur Naveen; edk2-devel@lists.01.org
Subject:
Great:).
> -Original Message-
> From: Santhapur Naveen [mailto:nave...@amiindia.co.in]
> Sent: Monday, March 20, 2017 4:14 PM
> To: Wu, Jiaxin ; edk2-devel@lists.01.org
> Subject: RE: Verifying HTTP Boot in Home environment
>
> Hi Jiaxin,
>
> Thanks for your prompt reply.
> I've
This serial of patches will add CPU featuers initialization on boot time.
1) One new Register CPU Features Library and instances are added to provide the
capability to register CPU feature's detect/initialize services.
2) One new NULL class CPU Commong Features Library instance is added to prov
Needn't to copy register table if AllocatedSize is 0.
v4:
Fix potential uninitialized variable issue.
v5:
Set DestinationRegisterTableList[Index].RegisterTableEntry before
RegisterTableEntry is updated.
Cc: Feng Tian
Cc: Michael Kinney
Contributed-under: TianoCore Contribution Agreement
This NULL CPU common Features Library instance will register some CPU features
defined in Intel(R) 64 and IA-32 Architectures Software Developer's Manual,
Volume 3, September 2016, Chapter 35 Model-Specific-Registers (MSR).
Add PCD PcdCpuClockModulationDutyCycle and PcdIsPowerOnReset consumed by N
Hi ,
Anyone knows whether edk2 have plan to implement EFI_REST_PROTOCOL ?
Currently I only see Rest.h but no real module install the prorocol. Thanks in
advance!
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/
MdeModulePkg/NvmExpressDxe: Memory leak fix
in async code flow
For async commands, the buffer allocated for Prp list is
not getting freed, which will cause memory leak for async
read write command. For example testing async command flow
with custom application to send multi
On 03/18/17 16:00, Leif Lindholm wrote:
> On Fri, Mar 17, 2017 at 09:47:24PM +0100, Laszlo Ersek wrote:
>> The presence of this protocol in the DXE protocol database implies that
>> the platform provides the operating system with an ACPI-based hardware
>> description. This is not necessarily mutual
On 03/18/17 16:06, Leif Lindholm wrote:
> On Fri, Mar 17, 2017 at 09:47:25PM +0100, Laszlo Ersek wrote:
>> The presence of this protocol in the DXE protocol database implies that
>> the platform provides the operating system with a Device Tree-based
>> hardware description. This is not necessarily
On 03/20/17 03:23, Zeng, Star wrote:
> Laszlo,
>
> Could the implementation have multiple instances of
> PlatformHasAcpiLib to return unsuccessfully in the constructor when
> EFI_ACPI_TABLE_PROTOCOL is not needed? And then eliminate
> PlatformHasAcpiDtDxe, gEdkiiPlatformHasAcpiProtocolGuid and
> gE
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=388
Add -NR (no-reset) option support, once the option is specified,
no reset will be trigger for the capsule with flag
CAPSULE_FLAGS_PERSIST_ACROSS_RESET and no CAPSULE_FLAGS_INITIATE_RESET.
Cc: Jiewen Yao
Cc: Xiaofeng Wang
Contributed-under:
On 03/20/17 03:16, Zeng, Star wrote:
> I am ok with this patch.
Thanks -- should I add an R-b or A-b in your name?
Thanks
Laszlo
>
> Feng and Hao, do you have any comments?
>
> Thanks,
> Star
> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Saturday, March
Oh got it, returning unsuccessfully in constructor of library does not work. :(
For (1), I definitely have no any comments. :)
For (2), I got no strong reason to support or reject it. We'd better could get
comments from Mike and Jiewen.
Thanks,
Star
-Original Message-
From: edk2-devel [m
Yes, please. :)
Thanks,
Star
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo
Ersek
Sent: Monday, March 20, 2017 5:46 PM
To: Zeng, Star ; edk2-devel-01
Cc: Wu, Hao A ; Tian, Feng ; Leif
Lindholm ; Ard Biesheuvel
Subject: Re: [edk2] [PATCH
On 03/20/17 10:57, Zeng, Star wrote:
> Yes, please. :)
Thank you all; I pushed this one patch in separation, as commit
76874be3d411.
Laszlo
>
> Thanks,
> Star
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo
> Ersek
> Sent: Monday, Ma
Hi Jiaxin,
I think my earlier result was in a corporate environment. I might have missed
something while verifying the same. :(
Please let me know if my understanding about this is correct or not.
The normal DHCP configuration in a corporate environment looks like this.
default-lease-time 600;
Hi,
I didn't test ArmVirtQemuKernel but I'm trying to use some of the code
for another platform.
So does this call ever succeed with PcdDxeNxMemoryProtectionPolicy
being enabled?
https://github.com/tianocore/edk2/blob/76874be3d411bf8daac051718e20932e0bf97d70/ArmVirtPkg/HighMemDxe/HighMemDxe.c#L95
On 20 March 2017 at 10:32, Michael Zimmermann wrote:
> Hi,
>
> I didn't test ArmVirtQemuKernel but I'm trying to use some of the code
> for another platform.
> So does this call ever succeed with PcdDxeNxMemoryProtectionPolicy
> being enabled?
> https://github.com/tianocore/edk2/blob/76874be3d411b
On 03/20/17 11:32, Michael Zimmermann wrote:
> Hi,
>
> I didn't test ArmVirtQemuKernel but I'm trying to use some of the code
> for another platform.
> So does this call ever succeed with PcdDxeNxMemoryProtectionPolicy
> being enabled?
> https://github.com/tianocore/edk2/blob/76874be3d411bf8daac05
UEFI executables that consist of a single read+write+exec PE/COFF section
trigger this message, but such a binary layout isn't actually an error.
The image can be launched alright, only image protection cannot be applied
to it fully.
One example that elicits the message is (some) Linux kernels (wi
> but then (I think) the DXE_CORE must
have set the same bit in the "supported" bitmask too, when the memory
was added.
that's the point, if my port behaves the same as ArmVirt, it doesn't.
for all memory, capabilities are 8008 and attributes are
for unused memory and 0
On 20 March 2017 at 11:09, Laszlo Ersek wrote:
> UEFI executables that consist of a single read+write+exec PE/COFF section
> trigger this message, but such a binary layout isn't actually an error.
> The image can be launched alright, only image protection cannot be applied
> to it fully.
>
> One e
Ard, why is SetMSetMemorySpaceAttributes being called in first place?
(ignoring the recent NX patch)
Looking at the initial GCD, it looks like unused memory usually
doesn't have any attributes set anyway.
Thanks
Michael
On Mon, Mar 20, 2017 at 12:04 PM, Ard Biesheuvel
wrote:
> On 20 March 2017 a
On 20 March 2017 at 11:16, Michael Zimmermann wrote:
> Ard, why is SetMSetMemorySpaceAttributes being called in first place?
> (ignoring the recent NX patch)
> Looking at the initial GCD, it looks like unused memory usually
> doesn't have any attributes set anyway.
>
Originally, we added the new
On 03/20/17 12:20, Ard Biesheuvel wrote:
> On 20 March 2017 at 11:16, Michael Zimmermann
> wrote:
>> Ard, why is SetMSetMemorySpaceAttributes being called in first place?
>> (ignoring the recent NX patch)
>> Looking at the initial GCD, it looks like unused memory usually
>> doesn't have any attri
On Mon, Mar 20, 2017 at 10:01:09AM +0100, Laszlo Ersek wrote:
> >> Because this protocol is not standard, it is prefixed with EDKII / Edkii,
> >> as seen elsewhere in MdeModulePkg and SecurityPkg, for example. (ARM / Arm
> >> doesn't look future-proof enough; future UEFI platforms could face the
>
On Sat, Mar 18, 2017 at 08:58:24PM +, Ard Biesheuvel wrote:
> Since commit 78c41ff519b1 ("ArmVirtPkg/FdtClientDxe: make DT table
> installation !ACPI dependent"), we inhibit the installation of the core
> ACPI tables when booting in DT mode, to relieve the OS from having to
> decide which hardw
On 20 March 2017 at 11:38, Laszlo Ersek wrote:
> On 03/20/17 12:20, Ard Biesheuvel wrote:
>> On 20 March 2017 at 11:16, Michael Zimmermann
>> wrote:
>>> Ard, why is SetMSetMemorySpaceAttributes being called in first place?
>>> (ignoring the recent NX patch)
>>> Looking at the initial GCD, it loo
Hello.
Are there anyone who tried to create UEFI driver support for raw nand flash,
for example, based on jffs2 or ubi/ubifs.
Maybe someone has a ready solution?
Thanks,
Michail.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/m
Invocations of EFI_ACPI_TABLE_PROTOCOL::UninstallAcpiTable() may
result in a crash when the value of PcdAcpiExposedTableVersions does
not include EFI_ACPI_TABLE_VERSION_1_0B.
The reason is that EFI_ACPI_TABLE_PROTOCOL::InstallAcpiTable() will
only populate the Rsdt1/Rsdt3 pointers when EFI_ACPI_TA
I agree to downgrade the logging level.
Can we add the comment, from log message to the comment in the C code?
Such as below:
==
//
// UEFI executables that consist of a single read+write+exec PE/COFF section
// isn't actually an error.
// The image can be launched alright,
We had some internal discussion on using gDS or using mCpu.
We decided to choose mCpu purposely at that moment, because we wanted to keep
UEFI memory map unchanged to avoid any potential compatibility issue.
Thank you
Yao Jiewen
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behal
On 03/20/17 15:08, Ard Biesheuvel wrote:
> On 20 March 2017 at 11:38, Laszlo Ersek wrote:
>> On 03/20/17 12:20, Ard Biesheuvel wrote:
>>> On 20 March 2017 at 11:16, Michael Zimmermann
>>> wrote:
Ard, why is SetMSetMemorySpaceAttributes being called in first place?
(ignoring the recent
On 03/20/17 16:09, Yao, Jiewen wrote:
> I agree to downgrade the logging level.
>
> Can we add the comment, from log message to the comment in the C code?
> Such as below:
> ==
> //
> // UEFI executables that consist of a single read+write+exec PE/COFF section
> // isn't ac
Do I understand correctly, that a PcdSet on a 'PcdsPatchableInModule'
is only visible to the current module?(SEC, driver, application, ...)
Because I've tested this and a PcdSet on
gArmTokenSpaceGuid.PcdSystemMemoryBase inisde PrePi is not visible
inside a DXE_DRIVER - which means that for everyone
On 03/20/17 17:06, Michael Zimmermann wrote:
> Do I understand correctly, that a PcdSet on a 'PcdsPatchableInModule'
> is only visible to the current module?(SEC, driver, application, ...)
I've no experience with patchable-in-module PCDs.
> Because I've tested this and a PcdSet on
> gArmTokenSpac
This patch unrolls REP INSx/OUTSx on IoRead/WriteFifo#() routines
when the SEV feature is enabled under a hypervisor environment.
This patch follows the series "[PATCH v3 00/10] IoLib class library",
which has already being pushed upstream.
Brijesh Singh (1):
MdePkg: BaseIoLibIntrinsic (IoLib c
From: Brijesh Singh
This patch unrolls REP INSx/OUTSx on IoRead/WriteFifo#() routines
when the SEV feature is enabled under a hypervisor environment.
Cc: Michael D Kinney
Cc: Liming Gao
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Brijesh Singh
Signed-off-by: Leo Dur
Hi Mike,
I agree with Laszlo's comments (including that this looks really
good!). Just one question below:
On Fri, Mar 17, 2017 at 01:07:59AM +, Kinney, Michael D wrote:
> Hello,
>
> The following is an RFC proposal for using GitBook for tianocore
> documentation. This RFC is also availabl
On 20 March 2017 at 16:06, Michael Zimmermann wrote:
> Do I understand correctly, that a PcdSet on a 'PcdsPatchableInModule'
> is only visible to the current module?(SEC, driver, application, ...)
Yes.
> Because I've tested this and a PcdSet on
> gArmTokenSpaceGuid.PcdSystemMemoryBase inisde Pre
> So the best way to pass information from PrePi to DXE is using HOBs.
Actually, it might be best for you to clone HighmemDxe if you need it,
and use a HOB instead.
I actually started a new port fully based on ArmVirtQemuKernel.
So for me it's not a problem to adjust the code, I just thought you
mi
Hi Leif,
Thanks for the feedback. I will update the RFC.
I only used my personal GitHub and GitBook accounts as a
staging area for the RFC discussion/approval.
I will migrate all GitHub and GitBook content to Tianocore
accounts once approved. The official GitBook account for
publishing will b
On 20 March 2017 at 15:24, Laszlo Ersek wrote:
> On 03/20/17 15:08, Ard Biesheuvel wrote:
>> On 20 March 2017 at 11:38, Laszlo Ersek wrote:
>>> On 03/20/17 12:20, Ard Biesheuvel wrote:
On 20 March 2017 at 11:16, Michael Zimmermann
wrote:
> Ard, why is SetMSetMemorySpaceAttributes
Add the missing call to EfiBootManagerDispatchDeferredImages() so that
images that have been deferred to after EndOfDxe (such as option ROMs)
will be loaded.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel
---
ArmPkg/Library/PlatformBootManagerLib/PlatformBm
Instead of indirecting the reference to the Shell binary via a PCD
that is defined in IntelFrameworkModulePkg, and which invariably
gets set to the same value by all users of this library, move the
reference into the code, and drop the reference to the PCD entirely.
Contributed-under: TianoCore Co
Replace the bootlogo implementation in QuietBoot.c with a call into
BootLogoLib, so we can get rid of some code.
While we're at it, add a missing call to dispatch deferred images, and
remove the IntelFrameworkModulePkg dependency directly, by switching to
a hardcoded Shell FILE_GUID reference rath
Replace the duplicated and outdated code in QuietBoot.c with a reference
to BootLogoLib, which provides the same functionality. This also allows
us to drop all references to IntelFrameworkModulePkg in this module.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuve
The memory protection code may be invoked to unprotect a driver when
DxeCore has not completed loading yet, in which case ImageAddress may
still be zero. So ignore the PdbPointer in this case, to prevent
PeCoffLoaderGetPdbPointer() from ASSERT()ing on a NULL value.
Contributed-under: TianoCore Con
Add the gEfiDebugImageInfoTableGuid, which is referenced in the code,
to both .INF files describing this module.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel
---
ArmPkg/Library/DefaultExceptionHandlerLib/DefaultExceptionHandlerLib.inf |
3 +++
ArmPkg
Currently, we only attempt to walk the call stack and print a backtrace
if the program counter refers to a location covered by a PE/COFF image.
However, regardless of the value of PC, the frame pointer may still have
a meaningful value, and so we can still produce the remainder of the
backtrace.
C
In order to be able to produce meaningful diagnostic output when taking
synchronous exceptions that have been caused by corruption of the stack
pointer, prepare the EL0 stack pointer and switch to it when handling the
'Sync exception using SPx' exception class. Other exception classes (of
which we
Make the default exception handler deal with corrupted SP or PC registers,
by switching to the EL0 stack pointer for sync exceptions, and walking the
call stack even if PC is 0x0 or otherwise invalid.
Ard Biesheuvel (3):
ArmPkg/DefaultExceptionHandlerLib: add missing GUID to .inf
ArmPkg/Defaul
Yes, the boot file URI need to be entered by user instead of the DHCP
extensions.
Thanks,
Jiaxin
> -Original Message-
> From: Santhapur Naveen [mailto:nave...@amiindia.co.in]
> Sent: Monday, March 20, 2017 6:16 PM
> To: Wu, Jiaxin ; edk2-devel@lists.01.org
> Subject: RE: Verifying HTTP B
Reviewed-by: Star Zeng
-Original Message-
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
Sent: Monday, March 20, 2017 10:52 PM
To: edk2-devel@lists.01.org; Zeng, Star ; Tian, Feng
Cc: Ard Biesheuvel
Subject: [PATCH] MdeModulePkg/AcpiTableDxe: consider version mask when removi
Reviewed-by: Hao Wu
I have removed some tab usages and trailing white space cases in the patch.
Pushed as commit: f2333c707dd04f069c102bcae004561ec590a3a0
Best Regards,
Hao Wu
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Suman Prakash
Ard:
On this case, UnprotectUefiImage() should be skipped, because the image is
not loaded.
Thanks
Liming
>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ard
>Biesheuvel
>Sent: Tuesday, March 21, 2017 4:45 AM
>To: edk2-devel@lists.01.org; Yao
Yes. Feature, FixedAtBuild and PatchableInModule PCD are module level; Dyanmic
and DynamicEx are platform level.
If you have case to share the data between the different modules, you can
configure PCD as Dynamic PCD.
Ard: do you meet with the issue on SetPcd() with dynamic PCD?
Thanks
>
Just an idea.
There is a way to do not introduce a new PCD, but reuse
PcdAcpiExposedTableVersions.
When PcdAcpiExposedTableVersions is configured to *0* (means no ANY ACPI table
should be exposed), AcpiTableDxe returns EFI_UNSUPPORTED in the driver
entrypoint.
Thanks,
Star
-Original Messa
Yes. Spec has no such limitation. I agree this change.
Reviewed-by: Liming Gao
Thanks
Liming
>-Original Message-
>From: Zeng, Star
>Sent: Monday, March 20, 2017 9:10 AM
>To: Ard Biesheuvel ; edk2-devel@lists.01.org;
>Tian, Feng
>Cc: Yao, Jiewen ; Gao, Liming
>; Zeng, Star
>Subject: RE
I feel a little confused on "but no CAPSULE_FLAGS_INITIATE_RESET".
> + Print(L" -NR: No reset will be trigger for the capsule with flag\n");
> + Print(L" CAPSULE_FLAGS_PERSIST_ACROSS_RESET but no
> CAPSULE_FLAGS_INITIATE_RESET.\n");
Do you mean "No impact to CAPSULE_FLAGS_INITIATE_RESE
Yes, right.
How about to like below?
Print(L" -NR: No reset will be triggered for the capsule\n");
Print(L" with CAPSULE_FLAGS_PERSIST_ACROSS_RESET and without
CAPSULE_FLAGS_INITIATE_RESET.\n");
Thanks,
Star
-Original Message-
From: Yao, Jiewen
Sent: Tuesday, March 21, 2017
OK
Reviewed-by: jiewen@intel.com
From: Zeng, Star
Sent: Tuesday, March 21, 2017 10:57 AM
To: Yao, Jiewen ; edk2-devel@lists.01.org
Cc: Xiaofeng Wang ; Zeng, Star
Subject: RE: [PATCH] MdeModulePkg CapsuleApp: Add -NR (no-reset) option support
Yes, right.
How about to like below?
Print(L"
Cc: Hegde Nagaraj P
Cc: Subramanian Sriram
Cc: Zhang Lubo
Cc: Ye Ting
Cc: Fu Siyuan
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wu Jiaxin
---
MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Nv.c| 9 ++---
MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Impl.
Cc: Hegde Nagaraj P
Cc: Subramanian Sriram
Cc: Zhang Lubo
Cc: Ye Ting
Cc: Fu Siyuan
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wu Jiaxin
---
NetworkPkg/DnsDxe/DnsProtocol.c | 4 ++--
NetworkPkg/TcpDxe/TcpMain.c | 5 +++--
NetworkPkg/UefiPxeBcDxe/PxeBcI
Cc: Hegde Nagaraj P
Cc: Subramanian Sriram
Cc: Zhang Lubo
Cc: Ye Ting
Cc: Fu Siyuan
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wu Jiaxin
Jiaxin Wu (2):
MdeModulePkg/Network: Fix potential ASSERT if NetIp4IsUnicast is called
NetworkPkg: Fix potential ASSERT if
Series Reviewed-by: Hegde, Nagaraj P
-Original Message-
From: Jiaxin Wu [mailto:jiaxin...@intel.com]
Sent: Tuesday, March 21, 2017 9:13 AM
To: edk2-devel@lists.01.org
Cc: Hegde, Nagaraj P ; Subramanian, Sriram
; Zhang Lubo ; Ye Ting
; Fu Siyuan ; Wu Jiaxin
Subject: [Patch 0/2] Fix po
69 matches
Mail list logo
