Regards,
Ray
>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo
>Ersek
>Sent: Monday, September 12, 2016 9:49 PM
>To: Ard Biesheuvel ; Yao, Jiewen
>
>Cc: Ni, Ruiyu ; Tian, Feng ;
>edk2-devel@lists.01.org ;
>leif.lindh...@linaro.org; Gao,
Cc: Wu Jiaxin
Cc: Zhang Lubo
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Fu Siyuan
---
NetworkPkg/HttpBootDxe/HttpBootDhcp6.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/NetworkPkg/HttpBootDxe/HttpBootDhcp6.c
b/NetworkPkg/HttpBootDxe/HttpBootDhcp6.c
index 8
Reviewed-by: Erik Bjorge
> -Original Message-
> From: Gao, Liming
> Sent: Monday, September 12, 2016 9:04 AM
> To: edk2-devel@lists.01.org
> Cc: Zhu, Yonghong ; Kinney, Michael D
> ; Bjorge, Erik C
> Subject: [Patch 4/4] BaseTools: Update toolsetup.bat to set PYTHONPATH
> env to run pyth
Reviewed-by: Erik Bjorge
> -Original Message-
> From: Gao, Liming
> Sent: Monday, September 12, 2016 9:03 AM
> To: edk2-devel@lists.01.org
> Cc: Zhu, Yonghong ; Kinney, Michael D
> ; Bjorge, Erik C
> Subject: [Patch 3/4] BaseTools: Update Python Makefile not to depend on
> PYTHON_FREEZER
Reviewed-by: Erik Bjorge
> -Original Message-
> From: Gao, Liming
> Sent: Monday, September 12, 2016 9:03 AM
> To: edk2-devel@lists.01.org
> Cc: Zhu, Yonghong ; Kinney, Michael D
> ; Bjorge, Erik C
> Subject: [Patch 2/4] BaseTools: Update python tool to call external
> tools with shell t
Reviewed-by: Erik Bjorge
> -Original Message-
> From: Gao, Liming
> Sent: Monday, September 12, 2016 9:03 AM
> To: edk2-devel@lists.01.org
> Cc: Zhu, Yonghong ; Kinney, Michael D
> ; Bjorge, Erik C
> Subject: [Patch 1/4] BaseTools: Add Windows batch files to run python
> tool from Source
Python tool may run from source as the dos batch files. So, update python
code to call external tools with shell true mode.
Cc: Yonghong Zhu
Cc: Michael Kinney
Cc: Erik Bjorge
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao
---
BaseTools/Source/Python/Common/
When python tool exe doesn't exist, toolsetup.bat will set up PYTHONPATH,
and set python tool dos script directory into system PATH.
Cc: Yonghong Zhu
Cc: Michael Kinney
Cc: Erik Bjorge
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao
---
BaseTools/toolsetup.ba
Add 13 windows batch files for every python tool.
Cc: Yonghong Zhu
Cc: Michael Kinney
Cc: Erik Bjorge
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao
---
BaseTools/BinWrappers/WindowsLike/BPDG.bat | 3 +++
BaseTools/BinWrappers/WindowsLik
If PYTHON_FREEZER_PATH is not set, Python tools will not be freeze.
Cc: Yonghong Zhu
Cc: Michael Kinney
Cc: Erik Bjorge
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao
---
BaseTools/Source/Python/Makefile | 17 +
1 file changed, 13 insertions(
When Python tool exe files don't exist, toolsetup.bat will configure
PYTHONPATH to python source code, and set BaseTools\BinWrappers\WindowsLike
into system PATH directory. Then, windows batch files will be used to
run python tools from source files.
Liming Gao (4):
BaseTools: Add Windows bat
On 09/12/16 15:16, Ard Biesheuvel wrote:
> On 12 September 2016 at 14:15, Yao, Jiewen wrote:
>> HI Ard
>> We should not let MdeModulePkg depend on IntelFrameworkPkg.
>> You patch violates the dependency rule.
>> I suggest we figure out other solution to resolve the problem.
>>
>
> Yes, please. An
On 12 September 2016 at 14:41, Ni, Ruiyu wrote:
> You could use IncompatiblePciDevice protocol. If you have no clue I will
> give you more information my tomorrow.
>
That works around the problem, but does not solve it. MdeModulePkg is
supposed to be generic/universal, and still, it contains a In
You could use IncompatiblePciDevice protocol. If you have no clue I will give
you more information my tomorrow.
Thanks,
Ray
在 2016年9月12日，下午9:16，Ard Biesheuvel
mailto:ard.biesheu...@linaro.org>> 写道：
On 12 September 2016 at 14:15, Yao, Jiewen
mailto:jiewen@intel.com>> wrote:
HI Ard
We shoul
On 12 September 2016 at 14:15, Yao, Jiewen wrote:
> HI Ard
> We should not let MdeModulePkg depend on IntelFrameworkPkg.
> You patch violates the dependency rule.
> I suggest we figure out other solution to resolve the problem.
>
Yes, please. And please keep us informed about any solutions you co
HI Ard
We should not let MdeModulePkg depend on IntelFrameworkPkg.
You patch violates the dependency rule.
I suggest we figure out other solution to resolve the problem.
Thank you
Yao Jiewen
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Ar
On 12 September 2016 at 13:29, Laszlo Ersek wrote:
> On 09/12/16 12:23, Leif Lindholm wrote:
>> On Mon, Sep 12, 2016 at 11:01:17AM +0100, Ard Biesheuvel wrote:
>>> By default, the generic PciBusDxe driver uses the presence of a ROM BAR
>>> as a hint that all MMIO BARs should be allocated in the 32
The practice of unconditionally degrading 64-bit PCI MMIO BARs to 32-bit
if the device in question happens to have an option ROM is based on
platform constraints, not architectural constraints, and really only makes
sense on Intel platforms that contain a CSM implementation.
So let's copy the OVMF
On 09/12/16 12:23, Leif Lindholm wrote:
> On Mon, Sep 12, 2016 at 11:01:17AM +0100, Ard Biesheuvel wrote:
>> By default, the generic PciBusDxe driver uses the presence of a ROM BAR
>> as a hint that all MMIO BARs should be allocated in the 32-bit region,
>> even the ones that could be allocated abo
On 09/12/16 12:01, Ard Biesheuvel wrote:
> On ARM/Linux systems, the PCI layer is usually reconfigured from scratch,
> given the embedded legacy of ARM systems. However, when booting arm64/Linux
> in ACPI mode, such reconfiguration can be avoided, since ACPI implies UEFI
> implies firmware (as oppo
On 09/12/16 08:49, Thomas Huth wrote:
> On 10.09.2016 01:28, Laszlo Ersek wrote:
>> Run "unix2dos" on the affected files. "git show -b" produces no diff for
>> this patch.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Laszlo Ersek
>> Cc: Jordan Justen
>> Cc: Thom
On Mon, Sep 12, 2016 at 11:01:17AM +0100, Ard Biesheuvel wrote:
> By default, the generic PciBusDxe driver uses the presence of a ROM BAR
> as a hint that all MMIO BARs should be allocated in the 32-bit region,
> even the ones that could be allocated above 4 GB. The reason is that
> such a ROM BAR
On ARM/Linux systems, the PCI layer is usually reconfigured from scratch,
given the embedded legacy of ARM systems. However, when booting arm64/Linux
in ACPI mode, such reconfiguration can be avoided, since ACPI implies UEFI
implies firmware (as opposed to DT mode, which could be booted via QEMU's
In preparation of adding IncompatibleDeviceSupportDxe to ArmVirtQemu,
in order to lure the PCI code into allocating all 64-bit BARs in the
64-bit region, update FdtPciPcdProducerLib so it sets the PcdPciMmio64Size
based on the DT description of the PCIe root complex.
Contributed-under: TianoCore C
To prevent the generic PCI bus driver from allocating 64-bit MMIO BARs in
the 32-bit region for no good reason (since no good reasons exist on ARM),
add the IncompatiblePciDeviceSupportDxe driver to the build, which will
force override the policy to do so in the presence of a ROM BAR.
Contributed-
By default, the generic PciBusDxe driver uses the presence of a ROM BAR
as a hint that all MMIO BARs should be allocated in the 32-bit region,
even the ones that could be allocated above 4 GB. The reason is that
such a ROM BAR may contain code that runs in the context of a legacy
BIOS (i.e., a CSM)
Reviewed-by: Liming Gao
> -Original Message-
> From: Thomas Huth [mailto:th...@redhat.com]
> Sent: Saturday, September 10, 2016 4:33 AM
> To: edk2-de...@ml01.01.org
> Cc: Kinney, Michael D ; Gao, Liming
>
> Subject: [PATCH] MdePkg: Fix some typing errors
>
> Correct the typos in some fi
Reviewed-by: Liming Gao
> -Original Message-
> From: Thomas Huth [mailto:th...@redhat.com]
> Sent: Monday, September 12, 2016 4:36 PM
> To: edk2-de...@ml01.01.org
> Cc: Kinney, Michael D ; Gao, Liming
>
> Subject: [PATCH] MdePkg: Fix some typing errors in the header files
>
> Correct th
On 12.09.2016 03:26, Gao, Liming wrote:
> Thomas:
> Thanks for your catching. Some similar issues also exist in header files in
> MdePkg. Could you help fix them also?
Sure, I just send a patch.
Regards,
Thomas
> Thanks
> Liming
>> -Original Message-
>> From: Thomas Huth [mailto:t
Correct the typos in some header files of MdePkg.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Thomas Huth
---
MdePkg/Include/AArch64/ProcessorBind.h| 2 +-
MdePkg/Include/Arm/ProcessorBind.h| 2 +-
MdePkg/Incl
On 10 September 2016 at 01:23, Andrew Fish wrote:
>
>
>> On Sep 9, 2016, at 11:00 AM, Ard Biesheuvel
>> wrote:
>>
>> Implement the backtrace formattting suggested by Andrew, i.e.,
>>
>> IRQ Exception at 0x5BE182B0
>> PC 0x5BE182B0 (0x5BE14000+0x42B0) [ 0] ArmCpuDxe.dll
>>
31 matches
Mail list logo
