Re: [edk2] [RFC] Plan to delete ShellBinPkg from edk2/master

[Laszlo Ersek]

On 04/03/19 17:49, Kinney, Michael D wrote:
> Laszlo,
> 
> I think it makes sense to post validated shell binaries
> with the edk2-stable tag releases.  GitHub does support
> this when a release tag is made.
> 
> However, we would need to make it simple for a platform
> to use a binary from that location.  We may need some
> enhancements to pull in binary artifacts from different
> locations to support a platform build that uses one or
> more pre-built binaries.

Can PREBUILD scripts (written by platform owners) download the required
binaries?

Thanks,
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [edk2-announce] ATTN: List Transition Begins Today

[stephano]

tl;dr
If you're sending emails to this list, now would be a good time to 
switch over to the new list: https://edk2.groups.io/g/devel



We will be transitioning to Groups.io today for our devel mailing list. 
At some point today, this email will begin to bounce any incoming 
messages. I'll be working on getting the archive of old emails uploaded 
to Groups.io. When I have a timetable for the archives I'll update the 
new list.


Cheers,
Stephano
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [RFC] Plan to delete ShellBinPkg from edk2/master

[Kinney, Michael D]

Laszlo,

I think it makes sense to post validated shell binaries
with the edk2-stable tag releases.  GitHub does support
this when a release tag is made.

However, we would need to make it simple for a platform
to use a binary from that location.  We may need some
enhancements to pull in binary artifacts from different
locations to support a platform build that uses one or
more pre-built binaries.

Mike

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Wednesday, April 3, 2019 3:10 AM
> To: Ni, Ray ; Bi, Dandan
> ; edk2-devel@lists.01.org
> Cc: Cetola, Stephano ;
> Kinney, Michael D ; Gao,
> Liming ; Carsey, Jaben
> 
> Subject: Re: [edk2] [RFC] Plan to delete ShellBinPkg
> from edk2/master
> 
> On 04/03/19 04:17, Ni, Ray wrote:
> >
> >
> >> -Original Message-
> >> From: edk2-devel 
> On Behalf Of Laszlo
> >> Ersek
> >> Sent: Tuesday, April 2, 2019 4:49 PM
> >> To: Bi, Dandan ; edk2-
> de...@lists.01.org
> >> Cc: Cetola, Stephano ;
> Kinney, Michael D
> >> ; Gao, Liming
> ; Carsey,
> >> Jaben 
> >> Subject: Re: [edk2] [RFC] Plan to delete ShellBinPkg
> from edk2/master
> >>
> >> On 04/02/19 07:38, Bi, Dandan wrote:
> >>> Hi All,
> >>>
> >>> ShellBinPkg is the remaining binary package in Edk2
> repo.  We plan to
> >> delete ShellBinPkg from edk2/master, and keep source
> ShellPkg only in edk2
> >> repo.
> >>> Before the deletion, I will update the existing
> consumers in Edk2 and
> >> Edk2Platforms to use ShellPkg directly.
> >>>
> >>> If you have any concern please raise here before
> mid-April . If there is no
> >> concern, I will create patches for this task after
> mid-April.
> >>>
> >>> Bugzilla for this task:
> >>> https://bugzilla.tianocore.org/show_bug.cgi?id=1675
> >>
> >> (adding a few CC's)
> >>
> >> I think we should not remove ShellBinPkg without a
> replacement
> >> *somehwere*.
> >>
> >> A shell binary that is built from a validated edk2
> tree, with a set of library
> >> resolutions and PCD settings that are known to keep
> platform dependencies
> >> *out* of the shell binary, is extremely useful.
> >
> > I understand the concern.
> > Maybe a "Shell.dsc.inc" provided by ShellPkg which
> lists all library resolutions
> > , PCD settings and build options can be included by
> platform DSC to resolve such
> > dependency issue.
> >
> >>
> >> IIRC, Andrew suggested earlier that we should treat
> the shell even as an "OS",
> >> with better compatibility standards than we
> currently maintain.
> >>
> >> I think we should only remove ShellBinPkg if we
> permanently offer a
> >> separate download location instead, and we rebuild
> the shell binary from
> >> "ShellPkg/ShellPkg.dsc" at every stable tag.
> >
> > I do not quite understand. All other modules in edk2
> repo are source-included by
> > OvmfPkg and daily commits directly generates new
> binaries for OvmfPkg.
> > I do not think we should have a different "binary-
> generation" model for
> > shell.
> 
> The standalone shell binary would not be offered for
> OVMF, but for all
> possible UEFI platforms (physical and virtual alike).
> 
> People frequently turn to the UEFI shell for debugging
> UEFI issues on
> their physical machines. Such users are generally not
> interested in
> building the shell from source, just booting it as
> easily as possible.
> 
> Thanks,
> Laszlo
> 
> 
> >> In that case, removing ShellBinPkg would indeed
> improve the edk2 tree, in
> >> my opinion.
> >>
> >> Thanks,
> >> Laszlo
> >> ___
> >> edk2-devel mailing list
> >> edk2-devel@lists.01.org
> >> https://lists.01.org/mailman/listinfo/edk2-devel

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] aarch64-linux-gnu-gcc.exe: error due to loss ‘/’in code path in in Jenkins server

[Sami Mujawar]

I cannot spot anything obvious, but we have seen issues where the workspace 
depth is long, which we resolve by using junctions on Windows.

We have tried building the FVP platform firmware on our Jenkins Windows 10 
infrastructure, using the same gcc toolchain 
(gcc-linaro-7.3.1-2018.05-i686-mingw32_aarch64-linux-gnu) and don’t see this 
issue.
Our Jenkins PC is configured with the following tools. It might be worth 
checking this in your setup.
1. python --version
Python 2.7.14

2. java -version
java version "1.8.0_202"
   Java(TM) SE Runtime Environment (build 1.8.0_202-b08)
   Java HotSpot(TM) 64-Bit Server VM (build 25.202-b08, mixed mode)

Note: We do not use Cygwin in our Jenkins infrastructure. Our build scripts are 
in DOS batch file format and are invoked by Jenkins.

Regards,

Sami Mujawar

-Original Message-
From: Leif Lindholm 
Sent: 03 April 2019 11:59 AM
To: wang xiaofeng 
Cc: Sami Mujawar ; Gao, Liming ; 
edk2-devel@lists.01.org; ard.biesheu...@linaro.org
Subject: Re: Re: aarch64-linux-gnu-gcc.exe: error due to loss ‘/’in code path 
in in Jenkins server

On Wed, Apr 03, 2019 at 04:07:58PM +0800, wang xiaofeng wrote:
> Hi Leif,
>We use VC for X86 (do not need GCC cross complie)

Ah, that was not clear from the original mail.

Are both server and local system using cygwin/mingw32?

Best Regards,

Leif

>gcc revision :
> Using built-in specs.
> COLLECT_GCC=aarch64-linux-gnu-gcc.exe
> COLLECT_LTO_WRAPPER=c:/code/gnutools/gcc-linaro-7.3.1-2018.05-i686-min
> gw32_aarch64-linux-gnu/bin/../libexec/gcc/aarch64-linux-gnu/7.3.1/lto-
> wrapper.exe
> Target: aarch64-linux-gnu
> Configured with:
> '/home/tcwg-buildslave/workspace/tcwg-make-release/builder_arch/amd64/
> label/tcwg-x86_64-build/target/aarch64-linux-gnu/snapshots/gcc.git~lin
> aro-7.3-2018.05/configure' SHELL=/bin/bash
> --with-mpc=/home/tcwg-buildslave/workspace/tcwg-make-release/builder_a
> rch/amd64/label/tcwg-x86_64-build/target/aarch64-linux-gnu/_build/buil
> ds/destdir/i686-w64-mingw32
> --with-mpfr=/home/tcwg-buildslave/workspace/tcwg-make-release/builder_
> arch/amd64/label/tcwg-x86_64-build/target/aarch64-linux-gnu/_build/bui
> lds/destdir/i686-w64-mingw32
> --with-gmp=/home/tcwg-buildslave/workspace/tcwg-make-release/builder_a
> rch/amd64/label/tcwg-x86_64-build/target/aarch64-linux-gnu/_build/buil
> ds/destdir/i686-w64-mingw32 --with-gnu-as --with-gnu-ld
> --disable-libmudflap --enable-lto --enable-shared
> --without-included-gettext --enable-nls --with-system-zlib
> --disable-sjlj-exceptions --enable-gnu-unique-object
> --enable-linker-build-id --disable-libstdcxx-pch --enable-c99
> --enable-clocale=gnu --enable-libstdcxx-debug --enable-long-long
> --with-cloog=no --with-ppl=no --with-isl=no --disable-multilib
> --enable-fix-cortex-a53-835769 --enable-fix-cortex-a53-843419
> --with-arch=armv8-a --enable-threads=posix --enable-multiarch
> --enable-libstdcxx-time=yes --enable-gnu-indirect-function
> --with-build-sysroot=/home/tcwg-buildslave/workspace/tcwg-make-release
> /builder_arch/amd64/label/tcwg-x86_64-build/target/aarch64-linux-gnu/_
> build/sysroots/aarch64-linux-gnu
> --with-sysroot=/home/tcwg-buildslave/workspace/tcwg-make-release/build
> er_arch/amd64/label/tcwg-x86_64-build/target/aarch64-linux-gnu/_build/
> builds/destdir/i686-w64-mingw32/aarch64-linux-gnu/libc
> --enable-checking=release --disable-bootstrap
> --enable-languages=c,c++,fortran,lto
> --with-libiconv-prefix=/home/tcwg-buildslave/workspace/tcwg-make-relea
> se/builder_arch/amd64/label/tcwg-x86_64-build/target/aarch64-linux-gnu
> /_build/builds/destdir/i686-w64-mingw32/usr --with-system-zlib=no
> --build=x86_64-unknown-linux-gnu --host=i686-w64-mingw32
> --target=aarch64-linux-gnu
> --prefix=/home/tcwg-buildslave/workspace/tcwg-make-release/builder_arc
> h/amd64/label/tcwg-x86_64-build/target/aarch64-linux-gnu/_build/builds
> /destdir/i686-w64-mingw32
> Thread model: posix
> gcc version 7.3.1 20180425 [linaro-7.3-2018.05 revision
> d29120a424ecfbc167ef90065c0eeb7f91977701] (Linaro GCC 7.3-2018.05)
>
>
>
>
>GNUmake revision : GNUMake-3.81_win32
>
>
>  Can the tool provide more debug output ?
>
>
>
>
>
>
>
>
>
>
> At 2019-04-03 16:00:04, "Leif Lindholm"  wrote:
> >Sami, any ideas?
> >
> >Xiaofeng, what gcc is being used for x86? (output of "gcc -v")
> >
> >Best Regards,
> >
> >Leif
> >
> >On Wed, Apr 03, 2019 at 03:54:33PM +0800, wang xiaofeng wrote:
> >> HI ARM Base tool owners,
> >>I meet a strange issue that aarch64 build . The aarch64 build
> >> pass on my local server.  But it fails at Jenkins server(a Win10
> >> autobuild system written by Java that will can call edk2 bat in
> >> command line)
> >>
> >>
> >> The build command is
> >> "c:\jenkins\workspace\gop2018\udk2018\gnutools\gcc-linaro-7.3.1-201
> >> 8.05-i686-mingw32_aarch64-linux-gnu\bin\aarch64-linux-gnu-gcc" -g
> >> -fshort-wchar -fno-builtin -fno-strict-aliasing -Wall -Werror
> >> -Wno-array-bounds -ffunction-sections -fdata-sections -include
> >> AutoGen.h 

Re: [edk2] [RFC PATCH v1 0/8] Duplicate 8259/8254 components in OvmfPkg

[Laszlo Ersek]

On 04/03/19 14:13, Laszlo Ersek wrote:
> On 04/03/19 14:10, Laszlo Ersek wrote:
>> On 04/03/19 09:00, Hao Wu wrote:
>>> This series is also available at:
>>> https://github.com/hwu25/edk2/tree/ovmf_8259_8254_rfcv1
>>>
>>>
>>> As a sub-task to remove the IntelFrameworkPkg (BZ-1604),
>>>
>>> 8259InterruptControllerDxe driver (PcAtChipsetPkg)
>>> Legacy8259 protocol (IntelFrameworkPkg)
>>> 8254TimerDxe driver (PcAtChipsetPkg)
>>>
>>> will be removed in the near future. Meanwhile, OVMF will still require
>>> those components (due to CSM support & HPET emulation stability concern).
>>>
>>> Thus, the series will copy the below 8259/8254 components:
>>>
>>> A. 8259InterruptControllerDxe driver (PcAtChipsetPkg)
>>> B. Two 8259 related PCDs (PcAtChipsetPkg)
>>> C. Legacy8259 protocol (IntelFrameworkPkg)
>>> D. 8254TimerDxe driver (PcAtChipsetPkg)
>>>
>>> in the OvmfPkg to address the above-mentioned issue.
>>>
>>>
>>> Tests done for the proposed series:
>>>
>>> A. OvmfPkg build pass for VS2015 & GCC5 tool chains;
>>> B. Boot to Shell with commands:
>>>   qemu-system-x86_64.exe -pflash \OVMF.fd -debugcon 
>>> file:boot.log -global isa-debugcon.iobase=0x402
>>>   qemu-system-x86_64.exe -machine q35 -pflash \OVMF.fd -debugcon 
>>> file:boot.log -global isa-debugcon.iobase=0x402
>>> C. 'stall X' command under Shell to verify the timer is working properly.
>>>
>>>
>>> (Please note that there will be a subsequent patch to remove the 8259/8254
>>> components after platforms dropping the dependencies on them.)
>>>
>>> Cc: Jordan Justen 
>>> Cc: Laszlo Ersek 
>>> Cc: Ard Biesheuvel 
>>> Cc: David Woodhouse 
>>> Cc: Ray Ni 
>>>
>>>
>>> Hao Wu (8):
>>>   OvmfPkg: Copy 8259InterruptControllerDxe driver from PcAtChipsetPkg
>>>   OvmfPkg: Copy Legacy8259 protocol definitions from IntelFrameworkPkg
>>>   OvmfPkg/OvmfPkg.dec: Add 8259-related PCDs in OVMF DEC file
>>>   OvmfPkg/8259InterruptControllerDxe: Update to make it build for OVMF
>>>   OvmfPkg/AcpiPlatformDxe: Consume the 8259 PCD defined in OvmfPkg
>>>   OvmfPkg: Copy 8254TimerDxe driver from PcAtChipsetPkg
>>>   OvmfPkg/8254TimerDxe: Update to make it build for OVMF
>>>   OvmfPkg: Update DSC/FDF files to consume 8259/8254 drivers in OvmfPkg
>>
>> While I'm reviewing the patches individually, let me make some general
>> comments:
>>
>> - please don't push the series before April 9th (i.e., before the end of
>> the file addition/removal freeze due to
>> )
>>
>> - if/when you push the series, please make sure that *all* files added
>> (copied) under OvmfPkg get the new license block format, i.e. the SPDX
>> license identifier only.
> 
> ... in fact, at that time, the license blocks under the *source*
> packages (PcAtChipsetPkg and IntelFrameworkPkg) will have been updated,
> so you will have to redo the copying steps anyway (and you can verify
> those on your end: "git show --find-copies-harder" should show now
> modifications as part of the copy operations).

Sigh. I meant

  "git show --find-copies-harder" should show *no* modifications as part
  of the copy operations

Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] aarch64-linux-gnu-gcc.exe: error due to loss ‘/’in code path in in Jenkins server

[wang xiaofeng]

manually trigger have the same error 








At 2019-04-03 20:51:16, "Gao, Liming"  wrote:
>I mean to manually trig build in Jenkins server and see what happen.
>
>Thanks
>Liming
>From: wang xiaofeng [mailto:winggundu...@163.com]
>Sent: Wednesday, April 3, 2019 8:16 PM
>To: Gao, Liming 
>Cc: edk2-devel@lists.01.org; ard.biesheu...@linaro.org; 
>leif.lindh...@linaro.org
>Subject: Re:Re: [edk2] aarch64-linux-gnu-gcc.exe: error due to loss ‘/’in code 
>path in in Jenkins server
>
>HI Liming,
>   I don;t have direct access to server but  I can ask someone to try.
>   How to verify gcc tool enviroment? any command I can run to check the 
> difference?
>   I just compare the gcc tool binarys , server and my local desktop are same. 
> But I am not sure whether other software/enviroment is installed on server 
> may affect the tools.
>
>
>
>
>At 2019-04-03 20:00:09, "Gao, Liming" 
>mailto:liming@intel.com>> wrote:
>
>>Are your local server the same environment to Jenkins server? Can you login 
>>in Jenkins sever and verify gcc tool?
>
>>
>
>>Thanks
>
>>Liming
>
>>From: wang xiaofeng [mailto:winggundu...@163.com]
>
>>Sent: Wednesday, April 3, 2019 3:55 PM
>
>>To: Gao, Liming mailto:liming@intel.com>>; 
>>edk2-devel@lists.01.org; 
>>ard.biesheu...@linaro.org; 
>>leif.lindh...@linaro.org
>
>>Subject: aarch64-linux-gnu-gcc.exe: error due to loss ‘/’in code path in in 
>>Jenkins server
>
>>
>
>>HI ARM Base tool owners,
>
>>   I meet a strange issue that aarch64 build . The aarch64 build pass on my 
>> local server.  But it fails at Jenkins server(a Win10 autobuild system 
>> written by Java that will can call edk2 bat in command line)
>
>>
>
>>The build command is 
>>"c:\jenkins\workspace\gop2018\udk2018\gnutools\gcc-linaro-7.3.1-2018.05-i686-mingw32_aarch64-linux-gnu\bin\aarch64-linux-gnu-gcc"
>> -g -fshort-wchar -fno-builtin -fno-strict-aliasing -Wall -Werror 
>>-Wno-array-bounds -ffunction-sections -fdata-sections -include AutoGen.h 
>>-fno-common -DSTRING_ARRAY_NAME=UefiDevicePathLibStrings -g -Os -fshort-wchar 
>>-fno-builtin -fno-strict-aliasing -Wall -Werror -Wno-missing-braces 
>>-Wno-array-bounds -include AutoGen.h -fno-common -mlittle-endian 
>>-fno-short-enums -fverbose-asm -funsigned-char -ffunction-sections 
>>-fdata-sections -Wno-address -fno-asynchronous-unwind-tables -fno-pic 
>>-fno-pie -ffixed-x18 -flto -Wno-unused-but-set-variable 
>>-Wno-unused-const-variable -mcmodel=small -DEDKII -DEFIX64 -DUEFI_BUILD 
>>-DFGL_LINUX -DGCC_TOOLCHAIN -c -o 
>>c:\jenkins\workspace\gop2018\udk2018\Build\AmdGopPkg\DEBUG_GCC5\AARCH64\MdePkg\Library\UefiDevicePathLib\UefiDevicePathLib\OUTPUT\.\DevicePathUtilities.obj
>> -Ic:\jenkins\workspace\gop2018\udk2018\MdePkg\Library\UefiDevicePathLib 
>>-Ic:\jenkins\workspace\gop2018\udk2018\Build\AmdGopPkg\DEBUG_GCC5\AARCH64\MdePkg\Library\UefiDevicePathLib\UefiDevicePathLib\DEBUG
>> -Ic:\jenkins\workspace\gop2018\udk2018\MdePkg 
>>-Ic:\jenkins\workspace\gop2018\udk2018\MdePkg\Include 
>>-Ic:\jenkins\workspace\gop2018\udk2018\MdePkg\Include\AArch64 
>>c:\jenkins\workspace\gop2018\udk2018\MdePkg\Library\UefiDevicePathLib\DevicePathUtilities.c
>
>>
>
>>But aarch64-linux-gnu-gcc.exe will return error with : 
>>c:jenkinsworkspacegop2018udk2018MdePkgLibraryUefiDevicePathLibDevicePathUtilities.c:
>> No such file or director
>
>>The failure is due to all \ is missed from view of aarch64-linux-gnu-gcc.exe, 
>>while the makefile and build log have '\'
>
>>Another clue is that x86 build is ok on the same Jenkins system
>
>>
>
>>Anyone have advice for this strange issue?
>
>>
>
>>
>
>>
>
>>
>
>>___
>
>>edk2-devel mailing list
>
>>edk2-devel@lists.01.org
>
>>https://lists.01.org/mailman/listinfo/edk2-devel
>
>
>
>___
>edk2-devel mailing list
>edk2-devel@lists.01.org
>https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [RFC PATCH v1 8/8] OvmfPkg: Update DSC/FDF files to consume 8259/8254 drivers in OvmfPkg

[Laszlo Ersek]

On 04/03/19 09:00, Hao Wu wrote:
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1496
> 
> This commit updates the OVMF DSC/FDF files to consume the copied
> 8259InterruptControllerDxe and 8254TimerDxe drivers within OvmfPkg.
> 
> The unconsumed PCD:
> gPcAtChipsetPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel
> 
> is removed from DSC files as well.
> 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Cc: David Woodhouse 
> Cc: Ray Ni 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Hao Wu 
> ---
>  OvmfPkg/OvmfPkgIa32.dsc| 3 ---
>  OvmfPkg/OvmfPkgIa32X64.dsc | 3 ---
>  OvmfPkg/OvmfPkgX64.dsc | 3 ---
>  OvmfPkg/OvmfPkgIa32.fdf| 4 ++--
>  OvmfPkg/OvmfPkgIa32X64.fdf | 4 ++--
>  OvmfPkg/OvmfPkgX64.fdf | 4 ++--
>  6 files changed, 6 insertions(+), 15 deletions(-)
> 
> diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
> index d88295f9fd..692da9584d 100644
> --- a/OvmfPkg/OvmfPkgIa32.dsc
> +++ b/OvmfPkg/OvmfPkgIa32.dsc
> @@ -516,7 +516,6 @@
>  !endif
>  
># IRQs 5, 9, 10, 11 are level-triggered
> -  gPcAtChipsetPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel|0x0E20
>gUefiOvmfPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel|0x0E20
>  
># Point to the MdeModulePkg/Application/UiApp/UiApp.inf
> @@ -669,11 +668,9 @@
>}
>  
>MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
> -  PcAtChipsetPkg/8259InterruptControllerDxe/8259.inf
>OvmfPkg/8259InterruptControllerDxe/8259.inf
>UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
>UefiCpuPkg/CpuDxe/CpuDxe.inf
> -  PcAtChipsetPkg/8254TimerDxe/8254Timer.inf
>OvmfPkg/8254TimerDxe/8254Timer.inf
>OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf
>OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.inf
> diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
> index a83b6f448e..01b2530064 100644
> --- a/OvmfPkg/OvmfPkgIa32X64.dsc
> +++ b/OvmfPkg/OvmfPkgIa32X64.dsc
> @@ -522,7 +522,6 @@
>  !endif
>  
># IRQs 5, 9, 10, 11 are level-triggered
> -  gPcAtChipsetPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel|0x0E20
>gUefiOvmfPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel|0x0E20
>  
># Point to the MdeModulePkg/Application/UiApp/UiApp.inf
> @@ -678,11 +677,9 @@
>}
>  
>MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
> -  PcAtChipsetPkg/8259InterruptControllerDxe/8259.inf
>OvmfPkg/8259InterruptControllerDxe/8259.inf
>UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
>UefiCpuPkg/CpuDxe/CpuDxe.inf
> -  PcAtChipsetPkg/8254TimerDxe/8254Timer.inf
>OvmfPkg/8254TimerDxe/8254Timer.inf
>OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf
>OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.inf
> diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
> index ad9816a165..444a00c87d 100644
> --- a/OvmfPkg/OvmfPkgX64.dsc
> +++ b/OvmfPkg/OvmfPkgX64.dsc
> @@ -521,7 +521,6 @@
>  !endif
>  
># IRQs 5, 9, 10, 11 are level-triggered
> -  gPcAtChipsetPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel|0x0E20
>gUefiOvmfPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel|0x0E20
>  
># Point to the MdeModulePkg/Application/UiApp/UiApp.inf
> @@ -676,11 +675,9 @@
>}
>  
>MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
> -  PcAtChipsetPkg/8259InterruptControllerDxe/8259.inf
>OvmfPkg/8259InterruptControllerDxe/8259.inf
>UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
>UefiCpuPkg/CpuDxe/CpuDxe.inf
> -  PcAtChipsetPkg/8254TimerDxe/8254Timer.inf
>OvmfPkg/8254TimerDxe/8254Timer.inf
>OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf
>OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.inf
> diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf
> index 006ea9a415..423984b4b9 100644
> --- a/OvmfPkg/OvmfPkgIa32.fdf
> +++ b/OvmfPkg/OvmfPkgIa32.fdf
> @@ -213,10 +213,10 @@ INF  MdeModulePkg/Universal/PCD/Dxe/Pcd.inf
>  INF  MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
>  INF  MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
>  INF  MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
> -INF  PcAtChipsetPkg/8259InterruptControllerDxe/8259.inf
> +INF  OvmfPkg/8259InterruptControllerDxe/8259.inf
>  INF  UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
>  INF  UefiCpuPkg/CpuDxe/CpuDxe.inf
> -INF  PcAtChipsetPkg/8254TimerDxe/8254Timer.inf
> +INF  OvmfPkg/8254TimerDxe/8254Timer.inf
>  INF  OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf
>  INF  OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.inf
>  INF  MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf
> diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/OvmfPkgIa32X64.fdf
> index 6c40540202..45eb561e3f 100644
> --- a/OvmfPkg/OvmfPkgIa32X64.fdf
> +++ b/OvmfPkg/OvmfPkgIa32X64.fdf
> @@ -214,10 +214,10 @@ INF  MdeModulePkg/Universal/PCD/Dxe/Pcd.inf
>  INF  MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
>  INF  MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
>  INF  MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
> -INF  PcAtChipsetPkg/8259InterruptControllerDxe/8259.inf
> +INF  

