On Thu, 6 Dec 2018 at 00:56, Gao, Liming wrote:
>
> Reviewed-by: Liming Gao
>
Thanks all
Pushed as 6e8cad49a09d..67938bcc9d9e
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ard
> > Biesheuvel
> > Sent: Wednesday, December 5, 2018
On 12/6/2018 11:11 AM, Shenglei Zhang wrote:
-DuetPkg
-W:https://github.com/tianocore/tianocore.github.io/wiki/DuetPkg
-M: Ruiyu Ni
-M: Hao Wu
Reviewed-by: Ruiyu Ni
--
Thanks,
Ray
___
edk2-devel mailing list
edk2-devel@lists.01.org
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=596
BaseLib interfaces are used in this library but not declared in module's
inf file. This patch fix this situation to keep inf and its code in
consistency. No functionality or interface change are involved.
Cc: Qin Long
Cc: Ting Ye
Reviewed-by: jiewen@intel.com
> -Original Message-
> From: Chiu, Chasel
> Sent: Wednesday, December 5, 2018 8:49 AM
> To: edk2-devel@lists.01.org
> Cc: Yao, Jiewen ; Desimone, Nathaniel L
> ; Zeng, Star ; Chiu,
> Chasel
> Subject: [PATCH v2] Maintainers.txt: Change package maintainer
Since DuetPkg is due to be removed, Maintainers.txt
should also be updated.
https://bugzilla.tianocore.org/show_bug.cgi?id=1322
Cc: Ruiyu Ni
Cc: Hao Wu
Cc: Andrew Fish
Cc: Laszlo Ersek
Cc: Leif Lindholm
Cc: Michael D Kinney
Contributed-under: TianoCore Contribution Agreement 1.1
Reviewed-by: Liming Gao for BaseTools part.
Besides, please also update Maintainers.txt to remove DuetPkg.
>-Original Message-
>From: Ni, Ruiyu
>Sent: Thursday, December 06, 2018 10:58 AM
>To: Zhang, Shenglei ; edk2-devel@lists.01.org
>Cc: Wu, Hao A ; Zhu, Yonghong
>; Gao, Liming
Reviewed-by: Ruiyu Ni
Thanks/Ray
> -Original Message-
> From: Zhang, Shenglei
> Sent: Monday, December 3, 2018 10:18 AM
> To: edk2-devel@lists.01.org
> Cc: Ni, Ruiyu ; Wu, Hao A ; Zhu,
> Yonghong ; Gao, Liming
> Subject: [PATCH v4 0/2] Remove DuetPkg and unused tools
>
> DuetPkg
Leif/Ard,
Any comments on this v2 patch for this?
Thanks,
Jeff
From: Jeff Brasen
Sent: Wednesday, November 28, 2018 1:36:16 PM
To: edk2-devel@lists.01.org
Cc: Jeff Brasen; Ard Biesheuvel; Leif Lindholm; Grish Pathak
Subject: [PATCH v2] ArmPkg/ArmScmiDxe:
Andrew,
I think there are two aspects here:
1) What's the final solution we would like to see?
I think DebugLibMpSafe and a fake PEI Services Table that you are proposing are
good ideas.
Ideally, it should still be possible to use the real PEI Services table by
overriding a library class.
How reproduce this issue? Could you list your step?
>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>Prem Kumar
>Sent: Thursday, December 06, 2018 2:37 AM
>To: edk2-devel@lists.01.org
>Subject: [edk2] Build fail using latest UDK2018
>
>Hi All,
>
Reviewed-by: Liming Gao
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ard
> Biesheuvel
> Sent: Wednesday, December 5, 2018 4:24 PM
> To: edk2-devel@lists.01.org
> Cc: ler...@redhat.com; Gao, Liming
> Subject: [edk2] [PATCH]
You didn't CC anyone, but that is the right syntax for adding the shell command.
Reviewed-by: Jaben Carsey
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Ard Biesheuvel
> Sent: Wednesday, December 05, 2018 10:50 AM
> To:
The PCDs containing the default MAC addresses are of type UINT64,
and so the byte order needs to be inverted. As they are currently,
both default MAC addresses are invalid since they have the multicast
bit set.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel
Enable the 'acpiview' UEFI shell command so we can inspect the ACPI
tables at boot time.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel
---
Platform/AMD/OverdriveBoard/OverdriveBoard.dsc | 1 +
Platform/LeMaker/CelloBoard/CelloBoard.dsc
Move the XGBE out of the DSDT, and along with it the logic that patches
the correct MAC address into the device nodes. However, this time we
patch the SSDT binary directly rather than relying on intermediate output
of an outdated version of the iasl compiler.
Contributed-under: TianoCore
Set the GOP resolution to 0x0 so that the resolution will be
chosen by the driver, usually based on the capabilities of
the connected display.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel
---
Platform/AMD/OverdriveBoard/OverdriveBoard.dsc | 3 +++
1 file
Instead of adding yet another redefinition in the next patch, move
the silicon revision testing macros into a shared header file.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel
---
Silicon/AMD/Styx/Common/SocVersion.h | 19
Instead of emitting the DSDT by incorporating the intermediate output
of [some version of] the iasl compiler, move the DSDT source file to
the ACPI platform driver, which will install it directly. This permits
us to drop a lot of cruft related to handling of this intermediate
output.
Instead of poking DSDT _STA method bytecode to make it return something
else depending on whether we are running on B1 silicon, move the B1 only
peripherals to a separate SSDT and only install it when running on
compatible hardware.
Contributed-under: TianoCore Contribution Agreement 1.1
Primarily, this series gets rid of the hacked up way this platform
patches the DSDT at build time, by #include'ing intermediate output
of the iasl compiler [or some version of it, at least]
While at it, apply some other cleanups/improvements.
Ard Biesheuvel (6):
Silicon/AMD/Styx: move SOC
Hi All,
When I try to build UDK2018 package I'm facing below build error.
*Note:*
When I delete the build folder the same build error is not happening.
The same build error is not happening when build is happening for first
time.
Any pointers is appreciated.
build.py...
: error C0DE:
On Wednesday, 5 December 2018 05:55:41 MST Laszlo Ersek wrote:
> Can you assist with the following please?
Also, a couple of notes:
Go to https://code.bluestop.org/settings/user/lersek/ to configure preferences
related to emails (http/plain), diffs etc.
Install the arcanist package on your
On Wednesday, 5 December 2018 05:55:41 MST Laszlo Ersek wrote:
> (1) Pls. explain to me how I can create an edk2 clone at
> . :)
You don't. In a production system it may be possible to clone from either
GitHub or code.bluestop.org (which mirrors github), but the clone URL given
when you click
Hey All,
Quick reminder that our community meetings will held in about 24 hours
or so. Remember that there are two: one at 17:00 GMT and one at 3:00 GMT
(+1 day), so please attend the one that is most convenient for your
timezone (or come to both! :) ).
Details and calendar invites here:
On 12/4/2018 10:20 AM, Philippe Mathieu-Daudé wrote:
Hi Stephano,
I'll run your checklist [*] with GitLab on Thursday.
Perfect, thank you Philippe.
Cheers,
Stephano
___
edk2-devel mailing list
edk2-devel@lists.01.org
edk2-stable201811 tag has been created. its planning can be removed.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Liming Gao
---
EDK-II-Release-Planning.md | 24
1 file changed, 24 deletions(-)
diff --git a/EDK-II-Release-Planning.md
https://bugzilla.tianocore.org/show_bug.cgi?id=1364
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Liming Gao
---
Readme.md | 4
1 file changed, 4 insertions(+)
diff --git a/Readme.md b/Readme.md
index 1ef0780ee0..bf7c97cd2b 100644
--- a/Readme.md
+++ b/Readme.md
On 12/03/18 22:39, Rebecca Cran wrote:
> On Monday, 3 December 2018 02:29:28 MST Laszlo Ersek wrote:
>> On 11/29/18 22:20, Rebecca Cran wrote:
>>> Would you be interested in going through this process with Phabricator,
>>> too?
>> Sure! Just tell me where to create an account.
>
> Go to
Hi,
You may try "ifconfig.efi" under shell, which supports Ip4Config2 protocol.
The source code is available under
ShellPkg\Library\UefiShellNetwork1CommandsLib\Ifconfig.c
Thanks,
Ting
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
On 12/05/18 09:24, Ard Biesheuvel wrote:
> The macro MAX_ADDRESS represents the largest virtual address that
> is valid for a certain architecture. For the BaseTools, this quantity
> is irrelevant, since the same tools can be used to build for different
> targets.
>
> Since we only refer to it in
On 5/12/18 9:24, Ard Biesheuvel wrote:
> The macro MAX_ADDRESS represents the largest virtual address that
> is valid for a certain architecture. For the BaseTools, this quantity
> is irrelevant, since the same tools can be used to build for different
> targets.
>
> Since we only refer to it in a
Add dummy RPC handler for RPCs that are not implemented as control
should be returned back to OP-TEE in case any RPC is invoked.
Cc: Ard Biesheuvel
Cc: Leif Lindholm
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sumit Garg
---
ArmPkg/Library/OpteeLib/OpteeSmc.h | 3
On Fri, Sep 21, 2018 at 08:26:04AM +, Chris Co wrote:
> This adds support for using the SD host controller on
> NXP i.MX platforms.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Christopher Co
> Cc: Ard Biesheuvel
> Cc: Leif Lindholm
> Cc: Michael D Kinney
>
On Wed, 5 Dec 2018 at 09:45, Leif Lindholm wrote:
> Hi Nariman,
>
> Sorry, one more round: can you replace the tags for 'text` and
> ```text
> more text
> even more text
> ```
> please?
>
No problem, will scrub and resend!
>
> And the with **text**?
>
> (And if I missed any more inline
Hi Nariman,
Sorry, one more round: can you replace the tags for 'text` and
```text
more text
even more text
```
please?
And the with **text**?
(And if I missed any more inline HTML, please convert that too.)
Regards,
Leif
On Fri, Nov 30, 2018 at 01:56:36PM +, Nariman Poushin wrote:
>
Hi,
Do we have any ipconfig.efi type utility to see the IP address details on shell
(all the existing utilities are old and does not support new Ipconfig2 protocol)
Regards,
Ankit Singh
___
edk2-devel mailing list
edk2-devel@lists.01.org
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1376
Today's implementation reuses the 32bit MMIO resource requested by
all PCI devices MMIO BARs when shadowing the option ROM.
Take a simple example, a system has only one PCI device. It requires
8MB 32bit MMIO and contains a 4MB option ROM.
The macro MAX_ADDRESS represents the largest virtual address that
is valid for a certain architecture. For the BaseTools, this quantity
is irrelevant, since the same tools can be used to build for different
targets.
Since we only refer to it in a single place, which is an ASSERT() that
doesn't
On Wed, 5 Dec 2018 at 01:04, Gao, Liming wrote:
>
> Reviewed-by: Liming Gao for this serials.
>
Thanks all
Series pushed as 64ab2c82e8f6..8efc6d84ca41
(with the requested MAX_UINT16 -> MAX_UINT32 change applied)
> On patch 4, I have the same comments to Laszlo.
>
> >-Original
39 matches
Mail list logo
