On 28 February 2018 at 07:56, Michael Zimmermann
wrote:
> I feel like both of you misunderstood my intention.
> As I said in my initial mail, I'm not arguing the spec - I know that
> StartImage must be called from TPL_APPLICATION.
>
> I'm just discussing a bug inside EmbeddedPkg/Application/Androi
On 28 February 2018 at 02:41, Gao, Liming wrote:
> Reviewed-by: Liming Gao
>
Thanks all
Pushed as a68749f39a2e04ef68e5656b7b72fca25a2e23dc
>> -Original Message-
>> From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
>> Sent: Wednesday, February 28, 2018 4:01 AM
>> To: Ard Biesheuvel
> I agree. Did you run into any issues due to this?
Surprisingly no. I was just trying to understand the fastboot
implementation before I use it on my platform
and was surprised that this works at all. I can imagine that's because this
is supposed to load linux's efistub which probably doesn't do a
On 28 February 2018 at 08:15, Michael Zimmermann
wrote:
>> I agree. Did you run into any issues due to this?
> Surprisingly no. I was just trying to understand the fastboot implementation
> before I use it on my platform
> and was surprised that this works at all. I can imagine that's because this
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Liming Gao
---
BaseTools/Source/C/Include/Common/UefiMultiPhase.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/BaseTools/Source/C/Include/Common/UefiMultiPhase.h
b/BaseTools/Source/C/Include/Common/
On 27 February 2018 at 20:06, Leif Lindholm wrote:
> On Tue, Feb 27, 2018 at 06:26:19PM +, Ard Biesheuvel wrote:
>> Even though the Secure96 device tree source is strictly an overlay, we
>> managed to express it in a way that does not rely on unresolved symbols
>> and other tricks that are onl
On 27 February 2018 at 18:10, Leif Lindholm wrote:
> On Tue, Feb 27, 2018 at 05:45:09PM +, Ard Biesheuvel wrote:
>> >> > +[Sources]
>> >> > + Stage2Tables.S
>> >> > +
>> >> > +[Packages]
>> >> > + MdePkg/MdePkg.dec
>> >> > + Silicon/Socionext/SynQuacer/SynQuacer.dec
>> >> > +
>> >> > +[Buil
On 02/28/18 08:53, Guo Heyi wrote:
> On Wed, Feb 28, 2018 at 03:25:03PM +0800, Ni, Ruiyu wrote:
>> Heyi,
>> My understanding is this whole change is backward compatible.
>> Which means an old version of PciHostBridgeLib + new PciHostBridgeLib.h +
>> new PciHostBridgeDxe driver won't cause build fa
Well since the fastboot implementation already is an application (and not a
driver) all we need to do is to use WaitEvent instead of a notify callback.
Once that's fixed I'd add ASSERTs on the current tpl to the relevant API
functions so you know immediately when you try to violate the spec.
On F
On 02/27/18 21:31, Marvin Häuser wrote:
>> -Original Message-
>> From: Laszlo Ersek
>> Sent: Tuesday, February 27, 2018 8:54 PM
>> To: Marvin Häuser ; edk2-
>> de...@lists.01.org
>> Cc: michael.d.kin...@intel.com; liming@intel.com
>> Subject: Re: [edk2] [PATCH 1/2] MdePkg/Base.h: Ensur
On 02/27/18 19:55, Marvin Häuser wrote:
> Hey Laszlo,
>
> Thanks for your... detailed explanation. :)
> I actually submitted another patch to prevent what you explained -
> "[edk2] [PATCH 1/2] MdePkg/Base.h: Ensure safe bitwise operations.",
> which marks all BIT defines (and more) as unsigned.
> M
On 02/27/18 19:50, Andrew Fish wrote:
>
>
>> On Feb 27, 2018, at 10:42 AM, Laszlo Ersek wrote:
>>
>> On 02/27/18 17:49, Marvin Häuser wrote:
>>> The toolcahin VS2015x86 issues warnings when truncating constant
>>> values. Explicitely cast such to avoid it.
>>>
>>> Contributed-under: TianoCore Co
Thanks. Comments are inline.
Best regards,
Marvin.
> -Original Message-
> From: Laszlo Ersek
> Sent: Wednesday, February 28, 2018 12:00 PM
> To: Marvin Häuser ; edk2-
> de...@lists.01.org
> Cc: michael.d.kin...@intel.com; liming@intel.com
> Subject: Re: [edk2] [PATCH 1/2] MdePkg/Base
> -Original Message-
> From: Laszlo Ersek
> Sent: Wednesday, February 28, 2018 12:42 PM
> To: Andrew Fish
> Cc: Marvin Häuser ; edk2-
> de...@lists.01.org; ruiyu...@intel.com; eric.d...@intel.com;
> star.z...@intel.com
> Subject: Re: [edk2] [PATCH 1/2] MdeModulePkg/PciBusDxe: Prevent
>
On 02/28/18 09:19, Ard Biesheuvel wrote:
> On 28 February 2018 at 08:15, Michael Zimmermann
> wrote:
>>> I agree. Did you run into any issues due to this?
>> Surprisingly no. I was just trying to understand the fastboot implementation
>> before I use it on my platform
>> and was surprised that thi
On 02/28/18 07:19, Zhang, Chao B wrote:
> From: Jiewen Yao
>
> Cc: Chao B Zhang
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jiewen Yao
> ---
> Maintainers.txt | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Maintainers.txt b/Maintainers.txt
> index 74f2
On Fri, Feb 23, 2018 at 11:47:28AM +0100, Laszlo Ersek wrote:
> >> I think the solution that saves the most on the *source* code size
> >> is:
> >> - introduce the BeIoLib class
> >> - duplicate the MMIO functions from BaseIoLibIntrinsic to the one
> >> BeIoLib instance that we introduce
> >> - m
On Wed, Feb 28, 2018 at 01:03:07AM +, Haojian Zhuang wrote:
> >> diff --git a/EmbeddedPkg/Drivers/VirtualKeyboardDxe/ComponentName.c
> >> b/EmbeddedPkg/Drivers/VirtualKeyboardDxe/ComponentName.c
> >> new file mode 100644
> >> index 000..2935307
> >> --- /dev/null
> >> +++ b/EmbeddedPkg/Dri
On 02/28/18 12:43, Marvin Häuser wrote:
> Actually, your explanations and the rest of the bit defines made me
> wonder, whether marking all BIT defines and bit masks of any kind,
> anywhere, as ULL, might be the best solution.
For a new project just being started, that could be one of the safest
On 02/28/18 14:57, Laszlo Ersek wrote:
> On 02/28/18 12:43, Marvin Häuser wrote:
>> +2) Binary operations (AND, OR, ...) should not raise any problems at
>> all (except for our fellow using VS2005x86 :) )
>
> Haha :) In earnest though, you are right.
Hm... It should not be a frequent pattern, bu
Hey Laszlo,
I cut your rant because it is not strictly related to this patch. However,
thank you for composing it nevertheless because it was an interesting read!
Comments are inline.
Michael, Liming,
Do you have any comments regarding the discussion? Thanks in advance.
Best regards,
Marvin.
>
I think it should be governed by edk2 conventions.
As far as I'm aware, currently there are no conventions related to packed data
structure decoration.
-Original Message-
From: Marvin H?user [mailto:marvin.haeu...@outlook.com]
Sent: Tuesday, February 27, 2018 4:36 PM
To: edk2-devel@lists
On Tue, Jan 02, 2018 at 03:50:34PM +, Ard Biesheuvel wrote:
> Commit 8ae5fc182941 ("ArmPlatformPkg/MemoryInitPeiLib: don't reserve
> primary FV in memory") deleted the code that removes the memory covering
> the primary firmware volume from the memory map. The assumption was that
> this is no l
On 28 February 2018 at 15:03, Leif Lindholm wrote:
> On Tue, Jan 02, 2018 at 03:50:34PM +, Ard Biesheuvel wrote:
>> Commit 8ae5fc182941 ("ArmPlatformPkg/MemoryInitPeiLib: don't reserve
>> primary FV in memory") deleted the code that removes the memory covering
>> the primary firmware volume fr
Hi Laszlo,
On 02/27/2018 02:37 PM, Brijesh Singh wrote:
Hi Laszlo,
On 2/27/18 11:17 AM, Laszlo Ersek wrote:
Hi Brijesh,
you provided a lot of information (and it seems like your analysis was
advancing in parallel with your email -- I too do that sometimes :) ),
so it's not easy for me to wr
Commit 8ae5fc182941 ("ArmPlatformPkg/MemoryInitPeiLib: don't reserve
primary FV in memory") deleted the code that removes the memory covering
the primary firmware volume from the memory map. The assumption was that
this is no longer necessary now that we no longer expose compression and
PE/COFF loa
Instead of completely removing the memory occupied by the primary PrePi
FV from the memory map, thereby making it inaccessible to the OS, mark
it as boot services data. This will ensure that the memory is left
untouched by the firmware, but will release it to the OS when it calls
ExitBootServices()
On Wed, Feb 28, 2018 at 03:44:41PM +, Ard Biesheuvel wrote:
> Instead of completely removing the memory occupied by the primary PrePi
> FV from the memory map, thereby making it inaccessible to the OS, mark
> it as boot services data. This will ensure that the memory is left
> untouched by the
copy the same logic from _BuildPa() function.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Yonghong Zhu
---
BaseTools/Source/Python/build/build.py | 8
1 file changed, 8 insertions(+)
diff --git a/BaseTools/Source/Python/build/build.py
b/BaseTools/Source/Pyth
On 28 February 2018 at 15:55, Leif Lindholm wrote:
> On Wed, Feb 28, 2018 at 03:44:41PM +, Ard Biesheuvel wrote:
>> Instead of completely removing the memory occupied by the primary PrePi
>> FV from the memory map, thereby making it inaccessible to the OS, mark
>> it as boot services data. Thi
The series adds the SMM support for the SEV guest.
Cc: Jordan Justen
Cc: Laszlo Ersek
Cc: Ard Biesheuvel
repo: https://github.com/codomania/edk2.git
branch: smm-v2
Changes since v1:
- add more comments to explain why we are not clearing the C-bit
from relocated SMM Saved area.
- restore
When OVMF is built with SMM, SMMSaved State area (SMM_DEFAULT_SMBASE +
SMRAM_SAVE_STATE_MAP_OFFSET) contains data which need to be accessed by
both guest and hypervisor. Since the data need to be accessed by both
hence we must map the SMMSaved State area as unencrypted (i.e C-bit
cleared).
This pa
Commit:24e4ad7 (OvmfPkg: Add AmdSevDxe driver) added a driver which runs
early in DXE phase and clears the C-bit from all MMIO regions (including
Qemu Flash). When SMM is enabled, we build two sets of page tables; first
page table is used when executing code in non SMM mode (SMM-less-pgtable)
and s
On Tue, Feb 27, 2018 at 09:20:13AM +, Ard Biesheuvel wrote:
> Fix the static B/D/F specifiers that refer to the pair of x1 PCIe slots
> on the DeveloperBox PCB.
What is the user-observable problem that is addressed by this patch?
> Contributed-under: TianoCore Contribution Agreement 1.1
> Sig
On 28 February 2018 at 16:17, Leif Lindholm wrote:
> On Tue, Feb 27, 2018 at 09:20:13AM +, Ard Biesheuvel wrote:
>> Fix the static B/D/F specifiers that refer to the pair of x1 PCIe slots
>> on the DeveloperBox PCB.
>
> What is the user-observable problem that is addressed by this patch?
>
Th
On Tue, Feb 27, 2018 at 09:20:14AM +, Ard Biesheuvel wrote:
> ACPI is not able to describe PCI resource windows that involve both type
> and address translation (i.e., for I/O windows on architectures that do
> not support port I/O natively), and so the ACPI/Linux code has a hard
> time perform
On 28 February 2018 at 16:26, Leif Lindholm wrote:
> On Tue, Feb 27, 2018 at 09:20:14AM +, Ard Biesheuvel wrote:
>> ACPI is not able to describe PCI resource windows that involve both type
>> and address translation (i.e., for I/O windows on architectures that do
>> not support port I/O native
On Tue, Feb 27, 2018 at 09:20:16AM +, Ard Biesheuvel wrote:
> Create a HII menu option to choose between device tree and ACPI platform
> descriptions.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel
Reviewed-by: Leif Lindholm
> ---
> Silicon/Soc
On Wed, Feb 28, 2018 at 04:18:50PM +, Ard Biesheuvel wrote:
> On 28 February 2018 at 16:17, Leif Lindholm wrote:
> > On Tue, Feb 27, 2018 at 09:20:13AM +, Ard Biesheuvel wrote:
> >> Fix the static B/D/F specifiers that refer to the pair of x1 PCIe slots
> >> on the DeveloperBox PCB.
> >
>
On Wed, Feb 28, 2018 at 04:30:50PM +, Ard Biesheuvel wrote:
> On 28 February 2018 at 16:26, Leif Lindholm wrote:
> > On Tue, Feb 27, 2018 at 09:20:14AM +, Ard Biesheuvel wrote:
> >> ACPI is not able to describe PCI resource windows that involve both type
> >> and address translation (i.e.,
On 28 February 2018 at 16:43, Leif Lindholm wrote:
> On Wed, Feb 28, 2018 at 04:30:50PM +, Ard Biesheuvel wrote:
>> On 28 February 2018 at 16:26, Leif Lindholm wrote:
>> > On Tue, Feb 27, 2018 at 09:20:14AM +, Ard Biesheuvel wrote:
>> >> ACPI is not able to describe PCI resource windows t
Hi Marvin,
I do not think add 'u' to the BITxx defines does not
seem to be a complete solution. Code can use integer
constants in lots of places including other #defines
or inline in expressions.
If we follow your suggestion wouldn’t we need to add
'u' to every constant that does not start with
I have just locally updated all BIT defines to use the ULL prefix and added
casts to defines using them.
I did that to ensure that 1) inversions always produce the correct value and 2)
assignments never result in implicit casts to a smaller int, which would raise
a warning.
After I was done doi
Hey Mike,
You are right, the patch was premature because I did not consider any
'incorrect' or 'clever' usages of these definitions.
The problem is not primarily undefined behavior, but implementation-defined
behavior.
Any bitwise operation to a signed integer results in implementation-defined
Hi Brijesh,
On 02/28/18 17:14, Brijesh Singh wrote:
> When OVMF is built with SMM, SMMSaved State area (SMM_DEFAULT_SMBASE +
> SMRAM_SAVE_STATE_MAP_OFFSET) contains data which need to be accessed by
> both guest and hypervisor. Since the data need to be accessed by both
> hence we must map the SMM
Hi Laszlo,
On 2/28/18 1:06 PM, Laszlo Ersek wrote:
> Hi Brijesh,
>
> On 02/28/18 17:14, Brijesh Singh wrote:
>> When OVMF is built with SMM, SMMSaved State area (SMM_DEFAULT_SMBASE +
>> SMRAM_SAVE_STATE_MAP_OFFSET) contains data which need to be accessed by
>> both guest and hypervisor. Since the
The ACPI/Linux code does not cope very well with I/O BAR windows that
involve type translation and address translation. In particular, the
secondary I/O window we implement on SynQuacer:
I/O 0x1 ... 0x1 -> 0x77f0
is misinterpreted by Linux, and results in the MMIO range starting a
This implements ACPI support for the SynQuacer platforms.
Changes since v1:
- improve commit log (#1, #2)
- replace bare numbers with symbolic constants (#2)
- add Leif's R-b (#4)
- add patches #6 and #7
Note that supporting ACPI on this SoC is non-trivial, due to the quirky
DesignWare RCs and th
Fix the static B/D/F specifiers that refer to the pair of x1 PCIe slots
on the DeveloperBox PCB. The current configuration caused user-configurable
settings for slots 1/2 to apply to the incorrect one.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel
---
Sili
Add the ACPI tables describing various parts of the SynQuacer SoC and
its peripherals, and the drivers to expose them to the EvalBoard and
DeveloperBox platforms.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel
---
Platform/Socionext/DeveloperBox/DeveloperBo
Expose a separate ACPI description of the SynQuacer eMMC controller
when both ACPI and eMMC support have been enabled in the HII menu.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel
---
Platform/Socionext/DeveloperBox/DeveloperBox.fdf| 1 +
Create a HII menu option to choose between device tree and ACPI platform
descriptions. Note that the option is only active if PCIe compatibility
mode is enabled.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel
Reviewed-by: Leif Lindholm
---
Silicon/Socionex
We have a couple of workarounds available for the ECAM ghosting issue
that affects the Synopsys Designware PCIe RCs. First of all, we can be
optimistic and hope that the silicon gets fixed at some point. Then,
there is a SCP firmware hack that hides these ghosts by remapping the
ECAM region using t
On the SynQuacer Evalution Board, PCIe RC #0 is not clocked if no card
is inserted into the PCIe slot, and so any attempt to access the device
registers will lock up the system.
So let's check the presence detect pin directly in the _STA implementation
of PCI0. This needs to be done before the con
On 02/28/18 17:14, Brijesh Singh wrote:
> Commit:24e4ad7 (OvmfPkg: Add AmdSevDxe driver) added a driver which runs
> early in DXE phase and clears the C-bit from all MMIO regions (including
> Qemu Flash).
(1) This appears incorrect / inexact; AmdSevDxe is dispatched from
APRIORI DXE before the fla
So, on the whole, I'm happy with this series.
Some of the .asl looks to me like it could be made more readable with
some additional #defines, but I may be oversimplifying. But I'd like
someone with more ACPI experience to give an R-b for 3,5-7.
With that provision, for the series:
Reviewed-by: Le
Hi Leif, Ard.
Can I get you two argue out the pros and cons of the "ASSERT(FALSE)" debate,
please.
(see https://lists.01.org/pipermail/edk2-devel/2018-January/019788.html)
For what it is worth, our (surprisingly unanimous) opinion is that, since the
ASSERT is only there to help spot a problem, th
One comment is inline.
Thank you in advance,
Marvin.
> -Original Message-
> From: edk2-devel On Behalf Of Marvin
> Häuser
> Sent: Wednesday, February 28, 2018 7:46 PM
> To: edk2-devel@lists.01.org; Laszlo Ersek
> Cc: michael.d.kin...@intel.com; liming@intel.com
> Subject: Re: [edk2]
On Wed, Feb 28, 2018 at 10:39:24AM +0100, Laszlo Ersek wrote:
> On 02/28/18 08:53, Guo Heyi wrote:
> > On Wed, Feb 28, 2018 at 03:25:03PM +0800, Ni, Ruiyu wrote:
>
> >> Heyi,
> >> My understanding is this whole change is backward compatible.
> >> Which means an old version of PciHostBridgeLib + ne
Hi Marvin,
Yes. I have been reading the thread.
Lots of really good analysis.
However, it does not make sense to me to add
'u' to the smaller BITxx, BASExx, and SIZExx
macros if we have constants in other places that
do not add the 'u'. I think this patch may
increase the inconsistency of the
eval argument start with " or ', but it is unicode string,
will encounter error:
List = list(eval(Value)) # translate escape character
File "", line 1
'jà =îµ¢Ã"FÃ
^
SyntaxError: EOL while scanning string literal
Cc: Liming Gao
Cc: Yonghong Zhu
Contributed-under: Tiano
When run GenFds, GlobalData.gConfDirectory is None, On Linux
self._ToolChainFamily default Value is "MSFT", and then
generate the wrong PcdValueInit Makefile
Cc: Liming Gao
Cc: Yonghong Zhu
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Yunhua Feng
---
BaseTools/Source
Function BmRepairAllControllers may recursively call itself if some
driver health protocol returns EfiDriverHealthStatusReconnectRequired.
However, driver health protocol of some buggy third party driver may
always return such status even after one and another reconnect. The
endless iteration will
Sorry, forgot to add a "v2" mark in the subjuect prefix...
Regards,
Heyi
On Thu, Mar 01, 2018 at 10:39:32AM +0800, Heyi Guo wrote:
> Function BmRepairAllControllers may recursively call itself if some
> driver health protocol returns EfiDriverHealthStatusReconnectRequired.
> However, driver healt
Hi Ray,
I've one question about (9); please see it below:
On Tue, Feb 27, 2018 at 04:48:47PM +0800, Ni, Ruiyu wrote:
> On 2/27/2018 10:09 AM, Heyi Guo wrote:
> >PCI address translation is necessary for some non-x86 platforms. On
> >such platforms, address value (denoted as "device address" or "ad
Reviewed-by: Liming Gao
>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>Yonghong Zhu
>Sent: Thursday, March 01, 2018 12:09 AM
>To: edk2-devel@lists.01.org
>Subject: [edk2] [Patch] BaseTools: Fix the bug for single module build with
>GenC/GenMak
On 3/1/2018 11:56 AM, Guo Heyi wrote:
Hi Ray,
I've one question about (9); please see it below:
On Tue, Feb 27, 2018 at 04:48:47PM +0800, Ni, Ruiyu wrote:
On 2/27/2018 10:09 AM, Heyi Guo wrote:
PCI address translation is necessary for some non-x86 platforms. On
such platforms, address value (
On 3/1/2018 10:39 AM, Heyi Guo wrote:
Function BmRepairAllControllers may recursively call itself if some
driver health protocol returns EfiDriverHealthStatusReconnectRequired.
However, driver health protocol of some buggy third party driver may
always return such status even after one and anothe
Reviewed-by: Yonghong Zhu
Best Regards,
Zhu Yonghong
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Liming
Gao
Sent: Wednesday, February 28, 2018 4:36 PM
To: edk2-devel@lists.01.org
Subject: [edk2] [Patch] BaseTools: Align WIN_CERTIFICATE_UEF
The root cause is the byte array value in the driver Pcd, some bytes
have additional space character, while the value in DSC file doesn't
have this space, it cause the string compare return false, so we remove
the extra space.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by:
For IPv6 case, if one invalid URL returned from DHCP server, HttpBootDxe
driver could not retrieve the URL host address from DNS server. In such a
case, the error message should be printed as:
Error: Could not retrieve the host address from DNS server.
Instead of:
Error: Could not discover the
The patch is to fix the incorrect parameter check for the
HttpBootGetFileFromCache().
Cc: Ye Ting
Cc: Fu Siyuan
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wu Jiaxin
---
NetworkPkg/HttpBootDxe/HttpBootClient.c | 13 ++---
1 file changed, 6 insertions(+), 7 d
The previous commit 137ed15511e2045a7333e33ae7f1e873ce1961dd
* MdeModulePkg/DebugLib: Print partial when format string is too long
copies partial format string to DEBUG_INFO buffer but when parsing
the format modifier, the original format string is still used.
The patch fixes this issue.
Contribu
Reviewed-by: Ye Ting
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jiaxin Wu
Sent: Thursday, March 1, 2018 2:30 PM
To: edk2-devel@lists.01.org
Cc: Ye, Ting ; Fu, Siyuan ; Wu, Jiaxin
Subject: [edk2] [Patch] NetworkPkg/HttpBootDxe: Correct the
Add Translation field to PCI_ROOT_BRIDGE_APERTURE. Translation is used
to represent the difference between device address and host address,
if they are not the same on some platforms.
In UEFI 2.7, "Address Translation Offset" is "Offset to apply to the
Starting address to convert it to a PCI addre
According to UEFI spec 2.7, PciIo->GetBarAttributes should return host
address (CPU view ddress) rather than device address (PCI view
address), and
device address = host address + address translation offset,
so we subtract translation from device address before returning.
Contributed-under: TianoC
Use ZeroMem to initialize all fields in temporary
PCI_ROOT_BRIDGE_APERTURE variables to zero. This is not mandatory but
helpful for future extension: when we add new fields to
PCI_ROOT_BRIDGE_APERTURE and the default value of these fields can
safely be zero, this code will not suffer from an additi
Patch v5 inherits the code from RFC v4; we don't restart the version number for
RFC to PATCH change.
v5:
- Patch 4/6: Modify the code according to the comments from Ray.
- Patch 1/6 and 2/6 are totally new. They add initialization for all fields of
PCI_ROOT_BRIDGE_APERTURE temporary variables in
According to UEFI spec 2.7, PciRootBridgeIo->Configuration() should
return host address (CPU view ddress) rather than device address
(PCI view address), so in function GetMmioAddressTranslationOffset we
need to convert the range to device address before comparing.
And device address = host address
Use ZeroMem to initialize all fields in temporary
PCI_ROOT_BRIDGE_APERTURE variables to zero. This is not mandatory but
is helpful for future extension: when we add new fields to
PCI_ROOT_BRIDGE_APERTURE and the default value of these fields can
safely be zero, this code will not suffer from an add
PCI address translation is necessary for some non-x86 platforms. On
such platforms, address value (denoted as "device address" or "address
in PCI view") set to PCI BAR registers in configuration space might be
different from the address which is used by CPU to access the
registers in memory BAR or
Reviewed-by: Fu Siyuan
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Jiaxin Wu
> Sent: Thursday, March 1, 2018 2:30 PM
> To: edk2-devel@lists.01.org
> Cc: Ye, Ting ; Fu, Siyuan ; Wu,
> Jiaxin
> Subject: [edk2] [Patch] NetworkPkg/HttpB
Reviewed-by: Fu Siyuan
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Jiaxin Wu
> Sent: Thursday, March 1, 2018 2:30 PM
> To: edk2-devel@lists.01.org
> Cc: Ye, Ting ; Fu, Siyuan ; Wu,
> Jiaxin
> Subject: [edk2] [Patch] NetworkPkg/HttpBootD
Currently DxeCorePerformanceLib will get SMM performance data based
on SMM communication handler. If SMM communication handler returns error,
the library will ASSERT. In fact, if SMM perf data is not found.
DXE perf data can still be dumped. So using status check instead of
ASSERT is better.
Cc: L
The default value of PcdExtFpdtBootRecordPadSize is 0x2
But the following commit in master update it to 0 by mistake.
SHA-1: 052c98ce246a1ffb0b4c5185a644aa9f902650f7
Subject: MdeModulePkg: Add ResetSystemPei PEIM
This patch is to restore the value.
Cc: Liming Gao
Cc: Star Zeng
Cc: Ruiyu Ni
Reviewed-by: Ye Ting
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jiaxin Wu
Sent: Thursday, March 1, 2018 2:30 PM
To: edk2-devel@lists.01.org
Cc: Ye, Ting ; Fu, Siyuan ; Wu, Jiaxin
Subject: [edk2] [Patch] NetworkPkg/HttpBootDxe: Fix the inco
86 matches
Mail list logo