Re: [edk2] [RFC PATCH v1 7/8] OvmfPkg/8254TimerDxe: Update to make it build for OVMF

[Laszlo Ersek]

On 04/03/19 09:00, Hao Wu wrote:
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1496
> 
> This commit will remove the IntelFrameworkPkg DEC file dependency in the
> driver INF file.
> 
> A new GUID has been updated for the INF file.
> 
> Corresponding changes have been made in OVMF DSC files as well in order to
> verify the build.

(1) Please add the same hint that I asked for under v1 4/8.

With that:

Reviewed-by: Laszlo Ersek 

Thanks
Laszlo

> 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Cc: David Woodhouse 
> Cc: Ray Ni 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Hao Wu 
> ---
>  OvmfPkg/OvmfPkgIa32.dsc| 1 +
>  OvmfPkg/OvmfPkgIa32X64.dsc | 1 +
>  OvmfPkg/OvmfPkgX64.dsc | 1 +
>  OvmfPkg/8254TimerDxe/8254Timer.inf | 6 +++---
>  4 files changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
> index 47182f0cad..d88295f9fd 100644
> --- a/OvmfPkg/OvmfPkgIa32.dsc
> +++ b/OvmfPkg/OvmfPkgIa32.dsc
> @@ -674,6 +674,7 @@
>UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
>UefiCpuPkg/CpuDxe/CpuDxe.inf
>PcAtChipsetPkg/8254TimerDxe/8254Timer.inf
> +  OvmfPkg/8254TimerDxe/8254Timer.inf
>OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf
>OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.inf
>MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf {
> diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
> index d9603a7107..a83b6f448e 100644
> --- a/OvmfPkg/OvmfPkgIa32X64.dsc
> +++ b/OvmfPkg/OvmfPkgIa32X64.dsc
> @@ -683,6 +683,7 @@
>UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
>UefiCpuPkg/CpuDxe/CpuDxe.inf
>PcAtChipsetPkg/8254TimerDxe/8254Timer.inf
> +  OvmfPkg/8254TimerDxe/8254Timer.inf
>OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf
>OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.inf
>MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf {
> diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
> index 2cc39d54b0..ad9816a165 100644
> --- a/OvmfPkg/OvmfPkgX64.dsc
> +++ b/OvmfPkg/OvmfPkgX64.dsc
> @@ -681,6 +681,7 @@
>UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
>UefiCpuPkg/CpuDxe/CpuDxe.inf
>PcAtChipsetPkg/8254TimerDxe/8254Timer.inf
> +  OvmfPkg/8254TimerDxe/8254Timer.inf
>OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf
>OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.inf
>MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf {
> diff --git a/OvmfPkg/8254TimerDxe/8254Timer.inf 
> b/OvmfPkg/8254TimerDxe/8254Timer.inf
> index 46cf01de39..93bee768ed 100644
> --- a/OvmfPkg/8254TimerDxe/8254Timer.inf
> +++ b/OvmfPkg/8254TimerDxe/8254Timer.inf
> @@ -1,7 +1,7 @@
>  ## @file
>  # 8254 timer driver that provides Timer Arch protocol.
>  #
> -# Copyright (c) 2005 - 2018, Intel Corporation. All rights reserved.
> +# Copyright (c) 2005 - 2019, Intel Corporation. All rights reserved.
>  # This program and the accompanying materials
>  # are licensed and made available under the terms and conditions of the BSD 
> License
>  # which accompanies this distribution.  The full text of the license may be 
> found at
> @@ -16,7 +16,7 @@
>INF_VERSION= 0x00010005
>BASE_NAME  = Timer
>MODULE_UNI_FILE= Timer.uni
> -  FILE_GUID  = f2765dec-6b41-11d5-8e71-00902707b35e
> +  FILE_GUID  = C190FE35-44AA-41A1-8AEA-4947BC60E09D
>MODULE_TYPE= DXE_DRIVER
>VERSION_STRING = 1.0
>  
> @@ -24,7 +24,7 @@
>  
>  [Packages]
>MdePkg/MdePkg.dec
> -  IntelFrameworkPkg/IntelFrameworkPkg.dec
> +  OvmfPkg/OvmfPkg.dec
>  
>  [LibraryClasses]
>UefiBootServicesTableLib
> 

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] aarch64-linux-gnu-gcc.exe: error due to loss ‘/’in code path in in Jenkins server

[Gao, Liming]

I mean to manually trig build in Jenkins server and see what happen.

Thanks
Liming
From: wang xiaofeng [mailto:winggundu...@163.com]
Sent: Wednesday, April 3, 2019 8:16 PM
To: Gao, Liming 
Cc: edk2-devel@lists.01.org; ard.biesheu...@linaro.org; leif.lindh...@linaro.org
Subject: Re:Re: [edk2] aarch64-linux-gnu-gcc.exe: error due to loss ‘/’in code 
path in in Jenkins server

HI Liming,
   I don;t have direct access to server but  I can ask someone to try.
   How to verify gcc tool enviroment? any command I can run to check the 
difference?
   I just compare the gcc tool binarys , server and my local desktop are same. 
But I am not sure whether other software/enviroment is installed on server may 
affect the tools.




At 2019-04-03 20:00:09, "Gao, Liming" 
mailto:liming@intel.com>> wrote:

>Are your local server the same environment to Jenkins server? Can you login in 
>Jenkins sever and verify gcc tool?

>

>Thanks

>Liming

>From: wang xiaofeng [mailto:winggundu...@163.com]

>Sent: Wednesday, April 3, 2019 3:55 PM

>To: Gao, Liming mailto:liming@intel.com>>; 
>edk2-devel@lists.01.org; 
>ard.biesheu...@linaro.org; 
>leif.lindh...@linaro.org

>Subject: aarch64-linux-gnu-gcc.exe: error due to loss ‘/’in code path in in 
>Jenkins server

>

>HI ARM Base tool owners,

>   I meet a strange issue that aarch64 build . The aarch64 build pass on my 
> local server.  But it fails at Jenkins server(a Win10 autobuild system 
> written by Java that will can call edk2 bat in command line)

>

>The build command is 
>"c:\jenkins\workspace\gop2018\udk2018\gnutools\gcc-linaro-7.3.1-2018.05-i686-mingw32_aarch64-linux-gnu\bin\aarch64-linux-gnu-gcc"
> -g -fshort-wchar -fno-builtin -fno-strict-aliasing -Wall -Werror 
>-Wno-array-bounds -ffunction-sections -fdata-sections -include AutoGen.h 
>-fno-common -DSTRING_ARRAY_NAME=UefiDevicePathLibStrings -g -Os -fshort-wchar 
>-fno-builtin -fno-strict-aliasing -Wall -Werror -Wno-missing-braces 
>-Wno-array-bounds -include AutoGen.h -fno-common -mlittle-endian 
>-fno-short-enums -fverbose-asm -funsigned-char -ffunction-sections 
>-fdata-sections -Wno-address -fno-asynchronous-unwind-tables -fno-pic -fno-pie 
>-ffixed-x18 -flto -Wno-unused-but-set-variable -Wno-unused-const-variable 
>-mcmodel=small -DEDKII -DEFIX64 -DUEFI_BUILD -DFGL_LINUX -DGCC_TOOLCHAIN -c -o 
>c:\jenkins\workspace\gop2018\udk2018\Build\AmdGopPkg\DEBUG_GCC5\AARCH64\MdePkg\Library\UefiDevicePathLib\UefiDevicePathLib\OUTPUT\.\DevicePathUtilities.obj
> -Ic:\jenkins\workspace\gop2018\udk2018\MdePkg\Library\UefiDevicePathLib 
>-Ic:\jenkins\workspace\gop2018\udk2018\Build\AmdGopPkg\DEBUG_GCC5\AARCH64\MdePkg\Library\UefiDevicePathLib\UefiDevicePathLib\DEBUG
> -Ic:\jenkins\workspace\gop2018\udk2018\MdePkg 
>-Ic:\jenkins\workspace\gop2018\udk2018\MdePkg\Include 
>-Ic:\jenkins\workspace\gop2018\udk2018\MdePkg\Include\AArch64 
>c:\jenkins\workspace\gop2018\udk2018\MdePkg\Library\UefiDevicePathLib\DevicePathUtilities.c

>

>But aarch64-linux-gnu-gcc.exe will return error with : 
>c:jenkinsworkspacegop2018udk2018MdePkgLibraryUefiDevicePathLibDevicePathUtilities.c:
> No such file or director

>The failure is due to all \ is missed from view of aarch64-linux-gnu-gcc.exe, 
>while the makefile and build log have '\'

>Another clue is that x86 build is ok on the same Jenkins system

>

>Anyone have advice for this strange issue?

>

>

>

>

>___

>edk2-devel mailing list

>edk2-devel@lists.01.org

>https://lists.01.org/mailman/listinfo/edk2-devel



___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [RFC PATCH v1 6/8] OvmfPkg: Copy 8254TimerDxe driver from PcAtChipsetPkg

[Laszlo Ersek]

On 04/03/19 09:00, Hao Wu wrote:
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1496
> 
> This commit copies the exact 8254TimerDxe driver from PcAtChipsetPkg to
> OvmfPkg.
> 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Cc: David Woodhouse 
> Cc: Ray Ni 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Hao Wu 
> ---
>  OvmfPkg/8254TimerDxe/8254Timer.inf  |  48 +++
>  OvmfPkg/8254TimerDxe/Timer.h| 191 +
>  OvmfPkg/8254TimerDxe/Timer.c| 407 
>  OvmfPkg/8254TimerDxe/Timer.uni  |  22 ++
>  OvmfPkg/8254TimerDxe/TimerExtra.uni |  20 +
>  5 files changed, 688 insertions(+)

Reviewed-by: Laszlo Ersek 

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [RFC PATCH v1 5/8] OvmfPkg/AcpiPlatformDxe: Consume the 8259 PCD defined in OvmfPkg

[Laszlo Ersek]

On 04/03/19 09:00, Hao Wu wrote:
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1496
> 
> Several updates have been made to the OvmfPkg/AcpiPlatformDxe driver to
> drop its dependency on PcAtChipsetPkg:
> 
> A) Consumes the PCD 'Pcd8259LegacyModeEdgeLevel' defined within OvmfPkg;
> B) Remove the PcAtChipsetPkg DEC file dependency in the driver INF file.
> 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Cc: David Woodhouse 
> Cc: Ray Ni 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Hao Wu 
> ---
>  OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf 
> b/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
> index 8440e7b343..24e2c0373f 100644
> --- a/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
> +++ b/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
> @@ -1,7 +1,7 @@
>  ## @file
>  #  OVMF ACPI Platform Driver
>  #
> -#  Copyright (c) 2008 - 2018, Intel Corporation. All rights reserved.
> +#  Copyright (c) 2008 - 2019, Intel Corporation. All rights reserved.
>  #  This program and the accompanying materials
>  #  are licensed and made available under the terms and conditions of the BSD 
> License
>  #  which accompanies this distribution.  The full text of the license may be 
> found at
> @@ -42,7 +42,6 @@
>MdeModulePkg/MdeModulePkg.dec
>OvmfPkg/OvmfPkg.dec
>UefiCpuPkg/UefiCpuPkg.dec
> -  PcAtChipsetPkg/PcAtChipsetPkg.dec
>  
>  [LibraryClasses]
>UefiLib
> @@ -72,7 +71,7 @@
>gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiTableStorageFile
>gEfiMdeModulePkgTokenSpaceGuid.PcdPciDisableBusEnumeration
>gUefiCpuPkgTokenSpaceGuid.PcdCpuLocalApicBaseAddress
> -  gPcAtChipsetPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel
> +  gUefiOvmfPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel
>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFdBaseAddress
>  
>  [Depex]
> 

Reviewed-by: Laszlo Ersek 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [RFC PATCH v1 4/8] OvmfPkg/8259InterruptControllerDxe: Update to make it build for OVMF

[Laszlo Ersek]

On 04/03/19 09:00, Hao Wu wrote:
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1496
> 
> Several updates have been made to the
> OvmfPkg/8259InterruptControllerDxe driver to make it build under OvmfPkg:
> 
> A) Update the driver INF file to consume PCDs defined within OvmfPkg;
> B) Remove the unnecessary dependency on the IntelFrameworkPkg header file
>'FrameworkDxe.h';
> C) Remove the IntelFrameworkPkg & PcAtChipsetPkg DEC files dependency in
>the driver INF file.
> 
> A new GUID has been updated for the INF file.
> 
> Corresponding changes have been made in OVMF DSC files as well in order to
> verify the build.

(1) This patch is really well done, but we need an extra hint here, in
the last paragraph of the commit message, namely that the DSC and FDF
files will get a final update (= removals) later in this series.

With that spelled out:

Reviewed-by: Laszlo Ersek 

Thanks
Laszlo

> 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Cc: David Woodhouse 
> Cc: Ray Ni 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Hao Wu 
> ---
>  OvmfPkg/OvmfPkgIa32.dsc |  2 ++
>  OvmfPkg/OvmfPkgIa32X64.dsc  |  2 ++
>  OvmfPkg/OvmfPkgX64.dsc  |  2 ++
>  OvmfPkg/8259InterruptControllerDxe/8259.inf | 11 +--
>  OvmfPkg/8259InterruptControllerDxe/8259.h   |  4 +---
>  5 files changed, 12 insertions(+), 9 deletions(-)
> 
> diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
> index f55ab5a3d2..47182f0cad 100644
> --- a/OvmfPkg/OvmfPkgIa32.dsc
> +++ b/OvmfPkg/OvmfPkgIa32.dsc
> @@ -517,6 +517,7 @@
>  
># IRQs 5, 9, 10, 11 are level-triggered
>gPcAtChipsetPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel|0x0E20
> +  gUefiOvmfPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel|0x0E20
>  
># Point to the MdeModulePkg/Application/UiApp/UiApp.inf
>gEfiMdeModulePkgTokenSpaceGuid.PcdBootManagerMenuFile|{ 0x21, 0xaa, 0x2c, 
> 0x46, 0x14, 0x76, 0x03, 0x45, 0x83, 0x6e, 0x8a, 0xb6, 0xf4, 0x66, 0x23, 0x31 }
> @@ -669,6 +670,7 @@
>  
>MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
>PcAtChipsetPkg/8259InterruptControllerDxe/8259.inf
> +  OvmfPkg/8259InterruptControllerDxe/8259.inf
>UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
>UefiCpuPkg/CpuDxe/CpuDxe.inf
>PcAtChipsetPkg/8254TimerDxe/8254Timer.inf
> diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
> index 5c9bdf034e..d9603a7107 100644
> --- a/OvmfPkg/OvmfPkgIa32X64.dsc
> +++ b/OvmfPkg/OvmfPkgIa32X64.dsc
> @@ -523,6 +523,7 @@
>  
># IRQs 5, 9, 10, 11 are level-triggered
>gPcAtChipsetPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel|0x0E20
> +  gUefiOvmfPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel|0x0E20
>  
># Point to the MdeModulePkg/Application/UiApp/UiApp.inf
>gEfiMdeModulePkgTokenSpaceGuid.PcdBootManagerMenuFile|{ 0x21, 0xaa, 0x2c, 
> 0x46, 0x14, 0x76, 0x03, 0x45, 0x83, 0x6e, 0x8a, 0xb6, 0xf4, 0x66, 0x23, 0x31 }
> @@ -678,6 +679,7 @@
>  
>MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
>PcAtChipsetPkg/8259InterruptControllerDxe/8259.inf
> +  OvmfPkg/8259InterruptControllerDxe/8259.inf
>UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
>UefiCpuPkg/CpuDxe/CpuDxe.inf
>PcAtChipsetPkg/8254TimerDxe/8254Timer.inf
> diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
> index 2943e9e8af..2cc39d54b0 100644
> --- a/OvmfPkg/OvmfPkgX64.dsc
> +++ b/OvmfPkg/OvmfPkgX64.dsc
> @@ -522,6 +522,7 @@
>  
># IRQs 5, 9, 10, 11 are level-triggered
>gPcAtChipsetPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel|0x0E20
> +  gUefiOvmfPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel|0x0E20
>  
># Point to the MdeModulePkg/Application/UiApp/UiApp.inf
>gEfiMdeModulePkgTokenSpaceGuid.PcdBootManagerMenuFile|{ 0x21, 0xaa, 0x2c, 
> 0x46, 0x14, 0x76, 0x03, 0x45, 0x83, 0x6e, 0x8a, 0xb6, 0xf4, 0x66, 0x23, 0x31 }
> @@ -676,6 +677,7 @@
>  
>MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
>PcAtChipsetPkg/8259InterruptControllerDxe/8259.inf
> +  OvmfPkg/8259InterruptControllerDxe/8259.inf
>UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
>UefiCpuPkg/CpuDxe/CpuDxe.inf
>PcAtChipsetPkg/8254TimerDxe/8254Timer.inf
> diff --git a/OvmfPkg/8259InterruptControllerDxe/8259.inf 
> b/OvmfPkg/8259InterruptControllerDxe/8259.inf
> index 1d9be675e3..c5a1385418 100644
> --- a/OvmfPkg/8259InterruptControllerDxe/8259.inf
> +++ b/OvmfPkg/8259InterruptControllerDxe/8259.inf
> @@ -1,7 +1,7 @@
>  ## @file
>  # 8259 Interrupt Controller driver that provides Legacy 8259 protocol.
>  #
> -# Copyright (c) 2005 - 2018, Intel Corporation. All rights reserved.
> +# Copyright (c) 2005 - 2019, Intel Corporation. All rights reserved.
>  # This program and the accompanying materials
>  # are licensed and made available under the terms and conditions of the BSD 
> License
>  # which accompanies this distribution.  The full text of the license may be 
> found at
> @@ -16,7 +16,7 @@
>INF_VERSION= 0x00010005
>BASE_NAME  = Legacy8259
>   

Re: [edk2] [RFC PATCH v1 3/8] OvmfPkg/OvmfPkg.dec: Add 8259-related PCDs in OVMF DEC file

[Laszlo Ersek]

On 04/03/19 09:00, Hao Wu wrote:
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1496
> 
> According to the DEC file in PcAtChipsetPkg, this commit adds the two
> 8259-driver-related PCDs into the OvmfPkg DEC file.
> 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Cc: David Woodhouse 
> Cc: Ray Ni 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Hao Wu 
> ---
>  OvmfPkg/OvmfPkg.dec | 26 
>  1 file changed, 26 insertions(+)
> 
> diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
> index fb89ebf3ad..cb838422aa 100644
> --- a/OvmfPkg/OvmfPkg.dec
> +++ b/OvmfPkg/OvmfPkg.dec
> @@ -128,6 +128,32 @@
>gUefiOvmfPkgTokenSpaceGuid.PcdGuidedExtractHandlerTableSize|0x0|UINT32|0x1a
>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDecompressionScratchEnd|0x0|UINT32|0x1f
>  
> +  ## Pcd8259LegacyModeMask defines the default mask value for platform. This
> +  #  value is determined.
> +  #  1) If platform only support pure UEFI, value should be set to 0x or
> +  # 0xFFFE; Because only clock interrupt is allowed in legacy mode in 
> pure
> +  # UEFI platform.
> +  #  2) If platform install CSM and use thunk module:
> +  # a) If thunk call provided by CSM binary requires some legacy 
> interrupt
> +  #support, the corresponding bit should be opened as 0.
> +  #For example, if keyboard interfaces provided CSM binary use legacy
> +  #keyboard interrupt in 8259 bit 1, then the value should be set to
> +  #0xFFFC.
> +  # b) If all thunk call provied by CSM binary do not require legacy
> +  #interrupt support, value should be set to 0x or 0xFFFE.
> +  #
> +  #  The default value of legacy mode mask could be changed by
> +  #  EFI_LEGACY_8259_PROTOCOL->SetMask(). But it is rarely need change it
> +  #  except some special cases such as when initializing the CSM binary, it
> +  #  should be set to 0x to mask all legacy interrupt. Please restore the
> +  #  original legacy mask value if changing is made for these special case.
> +  gUefiOvmfPkgTokenSpaceGuid.Pcd8259LegacyModeMask|0x|UINT16|0x28
> +
> +  ## Pcd8259LegacyModeEdgeLevel defines the default edge level for legacy
> +  #  mode's interrrupt controller.
> +  #  For the corresponding bits, 0 = Edge triggered and 1 = Level triggered.
> +  gUefiOvmfPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel|0x|UINT16|0x29
> +
>  [PcdsDynamic, PcdsDynamicEx]
>gUefiOvmfPkgTokenSpaceGuid.PcdEmuVariableEvent|0|UINT64|2
>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashVariablesEnable|FALSE|BOOLEAN|0x10
> 

Thank you for wrapping the comments so nicely!


(1) In PcAtChipsetPkg.dec, both PCDs are declared under:

[PcdsFixedAtBuild, PcdsDynamic, PcdsDynamicEx, PcdsPatchableInModule]

but in OvmfPkg, this patch introduces both PCDs under just

[PcdsFixedAtBuild]

I think that's fine for now, but please mention this change in the
commit message.


(2) OVMF's PCD token space seems to have some holes, namely at: 3
decimal, 5 decimal, and 0x17.

Can you introduce the new PCDs with tokens 3 and 5, just to decrease the
fragmentation?


With (1) and (2) addressed:

Reviewed-by: Laszlo Ersek 

Thanks,
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [RFC PATCH v1 2/8] OvmfPkg: Copy Legacy8259 protocol definitions from IntelFrameworkPkg

[Laszlo Ersek]

On 04/03/19 09:00, Hao Wu wrote:
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1496
> 
> This commit copies the exact Legacy8259 protocol header file from
> IntelFrameworkPkg to OvmfPkg. Also, the protocol GUID definition is
> duplicated in the OvmfPkg DEC file.
> 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Cc: David Woodhouse 
> Cc: Ray Ni 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Hao Wu 
> ---
>  OvmfPkg/OvmfPkg.dec   |   3 +-
>  OvmfPkg/Include/Protocol/Legacy8259.h | 297 
>  2 files changed, 299 insertions(+), 1 deletion(-)
> 
> diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
> index e50c6179a2..fb89ebf3ad 100644
> --- a/OvmfPkg/OvmfPkg.dec
> +++ b/OvmfPkg/OvmfPkg.dec
> @@ -1,7 +1,7 @@
>  ## @file
>  #  EFI/Framework Open Virtual Machine Firmware (OVMF) platform
>  #
> -#  Copyright (c) 2006 - 2013, Intel Corporation. All rights reserved.
> +#  Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
>  #
>  #  This program and the accompanying materials
>  #  are licensed and made available under the terms and conditions of the BSD 
> License
> @@ -89,6 +89,7 @@
>gXenBusProtocolGuid = {0x3d3ca290, 0xb9a5, 0x11e3, {0xb7, 
> 0x5d, 0xb8, 0xac, 0x6f, 0x7d, 0x65, 0xe6}}
>gXenIoProtocolGuid  = {0x6efac84f, 0x0ab0, 0x4747, {0x81, 
> 0xbe, 0x85, 0x55, 0x62, 0x59, 0x04, 0x49}}
>gIoMmuAbsentProtocolGuid= {0xf8775d50, 0x8abd, 0x4adf, {0x92, 
> 0xac, 0x85, 0x3e, 0x51, 0xf6, 0xc8, 0xdc}}
> +  gEfiLegacy8259ProtocolGuid  = {0x38321dba, 0x4fe0, 0x4e17, {0x8a, 
> 0xec, 0x41, 0x30, 0x55, 0xea, 0xed, 0xc1}}
>  
>  [PcdsFixedAtBuild]
>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvBase|0x0|UINT32|0

