Reviewed-by: Ray Ni
> > -Original Message-
> > From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> > Gao, Zhichao
> > Sent: Monday, April 15, 2019 11:06 AM
> > To: devel@edk2.groups.io
> > Cc: Ni, Ray ; Gao, Liming
> > Subject: [edk2-devel] [PATCH 19/25] PcAtChipsetPk
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1597
Currently RTData are allocated at/after ReadyToBoot to store the
contents in HiiDatabase and the HII configurations for OS runtime
utilization.
Some platforms may meet S4 resume issue since the allocation after
ReadyToBoot cause memory map c
> On Apr 24, 2019, at 6:40 PM, Zhang, Chao B wrote:
>
> Hi Andrew:
>Tks for your explanation. The middle octet of StartingCHS (0x000200) is
> for Sector. Based on CHS to LBA conversion rule. It should be 0x02. I think
> it is an spec compliance issue.
> Partition Dxe driver doesn’t appl
Reviewed-by: Eric Dong
> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Dandan Bi
> Sent: Tuesday, April 23, 2019 3:01 PM
> To: devel@edk2.groups.io
> Cc: Gao, Liming ; Dong, Eric ;
> Wu, Hao A ; Ni, Ray
> Subject: [edk2-devel] [patch 1/2] Md
Reviewed-by: Eric Dong
> -Original Message-
> From: Bi, Dandan
> Sent: Tuesday, April 23, 2019 3:01 PM
> To: devel@edk2.groups.io
> Cc: Gao, Liming ; Dong, Eric ;
> Wu, Hao A ; Ni, Ray
> Subject: [patch 2/2] MdeModulePkg/FileExplorer: Set Handle to NULL after
> uninstall protocol
>
> RE
Hi Andrew:
Tks for your explanation. The middle octet of StartingCHS (0x000200) is for
Sector. Based on CHS to LBA conversion rule. It should be 0x02. I think it is
an spec compliance issue.
Partition Dxe driver doesn't apply such check so there is no problem.
Partition Pei is in BIOS TCB,
Reviewed-by: Chasel Chiu
> -Original Message-
> From: Kubacki, Michael A
> Sent: Thursday, April 25, 2019 9:09 AM
> To: devel@edk2.groups.io
> Cc: Desimone, Nathaniel L ; Chiu, Chasel
> ; Kinney, Michael D
> Subject: [edk2-platforms/devel-MinPlatform][PATCH v1 1/2]
> KabylakeOpenBoardP
Removes ASL code not referenced in the package.
Cc: Nate DeSimone
Cc: Chasel Chiu
Cc: Michael D Kinney
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kubacki
---
.../KabylakeOpenBoardPkg/Features/Tbt/AcpiTables/Tbt.asl | 12 ++--
1 file changed, 2 i
These patchset removes code that will not be used in these packages.
Cc: Nate DeSimone
Cc: Chasel Chiu
Cc: Michael D Kinney
Cc: Ankit Sinha
Michael Kubacki (2):
KabylakeOpenBoardPkg/AcpiTables: Remove dead code
ClevoOpenBoardPkg/AcpiTables: Remove dead code
.../Intel/ClevoOpenBoardPkg/F
Removes ASL code not referenced in the package.
Cc: Nate DeSimone
Cc: Ankit Sinha
Cc: Michael D Kinney
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kubacki
---
Platform/Intel/ClevoOpenBoardPkg/Features/Tbt/AcpiTables/Tbt.asl | 8
1 file changed, 8 de
Looks normal now.
Regards,
Jian
> -Original Message-
> From: Rebecca Cran [mailto:rebe...@bluestop.org]
> Sent: Thursday, April 25, 2019 3:37 AM
> To: devel@edk2.groups.io; ler...@redhat.com; phi...@redhat.com; Wang,
> Jian J ; ard.biesheu...@linaro.org
> Cc: Ye, Ting ; Cetola, Stephano
>
Hi Jordan,
The TemporaryRamSupport PPI is mandatory for FSP. The reason why is the stack
migration algorithm for FSP is quite different compared to the standard method
implemented in PEI core.
During FspMemoryInit(), PEI core runs on top of the bootloader stack. PEI core
is not the root of the
On 2019-04-24 13:17, Laszlo Ersek wrote:
>
> So I don't think there's anything to fix for package maintainers here.
> It seems that groups.io rewrites the sender address for Rebecca. I don't
> know why groups.io performs this rewrite, and why only for Rebecca.
>
> Stephano -- can you please ask gro
On 2019-04-24 13:17, Laszlo Ersek wrote:
>
> Again, in email that I get directly from Rebecca, the From field looks
> just fine.
>
> So I don't think there's anything to fix for package maintainers here.
> It seems that groups.io rewrites the sender address for Rebecca. I don't
> know why groups.io
+Stephano
On 04/24/19 11:25, Philippe Mathieu-Daudé wrote:
> On 4/22/19 3:46 PM, Wang, Jian J wrote:
>> crypto/uid.c is needed by VS201x toolchain on Windows. Let's still keep it
>> in inf.
>> That means we need this patch for build on FreeBSD.
>>
>> Reviewed-by: Jian J Wang
>
> Commit 1a734ed8
On 04/24/19 11:50, Laszlo Ersek wrote:
> That's great, but there are two more sections in edk2-libc's
> Maintainers.txt that are not replated to edk2-libc's packages:
sorry, s/replated/related/
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Onli
Changing subject line to include [edk2-test].
+ Eric
Prakriti,
With the disclaimer that UEFI SCT is intended for testing against UEFI
specification, I will try to answer your question in the way I interpreted it.
I am not sure whether you are asking how to test EFI_SHELL_PROTOCOL or is it
relat
On 04/24/19 13:36, Xu, Wei6 wrote:
> Hi,
>
> I have a question about protective MBR. Thanks a lot for your time.
> Why is the StartingCHS of protective MBR partition record set to 0x000100 in
> RedHat / Ubuntu? While UEFI spec defines it as 0x000200.
>
> Problem Statement:
> I met a problem when
On Wed, 24 Apr 2019 at 19:31, Kinney, Michael D
wrote:
>
> Hi Ard,
>
> I see no issues with using 'static' on more symbols.
>
> I am not sure how to enforce it, so it would be a good
> recommendation for code style and a good recommendation
> for a code reviews.
>
In Linux, it is one of the thing
Hi Ard,
I see no issues with using 'static' on more symbols.
I am not sure how to enforce it, so it would be a good
recommendation for code style and a good recommendation
for a code reviews.
Can you provide an example where code generation is
improved when 'static' is used. That would be good
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1748
> -Original Message-
> From: Gao, Liming
> Sent: Wednesday, April 24, 2019 12:22 AM
> To: devel@edk2.groups.io; Kubacki, Michael A
>
> Subject: RE: [edk2-platforms] [RFC] Migrate devel-MinPlatform branch to
> master branch
>
> Mich
Ard,
Using edk2 and edk2-non-osi as submodules in the edk2-platforms
repo does have some advantages. Each branch in edk2-platforms
can decide which release/tag/sha is required from dependent repos.
This provides a platform focused view of the EDK II project.
If using a release/tag/sha for the
On Wed, 24 Apr 2019 at 18:59, Kinney, Michael D
wrote:
>
> Hi Ard,
>
> I see a mix of use of 'static' and 'STATIC' in the sources.
>
> The reason to use STATIC is if it needs to be replaced with
> something other than 'static' for a specific compiler or
> debug scenario.
>
> Long ago, there were s
Hi Ard,
I see a mix of use of 'static' and 'STATIC' in the sources.
The reason to use STATIC is if it needs to be replaced with
something other than 'static' for a specific compiler or
debug scenario.
Long ago, there were some source level debug issue with
'static' symbols, so using the macro ST
Hi,
Can we change the name of the access size PCD so it
does not use Mmio in the name?
I am ok with not implementing support for different
access widths for I/O, but it would be good if the PCD
name and description is for the access width so it
could potentially be used for I/O in the future if
On 04/24/19 09:51, Jordan Justen wrote:
> Short summary: Despite being part of the Platorm Initialization
> Specificication, this proposal would remove support for the
> TemporaryRamSupport PPI from PEI Core. Arguably, this would mean the
> PEI Core does not support the PI spec, but we do not curre
The intent of the protective MBR was to prevent tools that did not understand
GPT to not think a GPT disk was blank. 20 years ago that made a lot of sense,
today it is kind of an obsolete concept.
The protective MBR was never intended to identify the disk as GPT, but it seems
it got used as a s
On 04/18/19 19:47, Laszlo Ersek wrote:
> Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=1710
> Repo: https://github.com/lersek/edk2.git
> Branch: covscan_bz_1710_v2
>
> Patch-level updates relative to v1 have been noted on the patches
> themselves. And earlier I described the chang
Hi Ard,
On 04/23/19 22:21, Ard Biesheuvel wrote:
> Update the binary RELEASE build targeting AARCH64 systems, created
> with Ubuntu's gcc 7.3.0 using the GCC5 profile. This fixes an issue
> in the previous build which was built against the wrong version of
> CacheMaintenanceLib.
>
> Repo: http:
Hi,
For me it looks good also,
I do not see any change that will not allow to call WS ME on reset (as we
currently have for Workstation).
BR
Adam
> -Original Message-
> From: Piwko, Maciej
> Sent: Wednesday, April 24, 2019 3:45 PM
> To: Gao, Zhichao ; Bu, Daocheng
> ; devel@edk2.groups.
śr., 24 kwi 2019 o 15:51 Ard Biesheuvel napisał(a):
>
> On Wed, 24 Apr 2019 at 15:48, Marcin Wojtas wrote:
> >
> > Hi Ard,
> >
> > śr., 24 kwi 2019 o 15:02 Ard Biesheuvel
> > napisał(a):
> > >
> > > On Wed, 24 Apr 2019 at 09:11, Ard Biesheuvel
> > > wrote:
> > > >
> > > > On Wed, 24 Apr 2019
Hello All:
Would like to clarify few information on the timings on the HTTP Boot /
Download performed through Windows / Linux and UEFI HTTP Boot.
There was a HTTP server running in California and when an 450 MB ISO tried to
downloaded from that below are the time took to download. The data ret
Hi,
For me the change seems fine.
The only concern that I have may be related to the fact, the resetting the
system we may also want to inform the ME engine about that fact and choose
proper reset type.
I'm adding Adam, who can comment on the reset functionality from ME UEFIFW
perspective.
Ada
On Wed, 24 Apr 2019 at 15:48, Marcin Wojtas wrote:
>
> Hi Ard,
>
> śr., 24 kwi 2019 o 15:02 Ard Biesheuvel
> napisał(a):
> >
> > On Wed, 24 Apr 2019 at 09:11, Ard Biesheuvel
> > wrote:
> > >
> > > On Wed, 24 Apr 2019 at 08:52, Marcin Wojtas wrote:
> > > >
> > > > From: Kornel Duleba
> > > >
Hi Ard,
śr., 24 kwi 2019 o 15:02 Ard Biesheuvel napisał(a):
>
> On Wed, 24 Apr 2019 at 09:11, Ard Biesheuvel
> wrote:
> >
> > On Wed, 24 Apr 2019 at 08:52, Marcin Wojtas wrote:
> > >
> > > From: Kornel Duleba
> > >
> > > This path enables support for reading variables directly from flash
> >
On Wed, 24 Apr 2019 at 15:33, Leif Lindholm wrote:
>
> On Wed, Apr 24, 2019 at 03:23:54PM +0200, Ard Biesheuvel wrote:
> > Add a conditional build time include of the prebuild X64 PE/COFF emulator
> > binary to some platforms that will be able to make use of it (i.e., have
> > usable PCI slots)
>
On Wed, Apr 24, 2019 at 03:29:52PM +0200, Ard Biesheuvel wrote:
> We have had capsule support enabled on this platform for a while now, so
> let's drop the hacked up flasher tool that we no longer have a need for.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Bie
On Wed, Apr 24, 2019 at 03:23:54PM +0200, Ard Biesheuvel wrote:
> Add a conditional build time include of the prebuild X64 PE/COFF emulator
> binary to some platforms that will be able to make use of it (i.e., have
> usable PCI slots)
>
> Changes since v1:
> - add Armada entry to the shared .fdf,
(+ Alan)
On Wed, 24 Apr 2019 at 15:29, Ard Biesheuvel wrote:
>
> We have had capsule support enabled on this platform for a while now, so
> let's drop the hacked up flasher tool that we no longer have a need for.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Bie
We have had capsule support enabled on this platform for a while now, so
let's drop the hacked up flasher tool that we no longer have a need for.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel
---
Platform/AMD/OverdriveBoard/OverdriveBoard.dsc
Add the X64 emulator to the build if '-D X64EMU_ENABLE=TRUE' is passed
on the build command line.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel
---
Platform/AMD/OverdriveBoard/OverdriveBoard.dsc | 5 +++--
Platform/AMD/OverdriveBoard/OverdriveBoard.fdf | 3
Add a conditional build time include of the prebuild X64 PE/COFF emulator
binary to some platforms that will be able to make use of it (i.e., have
usable PCI slots)
Changes since v1:
- add Armada entry to the shared .fdf, and drop the default FALSE value (at
the request of Marcin)
Ard Biesheuve
Add the X64 emulator to the build if '-D X64EMU_ENABLE=TRUE' is passed
on the build command line. Note that this only works on AARCH64 builds.
Also note that the edk2-non-osi repository needs to be listed in the
PACKAGES_PATH environment variable.
Contributed-under: TianoCore Contribution Agreemen
Add the X64 emulator to the build if '-D X64EMU_ENABLE=TRUE' is passed
on the build command line. Note that this only works on AARCH64 builds.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel
---
Platform/Socionext/DeveloperBox/DeveloperBox.dsc | 1 +
Platfor
On Wed, 24 Apr 2019 at 11:05, Jagadeesh Ujja wrote:
>
> Fwd to new EDKII development mailing list.
>
> hi Ard,
>
> Sorry about missing your previous comment and adding here.
>
> "Hello Jagadeesh,
>
> Why are you moving this driver into edk2-platforms? I'd prefer to have
>
> it alongside the non-
On Wed, 24 Apr 2019 at 15:02, Gao, Liming wrote:
>
> Ard:
> I prefer to keep them as the separate repo. One dummy Git repo can be
> introduced to submodule edk2, edk2-platform, edk2-non-osi, and others. User
> can use this git repo to get everything.
>
That is not really my point.
A git subm
Ard:
I prefer to keep them as the separate repo. One dummy Git repo can be
introduced to submodule edk2, edk2-platform, edk2-non-osi, and others. User can
use this git repo to get everything.
Thanks
Liming
> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
On Wed, 24 Apr 2019 at 09:11, Ard Biesheuvel wrote:
>
> On Wed, 24 Apr 2019 at 08:52, Marcin Wojtas wrote:
> >
> > From: Kornel Duleba
> >
> > This path enables support for reading variables directly from flash without
> > relying on it to be memory mapped. It adds PcdSpiMemoryMapped PCD that
>
On Wed, 24 Apr 2019 at 14:46, Gao, Liming wrote:
>
>
> So, we need to consider the combination of edk2 master + edk2-platform
> master. When do the incompatible change in edk2 master, we need to update
> edk2-platform master together.
>
Yes, it is either that, or we separate them properly, by p
So, we need to consider the combination of edk2 master + edk2-platform master.
When do the incompatible change in edk2 master, we need to update edk2-platform
master together.
Thanks
Liming
> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Wednesday, April 24
Hi,
I have a question about protective MBR. Thanks a lot for your time.
Why is the StartingCHS of protective MBR partition record set to 0x000100 in
RedHat / Ubuntu? While UEFI spec defines it as 0x000200.
Problem Statement:
I met a problem when trying to use FatPei to fetch a file on the GPT pa
Hi Zhichao,
On 04/24/19 06:58, Zhichao Gao wrote:
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1740
>
> V1:
> The DebugLib instances of DebugPortProtocol, ConOut and StdErr
> use a global variable "mExitBootServicesEvent" which is in
> conflict with the same variable in StatusCodeHandler
On 04/24/19 12:24, Laszlo Ersek wrote:
> ... Actually, you mention "the phase immediately after the
> PlatformBootManagerAfterConsole() is the best choice". So how about the
> following approach:
>
> (1) Introduce a new protocol (an edk2 extension). The UEFI protocol
> database is supposed to con
On 04/24/19 04:37, Gao, Zhichao wrote:
>
>
>> -Original Message-
>> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
>> Laszlo Ersek
>> Sent: Tuesday, April 23, 2019 9:51 PM
>> To: Gao, Zhichao ; devel@edk2.groups.io
>> Cc: Aaron Antone ; Wang, Jian J
>> ; Wu, Hao A ;
On 04/23/19 19:52, Rebecca Cran wrote:
> On 2019-04-18 17:26, Laszlo Ersek wrote:
>>
>> (1) Introduce stable *branches* to the development model. Those would be
>> forked off at the stable tags (well, at some of them).
>
>
> Would this be _re_ introducing stable branches?
Yes.
> As explained in
On 04/23/19 16:30, liyi 00215672 wrote:
> Hi Laszlo,
>
> Glad to get your detailed advices, it's useful for us.
>
> We can give a label like "New feature" or "Bug fixed" to state the
> patch or BZ, then the LTS maintainer can easy to distinguish whether put
> them(patch or BZ) into
On 04/23/19 18:26, Ard Biesheuvel wrote:
> On Thu, 4 Apr 2019 at 15:52, Dandan Bi wrote:
>>
>> We will remove IntelFrameworkModulePkg,but BaseUefiTianoCustomDecompressLib
>> in it
>> may still need to be used. So move BaseUefiTianoCustomDecompressLib from
>> IntelFrameworkModulePkg to MdeModulePk
On 04/23/19 23:43, Kinney, Michael D wrote:
> Hi Laszlo,
>
> Many topics in here. Please let me know if I missed anything.
>
> 1) I did use git filter-branch to extract the history of these
>packages. The script I ran is shown below. It results in
>a local repo in the directory edk2-f
Hi,
I want to test if my interface is working or not using SCT framework, like give
IP address to interface and then run ping command.
Any pointers how can I achieve same?
Thanks,
Prakriti
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Onl
On 4/22/19 3:46 PM, Wang, Jian J wrote:
> crypto/uid.c is needed by VS201x toolchain on Windows. Let's still keep it in
> inf.
> That means we need this patch for build on FreeBSD.
>
> Reviewed-by: Jian J Wang
Commit 1a734ed85fda71630c795832e6d24ea560caf739 has weird authorship
again: rebecca v
From: "Tien Hock, Loh"
Adds support for Intel Stratix 10 Platform.
Signed-off-by: "Tien Hock, Loh"
Cc: Ard Biesheuvel
Cc: Leif Lindholm
Cc: Michael D Kinney
--
v2
- Updates ShellBinPkg with ShellPkg
---
.../Drivers/IntelPlatformDxe/IntelPlatformDxe.c| 43 ++
.../Drivers/IntelPlatformD
Fwd to new EDKII development mailing list.
hi Ard,
Sorry about missing your previous comment and adding here.
"Hello Jagadeesh,
Why are you moving this driver into edk2-platforms? I'd prefer to have
it alongside the non-MM version instead.
That would allow us to share a lot more code betwee
From: "Tien Hock, Loh"
Some busses doesn't allow 8 bit MMIO read/write, this adds support for
32 bits read/write
Signed-off-by: "Tien Hock, Loh"
Cc: Jian J Wang
Cc: Hao Wu
--
v3
- Updates the Pcd to be UINT8 to allow more options such as 16 bits access
in the future
- Updated copyright date
On Wed, 24 Apr 2019 at 06:59, Gao, Zhichao wrote:
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1740
>
> Add a 'static' descriptor to the global variables that only
> used in a single file to minimize the name collisions.
> This is only for the varable named 'mExitBootServicesEvent'.
>
>
The community feedback is to keep IntelFrameworkxxxPkg in 201905 tag. So, move
this retirement to next tag 201908.
Signed-off-by: Liming Gao
---
EDK-II-Release-Planning.md | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/EDK-II-Release-Planning.md b/EDK-II-Release-Planning
Short summary: Despite being part of the Platorm Initialization
Specificication, this proposal would remove support for the
TemporaryRamSupport PPI from PEI Core. Arguably, this would mean the
PEI Core does not support the PI spec, but we do not currently know if
any platforms require this PPI.
Ma
Michael:
I think this change is good. Could you submit one BZ for it?
Thanks
Liming
>-Original Message-
>From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
>Kubacki, Michael A
>Sent: Friday, April 19, 2019 5:12 AM
>To: 'devel@edk2.groups.io'
>Subject: [edk2-devel] [ed
On Wed, 24 Apr 2019 at 02:09, Dandan Bi wrote:
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1683
>
> We have moved the BaseUefiTianoCustomDecompressLib
> from IntelFrameworkModulePkg to MdeModulePkg, so
> update consumers accordingly.
>
> Cc: Ard Biesheuvel
> Cc: Leif Lindholm
> Cc: M
On Wed, 24 Apr 2019 at 08:52, Marcin Wojtas wrote:
>
> From: Kornel Duleba
>
> This path enables support for reading variables directly from flash without
> relying on it to be memory mapped. It adds PcdSpiMemoryMapped PCD that
> allows to switch between the modes. When in non-memory-mapped mode
On Wed, 24 Apr 2019 at 07:05, Hao Wu wrote:
>
> After commit 57df17fe26, some static check reports suspicous NULL pointer
> deference at line:
>
> Entry->MachineType = Entry->Emulator->MachineType;
>^^^
>
> within function PeCoffEmuProtocolNotify().
>
> Howeve
Hi Mike, Hao,
Replies inlined.
On Wed, 2019-04-24 at 03:45 +, Michael D Kinney wrote:
> One issue I see is using a FeatureFlag PCD.
> These PCDs can only be TRUE or FALSE, so they can not be
> extended later. A FixedAtBuild PCD of type BOOL has the
> same issue.
>
> It would be better to u
Got it. Thanks!
From: Fu, Siyuan
Sent: Wednesday, April 24, 2019 2:52 PM
To: Gao, Liming ; devel@edk2.groups.io
Cc: Wu, Jiaxin
Subject: RE: [RFC] Propose to remove IpSecDxe
Hi, Liming
Yes, Wang Fan already sent out the patch to remove both IpSecDxe and the
IpsecConfig application. See the patc
72 matches
Mail list logo
