Re: [edk2-devel] [edk2] [edk2-announce] ATTN: List Transition Begins Today
Hi Stephano, Excellent news, thanks. Just to get the information inline in this thread: the new list address is de...@edk2.groups.io. Regards, Leif On Wed, Apr 03, 2019 at 10:59:31AM -0500, stephano wrote: > 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 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#42): https://edk2.groups.io/g/devel/message/42 Mute This Topic: https://groups.io/mt/30894773/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2] 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-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\gop20
Re: [edk2] aarch64-linux-gnu-gcc.exe: error due to loss ‘/’in code path in in Jenkins server
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
Re: [edk2] [RFC] Plan to delete ShellBinPkg from edk2/master
Hi Laszlo, On Tue, Apr 02, 2019 at 10:49:16AM +0200, Laszlo Ersek wrote: > 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. Agreed. However, I am not sure that accurately describes what we have today. > 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 think this sounds like an exellent improvement. When I saw the patch, I did immediately think maybe I should start including them in my Linaro releases. But if we could automate a build of binaries for all supported architectures, and have a place to publish them, that would be much better. Best Regards, Leif > 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
Re: [edk2] [PATCH edk2-non-osi] Platform/DeveloperBox: add binary build of TF-A + standalone MM varstore
On Fri, Mar 29, 2019 at 10:52:41AM +0100, Ard Biesheuvel wrote: > On Fri, 29 Mar 2019 at 09:57, Leif Lindholm wrote: > > > > On Fri, Mar 29, 2019 at 08:46:12AM +0100, Ard Biesheuvel wrote: > > > Provide a prebuilt binary of the standalone MM payload containing the > > > UEFI authenticated variable store drivers. These are built from EDK2 > > > components, but the resulting image needs to be wrapped in a FIP > > > container and built into the secure world TF-A image. > > > > > > TF-A commit: e86e202c2e4e > > > edk2 commit: 8028f0303218 > > > edk2-platforms commit: 05fdad573966 > > > > > > Contributed-under: TianoCore Contribution Agreement 1.1 > > > Signed-off-by: Ard Biesheuvel > > > > Reviewed-by: Leif Lindholm > > > > Turns out I need to respin this based on 0a32c15d2172 (just pushed > into edk2-platforms). Right. Well, the reviewed-by stands, as long as the hash gets updated. / Leif ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-non-osi] Platform/DeveloperBox: add binary build of TF-A + standalone MM varstore
On Fri, Mar 29, 2019 at 08:46:12AM +0100, Ard Biesheuvel wrote: > Provide a prebuilt binary of the standalone MM payload containing the > UEFI authenticated variable store drivers. These are built from EDK2 > components, but the resulting image needs to be wrapped in a FIP > container and built into the secure world TF-A image. > > TF-A commit: e86e202c2e4e > edk2 commit: 8028f0303218 > edk2-platforms commit: 05fdad573966 > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ard Biesheuvel Reviewed-by: Leif Lindholm > --- > Platform/Socionext/DeveloperBox/fip_all_arm_tf_mm.bin | Bin 0 -> 374776 bytes > 1 file changed, 0 insertions(+), 0 deletions(-) > > diff --git a/Platform/Socionext/DeveloperBox/fip_all_arm_tf_mm.bin > b/Platform/Socionext/DeveloperBox/fip_all_arm_tf_mm.bin > new file mode 100644 > index ..eaae94874d4d > Binary files /dev/null and > b/Platform/Socionext/DeveloperBox/fip_all_arm_tf_mm.bin differ > -- > 2.20.1 > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-platforms 2/2] Platform/Socionext/DeveloperBox: align with upstream StandaloneMmPkg changes
On Fri, Mar 29, 2019 at 08:32:31AM +0100, Ard Biesheuvel wrote:
> On Fri, 8 Mar 2019 at 16:31, Ard Biesheuvel wrote:
> >
> > Bring DeveloperBox in line with EDK2 core changes to StandaloneMmPkg:
> > - switch from BaseExtractGuidedSectionLib to PrePiExtractGuidedSectionLib
> > - include a NULL library class resolution for VariableMmDependency
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Ard Biesheuvel
>
> Leif,
>
> I'd like to merge this today if you don't have any objections.
None - that was implied in
https://lists.01.org/pipermail/edk2-devel/2019-March/038167.html
(There wasn't a 0/2 to put a "for series" on.)
/
Leif
> > ---
> > Platform/Socionext/DeveloperBox/DeveloperBox.dsc | 5 -
> > Platform/Socionext/DeveloperBox/DeveloperBoxMm.dsc | 7 +++
> > 2 files changed, 7 insertions(+), 5 deletions(-)
> >
> > diff --git a/Platform/Socionext/DeveloperBox/DeveloperBox.dsc
> > b/Platform/Socionext/DeveloperBox/DeveloperBox.dsc
> > index 31afc4aac3c4..39077ab5ee79 100644
> > --- a/Platform/Socionext/DeveloperBox/DeveloperBox.dsc
> > +++ b/Platform/Socionext/DeveloperBox/DeveloperBox.dsc
> > @@ -293,7 +293,10 @@
> >VarCheckLib|MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf
> >}
> > !else
> > - ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.inf
> > + ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.inf {
> > +
> > +
> > NULL|StandaloneMmPkg/Library/VariableMmDependency/VariableMmDependency.inf
> > + }
> >MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.inf
> >
> > SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDxe.inf
> > !endif
> > diff --git a/Platform/Socionext/DeveloperBox/DeveloperBoxMm.dsc
> > b/Platform/Socionext/DeveloperBox/DeveloperBoxMm.dsc
> > index 55c5fbb7350d..141b175047b2 100644
> > --- a/Platform/Socionext/DeveloperBox/DeveloperBoxMm.dsc
> > +++ b/Platform/Socionext/DeveloperBox/DeveloperBoxMm.dsc
> > @@ -68,9 +68,6 @@
> > [PcdsFixedAtBuild]
> >gEfiMdeModulePkgTokenSpaceGuid.PcdSerialRegisterBase|0x5104
> >
> > -[PcdsPatchableInModule]
> > - gEfiMdePkgTokenSpaceGuid.PcdGuidedExtractHandlerTableAddress|0x0
> > -
> >
> >
> > #
> > # Components Section - list of all EDK II Modules needed by this Platform
> > @@ -82,8 +79,10 @@
> >#
> >StandaloneMmPkg/Core/StandaloneMmCore.inf {
> >
> > -
> > ExtractGuidedSectionLib|MdePkg/Library/BaseExtractGuidedSectionLib/BaseExtractGuidedSectionLib.inf
> > +
> > ExtractGuidedSectionLib|EmbeddedPkg/Library/PrePiExtractGuidedSectionLib/PrePiExtractGuidedSectionLib.inf
> >
> > NULL|MdeModulePkg/Library/LzmaCustomDecompressLib/LzmaCustomDecompressLib.inf
> > +
> > + gEfiMdePkgTokenSpaceGuid.PcdMaximumGuidedExtractHandler|0x2
> >}
> >
> >StandaloneMmPkg/Drivers/StandaloneMmCpu/AArch64/StandaloneMmCpu.inf
> > --
> > 2.20.1
> >
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH edk2-platforms] Platform/Hisilicon: update D06 system firmware description
Since the D06 port now depends on updated IMP firmware to function
properly, there needs to be a one-way upgrade path. Upgrade to the
current state of things must happen via .hpm. Subsequent capsule updates
cannot be permitted to go below this version.
So update the firmware descriptor to Version: 3 and
LowestSupportedFirmwareVersion: 3.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Leif Lindholm
---
Ming: I would also be cherry-picking this patch into RPF 19.03.
Platform/Hisilicon/D06/Drivers/SystemFirmwareDescriptor/SystemFirmwareDescriptor.aslc
| 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git
a/Platform/Hisilicon/D06/Drivers/SystemFirmwareDescriptor/SystemFirmwareDescriptor.aslc
b/Platform/Hisilicon/D06/Drivers/SystemFirmwareDescriptor/SystemFirmwareDescriptor.aslc
index 36175338dd..1287dfd834 100644
---
a/Platform/Hisilicon/D06/Drivers/SystemFirmwareDescriptor/SystemFirmwareDescriptor.aslc
+++
b/Platform/Hisilicon/D06/Drivers/SystemFirmwareDescriptor/SystemFirmwareDescriptor.aslc
@@ -22,9 +22,9 @@
#define PACKAGE_VERSION 0x
#define PACKAGE_VERSION_STRING L"Unknown"
-#define CURRENT_FIRMWARE_VERSION0x0002
-#define CURRENT_FIRMWARE_VERSION_STRING L"0x0002"
-#define LOWEST_SUPPORTED_FIRMWARE_VERSION 0x0001
+#define CURRENT_FIRMWARE_VERSION0x0003
+#define CURRENT_FIRMWARE_VERSION_STRING L"0x0003"
+#define LOWEST_SUPPORTED_FIRMWARE_VERSION 0x0003
#define IMAGE_IDSIGNATURE_64('H','W','A', 'R',
'M', '_', 'F', 'd')
#define IMAGE_ID_STRING L"ARMPlatformFd"
--
2.11.0
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [RFC PATCH] MdeModulePkg: add LockBoxNullLib for !IA32/X64 in .dsc
On Mon, Mar 25, 2019 at 02:17:05AM +, Wu, Hao A wrote: > > My original version is my preferred way of addressing the immediate > > problem though, mainly to keep the separate .EBC section. > > Got it. > Do you want me to help to push the patch? If you could, that would be appreciated. Best Regards, Leif ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-platforms v4 0/4] Platform/ARM: Platform support for Dynamic Tables Framework
On Tue, Mar 26, 2019 at 03:23:15PM +, Sami Mujawar wrote: > Dynamic Tables Framework aims to reduce the amount of effort > required for porting firmware to new platforms by simplifying > the generation of firmware tables based on hardware description > provided by a platform specific component. > > The Dynamic Tables Framework core queries the platform specific > component to retrieve the required hardware information for > generating standardised firmware tables at run-time. > > The platform specific component responsible for collating the > hardware information is called the Configuration Manager. > > This patch series introduce the Configuration Manager that > provides the hardware description to Dynamic Tables Framework. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Sami Mujawar > > The changes can be seen at: > https://github.com/samimujawar/edk2-platforms/tree/365_dynamic_tables_framework_v4 For the series: Reviewed-by: Leif Lindholm Pushed as 89f6901df0..8cb8080438. / Leif > This v4 patch series incorporates: > * Updates based on review comments to sort #include files and .inf sections > in alphabetical order. > > Patches updated in this series are: > - Platform/ARM: Configuration Manager for Juno > - Platform/ARM: Configuration Manager for FVP > > The corresponding edk2 code changes can be seen at: > https://github.com/samimujawar/edk2/tree/365_dynamic_tables_framework_v2 > > Sami Mujawar (4): > Platform/ARM: Configuration Manager for Juno > Platform/ARM: Dynamic Tables support for Juno > Platform/ARM: Configuration Manager for FVP > Platform/ARM: Dynamic Tables support for FVP > > Platform/ARM/JunoPkg/ArmJuno.dsc > | 12 +- > Platform/ARM/JunoPkg/ArmJuno.fdf > | 12 + > Platform/ARM/JunoPkg/ConfigurationManager/ConfigurationManager.dsc.inc > | 29 + > > Platform/ARM/JunoPkg/ConfigurationManager/ConfigurationManagerDxe/ConfigurationManager.c > | 750 > > Platform/ARM/JunoPkg/ConfigurationManager/ConfigurationManagerDxe/ConfigurationManager.h > | 179 + > > Platform/ARM/JunoPkg/ConfigurationManager/ConfigurationManagerDxe/ConfigurationManagerDxe.inf > | 87 +++ > Platform/ARM/JunoPkg/ConfigurationManager/ConfigurationManagerDxe/Platform.h > | 99 +++ > Platform/ARM/JunoPkg/ConfigurationManager/PlatformASLTablesLib/Dsdt.asl > | 276 +++ > > Platform/ARM/JunoPkg/ConfigurationManager/PlatformASLTablesLib/PlatformASLTablesLib.inf >| 45 ++ > > Platform/ARM/JunoPkg/ConfigurationManager/PlatformASLTablesLib/SsdtJunoUsb.asl > | 123 > Platform/ARM/JunoPkg/ConfigurationManager/PlatformASLTablesLib/SsdtPci.asl > | 201 ++ > Platform/ARM/JunoPkg/ConfigurationManager/PlatformASLTablesLib/SsdtUart.asl > | 48 ++ > Platform/ARM/JunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c > | 9 +- > Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc > | 15 + > Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.fdf > | 16 +- > Platform/ARM/VExpressPkg/ConfigurationManager/ConfigurationManager.dsc.inc > | 31 + > > Platform/ARM/VExpressPkg/ConfigurationManager/ConfigurationManagerDxe/ConfigurationManager.c > | 682 ++ > > Platform/ARM/VExpressPkg/ConfigurationManager/ConfigurationManagerDxe/ConfigurationManager.h > | 181 + > > Platform/ARM/VExpressPkg/ConfigurationManager/ConfigurationManagerDxe/ConfigurationManagerDxe.inf > | 80 +++ > > Platform/ARM/VExpressPkg/ConfigurationManager/ConfigurationManagerDxe/Platform.h > | 99 +++ > Platform/ARM/VExpressPkg/ConfigurationManager/PlatformASLTablesLib/Dsdt.asl > | 73 ++ > > Platform/ARM/VExpressPkg/ConfigurationManager/PlatformASLTablesLib/PlatformASLTablesLib.inf >| 35 + > 22 files changed, 3077 insertions(+), 5 deletions(-) > create mode 100644 > Platform/ARM/JunoPkg/ConfigurationManager/ConfigurationManager.dsc.inc > create mode 100644 > Platform/ARM/JunoPkg/ConfigurationManager/ConfigurationManagerDxe/ConfigurationManager.c > create mode 100644 > Platform/ARM/JunoPkg/ConfigurationManager/ConfigurationManagerDxe/ConfigurationManager.h > create mode 100644 > Platform/ARM/JunoPkg/ConfigurationMana
Re: [edk2] [PATCH edk2-platforms v1 0/4] Platform/ARM: Updates corresponding to Dynamic Tables Framework changes
On Thu, Feb 21, 2019 at 06:15:21PM +, Sami Mujawar wrote: > The Dynamic tables framework has been updated to incorporated a series of > updates namely: > * Resolving DEPEX order for modules. > * Removing GIC Distributor ID > > This patch series implement the corresponding changes required in the platform > Configuration Manager. > > Note: This patch series is dependent on the patch series: > https://lists.01.org/pipermail/edk2-devel/2019-January/035611.html Ah, right, so these changes will have to be pushed simultaneously with the edk2 ones. In that case: Reviewed-by: Leif Lindholm And feel free to push the changes to edk2-platforms for this set yourself. > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Sami Mujawar > > The changes can be seen at: > https://github.com/samimujawar/edk2-platforms/tree/473_dynamic_tables_framework_v1 > > The corresponding edk2 code changes can be seen at: > https://github.com/samimujawar/edk2/tree/473_dynamic_tables_framework_v1 > > Sami Mujawar (4): > Platform/ARM: Juno: Configuration Manager depex > Platform/ARM: FVP: Configuration Manager depex > Platform/ARM: FVP: Config Mgr remove GICD ID > Platform/ARM: Juno: Config Mgr remove GICD ID > > > Platform/ARM/JunoPkg/ConfigurationManager/ConfigurationManagerDxe/ConfigurationManager.c > | 1 - > > Platform/ARM/JunoPkg/ConfigurationManager/ConfigurationManagerDxe/ConfigurationManagerDxe.inf > | 4 ++-- > > Platform/ARM/VExpressPkg/ConfigurationManager/ConfigurationManagerDxe/ConfigurationManager.c > | 1 - > > Platform/ARM/VExpressPkg/ConfigurationManager/ConfigurationManagerDxe/ConfigurationManagerDxe.inf > | 4 ++-- > 4 files changed, 4 insertions(+), 6 deletions(-) > > -- > 'Guid(CE165669-3EF3-493F-B85D-6190EE5B9759)' > > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v1 1/2] DynamicTablesPkg: Fix line endings in dsc file
On Tue, Mar 26, 2019 at 06:44:38PM +, Sami Mujawar wrote: > Changed the line endings to DOS line endings for > DynamicTablesPkg/DynamicTablesPkg.dsc Ah, yes, good old SMTP stripping CR. I have a stupid script in my uefi-tools repo that I use to line-convert patches from mailing lists. https://git.linaro.org/uefi/uefi-tools.git/tree/edk2-to-git-am.sh I'll remember to put any future sets to you on a branch, as you helpfully do for me. Reviewed-by: Leif Lindholm > Cc: Alexei Fedorov > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Sami Mujawar > --- > DynamicTablesPkg/DynamicTablesPkg.dsc | 88 ++-- > 1 file changed, 44 insertions(+), 44 deletions(-) > > diff --git a/DynamicTablesPkg/DynamicTablesPkg.dsc > b/DynamicTablesPkg/DynamicTablesPkg.dsc > index > f71120c2d359d715b8046b170025fe530387b6a8..a66bba976ccdf5ced9213eb464f3ac8f6fd52da4 > 100644 > --- a/DynamicTablesPkg/DynamicTablesPkg.dsc > +++ b/DynamicTablesPkg/DynamicTablesPkg.dsc > @@ -1,44 +1,44 @@ > -## @file > -# Dsc file for Dynamic Tables Framework. > -# > -# Copyright (c) 2019, Linaro Limited. 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] > - PLATFORM_NAME = DynamicTables > - PLATFORM_GUID = f39096a0-7a0a-442a-9413-cf584ef80cbb > - PLATFORM_VERSION = 0.1 > - DSC_SPECIFICATION = 0x0001001a > - OUTPUT_DIRECTORY = Build/DynamicTables > - SUPPORTED_ARCHITECTURES= ARM|AARCH64 > - BUILD_TARGETS = DEBUG|RELEASE|NOOPT > - SKUID_IDENTIFIER = DEFAULT > - > -!include DynamicTables.dsc.inc > - > -[LibraryClasses] > - BaseLib|MdePkg/Library/BaseLib/BaseLib.inf > - BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf > - DebugLib|MdePkg/Library/BaseDebugLibNull/BaseDebugLibNull.inf > - IoLib|MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf > - > MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf > - PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf > - PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf > - > UefiBootServicesTableLib|MdePkg/Library/UefiBootServicesTableLib/UefiBootServicesTableLib.inf > - > UefiDriverEntryPoint|MdePkg/Library/UefiDriverEntryPoint/UefiDriverEntryPoint.inf > - > -[LibraryClasses.ARM, LibraryClasses.AARCH64] > - PL011UartLib|ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.inf > - > -[Components.common] > - DynamicTablesPkg/Library/Common/TableHelperLib/TableHelperLib.inf > +## @file > +# Dsc file for Dynamic Tables Framework. > +# > +# Copyright (c) 2019, Linaro Limited. 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] > + PLATFORM_NAME = DynamicTables > + PLATFORM_GUID = f39096a0-7a0a-442a-9413-cf584ef80cbb > + PLATFORM_VERSION = 0.1 > + DSC_SPECIFICATION = 0x0001001a > + OUTPUT_DIRECTORY = Build/DynamicTables > + SUPPORTED_ARCHITECTURES= ARM|AARCH64 > + BUILD_TARGETS = DEBUG|RELEASE|NOOPT > + SKUID_IDENTIFIER = DEFAULT > + > +!include DynamicTables.dsc.inc > + > +[LibraryClasses] > + BaseLib|MdePkg/Library/BaseLib/BaseLib.inf > + BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf > + DebugLib|MdePkg/Library/BaseDebugLibNull/BaseDebugLibNull.inf > + IoLib|MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf > + > MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf > + PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf > + PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf > + > UefiBootServicesTableLib|MdePkg/Library/UefiBootServicesTableLib/Uefi
Re: [edk2] [PATCH V2] Change EDK II to BSD+Patent License
On Tue, Mar 26, 2019 at 06:21:43PM +, Kinney, Michael D wrote: > Hi Leif, > > Thanks for the reviews. Responses below. > > Mike > > > -Original Message- > > From: Leif Lindholm [mailto:leif.lindh...@linaro.org] > > Sent: Tuesday, March 26, 2019 11:09 AM > > To: Kinney, Michael D > > Cc: edk2-devel@lists.01.org > > Subject: Re: [edk2] [PATCH V2] Change EDK II to > > BSD+Patent License > > > > Hi Mike, > > > > First of all - now the March table tag was made (and I'm > > back from > > holiday), I had planned to do the move of BeagleBoardPkg > > and > > Omap35xxPkg to edk2-platforms. > > > > Would you prefer me to put that on hold, or should we > > drop those > > changes from this set and worry about those if/when we > > get around to > > relicensing edk2-platforms too? > > I do not have a strong opinion on when those packages > move to edk2-platforms. > > I am holding off on other package moves I am involved in > until after the license change. > > > > > For the changes to ArmPkg, ArmPlatformPkg, EmbeddedPkg(, > > BeagleBoardPkg, Omap35xxPkg): > > Reviewed-by: Leif Lindholm > > > > Thank you! > > > For the changes to edk2: > > License.txt - could the commit message describe where > > the new text is > > from (as an implicit way of explaining why the > > layout/bulleting has changed in the portion > > that is > > otherwise content-wise identical)? > > I do not follow what you want updated here. Which > commit and what would you like the message changed to? Right, I could have been more clear. The patch in question is "edk2: Change License.txt from 2-Clause BSD to BSD+Patent" I'm referring to the fact that a diff between https://opensource.org/licenses/BSD-2-Clause and https://opensource.org/licenses/BSDplusPatent shows substantially less than this patch does - for layout and bulleting format reasons. So, as a clarification regarding why the diff appears greater than the actual difference between the licenses (which would simply be an insertion), you could note in the commit message that the . (An alternative course of action would be to insert a preceding patch aligning the layout and bulleting format of License.txt with the opensource.org version.) > > - (I'm sorry, I should just keep quiet, > > but...) > > The copyright lines at the top of the > > Licence.txt file > > have been bugging me since day 1. Can we > > drop them? > > Clearly none of these organisations hold > > copyright over > > either the old or the new license. > > > > The copyrights at the top of that file were inherited > from the packages when License.txt used to be in each > package. If you think it is appropriate to remove them > I am happy to do that as part of this series. Does the > same comment apply to License.txt in OvmfPkg? I think I could use input from Laszlo here, but looking at other BSD-licensed projects, they tend to have the LICENSE/COPYING/whatever file contain a row referring to the project/foundation. Which I guess in our case would be TianoCore. Some also add "and contributors" to that one line. (If including the statement in the top-level file is necessary, "TianoCore and contributors" certainly sounds the most appropriate to me.) The way top-level Licence.txt has been used so far has ... given the impression it was intended to be used as shorthand for identifying all copyrights held within the project (and their dates). Which I don't think is actually very useful. > > I'll just add that my wording for the Signed-off-by was > > just a > > meant as a starting point and I'd be happy to see it > > improved. > > Please let me know if you have any suggestions here. Well, I just feel it could do with some review. It's not *wrong* or anything. Regards, Leif > > > > But from my end, all edk2: patches other than > > "edk2: Change License.txt from 2-Clause BSD to > > BSD+Patent": > > Reviewed-by: Leif Lindholm > > > > / > > Leif > > > > On Sat, Mar 23, 2019 at 02:25:15AM +, 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 r
Re: [edk2] [PATCH V2] Change EDK II to BSD+Patent License
Hi Mike, First of all - now the March table tag was made (and I'm back from holiday), I had planned to do the move of BeagleBoardPkg and Omap35xxPkg to edk2-platforms. Would you prefer me to put that on hold, or should we drop those changes from this set and worry about those if/when we get around to relicensing edk2-platforms too? For the changes to ArmPkg, ArmPlatformPkg, EmbeddedPkg(, BeagleBoardPkg, Omap35xxPkg): Reviewed-by: Leif Lindholm For the changes to edk2: License.txt - could the commit message describe where the new text is from (as an implicit way of explaining why the layout/bulleting has changed in the portion that is otherwise content-wise identical)? - (I'm sorry, I should just keep quiet, but...) The copyright lines at the top of the Licence.txt file have been bugging me since day 1. Can we drop them? Clearly none of these organisations hold copyright over either the old or the new license. I'll just add that my wording for the Signed-off-by was just a meant as a starting point and I'd be happy to see it improved. But from my end, all edk2: patches other than "edk2: Change License.txt from 2-Clause BSD to BSD+Patent": Reviewed-by: Leif Lindholm / Leif On Sat, Mar 23, 2019 at 02:25:15AM +, 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. > > 2a7d2c56bc edk2: Remove Contributions.txt and update Readme.md > f9d59ccdc5 OvmfPkg: Change License.txt from 2-Clause BSD to BSD+Patent > ce3fbf929e StdLibPrivateInternalFiles: Replace BSD License with BSD+Patent > License > aa8a3692c7 StdLib: Replace BSD License with BSD+Patent License > 2dfbe1e1ee AppPkg: Replace BSD License with BSD+Patent License > b2161f6dd8 Vlv2TbltDevicePkg: Replace BSD License with BSD+Patent License > 3688c33755 Vlv2DeviceRefCodePkg: Replace BSD License with BSD+Patent License > 8170308c98 UefiCpuPkg: Replace BSD License with BSD+Patent License > 4b68832cdc StandaloneMmPkg: Replace BSD License with BSD+Patent License > 327dc18122 SourceLevelDebugPkg: Replace BSD License with BSD+Patent License > 6c4c506a5e SignedCapsulePkg: Replace BSD License with BSD+Patent License > 2fdd514aff ShellPkg: Replace BSD
Re: [edk2] [PATCH V4 08/17] ArmPkg/SemiHostingDebugLib: Add new APIs
Hi Zhichao,
Apologies for delay in responding, due to holiday and stuff.
On the whole this looks fine (one comment below), but I don't actually
have any platform on which to test this.
Ard: maybe it's time to retire this component?
On Thu, Mar 21, 2019 at 10:04:50PM +0800, Zhichao Gao wrote:
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1395
>
> Add new APIs' implementation (DebugVPrint, DebugBPrint)
> in the DebugLib instance. These APIs would expose print
> routines with VaList parameter and BaseList parameter.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Zhichao Gao
> Cc: Leif Lindholm
> Cc: Ard Biesheuvel
> Cc: Liming Gao
> Cc: Sean Brogan
> Cc: Michael Turner
> Cc: Bret Barkelew
> ---
> ArmPkg/Library/SemiHostingDebugLib/DebugLib.c | 106
> --
> 1 file changed, 101 insertions(+), 5 deletions(-)
>
> diff --git a/ArmPkg/Library/SemiHostingDebugLib/DebugLib.c
> b/ArmPkg/Library/SemiHostingDebugLib/DebugLib.c
> index ec03edb774..a368dd43b8 100644
> --- a/ArmPkg/Library/SemiHostingDebugLib/DebugLib.c
> +++ b/ArmPkg/Library/SemiHostingDebugLib/DebugLib.c
> @@ -1,7 +1,7 @@
> /** @file
>UEFI Debug Library that uses PrintLib to send messages to STDERR.
>
> - Copyright (c) 2006 - 2007, Intel Corporation. All rights reserved.
> + Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
>Portions copyright (c) 2008 - 2009, Apple Inc. All rights reserved.
>This program and the accompanying materials
>are licensed and made available under the terms and conditions of the BSD
> License
> @@ -27,6 +27,12 @@
> //
> #define MAX_DEBUG_MESSAGE_LENGTH 0x100
>
> +//
> +// VA_LIST can not initialize to NULL for all compiler, so we use this to
> +// indicate a null VA_LIST
> +//
> +VA_LIST mVaListNull;
I would prefer if this was marked STATIC.
If you feel strongly otherwise, leave it as is.
Either way:
Reviewed-by: Leif Lindholm
/
Leif
> +
> /**
>
>Prints a debug message to the debug output device if the specified error
> level is enabled.
> @@ -48,9 +54,41 @@ DebugPrint (
>IN CONST CHAR8 *Format,
>...
>)
> +{
> + VA_LIST Marker;
> +
> + VA_START (Marker, Format);
> + DebugVPrint (ErrorLevel, Format, Marker);
> + VA_END (Marker);
> +}
> +
> +
> +/**
> + Prints a debug message to the debug output device if the specified
> + error level is enabled base on Null-terminated format string and a
> + VA_LIST argument list or a BASE_LIST argument list.
> +
> + If any bit in ErrorLevel is also set in DebugPrintErrorLevelLib function
> + GetDebugPrintErrorLevel (), then print the message specified by Format and
> + the associated variable argument list to the debug output device.
> +
> + If Format is NULL, then ASSERT().
> +
> + @param ErrorLevel The error level of the debug message.
> + @param Format Format string for the debug message to print.
> + @param VaListMarkerVA_LIST marker for the variable argument list.
> + @param BaseListMarker BASE_LIST marker for the variable argument list.
> +
> +**/
> +VOID
> +DebugPrintMarker (
> + IN UINTN ErrorLevel,
> + IN CONST CHAR8 *Format,
> + IN VA_LIST VaListMarker,
> + IN BASE_LIST BaseListMarker
> + )
> {
>CHAR8AsciiBuffer[MAX_DEBUG_MESSAGE_LENGTH];
> - VA_LIST Marker;
>
>//
>// If Format is NULL, then ASSERT().
> @@ -67,14 +105,72 @@ DebugPrint (
>//
>// Convert the DEBUG() message to a Unicode String
>//
> - VA_START (Marker, Format);
> - AsciiVSPrint (AsciiBuffer, sizeof (AsciiBuffer), Format, Marker);
> - VA_END (Marker);
> + if (BaseListMarker == NULL) {
> +AsciiVSPrint (AsciiBuffer, sizeof (AsciiBuffer), Format, VaListMarker);
> + } else {
> +AsciiBSPrint (AsciiBuffer, sizeof (AsciiBuffer), Format, BaseListMarker);
> + }
>
>SemihostWriteString (AsciiBuffer);
> }
>
>
> +/**
> + Prints a debug message to the debug output device if the specified
> + error level is enabled.
> +
> + If any bit in ErrorLevel is also set in DebugPrintErrorLevelLib function
> + GetDebugPrintErrorLevel (), then print the message specified by Format and
> + the associated variable argument list to the debug output device.
> +
> + If Format is NULL, then ASSERT().
> +
> + @param ErrorLevelThe error level of the debug message.
> + @param FormatFormat string for the debug message to print.
> + @param VaListMarker VA_LIST marker for the variable argument list.
> +
> +**/
> +VOID
> +EFIAPI
> +DebugVPrint (
> + IN UINTN
Re: [edk2] [PATCH edk2-platforms 1/2] Platform/ARM/SgiPkg: align with upstream StandaloneMmPkg changes
On Fri, Mar 08, 2019 at 04:30:09PM +0100, Ard Biesheuvel wrote: > Bring SgiPkg in line with EDK2 core changes to StandaloneMmPkg: > - add a resolution for ExtractGuidedSectionLib > - remove reference to gStandaloneMmPkgTokenSpaceGuid.PcdStandaloneMmEnable > - update the resolution of StandaloneMmDriverEntryPoint > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ard Biesheuvel For series: Reviewed-by: Leif Lindholm > --- > Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc > b/Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc > index 65dd6ac82c4a..ef16bfa9a20e 100644 > --- a/Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc > +++ b/Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc > @@ -43,6 +43,7 @@ >BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf >DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf > > DebugPrintErrorLevelLib|MdePkg/Library/BaseDebugPrintErrorLevelLib/BaseDebugPrintErrorLevelLib.inf > + > ExtractGuidedSectionLib|EmbeddedPkg/Library/PrePiExtractGuidedSectionLib/PrePiExtractGuidedSectionLib.inf >FvLib|StandaloneMmPkg/Library/FvLib/FvLib.inf > > HobLib|StandaloneMmPkg/Library/StandaloneMmCoreHobLib/StandaloneMmCoreHobLib.inf >IoLib|MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf > @@ -56,7 +57,7 @@ ># ># Entry point ># > - > StandaloneMmDriverEntryPoint|StandaloneMmPkg/Library/StandaloneMmDriverEntryPoint/StandaloneMmDriverEntryPoint.inf > + > StandaloneMmDriverEntryPoint|MdePkg/Library/StandaloneMmDriverEntryPoint/StandaloneMmDriverEntryPoint.inf > >ArmLib|ArmPkg/Library/ArmLib/ArmBaseLib.inf > > StandaloneMmMmuLib|ArmPkg/Library/StandaloneMmMmuLib/ArmMmuStandaloneMmLib.inf > @@ -81,9 +82,6 @@ > # Pcd Section - list of all EDK II PCD Entries defined by this Platform > # > > > -[PcdsFeatureFlag] > - gStandaloneMmPkgTokenSpaceGuid.PcdStandaloneMmEnable|TRUE > - > [PcdsFixedAtBuild] >gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel|0x80CF >gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|0xff > @@ -93,6 +91,8 @@ >gEfiMdeModulePkgTokenSpaceGuid.PcdSerialRegisterBase|0x7FF7 >gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate|115200 > > + gEfiMdePkgTokenSpaceGuid.PcdMaximumGuidedExtractHandler|0x2 > + > > ### > # > # Components Section - list of the modules and components that will be > processed by compilation > -- > 2.20.1 > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-platforms v3 0/4] Platform/ARM: Platform support for Dynamic Tables Framework
Hi Sami, On the whole, this set looks fine - but: - could you go through and sort the #include files alphabetically in .c/.h (within each grouping)? - similarly, could you go through and ensure that .inf files contain alphabetically sorted [Sources], [Packages] and [LibraryClasses] sections? (The [*Pcd] sections are fine the way they are.) - Up to you, but if you would prefer to squash the set of minor updates into a v2 of this, I'd be OK with that. Best Regards, Leif On Thu, Jan 24, 2019 at 03:46:52PM +, Sami Mujawar wrote: > Dynamic Tables Framework aims to reduce the amount of effort > required for porting firmware to new platforms by simplifying > the generation of firmware tables based on hardware description > provided by a platform specific component. > > The Dynamic Tables Framework core queries the platform specific > component to retrieve the required hardware information for > generating standardised firmware tables at run-time. > > The platform specific component responsible for collating the > hardware information is called the Configuration Manager. > > This patch series introduce the Configuration Manager that > provides the hardware description to Dynamic Tables Framework. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Sami Mujawar > > The changes can be seen at: > https://github.com/samimujawar/edk2-platforms/tree/365_dynamic_tables_framework_v3 > > This v3 patch series incorporates: > * updates corresponding to the dynamic tables framework's change > to support the newer versions of specifications. > * support for describing the platform GT Block timers on Juno. > * minor code improvements. > > The corresponding edk2 code changes can be seen at: > https://github.com/samimujawar/edk2/tree/365_dynamic_tables_framework_v2 > > Sami Mujawar (4): > Platform/ARM: Configuration Manager for Juno > Platform/ARM: Dynamic Tables support for Juno > Platform/ARM: Configuration Manager for FVP > Platform/ARM: Dynamic Tables support for FVP > > Platform/ARM/JunoPkg/ArmJuno.dsc > | 12 +- > Platform/ARM/JunoPkg/ArmJuno.fdf > | 12 + > Platform/ARM/JunoPkg/ConfigurationManager/ConfigurationManager.dsc.inc > | 29 + > > Platform/ARM/JunoPkg/ConfigurationManager/ConfigurationManagerDxe/ConfigurationManager.c > | 752 > > Platform/ARM/JunoPkg/ConfigurationManager/ConfigurationManagerDxe/ConfigurationManager.h > | 179 + > > Platform/ARM/JunoPkg/ConfigurationManager/ConfigurationManagerDxe/ConfigurationManagerDxe.inf > | 86 +++ > Platform/ARM/JunoPkg/ConfigurationManager/ConfigurationManagerDxe/Platform.h > | 99 +++ > Platform/ARM/JunoPkg/ConfigurationManager/PlatformASLTablesLib/Dsdt.asl > | 276 +++ > > Platform/ARM/JunoPkg/ConfigurationManager/PlatformASLTablesLib/PlatformASLTablesLib.inf >| 45 ++ > > Platform/ARM/JunoPkg/ConfigurationManager/PlatformASLTablesLib/SsdtJunoUsb.asl > | 123 > Platform/ARM/JunoPkg/ConfigurationManager/PlatformASLTablesLib/SsdtPci.asl > | 201 ++ > Platform/ARM/JunoPkg/ConfigurationManager/PlatformASLTablesLib/SsdtUart.asl > | 48 ++ > Platform/ARM/JunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c > | 9 +- > Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc > | 15 + > Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.fdf > | 16 +- > Platform/ARM/VExpressPkg/ConfigurationManager/ConfigurationManager.dsc.inc > | 31 + > > Platform/ARM/VExpressPkg/ConfigurationManager/ConfigurationManagerDxe/ConfigurationManager.c > | 684 ++ > > Platform/ARM/VExpressPkg/ConfigurationManager/ConfigurationManagerDxe/ConfigurationManager.h > | 181 + > > Platform/ARM/VExpressPkg/ConfigurationManager/ConfigurationManagerDxe/ConfigurationManagerDxe.inf > | 79 ++ > > Platform/ARM/VExpressPkg/ConfigurationManager/ConfigurationManagerDxe/Platform.h > | 99 +++ > Platform/ARM/VExpressPkg/ConfigurationManager/PlatformASLTablesLib/Dsdt.asl > | 73 ++ > > Platform/ARM/VExpressPkg/ConfigurationManager/PlatformASLTablesLib/PlatformASLTablesLib.inf >| 35 + > 22 files changed, 3079 insertions(+), 5 deletions(-) > create mode 100644 > Platform/ARM/JunoPkg/ConfigurationManager/ConfigurationManager.dsc.inc > create mode 100644 > Platform/ARM/JunoPkg/ConfigurationManager/ConfigurationManagerDxe/ConfigurationManager.c > create mode 100644 >
Re: [edk2] [RFC PATCH] MdeModulePkg: add LockBoxNullLib for !IA32/X64 in .dsc
On Thu, Mar 21, 2019 at 03:27:45AM +, Wu, Hao A wrote:
> > -Original Message-
> > From: Zeng, Star
> > Sent: Thursday, March 21, 2019 9:03 AM
> > To: Leif Lindholm; Laszlo Ersek
> > Cc: edk2-devel@lists.01.org; ard.biesheu...@linaro.org; Wang, Jian J; Wu,
> > Hao A; Ni, Ray; Andrew Fish; Kinney, Michael D; Zeng, Star
> > Subject: RE: [RFC PATCH] MdeModulePkg: add LockBoxNullLib for !IA32/X64
> > in .dsc
> >
> > Another way to update the file is
> >
> > [LibraryClasses.EBC]
> > LockBoxLib|MdeModulePkg/Library/LockBoxNullLib/LockBoxNullLib.inf
> >
> > ->
> >
> > [LibraryClasses.EBC, LibraryClasses.ARM, LibraryClasses.AARCH64]
> > LockBoxLib|MdeModulePkg/Library/LockBoxNullLib/LockBoxNullLib.inf
>
> Hello Leif,
>
> The current proposed patch seems great to me.
> Reviewed-by: Hao Wu
>
> I am also fine with the above suggestion by Star. So if you prefer the
> above approach, please feel free to propose another patch. Thanks in
> advance.
Laszlo convinced me that this change makes sense. But the argument for
that was that each architecture needs to decide itself how to
implement LockBoxLib (or not).
What does not make sense to me is that
MdeModulePkg/Library/SmmLockBoxLib/ is used as a global default, and
set as the resolution for LockBoxLib in common sections, when it is
only valid for 2 of the 6 architectures supported by the UEFI
specification.
My original version is my preferred way of addressing the immediate
problem though, mainly to keep the separate .EBC section.
Best Regards,
Leif
> Best Regards,
> Hao Wu
>
> >
> >
> > Thanks,
> > Star
> > -Original Message-
> > From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> > Sent: Thursday, March 21, 2019 1:43 AM
> > To: Laszlo Ersek
> > Cc: edk2-devel@lists.01.org; ard.biesheu...@linaro.org; Wang, Jian J
> > ; Wu, Hao A ; Ni, Ray
> > ; Zeng, Star ; Andrew Fish
> > ; Kinney, Michael D
> > Subject: Re: [RFC PATCH] MdeModulePkg: add LockBoxNullLib for !IA32/X64
> > in .dsc
> >
> > On Wed, Mar 20, 2019 at 03:51:39PM +0100, Laszlo Ersek wrote:
> > > Hi Leif,
> > >
> > > On 03/18/19 15:56, Leif Lindholm wrote:
> > > > Commit 05fd2a926833
> > > > ("MdeModulePkg/NvmExpressPei: Consume S3StorageDeviceInitList
> > > > LockBox") added a dependency on LockBoxLib to NvmExpressPei, causing
> > > > builds using MdeModulePkg.dsc to fail on architectures other than
> > > > IA32/X64 with missing reference to
> > > > gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSwitchToLongMode.
> > > >
> > > > Add a resolution for LockBoxNullLib for ARM/AARCH64 to restore builds.
> > > >
> > > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > > Signed-off-by: Leif Lindholm
> > > > ---
> > > >
> > > > Note: this patch hides the symptom, but this isn't really the fix I
> > > > would like to see.
> > > >
> > > > The build error is caused by the chain of:
> > > > 1) NvmExpressPei depending on LockBoxLib
> > > > 2) LockBoxLib being mapped to SmmLockBoxPeiLib in
> > > > [LibraryClasses.common.PEIM]
> > > > 3) SmmLockBoxPeiLib depending on PcdDxeIplSwitchToLongMode
> > > > 4) PcdDxeIplSwitchToLongMode being declared in
> > > >[PcdsFeatureFlag.IA32, PcdsFeatureFlag.X64] in MdeModulePkg.dsc
> > > >
> > > > Now, an alternative quick-fix would be to move the PEIM LockBoxLib
> > > > mapping into a [LibraryClasses.IA32.PEIM, LibraryClasses.X64.PEIM]
> > > > section. But that would leave NvmExpressPei unbuildable on anything
> > > > not IA32/X64.
> > > >
> > > > Another option would be to add default declaration (for all other
> > > > architectures) of FALSE for PcdDxeIplSwitchToLongMode in
> > > > MdeModulePkg.dec, but the current way this is expressed seems to
> > > > treat this as an architecture-specific feature (which it is).
> > > >
> > > > What I believe would be the cleanest solution would be to abstract
> > > > NvmExpressPei to the point where it can function without the LockBoxLib.
> > > > But regardless, it does not look valid to me for something as
> > > > architecture-specific as MdeModulePkg/Library/SmmLockBoxLib/ to live
> > > > under .common sections in the .dsc. (And if this changes at some
> > > > point, because we implement an ARM/AARCH64 equivalent based on
Re: [edk2] [PATCH edk2-non-osi v3 0/8] Upload D0x binary modules
On Wed, Mar 20, 2019 at 04:17:21PM +0800, Ming Huang wrote: > Main Changes since v2 : > 1 Move "Add some header files" patch to the first of this series; > > Code can also be found in github: > https://github.com/hisilicon/OpenPlatformPkg.git > branch: 1902-non-osi-v3 Apart from the patches I've called out separately: Reviewed-by: Leif Lindholm Pushed as 635f97e0..99907896. Thanks! > Ming Huang (8): > Hisilicon/D0x: Add some header files > Hisilicon/D06: Remove PCI enumeration dependency from SAS driver > Hisilicon/D0x: Update PlatformSysCtrlLib binary > Hisilicon/D06: Update Mbigen and gic RAS register > Hisilicon/D06: Support PCIe local RAS > Hisilicon/D06: Use new flash layout > Hisilicon/D06: Fix numa node wrong issue > Hisilicon/D06: Add Setup Item "Support DPC" > > Silicon/Hisilicon/Include/Library/IpmiCmdLib.h > | 110 +++ > Silicon/Hisilicon/Include/Library/LpcLib.h > | 113 > Silicon/Hisilicon/Include/Library/OemAddressMapLib.h > | 45 > Silicon/Hisilicon/Include/Library/PlatformSysCtrlLib.h > | 112 +++ > Silicon/Hisilicon/Include/Library/SerdesLib.h > | 21 > Platform/Hisilicon/D06/CustomData.Fv > | Bin 0 -> 65536 bytes > Platform/Hisilicon/D06/Drivers/IoInitDxe/IoInitDxe.efi > | Bin 232832 -> 226784 bytes > Platform/Hisilicon/D06/Drivers/PcieRasInitDxe/PcieRasInitDxe.efi > | Bin 21248 -> 22048 bytes > Platform/Hisilicon/D06/Drivers/RasInitDxe/RasInitDxe.efi > | Bin 17984 -> 18720 bytes > Platform/Hisilicon/D06/Drivers/Sas/SasDriverDxe.depex > | Bin 216 -> 36 bytes > Platform/Hisilicon/D06/Drivers/Sas/SasDriverDxe.efi > | Bin 221312 -> 220640 bytes > Platform/Hisilicon/D06/Library/OemAddressMapD06/OemAddressMapD06.lib > | Bin 61892 -> 31696 bytes > Platform/Hisilicon/D06/MemoryInitPei/MemoryInit.efi > | Bin 297696 -> 358656 bytes > Platform/Hisilicon/D06/Sec/FVMAIN_SEC.Fv > | Bin 1048576 -> 1048576 bytes > Platform/Hisilicon/D06/bl1.bin > | Bin 12432 -> 12432 bytes > Platform/Hisilicon/D06/fip.bin > | Bin 113450 -> 121866 bytes > > Silicon/Hisilicon/Hi1610/Library/PlatformSysCtrlLibHi1610/PlatformSysCtrlLibHi1610.lib > | Bin 297590 -> 229128 bytes > > Silicon/Hisilicon/Hi1616/Library/PlatformSysCtrlLibHi1616/PlatformSysCtrlLibHi1616.lib > | Bin 344310 -> 275312 bytes > > Silicon/Hisilicon/Hi1620/Library/PlatformSysCtrlLibHi1620/PlatformSysCtrlLibHi1620.lib > | Bin 356032 -> 375916 bytes > 19 files changed, 401 insertions(+) > create mode 100644 Silicon/Hisilicon/Include/Library/IpmiCmdLib.h > create mode 100755 Silicon/Hisilicon/Include/Library/LpcLib.h > create mode 100644 Silicon/Hisilicon/Include/Library/OemAddressMapLib.h > create mode 100644 Silicon/Hisilicon/Include/Library/PlatformSysCtrlLib.h > create mode 100644 Silicon/Hisilicon/Include/Library/SerdesLib.h > create mode 100644 Platform/Hisilicon/D06/CustomData.Fv > > -- > 2.9.5 > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-platforms v3 00/18] Fix issues and improve D0x
On Wed, Mar 20, 2019 at 04:08:11PM +0800, Ming Huang wrote: > Main Changes since v2 : > 1 Move tidy and delete header file patch to the first of the series. > > Code can also be found in github: > https://github.com/hisilicon/OpenPlatformPkg.git > branch: 1902-platforms-v3 Apart from the patches I've called out separately: Reviewed-by: Leif Lindholm Pushed as a8f34e0658..89f6901df0. Thanks! > Jason Zhang (1): > Hisilicon/D06: Fix access variable fail issue > > Ming Huang (16): > Hisilicon/D0x: Remove and tidy some codes about SerdesLib > Hisilicon/D0x: Delete some header files > Hisilicon/D0x: Add DriverHealthManagerDxe > Hisilicon/D06: Optimize SAS driver for reducing boot time > Hisilicon/D06: Drop the leading 0 (0x0 -> 0x) > Hisilicon/D06: Add more PCIe port INT-x support > Hisilicon/D0x: Rename StartupAp() function > Hisilicon/D06: Use HCCS speed with 2.6G > Hisilicon/D06: Add PCI_OSC_SUPPORT > Hisilicon/D06: Modify for IMP self-Adapte support > Hisilicon/D06: Add Setup Item "Support DPC" and delete some PCIe menus > Hisilicon/D06: Use new flash layout > Hisilicon/D06: Remove SECURE_BOOT_ENABLE definition > Hisilicon/D0x: Remove SP805 watchdog pcd > Hisilicon/D06: Fix USB crash issue(4079) > Hisilicon/D0x: Modify version to 19.02 > > xingjiang tang (1): > Hisilicon/D06: Add OemGetCpuFreq to encapsulate difference > > Platform/Hisilicon/D03/D03.dsc > | 8 +- > Platform/Hisilicon/D05/D05.dsc > | 8 +- > Platform/Hisilicon/D06/D06.dsc > | 19 +- > Platform/Hisilicon/D03/D03.fdf > | 1 + > Platform/Hisilicon/D05/D05.fdf > | 1 + > Platform/Hisilicon/D06/D06.fdf > | 18 +- > Platform/Hisilicon/D03/EarlyConfigPeim/EarlyConfigPeimD03.inf > | 1 + > Platform/Hisilicon/D03/Library/OemMiscLib2P/OemMiscLib2PHi1610.inf > | 2 +- > Platform/Hisilicon/D05/EarlyConfigPeim/EarlyConfigPeimD05.inf > | 1 + > Platform/Hisilicon/D05/Library/OemMiscLibD05/OemMiscLibD05.inf > | 1 + > Platform/Hisilicon/D06/EarlyConfigPeim/EarlyConfigPeimD06.inf > | 1 + > Platform/Hisilicon/D06/Library/OemMiscLibD06/OemMiscLibD06.inf > | 1 + > Silicon/Hisilicon/Drivers/Smbios/MemorySubClassDxe/MemorySubClassDxe.inf > | 1 + > > Silicon/Hisilicon/Drivers/Smbios/ProcessorSubClassDxe/ProcessorSubClassDxe.inf > | 1 + > Silicon/Hisilicon/Drivers/Smbios/SmbiosMiscDxe/SmbiosMiscDxe.inf > | 4 +- > Silicon/Hisilicon/Drivers/VirtualEhciPciIo/VirtualEhciPciIo.inf > | 1 + > Silicon/Hisilicon/Hi1610/Drivers/IoInitDxe/IoInitDxe.inf > | 1 + > Silicon/Hisilicon/Library/ArmPlatformLibHisilicon/ArmPlatformLib.inf > | 1 - > Silicon/Hisilicon/Library/BmcConfigBootLib/BmcConfigBootLib.inf > | 1 + > Silicon/Hisilicon/Library/I2CLib/I2CLib.inf > | 1 + > Silicon/Hisilicon/Library/I2CLib/I2CLibRuntime.inf > | 1 + > Platform/Hisilicon/D06/Include/Library/CpldD06.h > | 4 + > Silicon/Hisilicon/Hi1610/Include/Library/SerdesLib.h > | 131 - > Silicon/Hisilicon/Hi1616/Include/Library/SerdesLib.h > | 86 -- > Silicon/Hisilicon/Hi1620/Include/Library/SerdesLib.h > | 85 -- > Silicon/Hisilicon/Include/Library/IpmiCmdLib.h > | 110 --- > Silicon/Hisilicon/Include/Library/LpcLib.h > | 113 --- > Silicon/Hisilicon/Include/Library/OemAddressMapLib.h > | 45 --- > Silicon/Hisilicon/Include/Library/OemConfigData.h > | 1 + > Silicon/Hisilicon/Include/Library/OemMiscLib.h > | 75 + > Silicon/Hisilicon/Include/Library/PlatformSysCtrlLib.h > | 112 --- > Silicon/Hisilicon/Hi1620/Hi1620OemCon
Re: [edk2] [PATCH edk2-non-osi v3 8/8] Hisilicon/D06: Add Setup Item "Support DPC"
Just in case there is an interdependency with the edk2-platforms patch Hisilicon/D06: Add Setup Item "Support DPC" and delete some PCIe menus" I will refrain from pushing this just yet, and will similarly cherry-pick this patch into the Linaro release build. I will push this patch once I push the corresponding edk2-platforms patch, or if you tell me there is no dependency. / Leif On Wed, Mar 20, 2019 at 04:17:29PM +0800, Ming Huang wrote: > Add setup item "Support DPC" to enable or disable PCIe DPC > (Downstream Port Containment). > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ming Huang > Reviewed-by: Leif Lindholm > --- > Platform/Hisilicon/D06/Drivers/IoInitDxe/IoInitDxe.efi | Bin 232832 -> > 226784 bytes > 1 file changed, 0 insertions(+), 0 deletions(-) > > diff --git a/Platform/Hisilicon/D06/Drivers/IoInitDxe/IoInitDxe.efi > b/Platform/Hisilicon/D06/Drivers/IoInitDxe/IoInitDxe.efi > index e32c056..4511f6b 100644 > Binary files a/Platform/Hisilicon/D06/Drivers/IoInitDxe/IoInitDxe.efi and > b/Platform/Hisilicon/D06/Drivers/IoInitDxe/IoInitDxe.efi differ > -- > 2.9.5 > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-platforms v3 12/18] Hisilicon/D06: Modify for IMP self-Adapte support
On Wed, Mar 20, 2019 at 04:08:23PM +0800, Ming Huang wrote:
> As new IMP(Cortex-M7) firmware support self-adapte, so do not
> need BIOS to implement some function, remove useless funtions
I will reword/correct the above to "unused functions". With that:
Reviewed-by: Leif Lindholm
> and report CPU0/CPU1 Nic NCL offset to IMP.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ming Huang
> ---
> Platform/Hisilicon/D06/Library/OemNicLib/OemNicLib.c | 281
>
> 1 file changed, 54 insertions(+), 227 deletions(-)
>
> diff --git a/Platform/Hisilicon/D06/Library/OemNicLib/OemNicLib.c
> b/Platform/Hisilicon/D06/Library/OemNicLib/OemNicLib.c
> index aaf990216982..678c2107bdd3 100644
> --- a/Platform/Hisilicon/D06/Library/OemNicLib/OemNicLib.c
> +++ b/Platform/Hisilicon/D06/Library/OemNicLib/OemNicLib.c
> @@ -21,44 +21,21 @@
> #include
>
> #define CPU2_SFP2_100G_CARD_OFFSET 0x25
> -#define CPU1_SFP1_LOCATE_OFFSET 0x16
> -#define CPU1_SFP0_LOCATE_OFFSET 0x12
> -#define CPU2_SFP1_LOCATE_OFFSET 0x21
> -#define CPU2_SFP0_LOCATE_OFFSET 0x19
> -#define CPU2_SFP2_10G_GE_CARD_OFFSET 0x25
>
> -#define SFP_10G_SPEED 10
> -#define SFP_25G_SPEED 25
> -#define SFP_100G_SPEED 100
> -#define SFP_GE_SPEED1
> -
> -#define SFP_GE_SPEED_VAL_VENDOR_FINISAR 0x0C
> -#define SFP_GE_SPEED_VAL0x0D
> -#define SFP_10G_SPEED_VAL 0x67
> -#define SFP_25G_SPEED_VAL 0xFF
> +#define SOCKET1_NET_PORT_100G 1
> +#define SOCKET0_NET_PORT_NUM 4
> +#define SOCKET1_NET_PORT_NUM 2
>
> #define CARD_PRESENT_100G (BIT7)
> -#define CARD_PRESENT_10G(BIT0)
> -#define SELECT_SFP_BY_INDEX(index) (1 << (index - 1))
> -#define SPF_SPEED_OFFSET12
> -
> -#define SFP_DEVICE_ADDRESS 0x50
> -#define CPU1_9545_I2C_ADDR 0x70
> -#define CPU2_9545_I2C_ADDR 0x71
> -
> -#define FIBER_PRESENT 0
> -#define CARD_PRESENT 1
> -#define I2C_PORT_SFP 4
> -#define CPU2_I2C_PORT_SFP 5
> -
> -#define SOCKET_0 0
> -#define SOCKET_1 1
> #define EEPROM_I2C_PORT 4
> #define EEPROM_PAGE_SIZE 0x40
> #define MAC_ADDR_LEN 6
> #define I2C_OFFSET_EEPROM_ETH0 (0xc00)
> #define I2C_SLAVEADDR_EEPROM (0x52)
>
> +#define SRAM_NIC_NCL1_OFFSET_ADDRESS 0xA0E87FE0
> +#define SRAM_NIC_NCL2_OFFSET_ADDRESS 0xA0E87FE4
> +
> #pragma pack(1)
> typedef struct {
>UINT16 Crc16;
> @@ -114,204 +91,6 @@ UINT16 CrcTable16[256] = {
>0x6E17, 0x7E36, 0x4E55, 0x5E74, 0x2E93, 0x3EB2, 0x0ED1, 0x1EF0,
> };
>
> -EFI_STATUS
> -GetSfpSpeed (
> - UINT16 Socket,
> - UINT16 SfpNum,
> - UINT8* FiberSpeed
> - )
> -{
> - EFI_STATUS Status;
> - I2C_DEVICE SpdDev;
> - UINT8 SfpSelect;
> - UINT8 SfpSpeed;
> - UINT32 RegAddr;
> - UINT16 I2cAddr;
> - UINT32 SfpPort;
> -
> - SfpSpeed = 0x0;
> - if (Socket == SOCKET_1) {
> -I2cAddr = CPU2_9545_I2C_ADDR;
> -SfpPort = CPU2_I2C_PORT_SFP;
> - } else {
> -I2cAddr = CPU1_9545_I2C_ADDR;
> -SfpPort = I2C_PORT_SFP;
> - }
> -
> - Status = I2CInit (Socket, SfpPort, Normal);
> - if (EFI_ERROR (Status)) {
> -DEBUG ((DEBUG_ERROR, "[%a]:[%dL] Socket%d Call I2CInit failed!
> p1=0x%x.\n",
> -__FUNCTION__, __LINE__, Socket, Status));
> -return Status;
> - }
> -
> - SpdDev.Socket = Socket;
> - SpdDev.DeviceType = DEVICE_TYPE_SPD;
> - SpdDev.Port = SfpPort;
> - SpdDev.SlaveDeviceAddress = I2cAddr;
> - RegAddr = 0x0;
> - SfpSelect = SELECT_SFP_BY_INDEX (SfpNum);
> -
> - Status = I2CWrite (, RegAddr, 1, );
> - if (EFI_ERROR (Status)) {
> -DEBUG ((DEBUG_ERROR, "I2CWrite Error =%r.\n", Status));
> -return Status;
> - }
> -
> - SpdDev.Socket = Socket;
> - SpdDev.DeviceType = DEVICE_TYPE_SPD;
> - SpdDev.Port = SfpPort;
> - SpdDev.SlaveDeviceAddress = SFP_DEVICE_ADDRESS;
> -
> - RegAddr = SPF_SPEED_OFFSET;
> - Status = I2CRead (, RegAddr, 1, );
> - if (EFI_ERROR (Status)) {
> -DEBUG ((DEBUG_ERROR, "I2CRead Error =%r.\n", Status));
> -return Status;
> - }
> -
> - DEBUG ((DEBUG_INFO, "BR, Nominal, Nominal signalling rate, SfpSpeed:
> 0x%x\n",
> - SfpSpeed));
> -
> - if (SfpSpeed == SFP_10G_SPEED_VAL) {
> -*FiberSpeed = SFP_10G_SPEED;
> - } else if (SfpSpeed == SFP_25G_SPEED_VAL) {
> -*FiberSpeed = SFP_25G_SPEED;
> - } else if ((SfpSpeed == SFP_GE_SPEED_VAL) ||
> - (SfpSpeed == SFP_GE_SP
Re: [edk2] [PATCH edk2-platforms v3 05/18] Hisilicon/D06: Fix access variable fail issue
Urgh, this was an unfortunate off-by-one post: I am deferring this patch until after Linaro's 2019.03 firmware release and cherry-picking it into that. There must be a better way to solve this. My comment referred to "Hisilicon/D06: Drop the leading 0 (0x0 -> 0x)", which will be pushed with an improved subject. / Leif On Thu, Mar 21, 2019 at 05:52:18PM +, Leif Lindholm wrote: > I will update the subject line to reflect what is actually being > changed. > > Other than that, > Reviewed-by: Leif Lindholm > > > On Wed, Mar 20, 2019 at 04:08:16PM +0800, Ming Huang wrote: > > From: Jason Zhang > > > > BmcWdtEnable is a field of OemConfigData structure, need have > > runtime service attribution if use it during exit boot service > > > > Contributed-under: TianoCore Contribution Agreement 1.1 > > Signed-off-by: Ming Huang > > --- > > Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfigVfr.vfr | 2 +- > > Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfig.c | 2 +- > > 2 files changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfigVfr.vfr > > b/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfigVfr.vfr > > index 470e9ace3dcf..08236704fbfe 100644 > > --- a/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfigVfr.vfr > > +++ b/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfigVfr.vfr > > @@ -23,7 +23,7 @@ formset > >help = STRING_TOKEN(STR_OEM_CONFIG), > >classguid = gEfiIfrFrontPageGuid, // for MdeModule Bds. > >efivarstore OEM_CONFIG_DATA, > > -attribute = EFI_VARIABLE_BOOTSERVICE_ACCESS | > > EFI_VARIABLE_NON_VOLATILE, > > +attribute = EFI_VARIABLE_BOOTSERVICE_ACCESS | > > EFI_VARIABLE_NON_VOLATILE | EFI_VARIABLE_RUNTIME_ACCESS, > > name = OemConfig, > > guid = gOemConfigGuid; > > > > diff --git a/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfig.c > > b/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfig.c > > index 012d45bc0214..6668103af027 100644 > > --- a/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfig.c > > +++ b/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfig.c > > @@ -316,7 +316,7 @@ OemConfigUiLibConstructor ( > >Status = gRT->SetVariable ( > >OEM_CONFIG_NAME, > >, > > - EFI_VARIABLE_NON_VOLATILE | > > EFI_VARIABLE_BOOTSERVICE_ACCESS, > > + EFI_VARIABLE_NON_VOLATILE | > > EFI_VARIABLE_BOOTSERVICE_ACCESS | EFI_VARIABLE_RUNTIME_ACCESS, > >sizeof (OEM_CONFIG_DATA), > > > >); > > -- > > 2.9.5 > > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-platforms v3 05/18] Hisilicon/D06: Fix access variable fail issue
I will update the subject line to reflect what is actually being changed. Other than that, Reviewed-by: Leif Lindholm On Wed, Mar 20, 2019 at 04:08:16PM +0800, Ming Huang wrote: > From: Jason Zhang > > BmcWdtEnable is a field of OemConfigData structure, need have > runtime service attribution if use it during exit boot service > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ming Huang > --- > Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfigVfr.vfr | 2 +- > Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfig.c | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfigVfr.vfr > b/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfigVfr.vfr > index 470e9ace3dcf..08236704fbfe 100644 > --- a/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfigVfr.vfr > +++ b/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfigVfr.vfr > @@ -23,7 +23,7 @@ formset >help = STRING_TOKEN(STR_OEM_CONFIG), >classguid = gEfiIfrFrontPageGuid, // for MdeModule Bds. >efivarstore OEM_CONFIG_DATA, > -attribute = EFI_VARIABLE_BOOTSERVICE_ACCESS | EFI_VARIABLE_NON_VOLATILE, > +attribute = EFI_VARIABLE_BOOTSERVICE_ACCESS | EFI_VARIABLE_NON_VOLATILE > | EFI_VARIABLE_RUNTIME_ACCESS, > name = OemConfig, > guid = gOemConfigGuid; > > diff --git a/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfig.c > b/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfig.c > index 012d45bc0214..6668103af027 100644 > --- a/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfig.c > +++ b/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfig.c > @@ -316,7 +316,7 @@ OemConfigUiLibConstructor ( >Status = gRT->SetVariable ( >OEM_CONFIG_NAME, >, > - EFI_VARIABLE_NON_VOLATILE | > EFI_VARIABLE_BOOTSERVICE_ACCESS, > + EFI_VARIABLE_NON_VOLATILE | > EFI_VARIABLE_BOOTSERVICE_ACCESS | EFI_VARIABLE_RUNTIME_ACCESS, >sizeof (OEM_CONFIG_DATA), > >); > -- > 2.9.5 > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-platforms v3 13/18] Hisilicon/D06: Add Setup Item "Support DPC" and delete some PCIe menus
Hi Ming,
On Wed, Mar 20, 2019 at 04:08:24PM +0800, Ming Huang wrote:
> Add setup item "Support DPC" to enable or disable PCIe DPC
> (Downstream Port Containment).
>
> The pcie menu is suppressed for original code as these menus
> are not ready. This patch remove the suppression for pcie menu,
> so delete these menus for now.
As the commit message shows, this patch does two unrelated things.
Could you break this patch up into two separate ones and resubmit just
those?
I will cherry-pick this patch manually in order to have it included in
RPF 2019.03 -rc1, but I would prefer what goes in upstream to be
cleaner.
Best Regards,
Leif
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ming Huang
> ---
> Silicon/Hisilicon/Include/Library/OemConfigData.h | 1 +
> Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfigVfr.vfr | 2 -
> Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfig.c | 4 +
> Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/PcieConfig.hfr| 197
> +---
> Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/PcieConfigStrings.uni | 3 +-
> 5 files changed, 10 insertions(+), 197 deletions(-)
>
> diff --git a/Silicon/Hisilicon/Include/Library/OemConfigData.h
> b/Silicon/Hisilicon/Include/Library/OemConfigData.h
> index f120e3123c83..c0097d0829f0 100644
> --- a/Silicon/Hisilicon/Include/Library/OemConfigData.h
> +++ b/Silicon/Hisilicon/Include/Library/OemConfigData.h
> @@ -49,6 +49,7 @@ typedef struct {
>UINT8 OSWdtAction;
>/*PCIe Config*/
>UINT8 PcieSRIOVSupport;
> + UINT8 PcieDPCSupport;
>UINT8 PciePort[PCIE_MAX_TOTAL_PORTS];
>UINT8 PcieLinkSpeedPort[PCIE_MAX_TOTAL_PORTS];
>UINT8 PcieLinkDeEmphasisPort[PCIE_MAX_TOTAL_PORTS];
> diff --git a/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfigVfr.vfr
> b/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfigVfr.vfr
> index 08236704fbfe..93ccb99bdc67 100644
> --- a/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfigVfr.vfr
> +++ b/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfigVfr.vfr
> @@ -62,11 +62,9 @@ formset
>prompt = STRING_TOKEN(STR_IBMC_CONFIG_FORM_TITLE),
>help = STRING_TOKEN(STR_IBMC_CONFIG_FORM_HELP);
>
> -suppressif TRUE;
> goto PCIE_CONFIG_FORM_ID,
>prompt = STRING_TOKEN(STR_PCIE_CONFIG_FORM_TITLE),
>help= STRING_TOKEN(STR_PCIE_CONFIG_FORM_HELP);
> -endif;
>
> goto MISC_CONFIG_FORM_ID,
>prompt = STRING_TOKEN(STR_MISC_CONFIG_FORM_TITLE),
> diff --git a/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfig.c
> b/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfig.c
> index 6668103af027..be4ce8820f73 100644
> --- a/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfig.c
> +++ b/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfig.c
> @@ -290,6 +290,10 @@ OemConfigUiLibConstructor (
>Configuration.OSWdtTimeout = 5;
>Configuration.OSWdtAction = 1;
>//
> + //Set the default value of the PCIe option
> + //
> + Configuration.PcieDPCSupport = 0;
> + //
>//Set the default value of the Misc option
>//
>Configuration.EnableSmmu = 1;
> diff --git a/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/PcieConfig.hfr
> b/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/PcieConfig.hfr
> index 7cf7cdd29ba2..c65907fe846e 100644
> --- a/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/PcieConfig.hfr
> +++ b/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/PcieConfig.hfr
> @@ -17,203 +17,12 @@
> form formid = PCIE_CONFIG_FORM_ID,
>title = STRING_TOKEN (STR_PCIE_CONFIG_FORM_TITLE);
>
> - goto VFR_FORMID_PCIE_SOCKET0,
> -prompt = STRING_TOKEN (STR_PCIE_CPU_0_PROMPT),
> -help= STRING_TOKEN (STR_PCIE_CPU_PROMPT_HELP);
> -
> - goto VFR_FORMID_PCIE_SOCKET1,
> -prompt = STRING_TOKEN (STR_PCIE_CPU_1_PROMPT),
> -help= STRING_TOKEN (STR_PCIE_CPU_PROMPT_HELP);
> -
> - oneof varid = OEM_CONFIG_DATA.PcieSRIOVSupport,
> -prompt = STRING_TOKEN (STR_SRIOV_SUPPORT_PROMPT),
> -help = STRING_TOKEN (STR_SRIOV_SUPPORT_HELP),
> + oneof varid = OEM_CONFIG_DATA.PcieDPCSupport,
> +prompt = STRING_TOKEN (STR_DPC_SUPPORT_PROMPT),
> +help = STRING_TOKEN (STR_DPC_SUPPORT_HELP),
> option text = STRING_TOKEN (STR_DISABLE), value = 0, flags =
> MANUFACTURING | DEFAULT | RESET_REQUIRED;
> option text = STRING_TOKEN (STR_ENABLE), value = 1, flags =
> RESET_REQUIRED;
>endoneof;
>
> endform;
>
> -form formid = VFR_FORMID_PCIE_SOCKET0,
> - title = STRING_TOKEN(STR_PCIE_CPU_0_PROMPT);
> -
> - goto VFR_FORMID_PCIE_PORT2,
> -prompt = STRING_TOKEN(STR_PCIE_PORT_2_PROMPT),
> -help= STRING_TOKEN(STR_PCIE_PORT_PROMPT_HELP);
> -
> - goto VFR_FORMID_PCIE_PORT4,
> -prompt = STRING_TOKEN(STR_PCIE_PORT_4_PROMPT),
> -help=
Re: [edk2] [RFC PATCH] MdeModulePkg: add LockBoxNullLib for !IA32/X64 in .dsc
On Wed, Mar 20, 2019 at 03:51:39PM +0100, Laszlo Ersek wrote:
> Hi Leif,
>
> On 03/18/19 15:56, Leif Lindholm wrote:
> > Commit 05fd2a926833
> > ("MdeModulePkg/NvmExpressPei: Consume S3StorageDeviceInitList LockBox")
> > added a dependency on LockBoxLib to NvmExpressPei, causing builds using
> > MdeModulePkg.dsc to fail on architectures other than IA32/X64 with
> > missing reference to
> > gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSwitchToLongMode.
> >
> > Add a resolution for LockBoxNullLib for ARM/AARCH64 to restore builds.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Leif Lindholm
> > ---
> >
> > Note: this patch hides the symptom, but this isn't really the fix I
> > would like to see.
> >
> > The build error is caused by the chain of:
> > 1) NvmExpressPei depending on LockBoxLib
> > 2) LockBoxLib being mapped to SmmLockBoxPeiLib in
> > [LibraryClasses.common.PEIM]
> > 3) SmmLockBoxPeiLib depending on PcdDxeIplSwitchToLongMode
> > 4) PcdDxeIplSwitchToLongMode being declared in
> >[PcdsFeatureFlag.IA32, PcdsFeatureFlag.X64] in MdeModulePkg.dsc
> >
> > Now, an alternative quick-fix would be to move the PEIM LockBoxLib mapping
> > into a [LibraryClasses.IA32.PEIM, LibraryClasses.X64.PEIM]
> > section. But that would leave NvmExpressPei unbuildable on anything not
> > IA32/X64.
> >
> > Another option would be to add default declaration (for all other
> > architectures) of FALSE for PcdDxeIplSwitchToLongMode in MdeModulePkg.dec,
> > but the current way this is expressed seems to treat this as an
> > architecture-specific feature (which it is).
> >
> > What I believe would be the cleanest solution would be to abstract
> > NvmExpressPei to the point where it can function without the LockBoxLib.
> > But regardless, it does not look valid to me for something as
> > architecture-specific as MdeModulePkg/Library/SmmLockBoxLib/ to live under
> > .common sections in the .dsc. (And if this changes at some point, because
> > we implement an ARM/AARCH64 equivalent based on StandaloneMmPkg, we will
> > need
> > a major refactoring of that library anyway.)
> >
> > /
> > Leif
> >
> > MdeModulePkg/MdeModulePkg.dsc | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/MdeModulePkg/MdeModulePkg.dsc b/MdeModulePkg/MdeModulePkg.dsc
> > index 6cd1727a0d..6e27e9cb68 100644
> > --- a/MdeModulePkg/MdeModulePkg.dsc
> > +++ b/MdeModulePkg/MdeModulePkg.dsc
> > @@ -178,6 +178,7 @@ [LibraryClasses.common.MM_STANDALONE]
> > [LibraryClasses.ARM, LibraryClasses.AARCH64]
> >ArmLib|ArmPkg/Library/ArmLib/ArmBaseLib.inf
> >ArmMmuLib|ArmPkg/Library/ArmMmuLib/ArmMmuBaseLib.inf
> > + LockBoxLib|MdeModulePkg/Library/LockBoxNullLib/LockBoxNullLib.inf
> >
> >#
> ># It is not possible to prevent ARM compiler calls to generic intrinsic
> > functions.
> >
>
> I think this patch is exactly the right solution.
>
> The code added in commit 05fd2a926833 is gated by (BootMode ==
> BOOT_ON_S3_RESUME). That condition can never evaluate to TRUE on
> ARM/AARCH64, presently. Accordingly, the stated goal of the commit
> doesn't apply to ARM/AARCH64:
>
> The purpose is to perform an on-demand (partial) NVM Express device
> enumeration/initialization to benefit the S3 resume performance.
>
> Given that the RestoreLockBox() calls are never reached (which is
> correct, by design, at the present level of ACPI S3 enablement in edk2
> for ARM/AARCH64), causing the lockbox APIs to "do nothing beyond
> compile" is exactly right. IMO anyway.
>
> Once ARM/AARCH64 grow S3 support, a functional and secure LockBox will
> have to be part of that. Perhaps it will use "standalone MM"; I'm not
> sure. The point is, once the goal of the commit starts applying to
> ARM/AARCH64, a functional LockBox will have been implemented for
> ARM/AARCH64; and that lib instance will certainly not depend on
> PcdDxeIplSwitchToLongMode.
>
> Until such time, this patch is fine.
OK, I buy that argument.
*But* I still think the IA32/X64 specific library mappings should be
moved out of .common LibraryClass sections.
Regards,
Leif
> 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] PATCH] Change EDK II to BSD+Patent License
A starting proposal for my end would be: --- In order to keep track of who did what, all patches contributed need to include a statement that to the best of the contributor's knowledge they have the right to contribute it under the specified license. The test for this is as specified in the [Developer's Certificate of Origin (DCO) 1.1](https://developercertificate.org/). The contributor certifies compliance by adding a line saying Signed-off-by: Developer Name where "Developer Name" is the contributor's real name, and the email address is one the developer is reachable through at the time of contributing. --- We could also do what Linux does and include the DCO v1.1 verbatim in the Readme.md instead of using the link. Best Regards, Leif On Tue, Mar 19, 2019 at 07:09:41PM +, Kinney, Michael D wrote: > Leif and Jordan, > > Would you mind putting together a specific proposal > and perhaps some links to other projects that use > the same approach? > > I am happy to update the RFC to V3 to address this > topic if we can close on it quickly. > > Thanks, > > Mike > > > > -Original Message- > > From: Leif Lindholm [mailto:leif.lindh...@linaro.org] > > Sent: Tuesday, March 19, 2019 10:59 AM > > To: Kinney, Michael D > > Cc: Justen, Jordan L ; edk2- > > de...@lists.01.org > > Subject: Re: [edk2] PATCH] Change EDK II to BSD+Patent > > License > > > > Hi Mike, > > > > I see where Jordan is coming from here. > > > > It isn't just about losing the comment in > > Contriutions.txt - there are > > bits in the actual TianoCore Contribution Agreement that > > cover the > > same things as https://developercertificate.org/ (that > > are not > > explicitly called out elsewhere in the existing > > Contributions.txt). > > > > Like Jordan says, we wouldn't be the first project that > > use > > Signed-off-by without specifying exactly what it means, > > but I think > > we're one of the ones that actually care quite a bit. > > > > I could live with us not resolving this at the same time > > as the > > license change, but I would prefer if we did... > > > > Best Regards, > > > > Leif > > > > On Mon, Mar 18, 2019 at 06:25:54PM +, Kinney, Michael > > D wrote: > > > Hi Jordan, > > > > > > No proposed changes to the Signed-off-by tags. If you > > have > > > a proposal, please provide an RFC or bring to the > > monthly > > > EDK II community meeting. > > > > > > This series is focused on the license change, the use > > of SPDX > > > identifiers, and removing the Contributed-under tag > > from > > > commit messages. > > > > > > I will update the V2 version of the patch series in to > > make > > > sure the content from Contributions.txt that is not > > part of > > > the TianoCore Contribution Agreement is added to > > Readme.md. > > > > > > The RFC mentioned the need to update documentation. I > > will > > > send that out as a separate Wiki patch series for > > review. > > > > > > Best regards, > > > > > > Mike > > > > > > > -Original Message- > > > > From: Justen, Jordan L > > > > Sent: Thursday, March 14, 2019 11:04 AM > > > > To: Kinney, Michael D ; > > > > edk2-devel@lists.01.org > > > > Subject: Re: [edk2] PATCH] Change EDK II to > > BSD+Patent > > > > License > > > > > > > > On 2019-03-13 10:54:22, Kinney, Michael D wrote: > > > > > > > > > > 84141eacac edk2: Remove Contributions.txt and > > update > > > > Readme.md > > > > > > > > I guess this removes the requirement for the > > > > 'Contributed-under' tag > > > > in commit messages? > > > > > > > > But, what about Signed-off-by? Is it desirable to > > > > remove that > > > > requirement? > > > > > > > > Relatedly, some open source projects have > > standardized > > > > on tying the > > > > Signed-off-by to this text: > > > > > > > > https://developercertificate.org/ > > > > > > > > So, the contributor doesn't have to agree to give the > > > > project the > > > > contribution under the Contributed-under terms, but > > > > they still > > > > indicate that they believe that the project can use > > the > >
Re: [edk2] PATCH] Change EDK II to BSD+Patent License
Hi Mike, I see where Jordan is coming from here. It isn't just about losing the comment in Contriutions.txt - there are bits in the actual TianoCore Contribution Agreement that cover the same things as https://developercertificate.org/ (that are not explicitly called out elsewhere in the existing Contributions.txt). Like Jordan says, we wouldn't be the first project that use Signed-off-by without specifying exactly what it means, but I think we're one of the ones that actually care quite a bit. I could live with us not resolving this at the same time as the license change, but I would prefer if we did... Best Regards, Leif On Mon, Mar 18, 2019 at 06:25:54PM +, Kinney, Michael D wrote: > Hi Jordan, > > No proposed changes to the Signed-off-by tags. If you have > a proposal, please provide an RFC or bring to the monthly > EDK II community meeting. > > This series is focused on the license change, the use of SPDX > identifiers, and removing the Contributed-under tag from > commit messages. > > I will update the V2 version of the patch series in to make > sure the content from Contributions.txt that is not part of > the TianoCore Contribution Agreement is added to Readme.md. > > The RFC mentioned the need to update documentation. I will > send that out as a separate Wiki patch series for review. > > Best regards, > > Mike > > > -Original Message- > > From: Justen, Jordan L > > Sent: Thursday, March 14, 2019 11:04 AM > > To: Kinney, Michael D ; > > edk2-devel@lists.01.org > > Subject: Re: [edk2] PATCH] Change EDK II to BSD+Patent > > License > > > > On 2019-03-13 10:54:22, Kinney, Michael D wrote: > > > > > > 84141eacac edk2: Remove Contributions.txt and update > > Readme.md > > > > I guess this removes the requirement for the > > 'Contributed-under' tag > > in commit messages? > > > > But, what about Signed-off-by? Is it desirable to > > remove that > > requirement? > > > > Relatedly, some open source projects have standardized > > on tying the > > Signed-off-by to this text: > > > > https://developercertificate.org/ > > > > So, the contributor doesn't have to agree to give the > > project the > > contribution under the Contributed-under terms, but > > they still > > indicate that they believe that the project can use the > > code under the > > project's indicated license. > > > > There is also other information in Contributions.txt > > that appears to > > have been deleted, rather than moved. I guess it is > > mostly duplicated > > on the wiki. That doesn't mean it's not a good idea to > > duplicate it in > > the source tree, or at least provide a web-link. It > > seems like the > > first place devs might look for such information is > > either the readme, > > or Contributions.txt. > > > > Regarding the wiki, I guess it has to be updated after > > this change is > > made. It might be good to add that to the bug so it > > can't be closed > > until that is fixed. > > > > How about updating BaseTools/Scripts/PatchCheck.py? > > > > -Jordan > ___ > 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 MdeModulePkg/Library v1 1/1] MdeModulePkg/UefiBootManangerLib: Fix exception issue
Thanks, Ming.
On Tue, Mar 19, 2019 at 08:59:13PM +0800, Ming Huang wrote:
> The system environment: virtual-CDROM(USB interface) via BMC, insert a
> iso file to CDROM, like ubuntu-18.04.1-server-arm64.iso, change CDROM
> to first boot option.
> With release version bios, disconnecting CDROM when boot to
> "1 seconds left, Press Esc or F2 to enter Setup"
> then system will get a exception.
>
> The root cause is the EFI_BLOCK_IO_PROTOCOL for UsbMass will be uninstalled
> in this situation after print some transfer error. The status will be
> invalid parameter. This line will get a exception for BlockIo not point
> to right address:
> AllocatePool (BlockIo->Media->BlockSize)
> So, here need to judge the status after ASSERT_EFI_ERROR.
>
> The Bugzilla tracker for this:
> https://bugzilla.tianocore.org/show_bug.cgi?id=1631
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ming Huang
Reviewed-by: Leif Lindholm
> ---
> MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
> b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
> index 4ce83ce22d61..0535cd7335b4 100644
> --- a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
> +++ b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
> @@ -1069,6 +1069,9 @@ BmExpandMediaDevicePath (
>//
>Status = gBS->HandleProtocol (Handle, , (VOID **)
> );
>ASSERT_EFI_ERROR (Status);
> + if (EFI_ERROR (Status)) {
> +return NULL;
> + }
>Buffer = AllocatePool (BlockIo->Media->BlockSize);
>if (Buffer != NULL) {
> BlockIo->ReadBlocks (
> --
> 2.9.5
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [MdeModulePkg/Library v1 1/1] MdeModulePkg/UefiBootManangerLib: Fix exception issue
On Tue, Mar 19, 2019 at 12:01:51PM +0800, Ming Huang wrote: > On 3/18/2019 8:42 PM, Leif Lindholm wrote: > > +MdeModulePkg maintainers (you added MdePkg maintainers to cc) > > > > This looks like an improvement to me. > > > > Am I correct in guessing this behaviour refers to some specific corner > > case of a USB CDROM emulated from a BMC? > > Yes, I found this issue with a USB CDROM emulated from a BMC. > I guess have the same symptom with physical USB CDROM. Yes, you would just be less likely to disconnect it :) Thanks for the confirmation. Best Regards, Leif ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH 0/2] DynamicTablesPkg: add package .dsc
Having a top-level .dsc simplifies automated builds of core modules in isolation from any final platforms. As demonstrated by 1/2, discovered while putting the .dsc together. Leif Lindholm (2): DynamicTablesPkg: correct LibraryClass dependencies for Arm/DBG2 DynamicTablesPkg: add package .dsc file DynamicTablesPkg/DynamicTablesPkg.dsc | 44 ++ .../Acpi/Arm/AcpiDbg2LibArm/AcpiDbg2LibArm.inf | 2 +- 2 files changed, 45 insertions(+), 1 deletion(-) create mode 100644 DynamicTablesPkg/DynamicTablesPkg.dsc -- 2.11.0 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH 1/2] DynamicTablesPkg: correct LibraryClass dependencies for Arm/DBG2
This patch changes the stated dependency in AcpiDbg2LibArm.inf from currently listed SerialPortLib to actually required PL011UartLib. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Leif Lindholm --- DynamicTablesPkg/Library/Acpi/Arm/AcpiDbg2LibArm/AcpiDbg2LibArm.inf | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/DynamicTablesPkg/Library/Acpi/Arm/AcpiDbg2LibArm/AcpiDbg2LibArm.inf b/DynamicTablesPkg/Library/Acpi/Arm/AcpiDbg2LibArm/AcpiDbg2LibArm.inf index 4075862204..6682e92448 100644 --- a/DynamicTablesPkg/Library/Acpi/Arm/AcpiDbg2LibArm/AcpiDbg2LibArm.inf +++ b/DynamicTablesPkg/Library/Acpi/Arm/AcpiDbg2LibArm/AcpiDbg2LibArm.inf @@ -34,7 +34,7 @@ [Packages] [LibraryClasses] BaseLib - SerialPortLib + PL011UartLib [FixedPcd] gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate -- 2.11.0 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH 2/2] DynamicTablesPkg: add package .dsc file
Having a top-level .dsc makes it easier to perform standalone build tests of the core code, so add one. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Leif Lindholm --- DynamicTablesPkg/DynamicTablesPkg.dsc | 44 +++ 1 file changed, 44 insertions(+) create mode 100644 DynamicTablesPkg/DynamicTablesPkg.dsc diff --git a/DynamicTablesPkg/DynamicTablesPkg.dsc b/DynamicTablesPkg/DynamicTablesPkg.dsc new file mode 100644 index 00..a66bba976c --- /dev/null +++ b/DynamicTablesPkg/DynamicTablesPkg.dsc @@ -0,0 +1,44 @@ +## @file +# Dsc file for Dynamic Tables Framework. +# +# Copyright (c) 2019, Linaro Limited. 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] + PLATFORM_NAME = DynamicTables + PLATFORM_GUID = f39096a0-7a0a-442a-9413-cf584ef80cbb + PLATFORM_VERSION = 0.1 + DSC_SPECIFICATION = 0x0001001a + OUTPUT_DIRECTORY = Build/DynamicTables + SUPPORTED_ARCHITECTURES= ARM|AARCH64 + BUILD_TARGETS = DEBUG|RELEASE|NOOPT + SKUID_IDENTIFIER = DEFAULT + +!include DynamicTables.dsc.inc + +[LibraryClasses] + BaseLib|MdePkg/Library/BaseLib/BaseLib.inf + BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf + DebugLib|MdePkg/Library/BaseDebugLibNull/BaseDebugLibNull.inf + IoLib|MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf + MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf + PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf + PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf + UefiBootServicesTableLib|MdePkg/Library/UefiBootServicesTableLib/UefiBootServicesTableLib.inf + UefiDriverEntryPoint|MdePkg/Library/UefiDriverEntryPoint/UefiDriverEntryPoint.inf + +[LibraryClasses.ARM, LibraryClasses.AARCH64] + PL011UartLib|ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.inf + +[Components.common] + DynamicTablesPkg/Library/Common/TableHelperLib/TableHelperLib.inf -- 2.11.0 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [RFC PATCH] MdeModulePkg: add LockBoxNullLib for !IA32/X64 in .dsc
Commit 05fd2a926833
("MdeModulePkg/NvmExpressPei: Consume S3StorageDeviceInitList LockBox")
added a dependency on LockBoxLib to NvmExpressPei, causing builds using
MdeModulePkg.dsc to fail on architectures other than IA32/X64 with
missing reference to
gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSwitchToLongMode.
Add a resolution for LockBoxNullLib for ARM/AARCH64 to restore builds.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Leif Lindholm
---
Note: this patch hides the symptom, but this isn't really the fix I
would like to see.
The build error is caused by the chain of:
1) NvmExpressPei depending on LockBoxLib
2) LockBoxLib being mapped to SmmLockBoxPeiLib in [LibraryClasses.common.PEIM]
3) SmmLockBoxPeiLib depending on PcdDxeIplSwitchToLongMode
4) PcdDxeIplSwitchToLongMode being declared in
[PcdsFeatureFlag.IA32, PcdsFeatureFlag.X64] in MdeModulePkg.dsc
Now, an alternative quick-fix would be to move the PEIM LockBoxLib mapping
into a [LibraryClasses.IA32.PEIM, LibraryClasses.X64.PEIM]
section. But that would leave NvmExpressPei unbuildable on anything not
IA32/X64.
Another option would be to add default declaration (for all other
architectures) of FALSE for PcdDxeIplSwitchToLongMode in MdeModulePkg.dec,
but the current way this is expressed seems to treat this as an
architecture-specific feature (which it is).
What I believe would be the cleanest solution would be to abstract
NvmExpressPei to the point where it can function without the LockBoxLib.
But regardless, it does not look valid to me for something as
architecture-specific as MdeModulePkg/Library/SmmLockBoxLib/ to live under
.common sections in the .dsc. (And if this changes at some point, because we
implement an ARM/AARCH64 equivalent based on StandaloneMmPkg, we will need
a major refactoring of that library anyway.)
/
Leif
MdeModulePkg/MdeModulePkg.dsc | 1 +
1 file changed, 1 insertion(+)
diff --git a/MdeModulePkg/MdeModulePkg.dsc b/MdeModulePkg/MdeModulePkg.dsc
index 6cd1727a0d..6e27e9cb68 100644
--- a/MdeModulePkg/MdeModulePkg.dsc
+++ b/MdeModulePkg/MdeModulePkg.dsc
@@ -178,6 +178,7 @@ [LibraryClasses.common.MM_STANDALONE]
[LibraryClasses.ARM, LibraryClasses.AARCH64]
ArmLib|ArmPkg/Library/ArmLib/ArmBaseLib.inf
ArmMmuLib|ArmPkg/Library/ArmMmuLib/ArmMmuBaseLib.inf
+ LockBoxLib|MdeModulePkg/Library/LockBoxNullLib/LockBoxNullLib.inf
#
# It is not possible to prevent ARM compiler calls to generic intrinsic
functions.
--
2.11.0
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [MdeModulePkg/Library v1 1/1] MdeModulePkg/UefiBootManangerLib: Fix exception issue
+MdeModulePkg maintainers (you added MdePkg maintainers to cc)
This looks like an improvement to me.
Am I correct in guessing this behaviour refers to some specific corner
case of a USB CDROM emulated from a BMC?
On Mon, Feb 25, 2019 at 05:10:52PM +0800, Ming Huang wrote:
> The system environment: virtual-CDROM(USB interface) via BMC, insert a
> iso file to CDROM, like ubuntu-18.04.1-server-arm64.iso, change CDROM
> to first boot option.
> With release version bios, disconnecting CDROM when boot to
> "1 seconds left, Press Esc or F2 to enter Setup"
> then system will get a exception.
>
> The root cause is the EFI_BLOCK_IO_PROTOCOL for UsbMass will be uninstalled
> in this situation after print some transfer error. The status will be
> invalid parameter. This line will get a exception for BlockIo not point
> to right address:
> AllocatePool (BlockIo->Media->BlockSize)
> So, here need to judge the status not using ASSERT_EFI_ERROR.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ming Huang
> ---
> MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
> b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
> index d5957db610d9..c2f1c651b02f 100644
> --- a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
> +++ b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
> @@ -1068,7 +1068,9 @@ BmExpandMediaDevicePath (
>// Block IO read/write will success.
>//
>Status = gBS->HandleProtocol (Handle, , (VOID **)
> );
> - ASSERT_EFI_ERROR (Status);
> + if (EFI_ERROR (Status)) {
It would still be worth including an ASSERT here, to let DEBUG builds
report on point of failure rather than several steps up the chain.
/
Leif
> +return NULL;
> + }
>Buffer = AllocatePool (BlockIo->Media->BlockSize);
>if (Buffer != NULL) {
> BlockIo->ReadBlocks (
> --
> 2.9.5
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] EmbeddedPkg/DwEmacSnpDxe: Add designware emac support This add support for designware emac controller
Hi Tzy Way, On Thu, Feb 28, 2019 at 08:39:32AM +, Ooi, Tzy Way wrote: > Thanks for your comment. I will modify the driver to comply to UEFI > driver model. Excellent, thanks. > I would like to ask why this driver should be submitted to edk2- > platforms instead of edk2? This driver is a generic driver which is > target to work on various platform. This was the decision we made when formalising the process for bringing hardware support into TianoCore, whereas the edk2 repository would strictly import support for industry-standard components. With DesignWare, a case could perhaps be made that like ARM PrimeCells, they exist in many different devices from many different vendors. But if so, EmbeddedPkg is not their natural home. Some of the drivers already under EmbeddedPkg clearly violate this definition, but that is because they predate the definition of the process. Hmm, I probably should add a Readme.md about this in EmbeddedPkg/Drivers. Best Regards, Leif > Best regards, > Tzy Way > > > On Thu, 2019-01-31 at 18:22 +, Leif Lindholm wrote: > > Hi Tzy Way, > > > > Thank you for this contribution. > > > > I do have some high-level comments. > > > > First of all, my best guess is that you have used Lan9118Dxe for > > reference when developing this driver. This is somewhat unfortunate. > > I am reminded that > > a) we badly need to migrate that driver (and Lan91xDxe) to > >edk2-platforms. > > b) we badly need to convert those drivers to UEFI driver model and > >NonDiscoverableDeviceRegistrationLib. > > Those two predate the NonDiscoverable implementation, so have been > > left as is, but any new drivers really need to implement proper > > driver > > model. > > Additionally, this driver should be submitted to edk2-platforms > > rather > > than edk2. > > > > Secondly, searching online for "designware emac" does not find > > unambigously the product this refers to. This is where it would be > > usful with a proper commit message and explain in a bit more detail > > what the driver is. > > > > On Thu, Jan 31, 2019 at 04:32:00PM +0800, tzy.way@intel.com > > wrote: > > > From: "Ooi, Tzy Way" > > > > > > Contributed-under: TianCore Contribution Agreement 1.1 > > > Signed-off-by: Ooi, Tzy Way > > > --- > > > .../Drivers/DwEmacSnpDxe/DwEmacSnpDxe.c | 1368 > > > + > > > .../Drivers/DwEmacSnpDxe/DwEmacSnpDxe.h | 236 +++ > > > .../Drivers/DwEmacSnpDxe/DwEmacSnpDxe.inf | 69 + > > > .../Drivers/DwEmacSnpDxe/EmacDxeUtil.c| 676 > > > .../Drivers/DwEmacSnpDxe/EmacDxeUtil.h| 378 + > > > EmbeddedPkg/Drivers/DwEmacSnpDxe/PhyDxeUtil.c | 604 > > > EmbeddedPkg/Drivers/DwEmacSnpDxe/PhyDxeUtil.h | 324 > > > EmbeddedPkg/EmbeddedPkg.dec |4 + > > > EmbeddedPkg/EmbeddedPkg.dsc |1 + > > > 9 files changed, 3660 insertions(+) > > > > Thirdly, please generate patches as described in > > > https://github.com/tianocore/tianocore.github.io/wiki/Laszlo%27s-unkempt-git-guide-for-edk2-contributors-and-maintainers#contrib-23 > > This greatly simplifies review. > > > > Best Regards, > > > > Leif ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch] BaseTools: Add python3-distutils Ubuntu package checking
On Wed, Feb 27, 2019 at 08:52:08AM +, Feng, Bob C wrote:
> Thanks for comments. I think the print message is not good. It's based on
> Ubutun OS. It's not right.
>
> I think the import error need to be caught and then print some
> messages, otherwise the build tool will break and print the call
> stack which is not friendly to user.
I agree printing the call stack is not useful for import errors.
Is there no way to suppress that for basic environment issues?
Surely a "failed to import..." message would also be printed?
Regards,
Leif
> Thanks,
> Bob
>
> -Original Message-
> From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> Sent: Wednesday, February 27, 2019 4:26 PM
> To: Feng, Bob C
> Cc: Ard Biesheuvel ; edk2-devel@lists.01.org; Gao,
> Liming
> Subject: Re: [edk2] [Patch] BaseTools: Add python3-distutils Ubuntu package
> checking
>
> On Wed, Feb 27, 2019 at 09:07:49AM +0100, Ard Biesheuvel wrote:
> > On Tue, 26 Feb 2019 at 02:05, Feng, Bob C wrote:
> > >
> > > https://bugzilla.tianocore.org/show_bug.cgi?id=1509
> > >
> > > Add python3-distutils Ubuntu package checking.
> > >
> >
> > Hi Bob,
> >
> > This assumes that all Linux systems are Ubuntu based, which is not
> > true. The apt tool is specific to Debian/Ubuntu, Fedora/Redhat and
> > Suse all use something else.
> >
> > In general, I don't think we should validate the Python environment to
> > this extent, since we cannot fix the problem for the user anyway, only
> > flag it, and since python explodes rather loudly in this case, I think
> > we should be able to leave it up to developers that are savvy enough
> > to build EDK2 to also find the python distutils package for their
> > platform.
> >
> > Note that that doesn't mean we shouldn't document this, and not just
> > for Ubuntu. But I think putting it in the script is overkill.
>
> Yes, I agree
>
> It is also worth noting that python3-distutils is the current debian/ubuntu
> package name. So if we *do* print a message...
>
> > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > Signed-off-by: Bob Feng
> > > Cc: Liming Gao
> > > ---
> > > BaseTools/Tests/RunTests.py | 14 ++
> > > 1 file changed, 14 insertions(+)
> > >
> > > diff --git a/BaseTools/Tests/RunTests.py
> > > b/BaseTools/Tests/RunTests.py index 0dd65632d0..64778db981 100644
> > > --- a/BaseTools/Tests/RunTests.py
> > > +++ b/BaseTools/Tests/RunTests.py
> > > @@ -17,10 +17,24 @@
> > > #
> > > import os
> > > import sys
> > > import unittest
> > >
> > > +distutils_exist = True
> > > +try:
> > > +import distutils.util
> > > +except:
> > > +distutils_exist = False
> > > +
> > > +if not distutils_exist:
> > > +print("""
> > > +python3-distutil packages is missing. Please install it with the
> > > following command:
>
> ... printing "missing python distutils package" and possibly python version
> would be more reliable.
>
> But as Ard points out - this is effectively what python itself will say.
>
> /
> Leif
>
> > > +
> > > +bash$ sudo apt-get install python3-distutil
> > > +""")
> > > +sys.exit(-1)
> > > +
> > > import TestTools
> > >
> > > def GetCTestSuite():
> > > import CToolsTests
> > > return CToolsTests.TheTestSuite()
> > > --
> > > 2.20.1.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
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch] BaseTools: Add python3-distutils Ubuntu package checking
On Wed, Feb 27, 2019 at 09:07:49AM +0100, Ard Biesheuvel wrote:
> On Tue, 26 Feb 2019 at 02:05, Feng, Bob C wrote:
> >
> > https://bugzilla.tianocore.org/show_bug.cgi?id=1509
> >
> > Add python3-distutils Ubuntu package checking.
> >
>
> Hi Bob,
>
> This assumes that all Linux systems are Ubuntu based, which is not
> true. The apt tool is specific to Debian/Ubuntu, Fedora/Redhat and
> Suse all use something else.
>
> In general, I don't think we should validate the Python environment to
> this extent, since we cannot fix the problem for the user anyway, only
> flag it, and since python explodes rather loudly in this case, I think
> we should be able to leave it up to developers that are savvy enough
> to build EDK2 to also find the python distutils package for their
> platform.
>
> Note that that doesn't mean we shouldn't document this, and not just
> for Ubuntu. But I think putting it in the script is overkill.
Yes, I agree
It is also worth noting that python3-distutils is the current
debian/ubuntu package name. So if we *do* print a message...
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Bob Feng
> > Cc: Liming Gao
> > ---
> > BaseTools/Tests/RunTests.py | 14 ++
> > 1 file changed, 14 insertions(+)
> >
> > diff --git a/BaseTools/Tests/RunTests.py b/BaseTools/Tests/RunTests.py
> > index 0dd65632d0..64778db981 100644
> > --- a/BaseTools/Tests/RunTests.py
> > +++ b/BaseTools/Tests/RunTests.py
> > @@ -17,10 +17,24 @@
> > #
> > import os
> > import sys
> > import unittest
> >
> > +distutils_exist = True
> > +try:
> > +import distutils.util
> > +except:
> > +distutils_exist = False
> > +
> > +if not distutils_exist:
> > +print("""
> > +python3-distutil packages is missing. Please install it with the following
> > command:
... printing "missing python distutils package" and possibly python
version would be more reliable.
But as Ard points out - this is effectively what python itself will
say.
/
Leif
> > +
> > +bash$ sudo apt-get install python3-distutil
> > +""")
> > +sys.exit(-1)
> > +
> > import TestTools
> >
> > def GetCTestSuite():
> > import CToolsTests
> > return CToolsTests.TheTestSuite()
> > --
> > 2.20.1.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
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-platforms v2 17/18] Hisilicon/D0x: Delete some header files
Hi Ming, Thank you for this rework. However, can you move it first in the series, so that it's obvious this series contains no changes to these headers (because they have all happened in edk2-non-osi)? Regards, Leif On Wed, Feb 20, 2019 at 03:28:36PM +0800, Ming Huang wrote: > As some interfaces exposed only by implementations in edk2-non-osi, > so delete corresponding header files and modify code to make build. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ming Huang > --- > Platform/Hisilicon/D03/EarlyConfigPeim/EarlyConfigPeimD03.inf > | 1 + > Platform/Hisilicon/D03/Library/OemMiscLib2P/OemMiscLib2PHi1610.inf > | 2 +- > Platform/Hisilicon/D05/EarlyConfigPeim/EarlyConfigPeimD05.inf > | 1 + > Platform/Hisilicon/D05/Library/OemMiscLibD05/OemMiscLibD05.inf > | 1 + > Platform/Hisilicon/D06/EarlyConfigPeim/EarlyConfigPeimD06.inf > | 1 + > Platform/Hisilicon/D06/Library/OemMiscLibD06/OemMiscLibD06.inf > | 1 + > Silicon/Hisilicon/Drivers/Smbios/MemorySubClassDxe/MemorySubClassDxe.inf > | 1 + > > Silicon/Hisilicon/Drivers/Smbios/ProcessorSubClassDxe/ProcessorSubClassDxe.inf > | 1 + > Silicon/Hisilicon/Drivers/Smbios/SmbiosMiscDxe/SmbiosMiscDxe.inf > | 2 +- > Silicon/Hisilicon/Drivers/VirtualEhciPciIo/VirtualEhciPciIo.inf > | 1 + > Silicon/Hisilicon/Hi1610/Drivers/IoInitDxe/IoInitDxe.inf > | 1 + > Silicon/Hisilicon/Library/BmcConfigBootLib/BmcConfigBootLib.inf > | 1 + > Silicon/Hisilicon/Library/I2CLib/I2CLib.inf > | 1 + > Silicon/Hisilicon/Library/I2CLib/I2CLibRuntime.inf > | 1 + > Silicon/Hisilicon/Hi1610/Include/Library/SerdesLib.h > | 22 > Silicon/Hisilicon/Hi1616/Include/Library/SerdesLib.h > | 22 > Silicon/Hisilicon/Include/Library/IpmiCmdLib.h > | 110 --- > Silicon/Hisilicon/Include/Library/LpcLib.h > | 113 > Silicon/Hisilicon/Include/Library/OemAddressMapLib.h > | 45 > Silicon/Hisilicon/Include/Library/PlatformSysCtrlLib.h > | 112 --- > 20 files changed, 14 insertions(+), 426 deletions(-) > > diff --git a/Platform/Hisilicon/D03/EarlyConfigPeim/EarlyConfigPeimD03.inf > b/Platform/Hisilicon/D03/EarlyConfigPeim/EarlyConfigPeimD03.inf > index c65cf7b6dd9f..90e40ae2b393 100644 > --- a/Platform/Hisilicon/D03/EarlyConfigPeim/EarlyConfigPeimD03.inf > +++ b/Platform/Hisilicon/D03/EarlyConfigPeim/EarlyConfigPeimD03.inf > @@ -30,6 +30,7 @@ [Packages] >MdeModulePkg/MdeModulePkg.dec > >ArmPkg/ArmPkg.dec > + Silicon/Hisilicon/HisiliconNonOsi.dec >Silicon/Hisilicon/HisiPkg.dec > > [LibraryClasses] > diff --git > a/Platform/Hisilicon/D03/Library/OemMiscLib2P/OemMiscLib2PHi1610.inf > b/Platform/Hisilicon/D03/Library/OemMiscLib2P/OemMiscLib2PHi1610.inf > index 0fa7fdf80fa8..c0195b2fa9cf 100644 > --- a/Platform/Hisilicon/D03/Library/OemMiscLib2P/OemMiscLib2PHi1610.inf > +++ b/Platform/Hisilicon/D03/Library/OemMiscLib2P/OemMiscLib2PHi1610.inf > @@ -30,7 +30,7 @@ [Packages] >MdePkg/MdePkg.dec >MdeModulePkg/MdeModulePkg.dec >ArmPkg/ArmPkg.dec > - > + Silicon/Hisilicon/HisiliconNonOsi.dec >Silicon/Hisilicon/HisiPkg.dec > > [LibraryClasses] > diff --git a/Platform/Hisilicon/D05/EarlyConfigPeim/EarlyConfigPeimD05.inf > b/Platform/Hisilicon/D05/EarlyConfigPeim/EarlyConfigPeimD05.inf > index 0f6b68d4c88d..e82c9204d5d6 100644 > --- a/Platform/Hisilicon/D05/EarlyConfigPeim/EarlyConfigPeimD05.inf > +++ b/Platform/Hisilicon/D05/EarlyConfigPeim/EarlyConfigPeimD05.inf > @@ -29,6 +29,7 @@ [Packages] >ArmPkg/ArmPkg.dec >MdePkg/MdePkg.dec >MdeModulePkg/MdeModulePkg.dec > + Silicon/Hisilicon/HisiliconNonOsi.dec >Silicon/Hisilicon/HisiPkg.dec > > [LibraryClasses] > diff --git a/Platform/Hisilicon/D05/Library/OemMiscLibD05/OemMiscLibD05.inf > b/Platform/Hisilicon/D05/Library/OemMiscLibD05/OemMiscLibD05.inf > index 022c3e940a31..7ec577530610 100644 > --- a/Platform/Hisilicon/D05/Library/OemMiscLibD05/OemMiscLibD05.inf > +++ b/Platform/Hisilicon/D05/Library/OemMiscLibD05/OemMiscLibD05.inf > @@ -30,6 +30,7 @@ [Packages] >ArmPkg/ArmPkg.dec >MdeModulePkg/MdeModulePkg.dec >MdePkg/MdePkg.dec > + Silicon/Hisilicon/HisiliconNonOsi.dec >Silicon/Hisilicon/HisiPkg.dec > > [LibraryClasses] > diff --git a/Platform/Hisilicon/D06/EarlyConfigPeim/EarlyConfigPeimD06.inf > b/Platform/Hisilicon/D06/EarlyConfigPeim/EarlyConfigPeimD06.inf > index 8296ee02de4e..715a4efadde8 100644 > --- a/Platform/Hisilicon/D06/EarlyConfigPeim/EarlyConfigPeimD06.inf > +++
Re: [edk2] [PATCH edk2-platforms] Silicon/AMD/Styx/Drivers/AcpiPlatformDxe: use correct object ref in DBG2
On Wed, Feb 20, 2019 at 03:27:41PM +0100, Ard Biesheuvel wrote:
> The NamespaceString[] field in the DBG2 table should contain a fully
> qualified ACPI namespace object reference. This was found by fwts.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel
Reviewed-by: Leif Lindholm
> ---
> Silicon/AMD/Styx/Drivers/AcpiPlatformDxe/Dbg2.aslc | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Silicon/AMD/Styx/Drivers/AcpiPlatformDxe/Dbg2.aslc
> b/Silicon/AMD/Styx/Drivers/AcpiPlatformDxe/Dbg2.aslc
> index 07635aa9dd8e..e55119258bac 100644
> --- a/Silicon/AMD/Styx/Drivers/AcpiPlatformDxe/Dbg2.aslc
> +++ b/Silicon/AMD/Styx/Drivers/AcpiPlatformDxe/Dbg2.aslc
> @@ -25,7 +25,7 @@
> #define EFI_ACPI_DBG2_REVISION 0
> #define DBG2_NUM_DEBUG_PORTS 1
> #define DBG2_NUMBER_OF_GENERIC_ADDRESS_REGISTERS 1
> -#define DBG2_NAMESPACESTRING_FIELD_SIZE8
> +#define DBG2_NAMESPACESTRING_FIELD_SIZE9
> #define DBG2_OEM_DATA_FIELD_SIZE 0
> #define DBG2_OEM_DATA_FIELD_OFFSET 0
>
> @@ -33,7 +33,7 @@
> #define DBG2_DEBUG_PORT_SUBTYPE_UEFI 0x0007// Sub type
> for UEFI Debug Port
> #define PL011_UART_LENGTH 0x1000
>
> -#define NAME_STR_UART1 {'C', 'O', 'M', '1', '\0', '\0', '\0', '\0'}
> +#define NAME_STR_UART1 "\\SB.COM1"
> #define NAME_STR_UEFI {'U', 'E', 'F', 'I', '\0', '\0', '\0', '\0'}
>
>
> --
> 2.20.1
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-platforms 0/2] Platform/RaspberryPi3: add RNG support
On Sat, Feb 16, 2019 at 11:34:20AM +0100, Ard Biesheuvel wrote: > Add a RNG driver for the BCM283x and wire it up for the Raspberry Pi 3 > platform so that the random number generator is accessible to the OS > loader via the EFI_RNG_PROTOCOL. This is used by the KASLR implementation > in the arm64 Linux kernel to randomize the placement of various parts of > the kernel. > > Changes since v2: > - move the RNG specific SoC definitions into the Bcm2836.h common header > - add patch that wires up the driver into the RPi3 platform > > Cc: Pete Batard > Cc: Jeremy Linton > Cc: Leif Lindholm For the series: Reviewed-by: Leif Lindholm > Ard Biesheuvel (2): > Silicon/Bcm2836: add random number generator driver > Platform/RaspberryPi3: add RNG driver > > Platform/RaspberryPi/RPi3/RPi3.dsc | 5 + > Platform/RaspberryPi/RPi3/RPi3.fdf | 5 + > Silicon/Broadcom/Bcm283x/Drivers/RngDxe/RngDxe.c| 203 > > Silicon/Broadcom/Bcm283x/Drivers/RngDxe/RngDxe.inf | 45 + > Silicon/Broadcom/Bcm283x/Include/IndustryStandard/Bcm2836.h | 9 + > 5 files changed, 267 insertions(+) > create mode 100644 Silicon/Broadcom/Bcm283x/Drivers/RngDxe/RngDxe.c > create mode 100644 Silicon/Broadcom/Bcm283x/Drivers/RngDxe/RngDxe.inf > > -- > 2.20.1 > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 1/1] EmbeddedPkg/Library: Add VirtualRealTimeClockLib
On Fri, Feb 15, 2019 at 01:12:11AM +0100, Pete Batard wrote: > Hi Leif, > > On 2019-02-12 19:14, Leif Lindholm wrote: > > On Mon, Feb 04, 2019 at 12:47:36PM +, Pete Batard wrote: > > > This is designed to be used on platforms where a a real RTC is not > > > available and relies on an RtcEpochSeconds variable having been set or, > > > if that is not the case, falls back to using the epoch embedded at > > > compilation time. > > > > > > Note that, in order to keep things simple for the setting of the > > > compilation time variable, only GCC environments with UNIX-like shells > > > and where a 'date' command is available are meant to be supported for > > > now. > > > > > > Contributed-under: TianoCore Contribution Agreement 1.1 > > > Signed-off-by: Pete Batard > > > > On the whole, this looks good to me. > > Thanks for the review. > > > One addition we'll need, so that we can build this library standalone > > is an entry in EmbeddedPkg.dsc: > > > > diff --git a/EmbeddedPkg/EmbeddedPkg.dsc b/EmbeddedPkg/EmbeddedPkg.dsc > > index 4d9e6399d5..dc5040e611 100644 > > --- a/EmbeddedPkg/EmbeddedPkg.dsc > > +++ b/EmbeddedPkg/EmbeddedPkg.dsc > > @@ -218,6 +218,7 @@ [Components.common] > > EmbeddedPkg/Library/CoherentDmaLib/CoherentDmaLib.inf > > EmbeddedPkg/Library/NonCoherentDmaLib/NonCoherentDmaLib.inf > > > > EmbeddedPkg/Library/DxeDtPlatformDtbLoaderLibDefault/DxeDtPlatformDtbLoaderLibDefault.inf > > + EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.inf > > EmbeddedPkg/EmbeddedMonotonicCounter/EmbeddedMonotonicCounter.inf > > EmbeddedPkg/RealTimeClockRuntimeDxe/RealTimeClockRuntimeDxe.inf > > Well, I actually tried just that but got a build failure when trying to > compile it (sorry can't remember exactly what was the issue and I don't have > access to an edk2 test env at the moment) and I saw that some libraries in > the same location, such as TimeLib which I believe is used by some > edk2-platforms, are also not referenced at all in the dsc. > > So my take was that not all of the libs are required to be included in the > dsc, especially if they are meant to be referenced directly. Oh, we do want all modules in the .dsc - so that we can easily compile test everything. (And sure, we may have missed some in the past, but we've gotten better at remembering when we add new ones :) With the above line added, I built VirtualRealTimeClockLib succesfully for AARCH64, ARM, IA32 and X64. > If you feel this is important, I can look into adding the .dsc ref again, > though provided I can figure out my issue (which may very well boil down to > me not being too familiar with compiling a standalone EmbeddedPkg) it might > be a week or two before I can send an updated patch. All that should be needed is: build -p EmbeddedPkg/EmbeddedPkg.dsc -m EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.inf Regards, Leif > Regards, > > /Pete > > > I don't have any strong opinions on either of Phil's suggestions, but > > if you could give some feedback on those and fold the above in, this > > could go in. > > > > Regards, > > > > Leif > > > > > --- > > > EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.c > > > | 400 > > > EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.inf > > > | 43 +++ > > > 2 files changed, 443 insertions(+) > > > > > > diff --git > > > a/EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.c > > > b/EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.c > > > new file mode 100644 > > > index ..4c354730d02b > > > --- /dev/null > > > +++ > > > b/EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.c > > > @@ -0,0 +1,400 @@ > > > +/** @file > > > + * > > > + * Implement virtual EFI RealTimeClock runtime services. > > > + * > > > + * Coypright (c) 2019, Pete Batard > > > + * Copyright (c) 2018, Andrei Warkentin > > > + * Copyright (c) 2011-2014, ARM Ltd. All rights reserved. > > > + * Copyright (c) 2008-2010, Apple Inc. All rights reserved. > > > + * Copyright (c) Microsoft 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 dist
Re: [edk2] [PATCH v5 edk2-platforms 00/22] Platform/RaspberryPi: Add Raspberry Pi 3 support
On Tue, Feb 05, 2019 at 04:25:15PM +, Pete Batard wrote: > Changes for v5: > > * Raspberry/Pi3 -> RaspberryPi/RPi3 > * Remove VirtualRealTimeClockLib as well as BUILD_EPOCH macro (use the > upcoming > EmbeddedPkg Virtual RTC from EDK2 instead) > * Use $(PLATFORM_NAME) where possible in .dsc and .fdf > * Update Readme to remove build instructions, describe ACPI limitations, fix > ATF Readme link and split OS installation & test notes into a separate file. > * Add -Wl,--fix-cortex-a53-843419 to LINK_FLAGS > > IMPORTANT: Due to the removal of VirtualRealTimeClockLib this series requires > https://lists.01.org/pipermail/edk2-devel/2019-February/036301.html to have > been applied to your edk2 repository. All of the comments I raised on previous versions of this set have been addressed. The VirtualRtc driver has been moved separately and I have provided feedback on that for the new edk2 version. Other than that, I gave an R-b for the added documentation, but I cannot claim to have properly looked at the rest of the platform support. I'll just mention here formally that I see no reason for Ard not to push this support once he is happy with it (and the Rtc driver is in edk2). Regards, Leif > Regards, > > /Pete > > > Pete Batard (22): > Silicon/Broadcom/Bcm283x: Add interrupt driver > Silicon/Broadcom/Bcm283x: Add GpioLib > Platform/RaspberryPi/RPi3: Add ACPI tables > Platform/RaspberryPi/RPi3: Add reset and memory init libraries > Platform/RaspberryPi/RPi3: Add platform library > Platform/RaspberryPi/RPi3: Add firmware driver > Platform/RaspberryPi/RPi3: Add platform config driver > Platform/RaspberryPi/RPi3: Add SMBIOS driver > Platform/RaspberryPi/RPi3: Add display driver > Platform/RaspberryPi/RPi3: Add console driver > Platform/RaspberryPi/RPi3: Add NV storage driver > Platform/RaspberryPi/RPi3: Add Device Tree driver > Platform/RaspberryPi/RPi3: Add base MMC driver > Platform/RaspberryPi/RPi3: Add Arasan MMC driver > Platform/RaspberryPi/RPi3: Add SD Host driver > Platform/RaspberryPi/RPi3: Add platform boot manager and helper libs > Platform/RaspberryPi/RPi3: Add USB host driver > Platform/RaspberryPi/RPi3 *NON-OSI*: Add ATF binaries > Platform/RaspberryPi/RPi3 *NON-OSI*: Add Device Tree binaries > Platform/RaspberryPi/RPi3 *NON-OSI*: Add logo driver > Platform/RaspberryPi/RPi3: Add platform > Platform/RaspberryPi/RPi3: Add platform readme's > > .../RaspberryPi/RPi3/AcpiTables/AcpiTables.h | 82 + > .../RPi3/AcpiTables/AcpiTables.inf| 46 + > .../RaspberryPi/RPi3/AcpiTables/Csrt.aslc | 332 +++ > .../RaspberryPi/RPi3/AcpiTables/Dbg2.aslc | 34 + > Platform/RaspberryPi/RPi3/AcpiTables/Dsdt.asl | 511 + > .../RaspberryPi/RPi3/AcpiTables/Fadt.aslc | 52 + > .../RaspberryPi/RPi3/AcpiTables/Gtdt.aslc | 33 + > .../RaspberryPi/RPi3/AcpiTables/Madt.aslc | 62 + > Platform/RaspberryPi/RPi3/AcpiTables/Pep.asl | 95 + > Platform/RaspberryPi/RPi3/AcpiTables/Pep.c| 84 + > Platform/RaspberryPi/RPi3/AcpiTables/Pep.h| 126 ++ > Platform/RaspberryPi/RPi3/AcpiTables/Rhpx.asl | 201 ++ > Platform/RaspberryPi/RPi3/AcpiTables/Sdhc.asl | 105 + > Platform/RaspberryPi/RPi3/AcpiTables/Spcr.asl | 53 + > Platform/RaspberryPi/RPi3/AcpiTables/Uart.asl | 158 ++ > .../RaspberryPi/RPi3/DeviceTree/License.txt | 340 +++ > .../RPi3/DeviceTree/bcm2710-rpi-3-b-plus.dtb | Bin 0 -> 25617 bytes > .../RPi3/DeviceTree/bcm2710-rpi-3-b-plus.dts | 1263 > .../RPi3/DeviceTree/bcm2710-rpi-3-b.dtb | Bin 0 -> 25354 bytes > .../RPi3/DeviceTree/bcm2710-rpi-3-b.dts | 1259 +++ > .../ArasanMmcHostDxe/ArasanMmcHostDxe.c | 723 +++ > .../ArasanMmcHostDxe/ArasanMmcHostDxe.h | 50 + > .../ArasanMmcHostDxe/ArasanMmcHostDxe.inf | 52 + > .../RPi3/Drivers/ConfigDxe/ConfigDxe.c| 351 > .../RPi3/Drivers/ConfigDxe/ConfigDxe.inf | 78 + > .../Drivers/ConfigDxe/ConfigDxeFormSetGuid.h | 23 + > .../RPi3/Drivers/ConfigDxe/ConfigDxeHii.uni | 100 + > .../RPi3/Drivers/ConfigDxe/ConfigDxeHii.vfr | 306 +++ > .../RPi3/Drivers/DisplayDxe/ComponentName.c | 222 ++ > .../RPi3/Drivers/DisplayDxe/DisplayDxe.c | 606 ++ > .../RPi3/Drivers/DisplayDxe/DisplayDxe.h | 42 + > .../RPi3/Drivers/DisplayDxe/DisplayDxe.inf| 71 + > .../RPi3/Drivers/DisplayDxe/Screenshot.c | 375 > .../RPi3/Drivers/DwUsbHostDxe/ComponentName.c | 225 ++ > .../RPi3/Drivers/DwUsbHostDxe/DriverBinding.c | 274 +++ > .../RPi3/Drivers/DwUsbHostDxe/DwUsbHostDxe.c | 1635 +++ > .../RPi3/Drivers/DwUsbHostDxe/DwUsbHostDxe.h | 162 ++ > .../Drivers/DwUsbHostDxe/DwUsbHostDxe.inf | 59 + > .../RPi3/Drivers/DwUsbHostDxe/DwcHw.h | 788 +++ > .../RaspberryPi/RPi3/Drivers/FdtDxe/FdtDxe.c | 364 > .../RPi3/Drivers/FdtDxe/FdtDxe.inf| 53 + > .../GraphicsConsoleDxe/ComponentName.c| 183 ++ >
Re: [edk2] [PATCH v5 edk2-platforms 22/22] Platform/RaspberryPi/RPi3: Add platform readme's
On Tue, Feb 05, 2019 at 04:25:37PM +, Pete Batard wrote: > Documentation is split between general plaform data and OS testing > and installation details. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Pete Batard Reviewed-by: Leif Lindholm > --- > Platform/RaspberryPi/RPi3/Readme.md | 167 > Platform/RaspberryPi/RPi3/Systems.md | 65 > Readme.md| 3 + > 3 files changed, 235 insertions(+) > > diff --git a/Platform/RaspberryPi/RPi3/Readme.md > b/Platform/RaspberryPi/RPi3/Readme.md > new file mode 100644 > index ..7434233df0fb > --- /dev/null > +++ b/Platform/RaspberryPi/RPi3/Readme.md > @@ -0,0 +1,167 @@ > +Raspberry Pi Platform > += > + > +# Summary > + > +This is a port of 64-bit Tiano Core UEFI firmware for the Raspberry Pi 3/3B+ > platforms, > +based on [Ard Bisheuvel's > 64-bit](http://www.workofard.com/2017/02/uefi-on-the-pi/) > +and [Microsoft's > 32-bit](https://github.com/ms-iot/RPi-UEFI/tree/ms-iot/Pi3BoardPkg) > +implementations, as maintained by [Andrei > Warkentin](https://github.com/andreiw/RaspberryPiPkg). > + > +This is meant as a generally useful 64-bit ATF + UEFI implementation for the > Raspberry > +Pi 3/3B+ which should be good enough for most kind of UEFI development, as > well as for > +running consummer Operating Systems in such as Linux or Windows. > + > +Raspberry Pi is a trademark of the [Raspberry Pi > Foundation](http://www.raspberrypi.org). > + > +# Status > + > +This firmware, that has been validated to compile against the current > +[edk2](https://github.com/tianocore/edk2)/[edk2-platforms](https://github.com/tianocore/edk2-platforms), > +should be able to boot Linux (SUSE, Ubuntu), NetBSD, FreeBSD as well as > Windows 10 ARM64 > +(full GUI version). > + > +It also provides support for ATF ([Arm Trusted > Platform](https://github.com/ARM-software/arm-trusted-firmware)). > + > +HDMI and the mini-UART serial port can be used for output devices, with > mirrored output. > +USB keyboards and the mini-UART serial port can be used as input. > + > +On a freshly built firmware, the default is to boot the UEFI shell. > +To change the default boot order (for instance to boot uSD media by default) > you > +will need to edit the preferences in _Boot Maintenance Manager_. > + > +For additional information about the tested systems and how to set them up, > +please see [Systems.md](./Systems.md). > + > +# Building > + > +Build instructions from the top level edk2-platforms Readme.md apply. > + > +# Booting the firmware > + > +1. Format a uSD card as FAT32 > +2. Copy the generated `RPI_EFI.fd` firmware onto the partition > +3. Download and copy the following files from > https://github.com/raspberrypi/firmware/tree/master/boot > + - `bootcode.bin` > + - `fixup.dat` > + - `start.elf` > +4. Create a `config.txt` with the following content: > + ``` > + arm_control=0x200 > + enable_uart=1 > + armstub=RPI_EFI.fd > + disable_commandline_tags=1 > + ``` > +5. Insert the uSD card and power up the Pi. > + > +Note that if you have a model 3+ or a model 3 where you enabled USB boot > through OTP > +(see > [here](https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/msd.md)) > +you may also be able to boot from a FAT32 USB driver rather than uSD. > + > +# Notes > + > +## ARM Trusted Firmware (ATF) > + > +The ATF binaries being used were compiled from the latest ATF source. > +No aleration to the official source have been applied. > + > +For more details on the ATF compilation, see the > [Readme](./TrustedFirmware/Readme.md) > +in the `TrustedFirmware/` directory. > + > +## Custom Device Tree > + > +The default Device Tree included in the firmware is the one for a Raspberry > Pi 3 Model B (not B+). > +If you want to use a different Device Tree, to boot a Pi 3 Model B+ for > instance (for which a > +DTB is also provided under `DeviceTree/`), you should copy the relevant > `.dtb` into the root of > +the SD or USB, and then edit your `config.txt` so that it looks like: > + > +``` > +(...) > +disable_commandline_tags=2 > +device_tree_address=0x1 > +device_tree_end=0x2 > +device_tree=bcm2710-rpi-3-b-plus.dtb > +``` > + > +Note: the address range **must** be `[0x1:0x2]`. > +`dtoverlay` and `dtparam` parameters are also supported **when** providing a > Device Tree`. > + > +## Custom `bootargs` > + > +This firmware will honor the command line passed by the GPU via > `cmdline.txt`. > + > +Note, that the ultimate contents of `/chosen/
Re: [edk2] [PATCH edk2-platforms v1 01/16] Hisilicon/D0x: Remove SerdesLib
On Wed, Feb 13, 2019 at 02:36:11PM +0800, Ming Huang wrote: > > Should it not then also delete #include from > > Platform/Hisilicon/D06/Library/OemMiscLibD06/BoardFeatureD06.c, > > Platform/Hisilicon/D06/Library/OemMiscLibD06/OemMiscLibD06.c and > > Silicon/Hisilicon/Drivers/Smbios/SmbiosMiscDxe/Type09/MiscSystemSlotDesignationFunction.c > > ? > > > > Meanwhile, > > Platform/Hisilicon/D03/Library/OemMiscLib2P/BoardFeature2PHi1610.c > > and > > Platform/Hisilicon/D05/Library/OemMiscLibD05/BoardFeatureD05.c > > both include this header, but > > Platform/Hisilicon/D03/Library/OemMiscLib2P/OemMiscLib2PHi1610.inf > > and > > Platform/Hisilicon/D05/Library/OemMiscLibD05/OemMiscLibD05.inf > > do not declare the dependency. > > OemMiscLibD06.c can remove the SerdesLib.h. As using the definitions in > SerdesLib.h, other .c files can not remove the header file. If they are using definitions from the library header, but not the library itself, there is something suspicious about the code structuring. But in the meantime, if they are referencing library header files, they need to list those libraryclasses in their .inf. > > Can you investigate and submit an updated patch addressing all of the > > unnecessary references? > > This may takes a lot of time, as Hi1620(D06) is our important project, > maybe we should focus on D06. Feel free to submit deletions for all and any platforms you are unwilling to maintain. Best Regards, Leif > Thanks > > > > > Best Regards, > > > > Leif > > > >> Contributed-under: TianoCore Contribution Agreement 1.1 > >> Signed-off-by: Ming Huang > >> --- > >> Platform/Hisilicon/D06/D06.dsc | 2 -- > >> Silicon/Hisilicon/Drivers/Smbios/SmbiosMiscDxe/SmbiosMiscDxe.inf | 1 - > >> 2 files changed, 3 deletions(-) > >> > >> diff --git a/Platform/Hisilicon/D06/D06.dsc > >> b/Platform/Hisilicon/D06/D06.dsc > >> index 396bd03c9d24..cbbd99e4a659 100644 > >> --- a/Platform/Hisilicon/D06/D06.dsc > >> +++ b/Platform/Hisilicon/D06/D06.dsc > >> @@ -64,8 +64,6 @@ [LibraryClasses.common] > >> > >>CpldIoLib|Silicon/Hisilicon/Library/CpldIoLib/CpldIoLib.inf > >> > >> - > >> SerdesLib|Silicon/Hisilicon/Hi1620/Library/Hi1620Serdes/Hi1620SerdesLib.inf > >> - > >>TimeBaseLib|EmbeddedPkg/Library/TimeBaseLib/TimeBaseLib.inf > >> > >> RealTimeClockLib|Silicon/Hisilicon/Library/M41T83RealTimeClockLib/M41T83RealTimeClockLib.inf > >> > >> OemMiscLib|Platform/Hisilicon/D06/Library/OemMiscLibD06/OemMiscLibD06.inf > >> diff --git > >> a/Silicon/Hisilicon/Drivers/Smbios/SmbiosMiscDxe/SmbiosMiscDxe.inf > >> b/Silicon/Hisilicon/Drivers/Smbios/SmbiosMiscDxe/SmbiosMiscDxe.inf > >> index 61cead7779b9..8e5c56fa41fd 100644 > >> --- a/Silicon/Hisilicon/Drivers/Smbios/SmbiosMiscDxe/SmbiosMiscDxe.inf > >> +++ b/Silicon/Hisilicon/Drivers/Smbios/SmbiosMiscDxe/SmbiosMiscDxe.inf > >> @@ -77,7 +77,6 @@ [LibraryClasses] > >> > >>IpmiCmdLib > >> > >> - SerdesLib > >> > >> [Protocols] > >>gEfiSmbiosProtocolGuid # PROTOCOL ALWAYS_CONSUMED > >> -- > >> 2.9.5 > >> ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-platforms v1 09/16] Hisilicon/D06: Add PCI_OSC_SUPPORT
On Wed, Feb 13, 2019 at 10:59:17AM +0800, Ming Huang wrote: > On 2/12/2019 2:51 AM, Leif Lindholm wrote: > > On Fri, Feb 01, 2019 at 09:34:29PM +0800, Ming Huang wrote: > >> Add PCI_OSC_SUPPORT for remaining host bridges to remove fail > >> output in kernel: > >> [ 103.478893] acpi PNP0A08:01: _OSC failed (AE_NOT_FOUND); > >> > >> Contributed-under: TianoCore Contribution Agreement 1.1 > >> Signed-off-by: Ming Huang > >> --- > >> Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Dsdt/Hi1620Pci.asl | 64 > >> > >> 1 file changed, 64 insertions(+) > >> > >> diff --git a/Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Dsdt/Hi1620Pci.asl > >> b/Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Dsdt/Hi1620Pci.asl > >> index 4d9d9d95be68..86d8728b82f2 100644 > >> --- a/Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Dsdt/Hi1620Pci.asl > >> +++ b/Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Dsdt/Hi1620Pci.asl > >> @@ -17,6 +17,50 @@ > >> **/ > >> > >> //#include "ArmPlatform.h" > >> + > >> +/* > >> + See ACPI 6.1 Spec, 6.2.11, PCI Firmware Spec 3.0, 4.5 > >> +*/ > >> +#define PCI_OSC_SUPPORT() \ > > > > PCI0 and PCI6 already have _OSC entries. > > This macro ends up being used for 1-5 and 7-B. > > So calling it PCI_OSC_SUPPORT seems somewhat misleading. > > > > Then again, there is a lot of similarities between this macro and the > > existing entries. Could the same macro be used for 0 and 6? Or could > > the macro be split up into multiple parts and reused? > > When I make this patch, I try to rewrite PCI0/6 with the same macro, but > the macro don't support parameter. For spliting up multiple parts, if modify > something in future, the parts need to split up to smaller parts. So, if > need to rewrite PCI0/6 with macro, is it applicable to add another macro > PCI_OSC_SUPPORT_HOTPLUG? Yes, that sounds like a good solution to me. Regards, Leif ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 1/1] EmbeddedPkg/Library: Add VirtualRealTimeClockLib
On Mon, Feb 04, 2019 at 12:47:36PM +, Pete Batard wrote:
> This is designed to be used on platforms where a a real RTC is not
> available and relies on an RtcEpochSeconds variable having been set or,
> if that is not the case, falls back to using the epoch embedded at
> compilation time.
>
> Note that, in order to keep things simple for the setting of the
> compilation time variable, only GCC environments with UNIX-like shells
> and where a 'date' command is available are meant to be supported for
> now.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Pete Batard
On the whole, this looks good to me.
One addition we'll need, so that we can build this library standalone
is an entry in EmbeddedPkg.dsc:
diff --git a/EmbeddedPkg/EmbeddedPkg.dsc b/EmbeddedPkg/EmbeddedPkg.dsc
index 4d9e6399d5..dc5040e611 100644
--- a/EmbeddedPkg/EmbeddedPkg.dsc
+++ b/EmbeddedPkg/EmbeddedPkg.dsc
@@ -218,6 +218,7 @@ [Components.common]
EmbeddedPkg/Library/CoherentDmaLib/CoherentDmaLib.inf
EmbeddedPkg/Library/NonCoherentDmaLib/NonCoherentDmaLib.inf
EmbeddedPkg/Library/DxeDtPlatformDtbLoaderLibDefault/DxeDtPlatformDtbLoaderLibDefault.inf
+ EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.inf
EmbeddedPkg/EmbeddedMonotonicCounter/EmbeddedMonotonicCounter.inf
EmbeddedPkg/RealTimeClockRuntimeDxe/RealTimeClockRuntimeDxe.inf
I don't have any strong opinions on either of Phil's suggestions, but
if you could give some feedback on those and fold the above in, this
could go in.
Regards,
Leif
> ---
> EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.c |
> 400
> EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.inf |
> 43 +++
> 2 files changed, 443 insertions(+)
>
> diff --git
> a/EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.c
> b/EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.c
> new file mode 100644
> index ..4c354730d02b
> --- /dev/null
> +++ b/EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.c
> @@ -0,0 +1,400 @@
> +/** @file
> + *
> + * Implement virtual EFI RealTimeClock runtime services.
> + *
> + * Coypright (c) 2019, Pete Batard
> + * Copyright (c) 2018, Andrei Warkentin
> + * Copyright (c) 2011-2014, ARM Ltd. All rights reserved.
> + * Copyright (c) 2008-2010, Apple Inc. All rights reserved.
> + * Copyright (c) Microsoft 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.
> + *
> + * Based on
> ArmPlatformPkg/Library/PL031RealTimeClockLib/PL031RealTimeClockLib.inf
> + *
> + **/
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +STATIC CONST CHAR16 mEpochVariableName[] = L"RtcEpochSeconds";
> +STATIC CONST CHAR16 mTimeZoneVariableName[] = L"RtcTimeZone";
> +STATIC CONST CHAR16 mDaylightVariableName[] = L"RtcDaylight";
> +
> +/**
> + Returns the current time and date information, and the time-keeping
> capabilities
> + of the virtual RTC.
> +
> + @param Time A pointer to storage to receive a snapshot
> of the current time.
> + @param Capabilities An optional pointer to a buffer to receive
> the real time clock
> + device's capabilities.
> +
> + @retval EFI_SUCCESS The operation completed successfully.
> + @retval EFI_INVALID_PARAMETER Time is NULL.
> + @retval EFI_DEVICE_ERROR The time could not be retrieved due to
> hardware error.
> +
> +**/
> +EFI_STATUS
> +EFIAPI
> +LibGetTime (
> + OUT EFI_TIME *Time,
> + OUT EFI_TIME_CAPABILITIES *Capabilities
> + )
> +{
> + EFI_STATUS Status;
> + UINT32 EpochSeconds;
> + INT16 TimeZone;
> + UINT8 Daylight;
> + UINT64 Freq;
> + UINT64 Counter;
> + UINT64 Remainder;
> + UINTN ElapsedSeconds;
> + UINTN Size;
> +
> + if (Time == NULL) {
> +return EFI_INVALID_PARAMETER;
> + }
> +
> + // Get the counter frequency
> + Freq = GetPerformanceCounterProperties (NULL, NULL);
> + if (Freq == 0) {
> +return EFI_DEVICE_ERROR;
> + }
> +
> + // Get the epoch time from non-volatile storage
> + Size = sizeof (UINTN);
> + ElapsedSeconds = 0;
> + Status = EfiGetVariable (
> + (CHAR16 *)mEpochVariableName,
> + ,
> + NULL,
> + ,
> + (VOID *)
> + );
> + // Fall back to compilation-time epoch if not set
> + if (EFI_ERROR (Status))
Re: [edk2] [PATCH edk2-platforms v1 11/16] Hisilicon/D06: Add Setup Item "Support DPC"
On Tue, Feb 12, 2019 at 11:22:24PM +0800, Ming Huang wrote: > On 2/12/2019 3:46 AM, Leif Lindholm wrote: > > On Fri, Feb 01, 2019 at 09:34:31PM +0800, Ming Huang wrote: > >> Add setup item "Support DPC" to enable or disable PCIe DPC > >> (Downstream Port Containment). > > > > This patch also seems to disable the SRIOV configuration and delete a > > lot of ports. Can you explain how this is related? > > The pcie menu is suppressed for original code as these menus are not ready, > this patch remove the suppression for pcie menu, so delete these menus for > now. OK. Please update subject and commit message to reflect these additional changes. / Leif ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-platforms v1 10/16] Hisilicon/D06: Modify for M7 self-Adapte support
On Tue, Feb 12, 2019 at 11:14:43PM +0800, Ming Huang wrote:
>
>
> On 2/12/2019 3:28 AM, Leif Lindholm wrote:
> > On Fri, Feb 01, 2019 at 09:34:30PM +0800, Ming Huang wrote:
> >> As new M7(Cortex-M7) firmware support self-adapte, so do not
> >> need BIOS to implement some function, remove useless funtions
> >> and report CPU0/CPU1 Nic NCL offset to M7.
> >
> > I don't really care that some other device in the system is a
> > Cortex-A7. What is its function? Is it an SCP, an MCP, ?
> > Please describe its function rather than its implementation.
>
> M7 is used for HNS(Hisilicon network system), cpu access the network
> component via M7.
Sure. But does customer documentation documentation refer to it as
"M7"?
> >
> > What are the external dependencies?
> > Is this addressed by one of the patches for edk2-non-osi?
>
> This is depend on M7 firmware which will include in hpm file.
So we don't get it when using Capsule Update?
What would be the implication of installing system firmware with the
below change on a system that had not had the corresponding M7
firmware update?
/
Leif
> >
> > More style issues below.
> >
> >>
> >> Contributed-under: TianoCore Contribution Agreement 1.1
> >> Signed-off-by: Ming Huang
> >> ---
> >> Platform/Hisilicon/D06/Library/OemNicLib/OemNicLib.c | 272
> >>
> >> 1 file changed, 45 insertions(+), 227 deletions(-)
> >>
> >> diff --git a/Platform/Hisilicon/D06/Library/OemNicLib/OemNicLib.c
> >> b/Platform/Hisilicon/D06/Library/OemNicLib/OemNicLib.c
> >> index aaf990216982..9bf274e1b991 100644
> >> --- a/Platform/Hisilicon/D06/Library/OemNicLib/OemNicLib.c
> >> +++ b/Platform/Hisilicon/D06/Library/OemNicLib/OemNicLib.c
> >> @@ -21,44 +21,21 @@
> >> #include
> >>
> >> #define CPU2_SFP2_100G_CARD_OFFSET 0x25
> >> -#define CPU1_SFP1_LOCATE_OFFSET 0x16
> >> -#define CPU1_SFP0_LOCATE_OFFSET 0x12
> >> -#define CPU2_SFP1_LOCATE_OFFSET 0x21
> >> -#define CPU2_SFP0_LOCATE_OFFSET 0x19
> >> -#define CPU2_SFP2_10G_GE_CARD_OFFSET 0x25
> >>
> >> -#define SFP_10G_SPEED 10
> >> -#define SFP_25G_SPEED 25
> >> -#define SFP_100G_SPEED 100
> >> -#define SFP_GE_SPEED1
> >> -
> >> -#define SFP_GE_SPEED_VAL_VENDOR_FINISAR 0x0C
> >> -#define SFP_GE_SPEED_VAL0x0D
> >> -#define SFP_10G_SPEED_VAL 0x67
> >> -#define SFP_25G_SPEED_VAL 0xFF
> >> +#define SOCKET1_NET_PORT_100G 1
> >> +#define SOCKET0_NET_PORT_NUM 4
> >> +#define SOCKET1_NET_PORT_NUM 2
> >>
> >> #define CARD_PRESENT_100G (BIT7)
> >> -#define CARD_PRESENT_10G(BIT0)
> >> -#define SELECT_SFP_BY_INDEX(index) (1 << (index - 1))
> >> -#define SPF_SPEED_OFFSET12
> >> -
> >> -#define SFP_DEVICE_ADDRESS 0x50
> >> -#define CPU1_9545_I2C_ADDR 0x70
> >> -#define CPU2_9545_I2C_ADDR 0x71
> >> -
> >> -#define FIBER_PRESENT 0
> >> -#define CARD_PRESENT 1
> >> -#define I2C_PORT_SFP 4
> >> -#define CPU2_I2C_PORT_SFP 5
> >> -
> >> -#define SOCKET_0 0
> >> -#define SOCKET_1 1
> >> #define EEPROM_I2C_PORT 4
> >> #define EEPROM_PAGE_SIZE 0x40
> >> #define MAC_ADDR_LEN 6
> >> #define I2C_OFFSET_EEPROM_ETH0 (0xc00)
> >> #define I2C_SLAVEADDR_EEPROM (0x52)
> >>
> >> +#define SRAM_NIC_NCL1_OFFSET_FLAG 0xA0E87FE0
> >> +#define SRAM_NIC_NCL2_OFFSET_FLAG 0xA0E87FE4
> >
> > Is this just a hard-coded address in SRAM? Where is it specified?
> > I don't think "_FLAG" is the correct name for this #define - this is
> > the actual offset value. So _OFFSET_ADDRESS would be more descriptive.
>
> Yes, M7 firmware will read this two sram addresses.
>
> >
> >> +
> >> #pragma pack(1)
> >> typedef struct {
> >>UINT16 Crc16;
> >> @@ -114,204 +91,6 @@ UINT16 CrcTable16[256] = {
> >>0x6E17, 0x7E36, 0x4E55, 0x5E74, 0x2E93, 0x3EB2, 0x0ED1, 0x1EF0,
> >> };
> >>
> >> -EFI_STATUS
> >> -GetSfpSpeed (
> >> - UINT16 Socket,
> >> - UINT16 SfpNum,
> >> - UINT8* FiberSpeed
> >> - )
> >> -{
> >> - EFI_STATUS Status;
> >> -
Re: [edk2] [PATCH edk2-non-osi v1 7/7] Hisilicon/D06: Add Setup Item "Support DPC"
On Fri, Feb 01, 2019 at 10:25:07PM +0800, Ming Huang wrote: > Add setup item "Support DPC" to enable or disable PCIe DPC > (Downstream Port Containment). > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ming Huang Reviewed-by: Leif Lindholm > --- > Platform/Hisilicon/D06/Drivers/IoInitDxe/IoInitDxe.efi | Bin 232832 -> > 226784 bytes > 1 file changed, 0 insertions(+), 0 deletions(-) > > diff --git a/Platform/Hisilicon/D06/Drivers/IoInitDxe/IoInitDxe.efi > b/Platform/Hisilicon/D06/Drivers/IoInitDxe/IoInitDxe.efi > index e32c056..4511f6b 100644 > Binary files a/Platform/Hisilicon/D06/Drivers/IoInitDxe/IoInitDxe.efi and > b/Platform/Hisilicon/D06/Drivers/IoInitDxe/IoInitDxe.efi differ > -- > 2.9.5 > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-non-osi v1 5/7] Hisilicon/D06: Use new flash layout
On Fri, Feb 01, 2019 at 10:25:05PM +0800, Ming Huang wrote: > In new flash layout, BIOS fd change from offset 1M to 8M in 16M > spi flash. I think I covered all of the layout questions in the corresponding edk2-platforms patch. > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ming Huang > --- > Platform/Hisilicon/D06/CustomData.Fv | Bin 0 > -> 65536 bytes > Platform/Hisilicon/D06/Library/OemAddressMapD06/OemAddressMapD06.lib | Bin > 61892 -> 31696 bytes But can you explain why the size of this lib is _halved_? / Leif > Platform/Hisilicon/D06/Sec/FVMAIN_SEC.Fv | Bin > 1048576 -> 1048576 bytes > 3 files changed, 0 insertions(+), 0 deletions(-) > > diff --git a/Platform/Hisilicon/D06/CustomData.Fv > b/Platform/Hisilicon/D06/CustomData.Fv > new file mode 100644 > index 000..22ef62b > Binary files /dev/null and b/Platform/Hisilicon/D06/CustomData.Fv differ > diff --git > a/Platform/Hisilicon/D06/Library/OemAddressMapD06/OemAddressMapD06.lib > b/Platform/Hisilicon/D06/Library/OemAddressMapD06/OemAddressMapD06.lib > index 7e1f6b2..851c2c3 100644 > Binary files > a/Platform/Hisilicon/D06/Library/OemAddressMapD06/OemAddressMapD06.lib and > b/Platform/Hisilicon/D06/Library/OemAddressMapD06/OemAddressMapD06.lib differ > diff --git a/Platform/Hisilicon/D06/Sec/FVMAIN_SEC.Fv > b/Platform/Hisilicon/D06/Sec/FVMAIN_SEC.Fv > index 247e44e..7f75bc6 100644 > Binary files a/Platform/Hisilicon/D06/Sec/FVMAIN_SEC.Fv and > b/Platform/Hisilicon/D06/Sec/FVMAIN_SEC.Fv differ > -- > 2.9.5 > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-non-osi v1 4/7] Hisilicon/D06: Support PCIe local RAS
On Fri, Feb 01, 2019 at 10:25:04PM +0800, Ming Huang wrote: > Add some registers configuration in PcieRasInitDxe and add PCIe > local RAS interrupt handle in trusted firmware to support PCIe > local RAS. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ming Huang Reviewed-by: Leif Lindholm > --- > Platform/Hisilicon/D06/Drivers/PcieRasInitDxe/PcieRasInitDxe.efi | Bin 21248 > -> 22048 bytes > Platform/Hisilicon/D06/bl1.bin | Bin 12432 > -> 12432 bytes > Platform/Hisilicon/D06/fip.bin | Bin > 113450 -> 121866 bytes > 3 files changed, 0 insertions(+), 0 deletions(-) > > diff --git a/Platform/Hisilicon/D06/Drivers/PcieRasInitDxe/PcieRasInitDxe.efi > b/Platform/Hisilicon/D06/Drivers/PcieRasInitDxe/PcieRasInitDxe.efi > index 0e22237..f9ceff2 100644 > Binary files > a/Platform/Hisilicon/D06/Drivers/PcieRasInitDxe/PcieRasInitDxe.efi and > b/Platform/Hisilicon/D06/Drivers/PcieRasInitDxe/PcieRasInitDxe.efi differ > diff --git a/Platform/Hisilicon/D06/bl1.bin b/Platform/Hisilicon/D06/bl1.bin > index 416535f..d0970e5 100644 > Binary files a/Platform/Hisilicon/D06/bl1.bin and > b/Platform/Hisilicon/D06/bl1.bin differ > diff --git a/Platform/Hisilicon/D06/fip.bin b/Platform/Hisilicon/D06/fip.bin > index c9b7ca0..795cfb5 100644 > Binary files a/Platform/Hisilicon/D06/fip.bin and > b/Platform/Hisilicon/D06/fip.bin differ > -- > 2.9.5 > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-non-osi v1 1/7] Hisilicon/D06: Optimize SAS driver for reducing boot time
Change the subject line to: Hisilicon/D06: remove PCI enumeration dependency from SAS driver On Fri, Feb 01, 2019 at 10:25:01PM +0800, Ming Huang wrote: > SAS controller is always existed, so accessing SAS register don't > depend on PciBusDxe (pci enumeration). Modify SAS driver remove the > dependence on pci enumeration. And mention here that this is done to improve boot times. > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ming Huang > --- > Platform/Hisilicon/D06/Drivers/Sas/SasDriverDxe.depex | Bin 216 -> 36 bytes What are the remaining depexes? Do we have the opportunity to get rid of this .depex? / Leif > Platform/Hisilicon/D06/Drivers/Sas/SasDriverDxe.efi | Bin 221312 -> 220640 > bytes > 2 files changed, 0 insertions(+), 0 deletions(-) > > diff --git a/Platform/Hisilicon/D06/Drivers/Sas/SasDriverDxe.depex > b/Platform/Hisilicon/D06/Drivers/Sas/SasDriverDxe.depex > index 1a5bc1e..e076777 100644 > Binary files a/Platform/Hisilicon/D06/Drivers/Sas/SasDriverDxe.depex and > b/Platform/Hisilicon/D06/Drivers/Sas/SasDriverDxe.depex differ > diff --git a/Platform/Hisilicon/D06/Drivers/Sas/SasDriverDxe.efi > b/Platform/Hisilicon/D06/Drivers/Sas/SasDriverDxe.efi > index ac6bae7..4a29e8c 100644 > Binary files a/Platform/Hisilicon/D06/Drivers/Sas/SasDriverDxe.efi and > b/Platform/Hisilicon/D06/Drivers/Sas/SasDriverDxe.efi differ > -- > 2.9.5 > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-platforms v1 04/16] Hisilicon/D06: Fix access variable fail issue
On Fri, Feb 01, 2019 at 09:34:24PM +0800, Ming Huang wrote: > From: Jason Zhang > > BmcWdtEnable is a field of OemConfigData structure, need have > runtime service attribution if use it during exit boot service This sounds like a very shady thing to do. Which module is seeing issues, and what issues are it seeing, during ExitBootServices? / Leif > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ming Huang > --- > Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfigVfr.vfr | 2 +- > Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfig.c | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfigVfr.vfr > b/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfigVfr.vfr > index 470e9ace3dcf..08236704fbfe 100644 > --- a/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfigVfr.vfr > +++ b/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfigVfr.vfr > @@ -23,7 +23,7 @@ formset >help = STRING_TOKEN(STR_OEM_CONFIG), >classguid = gEfiIfrFrontPageGuid, // for MdeModule Bds. >efivarstore OEM_CONFIG_DATA, > -attribute = EFI_VARIABLE_BOOTSERVICE_ACCESS | EFI_VARIABLE_NON_VOLATILE, > +attribute = EFI_VARIABLE_BOOTSERVICE_ACCESS | EFI_VARIABLE_NON_VOLATILE > | EFI_VARIABLE_RUNTIME_ACCESS, > name = OemConfig, > guid = gOemConfigGuid; > > diff --git a/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfig.c > b/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfig.c > index 012d45bc0214..6668103af027 100644 > --- a/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfig.c > +++ b/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfig.c > @@ -316,7 +316,7 @@ OemConfigUiLibConstructor ( >Status = gRT->SetVariable ( >OEM_CONFIG_NAME, >, > - EFI_VARIABLE_NON_VOLATILE | > EFI_VARIABLE_BOOTSERVICE_ACCESS, > + EFI_VARIABLE_NON_VOLATILE | > EFI_VARIABLE_BOOTSERVICE_ACCESS | EFI_VARIABLE_RUNTIME_ACCESS, >sizeof (OEM_CONFIG_DATA), > >); > -- > 2.9.5 > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-platforms v1 03/16] Hisilicon/D06: Optimize SAS driver for reducing boot time
On Fri, Feb 01, 2019 at 09:34:23PM +0800, Ming Huang wrote: > SAS controller is always existed, so accessing SAS register don't > depend on PciBusDxe (pci enumeration). > Move the SAS module early in D06.fdf for dispatching SAS driver > early. This can avoid wait in BDS normally and reduce boot time. > > This patch is relative with SasDriverDxe in edk2-non-osi. I think you are saying that this change is only valid after the update to SasDriverDxe in edk2-non-osi has been applied? Or does it mean that it only improves performance after that edk2-non-osi patch has been applied? Please be more explicit in the commit message. Other than that. I'm OK with this patch. / Leif > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ming Huang > --- > Platform/Hisilicon/D06/D06.fdf | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/Platform/Hisilicon/D06/D06.fdf b/Platform/Hisilicon/D06/D06.fdf > index a937660a09e2..d495ad7f264c 100644 > --- a/Platform/Hisilicon/D06/D06.fdf > +++ b/Platform/Hisilicon/D06/D06.fdf > @@ -165,6 +165,7 @@ [FV.FvMain] >INF MdeModulePkg/Universal/PCD/Dxe/Pcd.inf > >INF Platform/Hisilicon/D06/Drivers/IoInitDxe/IoInitDxe.inf > + INF Platform/Hisilicon/D06/Drivers/Sas/SasDxeDriver.inf ># ># PI DXE Drivers producing Architectural Protocols (EFI Services) ># > @@ -296,7 +297,6 @@ [FV.FvMain] ># >INF Platform/Hisilicon/D06/Drivers/Sm750Dxe/UefiSmi.inf >INF MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressDxe.inf > - INF Platform/Hisilicon/D06/Drivers/Sas/SasDxeDriver.inf >INF MdeModulePkg/Bus/Pci/SataControllerDxe/SataControllerDxe.inf >INF MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.inf >INF MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf > -- > 2.9.5 > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-platforms v1 08/16] Hisilicon/D06: Change HCCS speed from 30G to 26G
On Tue, Feb 12, 2019 at 10:45:05PM +0800, Ming Huang wrote:
>
>
> On 2/12/2019 2:36 AM, Leif Lindholm wrote:
> > On Fri, Feb 01, 2019 at 09:34:28PM +0800, Ming Huang wrote:
> >> Follow chip team suggestion to change HCCS(Huawei Cache-Coherent
> >> System) speed from 30G to 26G, this modification can avoid some
> >> unstable stress issue.
> >>
> >> Contributed-under: TianoCore Contribution Agreement 1.1
> >> Signed-off-by: Ming Huang
> >> ---
> >> Silicon/Hisilicon/Include/Library/OemMiscLib.h | 10
> >> ++
> >> Platform/Hisilicon/D06/Library/OemMiscLibD06/OemMiscLibD06.c | 8
> >> 2 files changed, 18 insertions(+)
> >>
> >> diff --git a/Silicon/Hisilicon/Include/Library/OemMiscLib.h
> >> b/Silicon/Hisilicon/Include/Library/OemMiscLib.h
> >> index dfac87d635d9..3c0cd0319122 100644
> >> --- a/Silicon/Hisilicon/Include/Library/OemMiscLib.h
> >> +++ b/Silicon/Hisilicon/Include/Library/OemMiscLib.h
> >> @@ -22,6 +22,11 @@
> >> #include
> >> #include
> >>
> >> +#define HCCS_PLL_VALUE_3000 0x52240781
> >> +#define HCCS_PLL_VALUE_2600 0x52240681
> >> +#define HCCS_PLL_VALUE_2800 0x52240701
> >
> > Could these be described by a proper macro instead of just values?
> > A cursory glance suggests that an increase of 0x80 in the lower half
> > means 200MHz.
> >
> > If not, please sort them by frequency, ascending.
>
> As the macros have use in other files, I prefer sort them by frequency.
>
> >
> >> +
> >> +
> >> #define PCIEDEVICE_REPORT_MAX 8
> >> #define MAX_PROCESSOR_SOCKETS MAX_SOCKET
> >> #define MAX_MEMORY_CHANNELSMAX_CHANNEL
> >> @@ -55,4 +60,9 @@ extern EFI_STRING_ID
> >> gDimmToDevLocator[MAX_SOCKET][MAX_CHANNEL][MAX_DIMM];
> >> EFI_HII_HANDLE EFIAPI OemGetPackages ();
> >> UINTN OemGetCpuFreq (UINT8 Socket);
> >>
> >> +UINTN
> >> +OemGetHccsFreq (
> >> + VOID
> >> + );
> >> +
> >> #endif
> >> diff --git a/Platform/Hisilicon/D06/Library/OemMiscLibD06/OemMiscLibD06.c
> >> b/Platform/Hisilicon/D06/Library/OemMiscLibD06/OemMiscLibD06.c
> >> index 8f2ac308c7b9..83e53cfeb5dd 100644
> >> --- a/Platform/Hisilicon/D06/Library/OemMiscLibD06/OemMiscLibD06.c
> >> +++ b/Platform/Hisilicon/D06/Library/OemMiscLibD06/OemMiscLibD06.c
> >> @@ -223,3 +223,11 @@ UINTN OemGetCpuFreq (UINT8 Socket)
> >>}
> >> }
> >>
> >> +UINTN
> >> +OemGetHccsFreq (
> >
> > The commit message describes this patch as changing the frequency.
> > The actual code simply returns a value.
> > The name of the function returning this value suggests the value is a
> > frequency>
> >> + VOID
> >> + )
> >> +{
> >> + return HCCS_PLL_VALUE_2600;
> >
> > But the constant returned is named suggesting a PLL configuration
> > value. And the frequency suggested by the name is many orders of
> > magnitude below that described by the commit message.
>
> Yes, the macros and function name are not very matched.
> I plan to modify the commit title and message:
> Hisilicon/D06: Use HCCS speed with 2.6G
>
> Follow chip team suggestion, HCCS(Huawei Cache-Coherent System)
> may be unstable while speed is 3.0G, so use 2.6G to avoid some
> unstable stress issue.
This all sounds good, thanks.
/
Leif
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-non-osi v1 2/7] Hisilicon/D0x: Rename StartupAp() function
On Tue, Feb 12, 2019 at 08:07:52PM +0800, Ming Huang wrote: > >> For D06 library, we use the same source code to support all Hi1620 > >> projects, > >> include product projects,so there are some modify for this, like support > >> 3 sockets, 4 sockets and remove some useless functions. > > > > So please reword the subject line of this commit to explain it is an > > overall update of PlatformSysCtrlLib - including which bits are dropped. > > > > And I think this makes a good argument for moving the header files for > > binary-only libraries from edk2-platforms to edk2-non-osi. > > If you do that in a separate patch before this one, you won't need to > > include as much detail in the commit message as you will otherwise. > > Do youe mean move PlatformSysCtrlLib.h, OemAddressMapLib.h and LpcLib.h to > edk2-non-osi? Yes. Any interfaces exposed _only_ by implementations in edk2-non-osi. If there are any interfaces _also_ exposed by implementations in edk2-platforms, then I would prefer for them to remain in edk2-platforms. Ideally, this would also include (the multiple) SerdesLib.h, IpmiCmdLib.h, and possibly others. Regards, Leif ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-non-osi v1 3/7] Hisilicon/D06: Update Mbigen and gic RAS register
On Tue, Feb 12, 2019 at 07:42:55PM +0800, Ming Huang wrote: > > > On 2/12/2019 5:38 AM, Leif Lindholm wrote: > > On Fri, Feb 01, 2019 at 10:25:03PM +0800, Ming Huang wrote: > >> As chip group suggestions, update Mbigen and gic RAS configuration > >> flow. > > > > Update how? > > Add below flow: > 1 Reset Mbigen; > 2 Disable Mbigen clock; > 3 Deassert reset Mbigen; > 4 Enable Mbigen clock; If you add that to commit message, that's good enough for me. Regards, Leif > Thanks. > > > > > / > > Leif > > > >> Contributed-under: TianoCore Contribution Agreement 1.1 > >> Signed-off-by: Ming Huang > >> --- > >> Platform/Hisilicon/D06/Drivers/RasInitDxe/RasInitDxe.efi | Bin 17984 -> > >> 18720 bytes > >> 1 file changed, 0 insertions(+), 0 deletions(-) > >> > >> diff --git a/Platform/Hisilicon/D06/Drivers/RasInitDxe/RasInitDxe.efi > >> b/Platform/Hisilicon/D06/Drivers/RasInitDxe/RasInitDxe.efi > >> index 19adbc9..9ea21e9 100644 > >> Binary files a/Platform/Hisilicon/D06/Drivers/RasInitDxe/RasInitDxe.efi > >> and b/Platform/Hisilicon/D06/Drivers/RasInitDxe/RasInitDxe.efi differ > >> -- > >> 2.9.5 > >> ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-non-osi v1 2/7] Hisilicon/D0x: Rename StartupAp() function
On Tue, Feb 12, 2019 at 04:05:50PM +0800, Ming Huang wrote: > On 2/12/2019 5:36 AM, Leif Lindholm wrote: > > On Fri, Feb 01, 2019 at 10:25:02PM +0800, Ming Huang wrote: > >> As suggestion of community, 'AP' is a bit unfortunate to use in EDK2 > >> context. PI specifies 'BSP' for Boot-strap Processor, as the one > >> executing all of the EDK2 code. It then uses 'AP' to refer to > >> Additional Processors, which can be assigned tasks using the > >> EFI_MP_SERVICES_PROTOCOL. In a TianoCore context, this should be > >> 'BSP'. So, Rename StartupAp() to StartUpBSP. > > > > Please add a comment somewhere that this applies to D0x > > PlatformSysCtrlLib. > > ok > > >> Contributed-under: TianoCore Contribution Agreement 1.1 > >> Signed-off-by: Ming Huang > >> --- > >> > >> Silicon/Hisilicon/Hi1610/Library/PlatformSysCtrlLibHi1610/PlatformSysCtrlLibHi1610.lib > >> | Bin 297590 -> 229128 bytes > >> > >> Silicon/Hisilicon/Hi1616/Library/PlatformSysCtrlLibHi1616/PlatformSysCtrlLibHi1616.lib > >> | Bin 344310 -> 275312 bytes > >> > >> Silicon/Hisilicon/Hi1620/Library/PlatformSysCtrlLibHi1620/PlatformSysCtrlLibHi1620.lib > >> | Bin 356032 -> 375916 bytes > >> 3 files changed, 0 insertions(+), 0 deletions(-) > > > > These are substantial changes in image size from only changing the > > name of a function. So I'll have a little look around. > > > > 1610 version appears to have switched from building with GCC49_RELEASE > > to GCC48_RELEASE. > > 1616 and 1620 versions seem to have used GCC48_RELEASE all along. > > > > I definitely see additional renamed functions in these libraries too. > > > > Please have an inventory and determine what may be affecting image sizes. > > > > Also, I *beg* you - please upgrade from "GNU C 4.8.3 20131202 (prerelease)". > > We have plan to upgrage gcc to 7.3, but our build server is share for all ARM > project, so need discuss with other project groups, it may be not enough time > for 19.02. Oh, we're too late in the game to change for this release. But you are using ancient toolchains with poor code generation and quite likely known bugs. And this has been the state for quite some time. If that can change for 19.06, that's good enough. > For D05/D03 libraries, just remove 2 functions from OemMiscLib which used > by PlatformSysCtrlLib. Does edk2 version effect the libraries size? > old edk2 base on: 2017-0904 > now edk2 base on: 2018-0801 Well, changing edk2 version will mean that command line options to compiler and linker may change. So certainly some change can be seen. But when the changes are this big, I suspect something else has been going on. > For D06 library, we use the same source code to support all Hi1620 projects, > include product projects,so there are some modify for this, like support > 3 sockets, 4 sockets and remove some useless functions. So please reword the subject line of this commit to explain it is an overall update of PlatformSysCtrlLib - including which bits are dropped. And I think this makes a good argument for moving the header files for binary-only libraries from edk2-platforms to edk2-non-osi. If you do that in a separate patch before this one, you won't need to include as much detail in the commit message as you will otherwise. Regards, Leif > Thanks. > > > > > / > > Leif > > > >> > >> diff --git > >> a/Silicon/Hisilicon/Hi1610/Library/PlatformSysCtrlLibHi1610/PlatformSysCtrlLibHi1610.lib > >> > >> b/Silicon/Hisilicon/Hi1610/Library/PlatformSysCtrlLibHi1610/PlatformSysCtrlLibHi1610.lib > >> index 68be770..4c63a26 100644 > >> Binary files > >> a/Silicon/Hisilicon/Hi1610/Library/PlatformSysCtrlLibHi1610/PlatformSysCtrlLibHi1610.lib > >> and > >> b/Silicon/Hisilicon/Hi1610/Library/PlatformSysCtrlLibHi1610/PlatformSysCtrlLibHi1610.lib > >> differ > >> diff --git > >> a/Silicon/Hisilicon/Hi1616/Library/PlatformSysCtrlLibHi1616/PlatformSysCtrlLibHi1616.lib > >> > >> b/Silicon/Hisilicon/Hi1616/Library/PlatformSysCtrlLibHi1616/PlatformSysCtrlLibHi1616.lib > >> index b3cc88e..cb2c652 100644 > >> Binary files > >> a/Silicon/Hisilicon/Hi1616/Library/PlatformSysCtrlLibHi1616/PlatformSysCtrlLibHi1616.lib > >> and > >> b/Silicon/Hisilicon/Hi1616/Library/PlatformSysCtrlLibHi1616/PlatformSysCtrlLibHi1616.lib > >> differ > >> diff --git > >> a/Silicon/Hisilicon/Hi1620/Library/PlatformSysCtrlLibHi1620/PlatformSysCtrlLibHi1620.lib > >> > >> b/Silicon/Hisilicon/Hi1620/Library/PlatformSysCtrlLibHi1620/PlatformSysCtrlLibHi1620.lib > >> index 50d453a..d643f7b 100644 > >> Binary files > >> a/Silicon/Hisilicon/Hi1620/Library/PlatformSysCtrlLibHi1620/PlatformSysCtrlLibHi1620.lib > >> and > >> b/Silicon/Hisilicon/Hi1620/Library/PlatformSysCtrlLibHi1620/PlatformSysCtrlLibHi1620.lib > >> differ > >> -- > >> 2.9.5 > >> ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-non-osi v1 3/7] Hisilicon/D06: Update Mbigen and gic RAS register
On Fri, Feb 01, 2019 at 10:25:03PM +0800, Ming Huang wrote: > As chip group suggestions, update Mbigen and gic RAS configuration > flow. Update how? / Leif > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ming Huang > --- > Platform/Hisilicon/D06/Drivers/RasInitDxe/RasInitDxe.efi | Bin 17984 -> > 18720 bytes > 1 file changed, 0 insertions(+), 0 deletions(-) > > diff --git a/Platform/Hisilicon/D06/Drivers/RasInitDxe/RasInitDxe.efi > b/Platform/Hisilicon/D06/Drivers/RasInitDxe/RasInitDxe.efi > index 19adbc9..9ea21e9 100644 > Binary files a/Platform/Hisilicon/D06/Drivers/RasInitDxe/RasInitDxe.efi and > b/Platform/Hisilicon/D06/Drivers/RasInitDxe/RasInitDxe.efi differ > -- > 2.9.5 > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-non-osi v1 2/7] Hisilicon/D0x: Rename StartupAp() function
On Fri, Feb 01, 2019 at 10:25:02PM +0800, Ming Huang wrote: > As suggestion of community, 'AP' is a bit unfortunate to use in EDK2 > context. PI specifies 'BSP' for Boot-strap Processor, as the one > executing all of the EDK2 code. It then uses 'AP' to refer to > Additional Processors, which can be assigned tasks using the > EFI_MP_SERVICES_PROTOCOL. In a TianoCore context, this should be > 'BSP'. So, Rename StartupAp() to StartUpBSP. Please add a comment somewhere that this applies to D0x PlatformSysCtrlLib. > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ming Huang > --- > > Silicon/Hisilicon/Hi1610/Library/PlatformSysCtrlLibHi1610/PlatformSysCtrlLibHi1610.lib > | Bin 297590 -> 229128 bytes > > Silicon/Hisilicon/Hi1616/Library/PlatformSysCtrlLibHi1616/PlatformSysCtrlLibHi1616.lib > | Bin 344310 -> 275312 bytes > > Silicon/Hisilicon/Hi1620/Library/PlatformSysCtrlLibHi1620/PlatformSysCtrlLibHi1620.lib > | Bin 356032 -> 375916 bytes > 3 files changed, 0 insertions(+), 0 deletions(-) These are substantial changes in image size from only changing the name of a function. So I'll have a little look around. 1610 version appears to have switched from building with GCC49_RELEASE to GCC48_RELEASE. 1616 and 1620 versions seem to have used GCC48_RELEASE all along. I definitely see additional renamed functions in these libraries too. Please have an inventory and determine what may be affecting image sizes. Also, I *beg* you - please upgrade from "GNU C 4.8.3 20131202 (prerelease)". / Leif > > diff --git > a/Silicon/Hisilicon/Hi1610/Library/PlatformSysCtrlLibHi1610/PlatformSysCtrlLibHi1610.lib > > b/Silicon/Hisilicon/Hi1610/Library/PlatformSysCtrlLibHi1610/PlatformSysCtrlLibHi1610.lib > index 68be770..4c63a26 100644 > Binary files > a/Silicon/Hisilicon/Hi1610/Library/PlatformSysCtrlLibHi1610/PlatformSysCtrlLibHi1610.lib > and > b/Silicon/Hisilicon/Hi1610/Library/PlatformSysCtrlLibHi1610/PlatformSysCtrlLibHi1610.lib > differ > diff --git > a/Silicon/Hisilicon/Hi1616/Library/PlatformSysCtrlLibHi1616/PlatformSysCtrlLibHi1616.lib > > b/Silicon/Hisilicon/Hi1616/Library/PlatformSysCtrlLibHi1616/PlatformSysCtrlLibHi1616.lib > index b3cc88e..cb2c652 100644 > Binary files > a/Silicon/Hisilicon/Hi1616/Library/PlatformSysCtrlLibHi1616/PlatformSysCtrlLibHi1616.lib > and > b/Silicon/Hisilicon/Hi1616/Library/PlatformSysCtrlLibHi1616/PlatformSysCtrlLibHi1616.lib > differ > diff --git > a/Silicon/Hisilicon/Hi1620/Library/PlatformSysCtrlLibHi1620/PlatformSysCtrlLibHi1620.lib > > b/Silicon/Hisilicon/Hi1620/Library/PlatformSysCtrlLibHi1620/PlatformSysCtrlLibHi1620.lib > index 50d453a..d643f7b 100644 > Binary files > a/Silicon/Hisilicon/Hi1620/Library/PlatformSysCtrlLibHi1620/PlatformSysCtrlLibHi1620.lib > and > b/Silicon/Hisilicon/Hi1620/Library/PlatformSysCtrlLibHi1620/PlatformSysCtrlLibHi1620.lib > differ > -- > 2.9.5 > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-platforms v1 16/16] Hisilicon/D0x: Modify version to 19.02
On Fri, Feb 01, 2019 at 10:29:07PM +0800, Ming Huang wrote: > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ming Huang Reviewed-by: Leif Lindholm > --- > Platform/Hisilicon/D03/D03.dsc | 4 ++-- > Platform/Hisilicon/D05/D05.dsc | 4 ++-- > Platform/Hisilicon/D06/D06.dsc | 4 ++-- > 3 files changed, 6 insertions(+), 6 deletions(-) > > diff --git a/Platform/Hisilicon/D03/D03.dsc b/Platform/Hisilicon/D03/D03.dsc > index 35b54f8c83be..07ff461277df 100644 > --- a/Platform/Hisilicon/D03/D03.dsc > +++ b/Platform/Hisilicon/D03/D03.dsc > @@ -171,12 +171,12 @@ [PcdsFixedAtBuild.common] >!ifdef $(FIRMWARE_VER) > > gEfiMdeModulePkgTokenSpaceGuid.PcdFirmwareVersionString|L"$(FIRMWARE_VER)" >!else > -gEfiMdeModulePkgTokenSpaceGuid.PcdFirmwareVersionString|L"Development > build 18.08 for Hisilicon D03" > +gEfiMdeModulePkgTokenSpaceGuid.PcdFirmwareVersionString|L"Development > build 19.02 for Hisilicon D03" >!endif > >gHisiTokenSpaceGuid.PcdBiosVersionString|L"10.01.01T18" > > - gHisiTokenSpaceGuid.PcdBiosVersionForBmc|L"1.12" > + gHisiTokenSpaceGuid.PcdBiosVersionForBmc|L"19.02" > >gHisiTokenSpaceGuid.PcdSystemProductName|L"D03" >gHisiTokenSpaceGuid.PcdSystemVersion|L"Estuary" > diff --git a/Platform/Hisilicon/D05/D05.dsc b/Platform/Hisilicon/D05/D05.dsc > index 49bd5b37ea34..70b044c7e33a 100644 > --- a/Platform/Hisilicon/D05/D05.dsc > +++ b/Platform/Hisilicon/D05/D05.dsc > @@ -187,12 +187,12 @@ [PcdsFixedAtBuild.common] >!ifdef $(FIRMWARE_VER) > > gEfiMdeModulePkgTokenSpaceGuid.PcdFirmwareVersionString|L"$(FIRMWARE_VER)" >!else > -gEfiMdeModulePkgTokenSpaceGuid.PcdFirmwareVersionString|L"Development > build 18.08 for Hisilicon D05" > +gEfiMdeModulePkgTokenSpaceGuid.PcdFirmwareVersionString|L"Development > build 19.02 for Hisilicon D05" >!endif > >gHisiTokenSpaceGuid.PcdBiosVersionString|L"10.01.01T18" > > - gHisiTokenSpaceGuid.PcdBiosVersionForBmc|L"1.12" > + gHisiTokenSpaceGuid.PcdBiosVersionForBmc|L"19.02" > >gHisiTokenSpaceGuid.PcdSystemProductName|L"D05" >gHisiTokenSpaceGuid.PcdSystemVersion|L"Estuary" > diff --git a/Platform/Hisilicon/D06/D06.dsc b/Platform/Hisilicon/D06/D06.dsc > index a3a01bfb1e23..73bea728b0f6 100644 > --- a/Platform/Hisilicon/D06/D06.dsc > +++ b/Platform/Hisilicon/D06/D06.dsc > @@ -156,12 +156,12 @@ [PcdsFixedAtBuild.common] >!ifdef $(FIRMWARE_VER) > > gEfiMdeModulePkgTokenSpaceGuid.PcdFirmwareVersionString|L"$(FIRMWARE_VER)" >!else > -gEfiMdeModulePkgTokenSpaceGuid.PcdFirmwareVersionString|L"Development > build 18.08 for Hisilicon D06" > +gEfiMdeModulePkgTokenSpaceGuid.PcdFirmwareVersionString|L"Development > build 19.02 for Hisilicon D06" >!endif > >gHisiTokenSpaceGuid.PcdBiosVersionString|L"10.01.01T18" > > - gHisiTokenSpaceGuid.PcdBiosVersionForBmc|L"0.42" > + gHisiTokenSpaceGuid.PcdBiosVersionForBmc|L"19.02" > >gHisiTokenSpaceGuid.PcdSystemProductName|L"D06" >gHisiTokenSpaceGuid.PcdSystemVersion|L"VER.A" > -- > 2.9.5 > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-platforms v1 15/16] Hisilicon/D06: Use CalculateCrc16 in BaseLib
On Fri, Feb 01, 2019 at 10:29:06PM +0800, Ming Huang wrote:
> This patch is relative with "Add new API CalculateCrc16()" in edk2.
The commit message should describe what the patch does.
I don't mind keeping the above line in, but we also need the
description.
Obviously, this patch depends on the corresponding one going into
edk2, which is has not yet.
/
Leif
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ming Huang
> ---
> Platform/Hisilicon/D06/Library/OemNicLib/OemNicLib.c | 69
> ++--
> 1 file changed, 5 insertions(+), 64 deletions(-)
>
> diff --git a/Platform/Hisilicon/D06/Library/OemNicLib/OemNicLib.c
> b/Platform/Hisilicon/D06/Library/OemNicLib/OemNicLib.c
> index 9bf274e1b991..3ba4f305fb8e 100644
> --- a/Platform/Hisilicon/D06/Library/OemNicLib/OemNicLib.c
> +++ b/Platform/Hisilicon/D06/Library/OemNicLib/OemNicLib.c
> @@ -14,6 +14,7 @@
> **/
>
> #include
> +#include
> #include
> #include
> #include
> @@ -56,66 +57,6 @@ ETH_PRODUCT_DESC gEthPdtDesc[ETH_MAX_PORT] =
> {FALSE, ETH_INVALID, ETH_INVALID, ETH_INVALID, ETH_INVALID}
> };
>
> -UINT16 CrcTable16[256] = {
> - 0x, 0x1021, 0x2042, 0x3063, 0x4084, 0x50A5, 0x60C6, 0x70E7,
> - 0x8108, 0x9129, 0xA14A, 0xB16B, 0xC18C, 0xD1AD, 0xE1CE, 0xF1EF,
> - 0x1231, 0x0210, 0x3273, 0x2252, 0x52B5, 0x4294, 0x72F7, 0x62D6,
> - 0x9339, 0x8318, 0xB37B, 0xA35A, 0xD3BD, 0xC39C, 0xF3FF, 0xE3DE,
> - 0x2462, 0x3443, 0x0420, 0x1401, 0x64E6, 0x74C7, 0x44A4, 0x5485,
> - 0xA56A, 0xB54B, 0x8528, 0x9509, 0xE5EE, 0xF5CF, 0xC5AC, 0xD58D,
> - 0x3653, 0x2672, 0x1611, 0x0630, 0x76D7, 0x66F6, 0x5695, 0x46B4,
> - 0xB75B, 0xA77A, 0x9719, 0x8738, 0xF7DF, 0xE7FE, 0xD79D, 0xC7BC,
> - 0x48C4, 0x58E5, 0x6886, 0x78A7, 0x0840, 0x1861, 0x2802, 0x3823,
> - 0xC9CC, 0xD9ED, 0xE98E, 0xF9AF, 0x8948, 0x9969, 0xA90A, 0xB92B,
> - 0x5AF5, 0x4AD4, 0x7AB7, 0x6A96, 0x1A71, 0x0A50, 0x3A33, 0x2A12,
> - 0xDBFD, 0xCBDC, 0xFBBF, 0xEB9E, 0x9B79, 0x8B58, 0xBB3B, 0xAB1A,
> - 0x6CA6, 0x7C87, 0x4CE4, 0x5CC5, 0x2C22, 0x3C03, 0x0C60, 0x1C41,
> - 0xEDAE, 0xFD8F, 0xCDEC, 0xDDCD, 0xAD2A, 0xBD0B, 0x8D68, 0x9D49,
> - 0x7E97, 0x6EB6, 0x5ED5, 0x4EF4, 0x3E13, 0x2E32, 0x1E51, 0x0E70,
> - 0xFF9F, 0xEFBE, 0xDFDD, 0xCFFC, 0xBF1B, 0xAF3A, 0x9F59, 0x8F78,
> - 0x9188, 0x81A9, 0xB1CA, 0xA1EB, 0xD10C, 0xC12D, 0xF14E, 0xE16F,
> - 0x1080, 0x00A1, 0x30C2, 0x20E3, 0x5004, 0x4025, 0x7046, 0x6067,
> - 0x83B9, 0x9398, 0xA3FB, 0xB3DA, 0xC33D, 0xD31C, 0xE37F, 0xF35E,
> - 0x02B1, 0x1290, 0x22F3, 0x32D2, 0x4235, 0x5214, 0x6277, 0x7256,
> - 0xB5EA, 0xA5CB, 0x95A8, 0x8589, 0xF56E, 0xE54F, 0xD52C, 0xC50D,
> - 0x34E2, 0x24C3, 0x14A0, 0x0481, 0x7466, 0x6447, 0x5424, 0x4405,
> - 0xA7DB, 0xB7FA, 0x8799, 0x97B8, 0xE75F, 0xF77E, 0xC71D, 0xD73C,
> - 0x26D3, 0x36F2, 0x0691, 0x16B0, 0x6657, 0x7676, 0x4615, 0x5634,
> - 0xD94C, 0xC96D, 0xF90E, 0xE92F, 0x99C8, 0x89E9, 0xB98A, 0xA9AB,
> - 0x5844, 0x4865, 0x7806, 0x6827, 0x18C0, 0x08E1, 0x3882, 0x28A3,
> - 0xCB7D, 0xDB5C, 0xEB3F, 0xFB1E, 0x8BF9, 0x9BD8, 0xABBB, 0xBB9A,
> - 0x4A75, 0x5A54, 0x6A37, 0x7A16, 0x0AF1, 0x1AD0, 0x2AB3, 0x3A92,
> - 0xFD2E, 0xED0F, 0xDD6C, 0xCD4D, 0xBDAA, 0xAD8B, 0x9DE8, 0x8DC9,
> - 0x7C26, 0x6C07, 0x5C64, 0x4C45, 0x3CA2, 0x2C83, 0x1CE0, 0x0CC1,
> - 0xEF1F, 0xFF3E, 0xCF5D, 0xDF7C, 0xAF9B, 0xBFBA, 0x8FD9, 0x9FF8,
> - 0x6E17, 0x7E36, 0x4E55, 0x5E74, 0x2E93, 0x3EB2, 0x0ED1, 0x1EF0,
> -};
> -
> -UINT16 MakeCrcCheckSum (
> - UINT8 *Buffer,
> - UINT32 Length
> - )
> -{
> - UINT16 StartCRC = 0;
> -
> - if (Length > SIZE_512KB) {
> -return 0;
> - }
> -
> - if (Buffer == NULL) {
> -return 0;
> - }
> -
> - while (Length) {
> -StartCRC = CrcTable16 [((UINT8) ((StartCRC >> 8) & 0xff)) ^ *(Buffer++)]
> ^
> - ((UINT16) (StartCRC << 8));
> -Length--;
> - }
> -
> - return StartCRC;
> -}
> -
> -
> EFI_STATUS
> OemGetMacE2prom(
>IN UINT32 Port,
> @@ -170,8 +111,8 @@ OemGetMacE2prom(
> return Status;
>}
>
> - Crc16 = MakeCrcCheckSum (
> -(UINT8 *)&(MacDesc.MacLen),
> + Crc16 = CalculateCrc16 (
> +&(MacDesc.MacLen),
> sizeof (MacDesc.MacLen) + sizeof (MacDesc.Mac)
> );
>if ((Crc16 != MacDesc.Crc16) || (Crc16 == 0)) {
> @@ -207,8 +148,8 @@ OemSetMacE2prom (
> MacDesc.Mac[I] = Addr[I];
>}
>
> - MacDesc.Crc16 = MakeCrcCheckSum (
> -(UINT8 *)&(MacDesc.MacLen),
> + MacDesc.Crc16 = CalculateCrc16 (
> +&(MacDesc.MacLen),
> sizeof (MacDesc.MacLen) + MAC_ADDR_LEN
> );
>
> --
> 2.9.5
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-platforms v1 14/16] Hisilicon/D0x: Remove SP805 watchdog pcd
On Fri, Feb 01, 2019 at 09:34:34PM +0800, Ming Huang wrote: > SP805 watchdog is no used for D0x, so remove it. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ming Huang Reviewed-by: Leif Lindholm > --- > Platform/Hisilicon/D03/D03.dsc | 3 --- > Platform/Hisilicon/D05/D05.dsc | 3 --- > Silicon/Hisilicon/Library/ArmPlatformLibHisilicon/ArmPlatformLib.inf | 1 - > 3 files changed, 7 deletions(-) > > diff --git a/Platform/Hisilicon/D03/D03.dsc b/Platform/Hisilicon/D03/D03.dsc > index fe443dd929ad..35b54f8c83be 100644 > --- a/Platform/Hisilicon/D03/D03.dsc > +++ b/Platform/Hisilicon/D03/D03.dsc > @@ -149,9 +149,6 @@ [PcdsFixedAtBuild.common] > >gHisiTokenSpaceGuid.PcdPcieRootBridgeMask|0x7 # > bit0:HB0RB0,bit1:HB0RB1,bit2:HB0RB2,bit3:HB0RB3,bit4:HB1RB0,bit5:HB1RB1,bit6:HB1RB2,bit7:HB1RB3 > > - ## SP805 Watchdog - Motherboard Watchdog > - gArmPlatformTokenSpaceGuid.PcdSP805WatchdogBase|0x601e > - >## Serial Terminal >gEfiMdeModulePkgTokenSpaceGuid.PcdSerialRegisterBase|0x2F8 >gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate|115200 > diff --git a/Platform/Hisilicon/D05/D05.dsc b/Platform/Hisilicon/D05/D05.dsc > index 0c4f21fbe056..49bd5b37ea34 100644 > --- a/Platform/Hisilicon/D05/D05.dsc > +++ b/Platform/Hisilicon/D05/D05.dsc > @@ -163,9 +163,6 @@ [PcdsFixedAtBuild.common] >gHisiTokenSpaceGuid.PcdPcieRootBridgeMask2P|0x34F4 # > bit0:HB0RB0,bit1:HB0RB1,bit2:HB0RB2,bit3:HB0RB3,bit4:HB0RB4,bit5:HB0RB5,bit6:HB0RB6,bit7:HB0RB7 > # > bit8:HB1RB0,bit9:HB1RB1,bit10:HB1RB2,bit11:HB1RB3,bit12:HB1RB4,bit13:HB1RB5,bit14:HB1RB6,bit14:HB1RB15 > > - ## SP805 Watchdog - Motherboard Watchdog > - gArmPlatformTokenSpaceGuid.PcdSP805WatchdogBase|0x601e > - >## Serial Terminal >gEfiMdeModulePkgTokenSpaceGuid.PcdSerialRegisterBase|0x602B >gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate|115200 > diff --git > a/Silicon/Hisilicon/Library/ArmPlatformLibHisilicon/ArmPlatformLib.inf > b/Silicon/Hisilicon/Library/ArmPlatformLibHisilicon/ArmPlatformLib.inf > index 3563df6e10d1..4ce5f5fea1f3 100644 > --- a/Silicon/Hisilicon/Library/ArmPlatformLibHisilicon/ArmPlatformLib.inf > +++ b/Silicon/Hisilicon/Library/ArmPlatformLibHisilicon/ArmPlatformLib.inf > @@ -61,5 +61,4 @@ [FixedPcd] >gArmTokenSpaceGuid.PcdGicInterruptInterfaceBase >gHisiTokenSpaceGuid.PcdSysControlBaseAddress >gHisiTokenSpaceGuid.PcdPeriSubctrlAddress > - gArmPlatformTokenSpaceGuid.PcdSP805WatchdogBase > > -- > 2.9.5 > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-platforms v1 13/16] Hisilicon/D06: Remove SECURE_BOOT_ENABLE definition
On Fri, Feb 01, 2019 at 09:34:33PM +0800, Ming Huang wrote:
> As secure boot is not ready, remove SECURE_BOOT_ENABLE and
> relative code.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ming Huang
Reviewed-by: Leif Lindholm
> ---
> Platform/Hisilicon/D06/D06.dsc | 12
> Platform/Hisilicon/D06/D06.fdf | 11 ---
> 2 files changed, 23 deletions(-)
>
> diff --git a/Platform/Hisilicon/D06/D06.dsc b/Platform/Hisilicon/D06/D06.dsc
> index 6d581337f199..a3a01bfb1e23 100644
> --- a/Platform/Hisilicon/D06/D06.dsc
> +++ b/Platform/Hisilicon/D06/D06.dsc
> @@ -30,7 +30,6 @@ [Defines]
>FLASH_DEFINITION =
> Platform/Hisilicon/$(PLATFORM_NAME)/$(PLATFORM_NAME).fdf
>DEFINE NETWORK_IP6_ENABLE = FALSE
>DEFINE HTTP_BOOT_ENABLE= FALSE
> - DEFINE SECURE_BOOT_ENABLE = FALSE
>
> !include Silicon/Hisilicon/Hisilicon.dsc.inc
>
> @@ -87,9 +86,6 @@ [LibraryClasses.common]
>LpcLib|Silicon/Hisilicon/Hi1620/Library/LpcLibHi1620/LpcLib.inf
>
> SerialPortLib|ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf
>OemNicLib|Platform/Hisilicon/D06/Library/OemNicLib/OemNicLib.inf
> -!if $(SECURE_BOOT_ENABLE) == TRUE
> - FileExplorerLib|MdeModulePkg/Library/FileExplorerLib/FileExplorerLib.inf
> -!endif
>PciExpressLib|MdePkg/Library/BasePciExpressLib/BasePciExpressLib.inf
>
> PciPlatformLib|Silicon/Hisilicon/Hi1620/Library/Hi1620PciPlatformLib/Hi1620PciPlatformLib.inf
>
> @@ -290,15 +286,7 @@ [Components.common]
>MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
>Platform/Hisilicon/D06/Drivers/OemNicConfig2PHi1620/OemNicConfig2P.inf
>
> -!if $(SECURE_BOOT_ENABLE) == TRUE
> - MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf {
> -
> -
> NULL|SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.inf
> - }
> -
> SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDxe.inf
> -!else
>MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
> -!endif
>Silicon/Hisilicon/Drivers/FlashFvbDxe/FlashFvbDxe.inf
>MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf {
>
> diff --git a/Platform/Hisilicon/D06/D06.fdf b/Platform/Hisilicon/D06/D06.fdf
> index f72b513352fb..e402628a1b35 100644
> --- a/Platform/Hisilicon/D06/D06.fdf
> +++ b/Platform/Hisilicon/D06/D06.fdf
> @@ -88,17 +88,10 @@ [FD.D06]
>#Blockmap[1]: End
>0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
>## This is the VARIABLE_STORE_HEADER
> -!if $(SECURE_BOOT_ENABLE) == TRUE
> - #Signature: gEfiAuthenticatedVariableGuid =
> - # { 0xaaf32c78, 0x947b, 0x439a, { 0xa1, 0x80, 0x2e, 0x14, 0x4e, 0xc3,
> 0x77, 0x92 }}
> - 0x78, 0x2c, 0xf3, 0xaa, 0x7b, 0x94, 0x9a, 0x43,
> - 0xa1, 0x80, 0x2e, 0x14, 0x4e, 0xc3, 0x77, 0x92,
> -!else
>#Signature: gEfiVariableGuid =
># { 0xddcf3616, 0x3275, 0x4164, { 0x98, 0xb6, 0xfe, 0x85, 0x70, 0x7f,
> 0xfe, 0x7d }}
>0x16, 0x36, 0xcf, 0xdd, 0x75, 0x32, 0x64, 0x41,
>0x98, 0xb6, 0xfe, 0x85, 0x70, 0x7f, 0xfe, 0x7d,
> -!endif
>#Size: 0xe000
> (gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize) - 0x48 (size
> of EFI_FIRMWARE_VOLUME_HEADER) = 0xdFB8
>0xB8, 0xdF, 0x00, 0x00,
>#FORMATTED: 0x5A #HEALTHY: 0xFE #Reserved: UINT16 #Reserved1: UINT32
> @@ -183,10 +176,6 @@ [FV.FvMain]
>INF MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
>INF
> MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
>
> -!if $(SECURE_BOOT_ENABLE) == TRUE
> - INF
> SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDxe.inf
> -!endif
> -
>INF MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystemRuntimeDxe.inf
>INF EmbeddedPkg/RealTimeClockRuntimeDxe/RealTimeClockRuntimeDxe.inf
>INF EmbeddedPkg/MetronomeDxe/MetronomeDxe.inf
> --
> 2.9.5
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-platforms v1 11/16] Hisilicon/D06: Add Setup Item "Support DPC"
On Fri, Feb 01, 2019 at 09:34:31PM +0800, Ming Huang wrote:
> Add setup item "Support DPC" to enable or disable PCIe DPC
> (Downstream Port Containment).
This patch also seems to disable the SRIOV configuration and delete a
lot of ports. Can you explain how this is related?
/
Leif
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ming Huang
> ---
> Silicon/Hisilicon/Include/Library/OemConfigData.h | 1 +
> Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfigVfr.vfr | 2 -
> Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfig.c | 4 +
> Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/PcieConfig.hfr| 197
> +---
> Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/PcieConfigStrings.uni | 3 +-
> 5 files changed, 10 insertions(+), 197 deletions(-)
>
> diff --git a/Silicon/Hisilicon/Include/Library/OemConfigData.h
> b/Silicon/Hisilicon/Include/Library/OemConfigData.h
> index f120e3123c83..c0097d0829f0 100644
> --- a/Silicon/Hisilicon/Include/Library/OemConfigData.h
> +++ b/Silicon/Hisilicon/Include/Library/OemConfigData.h
> @@ -49,6 +49,7 @@ typedef struct {
>UINT8 OSWdtAction;
>/*PCIe Config*/
>UINT8 PcieSRIOVSupport;
> + UINT8 PcieDPCSupport;
>UINT8 PciePort[PCIE_MAX_TOTAL_PORTS];
>UINT8 PcieLinkSpeedPort[PCIE_MAX_TOTAL_PORTS];
>UINT8 PcieLinkDeEmphasisPort[PCIE_MAX_TOTAL_PORTS];
> diff --git a/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfigVfr.vfr
> b/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfigVfr.vfr
> index 08236704fbfe..93ccb99bdc67 100644
> --- a/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfigVfr.vfr
> +++ b/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfigVfr.vfr
> @@ -62,11 +62,9 @@ formset
>prompt = STRING_TOKEN(STR_IBMC_CONFIG_FORM_TITLE),
>help = STRING_TOKEN(STR_IBMC_CONFIG_FORM_HELP);
>
> -suppressif TRUE;
> goto PCIE_CONFIG_FORM_ID,
>prompt = STRING_TOKEN(STR_PCIE_CONFIG_FORM_TITLE),
>help= STRING_TOKEN(STR_PCIE_CONFIG_FORM_HELP);
> -endif;
>
> goto MISC_CONFIG_FORM_ID,
>prompt = STRING_TOKEN(STR_MISC_CONFIG_FORM_TITLE),
> diff --git a/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfig.c
> b/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfig.c
> index 6668103af027..be4ce8820f73 100644
> --- a/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfig.c
> +++ b/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfig.c
> @@ -290,6 +290,10 @@ OemConfigUiLibConstructor (
>Configuration.OSWdtTimeout = 5;
>Configuration.OSWdtAction = 1;
>//
> + //Set the default value of the PCIe option
> + //
> + Configuration.PcieDPCSupport = 0;
> + //
>//Set the default value of the Misc option
>//
>Configuration.EnableSmmu = 1;
> diff --git a/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/PcieConfig.hfr
> b/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/PcieConfig.hfr
> index 7cf7cdd29ba2..c65907fe846e 100644
> --- a/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/PcieConfig.hfr
> +++ b/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/PcieConfig.hfr
> @@ -17,203 +17,12 @@
> form formid = PCIE_CONFIG_FORM_ID,
>title = STRING_TOKEN (STR_PCIE_CONFIG_FORM_TITLE);
>
> - goto VFR_FORMID_PCIE_SOCKET0,
> -prompt = STRING_TOKEN (STR_PCIE_CPU_0_PROMPT),
> -help= STRING_TOKEN (STR_PCIE_CPU_PROMPT_HELP);
> -
> - goto VFR_FORMID_PCIE_SOCKET1,
> -prompt = STRING_TOKEN (STR_PCIE_CPU_1_PROMPT),
> -help= STRING_TOKEN (STR_PCIE_CPU_PROMPT_HELP);
> -
> - oneof varid = OEM_CONFIG_DATA.PcieSRIOVSupport,
> -prompt = STRING_TOKEN (STR_SRIOV_SUPPORT_PROMPT),
> -help = STRING_TOKEN (STR_SRIOV_SUPPORT_HELP),
> + oneof varid = OEM_CONFIG_DATA.PcieDPCSupport,
> +prompt = STRING_TOKEN (STR_DPC_SUPPORT_PROMPT),
> +help = STRING_TOKEN (STR_DPC_SUPPORT_HELP),
> option text = STRING_TOKEN (STR_DISABLE), value = 0, flags =
> MANUFACTURING | DEFAULT | RESET_REQUIRED;
> option text = STRING_TOKEN (STR_ENABLE), value = 1, flags =
> RESET_REQUIRED;
>endoneof;
>
> endform;
>
> -form formid = VFR_FORMID_PCIE_SOCKET0,
> - title = STRING_TOKEN(STR_PCIE_CPU_0_PROMPT);
> -
> - goto VFR_FORMID_PCIE_PORT2,
> -prompt = STRING_TOKEN(STR_PCIE_PORT_2_PROMPT),
> -help= STRING_TOKEN(STR_PCIE_PORT_PROMPT_HELP);
> -
> - goto VFR_FORMID_PCIE_PORT4,
> -prompt = STRING_TOKEN(STR_PCIE_PORT_4_PROMPT),
> -help= STRING_TOKEN(STR_PCIE_PORT_PROMPT_HELP);
> -
> - goto VFR_FORMID_PCIE_PORT5,
> -prompt = STRING_TOKEN(STR_PCIE_PORT_5_PROMPT),
> -help= STRING_TOKEN(STR_PCIE_PORT_PROMPT_HELP);
> -
> - goto VFR_FORMID_PCIE_PORT6,
> -prompt = STRING_TOKEN(STR_PCIE_PORT_6_PROMPT),
> -help= STRING_TOKEN(STR_PCIE_PORT_PROMPT_HELP);
> -
> - goto VFR_FORMID_PCIE_PORT7,
> -
Re: [edk2] [PATCH edk2-platforms v1 10/16] Hisilicon/D06: Modify for M7 self-Adapte support
On Fri, Feb 01, 2019 at 09:34:30PM +0800, Ming Huang wrote:
> As new M7(Cortex-M7) firmware support self-adapte, so do not
> need BIOS to implement some function, remove useless funtions
> and report CPU0/CPU1 Nic NCL offset to M7.
I don't really care that some other device in the system is a
Cortex-A7. What is its function? Is it an SCP, an MCP, ?
Please describe its function rather than its implementation.
What are the external dependencies?
Is this addressed by one of the patches for edk2-non-osi?
More style issues below.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ming Huang
> ---
> Platform/Hisilicon/D06/Library/OemNicLib/OemNicLib.c | 272
>
> 1 file changed, 45 insertions(+), 227 deletions(-)
>
> diff --git a/Platform/Hisilicon/D06/Library/OemNicLib/OemNicLib.c
> b/Platform/Hisilicon/D06/Library/OemNicLib/OemNicLib.c
> index aaf990216982..9bf274e1b991 100644
> --- a/Platform/Hisilicon/D06/Library/OemNicLib/OemNicLib.c
> +++ b/Platform/Hisilicon/D06/Library/OemNicLib/OemNicLib.c
> @@ -21,44 +21,21 @@
> #include
>
> #define CPU2_SFP2_100G_CARD_OFFSET 0x25
> -#define CPU1_SFP1_LOCATE_OFFSET 0x16
> -#define CPU1_SFP0_LOCATE_OFFSET 0x12
> -#define CPU2_SFP1_LOCATE_OFFSET 0x21
> -#define CPU2_SFP0_LOCATE_OFFSET 0x19
> -#define CPU2_SFP2_10G_GE_CARD_OFFSET 0x25
>
> -#define SFP_10G_SPEED 10
> -#define SFP_25G_SPEED 25
> -#define SFP_100G_SPEED 100
> -#define SFP_GE_SPEED1
> -
> -#define SFP_GE_SPEED_VAL_VENDOR_FINISAR 0x0C
> -#define SFP_GE_SPEED_VAL0x0D
> -#define SFP_10G_SPEED_VAL 0x67
> -#define SFP_25G_SPEED_VAL 0xFF
> +#define SOCKET1_NET_PORT_100G 1
> +#define SOCKET0_NET_PORT_NUM 4
> +#define SOCKET1_NET_PORT_NUM 2
>
> #define CARD_PRESENT_100G (BIT7)
> -#define CARD_PRESENT_10G(BIT0)
> -#define SELECT_SFP_BY_INDEX(index) (1 << (index - 1))
> -#define SPF_SPEED_OFFSET12
> -
> -#define SFP_DEVICE_ADDRESS 0x50
> -#define CPU1_9545_I2C_ADDR 0x70
> -#define CPU2_9545_I2C_ADDR 0x71
> -
> -#define FIBER_PRESENT 0
> -#define CARD_PRESENT 1
> -#define I2C_PORT_SFP 4
> -#define CPU2_I2C_PORT_SFP 5
> -
> -#define SOCKET_0 0
> -#define SOCKET_1 1
> #define EEPROM_I2C_PORT 4
> #define EEPROM_PAGE_SIZE 0x40
> #define MAC_ADDR_LEN 6
> #define I2C_OFFSET_EEPROM_ETH0 (0xc00)
> #define I2C_SLAVEADDR_EEPROM (0x52)
>
> +#define SRAM_NIC_NCL1_OFFSET_FLAG 0xA0E87FE0
> +#define SRAM_NIC_NCL2_OFFSET_FLAG 0xA0E87FE4
Is this just a hard-coded address in SRAM? Where is it specified?
I don't think "_FLAG" is the correct name for this #define - this is
the actual offset value. So _OFFSET_ADDRESS would be more descriptive.
> +
> #pragma pack(1)
> typedef struct {
>UINT16 Crc16;
> @@ -114,204 +91,6 @@ UINT16 CrcTable16[256] = {
>0x6E17, 0x7E36, 0x4E55, 0x5E74, 0x2E93, 0x3EB2, 0x0ED1, 0x1EF0,
> };
>
> -EFI_STATUS
> -GetSfpSpeed (
> - UINT16 Socket,
> - UINT16 SfpNum,
> - UINT8* FiberSpeed
> - )
> -{
> - EFI_STATUS Status;
> - I2C_DEVICE SpdDev;
> - UINT8 SfpSelect;
> - UINT8 SfpSpeed;
> - UINT32 RegAddr;
> - UINT16 I2cAddr;
> - UINT32 SfpPort;
> -
> - SfpSpeed = 0x0;
> - if (Socket == SOCKET_1) {
> -I2cAddr = CPU2_9545_I2C_ADDR;
> -SfpPort = CPU2_I2C_PORT_SFP;
> - } else {
> -I2cAddr = CPU1_9545_I2C_ADDR;
> -SfpPort = I2C_PORT_SFP;
> - }
> -
> - Status = I2CInit (Socket, SfpPort, Normal);
> - if (EFI_ERROR (Status)) {
> -DEBUG ((DEBUG_ERROR, "[%a]:[%dL] Socket%d Call I2CInit failed!
> p1=0x%x.\n",
> -__FUNCTION__, __LINE__, Socket, Status));
> -return Status;
> - }
> -
> - SpdDev.Socket = Socket;
> - SpdDev.DeviceType = DEVICE_TYPE_SPD;
> - SpdDev.Port = SfpPort;
> - SpdDev.SlaveDeviceAddress = I2cAddr;
> - RegAddr = 0x0;
> - SfpSelect = SELECT_SFP_BY_INDEX (SfpNum);
> -
> - Status = I2CWrite (, RegAddr, 1, );
> - if (EFI_ERROR (Status)) {
> -DEBUG ((DEBUG_ERROR, "I2CWrite Error =%r.\n", Status));
> -return Status;
> - }
> -
> - SpdDev.Socket = Socket;
> - SpdDev.DeviceType = DEVICE_TYPE_SPD;
> - SpdDev.Port = SfpPort;
> - SpdDev.SlaveDeviceAddress = SFP_DEVICE_ADDRESS;
> -
> - RegAddr = SPF_SPEED_OFFSET;
> - Status = I2CRead (, RegAddr, 1, );
> - if (EFI_ERROR (Status)) {
> -DEBUG ((DEBUG_ERROR, "I2CRead Error =%r.\n", Status));
> -return Status;
> - }
> -
> - DEBUG ((DEBUG_INFO, "BR, Nominal, Nominal signalling rate, SfpSpeed:
> 0x%x\n",
> - SfpSpeed));
> -
> - if (SfpSpeed == SFP_10G_SPEED_VAL) {
> -*FiberSpeed = SFP_10G_SPEED;
> - } else if (SfpSpeed == SFP_25G_SPEED_VAL) {
> -*FiberSpeed = SFP_25G_SPEED;
> - } else if ((SfpSpeed == SFP_GE_SPEED_VAL) ||
> - (SfpSpeed == SFP_GE_SPEED_VAL_VENDOR_FINISAR)) {
> -*FiberSpeed = SFP_GE_SPEED;
> - }
>
Re: [edk2] [PATCH edk2-platforms] Silicon/SynQuacer/Stage2Tables: fix build for cross compile from x86
On Mon, Feb 11, 2019 at 07:33:22PM +0100, Ard Biesheuvel wrote: > AArch64 binutils support AArch32 seamlessly when running natively, > which allowed us to drop the -I objcopy argument specifying that > the input format is elf64-little, which is no longer accurate now > that the module can be built in 32-bit mode as well (which makes no > difference whatsoever given that the resulting binary image is only > a set of stage2 page tables) > > The same does not apply to binutils hosted on x86, so add back the > appropriate input format depending on the target type. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ard Biesheuvel Acked-by: Leif Lindholm Tested-by: Leif Lindholm > --- > Silicon/Socionext/SynQuacer/Stage2Tables/Stage2Tables.inf | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/Silicon/Socionext/SynQuacer/Stage2Tables/Stage2Tables.inf > b/Silicon/Socionext/SynQuacer/Stage2Tables/Stage2Tables.inf > index f845015b9002..3e7039d586e1 100644 > --- a/Silicon/Socionext/SynQuacer/Stage2Tables/Stage2Tables.inf > +++ b/Silicon/Socionext/SynQuacer/Stage2Tables/Stage2Tables.inf > @@ -26,6 +26,8 @@ [Sources] > [BuildOptions] >*_*_*_OBJCOPY_PATH == objcopy >*_*_*_OBJCOPY_FLAGS == -O binary -j .rodata > + *_*_AARCH64_OBJCOPY_FLAGS = -I elf64-little > + *_*_ARM_OBJCOPY_FLAGS = -I elf32-little >*_*_*_ASM_FLAGS == -nostdlib > -Wl,-e,0x81f8000,--section-start=.rodata=0x81f8000 >*_CLANG35_*_ASM_FLAGS = -no-integrated-as >*_CLANG38_*_ASM_FLAGS = -no-integrated-as > -- > 2.20.1 > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-platforms] Silicon/Socionext: use variable attributes from Uefi/UefiMultiPhase.h
On Mon, Feb 11, 2019 at 07:03:09PM +0100, Ard Biesheuvel wrote: > On Mon, 11 Feb 2019 at 19:02, Leif Lindholm wrote: > > > > Use EFI variable attributes from Uefi/UefiMultiPhase.h in PlatformDxe > > .vfr rather than local definitions. > > > > Contributed-under: TianoCore Contribution Agreement 1.1 > > Signed-off-by: Leif Lindholm > > Reviewed-by: Ard Biesheuvel Thanks, pushed as d7b29975f8. > > --- > > .../Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxeHii.vfr | 9 > > + > > 1 file changed, 1 insertion(+), 8 deletions(-) > > > > diff --git > > a/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxeHii.vfr > > b/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxeHii.vfr > > index 8a395eac68..25b7b49a3d 100644 > > --- a/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxeHii.vfr > > +++ b/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxeHii.vfr > > @@ -15,14 +15,7 @@ > > #include > > #include > > #include > > - > > -// > > -// EFI Variable attributes > > -// > > -#define EFI_VARIABLE_NON_VOLATILE 0x0001 > > -#define EFI_VARIABLE_BOOTSERVICE_ACCESS 0x0002 > > -#define EFI_VARIABLE_RUNTIME_ACCESS 0x0004 > > -#define EFI_VARIABLE_READ_ONLY 0x0008 > > +#include > > > > formset > >guid = SYNQUACER_PLATFORM_FORMSET_GUID, > > -- > > 2.11.0 > > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-platforms v1 09/16] Hisilicon/D06: Add PCI_OSC_SUPPORT
On Fri, Feb 01, 2019 at 09:34:29PM +0800, Ming Huang wrote:
> Add PCI_OSC_SUPPORT for remaining host bridges to remove fail
> output in kernel:
> [ 103.478893] acpi PNP0A08:01: _OSC failed (AE_NOT_FOUND);
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ming Huang
> ---
> Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Dsdt/Hi1620Pci.asl | 64
>
> 1 file changed, 64 insertions(+)
>
> diff --git a/Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Dsdt/Hi1620Pci.asl
> b/Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Dsdt/Hi1620Pci.asl
> index 4d9d9d95be68..86d8728b82f2 100644
> --- a/Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Dsdt/Hi1620Pci.asl
> +++ b/Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Dsdt/Hi1620Pci.asl
> @@ -17,6 +17,50 @@
> **/
>
> //#include "ArmPlatform.h"
> +
> +/*
> + See ACPI 6.1 Spec, 6.2.11, PCI Firmware Spec 3.0, 4.5
> +*/
> +#define PCI_OSC_SUPPORT() \
PCI0 and PCI6 already have _OSC entries.
This macro ends up being used for 1-5 and 7-B.
So calling it PCI_OSC_SUPPORT seems somewhat misleading.
Then again, there is a lot of similarities between this macro and the
existing entries. Could the same macro be used for 0 and 6? Or could
the macro be split up into multiple parts and reused?
/
Leif
> + Name(SUPP, Zero) /* PCI _OSC Support Field value */ \
> + Name(CTRL, Zero) /* PCI _OSC Control Field value */ \
> + Method(_OSC,4) { \
> +If(LEqual(Arg0,ToUUID("33DB4D5B-1FF7-401C-9657-7441C03DD766"))) { \
> + /* Create DWord-adressable fields from the Capabilities Buffer */ \
> + CreateDWordField(Arg3,0,CDW1) \
> + CreateDWordField(Arg3,4,CDW2) \
> + CreateDWordField(Arg3,8,CDW3) \
> + /* Save Capabilities DWord2 & 3 */ \
> + Store(CDW2,SUPP) \
> + Store(CDW3,CTRL) \
> + /* Only allow native hot plug control if OS supports: */ \
> + /* ASPM */ \
> + /* Clock PM */ \
> + /* MSI/MSI-X */ \
> + If(LNotEqual(And(SUPP, 0x16), 0x16)) { \
> +And(CTRL,0x1E,CTRL) \
> + }\
> + \
> + /* Do not allow native PME, AER */ \
> + /* Never allow SHPC (no SHPC controller in this system)*/ \
> + And(CTRL,0x10,CTRL) \
> + If(LNotEqual(Arg1,One)) { /* Unknown revision */ \
> +Or(CDW1,0x08,CDW1) \
> + } \
> + \
> + If(LNotEqual(CDW3,CTRL)) { /* Capabilities bits were masked */ \
> +Or(CDW1,0x10,CDW1) \
> + } \
> + \
> + /* Update DWORD3 in the buffer */ \
> + Store(CTRL,CDW3) \
> + Return(Arg3) \
> +} Else { \
> + Or(CDW1,4,CDW1) /* Unrecognized UUID */ \
> + Return(Arg3) \
> +} \
> + } // End _OSC
> +
> Scope(_SB)
> {
>Device (PCI0)
> @@ -270,6 +314,8 @@ Device (PCI1)
> Return (RBUF)
>} // Method(_CRS), this method
> return RBUF!
>
> + PCI_OSC_SUPPORT ()
> +
>Method (_STA, 0x0, NotSerialized)
>{
> Return (0xf)
> @@ -333,6 +379,8 @@ Device (PCI2)
> Return (RBUF)
>} // Method(_CRS), this method
> return RBUF!
>
> + PCI_OSC_SUPPORT ()
> +
>Method (_STA, 0x0, NotSerialized)
>{
> Return (0xf)
> @@ -382,6 +430,8 @@ Device (PCI3)
> Return (RBUF)
>} // Method(_CRS), this method
> return RBUF!
>
> + PCI_OSC_SUPPORT ()
> +
>Method (_STA, 0x0, NotSerialized)
>{
> Return (0xf)
> @@ -431,6 +481,8 @@ Device (PCI4)
> Return (RBUF)
>} // Method(_CRS), this method
> return RBUF!
>
> + PCI_OSC_SUPPORT ()
> +
>Method (_STA, 0x0, NotSerialized)
>{
> Return (0x0F)
> @@ -505,6 +557,8 @@ Device (PCI5)
> Return (RBUF)
>}// Method(_CRS), this method return
> RBUF!
>
> + PCI_OSC_SUPPORT ()
> +
>Method (_STA, 0x0, NotSerialized)
>{
> Return (0xf)
> @@ -1002,6 +1056,8 @@ Device (PCI7)
> Return (RBUF)
>} // Method(_CRS), this method
> return RBUF!
>
> + PCI_OSC_SUPPORT ()
> +
>Method (_STA, 0x0, NotSerialized)
>{
> Return (0xf)
> @@ -1066,6 +1122,8 @@ Device (PCI8)
> Return (RBUF)
>} // Method(_CRS), this method
> return RBUF!
>
> + PCI_OSC_SUPPORT ()
> +
>Method (_STA, 0x0, NotSerialized)
>{
> Return (0xf)
> @@ -1115,6 +1173,8 @@ Device (PCI9)
> Return (RBUF)
>} // Method(_CRS), this method
> return RBUF!
>
> + PCI_OSC_SUPPORT ()
> +
>Method (_STA, 0x0, NotSerialized)
>{
> Return (0xf)
> @@ -1164,6 +1224,8 @@ Device (PCIA)
> Return (RBUF)
>} // Method(_CRS), this method
> return RBUF!
>
> + PCI_OSC_SUPPORT ()
> +
>Method (_STA, 0x0, NotSerialized)
>{
> Return (0x0F)
> @@ -1238,6 +1300,8 @@ Device (PCIB)
> Return (RBUF)
>}
Re: [edk2] [PATCH edk2-platforms v1 08/16] Hisilicon/D06: Change HCCS speed from 30G to 26G
On Fri, Feb 01, 2019 at 09:34:28PM +0800, Ming Huang wrote:
> Follow chip team suggestion to change HCCS(Huawei Cache-Coherent
> System) speed from 30G to 26G, this modification can avoid some
> unstable stress issue.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ming Huang
> ---
> Silicon/Hisilicon/Include/Library/OemMiscLib.h | 10 ++
> Platform/Hisilicon/D06/Library/OemMiscLibD06/OemMiscLibD06.c | 8
> 2 files changed, 18 insertions(+)
>
> diff --git a/Silicon/Hisilicon/Include/Library/OemMiscLib.h
> b/Silicon/Hisilicon/Include/Library/OemMiscLib.h
> index dfac87d635d9..3c0cd0319122 100644
> --- a/Silicon/Hisilicon/Include/Library/OemMiscLib.h
> +++ b/Silicon/Hisilicon/Include/Library/OemMiscLib.h
> @@ -22,6 +22,11 @@
> #include
> #include
>
> +#define HCCS_PLL_VALUE_3000 0x52240781
> +#define HCCS_PLL_VALUE_2600 0x52240681
> +#define HCCS_PLL_VALUE_2800 0x52240701
Could these be described by a proper macro instead of just values?
A cursory glance suggests that an increase of 0x80 in the lower half
means 200MHz.
If not, please sort them by frequency, ascending.
> +
> +
> #define PCIEDEVICE_REPORT_MAX 8
> #define MAX_PROCESSOR_SOCKETS MAX_SOCKET
> #define MAX_MEMORY_CHANNELSMAX_CHANNEL
> @@ -55,4 +60,9 @@ extern EFI_STRING_ID
> gDimmToDevLocator[MAX_SOCKET][MAX_CHANNEL][MAX_DIMM];
> EFI_HII_HANDLE EFIAPI OemGetPackages ();
> UINTN OemGetCpuFreq (UINT8 Socket);
>
> +UINTN
> +OemGetHccsFreq (
> + VOID
> + );
> +
> #endif
> diff --git a/Platform/Hisilicon/D06/Library/OemMiscLibD06/OemMiscLibD06.c
> b/Platform/Hisilicon/D06/Library/OemMiscLibD06/OemMiscLibD06.c
> index 8f2ac308c7b9..83e53cfeb5dd 100644
> --- a/Platform/Hisilicon/D06/Library/OemMiscLibD06/OemMiscLibD06.c
> +++ b/Platform/Hisilicon/D06/Library/OemMiscLibD06/OemMiscLibD06.c
> @@ -223,3 +223,11 @@ UINTN OemGetCpuFreq (UINT8 Socket)
>}
> }
>
> +UINTN
> +OemGetHccsFreq (
The commit message describes this patch as changing the frequency.
The actual code simply returns a value.
The name of the function returning this value suggests the value is a
frequency.
> + VOID
> + )
> +{
> + return HCCS_PLL_VALUE_2600;
But the constant returned is named suggesting a PLL configuration
value. And the frequency suggested by the name is many orders of
magnitude below that described by the commit message.
/
Leif
> +}
> +
> --
> 2.9.5
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-platforms v1 07/16] Hisilicon/D0x: Rename StartupAp() function
On Fri, Feb 01, 2019 at 09:34:27PM +0800, Ming Huang wrote:
> As suggestion of community, 'AP' is a bit unfortunate to use in EDK2
> context. PI specifies 'BSP' for Boot-strap Processor, as the one
> executing all of the EDK2 code. It then uses 'AP' to refer to
> Additional Processors, which can be assigned tasks using the
> EFI_MP_SERVICES_PROTOCOL. In a TianoCore context, this should be 'BSP'.
> So, Rename StartupAp() to StartUpBSP.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ming Huang
Reviewed-by: Leif Lindholm
Thanks!
> ---
> Silicon/Hisilicon/Include/Library/PlatformSysCtrlLib.h | 2 +-
> Platform/Hisilicon/D03/EarlyConfigPeim/EarlyConfigPeimD03.c | 2 +-
> Platform/Hisilicon/D03/Library/OemMiscLib2P/OemMiscLib2PHi1610.c | 2 +-
> Platform/Hisilicon/D05/EarlyConfigPeim/EarlyConfigPeimD05.c | 2 +-
> Platform/Hisilicon/D05/Library/OemMiscLibD05/OemMiscLibD05.c | 3 ++-
> Platform/Hisilicon/D06/EarlyConfigPeim/EarlyConfigPeimD06.c | 2 +-
> 6 files changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/Silicon/Hisilicon/Include/Library/PlatformSysCtrlLib.h
> b/Silicon/Hisilicon/Include/Library/PlatformSysCtrlLib.h
> index a232e52ed719..712b77c44fc8 100644
> --- a/Silicon/Hisilicon/Include/Library/PlatformSysCtrlLib.h
> +++ b/Silicon/Hisilicon/Include/Library/PlatformSysCtrlLib.h
> @@ -76,7 +76,7 @@ VOID MN_CONFIG (VOID);
> VOID SmmuConfigForOS (VOID);
> VOID SmmuConfigForBios (VOID);
>
> -VOID StartupAp (VOID);
> +VOID StartUpBSP (VOID);
>
> VOID LlcCleanInvalidate (VOID);
>
> diff --git a/Platform/Hisilicon/D03/EarlyConfigPeim/EarlyConfigPeimD03.c
> b/Platform/Hisilicon/D03/EarlyConfigPeim/EarlyConfigPeimD03.c
> index 97cf6b8d8757..dacd9e871faf 100644
> --- a/Platform/Hisilicon/D03/EarlyConfigPeim/EarlyConfigPeimD03.c
> +++ b/Platform/Hisilicon/D03/EarlyConfigPeim/EarlyConfigPeimD03.c
> @@ -83,7 +83,7 @@ void QResetAp(VOID)
> //SCCL A
> if (!PcdGet64 (PcdTrustedFirmwareEnable))
> {
> -StartupAp();
> +StartUpBSP ();
> }
> }
>
> diff --git a/Platform/Hisilicon/D03/Library/OemMiscLib2P/OemMiscLib2PHi1610.c
> b/Platform/Hisilicon/D03/Library/OemMiscLib2P/OemMiscLib2PHi1610.c
> index b57fdfa68e45..c8a9da73bbca 100644
> --- a/Platform/Hisilicon/D03/Library/OemMiscLib2P/OemMiscLib2PHi1610.c
> +++ b/Platform/Hisilicon/D03/Library/OemMiscLib2P/OemMiscLib2PHi1610.c
> @@ -133,7 +133,7 @@ VOID CoreSelectBoot(VOID)
> {
> if (!PcdGet64 (PcdTrustedFirmwareEnable))
> {
> -StartupAp ();
> +StartUpBSP ();
> }
>
> return;
> diff --git a/Platform/Hisilicon/D05/EarlyConfigPeim/EarlyConfigPeimD05.c
> b/Platform/Hisilicon/D05/EarlyConfigPeim/EarlyConfigPeimD05.c
> index 76a055cbe980..b374347e5c4d 100644
> --- a/Platform/Hisilicon/D05/EarlyConfigPeim/EarlyConfigPeimD05.c
> +++ b/Platform/Hisilicon/D05/EarlyConfigPeim/EarlyConfigPeimD05.c
> @@ -35,7 +35,7 @@ QResetAp (
>(VOID)WriteBackInvalidateDataCacheRange((VOID *)
> FixedPcdGet64(PcdMailBoxAddress), 8);
>
>if (!PcdGet64 (PcdTrustedFirmwareEnable)) {
> -StartupAp();
> +StartUpBSP ();
>}
> }
>
> diff --git a/Platform/Hisilicon/D05/Library/OemMiscLibD05/OemMiscLibD05.c
> b/Platform/Hisilicon/D05/Library/OemMiscLibD05/OemMiscLibD05.c
> index 4c4c944dbead..a1458da7f0a3 100644
> --- a/Platform/Hisilicon/D05/Library/OemMiscLibD05/OemMiscLibD05.c
> +++ b/Platform/Hisilicon/D05/Library/OemMiscLibD05/OemMiscLibD05.c
> @@ -96,7 +96,7 @@ UINTN OemGetDimmSlot(UINTN Socket, UINTN Channel)
> VOID CoreSelectBoot(VOID)
> {
>if (!PcdGet64 (PcdTrustedFirmwareEnable)) {
> - StartupAp ();
> + StartUpBSP ();
>}
>
>return;
> @@ -128,3 +128,4 @@ BOOLEAN OemIsNeedDisableExpanderBuffer(VOID)
> {
>return TRUE;
> }
> +
> diff --git a/Platform/Hisilicon/D06/EarlyConfigPeim/EarlyConfigPeimD06.c
> b/Platform/Hisilicon/D06/EarlyConfigPeim/EarlyConfigPeimD06.c
> index 0790f7941ae7..a8261d370626 100644
> --- a/Platform/Hisilicon/D06/EarlyConfigPeim/EarlyConfigPeimD06.c
> +++ b/Platform/Hisilicon/D06/EarlyConfigPeim/EarlyConfigPeimD06.c
> @@ -78,7 +78,7 @@ QResetAp (
>
>//SCCL A
>if (!PcdGet64 (PcdTrustedFirmwareEnable)) {
> -StartupAp ();
> +StartUpBSP ();
>}
> }
>
> --
> 2.9.5
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH edk2-platforms] Silicon/Socionext: use variable attributes from Uefi/UefiMultiPhase.h
Use EFI variable attributes from Uefi/UefiMultiPhase.h in PlatformDxe .vfr rather than local definitions. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Leif Lindholm --- .../Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxeHii.vfr | 9 + 1 file changed, 1 insertion(+), 8 deletions(-) diff --git a/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxeHii.vfr b/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxeHii.vfr index 8a395eac68..25b7b49a3d 100644 --- a/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxeHii.vfr +++ b/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxeHii.vfr @@ -15,14 +15,7 @@ #include #include #include - -// -// EFI Variable attributes -// -#define EFI_VARIABLE_NON_VOLATILE 0x0001 -#define EFI_VARIABLE_BOOTSERVICE_ACCESS 0x0002 -#define EFI_VARIABLE_RUNTIME_ACCESS 0x0004 -#define EFI_VARIABLE_READ_ONLY 0x0008 +#include formset guid = SYNQUACER_PLATFORM_FORMSET_GUID, -- 2.11.0 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-platforms v1 06/16] Hisilicon/D06: Add OemGetCpuFreq to encapsulate difference
On Fri, Feb 01, 2019 at 09:34:26PM +0800, Ming Huang wrote:
> From: xingjiang tang
>
> Implementation OemGetCpuFreq() to get cpu frequency from cpld to
> encapsulate project difference, for some projects don't support
> get cpu frequency by this way.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ming Huang
> ---
> Platform/Hisilicon/D06/Include/Library/CpldD06.h | 4
> Silicon/Hisilicon/Include/Library/OemMiscLib.h | 2 ++
> Platform/Hisilicon/D06/Library/OemMiscLibD06/OemMiscLibD06.c | 16
>
> 3 files changed, 22 insertions(+)
>
> diff --git a/Platform/Hisilicon/D06/Include/Library/CpldD06.h
> b/Platform/Hisilicon/D06/Include/Library/CpldD06.h
> index ec9b49f4e70d..4d07a8ab3741 100644
> --- a/Platform/Hisilicon/D06/Include/Library/CpldD06.h
> +++ b/Platform/Hisilicon/D06/Include/Library/CpldD06.h
> @@ -36,4 +36,8 @@
> #define CPLD_X8_X8_X8_BOARD_ID0x92
> #define CPLD_X16_X8_BOARD_ID 0x93
>
> +#define CPLD_CLOCK_FLAG 0xFD
> +#define CPLD_BOM_VER_FLAG0x0B
> +#define BRD_VER_4TH 0x4
What is BRD_VER_4TH? Please write out full words.
Also, this macro needs a CPLD_ prefix.
> +
> #endif /* __CPLDD06_H__ */
> diff --git a/Silicon/Hisilicon/Include/Library/OemMiscLib.h
> b/Silicon/Hisilicon/Include/Library/OemMiscLib.h
> index 86ea6a1b3deb..dfac87d635d9 100644
> --- a/Silicon/Hisilicon/Include/Library/OemMiscLib.h
> +++ b/Silicon/Hisilicon/Include/Library/OemMiscLib.h
> @@ -53,4 +53,6 @@ BOOLEAN OemIsNeedDisableExpanderBuffer(VOID);
>
> extern EFI_STRING_ID gDimmToDevLocator[MAX_SOCKET][MAX_CHANNEL][MAX_DIMM];
> EFI_HII_HANDLE EFIAPI OemGetPackages ();
> +UINTN OemGetCpuFreq (UINT8 Socket);
> +
> #endif
> diff --git a/Platform/Hisilicon/D06/Library/OemMiscLibD06/OemMiscLibD06.c
> b/Platform/Hisilicon/D06/Library/OemMiscLibD06/OemMiscLibD06.c
> index 2a9db46d1ff9..8f2ac308c7b9 100644
> --- a/Platform/Hisilicon/D06/Library/OemMiscLibD06/OemMiscLibD06.c
> +++ b/Platform/Hisilicon/D06/Library/OemMiscLibD06/OemMiscLibD06.c
> @@ -207,3 +207,19 @@ OemIsNeedDisableExpanderBuffer (
> {
>return TRUE;
> }
> +
> +UINTN OemGetCpuFreq (UINT8 Socket)
> +{
> + UINT8 BrdVerData;
Write out full words.
> +
> + BrdVerData = MmioRead8(CPLD_BASE_ADDRESS + CPLD_BOM_VER_FLAG);
Space before (.
> +
> + if (BrdVerData >= BRD_VER_4TH){ //2.5G
What is the comment saying? The number below?
The number below is also saying the number below.
A useful comment would be
"// Board revision 4 and higher run at 2.5GHz
// Earlier revisions run at 2GHz"
At that point you don't even need the #define.
And not really the temporary variable either.
> +return 25;
> + }
> + else
> + {
} else {
/
Leif
> + return 20;
> + }
> +}
> +
> --
> 2.9.5
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-platforms v1 05/16] Hisilicon/D06: Add more PCIe port INT-x support
On Fri, Feb 01, 2019 at 09:34:25PM +0800, Ming Huang wrote:
> From: Jason Zhang
>
> Since NVMe riser width is 6*X4, need add the related
> port's INT-x support to match OS driver.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ming Huang
> ---
> Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Dsdt/Hi1620Pci.asl | 65
> +++-
> 1 file changed, 50 insertions(+), 15 deletions(-)
>
> diff --git a/Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Dsdt/Hi1620Pci.asl
> b/Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Dsdt/Hi1620Pci.asl
> index 27fde2e09bfe..4d9d9d95be68 100644
> --- a/Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Dsdt/Hi1620Pci.asl
> +++ b/Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Dsdt/Hi1620Pci.asl
> @@ -41,11 +41,21 @@ Scope(_SB)
>// adding RPx INTx configure deponds on hardware board topology,
>// if UEFI enables RPx, RPy, RPz... related INTx configure
>// should be added
> + Package () {0x2,0,0,640}, // INT_A
> + Package () {0x2,1,0,641}, // INT_B
> + Package () {0x2,2,0,642}, // INT_C
> + Package () {0x2,3,0,643}, // INT_D
> +
>Package () {0x4,0,0,640}, // INT_A
>Package () {0x4,1,0,641}, // INT_B
>Package () {0x4,2,0,642}, // INT_C
>Package () {0x4,3,0,643}, // INT_D
>
> + Package () {0x6,0,0,640}, // INT_A
> + Package () {0x6,1,0,641}, // INT_B
> + Package () {0x6,2,0,642}, // INT_C
> + Package () {0x6,3,0,643}, // INT_D
> +
>Package () {0x8,0,0,640}, // INT_A
>Package () {0x8,1,0,641}, // INT_B
>Package () {0x8,2,0,642}, // INT_C
> @@ -56,6 +66,11 @@ Scope(_SB)
>Package () {0xC,2,0,642}, // INT_C
>Package () {0xC,3,0,643}, // INT_D
>
> + Package () {0xE,0,0,640}, // INT_A
> + Package () {0xE,1,0,641}, // INT_B
> + Package () {0xE,2,0,642}, // INT_C
> + Package () {0xE,3,0,643}, // INT_D
> +
>Package () {0x10,0,0,640}, // INT_A
>Package () {0x10,1,0,641}, // INT_B
>Package () {0x10,2,0,642}, // INT_C
> @@ -759,26 +774,46 @@ Device (PCI6)
> // adding RPx INTx configure deponds on hardware board topology,
> // if UEFI enables RPx, RPy, RPz... related INTx configure
> // should be added
> -Package () {0x04,0,0,640}, // INT_A
> -Package () {0x04,1,0,641}, // INT_B
> -Package () {0x04,2,0,642}, // INT_C
> -Package () {0x04,3,0,643}, // INT_D
> -
> -Package () {0x08,0,0,640}, // INT_A
> -Package () {0x08,1,0,641}, // INT_B
> -Package () {0x08,2,0,642}, // INT_C
> -Package () {0x08,3,0,643}, // INT_D
> -
> -Package () {0x0C,0,0,640}, // INT_A
> -Package () {0x0C,1,0,641}, // INT_B
> -Package () {0x0C,2,0,642}, // INT_C
> -Package () {0x0C,3,0,643}, // INT_D
Please don't include the non-functional change of dropping the leading
0 (0x0 -> 0x) here together with the functional change of adding new
entries. Please submit as a separate patch.
/
Leif
> +Package () {0x2,0,0,640}, // INT_A
> +Package () {0x2,1,0,641}, // INT_B
> +Package () {0x2,2,0,642}, // INT_C
> +Package () {0x2,3,0,643}, // INT_D
> +
> +Package () {0x4,0,0,640}, // INT_A
> +Package () {0x4,1,0,641}, // INT_B
> +Package () {0x4,2,0,642}, // INT_C
> +Package () {0x4,3,0,643}, // INT_D
> +
> +Package () {0x6,0,0,640}, // INT_A
> +Package () {0x6,1,0,641}, // INT_B
> +Package () {0x6,2,0,642}, // INT_C
> +Package () {0x6,3,0,643}, // INT_D
> +
> +Package () {0x8,0,0,640}, // INT_A
> +Package () {0x8,1,0,641}, // INT_B
> +Package () {0x8,2,0,642}, // INT_C
> +Package () {0x8,3,0,643}, // INT_D
> +
> +Package () {0xC,0,0,640}, // INT_A
> +Package () {0xC,1,0,641}, // INT_B
> +Package () {0xC,2,0,642}, // INT_C
> +Package () {0xC,3,0,643}, // INT_D
> +
> +Package () {0xE,0,0,640}, // INT_A
> +Package () {0xE,1,0,641}, // INT_B
> +Package () {0xE,2,0,642}, // INT_C
> +Package () {0xE,3,0,643}, // INT_D
>
> Package () {0x10,0,0,640}, // INT_A
> Package () {0x10,1,0,641}, // INT_B
> Package () {0x10,2,0,642}, // INT_C
> Package () {0x10,3,0,643}, // INT_D
> - })
> +
> +Package ()
Re: [edk2] [PATCH edk2-platforms 6/8] Silicon/SynQuacer/Stage2Tables: fix 32-bit build
On Mon, Jan 14, 2019 at 06:52:07PM +0100, Ard Biesheuvel wrote: > On Mon, 14 Jan 2019 at 18:02, Ard Biesheuvel > wrote: > > > > The static stage2 page tables don't contain any code, but we are > > relying on the linker to resolve the references to the next level > > tables, so we can only use native word size quantities. So add a > > CPP macro to emit the same quantity in different ways. > > > > Contributed-under: TianoCore Contribution Agreement 1.1 > > Signed-off-by: Ard Biesheuvel > > --- > > Silicon/Socionext/SynQuacer/Stage2Tables/Stage2Tables.S | 12 +--- > > The 'elf64-little' in the .inf is now wrong as well, but it seems I > can just remove that and objcopy will detect the input format. Hmm. Actually, no. When cross-compiling: $ objcopy -O binary -j .rodata /work/git/tianocore/Build/DeveloperBox/DEBUG_GCC5/AARCH64/Silicon/Socionext/SynQuacer/Stage2Tables/Stage2Tables/OUTPUT/Stage2Tables.elf /work/git/tianocore/Build/DeveloperBox/DEBUG_GCC5/AARCH64/Silicon/Socionext/SynQuacer/Stage2Tables/Stage2Tables/OUTPUT/Stage2Tables.bin objcopy: Unable to recognise the format of the input file `/work/git/tianocore/Build/DeveloperBox/DEBUG_GCC5/AARCH64/Silicon/Socionext/SynQuacer/Stage2Tables/Stage2Tables/OUTPUT/Stage2Tables.elf' If I put -I elf64-little back, the command succeeds. If I explicitly call the cross-toolchain objcopy, the command succeeds without that addition. When building natively, this works fine without the flag. Why do we even end up running the build machine native objcopy here? / Leif > > 1 file changed, 9 insertions(+), 3 deletions(-) > > > > diff --git a/Silicon/Socionext/SynQuacer/Stage2Tables/Stage2Tables.S > > b/Silicon/Socionext/SynQuacer/Stage2Tables/Stage2Tables.S > > index af55f27bca47..28c7a6ac970f 100644 > > --- a/Silicon/Socionext/SynQuacer/Stage2Tables/Stage2Tables.S > > +++ b/Silicon/Socionext/SynQuacer/Stage2Tables/Stage2Tables.S > > @@ -32,6 +32,12 @@ > > #define TT_S2_L3_PAGE (0x1 << 1) > > #define TT_S2_VALID (0x1 << 0) > > > > +#ifdef __aarch64__ > > +#define QWORD(x).quad (x) > > +#else > > +#define QWORD(x).long (x), 0 > > +#endif > > + > >.altmacro > >.macrofor, start, count, do, arg2, arg3, arg4 > >.if \count == 1 > > @@ -69,7 +75,7 @@ > >.section ".rodata", "a", %progbits > >/* level 1 */ > >s2_mem_entry 0 /* 0x_ - 0x3fff_ */ > > - .quad 1f + TT_S2_TABLE /* 0x4000_ - 0x7fff_ */ > > + QWORD (1f + TT_S2_TABLE) /* 0x4000_ - 0x7fff_ */ > >for 2, 246, s2_mem_entry /* 0x8000_ - 0x3d__ */ > >for 248, 8, s2_dev_entry /* PCIe MMIO64 */ > >for 256, 768, s2_mem_entry /* 0x40__ - 0xff__ */ > > @@ -77,12 +83,12 @@ > >/* level 2 */ > > 1:for 0, 256, s2_mem_entry, 21, 0x4000, 1 > > > > - .quad 2f + TT_S2_TABLE /* 0x6000_ -> RC #0 bus 0 */ > > + QWORD (2f + TT_S2_TABLE) /* 0x6000_ -> RC #0 bus 0 */ > >for 1, 15, s2_mem_entry, 21, 0x6000 > >for 0, 48, s2_mem_entry, 21, 0x6200, 1 > >for 0, 64, s2_dev_entry, 21, 0x6800, 1 /* PCIe MMIO32 */ > > > > - .quad 3f + TT_S2_TABLE /* 0x7000_ -> RC #1 bus 0 */ > > + QWORD (3f + TT_S2_TABLE) /* 0x7000_ -> RC #1 bus 0 */ > >for 1, 15, s2_mem_entry, 21, 0x7000 > >for 0, 48, s2_mem_entry, 21, 0x7200, 1 > >for 0, 64, s2_dev_entry, 21, 0x7800, 1 /* PCIe MMIO32 */ > > -- > > 2.17.1 > > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-platforms v1 02/16] Hisilicon/D0x: Add DriverHealthManagerDxe
On Fri, Feb 01, 2019 at 09:34:22PM +0800, Ming Huang wrote:
> DriverHealthManagerDxe Collect driver health form of third party
> drivers to repair no healthy card.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ming Huang
Reviewed-by: Leif Lindholm
> ---
> Platform/Hisilicon/D03/D03.dsc | 1 +
> Platform/Hisilicon/D05/D05.dsc | 1 +
> Platform/Hisilicon/D06/D06.dsc | 1 +
> Platform/Hisilicon/D03/D03.fdf | 1 +
> Platform/Hisilicon/D05/D05.fdf | 1 +
> Platform/Hisilicon/D06/D06.fdf | 1 +
> 6 files changed, 6 insertions(+)
>
> diff --git a/Platform/Hisilicon/D03/D03.dsc b/Platform/Hisilicon/D03/D03.dsc
> index 3f59be22ec8e..fe443dd929ad 100644
> --- a/Platform/Hisilicon/D03/D03.dsc
> +++ b/Platform/Hisilicon/D03/D03.dsc
> @@ -492,6 +492,7 @@ [Components.common]
>
>MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
>MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
> + MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerDxe.inf
>MdeModulePkg/Universal/BdsDxe/BdsDxe.inf
>
> SignedCapsulePkg/Universal/SystemFirmwareUpdate/SystemFirmwareUpdateDxe.inf {
>
> diff --git a/Platform/Hisilicon/D05/D05.dsc b/Platform/Hisilicon/D05/D05.dsc
> index 25db1c38d287..0c4f21fbe056 100644
> --- a/Platform/Hisilicon/D05/D05.dsc
> +++ b/Platform/Hisilicon/D05/D05.dsc
> @@ -638,6 +638,7 @@ [Components.common]
>MdeModulePkg/Universal/MemoryTest/NullMemoryTestDxe/NullMemoryTestDxe.inf
>MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
>MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
> + MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerDxe.inf
>MdeModulePkg/Universal/BdsDxe/BdsDxe.inf
>
>
> SignedCapsulePkg/Universal/SystemFirmwareUpdate/SystemFirmwareUpdateDxe.inf {
> diff --git a/Platform/Hisilicon/D06/D06.dsc b/Platform/Hisilicon/D06/D06.dsc
> index cbbd99e4a659..6d581337f199 100644
> --- a/Platform/Hisilicon/D06/D06.dsc
> +++ b/Platform/Hisilicon/D06/D06.dsc
> @@ -435,6 +435,7 @@ [Components.common]
>
> Silicon/Hisilicon/Hi1620/Drivers/Pl011DebugSerialPortInitDxe/Pl011DebugSerialPortInitDxe.inf
>MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
>MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
> + MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerDxe.inf
>MdeModulePkg/Universal/BdsDxe/BdsDxe.inf
>
> SignedCapsulePkg/Universal/SystemFirmwareUpdate/SystemFirmwareUpdateDxe.inf {
>
> diff --git a/Platform/Hisilicon/D03/D03.fdf b/Platform/Hisilicon/D03/D03.fdf
> index f453f9e46321..3f07b2e57778 100644
> --- a/Platform/Hisilicon/D03/D03.fdf
> +++ b/Platform/Hisilicon/D03/D03.fdf
> @@ -295,6 +295,7 @@ [FV.FvMain]
>INF
> MdeModulePkg/Universal/MemoryTest/NullMemoryTestDxe/NullMemoryTestDxe.inf
>INF MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
>INF MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
> + INF
> MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerDxe.inf
>INF MdeModulePkg/Universal/BdsDxe/BdsDxe.inf
>
> [FV.FVMAIN_COMPACT]
> diff --git a/Platform/Hisilicon/D05/D05.fdf b/Platform/Hisilicon/D05/D05.fdf
> index 85dd791564a4..9632aea4b00e 100644
> --- a/Platform/Hisilicon/D05/D05.fdf
> +++ b/Platform/Hisilicon/D05/D05.fdf
> @@ -314,6 +314,7 @@ [FV.FvMain]
>INF
> MdeModulePkg/Universal/MemoryTest/NullMemoryTestDxe/NullMemoryTestDxe.inf
>INF MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
>INF MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
> + INF
> MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerDxe.inf
>INF MdeModulePkg/Universal/BdsDxe/BdsDxe.inf
>
> [FV.FVMAIN_COMPACT]
> diff --git a/Platform/Hisilicon/D06/D06.fdf b/Platform/Hisilicon/D06/D06.fdf
> index fda29ab322e9..a937660a09e2 100644
> --- a/Platform/Hisilicon/D06/D06.fdf
> +++ b/Platform/Hisilicon/D06/D06.fdf
> @@ -319,6 +319,7 @@ [FV.FvMain]
>INF
> MdeModulePkg/Universal/MemoryTest/NullMemoryTestDxe/NullMemoryTestDxe.inf
>INF MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
>INF MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
> + INF
> MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerDxe.inf
>INF MdeModulePkg/Universal/BdsDxe/BdsDxe.inf
>
> [FV.FVMAIN_COMPACT]
> --
> 2.9.5
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-platforms v1 01/16] Hisilicon/D0x: Remove SerdesLib
On Fri, Feb 01, 2019 at 09:34:21PM +0800, Ming Huang wrote: > SerdesLib is useless for SmbiosMiscDxe and D06, so remove it. Should it not then also delete #include from Platform/Hisilicon/D06/Library/OemMiscLibD06/BoardFeatureD06.c, Platform/Hisilicon/D06/Library/OemMiscLibD06/OemMiscLibD06.c and Silicon/Hisilicon/Drivers/Smbios/SmbiosMiscDxe/Type09/MiscSystemSlotDesignationFunction.c ? Meanwhile, Platform/Hisilicon/D03/Library/OemMiscLib2P/BoardFeature2PHi1610.c and Platform/Hisilicon/D05/Library/OemMiscLibD05/BoardFeatureD05.c both include this header, but Platform/Hisilicon/D03/Library/OemMiscLib2P/OemMiscLib2PHi1610.inf and Platform/Hisilicon/D05/Library/OemMiscLibD05/OemMiscLibD05.inf do not declare the dependency. Can you investigate and submit an updated patch addressing all of the unnecessary references? Best Regards, Leif > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ming Huang > --- > Platform/Hisilicon/D06/D06.dsc | 2 -- > Silicon/Hisilicon/Drivers/Smbios/SmbiosMiscDxe/SmbiosMiscDxe.inf | 1 - > 2 files changed, 3 deletions(-) > > diff --git a/Platform/Hisilicon/D06/D06.dsc b/Platform/Hisilicon/D06/D06.dsc > index 396bd03c9d24..cbbd99e4a659 100644 > --- a/Platform/Hisilicon/D06/D06.dsc > +++ b/Platform/Hisilicon/D06/D06.dsc > @@ -64,8 +64,6 @@ [LibraryClasses.common] > >CpldIoLib|Silicon/Hisilicon/Library/CpldIoLib/CpldIoLib.inf > > - SerdesLib|Silicon/Hisilicon/Hi1620/Library/Hi1620Serdes/Hi1620SerdesLib.inf > - >TimeBaseLib|EmbeddedPkg/Library/TimeBaseLib/TimeBaseLib.inf > > RealTimeClockLib|Silicon/Hisilicon/Library/M41T83RealTimeClockLib/M41T83RealTimeClockLib.inf >OemMiscLib|Platform/Hisilicon/D06/Library/OemMiscLibD06/OemMiscLibD06.inf > diff --git a/Silicon/Hisilicon/Drivers/Smbios/SmbiosMiscDxe/SmbiosMiscDxe.inf > b/Silicon/Hisilicon/Drivers/Smbios/SmbiosMiscDxe/SmbiosMiscDxe.inf > index 61cead7779b9..8e5c56fa41fd 100644 > --- a/Silicon/Hisilicon/Drivers/Smbios/SmbiosMiscDxe/SmbiosMiscDxe.inf > +++ b/Silicon/Hisilicon/Drivers/Smbios/SmbiosMiscDxe/SmbiosMiscDxe.inf > @@ -77,7 +77,6 @@ [LibraryClasses] > >IpmiCmdLib > > - SerdesLib > > [Protocols] >gEfiSmbiosProtocolGuid # PROTOCOL ALWAYS_CONSUMED > -- > 2.9.5 > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-platforms v1 12/16] Hisilicon/D06: Use new flash layout
On Fri, Feb 01, 2019 at 09:34:32PM +0800, Ming Huang wrote: > In new flash layout, BIOS fd change from offset 1M to 8M in 16M > spi flash. This bit > Use the new CustomData.Fv which indicate the offset > of fd and which flash area can be updated for BMC. is of critical importance. Should be its own paragraph. How does this change affect variable storage? Will the server maintain state after a firmware upgrade, or will the operator need to rescue it manually via the BMC? / Leif > > This patch is relative with patch "Use new flash layout" in > edk2-non-osi. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ming Huang > --- > Platform/Hisilicon/D06/D06.fdf | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/Platform/Hisilicon/D06/D06.fdf b/Platform/Hisilicon/D06/D06.fdf > index d495ad7f264c..f72b513352fb 100644 > --- a/Platform/Hisilicon/D06/D06.fdf > +++ b/Platform/Hisilicon/D06/D06.fdf > @@ -29,7 +29,7 @@ [DEFINES] > > > [FD.D06] > > -BaseAddress = 0x20410|gArmTokenSpaceGuid.PcdFdBaseAddress # The base > address of the Firmware in NOR Flash. > +BaseAddress = 0x20480|gArmTokenSpaceGuid.PcdFdBaseAddress # The base > address of the Firmware in NOR Flash. > > Size = 0x0040|gArmTokenSpaceGuid.PcdFdSize # The size > in bytes of the FLASH Device > ErasePolarity = 1 > @@ -124,7 +124,7 @@ [FD.D06] > 0x003E|0x0001 > > 0x003F|0x0001 > -FILE = Platform/Hisilicon/D0x-CustomData.Fv > +FILE = Platform/Hisilicon/D06/CustomData.Fv > > > > # > -- > 2.9.5 > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-non-osi v1 6/7] Hisilicon/D06: Fix numa node wrong issue
*bangs head on desk*
That question I just asked as a reply to
("Silicon/Hisilicon/D06: Set TA as Node 0 for TA boot")
was meant to be a comment on this patch.
So - was this change one that was meant to happen together with
edk2-platforms "Silicon/Hisilicon/D06: Set TA as Node 0 for TA boot"?
What is the user visible behaviour that this change addresses?
/
Leif
On Fri, Feb 01, 2019 at 10:25:06PM +0800, Ming Huang wrote:
> Numa informations are acquired from HOB that build from memory
> initialization module. Correct numa informations to match booting
> from TA(Totem A or super cpu cluster A).
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ming Huang
> ---
> Platform/Hisilicon/D06/MemoryInitPei/MemoryInit.efi | Bin 297696 -> 358656
> bytes
> 1 file changed, 0 insertions(+), 0 deletions(-)
>
> diff --git a/Platform/Hisilicon/D06/MemoryInitPei/MemoryInit.efi
> b/Platform/Hisilicon/D06/MemoryInitPei/MemoryInit.efi
> index 5fba353..fea1475 100644
> Binary files a/Platform/Hisilicon/D06/MemoryInitPei/MemoryInit.efi and
> b/Platform/Hisilicon/D06/MemoryInitPei/MemoryInit.efi differ
> --
> 2.9.5
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-platforms v3 4/5] Silicon/Hisilicon/D06: Set TA as Node 0 for TA boot
On Tue, Nov 20, 2018 at 05:01:49PM +0800, Ming Huang wrote:
> Linux kernel will recognize NUMA node by processor order,
> and the Node and proximity domain (PXM) will be not identical
> between BIOS and OS kernel after changing to TA(Totem A) boot,
> so adjust the NUMA node number and proximity domain (PXM) to
> match.
Is this a change that should have gone in together with edk2-platforms
cc2b26de91e09be9f9789d553e7b3e079c822efb?
("Silicon/Hisilicon/D06: Set TA as Node 0 for TA boot")
What is the visible effect to a user of the partial change?
Failure to boot? Poor performance?
/
Leif
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ming Huang
> ---
> Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Dsdt/Hi1620Pci.asl | 28 +--
> Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Hi1620Iort.asl | 18 +-
> Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Hi1620Srat.aslc| 194
> ++--
> 3 files changed, 120 insertions(+), 120 deletions(-)
>
> diff --git a/Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Dsdt/Hi1620Pci.asl
> b/Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Dsdt/Hi1620Pci.asl
> index 87a2da8843e4..27fde2e09bfe 100644
> --- a/Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Dsdt/Hi1620Pci.asl
> +++ b/Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Dsdt/Hi1620Pci.asl
> @@ -212,7 +212,7 @@ Scope(_SB)
>
>Method (_PXM, 0, NotSerialized)
>{
> -Return(0x01)
> +Return(0x00)
>}
> } // Device(PCI0)
>
> @@ -262,7 +262,7 @@ Device (PCI1)
>
>Method (_PXM, 0, NotSerialized)
>{
> -Return(0x01)
> +Return(0x00)
>}
> } // Device(PCI1)
>
> @@ -325,7 +325,7 @@ Device (PCI2)
>
>Method (_PXM, 0, NotSerialized)
>{
> -Return(0x01)
> +Return(0x00)
>}
> }
>
> @@ -374,7 +374,7 @@ Device (PCI3)
>
>Method (_PXM, 0, NotSerialized)
>{
> -Return(0x01)
> +Return(0x00)
>}
> }
>
> @@ -423,7 +423,7 @@ Device (PCI4)
>
>Method (_PXM, 0, NotSerialized)
>{
> -Return(0x01)
> +Return(0x00)
>}
> }
>
> @@ -733,7 +733,7 @@ Device (PCI5)
>
>Method (_PXM, 0, NotSerialized)
>{
> -Return(0x01)
> +Return(0x00)
>}
> }
>
> @@ -866,11 +866,11 @@ Device (PCI6)
> // Never allow SHPC (no SHPC controller in this system)
> And(CTRL,0x1D,CTRL)
>
> -If(LNotEqual(Arg1,One)) { // Unknown revision
> +If(LNotEqual(Arg1,One)) { // Unknown revision
>Or(CDW1,0x08,CDW1)
> }
>
> -If(LNotEqual(CDW3,CTRL)) { // Capabilities bits were masked
> +If(LNotEqual(CDW3,CTRL)) { // Capabilities bits were masked
>Or(CDW1,0x10,CDW1)
> }
>
> @@ -924,7 +924,7 @@ Device (PCI6)
>
>Method (_PXM, 0, NotSerialized)
>{
> -Return(0x03)
> +Return(0x02)
>}
> } // Device(PCI6)
>
> @@ -974,7 +974,7 @@ Device (PCI7)
>
>Method (_PXM, 0, NotSerialized)
>{
> -Return(0x03)
> +Return(0x02)
>}
> } // Device(PCI7)
>
> @@ -1038,7 +1038,7 @@ Device (PCI8)
>
>Method (_PXM, 0, NotSerialized)
>{
> -Return(0x03)
> +Return(0x02)
>}
> }// Device(PCI8)
>
> @@ -1087,7 +1087,7 @@ Device (PCI9)
>
>Method (_PXM, 0, NotSerialized)
>{
> -Return(0x03)
> +Return(0x02)
>}
> }// Device(PCI9)
>
> @@ -1136,7 +1136,7 @@ Device (PCIA)
>
>Method (_PXM, 0, NotSerialized)
>{
> -Return(0x03)
> +Return(0x02)
>}
> }// Device(PCIA)
>
> @@ -1210,7 +1210,7 @@ Device (PCIB)
>
>Method (_PXM, 0, NotSerialized)
>{
> -Return(0x03)
> +Return(0x02)
>}
> }
>
> diff --git a/Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Hi1620Iort.asl
> b/Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Hi1620Iort.asl
> index 08e15c17bf40..994018db96b5 100644
> --- a/Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Hi1620Iort.asl
> +++ b/Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Hi1620Iort.asl
> @@ -53,7 +53,7 @@
> [0004] PRI Interrupt :
> [0004] GERR Interrupt :
> [0004] Sync Interrupt :
> -[0004] Proximity Domain : 0001
> +[0004] Proximity Domain :
> [0004] DeviceID mapping index : 0002
>
> [0004] Input base :
> @@ -97,7 +97,7 @@
> [0004] PRI Interrupt :
> [0004] GERR Interrupt :
> [0004] Sync Interrupt :
> -[0004] Proximity Domain : 0001
> +[0004] Proximity Domain :
> [0004] DeviceID mapping index : 0001
>
> [0004] Input base : 7c00
> @@ -135,7 +135,7 @@
> [0004] PRI Interrupt :
> [0004] GERR Interrupt :
> [0004] Sync Interrupt :
> -[0004] Proximity Domain : 0001
> +[0004] Proximity Domain :
Re: [edk2] [PATCH] MdePkg/BaseLib: implement SpeculationBarrier() for ARM and AArch64
On Wed, Feb 06, 2019 at 12:08:22AM +, Ard Biesheuvel wrote: > Replace the dummy C implementation of SpeculationBarrier() with > implementations consisting of the recommended DSB SY + ISB sequence, > as recommended by ARM in the whitepaper "Cache Speculation Side-channels" > version 2.4, dated October 2018. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ard Biesheuvel Patch looks fine. Reviewed-by: Leif Lindholm Question: do we expect performance impact to be sufficient to motivate a Pcd to be able to disable the barrier on unaffected processors? Regards, Leif > --- > MdePkg/Library/BaseLib/AArch64/SpeculationBarrier.S | 39 > > MdePkg/Library/BaseLib/AArch64/SpeculationBarrier.asm | 38 > +++ > MdePkg/Library/BaseLib/Arm/SpeculationBarrier.S | 39 > > MdePkg/Library/BaseLib/Arm/SpeculationBarrier.asm | 39 > > MdePkg/Library/BaseLib/Arm/SpeculationBarrier.c | 30 --- > MdePkg/Library/BaseLib/BaseLib.inf| 7 +++- > 6 files changed, 160 insertions(+), 32 deletions(-) > > diff --git a/MdePkg/Library/BaseLib/AArch64/SpeculationBarrier.S > b/MdePkg/Library/BaseLib/AArch64/SpeculationBarrier.S > new file mode 100644 > index ..500bdadca5d2 > --- /dev/null > +++ b/MdePkg/Library/BaseLib/AArch64/SpeculationBarrier.S > @@ -0,0 +1,39 @@ > +##-- > +# > +# SpeculationBarrier() for AArch64 > +# > +# Copyright (c) 2019, Linaro Ltd. 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. > +# > +##-- > + > +.text > +.p2align 2 > + > +GCC_ASM_EXPORT(SpeculationBarrier) > + > + > +#/** > +# Uses as a barrier to stop speculative execution. > +# > +# Ensures that no later instruction will execute speculatively, until all > prior > +# instructions have completed. > +# > +#**/ > +#VOID > +#EFIAPI > +#SpeculationBarrier ( > +# VOID > +# ); > +# > +ASM_PFX(SpeculationBarrier): > +dsb sy > +isb > +ret > diff --git a/MdePkg/Library/BaseLib/AArch64/SpeculationBarrier.asm > b/MdePkg/Library/BaseLib/AArch64/SpeculationBarrier.asm > new file mode 100644 > index ..0c4b915b7798 > --- /dev/null > +++ b/MdePkg/Library/BaseLib/AArch64/SpeculationBarrier.asm > @@ -0,0 +1,38 @@ > +;-- > +; > +; SpeculationBarrier() for AArch64 > +; > +; Copyright (c) 2019, Linaro Ltd. 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. > +; > +;-- > + > + EXPORT SpeculationBarrier > + AREA BaseLib_LowLevel, CODE, READONLY > + > +;/** > +; Uses as a barrier to stop speculative execution. > +; > +; Ensures that no later instruction will execute speculatively, until all > prior > +; instructions have completed. > +; > +;**/ > +;VOID > +;EFIAPI > +;SpeculationBarrier ( > +; VOID > +; ); > +; > +SpeculationBarrier > +dsb sy > +isb > +ret > + > + END > diff --git a/MdePkg/Library/BaseLib/Arm/SpeculationBarrier.S > b/MdePkg/Library/BaseLib/Arm/SpeculationBarrier.S > new file mode 100644 > index ..7857558aba17 > --- /dev/null > +++ b/MdePkg/Library/BaseLib/Arm/SpeculationBarrier.S > @@ -0,0 +1,39 @@ > +##-- > +# > +# SpeculationBarrier() for AArch64 > +# > +# Copyright (c) 2019, Linaro Ltd. All rights reserved. > +# > +# This program
Re: [edk2] [PATCH] Maintainers: add TPM2 reviewers for OvmfPkg
On Mon, Feb 11, 2019 at 01:53:43PM +0100, Laszlo Ersek wrote: > OVMF can be built with a significant amount of TPM2 code now; add > Marc-André and Stefan as Reviewers for TPM2-related patches. > > Keep the list of "R" entries alphabetically sorted. For this patch: Reviewed-by: Leif Lindholm However - unrelated sidenote: Julien, is that address still valid for you? / Leif > Cc: Andrew Fish > Cc: Ard Biesheuvel > Cc: Jordan Justen > Cc: Leif Lindholm > Cc: Marc-André Lureau > Cc: Michael D Kinney > Cc: Stefan Berger > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Laszlo Ersek > --- > Maintainers.txt | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/Maintainers.txt b/Maintainers.txt > index 3b2676bc32ea..92f683827923 100644 > --- a/Maintainers.txt > +++ b/Maintainers.txt > @@ -214,14 +214,16 @@ M: Ray Ni > OvmfPkg > W: http://www.tianocore.org/ovmf/ > M: Jordan Justen > M: Laszlo Ersek > M: Ard Biesheuvel > R: Anthony Perard > R: Julien Grall > +R: Marc-André Lureau > +R: Stefan Berger > S: Maintained > > PcAtChipsetPkg > W: https://github.com/tianocore/tianocore.github.io/wiki/PcAtChipsetPkg > M: Ray Ni > > QuarkPlatformPkg, QuarkSocPkg > -- > 2.19.1.3.g30247aa5d201 > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] BaseTools: Fix build failure when specifying multiple BUILDTARGET
On Tue, Feb 05, 2019 at 10:03:21AM +0100, Laszlo Ersek wrote:
> On 02/05/19 02:23, Philippe Mathieu-Daudé wrote:
> > Since 9c2d68c0a299 the build tools default to the python version
> > provided by the ${PYTHON} environment variable.
> > However the Python3 transition is not effective before d943b0c339fe.
>
> (1) Do you mean "functional" rather than "effective"?
>
> (2) Why is this information relevant for this commit? I see that commit
> f8d11e5a4aaa, referenced below, falls between the above two, but I'm
> unsure if that has any special relevance.
>
> If the above paragraph is just background info, that's OK with me, of
> course.
>
> > With Python3, the dict.value() method returns an iterator.
> > If a dictionary is updated while an iterator on his keys is used,
>
> (3) s/his/its/
>
> > a RuntimeError is generated.
> > Converting the iterator to a list() forces a copy of the mutable
> > keys in an immutable list which can be safely iterated.
> >
> > Commit f8d11e5a4aaa converted various uses but missed one:
> > When specifying multiple BUILDTARGET, the first target builds
> > successfully, but then the PGen.BuildDatabase._CACHE_ dictionary is
> > updated, and the next target accessing it triggers a RuntimeError.
>
> (4) Can we clarify this please; I think it's not the "next target" that
> accesses the dictionary, instead the code accesses the next target in
> the dictionary. How about
>
> s/the next target accessing it/accessing the next target/
>
> ?
>
> >
> > Convert this iterator to an immutable list, to solve this build error:
> >
> > $ build -a IA32 -t GCC5 -b RELEASE -b NOOPT -p OvmfPkg/OvmfPkgIa32.dsc
> > [...]
> > Processing meta-data ...
> > build.py...
> > : error C0DE: Unknown fatal error when processing
> > [OvmfPkg/OvmfPkgIa32.dsc]
> >
> > (Please send email to edk2-devel@lists.01.org for help, attaching
> > following call stack trace!)
> >
> > (Python 3.5.3 on linux) Traceback (most recent call last):
> > File
> > "BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py", line
> > 2387, in Main
> > MyBuild.Launch()
> > File
> > "BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py", line
> > 2141, in Launch
> > self._MultiThreadBuildPlatform()
> > File
> > "BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py", line
> > 1921, in _MultiThreadBuildPlatform
> > self.Progress
> > File "BaseTools/Source/Python/AutoGen/AutoGen.py", line 304, in
> > __init__
> > self._InitWorker(Workspace, MetaFile, Target, Toolchain, Arch,
> > *args, **kwargs)
> > File "BaseTools/Source/Python/AutoGen/AutoGen.py", line 477, in
> > _InitWorker
> > for BuildData in PGen.BuildDatabase._CACHE_.values():
> > RuntimeError: dictionary changed size during iteration
> >
> > Reported-by: Leif Lindholm
> > Fixes: f8d11e5a4aaa90bf63b4789f3993dd6d16c60787
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Philippe Mathieu-Daude
> > Tested-by: Leif Lindholm
> > ---
> > BaseTools/Source/Python/AutoGen/AutoGen.py | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/BaseTools/Source/Python/AutoGen/AutoGen.py
> > b/BaseTools/Source/Python/AutoGen/AutoGen.py
> > index a95d2c710e..12592a2a46 100644
> > --- a/BaseTools/Source/Python/AutoGen/AutoGen.py
> > +++ b/BaseTools/Source/Python/AutoGen/AutoGen.py
> > @@ -474,7 +474,7 @@ class WorkspaceAutoGen(AutoGen):
> >
> > # generate the SourcePcdDict and BinaryPcdDict
> > PGen = PlatformAutoGen(self, self.MetaFile, Target, Toolchain,
> > Arch)
> > -for BuildData in PGen.BuildDatabase._CACHE_.values():
> > +for BuildData in list(PGen.BuildDatabase._CACHE_.values()):
> > if BuildData.Arch != Arch:
> > continue
> > if BuildData.MetaFile.Ext == '.inf':
> >
>
> LGTM :)
>
> With the commit message updated (as you prefer):
>
> Acked-by: Laszlo Ersek
I would be surprised if we hear back from the BaseTools maintainers
this week (Chinese New Year). For me, I have both a simple workaround
and this patch, so I'm OK with waiting.
But if anyone reports issues with CI environments or similar, I would
say either you or I could push this patch in their absence.
/
Leif
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] BaseTools: handling of $(ARCH) in .dsc/.fdf when multiple -a specified
On Mon, Feb 04, 2019 at 08:02:55PM +0100, Laszlo Ersek wrote: > > Now, the Ia32X64 target is very much of a special case, which I don't > > necessarily see as usefully supported by the current .dsc > > specification. But I believe we need to do one of > > - banning (simultaneous) multi-architecture platforms > > - treating them the same as multi-target (-b) builds (build them separately) > > - have a defined way of handling them > > Only option #3 can work here. OvmfPkgIa32X64.dsc is a platform where the > Reset Vector, SEC and PEI phases are built for IA32, the rest (i.e. > DXE+) is built for X64, and the images are finally organized into a > single flash device (FD). > > The key PCD is > > gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSwitchToLongMode|TRUE > > which you won't see in either the pure IA32 or the pure X64 OVMF > platform -- as none of those have to switch from 32-bit mode to 64-bit > (long) mode at the PEI/DXE boundary: > > - OvmfPkgIa32.dsc: > gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSwitchToLongMode|FALSE > > - OvmfPkgIa32X64.dsc: > gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSwitchToLongMode|TRUE > > - OvmfPkgX64.dsc: > gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSwitchToLongMode|FALSE > > > Regarding the usefulness of the OvmfPkgIa32X64.dsc, that's presently the > *only* OVMF platform that is suitable for production use. It is the only > platform that: > > (a) supports Secure Boot, *and* > (b) includes ACPI S3 suspend/resume support, *and* > (c) protects sensitive data related to (a) and (b), i.e. non-volatile > UEFI variables, and the LockBox data structure, respectively, by > inclusion of the SMM driver stack, and usage of SMRAM, *and* > (d) supports 64-bit OS-es. OK, at that point I totally agree only option #3 is workable. > > So, am I missing something, or does this require a change in > > BaseTools? > > I believe you may have missed that "-a IA32 -a X64" stands for more than > just "build this set of modules for each of IA32 and X64, separately". > > AIUI, "-a IA32 -a X64" it means "build the Components.* sections > (plural) as dictated by the '-a' flags, and then organize the full > (multi-arch) set of modules into the flash device(s), described by > FLASH_DEFINITION". Nope, I did spot that actually :) Although I was certainly confused the first 10 times I looked at those .dscs. And it could still be squashed into a common .dsc/.fdf if there was a useful way of handling $(ARCH) when multiple -a have been specified to the build command. / Leif ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] BaseTools: handling of $(ARCH) in .dsc/.fdf when multiple -a specified
Hi Bob, Liming, So, I've been playing around with merging the .dsc/.fdf files in OvmfPkg. Merging IA32 and X64 is simple enough, since you can test on !if $(ARCH) == "X64" However, from what I can tell, when trying to merge in the OvmfPkgIa32X64 platform - what you actually end up with in $(ARCH) when specifying multiple -a is a python list rather than a single string. To explain the problem in code, tryin to build the platform described by --- [Defines] PLATFORM_NAME = Ovmf PLATFORM_GUID = 5a9e7754-d81b-49ea-85ad-69eaa7b1539b PLATFORM_VERSION = 0.1 DSC_SPECIFICATION = 0x00010005 SUPPORTED_ARCHITECTURES= IA32|X64 BUILD_TARGETS = DEBUG|NOOPT|RELEASE !if "$(ARCH)" == "IA32 X64" or "$(ARCH)" == "X64 IA32" OUTPUT_DIRECTORY = Build/OvmfDummy !else OUTPUT_DIRECTORY = Build/Ovmf$(ARCH)Real !endif --- using the command line 'build -t GCC5 -a IA32 -a X64 -b DEBUG -p Test.dsc' inevitably results in an output like --- Build environment: Linux-4.9.0-3-amd64-x86_64-with-debian-9.7 Build start time: 18:21:33, Feb.04 2019 WORKSPACE= /work/git/edk2 EDK_TOOLS_PATH = /work/git/edk2/BaseTools CONF_PATH= /work/git/edk2/Conf PYTHON_COMMAND = /usr/bin/python3.5 build.py... /work/git/edk2/Test.dsc(11): error 3001: No space is allowed in OUTPUT_DIRECTORY Build/OvmfIA32 X64Real - Failed - --- Now, the Ia32X64 target is very much of a special case, which I don't necessarily see as usefully supported by the current .dsc specification. But I believe we need to do one of - banning (simultaneous) multi-architecture platforms - treating them the same as multi-target (-b) builds (build them separately) - have a defined way of handling them So, am I missing something, or does this require a change in BaseTools? Best Regards, Leif ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 0/6] fix top-level package builds for AARCH64/ARM
Hmm, I kind of dropped the ball on this set, waiting for feedback on
the reworked version of 1/6.
In the meantime, Ard submitted an identical fix for 4/6
"MdeModulePkg: drop DebugSupportDxe from AARCH64 components" which got
merged as fc27682813
("MdeModulePkg/MdeModulePkg/dsc: move DxeDebugSupportDxe to x86 only section")
Since I now have R-b for the set, I have just pushed the remaining 5
as 6c61ec4c62..3b6c73f13e.
On Thu, Nov 01, 2018 at 03:36:36PM +, Leif Lindholm wrote:
> Most of the top-level packages should be buildable for all architectures
> Here is a fairly trivial set that makes that happen.
>
> Leif Lindholm (6):
> AppPkg: fix webserver build for !Ia32/X64
> IntelFrameworkModulePkg: fix build for AARCH64/ARM
> IntelFrameworkPkg: fix build for AARCH64/ARM
> MdeModulePkg: drop DebugSupportDxe from AARCH64 components
> SecurityPkg: fix package build on ARM
> SignedCapsulePkg: enable package build for AARCH64/ARM
>
> Cc: Daryl McDaniel
> Cc: Jaben Carsey
> Cc: Liming Gao
> Cc: Michael D Kinney
> Cc: Liming Gao
> Cc: Star Zeng
> Cc: Jian J Wang
> Cc: Chao Zhang
> Cc: Jiewen Yao
>
> IntelFrameworkModulePkg/IntelFrameworkModulePkg.dsc | 13 -
> IntelFrameworkPkg/IntelFrameworkPkg.dsc | 2 +-
> MdeModulePkg/MdeModulePkg.dsc | 2 +-
> SecurityPkg/SecurityPkg.dsc | 11 +++
> SignedCapsulePkg/SignedCapsulePkg.dsc | 15 ++-
> AppPkg/Applications/Sockets/WebServer/WebServer.h | 2 ++
> 6 files changed, 41 insertions(+), 4 deletions(-)
>
> --
> 2.11.0
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] BaseTools: build failure when specifying multiple BUILDTARGET
On Mon, Feb 04, 2019 at 01:22:03PM +0100, Philippe Mathieu-Daudé wrote: > On 2/4/19 12:54 PM, Philippe Mathieu-Daudé wrote: > > On 2/4/19 10:58 AM, Leif Lindholm wrote: > >> Hi Bob, Liming, > >> > >> With the latest BaseTools (current HEAD, 6c61ec4c62), building > >> multiple targets from a single command line crashes. > >> > >> To reproduce: > >> build -a IA32 -t GCC5 -b RELEASE -b NOOPT -p OvmfPkg/OvmfPkgIa32.dsc > >> (I first built with -n32, but dropped that to see if it would make a > >> difference - it does not.) > >> > >> The first target specified builds successfully. When starting on the > >> second, the output is as below, and build exits. > >> > >> / > >> Leif > >> > >> Architecture(s) = IA32 > >> Build target = NOOPT > >> Toolchain= GCC5 > >> > >> Active Platform = /work/git/edk2/OvmfPkg/OvmfPkgIa32.dsc > >> Flash Image Definition = /work/git/edk2/OvmfPkg/OvmfPkgIa32.fdf > >> > >> Processing meta-data ... > >> > >> > >> build.py... > >> : error C0DE: Unknown fatal error when processing > >> [/work/git/edk2/OvmfPkg/OvmfPkgIa32.dsc] > >> > >> (Please send email to edk2-devel@lists.01.org for help, attaching > >> following call stack trace!) > >> > >> (Python 3.5.3 on linux) Traceback (most recent call last): > >> File > >> "/work/git/edk2/BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py", > >> line 2387, in Main > >> MyBuild.Launch() > >> File > >> "/work/git/edk2/BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py", > >> line 2141, in Launch > >> self._MultiThreadBuildPlatform() > >> File > >> "/work/git/edk2/BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py", > >> line 1921, in _MultiThreadBuildPlatform > >> self.Progress > >> File "/work/git/edk2/BaseTools/Source/Python/AutoGen/AutoGen.py", line > >> 304, in __init__ > >> self._InitWorker(Workspace, MetaFile, Target, Toolchain, Arch, *args, > >> **kwargs) > >> File "/work/git/edk2/BaseTools/Source/Python/AutoGen/AutoGen.py", line > >> 477, in _InitWorker > >> for BuildData in PGen.BuildDatabase._CACHE_.values(): > >> RuntimeError: dictionary changed size during iteration > > > > I believe the culprit is f8d11e5a4aaa. > > With Python3 the dict.value() method returns an iterator. > Using list() to force a copy works for me. > > Since I'm not a Python expert (and less with joys of py2/py3 > conversion), I'll start sharing a snippet rather than a formal patch :) I can confirm this change *appears* to fix the problem with both python3.5 and python2.7. So from my end: Tested-by: Leif Lindholm Thanks! > > -- >8 -- > --- a/BaseTools/Source/Python/AutoGen/AutoGen.py > +++ b/BaseTools/Source/Python/AutoGen/AutoGen.py > @@ -475,5 +475,5 @@ class WorkspaceAutoGen(AutoGen): > # generate the SourcePcdDict and BinaryPcdDict > PGen = PlatformAutoGen(self, self.MetaFile, Target, > Toolchain, Arch) > -for BuildData in PGen.BuildDatabase._CACHE_.values(): > +for BuildData in list(PGen.BuildDatabase._CACHE_.values()): > if BuildData.Arch != Arch: > continue > --- > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2] AppPkg: fix webserver build for !Ia32/X64
Mike, Daryl, Jaben - any comments on v2? On Fri, Nov 02, 2018 at 10:50:15AM +, Leif Lindholm wrote: > The WebServer application is not meant to be Ia32/X64 specific, and would > build for other architectures, if it wasn't for the > #include > in WebServer.h. Move that statement to Mtrr.c instead, which is the only > consumer, and is already being filtered out for other architectures. > > Cc: Daryl McDaniel > Cc: Jaben Carsey > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Leif Lindholm > --- > > Resending only 1/6, since the others got R-b already. > Looking at PageList.c, the app was clearly intended to be portable, > so updated commit message to reflect this. > > AppPkg/Applications/Sockets/WebServer/WebServer.h | 1 - > AppPkg/Applications/Sockets/WebServer/Mtrr.c | 1 + > 2 files changed, 1 insertion(+), 1 deletion(-) > > diff --git a/AppPkg/Applications/Sockets/WebServer/WebServer.h > b/AppPkg/Applications/Sockets/WebServer/WebServer.h > index 21b07b63df..16c30c8d6d 100644 > --- a/AppPkg/Applications/Sockets/WebServer/WebServer.h > +++ b/AppPkg/Applications/Sockets/WebServer/WebServer.h > @@ -20,7 +20,6 @@ > > #include > > -#include > #include > #include > #include > diff --git a/AppPkg/Applications/Sockets/WebServer/Mtrr.c > b/AppPkg/Applications/Sockets/WebServer/Mtrr.c > index 54356bde64..4b8482d4e2 100644 > --- a/AppPkg/Applications/Sockets/WebServer/Mtrr.c > +++ b/AppPkg/Applications/Sockets/WebServer/Mtrr.c > @@ -15,6 +15,7 @@ > > #include > #include > +#include > > #define VARIABLE_MTRR_VALID 0x800 > > -- > 2.11.0 > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] BaseTools: build failure when specifying multiple BUILDTARGET
Hi Bob, Liming, With the latest BaseTools (current HEAD, 6c61ec4c62), building multiple targets from a single command line crashes. To reproduce: build -a IA32 -t GCC5 -b RELEASE -b NOOPT -p OvmfPkg/OvmfPkgIa32.dsc (I first built with -n32, but dropped that to see if it would make a difference - it does not.) The first target specified builds successfully. When starting on the second, the output is as below, and build exits. / Leif Architecture(s) = IA32 Build target = NOOPT Toolchain= GCC5 Active Platform = /work/git/edk2/OvmfPkg/OvmfPkgIa32.dsc Flash Image Definition = /work/git/edk2/OvmfPkg/OvmfPkgIa32.fdf Processing meta-data ... build.py... : error C0DE: Unknown fatal error when processing [/work/git/edk2/OvmfPkg/OvmfPkgIa32.dsc] (Please send email to edk2-devel@lists.01.org for help, attaching following call stack trace!) (Python 3.5.3 on linux) Traceback (most recent call last): File "/work/git/edk2/BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py", line 2387, in Main MyBuild.Launch() File "/work/git/edk2/BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py", line 2141, in Launch self._MultiThreadBuildPlatform() File "/work/git/edk2/BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py", line 1921, in _MultiThreadBuildPlatform self.Progress File "/work/git/edk2/BaseTools/Source/Python/AutoGen/AutoGen.py", line 304, in __init__ self._InitWorker(Workspace, MetaFile, Target, Toolchain, Arch, *args, **kwargs) File "/work/git/edk2/BaseTools/Source/Python/AutoGen/AutoGen.py", line 477, in _InitWorker for BuildData in PGen.BuildDatabase._CACHE_.values(): RuntimeError: dictionary changed size during iteration - Failed - ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v4 edk2-platforms 01/23] Silicon/Broadcom/Bcm282x: Add interrupt driver
Please assume that for now. If you're ready to resubmit and we change our mind, I'll do the rework. Regards, Leif On Fri, Feb 01, 2019 at 10:28:32AM +, Pete Batard wrote: > All, > > From the feedback below, I'm going to assert that the current consensus is > to keep Bcm2836.h in IndustryStandard/ and therefore, outside of adding an > additional description with regards to its purpose, I will keep this patch > as-is for v5. > > If this is not what we want, please let me know. > > Regards, > > /Pete > > On 2019.02.01 08:43, Laszlo Ersek wrote: > > On 01/31/19 22:01, Andrew Fish wrote: > > > > > > > > > > On Jan 31, 2019, at 11:57 AM, Leif Lindholm > > > > wrote: > > > > > > > > +Andrew, Laszlo, Mike. > > > > > > > > On Thu, Jan 31, 2019 at 06:19:48PM +0100, Ard Biesheuvel wrote: > > > > > On Thu, 31 Jan 2019 at 16:24, Leif Lindholm > > > > > wrote: > > > > > > > > > > > > On Tue, Jan 29, 2019 at 04:26:33PM +, Pete Batard wrote: > > > > > > > Contributed-under: TianoCore Contribution Agreement 1.1 > > > > > > > Signed-off-by: Pete Batard > > > > > > > > > > > > > > Reviewed-by: Ard Biesheuvel > > > > > > > --- > > > > > > > Silicon/Broadcom/Bcm283x/Bcm283x.dec | > > > > > > > 23 ++ > > > > > > > Silicon/Broadcom/Bcm283x/Drivers/InterruptDxe/InterruptDxe.c | > > > > > > > 367 > > > > > > > Silicon/Broadcom/Bcm283x/Drivers/InterruptDxe/InterruptDxe.inf | > > > > > > > 48 +++ > > > > > > > Silicon/Broadcom/Bcm283x/Include/IndustryStandard/Bcm2836.h| > > > > > > > 72 > > > > > > > > > > > > Another generic comment: "IndustryStandard" is something like ACPI, > > > > > > SMBIOS, PCI, USB, MMC, ... (also including SoC/platform-specific > > > > > > additions to the same). > > > > > > > > > > Is that your interpretation? Or is this documented somewhere? > > > > > > > > Only in asmuch as it is a clearly descriptive name. > > > > > > > > > I could live with Chipset/, and I'm open to other suggestions, but the > > > > > Library vs Protocol vs IndustryStandard distinction is very useful > > > > > imo. > > > > > > > > It is useful because it is descriptive. > > > > Pretending that an SoC hardware description or a platform description > > > > header is an "Industry Standard" is disingenuous. > > > > > > > > > > I would be more comfortable with SoC-specific and Platform-specific > > > > > > include files living directly in Include/. > > > > > > > > > > No, don't drop headers in Include/ please. The namespacing is one of > > > > > the things EDK2 actually gets right (assuming you define the paths > > > > > correctly in the package .dec file), and I'd hate to start dumping > > > > > headers at the root level because we cannot make up our minds what to > > > > > call the enclosing folder. > > > > > > > > Mike, Andrew - what is your take on this? > > > > Is there a formal definition of not only what goes in > > > > IndustryStandard, but where chipset and platform headers should live > > > > in the namespace? > > > > > > > > > > Leif, > > > > > > I kind of think IndustryStandard as things that have a public spec > > > > I think the same. I think any device / interface headers can go under > > Include/IndustryStandard as long as the interface was explicitly > > designed for external consumption, and is promised to be stable. > > > > I realize some packages have Include/Register too... I find that a bit > > redundant. > > > > Thanks > > Laszlo > > > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v4 edk2-platforms 01/23] Silicon/Broadcom/Bcm282x: Add interrupt driver
+Andrew, Laszlo, Mike. On Thu, Jan 31, 2019 at 06:19:48PM +0100, Ard Biesheuvel wrote: > On Thu, 31 Jan 2019 at 16:24, Leif Lindholm wrote: > > > > On Tue, Jan 29, 2019 at 04:26:33PM +, Pete Batard wrote: > > > Contributed-under: TianoCore Contribution Agreement 1.1 > > > Signed-off-by: Pete Batard > > > > > > Reviewed-by: Ard Biesheuvel > > > --- > > > Silicon/Broadcom/Bcm283x/Bcm283x.dec | 23 ++ > > > Silicon/Broadcom/Bcm283x/Drivers/InterruptDxe/InterruptDxe.c | 367 > > > > > > Silicon/Broadcom/Bcm283x/Drivers/InterruptDxe/InterruptDxe.inf | 48 +++ > > > Silicon/Broadcom/Bcm283x/Include/IndustryStandard/Bcm2836.h| 72 > > > > Another generic comment: "IndustryStandard" is something like ACPI, > > SMBIOS, PCI, USB, MMC, ... (also including SoC/platform-specific > > additions to the same). > > Is that your interpretation? Or is this documented somewhere? Only in asmuch as it is a clearly descriptive name. > I could live with Chipset/, and I'm open to other suggestions, but the > Library vs Protocol vs IndustryStandard distinction is very useful > imo. It is useful because it is descriptive. Pretending that an SoC hardware description or a platform description header is an "Industry Standard" is disingenuous. > > I would be more comfortable with SoC-specific and Platform-specific > > include files living directly in Include/. > > No, don't drop headers in Include/ please. The namespacing is one of > the things EDK2 actually gets right (assuming you define the paths > correctly in the package .dec file), and I'd hate to start dumping > headers at the root level because we cannot make up our minds what to > call the enclosing folder. Mike, Andrew - what is your take on this? Is there a formal definition of not only what goes in IndustryStandard, but where chipset and platform headers should live in the namespace? Regards, Leif > > > 4 files changed, 510 insertions(+) > > > > > > diff --git a/Silicon/Broadcom/Bcm283x/Bcm283x.dec > > > b/Silicon/Broadcom/Bcm283x/Bcm283x.dec > > > new file mode 100644 > > > index ..d193da4c0e1e > > > --- /dev/null > > > +++ b/Silicon/Broadcom/Bcm283x/Bcm283x.dec > > > @@ -0,0 +1,23 @@ > > > +## @file > > > +# > > > +# Copyright (c) 2019, Pete Batard > > > +# > > > +# 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] > > > + DEC_SPECIFICATION = 0x0001001A > > > + PACKAGE_NAME = Bcm283xPkg > > > + PACKAGE_GUID = 900C0F44-1152-4FF9-B9C5-933E2918C831 > > > + PACKAGE_VERSION= 1.0 > > > + > > > +[Includes] > > > + Include > > > diff --git a/Silicon/Broadcom/Bcm283x/Drivers/InterruptDxe/InterruptDxe.c > > > b/Silicon/Broadcom/Bcm283x/Drivers/InterruptDxe/InterruptDxe.c > > > new file mode 100644 > > > index ..9058aa94ffb9 > > > --- /dev/null > > > +++ b/Silicon/Broadcom/Bcm283x/Drivers/InterruptDxe/InterruptDxe.c > > > @@ -0,0 +1,367 @@ > > > +/** @file > > > + * > > > + * Copyright (c) 2016, Linaro, Ltd. 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 > > > + > > > +#include > > > +#include > > > +#include > > > +#include > >
Re: [edk2] [PATCH edk2-platforms] Silicon/Bcm2836: add random number generator driver
On Thu, Jan 31, 2019 at 06:14:45PM +0100, Ard Biesheuvel wrote: > On Thu, 31 Jan 2019 at 16:05, Leif Lindholm wrote: > > > > On Wed, Jan 30, 2019 at 08:39:43PM +0100, Ard Biesheuvel wrote: > > > Expose the SoC's RNG peripheral via the EFI_RNG_PROTOCOL. > > > This is used by Linux to seed the KASLR routines. > > > > > > Contributed-under: TianoCore Contribution Agreement 1.1 > > > Signed-off-by: Ard Biesheuvel > > > > Not tested, but looks fine. Only question: could we add those few > > #defines to IndustryStandard/Bcm2836.h (should that really be > > #IndustryStandard, btw?) rather than creating a tiny standalone one? > > (more below) > > > > Sure. > > Re IndustryStandard/, I deliberately chose something idiomatic for > EDK2, and this is the least inappropriate one. I could live with > Chipset/ as well, but dumping headers under Include/ directly is not > the solution IMO. I disagree. Dumping the main SoC header under the top-level SoC directory (and same pattern for platform) is idiomatic. Dumping all kinds of random files there isn't, I agree (although that happens too). BeagleBoardPkg/Include/BeagleBoard.h OvmfPkg/Include/OvmfPlatforms.h Vlv2TbltDevicePkg/Include/Platform.h Silicon/Hisilicon/Hi6220/Include/Hi6220.h An alternative pattern is an include directory named after the SoC/Platform. Omap35xxPkg/Include/Omap3530/ You used Silicon/Socionext/SynQuacer/Include/Platform/ which I also don't mind. If you'd prefer it, I'd be happy with Platform/ and Silicon/. But we'd better settle on something before Pete changes too much based on my feedback. / Leif > > > --- > > > Silicon/Broadcom/Bcm283x/Drivers/RngDxe/RngDxe.c | 204 > > > > > > Silicon/Broadcom/Bcm283x/Drivers/RngDxe/RngDxe.inf | 45 > > > + > > > Silicon/Broadcom/Bcm283x/Include/IndustryStandard/Bcm2836Rng.h | 26 +++ > > > 3 files changed, 275 insertions(+) > > > > > > > > diff --git > > > a/Silicon/Broadcom/Bcm283x/Include/IndustryStandard/Bcm2836Rng.h > > > b/Silicon/Broadcom/Bcm283x/Include/IndustryStandard/Bcm2836Rng.h > > > new file mode 100644 > > > index ..8274e2fe8f77 > > > --- /dev/null > > > +++ b/Silicon/Broadcom/Bcm283x/Include/IndustryStandard/Bcm2836Rng.h > > > @@ -0,0 +1,26 @@ > > > + /** @file > > > + * > > > + * Copyright (c) 2019 Linaro, Ltd. 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 __BCM2836_RNG_H__ > > > +#define __BCM2836_RNG_H__ > > > + > > > +#define RNG_BASE_ADDRESS (BCM2836_SOC_REGISTERS + 0x00104000) > > > > If we can't, this file needs to pull in Bcm2836.h anyway. > > > > Yep. ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] EmbeddedPkg/DwEmacSnpDxe: Add designware emac support This add support for designware emac controller
Hi Tzy Way, Thank you for this contribution. I do have some high-level comments. First of all, my best guess is that you have used Lan9118Dxe for reference when developing this driver. This is somewhat unfortunate. I am reminded that a) we badly need to migrate that driver (and Lan91xDxe) to edk2-platforms. b) we badly need to convert those drivers to UEFI driver model and NonDiscoverableDeviceRegistrationLib. Those two predate the NonDiscoverable implementation, so have been left as is, but any new drivers really need to implement proper driver model. Additionally, this driver should be submitted to edk2-platforms rather than edk2. Secondly, searching online for "designware emac" does not find unambigously the product this refers to. This is where it would be usful with a proper commit message and explain in a bit more detail what the driver is. On Thu, Jan 31, 2019 at 04:32:00PM +0800, tzy.way@intel.com wrote: > From: "Ooi, Tzy Way" > > Contributed-under: TianCore Contribution Agreement 1.1 > Signed-off-by: Ooi, Tzy Way > --- > .../Drivers/DwEmacSnpDxe/DwEmacSnpDxe.c | 1368 + > .../Drivers/DwEmacSnpDxe/DwEmacSnpDxe.h | 236 +++ > .../Drivers/DwEmacSnpDxe/DwEmacSnpDxe.inf | 69 + > .../Drivers/DwEmacSnpDxe/EmacDxeUtil.c| 676 > .../Drivers/DwEmacSnpDxe/EmacDxeUtil.h| 378 + > EmbeddedPkg/Drivers/DwEmacSnpDxe/PhyDxeUtil.c | 604 > EmbeddedPkg/Drivers/DwEmacSnpDxe/PhyDxeUtil.h | 324 > EmbeddedPkg/EmbeddedPkg.dec |4 + > EmbeddedPkg/EmbeddedPkg.dsc |1 + > 9 files changed, 3660 insertions(+) Thirdly, please generate patches as described in https://github.com/tianocore/tianocore.github.io/wiki/Laszlo%27s-unkempt-git-guide-for-edk2-contributors-and-maintainers#contrib-23 This greatly simplifies review. Best Regards, Leif ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v4 edk2-platforms 01/23] Silicon/Broadcom/Bcm282x: Add interrupt driver
On Tue, Jan 29, 2019 at 04:26:33PM +, Pete Batard wrote:
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Pete Batard
>
> Reviewed-by: Ard Biesheuvel
> ---
> Silicon/Broadcom/Bcm283x/Bcm283x.dec | 23 ++
> Silicon/Broadcom/Bcm283x/Drivers/InterruptDxe/InterruptDxe.c | 367
>
> Silicon/Broadcom/Bcm283x/Drivers/InterruptDxe/InterruptDxe.inf | 48 +++
> Silicon/Broadcom/Bcm283x/Include/IndustryStandard/Bcm2836.h| 72
Another generic comment: "IndustryStandard" is something like ACPI,
SMBIOS, PCI, USB, MMC, ... (also including SoC/platform-specific
additions to the same).
I would be more comfortable with SoC-specific and Platform-specific
include files living directly in Include/.
/
Leif
> 4 files changed, 510 insertions(+)
>
> diff --git a/Silicon/Broadcom/Bcm283x/Bcm283x.dec
> b/Silicon/Broadcom/Bcm283x/Bcm283x.dec
> new file mode 100644
> index ..d193da4c0e1e
> --- /dev/null
> +++ b/Silicon/Broadcom/Bcm283x/Bcm283x.dec
> @@ -0,0 +1,23 @@
> +## @file
> +#
> +# Copyright (c) 2019, Pete Batard
> +#
> +# 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]
> + DEC_SPECIFICATION = 0x0001001A
> + PACKAGE_NAME = Bcm283xPkg
> + PACKAGE_GUID = 900C0F44-1152-4FF9-B9C5-933E2918C831
> + PACKAGE_VERSION= 1.0
> +
> +[Includes]
> + Include
> diff --git a/Silicon/Broadcom/Bcm283x/Drivers/InterruptDxe/InterruptDxe.c
> b/Silicon/Broadcom/Bcm283x/Drivers/InterruptDxe/InterruptDxe.c
> new file mode 100644
> index ..9058aa94ffb9
> --- /dev/null
> +++ b/Silicon/Broadcom/Bcm283x/Drivers/InterruptDxe/InterruptDxe.c
> @@ -0,0 +1,367 @@
> +/** @file
> + *
> + * Copyright (c) 2016, Linaro, Ltd. 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
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +#include
> +#include
> +
> +//
> +// This currently only implements support for the architected timer
> interrupts
> +// on the per-CPU interrupt controllers.
> +//
> +#define NUM_IRQS(4)
> +
> +#ifdef MDE_CPU_AARCH64
> +#define ARM_ARCH_EXCEPTION_IRQ EXCEPT_AARCH64_IRQ
> +#else
> +#define ARM_ARCH_EXCEPTION_IRQ EXCEPT_ARM_IRQ
> +#endif
> +
> +STATIC CONST
> +EFI_PHYSICAL_ADDRESS RegBase = FixedPcdGet32 (PcdInterruptBaseAddress);
> +
> +//
> +// Notifications
> +//
> +STATIC EFI_EVENTmExitBootServicesEvent;
> +STATIC HARDWARE_INTERRUPT_HANDLER mRegisteredInterruptHandlers[NUM_IRQS];
> +
> +/**
> + Shutdown our hardware
> +
> + DXE Core will disable interrupts and turn off the timer and disable
> interrupts
> + after all the event handlers have run.
> +
> + @param[in] Event The Event that is being processed
> + @param[in] Context Event Context
> +**/
> +STATIC
> +VOID
> +EFIAPI
> +ExitBootServicesEvent (
> + IN EFI_EVENT Event,
> + IN VOID *Context
> + )
> +{
> + // Disable all interrupts
> + MmioWrite32 (RegBase + BCM2836_INTC_TIMER_CONTROL_OFFSET, 0);
> +}
> +
> +/**
> + Enable interrupt source Source.
> +
> + @param This Instance pointer for this protocol
> + @param Source Hardware source of the interrupt
> +
> + @retval EFI_SUCCESS Source interrupt enabled.
> + @retval EFI_DEVICE_ERROR Hardware could not be programmed.
> +
> +**/
> +STATIC
> +EFI_STATUS
> +EFIAPI
> +EnableInterruptSource (
> + IN EFI_HARDWARE_INTERRUPT_PROTOCOL*This,
> + IN HARDWARE_INTERRUPT_SOURCE Source
> + )
> +{
> + if (Source >= NUM_IRQS) {
> +ASSERT (FALSE);
> +return EFI_UNSUPPORTED;
> + }
> +
> + MmioOr32 (RegBase + BCM2836_INTC_TIMER_CONTROL_OFFSET, 1 << Source);
> +
> + return EFI_SUCCESS;
> +}
> +
> +
> +/**
> + Disable interrupt source Source.
> +
> + @param This Instance pointer for this protocol
> + @param Source Hardware source of the interrupt
> +
> + @retval EFI_SUCCESS Source interrupt disabled.
> + @retval EFI_DEVICE_ERROR Hardware could not be programmed.
> +
> +**/
> +STATIC
> +EFI_STATUS
> +EFIAPI
Re: [edk2] [PATCH edk2-platforms] Silicon/Bcm2836: add random number generator driver
On Wed, Jan 30, 2019 at 08:39:43PM +0100, Ard Biesheuvel wrote: > Expose the SoC's RNG peripheral via the EFI_RNG_PROTOCOL. > This is used by Linux to seed the KASLR routines. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ard Biesheuvel Not tested, but looks fine. Only question: could we add those few #defines to IndustryStandard/Bcm2836.h (should that really be #IndustryStandard, btw?) rather than creating a tiny standalone one? (more below) > --- > Silicon/Broadcom/Bcm283x/Drivers/RngDxe/RngDxe.c | 204 > > Silicon/Broadcom/Bcm283x/Drivers/RngDxe/RngDxe.inf | 45 + > Silicon/Broadcom/Bcm283x/Include/IndustryStandard/Bcm2836Rng.h | 26 +++ > 3 files changed, 275 insertions(+) > > diff --git a/Silicon/Broadcom/Bcm283x/Include/IndustryStandard/Bcm2836Rng.h > b/Silicon/Broadcom/Bcm283x/Include/IndustryStandard/Bcm2836Rng.h > new file mode 100644 > index ..8274e2fe8f77 > --- /dev/null > +++ b/Silicon/Broadcom/Bcm283x/Include/IndustryStandard/Bcm2836Rng.h > @@ -0,0 +1,26 @@ > + /** @file > + * > + * Copyright (c) 2019 Linaro, Ltd. 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 __BCM2836_RNG_H__ > +#define __BCM2836_RNG_H__ > + > +#define RNG_BASE_ADDRESS (BCM2836_SOC_REGISTERS + 0x00104000) If we can't, this file needs to pull in Bcm2836.h anyway. / Leif > + > +#define RNG_CTRL (RNG_BASE_ADDRESS + 0x0) > +#define RNG_STATUS (RNG_BASE_ADDRESS + 0x4) > +#define RNG_DATA (RNG_BASE_ADDRESS + 0x8) > + > +#define RNG_CTRL_ENABLE0x1 > + > +#endif /* __BCM2836_RNG_H__ */ > -- > 2.20.1 > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v4 edk2-platforms 20/23] Platform/Raspberry/Pi3: Add platform readme
On Thu, Jan 31, 2019 at 12:30:22PM +, Pete Batard wrote: > Hi Leif. Thanks for reviewing this patchset. > > On 2019.01.30 21:50, Leif Lindholm wrote: > > Hi Pete, > > > > I will only have minor comments on this set, but I'll start with this > > documentation. > > > > On Tue, Jan 29, 2019 at 04:26:52PM +, Pete Batard wrote: > > > Contributed-under: TianoCore Contribution Agreement 1.1 > > > Signed-off-by: Pete Batard > > > --- > > > Platform/Raspberry/Pi3/Readme.md | 259 > > > Readme.md| 3 + > > > 2 files changed, 262 insertions(+) > > > > > > diff --git a/Platform/Raspberry/Pi3/Readme.md > > > b/Platform/Raspberry/Pi3/Readme.md > > > new file mode 100644 > > > index ..7fb59ccdc321 > > > --- /dev/null > > > +++ b/Platform/Raspberry/Pi3/Readme.md > > > @@ -0,0 +1,259 @@ > > > +Raspberry Pi 3 EDK2 Platform Support > > > + > > > + > > > +# Summary > > > + > > > +This is a port of 64-bit Tiano Core UEFI firmware for the Raspberry Pi > > > 3/3B+ platforms, > > > +based on [Ard Bisheuvel's > > > 64-bit](http://www.workofard.com/2017/02/uefi-on-the-pi/) > > > +and [Microsoft's > > > 32-bit](https://github.com/ms-iot/RPi-UEFI/tree/ms-iot/Pi3BoardPkg) > > > +implementations, as maintained by [Andrei > > > Warkentin](https://github.com/andreiw/RaspberryPiPkg). > > > + > > > +This is meant as a generally useful 64-bit ATF + UEFI implementation for > > > the Raspberry > > > +Pi 3/3B+ which should be good enough for most kind of UEFI development, > > > as well as for > > > +running consummer Operating Systems in such as Linux or Windows. > > > + > > > +Raspberry Pi is a trademark of the [Raspberry Pi > > > Foundation](http://www.raspberrypi.org). > > > + > > > +# Status > > > + > > > +This firmware, that has been validated to compile against the current > > > +[edk2](https://github.com/tianocore/edk2)/[edk2-platforms](https://github.com/tianocore/edk2-platforms), > > > +should be able to boot Linux (SUSE, Ubuntu), NetBSD, FreeBSD as well as > > > Windows 10 ARM64 > > > +(full GUI version). > > > + > > > +It also provides support for ATF ([Arm Trusted > > > Platform](https://github.com/ARM-software/arm-trusted-firmware)). > > > + > > > +HDMI and the mini-UART serial port can be used for output devices, with > > > mirrored output. > > > +USB keyboards and the mini-UART serial port can be used as input. > > > + > > > +The boot order is currently hardcoded, first to the USB ports and then > > > to the uSD card. > > > +If there no bootable media media is found, the UEFI Shell is launched. > > > +Esc enters platform setup. F1 boots the UEFI Shell. > > > + > > > +# Building > > > + > > > +(These instructions were validated against the latest edk2 / > > > edk2-platforms / > > > +edk2-non-osi as of 2019.01.27, on a Debian 9.6 x64 system). > > > + > > > +You may need to install the relevant compilation tools. Especially you > > > should have the > > > +ACPI Source Language (ASL) compiler, `nasm` as well as a native compiler > > > installed. > > > > nasm? The x86 assembler? > > I'll remove that. > > > > +On a Debian system, you can get these prerequisites installed with: > > > +``` > > > +sudo apt-get install build-essential acpica-tools nasm uuid-dev > > > +``` > > > + > > > +**IMPORTANT:** We recommend the use of the Linaro GCC for compilation > > > instead of > > > +your system's native ARM64 GCC cross compiler. > > > > This sounds like something written in the days of GCC 4.8. I doubt it > > has any relevance today. > > It very much had until circa one month ago, as we observed early Synchronous > Exceptions when trying to use the native Debian ARM64 compiler, which we did > not observe with Linaro's toolchain. We even had trouble (similar issue) > with recent Linaro toolchains at some stage, which is why, until v3, we > recommended an older version, but recent tests showed that the latest Linaro > GCC (2019.02) appeared to be okay, which is why I removed the previous > requirement to use exclusively Linaro's 2017.10 GCC 5.5. Urgh. But that actually makes the above statement even more misleading. What you have isn't an
Re: [edk2] [platforms: PATCH v3 0/5] Armada7k8k memory handling update
On Thu, Jan 31, 2019 at 01:06:15PM +0100, Marcin Wojtas wrote: > czw., 31 sty 2019 o 11:28 Leif Lindholm napisał(a): > > > > On Thu, Jan 31, 2019 at 08:01:08AM +0100, Marcin Wojtas wrote: > > > Hi Leif, > > > > > > Thanks a lot. While at it - do you think ArmPkg/Include/Library/ArmLib.h > > > / ArmPkg/Library/ArmLib/ArmLib.c would be a proper place for it? > > > > As good a place as any. While not ARM-architecture specific, I feel > > it's probably ARM-platform specific. > > > > I mean, hopefully we'll some day we'll get a sane reporting mechanism > > of Secure-reserved regions by ARM-TF and we can drop this juggling in > > Non-secure firmware. > > Agree on ARM-TF dependency, but the code is IMO pretty generic itself. > In the merged version I also used this routine to cut out a hole in > the HoB for the reason not related to NS region - therefore I think > even MdePkg/Library would be good to go :) I don't really disagree with you, but that would be something to take up with MdeModulePkg maintainers. Also, I'm not seeing an obvious existing library to put it into. Would it really be worth creating a new one for just this function? / Leif > Marcin > > > > Best regards, > > > Marcin > > > > > > śr., 30 sty 2019 o 17:47 Leif Lindholm > > > napisał(a): > > > > > > > Thanks for the rework. > > > > > > > > (We should probably move that broken-out function to ArmPkg at some > > > > point.) > > > > > > > > For the series: > > > > Reviewed-by: Leif Lindholm > > > > > > > > Pushed as b0bb325f20..0a7d8e7d93. > > > > > > > > On Mon, Jan 28, 2019 at 10:45:10AM +0100, Marcin Wojtas wrote: > > > > > Hi, > > > > > > > > > > The third version of the patchset moves the new common > > > > > header for Marvell SMC ID's to the IndustryStandard directory. > > > > > What is more important, now 3 regions (described by new PCDs) > > > > > are reserved separately. For that purpose a preparation > > > > > patch was added, which extract existing reservation code > > > > > into a new subroutine. More details can be found in > > > > > the changelog below and the commit messages. > > > > > > > > > > Patches are available in the github: > > > > > > > > > https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/commits/dram-upstream-r20190128 > > > > > > > > > > I'm looking forward to the comments and remarks. > > > > > > > > > > Best regards, > > > > > Marcin > > > > > > > > > > Changelog: > > > > > v2 -> v3 > > > > > * 1/5 > > > > > - New patch - extract memory reservation to a separate routine > > > > > > > > > > * 2/2 > > > > > - Add new PCDs and reserve 3 regions (ARM-TF, PEI stack, OP-TEE) > > > > > separately > > > > > - Update commit message accordingly > > > > > > > > > > * 3/5 > > > > > - Move MvSmc.h to Include/IndustryStandard > > > > > > > > > > * 4,5/5 > > > > > - Add Leif's RB > > > > > > > > > > v1 -> v2: > > > > > * 1/4 > > > > > - Improve commit log - mention single area size and new PEI stack > > > > > base > > > > > > > > > > * 2/4 (new patch) > > > > > - Add common header for Marvell SMC ID's > > > > > > > > > > * 3/4 > > > > > - Add function description comment > > > > > - Define and use ARMADA7K8K_AP806_INDEX > > > > > - Change function argument to EFI_PHYSICAL_ADDRESS > > > > > > > > > > * 4/4 > > > > > - Move new SMC ID to MvSmc.h > > > > > - Include ArmadaSoCDescLib.h directly (instead indirectly via > > > > BoardDesc.h) > > > > > - Remove ARMADA7K8K_AP806_INDEX macro > > > > > > > > > > Grzegorz Jaszczyk (2): > > > > > Marvell/Library: ArmadaSoCDescLib: Add North Bridge description > > > > > Marvell/Armada7k8k: Read DRAM settings from ARM-TF > > > > > > > > > > Marcin Wojtas (3): > > > > > Marvell/Armada7k8k: Refactor reserving memory regions > > > >
Re: [edk2] [platforms: PATCH v3 0/5] Armada7k8k memory handling update
On Thu, Jan 31, 2019 at 08:01:08AM +0100, Marcin Wojtas wrote: > Hi Leif, > > Thanks a lot. While at it - do you think ArmPkg/Include/Library/ArmLib.h > / ArmPkg/Library/ArmLib/ArmLib.c would be a proper place for it? As good a place as any. While not ARM-architecture specific, I feel it's probably ARM-platform specific. I mean, hopefully we'll some day we'll get a sane reporting mechanism of Secure-reserved regions by ARM-TF and we can drop this juggling in Non-secure firmware. Best Regards, Leif > Best regards, > Marcin > > śr., 30 sty 2019 o 17:47 Leif Lindholm > napisał(a): > > > Thanks for the rework. > > > > (We should probably move that broken-out function to ArmPkg at some point.) > > > > For the series: > > Reviewed-by: Leif Lindholm > > > > Pushed as b0bb325f20..0a7d8e7d93. > > > > On Mon, Jan 28, 2019 at 10:45:10AM +0100, Marcin Wojtas wrote: > > > Hi, > > > > > > The third version of the patchset moves the new common > > > header for Marvell SMC ID's to the IndustryStandard directory. > > > What is more important, now 3 regions (described by new PCDs) > > > are reserved separately. For that purpose a preparation > > > patch was added, which extract existing reservation code > > > into a new subroutine. More details can be found in > > > the changelog below and the commit messages. > > > > > > Patches are available in the github: > > > > > https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/commits/dram-upstream-r20190128 > > > > > > I'm looking forward to the comments and remarks. > > > > > > Best regards, > > > Marcin > > > > > > Changelog: > > > v2 -> v3 > > > * 1/5 > > > - New patch - extract memory reservation to a separate routine > > > > > > * 2/2 > > > - Add new PCDs and reserve 3 regions (ARM-TF, PEI stack, OP-TEE) > > > separately > > > - Update commit message accordingly > > > > > > * 3/5 > > > - Move MvSmc.h to Include/IndustryStandard > > > > > > * 4,5/5 > > > - Add Leif's RB > > > > > > v1 -> v2: > > > * 1/4 > > > - Improve commit log - mention single area size and new PEI stack base > > > > > > * 2/4 (new patch) > > > - Add common header for Marvell SMC ID's > > > > > > * 3/4 > > > - Add function description comment > > > - Define and use ARMADA7K8K_AP806_INDEX > > > - Change function argument to EFI_PHYSICAL_ADDRESS > > > > > > * 4/4 > > > - Move new SMC ID to MvSmc.h > > > - Include ArmadaSoCDescLib.h directly (instead indirectly via > > BoardDesc.h) > > > - Remove ARMADA7K8K_AP806_INDEX macro > > > > > > Grzegorz Jaszczyk (2): > > > Marvell/Library: ArmadaSoCDescLib: Add North Bridge description > > > Marvell/Armada7k8k: Read DRAM settings from ARM-TF > > > > > > Marcin Wojtas (3): > > > Marvell/Armada7k8k: Refactor reserving memory regions > > > Marvell/Armada7k8k: Shift PEI stack base and extend memory reservation > > > Marvell/Library: Introduce common header for the SMC ID's > > > > > > Silicon/Marvell/Marvell.dec > > | 8 +- > > > Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc > > | 16 ++- > > > Silicon/Marvell/Armada7k8k/Library/Armada7k8kLib/Armada7k8kLib.inf > > | 3 + > > > > > Silicon/Marvell/Armada7k8k/Library/Armada7k8kMemoryInitPeiLib/Armada7k8kMemoryInitPeiLib.inf > > | 8 +- > > > Silicon/Marvell/Armada7k8k/Library/Armada7k8kLib/Armada7k8kLibMem.h > > | 25 - > > > > > Silicon/Marvell/Armada7k8k/Library/Armada7k8kSoCDescLib/Armada7k8kSoCDescLib.h > > | 6 ++ > > > Silicon/Marvell/Include/IndustryStandard/MvSmc.h > > | 24 + > > > Silicon/Marvell/Include/Library/ArmadaSoCDescLib.h > > | 28 + > > > Silicon/Marvell/Library/ComPhyLib/ComPhySipSvc.h > > | 8 +- > > > Silicon/Marvell/Armada7k8k/Library/Armada7k8kLib/Armada7k8kLibMem.c > > | 60 --- > > > > > Silicon/Marvell/Armada7k8k/Library/Armada7k8kMemoryInitPeiLib/Armada7k8kMemoryInitPeiLib.c > > | 107 +--- > > > > > Silicon/Marvell/Armada7k8k/Library/Armada7k8kSoCDescLib/Armada7k8kSoCDescLib.c > > | 34 +++ > > > Silicon/Marvell/Library/ComPhyLib/ComPhyCp110.c > > | 14 +-- > > > 13 files changed, 220 insertions(+), 121 deletions(-) > > > create mode 100644 Silicon/Marvell/Include/IndustryStandard/MvSmc.h > > > > > > -- > > > 2.7.4 > > > > > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v4 edk2-platforms 00/23] Platform/Raspberry: Add Raspberry Pi 3 support
On Wed, Jan 30, 2019 at 09:59:34PM +, Leif Lindholm wrote: > Hi Pete, > > I have two annoying pieces of feedback that apply to the whole set. > > Firstly, I would really appreciate if we could have some sort of > commit messages rather than just subject lines. > So, for ACPI, mention the provenance and limitations. > For SMBIOS, version supported and any relevant omissions or surprising > inclusions. And so on. > > Secondly, we try to follow a //... pattern. > Could you possibly find it in your heart to do a global move and > search-and-replace of Platform/Raspberry to Platform/RaspberryPi? Err, Ard has pointed out to me that I may want to be more explicit here. My request is to rename Platform/Raspberry to Platform/RaspberryPi, such that we end up with Platform/RaspberryPi/Pi3/RPi3.dsc. It would also look more consistent to me if we renamed the subdirectory RPi3 instead of Pi3, but I don't actually _care_ :) Best Regards, Leif > > Best Regards, > > Leif > > On Tue, Jan 29, 2019 at 04:26:32PM +, Pete Batard wrote: > > Changes applied to v4: > > > > * Silicon/Broadcom/Include has been moved to > > Silicon/Broadcom/Bcm283x/Include. > > The [Packages] and [Includes] directives were also updated accordingly. > > * Move the GpioLib function declarations into their own separate header. > > * Add NOOPT to BUILD_TARGETS. > > * Remove the no longer needed '-mcmodel=small' workaround from AcpiTables. > > > > Changes not applied to v4: > > > > * Ensure that all the ACPI tables _CID names, and the rest of the tables, > > are > > ACPI specs compliant, since we are constrained with regards to their usage > > for Microsoft Windows. > > > > > > Preamble: > > > > Because of its price point, ease of use and availability, the Raspberry Pi > > is > > undeniably one of the most successful ARM platform in existence today. Its > > widespread adoption therefore makes it a perfect fit as an EDK2 platform. > > > > However, up until now, the Raspberry Pi hasn't been supported as a bona fide > > platform in our repository. This series of patches remedies that by > > introducing > > the Raspberry Pi 3 Model B and Model B+ as a viable EDK2 platform. > > > > Notes regarding non-OSI content: > > > > * Even though the ARM Trusted Firmware binary blobs are subject to a > > BSD-3-Clause licence, which may be compatible with the EDK2 one, we chose > > to follow the lead of other platforms that provide ATF binaries in non > > OSI. > > Ultimately, once there is a new dot release of ATF, we plan to remove > > these > > binaries and point to a dot release build configuartion. > > * The Device Tree binaries (and source descriptors) are subject to a GPLv2 > > license, as per the ones published by the Raspberry Pi Foundation. > > * The Logo source code is under an EDK2 license, but the logo itself, which > > we obtained authorisation to use from the Raspberry Pi Foundation itself > > after detailing our planned usage, is subject to the trademark licensing > > terms put forward by the Foundation. > > > > Additional Notes: > > > > * Detailed instructions on how to build and test the platform firmware are > > included in the Readme.md found at the root of the platform. > > * As detailed in the Readme, the resulting platform firmware has been > > successfully used to install and run Linux OSes, such as Ubuntu 18.10, as > > well as Windows 10 1809 (*full* UI version, not IoT). > > > > Regards, > > > > /Pete > > > > Pete Batard (23): > > Silicon/Broadcom/Bcm282x: Add interrupt driver > > Silicon/Broadcom/Bcm283x: Add GpioLib > > Platform/Raspberry/Pi3: Add ACPI tables > > Platform/Raspberry/Pi3: Add reset and memory init libraries > > Platform/Raspberry/Pi3: Add platform library > > Platform/Raspberry/Pi3: Add RTC library > > Platform/Raspberry/Pi3: Add firmware driver > > Platform/Raspberry/Pi3: Add platform config driver > > Platform/Raspberry/Pi3: Add SMBIOS driver > > Platform/Raspberry/Pi3: Add display driver > > Platform/Raspberry/Pi3: Add console driver > > Platform/Raspberry/Pi3: Add NV storage driver > > Platform/Raspberry/Pi3: Add Device Tree driver > > Platform/Raspberry/Pi3: Add base MMC driver > > Platform/Raspberry/Pi3: Add Arasan MMC driver > > Platform/Raspberry/Pi3: Platform/Raspberry/Pi3: Add SD Host driver > > Platform/Raspberry/Pi3: Add platform boot manager and helper libraries > > Platform/Raspberry/Pi3: Add USB host driver &g