(This comment is not about the patch, but your git setup.)

Please update your git config so that "git format-patch" and its friends
display the INI-style section, such as [Protocols], in the diff hunk
headers. The expected result is:

@@ -89,6 +89,7 @@ [Protocols]
  ^^^

You can find documentation at:

-
https://github.com/tianocore/tianocore.github.io/wiki/Laszlo's-unkempt-git-guide-for-edk2-contributors-and-maintainers#contrib-05
(see the 'diff.ini.xfuncname' setting)

-
https://github.com/tianocore/tianocore.github.io/wiki/Laszlo's-unkempt-git-guide-for-edk2-contributors-and-maintainers#contrib-09

For this patch:

Reviewed-by: Laszlo Ersek 

Thanks
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] aarch64-linux-gnu-gcc.exe: error due to loss ‘/’in code path in in Jenkins server

[wang xiaofeng]

HI Liming,
   I don;t have direct access to server but  I can ask someone to try. 
   How to verify gcc tool enviroment? any command I can run to check the 
difference?
   I just compare the gcc tool binarys , server and my local desktop are same. 
But I am not sure whether other software/enviroment is installed on server may 
affect the tools.







At 2019-04-03 20:00:09, "Gao, Liming"  wrote:
>Are your local server the same environment to Jenkins server? Can you login in 
>Jenkins sever and verify gcc tool?
>
>Thanks
>Liming
>From: wang xiaofeng [mailto:winggundu...@163.com]
>Sent: Wednesday, April 3, 2019 3:55 PM
>To: Gao, Liming ; edk2-devel@lists.01.org; 
>ard.biesheu...@linaro.org; leif.lindh...@linaro.org
>Subject: aarch64-linux-gnu-gcc.exe: error due to loss ‘/’in code path in in 
>Jenkins server
>
>HI ARM Base tool owners,
>   I meet a strange issue that aarch64 build . The aarch64 build pass on my 
> local server.  But it fails at Jenkins server(a Win10 autobuild system 
> written by Java that will can call edk2 bat in command line)
>
>The build command is 
>"c:\jenkins\workspace\gop2018\udk2018\gnutools\gcc-linaro-7.3.1-2018.05-i686-mingw32_aarch64-linux-gnu\bin\aarch64-linux-gnu-gcc"
> -g -fshort-wchar -fno-builtin -fno-strict-aliasing -Wall -Werror 
>-Wno-array-bounds -ffunction-sections -fdata-sections -include AutoGen.h 
>-fno-common -DSTRING_ARRAY_NAME=UefiDevicePathLibStrings -g -Os -fshort-wchar 
>-fno-builtin -fno-strict-aliasing -Wall -Werror -Wno-missing-braces 
>-Wno-array-bounds -include AutoGen.h -fno-common -mlittle-endian 
>-fno-short-enums -fverbose-asm -funsigned-char -ffunction-sections 
>-fdata-sections -Wno-address -fno-asynchronous-unwind-tables -fno-pic -fno-pie 
>-ffixed-x18 -flto -Wno-unused-but-set-variable -Wno-unused-const-variable 
>-mcmodel=small -DEDKII -DEFIX64 -DUEFI_BUILD -DFGL_LINUX -DGCC_TOOLCHAIN -c -o 
>c:\jenkins\workspace\gop2018\udk2018\Build\AmdGopPkg\DEBUG_GCC5\AARCH64\MdePkg\Library\UefiDevicePathLib\UefiDevicePathLib\OUTPUT\.\DevicePathUtilities.obj
> -Ic:\jenkins\workspace\gop2018\udk2018\MdePkg\Library\UefiDevicePathLib 
>-Ic:\jenkins\workspace\gop2018\udk2018\Build\AmdGopPkg\DEBUG_GCC5\AARCH64\MdePkg\Library\UefiDevicePathLib\UefiDevicePathLib\DEBUG
> -Ic:\jenkins\workspace\gop2018\udk2018\MdePkg 
>-Ic:\jenkins\workspace\gop2018\udk2018\MdePkg\Include 
>-Ic:\jenkins\workspace\gop2018\udk2018\MdePkg\Include\AArch64 
>c:\jenkins\workspace\gop2018\udk2018\MdePkg\Library\UefiDevicePathLib\DevicePathUtilities.c
>
>But aarch64-linux-gnu-gcc.exe will return error with : 
>c:jenkinsworkspacegop2018udk2018MdePkgLibraryUefiDevicePathLibDevicePathUtilities.c:
> No such file or director
>The failure is due to all \ is missed from view of aarch64-linux-gnu-gcc.exe, 
>while the makefile and build log have '\'
>Another clue is that x86 build is ok on the same Jenkins system
>
>Anyone have advice for this strange issue?
>
>
>
>
>___
>edk2-devel mailing list
>edk2-devel@lists.01.org
>https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] aarch64-linux-gnu-gcc.exe: error due to loss ‘/’in code path in in Jenkins server

[wang xiaofeng]

Yes, both my local and server using Cygwin for aarch64 build 








At 2019-04-03 18:59:29, "Leif Lindholm"  wrote:
>On Wed, Apr 03, 2019 at 04:07:58PM +0800, wang xiaofeng wrote:
>> Hi Leif,
>>We use VC for X86 (do not need GCC cross complie)
>
>Ah, that was not clear from the original mail.
>
>Are both server and local system using cygwin/mingw32?
>
>Best Regards,
>
>Leif
>
>>gcc revision : 
>> Using built-in specs.
>> COLLECT_GCC=aarch64-linux-gnu-gcc.exe
>> COLLECT_LTO_WRAPPER=c:/code/gnutools/gcc-linaro-7.3.1-2018.05-i686-mingw32_aarch64-linux-gnu/bin/../libexec/gcc/aarch64-linux-gnu/7.3.1/lto-wrapper.exe
>> Target: aarch64-linux-gnu
>> Configured with: 
>> '/home/tcwg-buildslave/workspace/tcwg-make-release/builder_arch/amd64/label/tcwg-x86_64-build/target/aarch64-linux-gnu/snapshots/gcc.git~linaro-7.3-2018.05/configure'
>>  SHELL=/bin/bash 
>> --with-mpc=/home/tcwg-buildslave/workspace/tcwg-make-release/builder_arch/amd64/label/tcwg-x86_64-build/target/aarch64-linux-gnu/_build/builds/destdir/i686-w64-mingw32
>>  
>> --with-mpfr=/home/tcwg-buildslave/workspace/tcwg-make-release/builder_arch/amd64/label/tcwg-x86_64-build/target/aarch64-linux-gnu/_build/builds/destdir/i686-w64-mingw32
>>  
>> --with-gmp=/home/tcwg-buildslave/workspace/tcwg-make-release/builder_arch/amd64/label/tcwg-x86_64-build/target/aarch64-linux-gnu/_build/builds/destdir/i686-w64-mingw32
>>  --with-gnu-as --with-gnu-ld --disable-libmudflap --enable-lto 
>> --enable-shared --without-included-gettext --enable-nls --with-system-zlib 
>> --disable-sjlj-exceptions --enable-gnu-unique-object 
>> --enable-linker-build-id --disable-libstdcxx-pch --enable-c99 
>> --enable-clocale=gnu --enable-libstdcx
 x-debug --enable-long-long --with-cloog=no --with-ppl=no --with-isl=no 
--disable-multilib --enable-fix-cortex-a53-835769 
--enable-fix-cortex-a53-843419 --with-arch=armv8-a --enable-threads=posix 
--enable-multiarch --enable-libstdcxx-time=yes --enable-gnu-indirect-function 
--with-build-sysroot=/home/tcwg-buildslave/workspace/tcwg-make-release/builder_arch/amd64/label/tcwg-x86_64-build/target/aarch64-linux-gnu/_build/sysroots/aarch64-linux-gnu
 
--with-sysroot=/home/tcwg-buildslave/workspace/tcwg-make-release/builder_arch/amd64/label/tcwg-x86_64-build/target/aarch64-linux-gnu/_build/builds/destdir/i686-w64-mingw32/aarch64-linux-gnu/libc
 --enable-checking=release --disable-bootstrap 
--enable-languages=c,c++,fortran,lto 
--with-libiconv-prefix=/home/tcwg-buildslave/workspace/tcwg-make-release/builder_arch/amd64/label/tcwg-x86_64-build/target/aarch64-linux-gnu/_build/builds/destdir/i686-w64-mingw32/usr
 --with-system-zlib=no --build=x86_64-unknown-linux-gnu --host=i686-w64-mingw32 
--target=a
 arch64-linux-gnu 
--prefix=/home/tcwg-buildslave/workspace/tcwg-make-release/builder_arch/amd64/label/tcwg-x86_64-build/target/aarch64-linux-gnu/_build/builds/destdir/i686-w64-mingw32
>> Thread model: posix
>> gcc version 7.3.1 20180425 [linaro-7.3-2018.05 revision 
>> d29120a424ecfbc167ef90065c0eeb7f91977701] (Linaro GCC 7.3-2018.05)
>> 
>> 
>> 
>> 
>>GNUmake revision : GNUMake-3.81_win32
>> 
>> 
>>  Can the tool provide more debug output ?
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> At 2019-04-03 16:00:04, "Leif Lindholm"  wrote:
>> >Sami, any ideas?
>> >
>> >Xiaofeng, what gcc is being used for x86? (output of "gcc -v")
>> >
>> >Best Regards,
>> >
>> >Leif
>> >
>> >On Wed, Apr 03, 2019 at 03:54:33PM +0800, wang xiaofeng wrote:
>> >> HI ARM Base tool owners,
>> >>I meet a strange issue that aarch64 build . The aarch64 build pass on 
>> >> my local server.  But it fails at Jenkins server(a Win10 autobuild system 
>> >> written by Java that will can call edk2 bat in command line)
>> >> 
>> >> 
>> >> The build command is 
>> >> "c:\jenkins\workspace\gop2018\udk2018\gnutools\gcc-linaro-7.3.1-2018.05-i686-mingw32_aarch64-linux-gnu\bin\aarch64-linux-gnu-gcc"
>> >>  -g -fshort-wchar -fno-builtin -fno-strict-aliasing -Wall -Werror 
>> >> -Wno-array-bounds -ffunction-sections -fdata-sections -include AutoGen.h 
>> >> -fno-common -DSTRING_ARRAY_NAME=UefiDevicePathLibStrings -g -Os 
>> >> -fshort-wchar -fno-builtin -fno-strict-aliasing -Wall -Werror 
>> >> -Wno-missing-braces -Wno-array-bounds -include AutoGen.h -fno-common 
>> >> -mlittle-endian -fno-short-enums -fverbose-asm -funsigned-char 
>> >> -ffunction-sections -fdata-sections -Wno-address 
>> >> -fno-asynchronous-unwind-tables -fno-pic -fno-pie -ffixed-x18 -flto 
>> >> -Wno-unused-but-set-variable -Wno-unused-const-variable -mcmodel=small 
>> >> -DEDKII -DEFIX64 -DUEFI_BUILD -DFGL_LINUX -DGCC_TOOLCHAIN -c -o 
>> >> c:\jenkins\workspace\gop2018\udk2018\Build\AmdGopPkg\DEBUG_GCC5\AARCH64\MdePkg\Library\UefiDevicePathLib\UefiDevicePathLib\OUTPUT\.\DevicePathUtilities.obj
>> >>  -Ic:\jenkins\workspace\gop2018\udk201
 8\MdePkg\Library\UefiDevicePathLib 
-Ic:\jenkins\workspace\gop2018\udk2018\Build\AmdGopPkg\DEBUG_GCC5\AARCH64\MdePkg\Library\UefiDevicePathLib\UefiDevicePathLib\DEBUG
 

Re: [edk2] [RFC PATCH v1 0/8] Duplicate 8259/8254 components in OvmfPkg

[Laszlo Ersek]

On 04/03/19 14:10, Laszlo Ersek wrote:
> On 04/03/19 09:00, Hao Wu wrote:
>> This series is also available at:
>> https://github.com/hwu25/edk2/tree/ovmf_8259_8254_rfcv1
>>
>>
>> As a sub-task to remove the IntelFrameworkPkg (BZ-1604),
>>
>> 8259InterruptControllerDxe driver (PcAtChipsetPkg)
>> Legacy8259 protocol (IntelFrameworkPkg)
>> 8254TimerDxe driver (PcAtChipsetPkg)
>>
>> will be removed in the near future. Meanwhile, OVMF will still require
>> those components (due to CSM support & HPET emulation stability concern).
>>
>> Thus, the series will copy the below 8259/8254 components:
>>
>> A. 8259InterruptControllerDxe driver (PcAtChipsetPkg)
>> B. Two 8259 related PCDs (PcAtChipsetPkg)
>> C. Legacy8259 protocol (IntelFrameworkPkg)
>> D. 8254TimerDxe driver (PcAtChipsetPkg)
>>
>> in the OvmfPkg to address the above-mentioned issue.
>>
>>
>> Tests done for the proposed series:
>>
>> A. OvmfPkg build pass for VS2015 & GCC5 tool chains;
>> B. Boot to Shell with commands:
>>   qemu-system-x86_64.exe -pflash \OVMF.fd -debugcon file:boot.log 
>> -global isa-debugcon.iobase=0x402
>>   qemu-system-x86_64.exe -machine q35 -pflash \OVMF.fd -debugcon 
>> file:boot.log -global isa-debugcon.iobase=0x402
>> C. 'stall X' command under Shell to verify the timer is working properly.
>>
>>
>> (Please note that there will be a subsequent patch to remove the 8259/8254
>> components after platforms dropping the dependencies on them.)
>>
>> Cc: Jordan Justen 
>> Cc: Laszlo Ersek 
>> Cc: Ard Biesheuvel 
>> Cc: David Woodhouse 
>> Cc: Ray Ni 
>>
>>
>> Hao Wu (8):
>>   OvmfPkg: Copy 8259InterruptControllerDxe driver from PcAtChipsetPkg
>>   OvmfPkg: Copy Legacy8259 protocol definitions from IntelFrameworkPkg
>>   OvmfPkg/OvmfPkg.dec: Add 8259-related PCDs in OVMF DEC file
>>   OvmfPkg/8259InterruptControllerDxe: Update to make it build for OVMF
>>   OvmfPkg/AcpiPlatformDxe: Consume the 8259 PCD defined in OvmfPkg
>>   OvmfPkg: Copy 8254TimerDxe driver from PcAtChipsetPkg
>>   OvmfPkg/8254TimerDxe: Update to make it build for OVMF
>>   OvmfPkg: Update DSC/FDF files to consume 8259/8254 drivers in OvmfPkg
> 
> While I'm reviewing the patches individually, let me make some general
> comments:
> 
> - please don't push the series before April 9th (i.e., before the end of
> the file addition/removal freeze due to
> )
> 
> - if/when you push the series, please make sure that *all* files added
> (copied) under OvmfPkg get the new license block format, i.e. the SPDX
> license identifier only.

... in fact, at that time, the license blocks under the *source*
packages (PcAtChipsetPkg and IntelFrameworkPkg) will have been updated,
so you will have to redo the copying steps anyway (and you can verify
those on your end: "git show --find-copies-harder" should show now
modifications as part of the copy operations).

Thanks
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [RFC PATCH v1 0/8] Duplicate 8259/8254 components in OvmfPkg

[Laszlo Ersek]

On 04/03/19 09:00, Hao Wu wrote:
> This series is also available at:
> https://github.com/hwu25/edk2/tree/ovmf_8259_8254_rfcv1
> 
> 
> As a sub-task to remove the IntelFrameworkPkg (BZ-1604),
> 
> 8259InterruptControllerDxe driver (PcAtChipsetPkg)
> Legacy8259 protocol (IntelFrameworkPkg)
> 8254TimerDxe driver (PcAtChipsetPkg)
> 
> will be removed in the near future. Meanwhile, OVMF will still require
> those components (due to CSM support & HPET emulation stability concern).
> 
> Thus, the series will copy the below 8259/8254 components:
> 
> A. 8259InterruptControllerDxe driver (PcAtChipsetPkg)
> B. Two 8259 related PCDs (PcAtChipsetPkg)
> C. Legacy8259 protocol (IntelFrameworkPkg)
> D. 8254TimerDxe driver (PcAtChipsetPkg)
> 
> in the OvmfPkg to address the above-mentioned issue.
> 
> 
> Tests done for the proposed series:
> 
> A. OvmfPkg build pass for VS2015 & GCC5 tool chains;
> B. Boot to Shell with commands:
>   qemu-system-x86_64.exe -pflash \OVMF.fd -debugcon file:boot.log 
> -global isa-debugcon.iobase=0x402
>   qemu-system-x86_64.exe -machine q35 -pflash \OVMF.fd -debugcon 
> file:boot.log -global isa-debugcon.iobase=0x402
> C. 'stall X' command under Shell to verify the timer is working properly.
> 
> 
> (Please note that there will be a subsequent patch to remove the 8259/8254
> components after platforms dropping the dependencies on them.)
> 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Cc: David Woodhouse 
> Cc: Ray Ni 
> 
> 
> Hao Wu (8):
>   OvmfPkg: Copy 8259InterruptControllerDxe driver from PcAtChipsetPkg
>   OvmfPkg: Copy Legacy8259 protocol definitions from IntelFrameworkPkg
>   OvmfPkg/OvmfPkg.dec: Add 8259-related PCDs in OVMF DEC file
>   OvmfPkg/8259InterruptControllerDxe: Update to make it build for OVMF
>   OvmfPkg/AcpiPlatformDxe: Consume the 8259 PCD defined in OvmfPkg
>   OvmfPkg: Copy 8254TimerDxe driver from PcAtChipsetPkg
>   OvmfPkg/8254TimerDxe: Update to make it build for OVMF
>   OvmfPkg: Update DSC/FDF files to consume 8259/8254 drivers in OvmfPkg

While I'm reviewing the patches individually, let me make some general
comments:

- please don't push the series before April 9th (i.e., before the end of
the file addition/removal freeze due to
)

- if/when you push the series, please make sure that *all* files added
(copied) under OvmfPkg get the new license block format, i.e. the SPDX
license identifier only.

Thanks
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [RFC PATCH v1 1/8] OvmfPkg: Copy 8259InterruptControllerDxe driver from PcAtChipsetPkg

[Laszlo Ersek]

On 04/03/19 09:00, Hao Wu wrote:
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1496
> 
> This commit copies the exact 8259InterruptControllerDxe driver from
> PcAtChipsetPkg to OvmfPkg.
> 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Cc: David Woodhouse 
> Cc: Ray Ni 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Hao Wu 
> ---
>  OvmfPkg/8259InterruptControllerDxe/8259.inf|  52 ++
>  OvmfPkg/8259InterruptControllerDxe/8259.h  | 226 +++
>  OvmfPkg/8259InterruptControllerDxe/8259.c  | 628 
> 
>  OvmfPkg/8259InterruptControllerDxe/Legacy8259.uni  |  22 +
>  OvmfPkg/8259InterruptControllerDxe/Legacy8259Extra.uni |  20 +
>  5 files changed, 948 insertions(+)
> 
> diff --git a/OvmfPkg/8259InterruptControllerDxe/8259.inf 
> b/OvmfPkg/8259InterruptControllerDxe/8259.inf
> new file mode 100644
> index 00..1d9be675e3
> --- /dev/null
> +++ b/OvmfPkg/8259InterruptControllerDxe/8259.inf
> @@ -0,0 +1,52 @@
> +## @file
> +# 8259 Interrupt Controller driver that provides Legacy 8259 protocol.
> +#
> +# Copyright (c) 2005 - 2018, Intel Corporation. All rights reserved.
> +# This program and the accompanying materials
> +# are licensed and made available under the terms and conditions of the BSD 
> License
> +# which accompanies this distribution.  The full text of the license may be 
> found at
> +# http://opensource.org/licenses/bsd-license.php
> +#
> +# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> +# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
> IMPLIED.
> +#
> +##
> +
> +[Defines]
> +  INF_VERSION= 0x00010005
> +  BASE_NAME  = Legacy8259
> +  MODULE_UNI_FILE= Legacy8259.uni
> +  FILE_GUID  = 79CA4208-BBA1-4a9a-8456-E1E66A81484E

When creating customized copies, we usually like to generate new
FILE_GUIDs at once -- but in this case, I agree that the GUID should
remain unchanged, as ultimately this code copy will amount to a rename /
move.

I also verified this patch with "git show --find-copies-harder".

Reviewed-by: Laszlo Ersek 

Thanks,
Laszlo


