Reviewed-by: Nate DeSimone
-Original Message-
From: Desimone, Ashley E
Sent: Wednesday, March 4, 2020 5:49 PM
To: devel@edk2.groups.io
Cc: Desimone, Nathaniel L ; Pandya, Puja
; Bjorge, Erik C
Subject: [edk2-staging/EdkRepo] [PATCH] EdkRepo: Correct typo in error strings
Fix typo of
Sorry let me clarify a little more. I don't doubt that you spending the time
to validate a patch using OVMF catches issues and regressions. I am very
appreciative of that effort, my point is you could do that without being in the
edk2 tree and in fact we need to enable and request that more do
Correct an error case in the checkout function defined in:
common/common_repo_functions.py where the need to perform a
sparse reset was not correctly calculated.
Signed-off-by: Ashley E Desimone
Cc: Nate DeSimone
Cc: Puja Pandya
Cc: Erik Bjorge
---
edkrepo/common/common_repo_functions.py | 13
On 03/07/20 10:10, Ard Biesheuvel wrote:
> Some mostly cosmetic tweaks to the AArch64 MMU code that are mostly unrelated
> to the actual fixes and improvements I posted earlier, so I am posting them
> separately.
>
> Ard Biesheuvel (2):
> ArmPkg/ArmMmuLib AARCH64: drop pointless page table memo
On 03/07/20 09:38, Ard Biesheuvel wrote:
> I finally got fed up with the state of the AArch64 MMU handling code, and
> decided to rewrite it before rebasing the cache invalidation fix onto
> it.
>
> Changes since v3:
> - move code for better diffing
> - free allocated page tables on failure if it
Hi Ard,
On 03/07/20 14:34, Ard Biesheuvel wrote:
> Currently, depending on the size of the region being (re)mapped, the
> page table manipulation code may replace a table entry with a block entry,
> even if the existing table entry uses different mapping attributes to
> describe different parts of
On 03/07/20 00:04, Laszlo Ersek wrote:
> When the MDE_CPU_IA32 macro is not defined, there is no access to the
> "KernelImageHandle" local variable in QemuStartKernelImage(). This breaks
> the OvmfPkgIa32X64 and OvmfPkgX64 platform builds, at least with gcc-8.
>
> Move the local variable to the in
On 03/09/20 23:54, Laszlo Ersek wrote:
> On 03/09/20 07:08, Sean via Groups.Io wrote:
>> From someone who has developed and maintained platforms with edk2 for
>> the last decade +, I can tell you that having OVMF in edk2 hasn't kept
>> the tree free from regressions.
>
> Of course. Changes to cor
On 03/09/20 07:08, Sean via Groups.Io wrote:
> Ard/Lazlo,
>
> I find your position on OvmfPkg, ArmVirtPkg,and edk2-platforms in edk2
> to be detrimental to the overall success of the edk2 project. The
> majority of edk2 consumers already have to deal with their platform
> not being part of the edk
Laszlo,
My guess is the Mergify only allows commands from
GitHub users with admin roles on a repo. Which
would explain why I can submit those commands but
you and Sean got that message.
I would prefer that this condition never occur
and we never need to use these commands. It sounds
like Merg
Laszlo,
If the dev branch that is being submitted as a PR
contains the merge commit, or that developer use the
one of the github features to rebase, the merge
commit can be introduced.
When a PR is in this state, the developer need to
clean up their history locally and do a forced
push or open a
Hello again,
On 03/08/20 20:53, Kinney, Michael D wrote:
> This one is failing PatchCheck with a missing Signed-off-by
> https://github.com/tianocore/edk2/pull/430
The lack of signed-off-by is a red herring.
Ard's pull request
https://github.com/tianocore/edk2/pull/430
consists of fou
On 03/09/20 20:29, Laszlo Ersek wrote:
> mergify.io didn't respond to my ticket
They have gotten back to me since; quote:
On 03/09/20 14:10, Mehdi Abaakouk wrote:
> We are aware of the issue and working on a fix. We recently implement
> a Github recommendation about caching Github API HTTP call
On 03/09/20 20:29, Laszlo Ersek wrote:
> Hi Mike,
>
> On 03/08/20 20:53, Kinney, Michael D wrote:
>> I added the @Mergifyio refresh to these PRs.
>>
>> This one was merged:
>> https://github.com/tianocore/edk2/pull/427
>>
>> This one is failing PatchCheck with a missing Signed-off-by
>>
Hi Mike,
On 03/08/20 20:53, Kinney, Michael D wrote:
> I added the @Mergifyio refresh to these PRs.
>
> This one was merged:
> https://github.com/tianocore/edk2/pull/427
>
> This one is failing PatchCheck with a missing Signed-off-by
> https://github.com/tianocore/edk2/pull/430
>
>
Silence 2 warnings from pep.asl:
* "Warning 3133 - Unknown reserved name (_GPI/_GCI/_GDI)"
* "Warning 3150 - Empty Resource Template", which is caused by
section "Name (_CRS, ResourceTemplate () {})"
Remove "Offset(0)" in Xhci.asl, which produces the warning:
"Unnecessary/redundant use of Offse
This addresses the following warnings, that are generated during
compilation of the RPi firmware:
--
/usr/src/Build/RPi4/DEBUG_GCC5/AARCH64/Platform/RaspberryPi/AcpiTables/AcpiTables/OUTPUT/./Dsdt.
165: })
Warning 3150
This fixes "WARNING: default value re-defined with different value"
being produced when trying to set default values for the Scaled
VModes in ConfigDxeHii.vfr.
This warning is generated regardless of what the default value is
being set to and since we don't actually care about setting a default
va
On Sat, Mar 07, 2020 at 14:34:13 +0100, Ard Biesheuvel wrote:
> Last one, I promise :-)
>
> The new ArmMmuLib code is easier to reason about, so that is what I did:
> currently, when we create mappings that cover existing table entries, we
> may end up overwriting those with block entries without
On 2020.03.08 05:31, Andrei Warkentin wrote:
For Pi 4, the custom CPU frequency range goes all the way up to 2.2GHz.
The acrobatics with CHIPSET_CUSTOM_CPU_CLOCK_HELP_TOKEN in the VFR
are required as the preprocessor is not run on the UNI (strings) file.
Testing: Pi 4 (saw correct help message,
Zhiju:
Please specify the command of copy source file PcdValueCommon.c in the
generated Makefile instead of do it in python script.
Thanks
Liming
> -Original Message-
> From: Fan, ZhijuX
> Sent: Monday, March 9, 2020 3:09 PM
> To: devel@edk2.groups.io
> Cc: Gao, Liming ; Feng, Bob C ;
BZ:2583:
https://bugzilla.tianocore.org/show_bug.cgi?id=2583
Current DxeIpl has bindings for different processor
architectures, this results in MdeModulePkg has the
dependence with processor architecture packages such as
ArmPkg or RiscVPkg. This also leads CI testing to error
during package depend
BZ:2562:
https://bugzilla.tianocore.org/show_bug.cgi?id=2562
Add RISC-V architecture on RISC-V EDK2 CI testing.
Signed-off-by: Abner Chang
Cc: Bret Barkelew
Cc: Sean Brogan
Cc: Leif Lindholm
Cc: Michael D Kinney
Cc: Gilbert Chen
Cc: Daniel Helmut Schaefer
Signed-off-by: Abner Chang
---
BZ:2562:
https://bugzilla.tianocore.org/show_bug.cgi?id=2562
Add yaml file for EDK2 CI testing on RiscVPkg.
Signed-off-by: Abner Chang
Cc: Bret Barkelew
Cc: Sean Brogan
Cc: Leif Lindholm
Cc: Gilbert Chen
Cc: Daniel Helmut Schaefer
Signed-off-by: Abner Chang
---
RiscVPkg/RiscVPkg.ci.yaml
BZ:2562:
https://bugzilla.tianocore.org/show_bug.cgi?id=2562
Add yaml file for EDK2 CI testing on RiscVPlatformPkg.
Signed-off-by: Abner Chang
Cc: Bret Barkelew
Cc: Sean Brogan
Cc: Leif Lindholm
Cc: Gilbert Chen
Cc: Daniel Helmut Schaefer
Signed-off-by: Abner Chang
---
RiscVPlatformPkg/R
Address Sean's comments on "edk2/master PATCH RISC-V CI v1".
- Remove dependency of RiscVPkg from MdeModulePkg.ci.yaml.
- Add SHA to gcc_riscv64_unknown_ext_dep.yaml
- Create empty ExtendWords in both RiscVPkg.ci.yaml and
RiscVPlatformPkg.ci.yaml.
BZ:2562:
https://bugzilla.tianocore.org/show_bug.
BZ:2562:
https://bugzilla.tianocore.org/show_bug.cgi?id=2562
Add RISC-V architecture on RISC-V EDK2 CI.
Signed-off-by: Abner Chang
Cc: Bret Barkelew
Cc: Sean Brogan
Cc: Leif Lindholm
Cc: Michael D Kinney
Cc: Gilbert Chen
Cc: Daniel Helmut Schaefer
Signed-off-by: Abner Chang
---
.azurepi
BZ:2562:
https://bugzilla.tianocore.org/show_bug.cgi?id=2562
EDK CI for RISC-V architecture
Enable RISC-V architecture for RISC-V EDK2 CI testing.
Signed-off-by: Abner Chang
Cc: Bret Barkelew
Cc: Sean Brogan
Cc: Bob Feng
Cc: Leif Lindholm
Cc: Michael D Kinney
Cc: Liming Gao
Cc: Gilbert C
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2568
PcdValueInit shares the same Edk2\BaseTools\Source\C\PcdValueCommon.obj.
To avoid the conflict, it should copy this file to its output directory,
If so, PcdValueCommon.obj file will be private for PcdValueInit
Cc: Liming Gao
Cc: Bob Feng
S
29 matches
Mail list logo