> +  MODULE_TYPE= DXE_DRIVER
> +  VERSION_STRING = 1.0
> +  ENTRY_POINT= Install8259
> +
> +[Sources]
> +  8259.c
> +  8259.h
> +
> +[Packages]
> +  MdePkg/MdePkg.dec
> +  IntelFrameworkPkg/IntelFrameworkPkg.dec
> +  PcAtChipsetPkg/PcAtChipsetPkg.dec
> +
> +[LibraryClasses]
> +  UefiBootServicesTableLib
> +  DebugLib
> +  UefiDriverEntryPoint
> +  IoLib
> +  PcdLib
> +
> +[Protocols]
> +  gEfiLegacy8259ProtocolGuid## PRODUCES
> +  gEfiPciIoProtocolGuid ## SOMETIMES_CONSUMES
> +
> +[Pcd]
> +  gPcAtChipsetPkgTokenSpaceGuid.Pcd8259LegacyModeMask  ## CONSUMES
> +  gPcAtChipsetPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel ## CONSUMES
> +
> +[Depex]
> +  TRUE
> +
> +[UserExtensions.TianoCore."ExtraFiles"]
> +  Legacy8259Extra.uni
> diff --git a/OvmfPkg/8259InterruptControllerDxe/8259.h 
> b/OvmfPkg/8259InterruptControllerDxe/8259.h
> new file mode 100644
> index 00..0d4c1e8223
> --- /dev/null
> +++ b/OvmfPkg/8259InterruptControllerDxe/8259.h
> @@ -0,0 +1,226 @@
> +/** @file
> +  Driver implementing the Tiano Legacy 8259 Protocol
> +
> +Copyright (c) 2005 - 2009, Intel Corporation. All rights reserved.
> +This program and the accompanying materials
> +are licensed and made available under the terms and conditions of the BSD 
> License
> +which accompanies this distribution.  The full text of the license may be 
> found at
> +http://opensource.org/licenses/bsd-license.php.
> +
> +THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> +WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
> +
> +**/
> +
> +#ifndef _8259_H__
> +#define _8259_H__
> +
> +#include 
> +
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +// 8259 Hardware definitions
> +
> +#define LEGACY_MODE_BASE_VECTOR_MASTER0x08
> +#define LEGACY_MODE_BASE_VECTOR_SLAVE 0x70
> +
> +#define PROTECTED_MODE_BASE_VECTOR_MASTER 0x68
> +#define PROTECTED_MODE_BASE_VECTOR_SLAVE  0x70
> +
> +#define LEGACY_8259_CONTROL_REGISTER_MASTER   0x20
> +#define LEGACY_8259_MASK_REGISTER_MASTER  0x21
> +#define LEGACY_8259_CONTROL_REGISTER_SLAVE0xA0
> +#define LEGACY_8259_MASK_REGISTER_SLAVE   0xA1
> +#define LEGACY_8259_EDGE_LEVEL_TRIGGERED_REGISTER_MASTER  0x4D0
> +#define LEGACY_8259_EDGE_LEVEL_TRIGGERED_REGISTER_SLAVE   0x4D1
> +
> +#define LEGACY_8259_EOI   0x20
> +
> +// Protocol Function Prototypes
> +
> +/**
> +  Sets the base address for the 8259 master and slave PICs.
> +
> +  @param[in]  This

Re: [edk2] aarch64-linux-gnu-gcc.exe: error due to loss ‘/’in code path in in Jenkins server

[Gao, Liming]

Are your local server the same environment to Jenkins server? Can you login in 
Jenkins sever and verify gcc tool?

Thanks
Liming
From: wang xiaofeng [mailto:winggundu...@163.com]
Sent: Wednesday, April 3, 2019 3:55 PM
To: Gao, Liming ; edk2-devel@lists.01.org; 
ard.biesheu...@linaro.org; leif.lindh...@linaro.org
Subject: aarch64-linux-gnu-gcc.exe: error due to loss ‘/’in code path in in 
Jenkins server

HI ARM Base tool owners,
   I meet a strange issue that aarch64 build . The aarch64 build pass on my 
local server.  But it fails at Jenkins server(a Win10 autobuild system written 
by Java that will can call edk2 bat in command line)

The build command is 
"c:\jenkins\workspace\gop2018\udk2018\gnutools\gcc-linaro-7.3.1-2018.05-i686-mingw32_aarch64-linux-gnu\bin\aarch64-linux-gnu-gcc"
 -g -fshort-wchar -fno-builtin -fno-strict-aliasing -Wall -Werror 
-Wno-array-bounds -ffunction-sections -fdata-sections -include AutoGen.h 
-fno-common -DSTRING_ARRAY_NAME=UefiDevicePathLibStrings -g -Os -fshort-wchar 
-fno-builtin -fno-strict-aliasing -Wall -Werror -Wno-missing-braces 
-Wno-array-bounds -include AutoGen.h -fno-common -mlittle-endian 
-fno-short-enums -fverbose-asm -funsigned-char -ffunction-sections 
-fdata-sections -Wno-address -fno-asynchronous-unwind-tables -fno-pic -fno-pie 
-ffixed-x18 -flto -Wno-unused-but-set-variable -Wno-unused-const-variable 
-mcmodel=small -DEDKII -DEFIX64 -DUEFI_BUILD -DFGL_LINUX -DGCC_TOOLCHAIN -c -o 
c:\jenkins\workspace\gop2018\udk2018\Build\AmdGopPkg\DEBUG_GCC5\AARCH64\MdePkg\Library\UefiDevicePathLib\UefiDevicePathLib\OUTPUT\.\DevicePathUtilities.obj
 -Ic:\jenkins\workspace\gop2018\udk2018\MdePkg\Library\UefiDevicePathLib 
-Ic:\jenkins\workspace\gop2018\udk2018\Build\AmdGopPkg\DEBUG_GCC5\AARCH64\MdePkg\Library\UefiDevicePathLib\UefiDevicePathLib\DEBUG
 -Ic:\jenkins\workspace\gop2018\udk2018\MdePkg 
-Ic:\jenkins\workspace\gop2018\udk2018\MdePkg\Include 
-Ic:\jenkins\workspace\gop2018\udk2018\MdePkg\Include\AArch64 
c:\jenkins\workspace\gop2018\udk2018\MdePkg\Library\UefiDevicePathLib\DevicePathUtilities.c

But aarch64-linux-gnu-gcc.exe will return error with : 
c:jenkinsworkspacegop2018udk2018MdePkgLibraryUefiDevicePathLibDevicePathUtilities.c:
 No such file or director
The failure is due to all \ is missed from view of aarch64-linux-gnu-gcc.exe, 
while the makefile and build log have '\'
Another clue is that x86 build is ok on the same Jenkins system

Anyone have advice for this strange issue?




___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH V2] Change EDK II to BSD+Patent License

[Laszlo Ersek]

Hi Mike,

On 03/23/19 03:25, Kinney, Michael D wrote:
> Hello,
>
> New in V2
> =
> * Remove Cc lines from commit messages
> * Remove branch reference from commit messages
> * Change license in 2 files missed in OvmfPkg
> * Update OvmfPkg/License.txt to BSD+Patent as the default license
> * Move the portions of Contributions.txt in the root of edk2 to
>   Readme.md in the root of edk2 that describe how to contribute
>   along with the commit message format.
> * Add to Readme.md in the root of edk2 that Signed-off-by means that
>   the contributor certifies compliance to the Developer's Certificate
>   of Origin 1.1.  https://developercertificate.org
> =
>
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1373
>
> This change is based on the following emails:
>   https://lists.01.org/pipermail/edk2-devel/2019-February/036260.html
>   https://lists.01.org/pipermail/edk2-devel/2018-October/030385.html
>
> RFCs with detailed process for the license change:
>   V3: https://lists.01.org/pipermail/edk2-devel/2019-March/038116.html
>   V2: https://lists.01.org/pipermail/edk2-devel/2019-March/037669.html
>   V1: https://lists.01.org/pipermail/edk2-devel/2019-March/037500.html
>
> I have posted the patch series for review on the following branch
> using edk2-stable201903 as the base for the patch series.
>
>   https://github.com/mdkinney/edk2/tree/Bug_1373_BsdPatentLicense_V2
>
> The commits in patch series can be viewed here:
>
>   https://github.com/mdkinney/edk2/commits/Bug_1373_BsdPatentLicense_V2
>
> The patch series has one patch per package along with a few patches
> to update the license information in the root of the edk2 repository
> as described in the RFC V3.
>
> Due to the size of the patch series, I prefer to not send the
> patch emails.  Instead, please perform code reviews using content
> from the branch.
>
> All EDK II package maintainers and package reviewers should provide
> review feedback for their packages.  The critical part of the review
> is:
> 1) Any changes that cause build breaks or logic changes.  These code
>changes are intended to only modify license contents in comment
>blocks.
> 2) Any file that has been changed to BSD+Patent, but should remain
>with the current license.
> 3) Any file that that has not changed to BSD+Patent, but should be
>changed to BSD+Patent.
>
> Feedback and Reviewed-by emails should identify the patch the feedback
> applies using the patch summary listed below.  The goal is to complete
> all reviews to support the commit of these patches on April 9, 2019.

Given that we've now entered the file addition/removal freeze:

  
E92EE9817A31E24EB0585FDF735412F5B9C772EE@ORSMSX112.amr.corp.intel.com">http://mid.mail-archive.com/E92EE9817A31E24EB0585FDF735412F5B9C772EE@ORSMSX112.amr.corp.intel.com

and that in that email you identify this (v2) series as "current", I'm
now reviewing v2.

Your v2 series was based on upstream commit 89910a39dcfd. The master
branch has since advanced to 7ed72121b753 however. Therefore, for this
review, I've rebased the three v2 patches listed below on top of commit
7ed72121b753 (i.e. on top the current master HEAD).


> f23540ea65 ArmVirtPkg: Replace BSD License with BSD+Patent License

I reviewed this patch most recently as part of your v1 series:

  f2a32071-868a-e4fa-dcca-41bf28ba93aa@redhat.com">http://mid.mail-archive.com/f2a32071-868a-e4fa-dcca-41bf28ba93aa@redhat.com

Content-wise, I'm in luck with the v2 review of this patch, because the
ArmVirtPkg directory tree is identical
- between your v1 patch set
- and your v2 patch set, rebased on top of current master.

Comparing the commit messages, I find:

- the RFC link list has been extended with the v3 RFC,
- the reference to your branch on github has been removed,
- the Cc: list in the commit message has been deleted.

Hence all my remarks have been observed. For this patch:

Reviewed-by: Laszlo Ersek 


> e39d07266d OvmfPkg: Replace BSD License with BSD+Patent License

(While rebasing this patch from your v2 to current master, I ran into a
conflict, but that was easy to resolve and it's going to be covered
below anyway.)

Relative to v1:

(1) RFC link list updated, OK

(2) "Branch for review" removed, OK (v1/1.2)

(3) Cc: list removed, OK (v1/1.1)

(4) The "create-release.py" hunk doesn't apply any longer, so please
remove it in v3. This conflict is due to us removing
"create-release.py" altogether, for
. (v1/2.1.1)

(5) At commit 7ed72121b753 (= current master HEAD), OvmfPkg contains the
following new files:

  OvmfPkg/SioBusDxe/ComponentName.c
  OvmfPkg/SioBusDxe/SioBusDxe.c
  OvmfPkg/SioBusDxe/SioBusDxe.h
  OvmfPkg/SioBusDxe/SioBusDxe.inf
  OvmfPkg/SioBusDxe/SioBusDxe.uni
  OvmfPkg/SioBusDxe/SioService.c
  OvmfPkg/SioBusDxe/SioService.h

All of them reference the URL
, so please convert
them 

Re: [edk2] [PATCH 1/2] MdePkg/BaseIoLibIntrinsic: Remove IoLibIcc.c

[Gao, Liming]

Can you also clean up BaseLib to remove the support of INTEL tool chain?

> -Original Message-
> From: Zhang, Shenglei
> Sent: Wednesday, April 3, 2019 4:30 PM
> To: edk2-devel@lists.01.org
> Cc: Kinney, Michael D ; Gao, Liming 
> 
> Subject: [PATCH 1/2] MdePkg/BaseIoLibIntrinsic: Remove IoLibIcc.c
> 
> As ICC tool chain will be removed, IoLibIcc.c should
> also be removed.
> https://bugzilla.tianocore.org/show_bug.cgi?id=1666
> 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Shenglei Zhang 
> ---
>  .../BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf |   2 -
>  .../BaseIoLibIntrinsicSev.inf |   2 -
>  MdePkg/Library/BaseIoLibIntrinsic/IoLibIcc.c  | 214 --
>  3 files changed, 218 deletions(-)
>  delete mode 100644 MdePkg/Library/BaseIoLibIntrinsic/IoLibIcc.c
> 
> diff --git a/MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf 
> b/MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf
> index eb81aab2d4..6020fe90da 100644
> --- a/MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf
> +++ b/MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf
> @@ -41,14 +41,12 @@
>  [Sources.IA32]
>IoLibGcc.c| GCC
>IoLibMsc.c| MSFT
> -  IoLibIcc.c| INTEL
>IoLib.c
>Ia32/IoFifo.nasm
> 
>  [Sources.X64]
>IoLibGcc.c| GCC
>IoLibMsc.c| MSFT
> -  IoLibIcc.c| INTEL
>IoLib.c
>X64/IoFifo.nasm
> 
> diff --git a/MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf 
> b/MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf
> index da846704d5..e92b5ed94d 100644
> --- a/MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf
> +++ b/MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf
> @@ -39,14 +39,12 @@
>  [Sources.IA32]
>IoLibGcc.c| GCC
>IoLibMsc.c| MSFT
> -  IoLibIcc.c| INTEL
>IoLib.c
>Ia32/IoFifoSev.nasm
> 
>  [Sources.X64]
>IoLibGcc.c| GCC
>IoLibMsc.c| MSFT
> -  IoLibIcc.c| INTEL
>IoLib.c
>X64/IoFifoSev.nasm
> 
> diff --git a/MdePkg/Library/BaseIoLibIntrinsic/IoLibIcc.c 
> b/MdePkg/Library/BaseIoLibIntrinsic/IoLibIcc.c
> deleted file mode 100644
> index 3036084f0c..00
> --- a/MdePkg/Library/BaseIoLibIntrinsic/IoLibIcc.c
> +++ /dev/null
> @@ -1,214 +0,0 @@
> -/** @file
> -  I/O Library. This file has compiler specifics for ICC as there
> -  is no ANSI C standard for doing IO.
> -
> -  Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
> -  This program and the accompanying materials are
> -  licensed and made available under the terms and conditions of the BSD 
> License
> -  which accompanies this distribution.  The full text of the license may be 
> found at
> -  http://opensource.org/licenses/bsd-license.php.
> -
> -  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> -  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
> IMPLIED.
> -
> -**/
> -
> -#include "BaseIoLibIntrinsicInternal.h"
> -
> -/**
> -  Reads an 8-bit I/O port.
> -
> -  Reads the 8-bit I/O port specified by Port. The 8-bit read value is 
> returned.
> -  This function must guarantee that all I/O read and write operations are
> -  serialized.
> -
> -  If 8-bit I/O port operations are not supported, then ASSERT().
> -
> -  @param  Port  The I/O port to read.
> -
> -  @return The value read.
> -
> -**/
> -UINT8
> -EFIAPI
> -IoRead8 (
> -  IN  UINTN Port
> -  )
> -{
> -  UINT8   Data;
> -
> -  __asm {
> -mov dx, word ptr [Port]
> -in  al, dx
> -
> -mov Data, al
> -  }
> -  return Data;
> -}
> -
> -/**
> -  Writes an 8-bit I/O port.
> -
> -  Writes the 8-bit I/O port specified by Port with the value specified by 
> Value
> -  and returns Value. This function must guarantee that all I/O read and write
> -  operations are serialized.
> -
> -  If 8-bit I/O port operations are not supported, then ASSERT().
> -
> -  @param  Port  The I/O port to write.
> -  @param  Value The value to write to the I/O port.
> -
> -  @return The value written the I/O port.
> -
> -**/
> -UINT8
> -EFIAPI
> -IoWrite8 (
> -  IN  UINTN Port,
> -  IN  UINT8 Value
> -  )
> -{
> -  __asm {
> -mov al, byte ptr [Value]
> -mov dx, word ptr [Port]
> -out dx, al
> -  }
> -  return Value;
> -}
> -
> -/**
> -  Reads a 16-bit I/O port.
> -
> -  Reads the 16-bit I/O port specified by Port. The 16-bit read value is 
> returned.
> -  This function must guarantee that all I/O read and write operations are
> -  serialized.
> -
> -  If 16-bit I/O port operations are not supported, then ASSERT().
> -  If Port is not aligned on a 16-bit boundary, then ASSERT().
> -
> -  @param  Port  The I/O port to read.
> -
> -  @return The value read.
> -
> -**/
> -UINT16
> -EFIAPI
> -IoRead16 (
> -  IN  UINTN Port
> -  )
> -{
> -  UINT16  Data;
> -
> -  ASSERT ((Port & 1) == 0);
> -
> -  __asm 

Re: [edk2] aarch64-linux-gnu-gcc.exe: error due to loss ‘/’in code path in in Jenkins server

[Leif Lindholm]

On Wed, Apr 03, 2019 at 04:07:58PM +0800, wang xiaofeng wrote:
> Hi Leif,
>We use VC for X86 (do not need GCC cross complie)

Ah, that was not clear from the original mail.

Are both server and local system using cygwin/mingw32?

Best Regards,

Leif

>gcc revision : 
> Using built-in specs.
> COLLECT_GCC=aarch64-linux-gnu-gcc.exe
> COLLECT_LTO_WRAPPER=c:/code/gnutools/gcc-linaro-7.3.1-2018.05-i686-mingw32_aarch64-linux-gnu/bin/../libexec/gcc/aarch64-linux-gnu/7.3.1/lto-wrapper.exe
> Target: aarch64-linux-gnu
> Configured with: 
> '/home/tcwg-buildslave/workspace/tcwg-make-release/builder_arch/amd64/label/tcwg-x86_64-build/target/aarch64-linux-gnu/snapshots/gcc.git~linaro-7.3-2018.05/configure'
>  SHELL=/bin/bash 
> --with-mpc=/home/tcwg-buildslave/workspace/tcwg-make-release/builder_arch/amd64/label/tcwg-x86_64-build/target/aarch64-linux-gnu/_build/builds/destdir/i686-w64-mingw32
>  
> --with-mpfr=/home/tcwg-buildslave/workspace/tcwg-make-release/builder_arch/amd64/label/tcwg-x86_64-build/target/aarch64-linux-gnu/_build/builds/destdir/i686-w64-mingw32
>  
> --with-gmp=/home/tcwg-buildslave/workspace/tcwg-make-release/builder_arch/amd64/label/tcwg-x86_64-build/target/aarch64-linux-gnu/_build/builds/destdir/i686-w64-mingw32
>  --with-gnu-as --with-gnu-ld --disable-libmudflap --enable-lto 
> --enable-shared --without-included-gettext --enable-nls --with-system-zlib 
> --disable-sjlj-exceptions --enable-gnu-unique-object --enable-linker-build-id 
> --disable-libstdcxx-pch --enable-c99 --enable-clocale=gnu --enable-libstdcxx
 -debug --enable-long-long --with-cloog=no --with-ppl=no --with-isl=no 
--disable-multilib --enable-fix-cortex-a53-835769 
--enable-fix-cortex-a53-843419 --with-arch=armv8-a --enable-threads=posix 
--enable-multiarch --enable-libstdcxx-time=yes --enable-gnu-indirect-function 
--with-build-sysroot=/home/tcwg-buildslave/workspace/tcwg-make-release/builder_arch/amd64/label/tcwg-x86_64-build/target/aarch64-linux-gnu/_build/sysroots/aarch64-linux-gnu
 
--with-sysroot=/home/tcwg-buildslave/workspace/tcwg-make-release/builder_arch/amd64/label/tcwg-x86_64-build/target/aarch64-linux-gnu/_build/builds/destdir/i686-w64-mingw32/aarch64-linux-gnu/libc
 --enable-checking=release --disable-bootstrap 
--enable-languages=c,c++,fortran,lto 
--with-libiconv-prefix=/home/tcwg-buildslave/workspace/tcwg-make-release/builder_arch/amd64/label/tcwg-x86_64-build/target/aarch64-linux-gnu/_build/builds/destdir/i686-w64-mingw32/usr
 --with-system-zlib=no --build=x86_64-unknown-linux-gnu --host=i686-w64-mingw32 
--target=aa
 rch64-linux-gnu 
--prefix=/home/tcwg-buildslave/workspace/tcwg-make-release/builder_arch/amd64/label/tcwg-x86_64-build/target/aarch64-linux-gnu/_build/builds/destdir/i686-w64-mingw32
> Thread model: posix
> gcc version 7.3.1 20180425 [linaro-7.3-2018.05 revision 
> d29120a424ecfbc167ef90065c0eeb7f91977701] (Linaro GCC 7.3-2018.05)
> 
> 
> 
> 
>GNUmake revision : GNUMake-3.81_win32
> 
> 
>  Can the tool provide more debug output ?
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> At 2019-04-03 16:00:04, "Leif Lindholm"  wrote:
> >Sami, any ideas?
> >
> >Xiaofeng, what gcc is being used for x86? (output of "gcc -v")
> >
> >Best Regards,
> >
> >Leif
> >
> >On Wed, Apr 03, 2019 at 03:54:33PM +0800, wang xiaofeng wrote:
> >> HI ARM Base tool owners,
> >>I meet a strange issue that aarch64 build . The aarch64 build pass on 
> >> my local server.  But it fails at Jenkins server(a Win10 autobuild system 
> >> written by Java that will can call edk2 bat in command line)
> >> 
> >> 
> >> The build command is 
> >> "c:\jenkins\workspace\gop2018\udk2018\gnutools\gcc-linaro-7.3.1-2018.05-i686-mingw32_aarch64-linux-gnu\bin\aarch64-linux-gnu-gcc"
> >>  -g -fshort-wchar -fno-builtin -fno-strict-aliasing -Wall -Werror 
> >> -Wno-array-bounds -ffunction-sections -fdata-sections -include AutoGen.h 
> >> -fno-common -DSTRING_ARRAY_NAME=UefiDevicePathLibStrings -g -Os 
> >> -fshort-wchar -fno-builtin -fno-strict-aliasing -Wall -Werror 
> >> -Wno-missing-braces -Wno-array-bounds -include AutoGen.h -fno-common 
> >> -mlittle-endian -fno-short-enums -fverbose-asm -funsigned-char 
> >> -ffunction-sections -fdata-sections -Wno-address 
> >> -fno-asynchronous-unwind-tables -fno-pic -fno-pie -ffixed-x18 -flto 
> >> -Wno-unused-but-set-variable -Wno-unused-const-variable -mcmodel=small 
> >> -DEDKII -DEFIX64 -DUEFI_BUILD -DFGL_LINUX -DGCC_TOOLCHAIN -c -o 
> >> c:\jenkins\workspace\gop2018\udk2018\Build\AmdGopPkg\DEBUG_GCC5\AARCH64\MdePkg\Library\UefiDevicePathLib\UefiDevicePathLib\OUTPUT\.\DevicePathUtilities.obj
> >>  -Ic:\jenkins\workspace\gop2018\udk2018
 \MdePkg\Library\UefiDevicePathLib 
-Ic:\jenkins\workspace\gop2018\udk2018\Build\AmdGopPkg\DEBUG_GCC5\AARCH64\MdePkg\Library\UefiDevicePathLib\UefiDevicePathLib\DEBUG
 -Ic:\jenkins\workspace\gop2018\udk2018\MdePkg 
-Ic:\jenkins\workspace\gop2018\udk2018\MdePkg\Include 
-Ic:\jenkins\workspace\gop2018\udk2018\MdePkg\Include\AArch64 

Re: [edk2] [RFC] Plan to delete ShellBinPkg from edk2/master

[Laszlo Ersek]

On 04/03/19 04:17, Ni, Ray wrote:
> 
> 
>> -Original Message-
>> From: edk2-devel  On Behalf Of Laszlo
>> Ersek
>> Sent: Tuesday, April 2, 2019 4:49 PM
>> To: Bi, Dandan ; edk2-devel@lists.01.org
>> Cc: Cetola, Stephano ; Kinney, Michael D
>> ; Gao, Liming ; Carsey,
>> Jaben 
>> Subject: Re: [edk2] [RFC] Plan to delete ShellBinPkg from edk2/master
>>
>> On 04/02/19 07:38, Bi, Dandan wrote:
>>> Hi All,
>>>
>>> ShellBinPkg is the remaining binary package in Edk2 repo.  We plan to
>> delete ShellBinPkg from edk2/master, and keep source ShellPkg only in edk2
>> repo.
>>> Before the deletion, I will update the existing consumers in Edk2 and
>> Edk2Platforms to use ShellPkg directly.
>>>
>>> If you have any concern please raise here before mid-April . If there is no
>> concern, I will create patches for this task after mid-April.
>>>
>>> Bugzilla for this task:
>>> https://bugzilla.tianocore.org/show_bug.cgi?id=1675
>>
>> (adding a few CC's)
>>
>> I think we should not remove ShellBinPkg without a replacement
>> *somehwere*.
>>
>> A shell binary that is built from a validated edk2 tree, with a set of 
>> library
>> resolutions and PCD settings that are known to keep platform dependencies
>> *out* of the shell binary, is extremely useful.
> 
> I understand the concern.
> Maybe a "Shell.dsc.inc" provided by ShellPkg which lists all library 
> resolutions
> , PCD settings and build options can be included by platform DSC to resolve 
> such
> dependency issue.
> 
>>
>> IIRC, Andrew suggested earlier that we should treat the shell even as an 
>> "OS",
>> with better compatibility standards than we currently maintain.
>>
>> I think we should only remove ShellBinPkg if we permanently offer a
>> separate download location instead, and we rebuild the shell binary from
>> "ShellPkg/ShellPkg.dsc" at every stable tag.
> 
> I do not quite understand. All other modules in edk2 repo are source-included 
> by
> OvmfPkg and daily commits directly generates new binaries for OvmfPkg.
> I do not think we should have a different "binary-generation" model for
> shell.

The standalone shell binary would not be offered for OVMF, but for all
possible UEFI platforms (physical and virtual alike).

People frequently turn to the UEFI shell for debugging UEFI issues on
their physical machines. Such users are generally not interested in
building the shell from source, just booting it as easily as possible.

Thanks,
Laszlo


>> In that case, removing ShellBinPkg would indeed improve the edk2 tree, in
>> my opinion.
>>
>> Thanks,
>> Laszlo
>> ___
>> edk2-devel mailing list
>> edk2-devel@lists.01.org
>> https://lists.01.org/mailman/listinfo/edk2-devel

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH 0/2] Remove ICC tool chain

[Shenglei Zhang]

There is no Intel complier test. So suggest to remove ICC
tool chain from tools_def.template. And also IoLibIcc.c
in MdePkg should update to be removed.
https://bugzilla.tianocore.org/show_bug.cgi?id=1666

Cc: Michael D Kinney 
Cc: Bob Feng 
Cc: Liming Gao 
Cc: Yonghong Zhu 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Shenglei Zhang 
Shenglei Zhang (2):
  MdePkg/BaseIoLibIntrinsic: Remove IoLibIcc.c
  BaseTools: Remove ICC tool chain in tools_def.template

 BaseTools/Conf/tools_def.template | 1092 -
 .../BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf |2 -
 .../BaseIoLibIntrinsicSev.inf |2 -
 MdePkg/Library/BaseIoLibIntrinsic/IoLibIcc.c  |  214 
 4 files changed, 1310 deletions(-)
 delete mode 100644 MdePkg/Library/BaseIoLibIntrinsic/IoLibIcc.c

-- 
2.18.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH 1/2] MdePkg/BaseIoLibIntrinsic: Remove IoLibIcc.c

[Shenglei Zhang]

As ICC tool chain will be removed, IoLibIcc.c should
also be removed.
https://bugzilla.tianocore.org/show_bug.cgi?id=1666

Cc: Michael D Kinney 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Shenglei Zhang 
---
 .../BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf |   2 -
 .../BaseIoLibIntrinsicSev.inf |   2 -
 MdePkg/Library/BaseIoLibIntrinsic/IoLibIcc.c  | 214 --
 3 files changed, 218 deletions(-)
 delete mode 100644 MdePkg/Library/BaseIoLibIntrinsic/IoLibIcc.c

diff --git a/MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf 
b/MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf
index eb81aab2d4..6020fe90da 100644
--- a/MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf
+++ b/MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf
@@ -41,14 +41,12 @@
 [Sources.IA32]
   IoLibGcc.c| GCC
   IoLibMsc.c| MSFT
-  IoLibIcc.c| INTEL
   IoLib.c
   Ia32/IoFifo.nasm
 
 [Sources.X64]
   IoLibGcc.c| GCC
   IoLibMsc.c| MSFT
-  IoLibIcc.c| INTEL
   IoLib.c
   X64/IoFifo.nasm
 
diff --git a/MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf 
b/MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf
index da846704d5..e92b5ed94d 100644
--- a/MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf
+++ b/MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf
@@ -39,14 +39,12 @@
 [Sources.IA32]
   IoLibGcc.c| GCC
   IoLibMsc.c| MSFT
-  IoLibIcc.c| INTEL
   IoLib.c
   Ia32/IoFifoSev.nasm
 
 [Sources.X64]
   IoLibGcc.c| GCC
   IoLibMsc.c| MSFT
-  IoLibIcc.c| INTEL
   IoLib.c
   X64/IoFifoSev.nasm
 
diff --git a/MdePkg/Library/BaseIoLibIntrinsic/IoLibIcc.c 
b/MdePkg/Library/BaseIoLibIntrinsic/IoLibIcc.c
deleted file mode 100644
index 3036084f0c..00
--- a/MdePkg/Library/BaseIoLibIntrinsic/IoLibIcc.c
+++ /dev/null
@@ -1,214 +0,0 @@
-/** @file
-  I/O Library. This file has compiler specifics for ICC as there
-  is no ANSI C standard for doing IO.
-
-  Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
-  This program and the accompanying materials are
-  licensed and made available under the terms and conditions of the BSD License
-  which accompanies this distribution.  The full text of the license may be 
found at
-  http://opensource.org/licenses/bsd-license.php.
-
-  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
-  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
-
-**/
-
-#include "BaseIoLibIntrinsicInternal.h"
-
-/**
-  Reads an 8-bit I/O port.
-
-  Reads the 8-bit I/O port specified by Port. The 8-bit read value is returned.
-  This function must guarantee that all I/O read and write operations are
-  serialized.
-
-  If 8-bit I/O port operations are not supported, then ASSERT().
-
-  @param  Port  The I/O port to read.
-
-  @return The value read.
-
-**/
-UINT8
-EFIAPI
-IoRead8 (
-  IN  UINTN Port
-  )
-{
-  UINT8   Data;
-
-  __asm {
-mov dx, word ptr [Port]
-in  al, dx
-
-mov Data, al
-  }
-  return Data;
-}
-
-/**
-  Writes an 8-bit I/O port.
-
-  Writes the 8-bit I/O port specified by Port with the value specified by Value
-  and returns Value. This function must guarantee that all I/O read and write
-  operations are serialized.
-
-  If 8-bit I/O port operations are not supported, then ASSERT().
-
-  @param  Port  The I/O port to write.
-  @param  Value The value to write to the I/O port.
-
-  @return The value written the I/O port.
-
-**/
-UINT8
-EFIAPI
-IoWrite8 (
-  IN  UINTN Port,
-  IN  UINT8 Value
-  )
-{
-  __asm {
-mov al, byte ptr [Value]
-mov dx, word ptr [Port]
-out dx, al
-  }
-  return Value;
-}
-
-/**
-  Reads a 16-bit I/O port.
-
-  Reads the 16-bit I/O port specified by Port. The 16-bit read value is 
returned.
-  This function must guarantee that all I/O read and write operations are
-  serialized.
-
-  If 16-bit I/O port operations are not supported, then ASSERT().
-  If Port is not aligned on a 16-bit boundary, then ASSERT().
-
-  @param  Port  The I/O port to read.
-
-  @return The value read.
-
-**/
-UINT16
-EFIAPI
-IoRead16 (
-  IN  UINTN Port
-  )
-{
-  UINT16  Data;
-
-  ASSERT ((Port & 1) == 0);
-
-  __asm {
-mov dx, word ptr [Port]
-in  ax, dx
-mov word ptr [Data], ax
-  }
-
-  return Data;
-}
-
-/**
-  Writes a 16-bit I/O port.
-
-  Writes the 16-bit I/O port specified by Port with the value specified by 
Value
-  and returns Value. This function must guarantee that all I/O read and write
-  operations are serialized.
-
-  If 16-bit I/O port operations are not supported, then ASSERT().
-  If Port is not aligned on a 16-bit boundary, then ASSERT().
-
-  @param  Port  The I/O port to write.
-  @param  Value The value to write to the I/O port.
-
-  @return The value written the I/O port.
-
-**/
-UINT16
-EFIAPI
-IoWrite16 (
-  IN  

[edk2] [PATCH 2/2] BaseTools: Remove ICC tool chain in tools_def.template

[Shenglei Zhang]

There is no Intel compiler test. Suggest to remove ICC tool chain from
tools_def.template.
https://bugzilla.tianocore.org/show_bug.cgi?id=1666

Cc: Bob Feng 
Cc: Liming Gao 
Cc: Yonghong Zhu 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Shenglei Zhang 
---
 BaseTools/Conf/tools_def.template | 1092 -
 1 file changed, 1092 deletions(-)

diff --git a/BaseTools/Conf/tools_def.template 
b/BaseTools/Conf/tools_def.template
index abda2164a6..d826205cc1 100755
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -103,43 +103,6 @@ DEFINE MS_VS_DLL   = DEF(VS2008_DLL)
 DEFINE WINDDK_BIN16 = ENV(WINDDK3790_PREFIX)bin16
 DEFINE WINDDK_BINX64= ENV(WINDDK3790_PREFIX)win64\x86\amd64
 
-# NOTE: The Intel C++ Compiler for Windows requires one of the Microsoft C 
compiler
-#tool chains for the linker and nmake commands.
-#This configuration assumes a Windows 2003 Server DDK installation.
-DEFINE ICC_VERSION  = 9.1
-#DEFINE ICC_VERSION = 10.1.021
-DEFINE ICC_BIN32= C:\Program 
Files\Intel\Compiler\C++\DEF(ICC_VERSION)\IA32\Bin
-DEFINE ICC_ASM32= C:\Program 
Files\Intel\Compiler\C++\DEF(ICC_VERSION)\IA32\Bin
-DEFINE ICC_BIN32x86 = C:\Program Files 
(x86)\Intel\Compiler\C++\DEF(ICC_VERSION)\IA32\Bin
-DEFINE ICC_ASM32x86 = C:\Program Files 
(x86)\Intel\Compiler\C++\DEF(ICC_VERSION)\IA32\Bin
-
-DEFINE ICC_BINX64   = C:\Program 
Files\Intel\Compiler\C++\DEF(ICC_VERSION)\EM64T\Bin
-DEFINE ICC_ASMX64   = C:\Program 
Files\Intel\Compiler\C++\DEF(ICC_VERSION)\EM64T\Bin
-DEFINE ICC_BINX64x86= C:\Program Files 
(x86)\Intel\Compiler\C++\DEF(ICC_VERSION)\EM64T\Bin
-DEFINE ICC_ASMX64x86= C:\Program Files 
(x86)\Intel\Compiler\C++\DEF(ICC_VERSION)\EM64T\Bin
-
-DEFINE ICC_BIN64= C:\Program 
Files\Intel\Compiler\C++\DEF(ICC_VERSION)\Itanium\Bin
-DEFINE ICC_BIN64x86 = C:\Program Files 
(x86)\Intel\Compiler\C++\DEF(ICC_VERSION)\Itanium\Bin
-
-
-# Note: The Intel C++ Compiler 11.1 uses different installation path from 
previous versions
-#   We use "ICC11" tag for ICC 11.1 while "ICC" tag is dedicated for 
earlier versions
-#
-DEFINE ICC11_VERSION  = 11.1
-DEFINE ICC11_BUILD= 072
-DEFINE ICC11_BIN32= C:\Program 
Files\Intel\Compiler\DEF(ICC11_VERSION)\DEF(ICC11_BUILD)\bin\ia32
-DEFINE ICC11_ASM32= C:\Program 
Files\Intel\Compiler\DEF(ICC11_VERSION)\DEF(ICC11_BUILD)\bin\ia32
-DEFINE ICC11_BIN32x86 = C:\Program Files 
(x86)\Intel\Compiler\DEF(ICC11_VERSION)\DEF(ICC11_BUILD)\bin\ia32
-DEFINE ICC11_ASM32x86 = C:\Program Files 
(x86)\Intel\Compiler\DEF(ICC11_VERSION)\DEF(ICC11_BUILD)\bin\ia32
-
-DEFINE ICC11_BINX64   = C:\Program 
Files\Intel\Compiler\DEF(ICC11_VERSION)\DEF(ICC11_BUILD)\bin\ia32_intel64
-DEFINE ICC11_ASMX64   = C:\Program 
Files\Intel\Compiler\DEF(ICC11_VERSION)\DEF(ICC11_BUILD)\bin\ia32_intel64
-DEFINE ICC11_BINX64x86= C:\Program Files 
(x86)\Intel\Compiler\DEF(ICC11_VERSION)\DEF(ICC11_BUILD)\bin\intel64
-DEFINE ICC11_ASMX64x86= C:\Program Files 
(x86)\Intel\Compiler\DEF(ICC11_VERSION)\DEF(ICC11_BUILD)\bin\intel64
-
-DEFINE ICC11_BIN64= C:\Program 
Files\Intel\Compiler\DEF(ICC11_VERSION)\DEF(ICC11_BUILD)\bin\ia32_ia64
-DEFINE ICC11_BIN64x86 = C:\Program Files 
(x86)\Intel\Compiler\DEF(ICC11_VERSION)\DEF(ICC11_BUILD)\bin\ia32_ia64
-
 DEFINE EBC_BIN  = C:\Program Files\Intel\EBC\Bin
 DEFINE EBC_BINx86   = C:\Program Files (x86)\Intel\EBC\Bin
 
@@ -178,10 +141,6 @@ DEFINE MSFT_ASLPP_FLAGS= /nologo /E /C /FIAutoGen.h
 DEFINE MSFT_ASLCC_FLAGS= /nologo /c /FIAutoGen.h /TC 
/Dmain=ReferenceAcpiTable
 DEFINE MSFT_ASLDLINK_FLAGS = /NODEFAULTLIB /ENTRY:ReferenceAcpiTable 
/SUBSYSTEM:CONSOLE
 
-DEFINE ICC_WIN_ASLPP_FLAGS = /nologo /E /C /FIAutoGen.h
-DEFINE ICC_WIN_ASLCC_FLAGS = /nologo /c /FIAutoGen.h /TC 
/Dmain=ReferenceAcpiTable
-DEFINE ICC_WIN_ASLDLINK_FLAGS  = /NODEFAULTLIB /ENTRY:ReferenceAcpiTable 
/SUBSYSTEM:CONSOLE /NODEFAULTLIB:libmmt /NODEFAULTLIB:libirc
-
 DEFINE IPHONE_TOOLS= 
/Developer/Platforms/iPhoneOS.platform/Developer
 
 DEFINE SOURCERY_CYGWIN_TOOLS = /cygdrive/c/Program Files/CodeSourcery/Sourcery 
G++ Lite/bin
@@ -302,30 +261,6 @@ DEFINE DTC_BIN = ENV(DTC_PREFIX)dtc
 # Required to build platforms or ACPI tables:
 #   Intel(r) ACPI Compiler from
 #   https://acpica.org/downloads
-#   ICC -win32-  Requires:
-# Intel C Compiler V9.1
-#Dependencies:
-# Microsoft Visual Studio 2003 or 2005
-# Microsoft Windows Server 2003 Driver Development 
Kit (Microsoft WINDDK)
-# version 3790.1830 for X64 target architectures
-#Optional:
-# Required to build EBC 

[edk2] [RFC] Remove Nt32Pkg

[Ni, Ray]

All,
Now since EmulatorPkg supports to run in Windows environment, I propose to 
remove Nt32Pkg.
Do you have any concern on the Nt32Pkg removal?

Thanks,
Ray
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] UefiCpuPkg/Cpuid: Dump leaf 1FH information correctly

[Ni, Ray]

> -Original Message-
> From: Dong, Eric 
> Sent: Wednesday, April 3, 2019 2:40 PM
> To: Ni, Ray ; edk2-devel@lists.01.org
> Subject: RE: [PATCH] UefiCpuPkg/Cpuid: Dump leaf 1FH information correctly
> 
> Hi Ray,
> 
> > -Original Message-
> > From: Ni, Ray
> > Sent: Friday, March 29, 2019 4:42 PM
> > To: edk2-devel@lists.01.org
> > Cc: Dong, Eric 
> > Subject: [PATCH] UefiCpuPkg/Cpuid: Dump leaf 1FH information correctly
> >
> > Leaf 1FH is very similar to leaf 0BH. Both return the CPU topology
> information.
> > Leaf 0BH returns 3-level (Package/Core/Thread) CPU topology info.
> > Leaf 1FH returns 6-level (Package/Die/Tile/Module/Core/Thread) CPU
> > topology info.
> > The logic to enumerate the topology info is the same.
> >
> > But today's logic to handle 1FH is completely wrong.
> > The patch combines them together to fix the 1FH issue.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Ray Ni 
> > Cc: Eric Dong 
> > ---
> >  UefiCpuPkg/Application/Cpuid/Cpuid.c | 83
> > ++--
> >  1 file changed, 28 insertions(+), 55 deletions(-)
> >
> > diff --git a/UefiCpuPkg/Application/Cpuid/Cpuid.c
> > b/UefiCpuPkg/Application/Cpuid/Cpuid.c
> > index 67cacf2714..3d242a0cbf 100644
> > --- a/UefiCpuPkg/Application/Cpuid/Cpuid.c
> > +++ b/UefiCpuPkg/Application/Cpuid/Cpuid.c
> > @@ -1,7 +1,7 @@
> >  /** @file
> >UEFI Application to display CPUID leaf information.
> >
> > -  Copyright (c) 2016 - 2018, Intel Corporation. All rights
> > reserved.
> > +  Copyright (c) 2016 - 2019, Intel Corporation. All rights
> > + reserved.
> >This program and the accompanying materials
> >are licensed and made available under the terms and conditions of
> > the BSD License
> >which accompanies this distribution.  The full text of the license
> > may be found at @@ -717,36 +717,42 @@
> > CpuidArchitecturalPerformanceMonitoring (  **/  VOID
> > CpuidExtendedTopology (
> > -  VOID
> > +  UINT32   LeafFunction
> >)
> >  {
> > -  CPUID_EXTENDED_TOPOLOGY_EAX  Eax;
> > -  CPUID_EXTENDED_TOPOLOGY_EBX  Ebx;
> > -  CPUID_EXTENDED_TOPOLOGY_ECX  Ecx;
> > -  UINT32   Edx;
> > -  UINT32   LevelNumber;
> > +  CPUID_V2_EXTENDED_TOPOLOGY_ENUMERATION_EAX  Eax;
> > + CPUID_V2_EXTENDED_TOPOLOGY_ENUMERATION_EBX  Ebx;
> > + CPUID_V2_EXTENDED_TOPOLOGY_ENUMERATION_ECX  Ecx;
> > +  UINT32  Edx;
> > +  UINT32  LevelNumber;
> >
> > -  if (CPUID_EXTENDED_TOPOLOGY > gMaximumBasicFunction) {
> > +  if (LeafFunction > gMaximumBasicFunction) {
> > +return;
> > +  }
> > +  if ((LeafFunction != CPUID_EXTENDED_TOPOLOGY) && (LeafFunction !=
> > + CPUID_V2_EXTENDED_TOPOLOGY_ENUMERATION)) {
> >  return;
> >}
> >
> >LevelNumber = 0;
> > -  do {
> > +  for (LevelNumber = 0; ; LevelNumber++) {
> >  AsmCpuidEx (
> > -  CPUID_EXTENDED_TOPOLOGY, LevelNumber,
> > +  LeafFunction, LevelNumber,
> >, , , 
> >);
> > -if (Eax.Bits.ApicIdShift != 0) {
> > -  Print (L"CPUID_EXTENDED_TOPOLOGY (Leaf %08x, Sub-Leaf %08x)\n",
> > CPUID_EXTENDED_TOPOLOGY, LevelNumber);
> > -  Print (L"  EAX:%08x  EBX:%08x  ECX:%08x  EDX:%08x\n", Eax.Uint32,
> > Ebx.Uint32, Ecx.Uint32, Edx);
> > -  PRINT_BIT_FIELD (Eax, ApicIdShift);
> > -  PRINT_BIT_FIELD (Ebx, LogicalProcessors);
> > -  PRINT_BIT_FIELD (Ecx, LevelNumber);
> > -  PRINT_BIT_FIELD (Ecx, LevelType);
> > -  PRINT_VALUE (Edx, x2APIC_ID);
> > +if (Ecx.Bits.LevelType ==
> > CPUID_V2_EXTENDED_TOPOLOGY_ENUMERATION_LEVEL_TYPE_INVALID)
> {
> > +  break;
> >  }
> > -LevelNumber++;
> > -  } while (Eax.Bits.ApicIdShift != 0);
> > +Print (
> > +  L"%a (Leaf %08x, Sub-Leaf %08x)\n",
> > +  LeafFunction == CPUID_EXTENDED_TOPOLOGY ?
> > "CPUID_EXTENDED_TOPOLOGY" :
> > "CPUID_V2_EXTENDED_TOPOLOGY_ENUMERATION-2",
> > +  LeafFunction, LevelNumber);
> > +Print (L"  EAX:%08x  EBX:%08x  ECX:%08x  EDX:%08x\n", Eax.Uint32,
> > Ebx.Uint32, Ecx.Uint32, Edx);
> > +PRINT_BIT_FIELD (Eax, BitsNum);
> > +PRINT_BIT_FIELD (Ebx, ProcessorsNum);
> > +PRINT_BIT_FIELD (Ecx, LevelNum);
> > +PRINT_BIT_FIELD (Ecx, LevelType);
> > +PRINT_VALUE (Edx, x2APIC_ID);
> 
> The name for above fields are different in CPUID_EXTENDED_TOPOLOGY and
> CPUID_V2_EXTENDED_TOPOLOGY_ENUMERATION,
> So I think above print are not correct for CPUID_EXTENDED_TOPOLOGY, right?
> 

Per IA32 SDM, CPUID leaf 0BH and 1FH are very similar except 1FH returns more
level types than that of 0BH.
If you compare the accordingly output EAX/EBX, ECX, EDX, the structure 
definitions
are the same except the field names are different.
I don't know why the field names are different when the new structure 
definitions
were added for 1FH.
___
edk2-devel mailing list
edk2-devel@lists.01.org

Re: [edk2] aarch64-linux-gnu-gcc.exe: error due to loss ‘/’in code path in in Jenkins server

[wang xiaofeng]

Hi Leif,
   We use VC for X86 (do not need GCC cross complie)
   gcc revision : 
Using built-in specs.
COLLECT_GCC=aarch64-linux-gnu-gcc.exe
COLLECT_LTO_WRAPPER=c:/code/gnutools/gcc-linaro-7.3.1-2018.05-i686-mingw32_aarch64-linux-gnu/bin/../libexec/gcc/aarch64-linux-gnu/7.3.1/lto-wrapper.exe
Target: aarch64-linux-gnu
Configured with: 
'/home/tcwg-buildslave/workspace/tcwg-make-release/builder_arch/amd64/label/tcwg-x86_64-build/target/aarch64-linux-gnu/snapshots/gcc.git~linaro-7.3-2018.05/configure'
 SHELL=/bin/bash 
--with-mpc=/home/tcwg-buildslave/workspace/tcwg-make-release/builder_arch/amd64/label/tcwg-x86_64-build/target/aarch64-linux-gnu/_build/builds/destdir/i686-w64-mingw32
 
--with-mpfr=/home/tcwg-buildslave/workspace/tcwg-make-release/builder_arch/amd64/label/tcwg-x86_64-build/target/aarch64-linux-gnu/_build/builds/destdir/i686-w64-mingw32
 
--with-gmp=/home/tcwg-buildslave/workspace/tcwg-make-release/builder_arch/amd64/label/tcwg-x86_64-build/target/aarch64-linux-gnu/_build/builds/destdir/i686-w64-mingw32
 --with-gnu-as --with-gnu-ld --disable-libmudflap --enable-lto --enable-shared 
--without-included-gettext --enable-nls --with-system-zlib 
--disable-sjlj-exceptions --enable-gnu-unique-object --enable-linker-build-id 
--disable-libstdcxx-pch --enable-c99 --enable-clocale=gnu --enable-libstdcxx-d
 ebug --enable-long-long --with-cloog=no --with-ppl=no --with-isl=no 
--disable-multilib --enable-fix-cortex-a53-835769 
--enable-fix-cortex-a53-843419 --with-arch=armv8-a --enable-threads=posix 
--enable-multiarch --enable-libstdcxx-time=yes --enable-gnu-indirect-function 
--with-build-sysroot=/home/tcwg-buildslave/workspace/tcwg-make-release/builder_arch/amd64/label/tcwg-x86_64-build/target/aarch64-linux-gnu/_build/sysroots/aarch64-linux-gnu
 
--with-sysroot=/home/tcwg-buildslave/workspace/tcwg-make-release/builder_arch/amd64/label/tcwg-x86_64-build/target/aarch64-linux-gnu/_build/builds/destdir/i686-w64-mingw32/aarch64-linux-gnu/libc
 --enable-checking=release --disable-bootstrap 
--enable-languages=c,c++,fortran,lto 
--with-libiconv-prefix=/home/tcwg-buildslave/workspace/tcwg-make-release/builder_arch/amd64/label/tcwg-x86_64-build/target/aarch64-linux-gnu/_build/builds/destdir/i686-w64-mingw32/usr
 --with-system-zlib=no --build=x86_64-unknown-linux-gnu --host=i686-w64-mingw32 
--target=aarc
 h64-linux-gnu 
--prefix=/home/tcwg-buildslave/workspace/tcwg-make-release/builder_arch/amd64/label/tcwg-x86_64-build/target/aarch64-linux-gnu/_build/builds/destdir/i686-w64-mingw32
Thread model: posix
gcc version 7.3.1 20180425 [linaro-7.3-2018.05 revision 
d29120a424ecfbc167ef90065c0eeb7f91977701] (Linaro GCC 7.3-2018.05)




   GNUmake revision : GNUMake-3.81_win32


 Can the tool provide more debug output ?










At 2019-04-03 16:00:04, "Leif Lindholm"  wrote:
>Sami, any ideas?
>
>Xiaofeng, what gcc is being used for x86? (output of "gcc -v")
>
>Best Regards,
>
>Leif
>
>On Wed, Apr 03, 2019 at 03:54:33PM +0800, wang xiaofeng wrote:
>> HI ARM Base tool owners,
>>I meet a strange issue that aarch64 build . The aarch64 build pass on my 
>> local server.  But it fails at Jenkins server(a Win10 autobuild system 
>> written by Java that will can call edk2 bat in command line)
>> 
>> 
>> The build command is 
>> "c:\jenkins\workspace\gop2018\udk2018\gnutools\gcc-linaro-7.3.1-2018.05-i686-mingw32_aarch64-linux-gnu\bin\aarch64-linux-gnu-gcc"
>>  -g -fshort-wchar -fno-builtin -fno-strict-aliasing -Wall -Werror 
>> -Wno-array-bounds -ffunction-sections -fdata-sections -include AutoGen.h 
>> -fno-common -DSTRING_ARRAY_NAME=UefiDevicePathLibStrings -g -Os 
>> -fshort-wchar -fno-builtin -fno-strict-aliasing -Wall -Werror 
>> -Wno-missing-braces -Wno-array-bounds -include AutoGen.h -fno-common 
>> -mlittle-endian -fno-short-enums -fverbose-asm -funsigned-char 
>> -ffunction-sections -fdata-sections -Wno-address 
>> -fno-asynchronous-unwind-tables -fno-pic -fno-pie -ffixed-x18 -flto 
>> -Wno-unused-but-set-variable -Wno-unused-const-variable -mcmodel=small 
>> -DEDKII -DEFIX64 -DUEFI_BUILD -DFGL_LINUX -DGCC_TOOLCHAIN -c -o 
>> c:\jenkins\workspace\gop2018\udk2018\Build\AmdGopPkg\DEBUG_GCC5\AARCH64\MdePkg\Library\UefiDevicePathLib\UefiDevicePathLib\OUTPUT\.\DevicePathUtilities.obj
>>  -Ic:\jenkins\workspace\gop2018\udk2018\M
 dePkg\Library\UefiDevicePathLib 
-Ic:\jenkins\workspace\gop2018\udk2018\Build\AmdGopPkg\DEBUG_GCC5\AARCH64\MdePkg\Library\UefiDevicePathLib\UefiDevicePathLib\DEBUG
 -Ic:\jenkins\workspace\gop2018\udk2018\MdePkg 
-Ic:\jenkins\workspace\gop2018\udk2018\MdePkg\Include 
-Ic:\jenkins\workspace\gop2018\udk2018\MdePkg\Include\AArch64 
c:\jenkins\workspace\gop2018\udk2018\MdePkg\Library\UefiDevicePathLib\DevicePathUtilities.c
>> 
>> 
>> But aarch64-linux-gnu-gcc.exe will return error with : 
>> c:jenkinsworkspacegop2018udk2018MdePkgLibraryUefiDevicePathLibDevicePathUtilities.c:
>>  No such file or director
>> The failure is due to all \ is missed from view of 
>> aarch64-linux-gnu-gcc.exe, while the 

Re: [edk2] aarch64-linux-gnu-gcc.exe: error due to loss ‘/’in code path in in Jenkins server

[Leif Lindholm]

Sami, any ideas?

Xiaofeng, what gcc is being used for x86? (output of "gcc -v")

Best Regards,

Leif

On Wed, Apr 03, 2019 at 03:54:33PM +0800, wang xiaofeng wrote:
> HI ARM Base tool owners,
>I meet a strange issue that aarch64 build . The aarch64 build pass on my 
> local server.  But it fails at Jenkins server(a Win10 autobuild system 
> written by Java that will can call edk2 bat in command line)
> 
> 
> The build command is 
> "c:\jenkins\workspace\gop2018\udk2018\gnutools\gcc-linaro-7.3.1-2018.05-i686-mingw32_aarch64-linux-gnu\bin\aarch64-linux-gnu-gcc"
>  -g -fshort-wchar -fno-builtin -fno-strict-aliasing -Wall -Werror 
> -Wno-array-bounds -ffunction-sections -fdata-sections -include AutoGen.h 
> -fno-common -DSTRING_ARRAY_NAME=UefiDevicePathLibStrings -g -Os -fshort-wchar 
> -fno-builtin -fno-strict-aliasing -Wall -Werror -Wno-missing-braces 
> -Wno-array-bounds -include AutoGen.h -fno-common -mlittle-endian 
> -fno-short-enums -fverbose-asm -funsigned-char -ffunction-sections 
> -fdata-sections -Wno-address -fno-asynchronous-unwind-tables -fno-pic 
> -fno-pie -ffixed-x18 -flto -Wno-unused-but-set-variable 
> -Wno-unused-const-variable -mcmodel=small -DEDKII -DEFIX64 -DUEFI_BUILD 
> -DFGL_LINUX -DGCC_TOOLCHAIN -c -o 
> c:\jenkins\workspace\gop2018\udk2018\Build\AmdGopPkg\DEBUG_GCC5\AARCH64\MdePkg\Library\UefiDevicePathLib\UefiDevicePathLib\OUTPUT\.\DevicePathUtilities.obj
>  -Ic:\jenkins\workspace\gop2018\udk2018\Md
 ePkg\Library\UefiDevicePathLib 
-Ic:\jenkins\workspace\gop2018\udk2018\Build\AmdGopPkg\DEBUG_GCC5\AARCH64\MdePkg\Library\UefiDevicePathLib\UefiDevicePathLib\DEBUG
 -Ic:\jenkins\workspace\gop2018\udk2018\MdePkg 
-Ic:\jenkins\workspace\gop2018\udk2018\MdePkg\Include 
-Ic:\jenkins\workspace\gop2018\udk2018\MdePkg\Include\AArch64 
c:\jenkins\workspace\gop2018\udk2018\MdePkg\Library\UefiDevicePathLib\DevicePathUtilities.c
> 
> 
> But aarch64-linux-gnu-gcc.exe will return error with : 
> c:jenkinsworkspacegop2018udk2018MdePkgLibraryUefiDevicePathLibDevicePathUtilities.c:
>  No such file or director
> The failure is due to all \ is missed from view of aarch64-linux-gnu-gcc.exe, 
> while the makefile and build log have '\' 
> Another clue is that x86 build is ok on the same Jenkins system
> 
> 
> Anyone have advice for this strange issue?
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH V2] BaseTools:GenMakeFile Complete the task using CC Tool multithreading

[Fan, ZhijuX]

CC_FLAGS "/Mp" enables multithreading with CC Tool.
In order to adapt to this change, I made some changes to other tools

Cc: Bob Feng 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Zhiju.Fan 
---
 BaseTools/Conf/build_rule.template |  2 +-
 BaseTools/Conf/tools_def.template  | 48 -
 BaseTools/Source/Python/AutoGen/GenMake.py | 83 +++---
 3 files changed, 101 insertions(+), 32 deletions(-)

diff --git a/BaseTools/Conf/build_rule.template 
b/BaseTools/Conf/build_rule.template
index e56b1d9c59..4fc042f457 100755
--- a/BaseTools/Conf/build_rule.template
+++ b/BaseTools/Conf/build_rule.template
@@ -129,7 +129,7 @@
 $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.obj
 
 
-"$(CC)" /Fo${dst} $(CC_FLAGS) $(INC) ${src}
+"$(CC)" /Fo${d_path}\ $(CC_FLAGS) $(INC) ${src}
 
 
 # For RVCTCYGWIN CC_FLAGS must be first to work around pathing issues
diff --git a/BaseTools/Conf/tools_def.template 
b/BaseTools/Conf/tools_def.template
index abda2164a6..f65df7dbd9 100755
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -1810,9 +1810,9 @@ NOOPT_VS2012xASL_X64_DLINK_FLAGS= /NOLOGO 
/NODEFAULTLIB /IGNORE:4001 /OPT:RE
 *_VS2012x86_IA32_ASM_PATH = DEF(VS2012x86_BIN)\ml.exe
 
   *_VS2012x86_IA32_MAKE_FLAGS  = /nologo
-  DEBUG_VS2012x86_IA32_CC_FLAGS= /nologo /arch:IA32 /c /WX /GS- /W4 
/Gs32768 /D UNICODE /O1b2 /GL /FIAutoGen.h /EHs-c- /GR- /GF /Gy /Z7
-RELEASE_VS2012x86_IA32_CC_FLAGS= /nologo /arch:IA32 /c /WX /GS- /W4 
/Gs32768 /D UNICODE /O1b2 /GL /FIAutoGen.h /EHs-c- /GR- /GF
-NOOPT_VS2012x86_IA32_CC_FLAGS  = /nologo /arch:IA32 /c /WX /GS- /W4 
/Gs32768 /D UNICODE /FIAutoGen.h /EHs-c- /GR- /GF /Gy /Z7 /Od
+  DEBUG_VS2012x86_IA32_CC_FLAGS= /nologo /arch:IA32 /c /WX /GS- /W4 
/Gs32768 /D UNICODE /O1b2 /GL /FIAutoGen.h /EHs-c- /GR- /GF /Gy /Z7 /MP1
+RELEASE_VS2012x86_IA32_CC_FLAGS= /nologo /arch:IA32 /c /WX /GS- /W4 
/Gs32768 /D UNICODE /O1b2 /GL /FIAutoGen.h /EHs-c- /GR- /GF /MP1
+NOOPT_VS2012x86_IA32_CC_FLAGS  = /nologo /arch:IA32 /c /WX /GS- /W4 
/Gs32768 /D UNICODE /FIAutoGen.h /EHs-c- /GR- /GF /Gy /Z7 /Od /MP1
 
   DEBUG_VS2012x86_IA32_ASM_FLAGS   = /nologo /c /WX /W3 /Cx /coff /Zd /Zi
 RELEASE_VS2012x86_IA32_ASM_FLAGS   = /nologo /c /WX /W3 /Cx /coff /Zd
@@ -1842,9 +1842,9 @@ NOOPT_VS2012x86_IA32_DLINK_FLAGS   = /NOLOGO 
/NODEFAULTLIB /IGNORE:4001 /OPT:REF
 *_VS2012x86_X64_DLINK_PATH= DEF(VS2012x86_BINX64)\link.exe
 *_VS2012x86_X64_ASLDLINK_PATH = DEF(VS2012x86_BINX64)\link.exe
 
-  DEBUG_VS2012x86_X64_CC_FLAGS = /nologo /c /WX /GS- /W4 /Gs32768 /D 
UNICODE /O1b2s /GL /Gy /FIAutoGen.h /EHs-c- /GR- /GF /Z7
-RELEASE_VS2012x86_X64_CC_FLAGS = /nologo /c /WX /GS- /W4 /Gs32768 /D 
UNICODE /O1b2s /GL /Gy /FIAutoGen.h /EHs-c- /GR- /GF
-NOOPT_VS2012x86_X64_CC_FLAGS   = /nologo /c /WX /GS- /W4 /Gs32768 /D 
UNICODE /Gy /FIAutoGen.h /EHs-c- /GR- /GF /Z7 /Od
+  DEBUG_VS2012x86_X64_CC_FLAGS = /nologo /c /WX /GS- /W4 /Gs32768 /D 
UNICODE /O1b2s /GL /Gy /FIAutoGen.h /EHs-c- /GR- /GF /Z7 /MP1
+RELEASE_VS2012x86_X64_CC_FLAGS = /nologo /c /WX /GS- /W4 /Gs32768 /D 
UNICODE /O1b2s /GL /Gy /FIAutoGen.h /EHs-c- /GR- /GF /MP1
+NOOPT_VS2012x86_X64_CC_FLAGS   = /nologo /c /WX /GS- /W4 /Gs32768 /D 
UNICODE /Gy /FIAutoGen.h /EHs-c- /GR- /GF /Z7 /Od /MP1
 
   DEBUG_VS2012x86_X64_ASM_FLAGS= /nologo /c /WX /W3 /Cx /Zd /Zi
 RELEASE_VS2012x86_X64_ASM_FLAGS= /nologo /c /WX /W3 /Cx /Zd
@@ -2276,9 +2276,9 @@ NOOPT_VS2013xASL_X64_DLINK_FLAGS= /NOLOGO 
/NODEFAULTLIB /IGNORE:4001 /OPT:RE
 *_VS2013x86_IA32_ASM_PATH = DEF(VS2013x86_BIN)\ml.exe
 
   *_VS2013x86_IA32_MAKE_FLAGS  = /nologo
-  DEBUG_VS2013x86_IA32_CC_FLAGS= /nologo /arch:IA32 /c /WX /GS- /W4 
/Gs32768 /D UNICODE /O1b2 /GL /FIAutoGen.h /EHs-c- /GR- /GF /Gy /Z7 /Gw
-RELEASE_VS2013x86_IA32_CC_FLAGS= /nologo /arch:IA32 /c /WX /GS- /W4 
/Gs32768 /D UNICODE /O1b2 /GL /FIAutoGen.h /EHs-c- /GR- /GF /Gw
-NOOPT_VS2013x86_IA32_CC_FLAGS  = /nologo /arch:IA32 /c /WX /GS- /W4 
/Gs32768 /D UNICODE /FIAutoGen.h /EHs-c- /GR- /GF /Gy /Z7 /Od
+  DEBUG_VS2013x86_IA32_CC_FLAGS= /nologo /arch:IA32 /c /WX /GS- /W4 
/Gs32768 /D UNICODE /O1b2 /GL /FIAutoGen.h /EHs-c- /GR- /GF /Gy /Z7 /Gw /MP1
+RELEASE_VS2013x86_IA32_CC_FLAGS= /nologo /arch:IA32 /c /WX /GS- /W4 
/Gs32768 /D UNICODE /O1b2 /GL /FIAutoGen.h /EHs-c- /GR- /GF /Gw /MP1
+NOOPT_VS2013x86_IA32_CC_FLAGS  = /nologo /arch:IA32 /c /WX /GS- /W4 
/Gs32768 /D UNICODE /FIAutoGen.h /EHs-c- /GR- /GF /Gy /Z7 /Od /MP1
 
   DEBUG_VS2013x86_IA32_ASM_FLAGS   = /nologo /c /WX /W3 /Cx /coff /Zd /Zi
 RELEASE_VS2013x86_IA32_ASM_FLAGS   = /nologo /c /WX /W3 /Cx /coff /Zd
@@ -2308,9 +2308,9 @@ NOOPT_VS2013x86_IA32_DLINK_FLAGS   = /NOLOGO 
/NODEFAULTLIB /IGNORE:4001 /OPT:REF
 *_VS2013x86_X64_DLINK_PATH= DEF(VS2013x86_BINX64)\link.exe
 *_VS2013x86_X64_ASLDLINK_PATH = DEF(VS2013x86_BINX64)\link.exe
 
-  

[edk2] aarch64-linux-gnu-gcc.exe: error due to loss ‘/’in code path in in Jenkins server

[wang xiaofeng]

HI ARM Base tool owners,
   I meet a strange issue that aarch64 build . The aarch64 build pass on my 
local server.  But it fails at Jenkins server(a Win10 autobuild system written 
by Java that will can call edk2 bat in command line)


The build command is 
"c:\jenkins\workspace\gop2018\udk2018\gnutools\gcc-linaro-7.3.1-2018.05-i686-mingw32_aarch64-linux-gnu\bin\aarch64-linux-gnu-gcc"
 -g -fshort-wchar -fno-builtin -fno-strict-aliasing -Wall -Werror 
-Wno-array-bounds -ffunction-sections -fdata-sections -include AutoGen.h 
-fno-common -DSTRING_ARRAY_NAME=UefiDevicePathLibStrings -g -Os -fshort-wchar 
-fno-builtin -fno-strict-aliasing -Wall -Werror -Wno-missing-braces 
-Wno-array-bounds -include AutoGen.h -fno-common -mlittle-endian 
-fno-short-enums -fverbose-asm -funsigned-char -ffunction-sections 
-fdata-sections -Wno-address -fno-asynchronous-unwind-tables -fno-pic -fno-pie 
-ffixed-x18 -flto -Wno-unused-but-set-variable -Wno-unused-const-variable 
-mcmodel=small -DEDKII -DEFIX64 -DUEFI_BUILD -DFGL_LINUX -DGCC_TOOLCHAIN -c -o 
c:\jenkins\workspace\gop2018\udk2018\Build\AmdGopPkg\DEBUG_GCC5\AARCH64\MdePkg\Library\UefiDevicePathLib\UefiDevicePathLib\OUTPUT\.\DevicePathUtilities.obj
 -Ic:\jenkins\workspace\gop2018\udk2018\MdeP
 kg\Library\UefiDevicePathLib 
-Ic:\jenkins\workspace\gop2018\udk2018\Build\AmdGopPkg\DEBUG_GCC5\AARCH64\MdePkg\Library\UefiDevicePathLib\UefiDevicePathLib\DEBUG
 -Ic:\jenkins\workspace\gop2018\udk2018\MdePkg 
-Ic:\jenkins\workspace\gop2018\udk2018\MdePkg\Include 
-Ic:\jenkins\workspace\gop2018\udk2018\MdePkg\Include\AArch64 
c:\jenkins\workspace\gop2018\udk2018\MdePkg\Library\UefiDevicePathLib\DevicePathUtilities.c


But aarch64-linux-gnu-gcc.exe will return error with : 
c:jenkinsworkspacegop2018udk2018MdePkgLibraryUefiDevicePathLibDevicePathUtilities.c:
 No such file or director
The failure is due to all \ is missed from view of aarch64-linux-gnu-gcc.exe, 
while the makefile and build log have '\' 
Another clue is that x86 build is ok on the same Jenkins system


Anyone have advice for this strange issue?

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] SourceLevelDebugPkg/DebugAgent: Remove AsmFuncs.S in INF

[Wu, Hao A]

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Wu, Hao A
> Sent: Wednesday, April 03, 2019 3:27 PM
> To: Zhang, Shenglei; edk2-devel@lists.01.org
> Subject: Re: [edk2] [PATCH] SourceLevelDebugPkg/DebugAgent: Remove
> AsmFuncs.S in INF
> 
> Reviewed-by: Hao Wu 
> 
> I will push this patch shortly to address the build failure for
> SourceLevelDebugPkg.

Pushed via commit 7ed72121b753a7493a8c5bf3711b5efbc5e80491.


> 
> Best Regards,
> Hao Wu
> 
> 
> > -Original Message-
> > From: Zhang, Shenglei
> > Sent: Wednesday, April 03, 2019 2:32 PM
> > To: edk2-devel@lists.01.org
> > Cc: Wu, Hao A; Zhang, Shenglei
> > Subject: [PATCH] SourceLevelDebugPkg/DebugAgent: Remove
> AsmFuncs.S
> > in INF
> >
> > AsmFuncs.S is removed at c7d22535f7dc90b8fef70153ef98549228569680.
> > And also it should be removed in SecPeiDebugAgentLib.inf and
> > SmmDebugAgentLib.inf.
> >
> > Cc: Hao Wu 
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Shenglei Zhang 
> > ---
> >  SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgentLib.inf | 2 -
> -
> >  SourceLevelDebugPkg/Library/DebugAgent/SmmDebugAgentLib.inf| 2 -
> -
> >  2 files changed, 4 deletions(-)
> >
> > diff --git
> > a/SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgentLib.inf
> > b/SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgentLib.inf
> > index 03ebbb6e74..8b81795d96 100644
> > --- a/SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgentLib.inf
> > +++
> b/SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgentLib.inf
> > @@ -39,14 +39,12 @@
> >DebugAgentCommon/DebugMp.h
> >
> >  [Sources.Ia32]
> > -  DebugAgentCommon/Ia32/AsmFuncs.S
> >DebugAgentCommon/Ia32/AsmFuncs.nasm
> >DebugAgentCommon/Ia32/ArchDebugSupport.h
> >DebugAgentCommon/Ia32/ArchDebugSupport.c
> >DebugAgentCommon/Ia32/DebugException.h
> >
> >  [Sources.X64]
> > -  DebugAgentCommon/X64/AsmFuncs.S
> >DebugAgentCommon/X64/AsmFuncs.nasm
> >DebugAgentCommon/X64/ArchDebugSupport.h
> >DebugAgentCommon/X64/ArchDebugSupport.c
> > diff --git
> > a/SourceLevelDebugPkg/Library/DebugAgent/SmmDebugAgentLib.inf
> > b/SourceLevelDebugPkg/Library/DebugAgent/SmmDebugAgentLib.inf
> > index 08ed1777be..f1b32daab3 100644
> > --- a/SourceLevelDebugPkg/Library/DebugAgent/SmmDebugAgentLib.inf
> > +++ b/SourceLevelDebugPkg/Library/DebugAgent/SmmDebugAgentLib.inf
> > @@ -39,14 +39,12 @@
> >DebugAgentCommon/DebugMp.h
> >
> >  [Sources.Ia32]
> > -  DebugAgentCommon/Ia32/AsmFuncs.S
> >DebugAgentCommon/Ia32/AsmFuncs.nasm
> >DebugAgentCommon/Ia32/ArchDebugSupport.h
> >DebugAgentCommon/Ia32/ArchDebugSupport.c
> >DebugAgentCommon/Ia32/DebugException.h
> >
> >  [Sources.X64]
> > -  DebugAgentCommon/X64/AsmFuncs.S
> >DebugAgentCommon/X64/AsmFuncs.nasm
> >DebugAgentCommon/X64/ArchDebugSupport.h
> >DebugAgentCommon/X64/ArchDebugSupport.c
> > --
> > 2.18.0.windows.1
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] SourceLevelDebugPkg/DebugAgent: Remove AsmFuncs.S in INF

[Wu, Hao A]

Reviewed-by: Hao Wu 

I will push this patch shortly to address the build failure for
SourceLevelDebugPkg.

Best Regards,
Hao Wu


> -Original Message-
> From: Zhang, Shenglei
> Sent: Wednesday, April 03, 2019 2:32 PM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A; Zhang, Shenglei
> Subject: [PATCH] SourceLevelDebugPkg/DebugAgent: Remove AsmFuncs.S
> in INF
> 
> AsmFuncs.S is removed at c7d22535f7dc90b8fef70153ef98549228569680.
> And also it should be removed in SecPeiDebugAgentLib.inf and
> SmmDebugAgentLib.inf.
> 
> Cc: Hao Wu 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Shenglei Zhang 
> ---
>  SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgentLib.inf | 2 --
>  SourceLevelDebugPkg/Library/DebugAgent/SmmDebugAgentLib.inf| 2 --
>  2 files changed, 4 deletions(-)
> 
> diff --git
> a/SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgentLib.inf
> b/SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgentLib.inf
> index 03ebbb6e74..8b81795d96 100644
> --- a/SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgentLib.inf
> +++ b/SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgentLib.inf
> @@ -39,14 +39,12 @@
>DebugAgentCommon/DebugMp.h
> 
>  [Sources.Ia32]
> -  DebugAgentCommon/Ia32/AsmFuncs.S
>DebugAgentCommon/Ia32/AsmFuncs.nasm
>DebugAgentCommon/Ia32/ArchDebugSupport.h
>DebugAgentCommon/Ia32/ArchDebugSupport.c
>DebugAgentCommon/Ia32/DebugException.h
> 
>  [Sources.X64]
> -  DebugAgentCommon/X64/AsmFuncs.S
>DebugAgentCommon/X64/AsmFuncs.nasm
>DebugAgentCommon/X64/ArchDebugSupport.h
>DebugAgentCommon/X64/ArchDebugSupport.c
> diff --git
> a/SourceLevelDebugPkg/Library/DebugAgent/SmmDebugAgentLib.inf
> b/SourceLevelDebugPkg/Library/DebugAgent/SmmDebugAgentLib.inf
> index 08ed1777be..f1b32daab3 100644
> --- a/SourceLevelDebugPkg/Library/DebugAgent/SmmDebugAgentLib.inf
> +++ b/SourceLevelDebugPkg/Library/DebugAgent/SmmDebugAgentLib.inf
> @@ -39,14 +39,12 @@
>DebugAgentCommon/DebugMp.h
> 
>  [Sources.Ia32]
> -  DebugAgentCommon/Ia32/AsmFuncs.S
>DebugAgentCommon/Ia32/AsmFuncs.nasm
>DebugAgentCommon/Ia32/ArchDebugSupport.h
>DebugAgentCommon/Ia32/ArchDebugSupport.c
>DebugAgentCommon/Ia32/DebugException.h
> 
>  [Sources.X64]
> -  DebugAgentCommon/X64/AsmFuncs.S
>DebugAgentCommon/X64/AsmFuncs.nasm
>DebugAgentCommon/X64/ArchDebugSupport.h
>DebugAgentCommon/X64/ArchDebugSupport.c
> --
> 2.18.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [RFC PATCH v1 7/8] OvmfPkg/8254TimerDxe: Update to make it build for OVMF

[Hao Wu]

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1496

This commit will remove the IntelFrameworkPkg DEC file dependency in the
driver INF file.

A new GUID has been updated for the INF file.

Corresponding changes have been made in OVMF DSC files as well in order to
verify the build.

Cc: Jordan Justen 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Cc: David Woodhouse 
Cc: Ray Ni 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu 
---
 OvmfPkg/OvmfPkgIa32.dsc| 1 +
 OvmfPkg/OvmfPkgIa32X64.dsc | 1 +
 OvmfPkg/OvmfPkgX64.dsc | 1 +
 OvmfPkg/8254TimerDxe/8254Timer.inf | 6 +++---
 4 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index 47182f0cad..d88295f9fd 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -674,6 +674,7 @@
   UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
   UefiCpuPkg/CpuDxe/CpuDxe.inf
   PcAtChipsetPkg/8254TimerDxe/8254Timer.inf
+  OvmfPkg/8254TimerDxe/8254Timer.inf
   OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf
   OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.inf
   MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf {
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index d9603a7107..a83b6f448e 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -683,6 +683,7 @@
   UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
   UefiCpuPkg/CpuDxe/CpuDxe.inf
   PcAtChipsetPkg/8254TimerDxe/8254Timer.inf
+  OvmfPkg/8254TimerDxe/8254Timer.inf
   OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf
   OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.inf
   MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf {
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index 2cc39d54b0..ad9816a165 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -681,6 +681,7 @@
   UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
   UefiCpuPkg/CpuDxe/CpuDxe.inf
   PcAtChipsetPkg/8254TimerDxe/8254Timer.inf
+  OvmfPkg/8254TimerDxe/8254Timer.inf
   OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf
   OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.inf
   MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf {
diff --git a/OvmfPkg/8254TimerDxe/8254Timer.inf 
b/OvmfPkg/8254TimerDxe/8254Timer.inf
index 46cf01de39..93bee768ed 100644
--- a/OvmfPkg/8254TimerDxe/8254Timer.inf
+++ b/OvmfPkg/8254TimerDxe/8254Timer.inf
@@ -1,7 +1,7 @@
 ## @file
 # 8254 timer driver that provides Timer Arch protocol.
 #
-# Copyright (c) 2005 - 2018, Intel Corporation. All rights reserved.
+# Copyright (c) 2005 - 2019, Intel Corporation. All rights reserved.
 # This program and the accompanying materials
 # are licensed and made available under the terms and conditions of the BSD 
License
 # which accompanies this distribution.  The full text of the license may be 
found at
@@ -16,7 +16,7 @@
   INF_VERSION= 0x00010005
   BASE_NAME  = Timer
   MODULE_UNI_FILE= Timer.uni
-  FILE_GUID  = f2765dec-6b41-11d5-8e71-00902707b35e
+  FILE_GUID  = C190FE35-44AA-41A1-8AEA-4947BC60E09D
   MODULE_TYPE= DXE_DRIVER
   VERSION_STRING = 1.0
 
@@ -24,7 +24,7 @@
 
 [Packages]
   MdePkg/MdePkg.dec
-  IntelFrameworkPkg/IntelFrameworkPkg.dec
+  OvmfPkg/OvmfPkg.dec
 
 [LibraryClasses]
   UefiBootServicesTableLib
-- 
2.12.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [RFC PATCH v1 6/8] OvmfPkg: Copy 8254TimerDxe driver from PcAtChipsetPkg

[Hao Wu]

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1496

This commit copies the exact 8254TimerDxe driver from PcAtChipsetPkg to
OvmfPkg.

Cc: Jordan Justen 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Cc: David Woodhouse 
Cc: Ray Ni 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu 
---
 OvmfPkg/8254TimerDxe/8254Timer.inf  |  48 +++
 OvmfPkg/8254TimerDxe/Timer.h| 191 +
 OvmfPkg/8254TimerDxe/Timer.c| 407 
 OvmfPkg/8254TimerDxe/Timer.uni  |  22 ++
 OvmfPkg/8254TimerDxe/TimerExtra.uni |  20 +
 5 files changed, 688 insertions(+)

diff --git a/OvmfPkg/8254TimerDxe/8254Timer.inf 
b/OvmfPkg/8254TimerDxe/8254Timer.inf
new file mode 100644
index 00..46cf01de39
--- /dev/null
+++ b/OvmfPkg/8254TimerDxe/8254Timer.inf
@@ -0,0 +1,48 @@
+## @file
+# 8254 timer driver that provides Timer Arch protocol.
+#
+# Copyright (c) 2005 - 2018, Intel Corporation. All rights reserved.
+# This program and the accompanying materials
+# are licensed and made available under the terms and conditions of the BSD 
License
+# which accompanies this distribution.  The full text of the license may be 
found at
+# http://opensource.org/licenses/bsd-license.php
+#
+# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+#
+##
+
+[Defines]
+  INF_VERSION= 0x00010005
+  BASE_NAME  = Timer
+  MODULE_UNI_FILE= Timer.uni
+  FILE_GUID  = f2765dec-6b41-11d5-8e71-00902707b35e
+  MODULE_TYPE= DXE_DRIVER
+  VERSION_STRING = 1.0
+
+  ENTRY_POINT= TimerDriverInitialize
+
+[Packages]
+  MdePkg/MdePkg.dec
+  IntelFrameworkPkg/IntelFrameworkPkg.dec
+
+[LibraryClasses]
+  UefiBootServicesTableLib
+  BaseLib
+  DebugLib
+  UefiDriverEntryPoint
+  IoLib
+
+[Sources]
+  Timer.h
+  Timer.c
+
+[Protocols]
+  gEfiCpuArchProtocolGuid   ## CONSUMES
+  gEfiLegacy8259ProtocolGuid## CONSUMES
+  gEfiTimerArchProtocolGuid ## PRODUCES
+
+[Depex]
+  gEfiCpuArchProtocolGuid AND gEfiLegacy8259ProtocolGuid
+[UserExtensions.TianoCore."ExtraFiles"]
+  TimerExtra.uni
diff --git a/OvmfPkg/8254TimerDxe/Timer.h b/OvmfPkg/8254TimerDxe/Timer.h
new file mode 100644
index 00..9d70e3aa19
--- /dev/null
+++ b/OvmfPkg/8254TimerDxe/Timer.h
@@ -0,0 +1,191 @@
+/** @file
+  Private data structures
+
+Copyright (c) 2005 - 2018, Intel Corporation. All rights reserved.
+This program and the accompanying materials
+are licensed and made available under the terms and conditions of the BSD 
License
+which accompanies this distribution.  The full text of the license may be 
found at
+http://opensource.org/licenses/bsd-license.php
+
+THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+**/
+
+#ifndef _TIMER_H_
+#define _TIMER_H_
+
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+//
+// The PCAT 8253/8254 has an input clock at 1.193182 MHz and Timer 0 is
+// initialized as a 16 bit free running counter that generates an 
interrupt(IRQ0)
+// each time the counter rolls over.
+//
+//   65536 counts
+//  * 1,000,000 uS/S = 54925.4 uS = 549254 * 100 ns
+//   1,193,182 Hz
+//
+
+//
+// The maximum tick duration for 8254 timer
+//
+#define MAX_TIMER_TICK_DURATION 549254
+//
+// The default timer tick duration is set to 10 ms = 10 100 ns units
+//
+#define DEFAULT_TIMER_TICK_DURATION 10
+#define TIMER_CONTROL_PORT  0x43
+#define TIMER0_COUNT_PORT   0x40
+
+//
+// Function Prototypes
+//
+/**
+  Initialize the Timer Architectural Protocol driver
+
+  @param ImageHandle ImageHandle of the loaded driver
+  @param SystemTable Pointer to the System Table
+
+  @retval EFI_SUCCESSTimer Architectural Protocol created
+  @retval EFI_OUT_OF_RESOURCES   Not enough resources available to initialize 
driver.
+  @retval EFI_DEVICE_ERROR   A device error occurred attempting to 
initialize the driver.
+
+**/
+EFI_STATUS
+EFIAPI
+TimerDriverInitialize (
+  IN EFI_HANDLEImageHandle,
+  IN EFI_SYSTEM_TABLE  *SystemTable
+  )
+;
+
+/**
+
+  This function adjusts the period of timer interrupts to the value specified
+  by TimerPeriod.  If the timer period is updated, then the selected timer
+  period is stored in EFI_TIMER.TimerPeriod, and EFI_SUCCESS is returned.  If
+  the timer hardware is not programmable, then EFI_UNSUPPORTED is returned.
+  If an error occurs while attempting to update the timer period, then the
+  timer hardware will be put back in its state prior to this call, and
+  EFI_DEVICE_ERROR is returned.  If TimerPeriod is 0, then the timer interrupt
+  is disabled.  This is not the same as disabling the CPU's interrupts.
+  Instead, it must either turn off the timer 

[edk2] [RFC PATCH v1 8/8] OvmfPkg: Update DSC/FDF files to consume 8259/8254 drivers in OvmfPkg

[Hao Wu]

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1496

This commit updates the OVMF DSC/FDF files to consume the copied
8259InterruptControllerDxe and 8254TimerDxe drivers within OvmfPkg.

The unconsumed PCD:
gPcAtChipsetPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel

is removed from DSC files as well.

Cc: Jordan Justen 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Cc: David Woodhouse 
Cc: Ray Ni 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu 
---
 OvmfPkg/OvmfPkgIa32.dsc| 3 ---
 OvmfPkg/OvmfPkgIa32X64.dsc | 3 ---
 OvmfPkg/OvmfPkgX64.dsc | 3 ---
 OvmfPkg/OvmfPkgIa32.fdf| 4 ++--
 OvmfPkg/OvmfPkgIa32X64.fdf | 4 ++--
 OvmfPkg/OvmfPkgX64.fdf | 4 ++--
 6 files changed, 6 insertions(+), 15 deletions(-)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index d88295f9fd..692da9584d 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -516,7 +516,6 @@
 !endif
 
   # IRQs 5, 9, 10, 11 are level-triggered
-  gPcAtChipsetPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel|0x0E20
   gUefiOvmfPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel|0x0E20
 
   # Point to the MdeModulePkg/Application/UiApp/UiApp.inf
@@ -669,11 +668,9 @@
   }
 
   MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
-  PcAtChipsetPkg/8259InterruptControllerDxe/8259.inf
   OvmfPkg/8259InterruptControllerDxe/8259.inf
   UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
   UefiCpuPkg/CpuDxe/CpuDxe.inf
-  PcAtChipsetPkg/8254TimerDxe/8254Timer.inf
   OvmfPkg/8254TimerDxe/8254Timer.inf
   OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf
   OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.inf
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index a83b6f448e..01b2530064 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -522,7 +522,6 @@
 !endif
 
   # IRQs 5, 9, 10, 11 are level-triggered
-  gPcAtChipsetPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel|0x0E20
   gUefiOvmfPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel|0x0E20
 
   # Point to the MdeModulePkg/Application/UiApp/UiApp.inf
@@ -678,11 +677,9 @@
   }
 
   MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
-  PcAtChipsetPkg/8259InterruptControllerDxe/8259.inf
   OvmfPkg/8259InterruptControllerDxe/8259.inf
   UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
   UefiCpuPkg/CpuDxe/CpuDxe.inf
-  PcAtChipsetPkg/8254TimerDxe/8254Timer.inf
   OvmfPkg/8254TimerDxe/8254Timer.inf
   OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf
   OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.inf
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index ad9816a165..444a00c87d 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -521,7 +521,6 @@
 !endif
 
   # IRQs 5, 9, 10, 11 are level-triggered
-  gPcAtChipsetPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel|0x0E20
   gUefiOvmfPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel|0x0E20
 
   # Point to the MdeModulePkg/Application/UiApp/UiApp.inf
@@ -676,11 +675,9 @@
   }
 
   MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
-  PcAtChipsetPkg/8259InterruptControllerDxe/8259.inf
   OvmfPkg/8259InterruptControllerDxe/8259.inf
   UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
   UefiCpuPkg/CpuDxe/CpuDxe.inf
-  PcAtChipsetPkg/8254TimerDxe/8254Timer.inf
   OvmfPkg/8254TimerDxe/8254Timer.inf
   OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf
   OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.inf
diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf
index 006ea9a415..423984b4b9 100644
--- a/OvmfPkg/OvmfPkgIa32.fdf
+++ b/OvmfPkg/OvmfPkgIa32.fdf
@@ -213,10 +213,10 @@ INF  MdeModulePkg/Universal/PCD/Dxe/Pcd.inf
 INF  MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
 INF  MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
 INF  MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
-INF  PcAtChipsetPkg/8259InterruptControllerDxe/8259.inf
+INF  OvmfPkg/8259InterruptControllerDxe/8259.inf
 INF  UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
 INF  UefiCpuPkg/CpuDxe/CpuDxe.inf
-INF  PcAtChipsetPkg/8254TimerDxe/8254Timer.inf
+INF  OvmfPkg/8254TimerDxe/8254Timer.inf
 INF  OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf
 INF  OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.inf
 INF  MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf
diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/OvmfPkgIa32X64.fdf
index 6c40540202..45eb561e3f 100644
--- a/OvmfPkg/OvmfPkgIa32X64.fdf
+++ b/OvmfPkg/OvmfPkgIa32X64.fdf
@@ -214,10 +214,10 @@ INF  MdeModulePkg/Universal/PCD/Dxe/Pcd.inf
 INF  MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
 INF  MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
 INF  MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
-INF  PcAtChipsetPkg/8259InterruptControllerDxe/8259.inf
+INF  OvmfPkg/8259InterruptControllerDxe/8259.inf
 INF  UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
 INF  UefiCpuPkg/CpuDxe/CpuDxe.inf
-INF  PcAtChipsetPkg/8254TimerDxe/8254Timer.inf
+INF  OvmfPkg/8254TimerDxe/8254Timer.inf
 INF  OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf
 INF  

[edk2] [RFC PATCH v1 5/8] OvmfPkg/AcpiPlatformDxe: Consume the 8259 PCD defined in OvmfPkg

[Hao Wu]

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1496

Several updates have been made to the OvmfPkg/AcpiPlatformDxe driver to
drop its dependency on PcAtChipsetPkg:

A) Consumes the PCD 'Pcd8259LegacyModeEdgeLevel' defined within OvmfPkg;
B) Remove the PcAtChipsetPkg DEC file dependency in the driver INF file.

Cc: Jordan Justen 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Cc: David Woodhouse 
Cc: Ray Ni 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu 
---
 OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf 
b/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
index 8440e7b343..24e2c0373f 100644
--- a/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
+++ b/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
@@ -1,7 +1,7 @@
 ## @file
 #  OVMF ACPI Platform Driver
 #
-#  Copyright (c) 2008 - 2018, Intel Corporation. All rights reserved.
+#  Copyright (c) 2008 - 2019, Intel Corporation. All rights reserved.
 #  This program and the accompanying materials
 #  are licensed and made available under the terms and conditions of the BSD 
License
 #  which accompanies this distribution.  The full text of the license may be 
found at
@@ -42,7 +42,6 @@
   MdeModulePkg/MdeModulePkg.dec
   OvmfPkg/OvmfPkg.dec
   UefiCpuPkg/UefiCpuPkg.dec
-  PcAtChipsetPkg/PcAtChipsetPkg.dec
 
 [LibraryClasses]
   UefiLib
@@ -72,7 +71,7 @@
   gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiTableStorageFile
   gEfiMdeModulePkgTokenSpaceGuid.PcdPciDisableBusEnumeration
   gUefiCpuPkgTokenSpaceGuid.PcdCpuLocalApicBaseAddress
-  gPcAtChipsetPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel
+  gUefiOvmfPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFdBaseAddress
 
 [Depex]
-- 
2.12.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [RFC PATCH v1 4/8] OvmfPkg/8259InterruptControllerDxe: Update to make it build for OVMF

[Hao Wu]

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1496

Several updates have been made to the
OvmfPkg/8259InterruptControllerDxe driver to make it build under OvmfPkg:

A) Update the driver INF file to consume PCDs defined within OvmfPkg;
B) Remove the unnecessary dependency on the IntelFrameworkPkg header file
   'FrameworkDxe.h';
C) Remove the IntelFrameworkPkg & PcAtChipsetPkg DEC files dependency in
   the driver INF file.

A new GUID has been updated for the INF file.

Corresponding changes have been made in OVMF DSC files as well in order to
verify the build.

Cc: Jordan Justen 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Cc: David Woodhouse 
Cc: Ray Ni 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu 
---
 OvmfPkg/OvmfPkgIa32.dsc |  2 ++
 OvmfPkg/OvmfPkgIa32X64.dsc  |  2 ++
 OvmfPkg/OvmfPkgX64.dsc  |  2 ++
 OvmfPkg/8259InterruptControllerDxe/8259.inf | 11 +--
 OvmfPkg/8259InterruptControllerDxe/8259.h   |  4 +---
 5 files changed, 12 insertions(+), 9 deletions(-)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index f55ab5a3d2..47182f0cad 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -517,6 +517,7 @@
 
   # IRQs 5, 9, 10, 11 are level-triggered
   gPcAtChipsetPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel|0x0E20
+  gUefiOvmfPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel|0x0E20
 
   # Point to the MdeModulePkg/Application/UiApp/UiApp.inf
   gEfiMdeModulePkgTokenSpaceGuid.PcdBootManagerMenuFile|{ 0x21, 0xaa, 0x2c, 
0x46, 0x14, 0x76, 0x03, 0x45, 0x83, 0x6e, 0x8a, 0xb6, 0xf4, 0x66, 0x23, 0x31 }
@@ -669,6 +670,7 @@
 
   MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
   PcAtChipsetPkg/8259InterruptControllerDxe/8259.inf
+  OvmfPkg/8259InterruptControllerDxe/8259.inf
   UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
   UefiCpuPkg/CpuDxe/CpuDxe.inf
   PcAtChipsetPkg/8254TimerDxe/8254Timer.inf
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 5c9bdf034e..d9603a7107 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -523,6 +523,7 @@
 
   # IRQs 5, 9, 10, 11 are level-triggered
   gPcAtChipsetPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel|0x0E20
+  gUefiOvmfPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel|0x0E20
 
   # Point to the MdeModulePkg/Application/UiApp/UiApp.inf
   gEfiMdeModulePkgTokenSpaceGuid.PcdBootManagerMenuFile|{ 0x21, 0xaa, 0x2c, 
0x46, 0x14, 0x76, 0x03, 0x45, 0x83, 0x6e, 0x8a, 0xb6, 0xf4, 0x66, 0x23, 0x31 }
@@ -678,6 +679,7 @@
 
   MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
   PcAtChipsetPkg/8259InterruptControllerDxe/8259.inf
+  OvmfPkg/8259InterruptControllerDxe/8259.inf
   UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
   UefiCpuPkg/CpuDxe/CpuDxe.inf
   PcAtChipsetPkg/8254TimerDxe/8254Timer.inf
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index 2943e9e8af..2cc39d54b0 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -522,6 +522,7 @@
 
   # IRQs 5, 9, 10, 11 are level-triggered
   gPcAtChipsetPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel|0x0E20
+  gUefiOvmfPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel|0x0E20
 
   # Point to the MdeModulePkg/Application/UiApp/UiApp.inf
   gEfiMdeModulePkgTokenSpaceGuid.PcdBootManagerMenuFile|{ 0x21, 0xaa, 0x2c, 
0x46, 0x14, 0x76, 0x03, 0x45, 0x83, 0x6e, 0x8a, 0xb6, 0xf4, 0x66, 0x23, 0x31 }
@@ -676,6 +677,7 @@
 
   MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
   PcAtChipsetPkg/8259InterruptControllerDxe/8259.inf
+  OvmfPkg/8259InterruptControllerDxe/8259.inf
   UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
   UefiCpuPkg/CpuDxe/CpuDxe.inf
   PcAtChipsetPkg/8254TimerDxe/8254Timer.inf
diff --git a/OvmfPkg/8259InterruptControllerDxe/8259.inf 
b/OvmfPkg/8259InterruptControllerDxe/8259.inf
index 1d9be675e3..c5a1385418 100644
--- a/OvmfPkg/8259InterruptControllerDxe/8259.inf
+++ b/OvmfPkg/8259InterruptControllerDxe/8259.inf
@@ -1,7 +1,7 @@
 ## @file
 # 8259 Interrupt Controller driver that provides Legacy 8259 protocol.
 #
-# Copyright (c) 2005 - 2018, Intel Corporation. All rights reserved.
+# Copyright (c) 2005 - 2019, Intel Corporation. All rights reserved.
 # This program and the accompanying materials
 # are licensed and made available under the terms and conditions of the BSD 
License
 # which accompanies this distribution.  The full text of the license may be 
found at
@@ -16,7 +16,7 @@
   INF_VERSION= 0x00010005
   BASE_NAME  = Legacy8259
   MODULE_UNI_FILE= Legacy8259.uni
-  FILE_GUID  = 79CA4208-BBA1-4a9a-8456-E1E66A81484E
+  FILE_GUID  = 245CB4DA-8E15-4A1B-87E3-9878FFA07520
   MODULE_TYPE= DXE_DRIVER
   VERSION_STRING = 1.0
   ENTRY_POINT= Install8259
@@ -27,8 +27,7 @@
 
 [Packages]
   MdePkg/MdePkg.dec
-  IntelFrameworkPkg/IntelFrameworkPkg.dec
-  PcAtChipsetPkg/PcAtChipsetPkg.dec
+  OvmfPkg/OvmfPkg.dec
 
 [LibraryClasses]
   UefiBootServicesTableLib

[edk2] [RFC PATCH v1 0/8] Duplicate 8259/8254 components in OvmfPkg

[Hao Wu]

This series is also available at:
https://github.com/hwu25/edk2/tree/ovmf_8259_8254_rfcv1


As a sub-task to remove the IntelFrameworkPkg (BZ-1604),

8259InterruptControllerDxe driver (PcAtChipsetPkg)
Legacy8259 protocol (IntelFrameworkPkg)
8254TimerDxe driver (PcAtChipsetPkg)

will be removed in the near future. Meanwhile, OVMF will still require
those components (due to CSM support & HPET emulation stability concern).

Thus, the series will copy the below 8259/8254 components:

A. 8259InterruptControllerDxe driver (PcAtChipsetPkg)
B. Two 8259 related PCDs (PcAtChipsetPkg)
C. Legacy8259 protocol (IntelFrameworkPkg)
D. 8254TimerDxe driver (PcAtChipsetPkg)

in the OvmfPkg to address the above-mentioned issue.


Tests done for the proposed series:

A. OvmfPkg build pass for VS2015 & GCC5 tool chains;
B. Boot to Shell with commands:
  qemu-system-x86_64.exe -pflash \OVMF.fd -debugcon file:boot.log 
-global isa-debugcon.iobase=0x402
  qemu-system-x86_64.exe -machine q35 -pflash \OVMF.fd -debugcon 
file:boot.log -global isa-debugcon.iobase=0x402
C. 'stall X' command under Shell to verify the timer is working properly.


(Please note that there will be a subsequent patch to remove the 8259/8254
components after platforms dropping the dependencies on them.)

Cc: Jordan Justen 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Cc: David Woodhouse 
Cc: Ray Ni 


Hao Wu (8):
  OvmfPkg: Copy 8259InterruptControllerDxe driver from PcAtChipsetPkg
  OvmfPkg: Copy Legacy8259 protocol definitions from IntelFrameworkPkg
  OvmfPkg/OvmfPkg.dec: Add 8259-related PCDs in OVMF DEC file
  OvmfPkg/8259InterruptControllerDxe: Update to make it build for OVMF
  OvmfPkg/AcpiPlatformDxe: Consume the 8259 PCD defined in OvmfPkg
  OvmfPkg: Copy 8254TimerDxe driver from PcAtChipsetPkg
  OvmfPkg/8254TimerDxe: Update to make it build for OVMF
  OvmfPkg: Update DSC/FDF files to consume 8259/8254 drivers in OvmfPkg

 OvmfPkg/OvmfPkg.dec|  29 +-
 OvmfPkg/OvmfPkgIa32.dsc|   6 +-
 OvmfPkg/OvmfPkgIa32X64.dsc |   6 +-
 OvmfPkg/OvmfPkgX64.dsc |   6 +-
 OvmfPkg/OvmfPkgIa32.fdf|   4 +-
 OvmfPkg/OvmfPkgIa32X64.fdf |   4 +-
 OvmfPkg/OvmfPkgX64.fdf |   4 +-
 OvmfPkg/8254TimerDxe/8254Timer.inf |  48 ++
 OvmfPkg/8259InterruptControllerDxe/8259.inf|  51 ++
 OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf|   5 +-
 OvmfPkg/8254TimerDxe/Timer.h   | 191 ++
 OvmfPkg/8259InterruptControllerDxe/8259.h  | 224 +++
 OvmfPkg/Include/Protocol/Legacy8259.h  | 297 +
 OvmfPkg/8254TimerDxe/Timer.c   | 407 +
 OvmfPkg/8259InterruptControllerDxe/8259.c  | 628 

 OvmfPkg/8254TimerDxe/Timer.uni |  22 +
 OvmfPkg/8254TimerDxe/TimerExtra.uni|  20 +
 OvmfPkg/8259InterruptControllerDxe/Legacy8259.uni  |  22 +
 OvmfPkg/8259InterruptControllerDxe/Legacy8259Extra.uni |  20 +
 19 files changed, 1975 insertions(+), 19 deletions(-)
 create mode 100644 OvmfPkg/8254TimerDxe/8254Timer.inf
 create mode 100644 OvmfPkg/8259InterruptControllerDxe/8259.inf
 create mode 100644 OvmfPkg/8254TimerDxe/Timer.h
 create mode 100644 OvmfPkg/8259InterruptControllerDxe/8259.h
 create mode 100644 OvmfPkg/Include/Protocol/Legacy8259.h
 create mode 100644 OvmfPkg/8254TimerDxe/Timer.c
 create mode 100644 OvmfPkg/8259InterruptControllerDxe/8259.c
 create mode 100644 OvmfPkg/8254TimerDxe/Timer.uni
 create mode 100644 OvmfPkg/8254TimerDxe/TimerExtra.uni
 create mode 100644 OvmfPkg/8259InterruptControllerDxe/Legacy8259.uni
 create mode 100644 OvmfPkg/8259InterruptControllerDxe/Legacy8259Extra.uni

-- 
2.12.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [RFC PATCH v1 2/8] OvmfPkg: Copy Legacy8259 protocol definitions from IntelFrameworkPkg

[Hao Wu]

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1496

This commit copies the exact Legacy8259 protocol header file from
IntelFrameworkPkg to OvmfPkg. Also, the protocol GUID definition is
duplicated in the OvmfPkg DEC file.

Cc: Jordan Justen 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Cc: David Woodhouse 
Cc: Ray Ni 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu 
---
 OvmfPkg/OvmfPkg.dec   |   3 +-
 OvmfPkg/Include/Protocol/Legacy8259.h | 297 
 2 files changed, 299 insertions(+), 1 deletion(-)

diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
index e50c6179a2..fb89ebf3ad 100644
--- a/OvmfPkg/OvmfPkg.dec
+++ b/OvmfPkg/OvmfPkg.dec
@@ -1,7 +1,7 @@
 ## @file
 #  EFI/Framework Open Virtual Machine Firmware (OVMF) platform
 #
-#  Copyright (c) 2006 - 2013, Intel Corporation. All rights reserved.
+#  Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
 #
 #  This program and the accompanying materials
 #  are licensed and made available under the terms and conditions of the BSD 
License
@@ -89,6 +89,7 @@
   gXenBusProtocolGuid = {0x3d3ca290, 0xb9a5, 0x11e3, {0xb7, 
0x5d, 0xb8, 0xac, 0x6f, 0x7d, 0x65, 0xe6}}
   gXenIoProtocolGuid  = {0x6efac84f, 0x0ab0, 0x4747, {0x81, 
0xbe, 0x85, 0x55, 0x62, 0x59, 0x04, 0x49}}
   gIoMmuAbsentProtocolGuid= {0xf8775d50, 0x8abd, 0x4adf, {0x92, 
0xac, 0x85, 0x3e, 0x51, 0xf6, 0xc8, 0xdc}}
+  gEfiLegacy8259ProtocolGuid  = {0x38321dba, 0x4fe0, 0x4e17, {0x8a, 
0xec, 0x41, 0x30, 0x55, 0xea, 0xed, 0xc1}}
 
 [PcdsFixedAtBuild]
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvBase|0x0|UINT32|0
diff --git a/OvmfPkg/Include/Protocol/Legacy8259.h 
b/OvmfPkg/Include/Protocol/Legacy8259.h
new file mode 100644
index 00..3f973f6700
--- /dev/null
+++ b/OvmfPkg/Include/Protocol/Legacy8259.h
@@ -0,0 +1,297 @@
+/** @file
+  This protocol abstracts the 8259 interrupt controller. This includes
+  PCI IRQ routing needed to program the PCI Interrupt Line register.
+
+Copyright (c) 2007 - 2018, Intel Corporation. All rights reserved.
+This program and the accompanying materials are licensed and made available 
under
+the terms and conditions of the BSD License that accompanies this distribution.
+The full text of the license may be found at
+http://opensource.org/licenses/bsd-license.php.
+
+THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+  @par Revision Reference:
+  This protocol is defined in Framework for EFI Compatibility Support Module 
spec
+  Version 0.97.
+
+**/
+
+#ifndef _EFI_LEGACY_8259_H_
+#define _EFI_LEGACY_8259_H_
+
+
+#define EFI_LEGACY_8259_PROTOCOL_GUID \
+  { \
+0x38321dba, 0x4fe0, 0x4e17, {0x8a, 0xec, 0x41, 0x30, 0x55, 0xea, 0xed, 
0xc1 } \
+  }
+
+typedef struct _EFI_LEGACY_8259_PROTOCOL EFI_LEGACY_8259_PROTOCOL;
+
+typedef enum {
+  Efi8259Irq0,
+  Efi8259Irq1,
+  Efi8259Irq2,
+  Efi8259Irq3,
+  Efi8259Irq4,
+  Efi8259Irq5,
+  Efi8259Irq6,
+  Efi8259Irq7,
+  Efi8259Irq8,
+  Efi8259Irq9,
+  Efi8259Irq10,
+  Efi8259Irq11,
+  Efi8259Irq12,
+  Efi8259Irq13,
+  Efi8259Irq14,
+  Efi8259Irq15,
+  Efi8259IrqMax
+} EFI_8259_IRQ;
+
+typedef enum {
+  Efi8259LegacyMode,
+  Efi8259ProtectedMode,
+  Efi8259MaxMode
+} EFI_8259_MODE;
+
+/**
+  Get the 8259 interrupt masks for Irq0 - Irq15. A different mask exists for
+  the legacy mode mask and the protected mode mask. The base address for the 
8259
+  is different for legacy and protected mode, so two masks are required.
+
+  @param  This  The protocol instance pointer.
+  @param  MasterBaseThe base vector for the Master PIC in the 8259 
controller.
+  @param  SlaveBase The base vector for the Slave PIC in the 8259 
controller.
+
+  @retval EFI_SUCCESS   The new bases were programmed.
+  @retval EFI_DEVICE_ERROR  A device error occured programming the vector 
bases.
+
+**/
+typedef
+EFI_STATUS
+(EFIAPI *EFI_LEGACY_8259_SET_VECTOR_BASE)(
+  IN EFI_LEGACY_8259_PROTOCOL   *This,
+  IN  UINT8 MasterBase,
+  IN  UINT8 SlaveBase
+  );
+
+/**
+  Get the 8259 interrupt masks for Irq0 - Irq15. A different mask exists for
+  the legacy mode mask and the protected mode mask. The base address for the 
8259
+  is different for legacy and protected mode, so two masks are required.
+
+  @param  This  The protocol instance pointer.
+  @param  LegacyMaskBit 0 is Irq0 - Bit 15 is Irq15.
+  @param  LegacyEdgeLevel   Bit 0 is Irq0 - Bit 15 is Irq15.
+  @param  ProtectedMask Bit 0 is Irq0 - Bit 15 is Irq15.
+  @param  ProtectedEdgeLevelBit 0 is Irq0 - Bit 15 is Irq15.
+
+  @retval EFI_SUCCESS   8259 status returned.
+  @retval EFI_DEVICE_ERROR  Error reading 8259.
+
+**/
+typedef
+EFI_STATUS
+(EFIAPI *EFI_LEGACY_8259_GET_MASK)(
+  IN 

[edk2] [RFC PATCH v1 1/8] OvmfPkg: Copy 8259InterruptControllerDxe driver from PcAtChipsetPkg

[Hao Wu]

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1496

This commit copies the exact 8259InterruptControllerDxe driver from
PcAtChipsetPkg to OvmfPkg.

Cc: Jordan Justen 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Cc: David Woodhouse 
Cc: Ray Ni 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu 
---
 OvmfPkg/8259InterruptControllerDxe/8259.inf|  52 ++
 OvmfPkg/8259InterruptControllerDxe/8259.h  | 226 +++
 OvmfPkg/8259InterruptControllerDxe/8259.c  | 628 

 OvmfPkg/8259InterruptControllerDxe/Legacy8259.uni  |  22 +
 OvmfPkg/8259InterruptControllerDxe/Legacy8259Extra.uni |  20 +
 5 files changed, 948 insertions(+)

diff --git a/OvmfPkg/8259InterruptControllerDxe/8259.inf 
b/OvmfPkg/8259InterruptControllerDxe/8259.inf
new file mode 100644
index 00..1d9be675e3
--- /dev/null
+++ b/OvmfPkg/8259InterruptControllerDxe/8259.inf
@@ -0,0 +1,52 @@
+## @file
+# 8259 Interrupt Controller driver that provides Legacy 8259 protocol.
+#
+# Copyright (c) 2005 - 2018, Intel Corporation. All rights reserved.
+# This program and the accompanying materials
+# are licensed and made available under the terms and conditions of the BSD 
License
+# which accompanies this distribution.  The full text of the license may be 
found at
+# http://opensource.org/licenses/bsd-license.php
+#
+# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+#
+##
+
+[Defines]
+  INF_VERSION= 0x00010005
+  BASE_NAME  = Legacy8259
+  MODULE_UNI_FILE= Legacy8259.uni
+  FILE_GUID  = 79CA4208-BBA1-4a9a-8456-E1E66A81484E
+  MODULE_TYPE= DXE_DRIVER
+  VERSION_STRING = 1.0
+  ENTRY_POINT= Install8259
+
+[Sources]
+  8259.c
+  8259.h
+
+[Packages]
+  MdePkg/MdePkg.dec
+  IntelFrameworkPkg/IntelFrameworkPkg.dec
+  PcAtChipsetPkg/PcAtChipsetPkg.dec
+
+[LibraryClasses]
+  UefiBootServicesTableLib
+  DebugLib
+  UefiDriverEntryPoint
+  IoLib
+  PcdLib
+
+[Protocols]
+  gEfiLegacy8259ProtocolGuid## PRODUCES
+  gEfiPciIoProtocolGuid ## SOMETIMES_CONSUMES
+
+[Pcd]
+  gPcAtChipsetPkgTokenSpaceGuid.Pcd8259LegacyModeMask  ## CONSUMES
+  gPcAtChipsetPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel ## CONSUMES
+
+[Depex]
+  TRUE
+
+[UserExtensions.TianoCore."ExtraFiles"]
+  Legacy8259Extra.uni
diff --git a/OvmfPkg/8259InterruptControllerDxe/8259.h 
b/OvmfPkg/8259InterruptControllerDxe/8259.h
new file mode 100644
index 00..0d4c1e8223
--- /dev/null
+++ b/OvmfPkg/8259InterruptControllerDxe/8259.h
@@ -0,0 +1,226 @@
+/** @file
+  Driver implementing the Tiano Legacy 8259 Protocol
+
+Copyright (c) 2005 - 2009, Intel Corporation. All rights reserved.
+This program and the accompanying materials
+are licensed and made available under the terms and conditions of the BSD 
License
+which accompanies this distribution.  The full text of the license may be 
found at
+http://opensource.org/licenses/bsd-license.php.
+
+THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#ifndef _8259_H__
+#define _8259_H__
+
+#include 
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+// 8259 Hardware definitions
+
+#define LEGACY_MODE_BASE_VECTOR_MASTER0x08
+#define LEGACY_MODE_BASE_VECTOR_SLAVE 0x70
+
+#define PROTECTED_MODE_BASE_VECTOR_MASTER 0x68
+#define PROTECTED_MODE_BASE_VECTOR_SLAVE  0x70
+
+#define LEGACY_8259_CONTROL_REGISTER_MASTER   0x20
+#define LEGACY_8259_MASK_REGISTER_MASTER  0x21
+#define LEGACY_8259_CONTROL_REGISTER_SLAVE0xA0
+#define LEGACY_8259_MASK_REGISTER_SLAVE   0xA1
+#define LEGACY_8259_EDGE_LEVEL_TRIGGERED_REGISTER_MASTER  0x4D0
+#define LEGACY_8259_EDGE_LEVEL_TRIGGERED_REGISTER_SLAVE   0x4D1
+
+#define LEGACY_8259_EOI   0x20
+
+// Protocol Function Prototypes
+
+/**
+  Sets the base address for the 8259 master and slave PICs.
+
+  @param[in]  ThisIndicates the EFI_LEGACY_8259_PROTOCOL instance.
+  @param[in]  MasterBase  Interrupt vectors for IRQ0-IRQ7.
+  @param[in]  SlaveBase   Interrupt vectors for IRQ8-IRQ15.
+
+  @retval  EFI_SUCCESS   The 8259 PIC was programmed successfully.
+  @retval  EFI_DEVICE_ERROR  There was an error while writing to the 8259 PIC.
+
+**/
+EFI_STATUS
+EFIAPI
+Interrupt8259SetVectorBase (
+  IN EFI_LEGACY_8259_PROTOCOL  *This,
+  IN UINT8 MasterBase,
+  IN UINT8 SlaveBase
+  );
+
+/**
+  Gets the current 16-bit real mode and 32-bit protected-mode IRQ masks.
+
+  @param[in]   ThisIndicates the 

[edk2] [RFC PATCH v1 3/8] OvmfPkg/OvmfPkg.dec: Add 8259-related PCDs in OVMF DEC file

[Hao Wu]

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1496

According to the DEC file in PcAtChipsetPkg, this commit adds the two
8259-driver-related PCDs into the OvmfPkg DEC file.

Cc: Jordan Justen 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Cc: David Woodhouse 
Cc: Ray Ni 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu 
---
 OvmfPkg/OvmfPkg.dec | 26 
 1 file changed, 26 insertions(+)

diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
index fb89ebf3ad..cb838422aa 100644
--- a/OvmfPkg/OvmfPkg.dec
+++ b/OvmfPkg/OvmfPkg.dec
@@ -128,6 +128,32 @@
   gUefiOvmfPkgTokenSpaceGuid.PcdGuidedExtractHandlerTableSize|0x0|UINT32|0x1a
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDecompressionScratchEnd|0x0|UINT32|0x1f
 
+  ## Pcd8259LegacyModeMask defines the default mask value for platform. This
+  #  value is determined.
+  #  1) If platform only support pure UEFI, value should be set to 0x or
+  # 0xFFFE; Because only clock interrupt is allowed in legacy mode in pure
+  # UEFI platform.
+  #  2) If platform install CSM and use thunk module:
+  # a) If thunk call provided by CSM binary requires some legacy interrupt
+  #support, the corresponding bit should be opened as 0.
+  #For example, if keyboard interfaces provided CSM binary use legacy
+  #keyboard interrupt in 8259 bit 1, then the value should be set to
+  #0xFFFC.
+  # b) If all thunk call provied by CSM binary do not require legacy
+  #interrupt support, value should be set to 0x or 0xFFFE.
+  #
+  #  The default value of legacy mode mask could be changed by
+  #  EFI_LEGACY_8259_PROTOCOL->SetMask(). But it is rarely need change it
+  #  except some special cases such as when initializing the CSM binary, it
+  #  should be set to 0x to mask all legacy interrupt. Please restore the
+  #  original legacy mask value if changing is made for these special case.
+  gUefiOvmfPkgTokenSpaceGuid.Pcd8259LegacyModeMask|0x|UINT16|0x28
+
+  ## Pcd8259LegacyModeEdgeLevel defines the default edge level for legacy
+  #  mode's interrrupt controller.
+  #  For the corresponding bits, 0 = Edge triggered and 1 = Level triggered.
+  gUefiOvmfPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel|0x|UINT16|0x29
+
 [PcdsDynamic, PcdsDynamicEx]
   gUefiOvmfPkgTokenSpaceGuid.PcdEmuVariableEvent|0|UINT64|2
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashVariablesEnable|FALSE|BOOLEAN|0x10
-- 
2.12.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] UefiCpuPkg/Cpuid: Dump leaf 1FH information correctly

[Dong, Eric]

Hi Ray,

> -Original Message-
> From: Ni, Ray
> Sent: Friday, March 29, 2019 4:42 PM
> To: edk2-devel@lists.01.org
> Cc: Dong, Eric 
> Subject: [PATCH] UefiCpuPkg/Cpuid: Dump leaf 1FH information correctly
> 
> Leaf 1FH is very similar to leaf 0BH. Both return the CPU topology 
> information.
> Leaf 0BH returns 3-level (Package/Core/Thread) CPU topology info.
> Leaf 1FH returns 6-level (Package/Die/Tile/Module/Core/Thread) CPU
> topology info.
> The logic to enumerate the topology info is the same.
> 
> But today's logic to handle 1FH is completely wrong.
> The patch combines them together to fix the 1FH issue.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ray Ni 
> Cc: Eric Dong 
> ---
>  UefiCpuPkg/Application/Cpuid/Cpuid.c | 83 ++--
>  1 file changed, 28 insertions(+), 55 deletions(-)
> 
> diff --git a/UefiCpuPkg/Application/Cpuid/Cpuid.c
> b/UefiCpuPkg/Application/Cpuid/Cpuid.c
> index 67cacf2714..3d242a0cbf 100644
> --- a/UefiCpuPkg/Application/Cpuid/Cpuid.c
> +++ b/UefiCpuPkg/Application/Cpuid/Cpuid.c
> @@ -1,7 +1,7 @@
>  /** @file
>UEFI Application to display CPUID leaf information.
> 
> -  Copyright (c) 2016 - 2018, Intel Corporation. All rights reserved.
> +  Copyright (c) 2016 - 2019, Intel Corporation. All rights
> + reserved.
>This program and the accompanying materials
>are licensed and made available under the terms and conditions of the BSD
> License
>which accompanies this distribution.  The full text of the license may be
> found at @@ -717,36 +717,42 @@
> CpuidArchitecturalPerformanceMonitoring (  **/  VOID
> CpuidExtendedTopology (
> -  VOID
> +  UINT32   LeafFunction
>)
>  {
> -  CPUID_EXTENDED_TOPOLOGY_EAX  Eax;
> -  CPUID_EXTENDED_TOPOLOGY_EBX  Ebx;
> -  CPUID_EXTENDED_TOPOLOGY_ECX  Ecx;
> -  UINT32   Edx;
> -  UINT32   LevelNumber;
> +  CPUID_V2_EXTENDED_TOPOLOGY_ENUMERATION_EAX  Eax;
> + CPUID_V2_EXTENDED_TOPOLOGY_ENUMERATION_EBX  Ebx;
> + CPUID_V2_EXTENDED_TOPOLOGY_ENUMERATION_ECX  Ecx;
> +  UINT32  Edx;
> +  UINT32  LevelNumber;
> 
> -  if (CPUID_EXTENDED_TOPOLOGY > gMaximumBasicFunction) {
> +  if (LeafFunction > gMaximumBasicFunction) {
> +return;
> +  }
> +  if ((LeafFunction != CPUID_EXTENDED_TOPOLOGY) && (LeafFunction !=
> + CPUID_V2_EXTENDED_TOPOLOGY_ENUMERATION)) {
>  return;
>}
> 
>LevelNumber = 0;
> -  do {
> +  for (LevelNumber = 0; ; LevelNumber++) {
>  AsmCpuidEx (
> -  CPUID_EXTENDED_TOPOLOGY, LevelNumber,
> +  LeafFunction, LevelNumber,
>, , , 
>);
> -if (Eax.Bits.ApicIdShift != 0) {
> -  Print (L"CPUID_EXTENDED_TOPOLOGY (Leaf %08x, Sub-Leaf %08x)\n",
> CPUID_EXTENDED_TOPOLOGY, LevelNumber);
> -  Print (L"  EAX:%08x  EBX:%08x  ECX:%08x  EDX:%08x\n", Eax.Uint32,
> Ebx.Uint32, Ecx.Uint32, Edx);
> -  PRINT_BIT_FIELD (Eax, ApicIdShift);
> -  PRINT_BIT_FIELD (Ebx, LogicalProcessors);
> -  PRINT_BIT_FIELD (Ecx, LevelNumber);
> -  PRINT_BIT_FIELD (Ecx, LevelType);
> -  PRINT_VALUE (Edx, x2APIC_ID);
> +if (Ecx.Bits.LevelType ==
> CPUID_V2_EXTENDED_TOPOLOGY_ENUMERATION_LEVEL_TYPE_INVALID) {
> +  break;
>  }
> -LevelNumber++;
> -  } while (Eax.Bits.ApicIdShift != 0);
> +Print (
> +  L"%a (Leaf %08x, Sub-Leaf %08x)\n",
> +  LeafFunction == CPUID_EXTENDED_TOPOLOGY ?
> "CPUID_EXTENDED_TOPOLOGY" :
> "CPUID_V2_EXTENDED_TOPOLOGY_ENUMERATION-2",
> +  LeafFunction, LevelNumber);
> +Print (L"  EAX:%08x  EBX:%08x  ECX:%08x  EDX:%08x\n", Eax.Uint32,
> Ebx.Uint32, Ecx.Uint32, Edx);
> +PRINT_BIT_FIELD (Eax, BitsNum);
> +PRINT_BIT_FIELD (Ebx, ProcessorsNum);
> +PRINT_BIT_FIELD (Ecx, LevelNum);
> +PRINT_BIT_FIELD (Ecx, LevelType);
> +PRINT_VALUE (Edx, x2APIC_ID);

The name for above fields are different in CPUID_EXTENDED_TOPOLOGY and 
CPUID_V2_EXTENDED_TOPOLOGY_ENUMERATION,
So I think above print are not correct for CPUID_EXTENDED_TOPOLOGY, right?

Thanks,
Eric

> +  }
>  }
> 
>  /**
> @@ -1385,39 +1391,6 @@ CpuidDeterministicAddressTranslationParameters
> (
>PRINT_BIT_FIELD (Edx, MaximumNum);
>  }
> 
> -/**
> -  Display CPUID_V2_EXTENDED_TOPOLOGY_ENUMERATION main leaf and
> sub-leafs.
> -
> -**/
> -VOID
> -CpuidV2ExtendedTopologyEnumeration (
> -  VOID
> -  )
> -{
> -  CPUID_V2_EXTENDED_TOPOLOGY_ENUMERATION_EAX  Eax;
> -  CPUID_V2_EXTENDED_TOPOLOGY_ENUMERATION_EBX  Ebx;
> -  CPUID_V2_EXTENDED_TOPOLOGY_ENUMERATION_ECX  Ecx;
> -  UINT32  Edx;
> -
> -  if (CPUID_V2_EXTENDED_TOPOLOGY_ENUMERATION >
> gMaximumBasicFunction) {
> -return;
> -  }
> -
> -  AsmCpuidEx (
> -CPUID_V2_EXTENDED_TOPOLOGY_ENUMERATION,
> -CPUID_V2_EXTENDED_TOPOLOGY_ENUMERATION_MAIN_LEAF,
> -, , , 
> -);
> -  Print (L"CPUID_V2_EXTENDED_TOPOLOGY_ENUMERATION (Leaf %08x,
> Sub-Leaf %08x)\n", 

[edk2] [PATCH] SourceLevelDebugPkg/DebugAgent: Remove AsmFuncs.S in INF

[shenglei]

AsmFuncs.S is removed at c7d22535f7dc90b8fef70153ef98549228569680.
And also it should be removed in SecPeiDebugAgentLib.inf and
SmmDebugAgentLib.inf.

Cc: Hao Wu 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Shenglei Zhang 
---
 SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgentLib.inf | 2 --
 SourceLevelDebugPkg/Library/DebugAgent/SmmDebugAgentLib.inf| 2 --
 2 files changed, 4 deletions(-)

diff --git a/SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgentLib.inf 
b/SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgentLib.inf
index 03ebbb6e74..8b81795d96 100644
--- a/SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgentLib.inf
+++ b/SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgentLib.inf
@@ -39,14 +39,12 @@
   DebugAgentCommon/DebugMp.h
 
 [Sources.Ia32]
-  DebugAgentCommon/Ia32/AsmFuncs.S
   DebugAgentCommon/Ia32/AsmFuncs.nasm
   DebugAgentCommon/Ia32/ArchDebugSupport.h
   DebugAgentCommon/Ia32/ArchDebugSupport.c
   DebugAgentCommon/Ia32/DebugException.h
 
 [Sources.X64]
-  DebugAgentCommon/X64/AsmFuncs.S
   DebugAgentCommon/X64/AsmFuncs.nasm
   DebugAgentCommon/X64/ArchDebugSupport.h
   DebugAgentCommon/X64/ArchDebugSupport.c
diff --git a/SourceLevelDebugPkg/Library/DebugAgent/SmmDebugAgentLib.inf 
b/SourceLevelDebugPkg/Library/DebugAgent/SmmDebugAgentLib.inf
index 08ed1777be..f1b32daab3 100644
--- a/SourceLevelDebugPkg/Library/DebugAgent/SmmDebugAgentLib.inf
+++ b/SourceLevelDebugPkg/Library/DebugAgent/SmmDebugAgentLib.inf
@@ -39,14 +39,12 @@
   DebugAgentCommon/DebugMp.h
 
 [Sources.Ia32]
-  DebugAgentCommon/Ia32/AsmFuncs.S
   DebugAgentCommon/Ia32/AsmFuncs.nasm
   DebugAgentCommon/Ia32/ArchDebugSupport.h
   DebugAgentCommon/Ia32/ArchDebugSupport.c
   DebugAgentCommon/Ia32/DebugException.h
 
 [Sources.X64]
-  DebugAgentCommon/X64/AsmFuncs.S
   DebugAgentCommon/X64/AsmFuncs.nasm
   DebugAgentCommon/X64/ArchDebugSupport.h
   DebugAgentCommon/X64/ArchDebugSupport.c
-- 
2.18.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel