Re: [edk2] Mixed (unix/windows) line endings in EDK2
On Wed, 2015-08-05 at 01:27 -0500, Scott Duplichan wrote: How can we make these files use consistent line endings? Would a patch work? Git can handle this, and automatically check out the appropriate type of line endings according to the system you're working on. Perhaps we should use that facility when we finally make the switch? -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation smime.p7s Description: S/MIME cryptographic signature ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 0/9] OvmfPkg, ArmVirtPkg: SMBIOS 3.0, round 2
On 08/04/15 21:50, Wei Huang wrote: I tested this version of binary with QEMU that supports SMBIOS 3.0. The guest VM is a 64-bit RHEL Server for ARM. Everything worked out of box. With it: Tested-by: Wei Huang w...@redhat.com Thanks a lot, Wei! Jordan -- can you please (1) skim the OVMF patches (they are easy and the idea in them was suggested by you (and I thank you for that)), (2) add Wei to the poster-without-subscription whitelist, in case that option is available in the mailing list software? Thank you Laszlo Thanks, -Wei On 7/31/15 13:40, Laszlo Ersek wrote: The SMBIOS 3.x entry point is structurally different from the 2.x variant, therefore the current code used by OvmfPkg and ArmVirtPkg doesn't recognize an SMBIOS 3.0 entry point structure even if QEMU exports one. This series rectifies that. The first four patches implement Jordan's great idea: they refactor the code without any observable changes, unifying the currently duplicated QEMU SMBIOS entry point checks / version setting between OvmfPkg and ArmVirtPkg. Patches 5 to 7, inclusive, eliminate yet another instance of the entry point checks, this time the last one, from SmbiosPlatformDxe. Building on the centralized QEMU SMBIOS entry point examination, patches 8 and 9 add SMBIOS 3.0 support for real. The series builds at every stage. I regression-tested it with OVMF (2.8 entry point), and tested the 3.0 entry point support using Wei's QEMU series pending at http://thread.gmane.org/gmane.comp.emulators.qemu/353282, with a small QEMU fix on top (which I posted in that thread). As I wrote in that thread as well, I didn't test with dmidecode in an aarch64 Linux guest just yet; I used the smbiosview UEFI shell command in the guest. Public branch: https://github.com/lersek/edk2/commits/smbios30_round2. Wei, you can find a binary at http://people.redhat.com/~lersek/smbios30_round2_v1/QEMU_EFI.fd.xz, for testing any further QEMU changes. Cc: Ard Biesheuvel ard.biesheu...@linaro.org Cc: Wei Huang w...@redhat.com Cc: Jordan Justen jordan.l.jus...@intel.com Cc: Gabriel L. Somlo so...@cmu.edu Thanks Laszlo Laszlo Ersek (9): OvmfPkg: SmbiosVersionLib: add plugin for detecting SMBIOS version OvmfPkg: set SMBIOS version in DetectSmbiosVersionLib instead of PlatformPei ArmVirtPkg: set SMBIOS version in DetectSmbiosVersionLib instead of QemuFwCfgToPcdDxe ArmVirtPkg: revert ArmVirtPkg: add QemuFwCfgToPcdDxe OvmfPkg: introduce PcdQemuSmbiosValidated ArmVirtPkg/ArmVirtQemu.dsc: set default for PcdQemuSmbiosValidated OvmfPkg: SmbiosPlatformDxe: eliminate duplicate entry point validation ArmVirtPkg: set default for PcdSmbiosDocRev OvmfPkg: SmbiosVersionLib: recognize SMBIOS 3.x entry point ArmVirtPkg/ArmVirtQemu.dsc | 8 +- ArmVirtPkg/ArmVirtQemu.fdf | 2 - ArmVirtPkg/QemuFwCfgToPcdDxe/QemuFwCfgToPcd.c | 73 - ArmVirtPkg/QemuFwCfgToPcdDxe/QemuFwCfgToPcd.inf | 46 - OvmfPkg/Library/SmbiosVersionLib/DetectSmbiosVersionLib.c | 107 OvmfPkg/Library/SmbiosVersionLib/DetectSmbiosVersionLib.inf | 53 ++ OvmfPkg/OvmfPkg.dec | 1 + OvmfPkg/OvmfPkgIa32.dsc | 7 +- OvmfPkg/OvmfPkgIa32X64.dsc | 7 +- OvmfPkg/OvmfPkgX64.dsc | 7 +- OvmfPkg/PlatformPei/Platform.c | 39 --- OvmfPkg/PlatformPei/PlatformPei.inf | 2 - OvmfPkg/SmbiosPlatformDxe/Qemu.c| 30 ++ OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.inf | 4 + 14 files changed, 198 insertions(+), 188 deletions(-) create mode 100644 OvmfPkg/Library/SmbiosVersionLib/DetectSmbiosVersionLib.c create mode 100644 OvmfPkg/Library/SmbiosVersionLib/DetectSmbiosVersionLib.inf delete mode 100644 ArmVirtPkg/QemuFwCfgToPcdDxe/QemuFwCfgToPcd.c delete mode 100644 ArmVirtPkg/QemuFwCfgToPcdDxe/QemuFwCfgToPcd.inf ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Building on Windows
On Wed, 2015-08-05 at 09:43 -0500, Scott Duplichan wrote: Here is how you can build Ovmf on Windows (tested with Win7 x64): 1) Get edk2, including BaseTools\Bin\Win32. You are right, git doesn't work for getting the external BaseTools\Bin\Win32. 2) Install Visual Studio 2008. EDK2 supports only a C: drive installation. EDK2 doesn't fully support installing multiple versions of Visual Studio. OK. 3) Open a plain Windows command prompt (cmd.exe). 4) Tell EDK2 where nasm is: C:\tmp\edk2 set NASM_PREFIX=D:\edk2build\uefiTools\nasm211\ And where *is* nasm? I installed the Bin\Win32 tools as directed, but it doesn't seem to be there. So I downloaded a version and installed it, such that %NASM_PREFIX%nasm.exe works. I also installed IASL for good measure, although that wasn't mentioned in the documentation I was looking at either. 5) Run Edk2Setup.bat: d:\tmp\edk2 Edk2Setup.bat Rebuilding of the tools is not required. Binaries of the latest, tested versions of the tools have been tested and included in the EDK II repository. If you really want to build the tools, use the --rebuild option. !!! WARNING !!! No CYGWIN_HOME set, gcc build may not be used !!! # WORKSPACE= d:\tmp\edk2 EDK_TOOLS_PATH = d:\tmp\edk2\BaseTools BASE_TOOLS_PATH = d:\tmp\edk2\BaseTools ## PATH # d:\tmp\edk2\BaseTools\Bin\Win32 C:\Windows\system32 C:\Windows C:\Windows\System32\Wbem d:\util d:\tmp\edk2 OK. 6) Add your openssl-1.0.2d files before building. 7) Build using one of these command lines: build.exe -p OvmfPkg\OvmfPkgX64.dsc -b DEBUG -t VS2008x86 -n 16 -a X64 -DSECURE_BOOT_ENABLE -DFD_SIZE_2MB build.exe -p OvmfPkg\OvmfPkgIA32.dsc -b DEBUG -t VS2008x86 -n 16 -a IA32 -DSECURE_BOOT_ENABLE -DFD_SIZE_2MB build.exe -p OvmfPkg\OvmfPkgIA32X64.dsc -b DEBUG -t VS2008x86 -n 16 -a IA32 -a X64 -DSECURE_BOOT_ENABLE -DFD_SIZE_2MB These instructions are for a 64-bit Windows version. For 32-bit, replace VS2008x86 with VS2008. Aha, that was it. I was using VS2008 so was looking in Program Files not Program Files (x86). Thanks. Oh Windows, how I hate thee. But at least I'd mostly solved the issues by building on a sane system with MinGw64, and I only need to *test* under Windows/MSVC. Actually having to do any real work in the Windows environment might have blown my tiny little mind. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] MdeModulePkg DxeIpl: Add stack NX support
On 07/31/15 14:22, Star Zeng wrote: This feature is added for UEFI spec that says Stack may be marked as non-executable in identity mapped page tables. A PCD PcdSetNxForStack is added to turn on/off this feature, and it is FALSE by default. Cc: Jiewen Yao jiewen@intel.com Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng star.z...@intel.com --- MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf | 3 +- MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c | 185 ++- MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c | 10 +- MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c | 160 +--- MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.h | 61 +++- MdeModulePkg/MdeModulePkg.dec| 11 +- MdeModulePkg/MdeModulePkg.uni| Bin 166792 - 168862 bytes 7 files changed, 392 insertions(+), 38 deletions(-) I tried to enable this feature in the OvmfPkg builds (all three of them). Unfortunately, I have found that a non-executable DXE stack breaks the EFI_MP_SERVICE_PROTOCOL.StartupAllAPs() function. (Which is provided by UefiCpuPkg/CpuDxe/CpuMp.c.) The virtual machine is re-set when that function is called. I presume the starup code for the APs resides in an area that happens to be marked non-executable (if this feature enabled), and that causes a fatal fault or some such when the APs get the startup IPI. Thanks Laszlo ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] BaseTools features: multiple workspaces
On Aug 5, 2015, at 8:38 AM, Kinney, Michael D michael.d.kin...@intel.com
wrote:
Andrew,
I would recommend a DSC define setting have precedence over the
WORKSPACE_MULTIPLE environment variable. This way, a single development
environment can support many platform DSC files. Most of the DSC files can
choose to let the WORKSPACE_MULTIPLE environment variable select the dirs,
and only platform DSC files that need dirs different than WORKSPACE_MULTIPLE
environment variable should set the DSC file define.
I would also recommend that the priority of the paths be the same for both
the WORKSPACE_MULTIPLE environment variable and a DSC define.
Mike,
Well in reality the priority is not the same as 1st match wins (well we need to
define how that works too). So an “override” is possible if a module is in
multiple paths.
So the question is if the DSC entry exists:
1) It overrides WORKSPACE_MULTIPLE - prevents side effects from env breaking
build.
2) It appends to $WORKSPACE_MULTIPLE, so env overrides DSC
3) it pre-pends to $WORKSPACE_MULTIPLE, so DSC overrides env.
Thanks,
Andrew Fish
One interesting issue is the selection of a path separator in the DSC file
define syntax.
Best regards,
Mike
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Andrew
Fish
Sent: Wednesday, August 05, 2015 8:28 AM
To: Gao, Liming
Cc: Justen, Jordan L; edk2-devel@lists.01.org; Laszlo Ersek; Paolo Bonzini
Subject: Re: [edk2] BaseTools features: multiple workspaces
On Aug 5, 2015, at 7:06 AM, Gao, Liming liming@intel.com wrote:
Thanks for your all comments.
Most people prefers to keep WOSKAPCE as single directory, and introduce new
env $(WORKSPACE_MULTIPLE). I think Mike solution can make them more clear if
WORKSPACE_MULTIPLE is set.
On QA team impact, it should be small. QA team can still use the current
working model to place all packages in root directory, and set WORKSPACE
only. QA team just needs to know the package list.
Tim gave another idea to define multiple source locations in Platform DSC
file. It doesn't conflict with this proposal. We can implement
$(WORKSPACE_MULTIPLE) feature first, and evaluate DSC update. On the fixed
tree layout, these two solutions can work. Once the end user reorganizes its
tree layout, he needs to set $(WORKSPACE_MULTIPLE) env or update Platform
DSC file, and build platform DSC.
We should probably decided up front which has precedence the env variable or
the DSC entry.
It might not hurt to think about the DSC case when implementing the env case,
as some arbitrary choices in the env path may make the DSC path harder.
Thanks,
Andrew Fish
Thanks
Liming
-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com]
Sent: Tuesday, August 04, 2015 7:20 PM
To: Justen, Jordan L
Cc: Gao, Liming; Paolo Bonzini; edk2-devel@lists.01.org
Subject: Re: [edk2] BaseTools features: multiple workspaces
On 08/03/15 19:35, Jordan Justen wrote:
On 2015-08-03 02:08:14, Gao, Liming wrote:
Paolo:
I think that keep the exiting syntax for WORKSPACE to be a single
path can minimize the impacts to exiting tools that assume a
single workspace.
I know you originally suggested to use WORKSPACE, but got some
feedback that it might be better to create a new variable to not break
some unspecified tools.
Was anyone able to name an actual tool that would be impacted? Why not
work to update these tools at the same time? An easy 'fix' will be for
any such tool to give an error message if it sees ':' or ';' in the
WORKSPACE environment variable. Although this is really not a fix, it
will be just as much support as if they ignore the new
WORKSPACE_MULTIPLE environment variable.
I think that using the single separated WORKSPACE environment variable
is more intuitive/expected. From using env vars such as PATH, we all
know what it means.
For WORKSPACE+WORKSPACE_MULTIPLE, I don't know which has priority. I
assume WORKSPACE is checked first, and then WORKSPACE_MULTIPLE?
This was described in Liming's email, in point 4b.
Will this work for the integrated CryptoPkg + open-ssl? It seems like
we need a priority above EDK II for this. I guess WORKSPACE will not
be set to EDK II in this case?
Anyway, it just seems a little odd.
For me a colon-separated (well, separator-separated :)) single WORKSPACE
variable would be more intuitive, but WORKSPACE_MULTIPLE can be defined well
enough too. For example:
- WORKSPACE must not contain separators
- if WORKSPACE_MULTIPLE is set, then the effect is as if
${WORKSPACE}:${WORKSPACE_MULTIPLE} were specified under the
well-known PATH semantics.
No clue about the CryptoPkg impact. Can you remind me please why CryptoPkg /
OpensslLib are special wrt. WORKSPACE?
Thanks
Laszlo
-Jordan
-Original Message-
From: edk2-devel
Re: [edk2] [PATCH] MdeModulePkg DxeIpl: Add stack NX support
On Aug 5, 2015, at 8:41 AM, Laszlo Ersek ler...@redhat.com wrote: On 07/31/15 14:22, Star Zeng wrote: This feature is added for UEFI spec that says Stack may be marked as non-executable in identity mapped page tables. A PCD PcdSetNxForStack is added to turn on/off this feature, and it is FALSE by default. Cc: Jiewen Yao jiewen@intel.com Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng star.z...@intel.com --- MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf | 3 +- MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c | 185 ++- MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c | 10 +- MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c | 160 +--- MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.h | 61 +++- MdeModulePkg/MdeModulePkg.dec| 11 +- MdeModulePkg/MdeModulePkg.uni| Bin 166792 - 168862 bytes 7 files changed, 392 insertions(+), 38 deletions(-) I tried to enable this feature in the OvmfPkg builds (all three of them). Good thing it is a PCD flag. Unfortunately, I have found that a non-executable DXE stack breaks the EFI_MP_SERVICE_PROTOCOL.StartupAllAPs() function. (Which is provided by UefiCpuPkg/CpuDxe/CpuMp.c.) The virtual machine is re-set when that function is called. I would think it would just be the BSP stack that is set to NX. This could be a bug in the code, as the AP’s run off a different stack that is not NX, and it looks like the code gets copied to BootServices, and the AP startup code in ACPI NVS memory? Thanks, Andrew Fish I presume the starup code for the APs resides in an area that happens to be marked non-executable (if this feature enabled), and that causes a fatal fault or some such when the APs get the startup IPI. Thanks Laszlo ___ edk2-devel mailing list edk2-devel@lists.01.org mailto:edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel 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 DxeIpl: Add stack NX support
On 08/05/15 18:18, Andrew Fish wrote: On Aug 5, 2015, at 8:41 AM, Laszlo Ersek ler...@redhat.com mailto:ler...@redhat.com wrote: On 07/31/15 14:22, Star Zeng wrote: This feature is added for UEFI spec that says Stack may be marked as non-executable in identity mapped page tables. A PCD PcdSetNxForStack is added to turn on/off this feature, and it is FALSE by default. Cc: Jiewen Yao jiewen@intel.com mailto:jiewen@intel.com Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng star.z...@intel.com mailto:star.z...@intel.com --- MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf | 3 +- MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c | 185 ++- MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c | 10 +- MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c | 160 +--- MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.h | 61 +++- MdeModulePkg/MdeModulePkg.dec| 11 +- MdeModulePkg/MdeModulePkg.uni| Bin 166792 - 168862 bytes 7 files changed, 392 insertions(+), 38 deletions(-) I tried to enable this feature in the OvmfPkg builds (all three of them). Good thing it is a PCD flag. I thought the same :) Unfortunately, I have found that a non-executable DXE stack breaks the EFI_MP_SERVICE_PROTOCOL.StartupAllAPs() function. (Which is provided by UefiCpuPkg/CpuDxe/CpuMp.c.) The virtual machine is re-set when that function is called. I would think it would just be the BSP stack that is set to NX. This could be a bug in the code, as the AP’s run off a different stack that is not NX, and it looks like the code gets copied to BootServices, and the AP startup code in ACPI NVS memory? I hope the respective package maintainers / feature developers will seize the opportunity to investigate this! :) I have the interest, but not the time, to dig into it right now. Thanks! Laszlo Thanks, Andrew Fish I presume the starup code for the APs resides in an area that happens to be marked non-executable (if this feature enabled), and that causes a fatal fault or some such when the APs get the startup IPI. Thanks Laszlo ___ edk2-devel mailing list edk2-devel@lists.01.org mailto: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] Building on Windows
David Woodhouse [mailto:dw...@infradead.org] wrote: ]Sent: Wednesday, August 05, 2015 10:32 AM ]To: Scott Duplichan sc...@notabs.org; edk2-de...@ml01.01.org ]Cc: david.woodho...@intel.com; 'Long, Qin' qin.l...@intel.com ]Subject: Re: [edk2] Building on Windows ] ]On Wed, 2015-08-05 at 09:43 -0500, Scott Duplichan wrote: ] Here is how you can build Ovmf on Windows (tested with Win7 x64): ] ] 1) Get edk2, including BaseTools\Bin\Win32. You are right, git doesn't ] work for getting the external BaseTools\Bin\Win32. ] ] 2) Install Visual Studio 2008. EDK2 supports only a C: drive installation. ] EDK2 doesn't fully support installing multiple versions of Visual ] Studio. ] ]OK. ] ] 3) Open a plain Windows command prompt (cmd.exe). ] ] 4) Tell EDK2 where nasm is: ]C:\tmp\edk2 set NASM_PREFIX=D:\edk2build\uefiTools\nasm211\ ] ]And where *is* nasm? I installed the Bin\Win32 tools as directed, but ]it doesn't seem to be there. ] ]So I downloaded a version and installed it, such that ]%NASM_PREFIX%nasm.exe works. ] ]I also installed IASL for good measure, although that wasn't mentioned ]in the documentation I was looking at either. ] ] 5) Run Edk2Setup.bat: ] ]d:\tmp\edk2 Edk2Setup.bat ] ]Rebuilding of the tools is not required. Binaries of the latest, ]tested versions of the tools have been tested and included in the ]EDK II repository. ] ]If you really want to build the tools, use the --rebuild option. ] ]!!! WARNING !!! No CYGWIN_HOME set, gcc build may not be used !!! ] ] ] # ]WORKSPACE= d:\tmp\edk2 ]EDK_TOOLS_PATH = d:\tmp\edk2\BaseTools ]BASE_TOOLS_PATH = d:\tmp\edk2\BaseTools ]## PATH # ]d:\tmp\edk2\BaseTools\Bin\Win32 ]C:\Windows\system32 ]C:\Windows ]C:\Windows\System32\Wbem ]d:\util ] ]d:\tmp\edk2 ] ]OK. ] ] 6) Add your openssl-1.0.2d files before building. ] ] 7) Build using one of these command lines: ]build.exe -p OvmfPkg\OvmfPkgX64.dsc -b DEBUG -t VS2008x86 -n 16 -a X64 -DSECURE_BOOT_ENABLE -]DFD_SIZE_2MB ]build.exe -p OvmfPkg\OvmfPkgIA32.dsc -b DEBUG -t VS2008x86 -n 16 -a IA32 -DSECURE_BOOT_ENABLE -]DFD_SIZE_2MB ]build.exe -p OvmfPkg\OvmfPkgIA32X64.dsc -b DEBUG -t VS2008x86 -n 16 -a IA32 -a X64 -]DSECURE_BOOT_ENABLE -DFD_SIZE_2MB ] ] ] These instructions are for a 64-bit Windows version. For 32-bit, ] replace VS2008x86 with VS2008. ] ]Aha, that was it. I was using VS2008 so was looking in Program Files ]not Program Files (x86). Thanks. ] ]Oh Windows, how I hate thee. It is not really a Windows problem. Visual Studio gives us an environment variable that points to the installation directory. I proposed a change to use this EV instead of the hard-coded paths. It was rejected: https://www.mail-archive.com/edk2-devel@lists.sourceforge.net/msg09690.html Part of that solution addresses the exact problem you speak of: One significant benefit is the elimination of redundant tool chain names. With the current scheme, a Win32 user calling build.exe with --tagname=VS2008 must call with --tagname=VS2008x86 for Win64. Thanks, Scott ]But at least I'd mostly solved the issues by building on a sane system ]with MinGw64, and I only need to *test* under Windows/MSVC. Actually ]having to do any real work in the Windows environment might have blown ]my tiny little mind. ] ]-- ]dwmw2 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Building on Windows
Some Windows/EDK2 blog posts that may help: http://uefi.blogspot.com/2013/06/how-to-set-up-edk2s-windows-hosted-uefi.html http://pete.akeo.ie/2015/01/easily-create-uefi-applications-using.html http://spyker729.blogspot.com/2012/10/how-to-build-edk-edkii-environment-in.html If you look at the Intel SSG training, it is mostly Windows/VisualStudio-centric, and spends a lot of time on setup, maybe it'll be helpful. It looks like 5/24 is the last update, grab both Presentations and Lab zips. http://sourceforge.net/projects/edk2/files/Training/TrainingMaterial/ IMO, besides a batch file, the EDK2 needs an MSI or NSIS installer for Windows. A Python script that looked for any available installed toolchains from the paths in the EDK2 tools def file, might also be helpful. ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] BaseTools features: multiple workspaces
On 2015-08-05 07:06:46, Gao, Liming wrote:
Thanks for your all comments.
Most people prefers to keep WOSKAPCE as single directory, and
introduce new env $(WORKSPACE_MULTIPLE).
I'm not sure about this conclusion. I think Paolo, Laszlo and I all
expressed that using WORKSPACE for the multiple directories seemed
more natural.
I think you originally suggested just using WORKSPACE, but maybe now
have changed your mind.
I know Tim had some big concerns with expanding WORKSPACE. I agree
with his concerns, but I don't think it will be much better with
WORKSPACE_MULTIPLE. (The same tools will break.)
Mike and Andrew appear to prefer WORKSPACE_MULTIPLE.
What about this suggestion?
WORKSPACE: expand to a list of directories
WORKSPACE_BUILD: if not set, use first path in WORKSPACE + '/Build'
WORKSPACE_CONF: if not set, scan WORKSPACE paths to find 'Conf' dir
WORKSPACE_TOOLS: if not set, scan WORKSPACE paths to find 'BaseTools' dir
With WORKSPACE and WORKSPACE_MULTIPLE we have a strange intersection
of 'part of the source tree' and 'all of the source tree'. I think the
variables I recommend avoid that partial overlap.
-Jordan
I think Mike solution can
make them more clear if WORKSPACE_MULTIPLE is set.
On QA team impact, it should be small. QA team can still use the
current working model to place all packages in root directory, and
set WORKSPACE only. QA team just needs to know the package list.
Tim gave another idea to define multiple source locations in
Platform DSC file. It doesn't conflict with this proposal. We can
implement $(WORKSPACE_MULTIPLE) feature first, and evaluate DSC
update. On the fixed tree layout, these two solutions can work. Once
the end user reorganizes its tree layout, he needs to set
$(WORKSPACE_MULTIPLE) env or update Platform DSC file, and build
platform DSC.
Thanks
Liming
-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com]
Sent: Tuesday, August 04, 2015 7:20 PM
To: Justen, Jordan L
Cc: Gao, Liming; Paolo Bonzini; edk2-devel@lists.01.org
Subject: Re: [edk2] BaseTools features: multiple workspaces
On 08/03/15 19:35, Jordan Justen wrote:
On 2015-08-03 02:08:14, Gao, Liming wrote:
Paolo:
I think that keep the exiting syntax for WORKSPACE to be a single
path can minimize the impacts to exiting tools that assume a
single workspace.
I know you originally suggested to use WORKSPACE, but got some
feedback that it might be better to create a new variable to not break
some unspecified tools.
Was anyone able to name an actual tool that would be impacted? Why not
work to update these tools at the same time? An easy 'fix' will be for
any such tool to give an error message if it sees ':' or ';' in the
WORKSPACE environment variable. Although this is really not a fix, it
will be just as much support as if they ignore the new
WORKSPACE_MULTIPLE environment variable.
I think that using the single separated WORKSPACE environment variable
is more intuitive/expected. From using env vars such as PATH, we all
know what it means.
For WORKSPACE+WORKSPACE_MULTIPLE, I don't know which has priority. I
assume WORKSPACE is checked first, and then WORKSPACE_MULTIPLE?
This was described in Liming's email, in point 4b.
Will this work for the integrated CryptoPkg + open-ssl? It seems like
we need a priority above EDK II for this. I guess WORKSPACE will not
be set to EDK II in this case?
Anyway, it just seems a little odd.
For me a colon-separated (well, separator-separated :)) single WORKSPACE
variable would be more intuitive, but WORKSPACE_MULTIPLE can be defined well
enough too. For example:
- WORKSPACE must not contain separators
- if WORKSPACE_MULTIPLE is set, then the effect is as if
${WORKSPACE}:${WORKSPACE_MULTIPLE} were specified under the
well-known PATH semantics.
No clue about the CryptoPkg impact. Can you remind me please why CryptoPkg /
OpensslLib are special wrt. WORKSPACE?
Thanks
Laszlo
-Jordan
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf
Of Paolo Bonzini
Sent: Monday, August 03, 2015 4:31 PM
To: Gao, Liming; edk2-devel@lists.01.org
Subject: Re: [edk2] BaseTools features: multiple workspaces
On 03/08/2015 05:56, Gao, Liming wrote:
Hi, all
We will update BaseTools feature to allow more than one workspaces. The
detail design in the below. Please help review it. If you have any
comments, please let me know.
1. Keep $(WORKSPACE) environment as is
a. $(WORKSPACE) determines location of Build and Conf directory.
2. New optional $(WORKSPACE_MULTIPLE) environment is added to
include more directories with the separator ';', like $(PATH)
Why is $(WORKSPACE_MULTIPLE) necessary? On Linux it is okay to break
preexisting paths that contain a :; on Windows semicolons are allowed in
theory but in practice break in
Re: [edk2] BaseTools features: multiple workspaces
On Aug 5, 2015, at 12:09 PM, Jordan Justen jordan.l.jus...@intel.com wrote: On 2015-08-05 07:06:46, Gao, Liming wrote: Thanks for your all comments. Most people prefers to keep WOSKAPCE as single directory, and introduce new env $(WORKSPACE_MULTIPLE). I'm not sure about this conclusion. I think Paolo, Laszlo and I all expressed that using WORKSPACE for the multiple directories seemed more natural. Have your really thought this out? It breaks all of my internal build tips, and a lot of the edk2 build tips. git grep WORKSPACE — ... EmulatorPkg/Unix/Host/Host.inf:148: XCODE:*_*_X64_CC_FLAGS = -I$(WORKSPACE)/EmulatorPkg/Unix/Host/X11IncludeHack EmulatorPkg/build.sh:22:if [ -z $WORKSPACE ] EmulatorPkg/build.sh:37: echo Building from: $WORKSPACE EmulatorPkg/build.sh:178:BUILD_OUTPUT_DIR=$WORKSPACE/Build/Emulator32 EmulatorPkg/build.sh:184:BUILD_OUTPUT_DIR=$WORKSPACE/Build/Emulator EmulatorPkg/build.sh:201:PLATFORMFILE=$WORKSPACE/EmulatorPkg/EmulatorPkg.dsc EmulatorPkg/build.sh:209: make -C $WORKSPACE/BaseTools EmulatorPkg/build.sh:214: make -C $WORKSPACE/BaseTools EmulatorPkg/build.sh:232:cp $WORKSPACE/EmulatorPkg/Unix/lldbefi.py $BUILD_OUTPUT_DIR/DEBUG_$TARGET_TOOLS/$PROCESSOR EmulatorPkg/build.sh:233:cd $BUILD_ROOT_ARCH; /usr/bin/lldb --source $WORKSPACE/EmulatorPkg/Unix/lldbinit Host EmulatorPkg/build.sh:236:cp $WORKSPACE/EmulatorPkg/Unix/.gdbinit $BUILD_OUTPUT_DIR/DEBUG_$TARGET_TOOLS/$PROCESSOR EmulatorPkg/build.sh:241: /usr/bin/gdb $BUILD_ROOT_ARCH/Host -q -cd=$BUILD_ROOT_ARCH -x $WORKSPACE/EmulatorPkg/Unix/GdbRun EmulatorPkg/build.sh:247:build -p $WORKSPACE/EmulatorPkg/EmulatorPkg.dsc -a $PROCESSOR -b $BUILDTARGET -t $HOST_TOOLS -D UNIX_SEC_BUILD -n 3 clean EmulatorPkg/build.sh:248:build -p $WORKSPACE/EmulatorPkg/EmulatorPkg.dsc -a $PROCESSOR -b $BUILDTARGET -t $TARGET_TOOLS -n 3 clean EmulatorPkg/build.sh:252:make -C $WORKSPACE/BaseTools clean EmulatorPkg/build.sh:253:build -p $WORKSPACE/EmulatorPkg/EmulatorPkg.dsc -a $PROCESSOR -b $BUILDTARGET -t $HOST_TOOLS -D UNIX_SEC_BUILD -n 3 clean EmulatorPkg/build.sh:254:build -p $WORKSPACE/EmulatorPkg/EmulatorPkg.dsc -a $PROCESSOR -b $BUILDTARGET -t $TARGET_TOOLS -n 3 clean EmulatorPkg/build.sh:255:build -p $WORKSPACE/ShellPkg/ShellPkg.dsc -a IA32 -b $BUILDTARGET -t $TARGET_TOOLS -n 3 clean EmulatorPkg/build.sh:265: build -p $WORKSPACE/EmulatorPkg/EmulatorPkg.dsc $BUILD_OPTIONS -a $PROCESSOR -b $BUILDTARGET -t $TARGET_TOOLS -D BUILD_$ARCH_SIZE -D UNIX_SEC_BUILD $NETWORK_SUPPORT $BUILD_NEW_SHELL $BUILD_FAT -n 3 EmulatorPkg/build.sh:267: build -p $WORKSPACE/EmulatorPkg/EmulatorPkg.dsc $BUILD_OPTIONS -a $PROCESSOR -b $BUILDTARGET -t $HOST_TOOLS -D BUILD_$ARCH_SIZE -D UNIX_SEC_BUILD -D SKIP_MAIN_BUILD -n 3 modules EmulatorPkg/build.sh:268: build -p $WORKSPACE/EmulatorPkg/EmulatorPkg.dsc $BUILD_OPTIONS -a $PROCESSOR -b $BUILDTARGET -t $TARGET_TOOLS -D BUILD_$ARCH_SIZE $NETWORK_SUPPORT $BUILD_NEW_SHELL $BUILD_FAT -n 3 OvmfPkg/README:48:under the $WORKSPACE/Build/*/*/FV directory. The actual path will OvmfPkg/README:179:- Install the drivers into a directory called Intel3.5 in your WORKSPACE. OvmfPkg/ResetVector/ResetVector.inf:36: *_*_IA32_NASMB_FLAGS = -I$(WORKSPACE)/UefiCpuPkg/ResetVector/Vtf0/ OvmfPkg/ResetVector/ResetVector.inf:37: *_*_X64_NASMB_FLAGS = -I$(WORKSPACE)/UefiCpuPkg/ResetVector/Vtf0/ OvmfPkg/build.sh:22:if [ -z $WORKSPACE ] OvmfPkg/build.sh:37: echo Building from: $WORKSPACE OvmfPkg/build.sh:215: PLATFORMFILE=$WORKSPACE/OvmfPkg/OvmfPkg$Processor.dsc OvmfPkg/build.sh:249:BUILD_ROOT=$WORKSPACE/Build/$PLATFORM_BUILD_DIR/$BUILDTARGET_$TARGET_TOOLS OvmfPkg/build.sh:258: make -C $WORKSPACE/BaseTools OvmfPkg/build.sh:263: make -C $WORKSPACE/BaseTools ShellBinPkg/ReadMe.txt:9:1. Check out EDK II to $(WORKSPACE) ShellBinPkg/ReadMe.txt:12:2. Under $(WORKSPACE) directory (i.e. c:\EdkII), StdLib/StdLib.inc:114:RVCT:*_*_*_CC_FLAGS = --library_interface=none -DUEFI_C_SOURCE -J$(WORKSPACE)/StdLib/Include -J$(WORKSPACE)/StdLib/Include/Arm StdLib/StdLib.inc:124:RVCT:*_*_*_CC_FLAGS = --library_interface=none -DUEFI_C_SOURCE -J$(WORKSPACE)/StdLib/Include -J$(WORKSPACE)/StdLib/Include/Arm Vlv2TbltDevicePkg/PlatformPkg.fdf:963:DXE_DEPEX DXE_DEPEX Optional $(WORKSPACE)/$(PLATFORM_PACKAGE)/IntelGopDepex/IntelGopDriver.depex Vlv2TbltDevicePkg/PlatformPkgGcc.fdf:127:FILE = $(WORKSPACE)/Vlv2TbltDevicePkg/Stitch/Gcc/NvStorageVariable.bin Vlv2TbltDevicePkg/PlatformPkgGcc.fdf:131:FILE = $(WORKSPACE)/Vlv2TbltDevicePkg/Stitch/Gcc/NvStorageFtwWorking.bin Vlv2TbltDevicePkg/PlatformPkgGcc.fdf:135:FILE = $(WORKSPACE)/Vlv2TbltDevicePkg/Stitch/Gcc/NvStorageFtwSpare.bin Vlv2TbltDevicePkg/PlatformPkgGcc.fdf:921:DXE_DEPEX DXE_DEPEX Optional $(WORKSPACE)/$(PLATFORM_PACKAGE)/IntelGopDepex/IntelGopDriver.depex Vlv2TbltDevicePkg/bldX64.bat:18:@if exist %WORKSPACE%\edk2.log del %WORKSPACE%\edk2.log
Re: [edk2] BaseTools features: multiple workspaces
Jordan,
We already have EDK_TOOLS_PATH for the path to the tools, so I don't think we
should add WORKSPACE_TOOLS.
The DSC file specifies the output directory and the syntax supports both
workspace relative paths and absolute paths. I am not sure I understand what
issue is addressed by adding WORKSPACE_BUILD. If DSC specifies output
directory using a workspace relative path, then tools use WORKSPACE. If DSC
uses absolute path for the output path, then the output can be places anywhere.
The build command supports the --conf flag, so alternate CONF directories can
be specified on the build command line. I am not sure I understand what issue
is addressed by adding WORKSPACE_CONF.
Best regards,
Mike
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jordan
Justen
Sent: Wednesday, August 05, 2015 12:09 PM
To: Gao, Liming; Laszlo Ersek
Cc: Paolo Bonzini; edk2-devel@lists.01.org
Subject: Re: [edk2] BaseTools features: multiple workspaces
On 2015-08-05 07:06:46, Gao, Liming wrote:
Thanks for your all comments.
Most people prefers to keep WOSKAPCE as single directory, and
introduce new env $(WORKSPACE_MULTIPLE).
I'm not sure about this conclusion. I think Paolo, Laszlo and I all
expressed that using WORKSPACE for the multiple directories seemed
more natural.
I think you originally suggested just using WORKSPACE, but maybe now
have changed your mind.
I know Tim had some big concerns with expanding WORKSPACE. I agree
with his concerns, but I don't think it will be much better with
WORKSPACE_MULTIPLE. (The same tools will break.)
Mike and Andrew appear to prefer WORKSPACE_MULTIPLE.
What about this suggestion?
WORKSPACE: expand to a list of directories
WORKSPACE_BUILD: if not set, use first path in WORKSPACE + '/Build'
WORKSPACE_CONF: if not set, scan WORKSPACE paths to find 'Conf' dir
WORKSPACE_TOOLS: if not set, scan WORKSPACE paths to find 'BaseTools' dir
With WORKSPACE and WORKSPACE_MULTIPLE we have a strange intersection
of 'part of the source tree' and 'all of the source tree'. I think the
variables I recommend avoid that partial overlap.
-Jordan
I think Mike solution can
make them more clear if WORKSPACE_MULTIPLE is set.
On QA team impact, it should be small. QA team can still use the
current working model to place all packages in root directory, and
set WORKSPACE only. QA team just needs to know the package list.
Tim gave another idea to define multiple source locations in
Platform DSC file. It doesn't conflict with this proposal. We can
implement $(WORKSPACE_MULTIPLE) feature first, and evaluate DSC
update. On the fixed tree layout, these two solutions can work. Once
the end user reorganizes its tree layout, he needs to set
$(WORKSPACE_MULTIPLE) env or update Platform DSC file, and build
platform DSC.
Thanks
Liming
-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com]
Sent: Tuesday, August 04, 2015 7:20 PM
To: Justen, Jordan L
Cc: Gao, Liming; Paolo Bonzini; edk2-devel@lists.01.org
Subject: Re: [edk2] BaseTools features: multiple workspaces
On 08/03/15 19:35, Jordan Justen wrote:
On 2015-08-03 02:08:14, Gao, Liming wrote:
Paolo:
I think that keep the exiting syntax for WORKSPACE to be a single
path can minimize the impacts to exiting tools that assume a
single workspace.
I know you originally suggested to use WORKSPACE, but got some
feedback that it might be better to create a new variable to not break
some unspecified tools.
Was anyone able to name an actual tool that would be impacted? Why not
work to update these tools at the same time? An easy 'fix' will be for
any such tool to give an error message if it sees ':' or ';' in the
WORKSPACE environment variable. Although this is really not a fix, it
will be just as much support as if they ignore the new
WORKSPACE_MULTIPLE environment variable.
I think that using the single separated WORKSPACE environment variable
is more intuitive/expected. From using env vars such as PATH, we all
know what it means.
For WORKSPACE+WORKSPACE_MULTIPLE, I don't know which has priority. I
assume WORKSPACE is checked first, and then WORKSPACE_MULTIPLE?
This was described in Liming's email, in point 4b.
Will this work for the integrated CryptoPkg + open-ssl? It seems like
we need a priority above EDK II for this. I guess WORKSPACE will not
be set to EDK II in this case?
Anyway, it just seems a little odd.
For me a colon-separated (well, separator-separated :)) single WORKSPACE
variable would be more intuitive, but WORKSPACE_MULTIPLE can be defined well
enough too. For example:
- WORKSPACE must not contain separators
- if WORKSPACE_MULTIPLE is set, then the effect is as if
${WORKSPACE}:${WORKSPACE_MULTIPLE} were specified under the
well-known PATH semantics.
No clue about the CryptoPkg impact. Can you remind me please why CryptoPkg /
OpensslLib
Re: [edk2] BaseTools features: multiple workspaces
On 2015-08-05 12:19:47, Andrew Fish wrote: On Aug 5, 2015, at 12:09 PM, Jordan Justen jordan.l.jus...@intel.com wrote: On 2015-08-05 07:06:46, Gao, Liming wrote: Thanks for your all comments. Most people prefers to keep WOSKAPCE as single directory, and introduce new env $(WORKSPACE_MULTIPLE). I'm not sure about this conclusion. I think Paolo, Laszlo and I all expressed that using WORKSPACE for the multiple directories seemed more natural. Have your really thought this out? It breaks all of my internal build tips, and a lot of the edk2 build tips. Unless we do something about most of those references then WORKSPACE will have to be set to your 'edk2' tree. Therefore your Conf files must exist in your edk2 tree, and your build output must exist in your edk2 tree, and BaseTools must exist in your edk2 tree. Many of those references map to the three new variables I mentioned. $WORKSPACE/EmulatorPkg doesn't. I don't know if that means that we need an EDKII variable, or maybe PLATFORM_WORKSPACE, or perhaps something else... -Jordan git grep WORKSPACE — ... EmulatorPkg/Unix/Host/Host.inf:148: XCODE:*_*_X64_CC_FLAGS = -I$(WORKSPACE)/EmulatorPkg/Unix/Host/X11IncludeHack EmulatorPkg/build.sh:22:if [ -z $WORKSPACE ] EmulatorPkg/build.sh:37: echo Building from: $WORKSPACE EmulatorPkg/build.sh:178:BUILD_OUTPUT_DIR=$WORKSPACE/Build/Emulator32 EmulatorPkg/build.sh:184:BUILD_OUTPUT_DIR=$WORKSPACE/Build/Emulator EmulatorPkg/build.sh:201:PLATFORMFILE=$WORKSPACE/EmulatorPkg/EmulatorPkg.dsc EmulatorPkg/build.sh:209: make -C $WORKSPACE/BaseTools EmulatorPkg/build.sh:214: make -C $WORKSPACE/BaseTools EmulatorPkg/build.sh:232:cp $WORKSPACE/EmulatorPkg/Unix/lldbefi.py $BUILD_OUTPUT_DIR/DEBUG_$TARGET_TOOLS/$PROCESSOR EmulatorPkg/build.sh:233:cd $BUILD_ROOT_ARCH; /usr/bin/lldb --source $WORKSPACE/EmulatorPkg/Unix/lldbinit Host EmulatorPkg/build.sh:236:cp $WORKSPACE/EmulatorPkg/Unix/.gdbinit $BUILD_OUTPUT_DIR/DEBUG_$TARGET_TOOLS/$PROCESSOR EmulatorPkg/build.sh:241: /usr/bin/gdb $BUILD_ROOT_ARCH/Host -q -cd=$BUILD_ROOT_ARCH -x $WORKSPACE/EmulatorPkg/Unix/GdbRun EmulatorPkg/build.sh:247:build -p $WORKSPACE/EmulatorPkg/EmulatorPkg.dsc -a $PROCESSOR -b $BUILDTARGET -t $HOST_TOOLS -D UNIX_SEC_BUILD -n 3 clean EmulatorPkg/build.sh:248:build -p $WORKSPACE/EmulatorPkg/EmulatorPkg.dsc -a $PROCESSOR -b $BUILDTARGET -t $TARGET_TOOLS -n 3 clean EmulatorPkg/build.sh:252:make -C $WORKSPACE/BaseTools clean EmulatorPkg/build.sh:253:build -p $WORKSPACE/EmulatorPkg/EmulatorPkg.dsc -a $PROCESSOR -b $BUILDTARGET -t $HOST_TOOLS -D UNIX_SEC_BUILD -n 3 clean EmulatorPkg/build.sh:254:build -p $WORKSPACE/EmulatorPkg/EmulatorPkg.dsc -a $PROCESSOR -b $BUILDTARGET -t $TARGET_TOOLS -n 3 clean EmulatorPkg/build.sh:255:build -p $WORKSPACE/ShellPkg/ShellPkg.dsc -a IA32 -b $BUILDTARGET -t $TARGET_TOOLS -n 3 clean EmulatorPkg/build.sh:265: build -p $WORKSPACE/EmulatorPkg/EmulatorPkg.dsc $BUILD_OPTIONS -a $PROCESSOR -b $BUILDTARGET -t $TARGET_TOOLS -D BUILD_$ARCH_SIZE -D UNIX_SEC_BUILD $NETWORK_SUPPORT $BUILD_NEW_SHELL $BUILD_FAT -n 3 EmulatorPkg/build.sh:267: build -p $WORKSPACE/EmulatorPkg/EmulatorPkg.dsc $BUILD_OPTIONS -a $PROCESSOR -b $BUILDTARGET -t $HOST_TOOLS -D BUILD_$ARCH_SIZE -D UNIX_SEC_BUILD -D SKIP_MAIN_BUILD -n 3 modules EmulatorPkg/build.sh:268: build -p $WORKSPACE/EmulatorPkg/EmulatorPkg.dsc $BUILD_OPTIONS -a $PROCESSOR -b $BUILDTARGET -t $TARGET_TOOLS -D BUILD_$ARCH_SIZE $NETWORK_SUPPORT $BUILD_NEW_SHELL $BUILD_FAT -n 3 OvmfPkg/README:48:under the $WORKSPACE/Build/*/*/FV directory. The actual path will OvmfPkg/README:179:- Install the drivers into a directory called Intel3.5 in your WORKSPACE. OvmfPkg/ResetVector/ResetVector.inf:36: *_*_IA32_NASMB_FLAGS = -I$(WORKSPACE)/UefiCpuPkg/ResetVector/Vtf0/ OvmfPkg/ResetVector/ResetVector.inf:37: *_*_X64_NASMB_FLAGS = -I$(WORKSPACE)/UefiCpuPkg/ResetVector/Vtf0/ OvmfPkg/build.sh:22:if [ -z $WORKSPACE ] OvmfPkg/build.sh:37: echo Building from: $WORKSPACE OvmfPkg/build.sh:215: PLATFORMFILE=$WORKSPACE/OvmfPkg/OvmfPkg$Processor.dsc OvmfPkg/build.sh:249:BUILD_ROOT=$WORKSPACE/Build/$PLATFORM_BUILD_DIR/$BUILDTARGET_$TARGET_TOOLS OvmfPkg/build.sh:258: make -C $WORKSPACE/BaseTools OvmfPkg/build.sh:263: make -C $WORKSPACE/BaseTools ShellBinPkg/ReadMe.txt:9:1. Check out EDK II to $(WORKSPACE) ShellBinPkg/ReadMe.txt:12:2. Under $(WORKSPACE) directory (i.e. c:\EdkII), StdLib/StdLib.inc:114:RVCT:*_*_*_CC_FLAGS = --library_interface=none -DUEFI_C_SOURCE -J$(WORKSPACE)/StdLib/Include -J$(WORKSPACE)/StdLib/Include/Arm StdLib/StdLib.inc:124:RVCT:*_*_*_CC_FLAGS = --library_interface=none -DUEFI_C_SOURCE -J$(WORKSPACE)/StdLib/Include -J$(WORKSPACE)/StdLib/Include/Arm Vlv2TbltDevicePkg/PlatformPkg.fdf:963:DXE_DEPEX DXE_DEPEX Optional
Re: [edk2] BaseTools features: multiple workspaces
On Aug 5, 2015, at 12:40 PM, Jordan Justen jordan.l.jus...@intel.com wrote: On 2015-08-05 12:19:47, Andrew Fish wrote: On Aug 5, 2015, at 12:09 PM, Jordan Justen jordan.l.jus...@intel.com wrote: On 2015-08-05 07:06:46, Gao, Liming wrote: Thanks for your all comments. Most people prefers to keep WOSKAPCE as single directory, and introduce new env $(WORKSPACE_MULTIPLE). I'm not sure about this conclusion. I think Paolo, Laszlo and I all expressed that using WORKSPACE for the multiple directories seemed more natural. Have your really thought this out? It breaks all of my internal build tips, and a lot of the edk2 build tips. Unless we do something about most of those references then WORKSPACE will have to be set to your 'edk2' tree. Therefore your Conf files must exist in your edk2 tree, and your build output must exist in your edk2 tree, and BaseTools must exist in your edk2 tree. Sorry I’m not following. In our local hack we do something like. BaseTools/ - edk2 tools BuildResults/ - Build output edk2/ - Open source edk2 stuff Vendor/ - code from vendors, that is usually rooted in $(WORKSPACE). So we set WORKSPACE_MULTIPLE = WORKSPACE/edk2;WORKSPACE/Vendor/Alpha;WORKSPACE/Vendor/Beta and we are good. Thus you can : Move the edk2/ code to any location you want down stream of WORKSPACE BuildResults is defined in DSC so it can be any location you want down stream of WORKSPACE. You can override Conf if needed? BaseTools ends up in the root of the tree, and that is kind of a feature. This solves enough problems to be useful, and does not break anything existing. From a product point of view you need the BaseTools in the tree in case you need to reproduce your ROM years later. Thanks, Andrew Fish Many of those references map to the three new variables I mentioned. $WORKSPACE/EmulatorPkg doesn't. I don't know if that means that we need an EDKII variable, or maybe PLATFORM_WORKSPACE, or perhaps something else... -Jordan git grep WORKSPACE — ... EmulatorPkg/Unix/Host/Host.inf:148: XCODE:*_*_X64_CC_FLAGS = -I$(WORKSPACE)/EmulatorPkg/Unix/Host/X11IncludeHack EmulatorPkg/build.sh:22:if [ -z $WORKSPACE ] EmulatorPkg/build.sh:37: echo Building from: $WORKSPACE EmulatorPkg/build.sh:178:BUILD_OUTPUT_DIR=$WORKSPACE/Build/Emulator32 EmulatorPkg/build.sh:184:BUILD_OUTPUT_DIR=$WORKSPACE/Build/Emulator EmulatorPkg/build.sh:201:PLATFORMFILE=$WORKSPACE/EmulatorPkg/EmulatorPkg.dsc EmulatorPkg/build.sh:209: make -C $WORKSPACE/BaseTools EmulatorPkg/build.sh:214: make -C $WORKSPACE/BaseTools EmulatorPkg/build.sh:232:cp $WORKSPACE/EmulatorPkg/Unix/lldbefi.py $BUILD_OUTPUT_DIR/DEBUG_$TARGET_TOOLS/$PROCESSOR EmulatorPkg/build.sh:233:cd $BUILD_ROOT_ARCH; /usr/bin/lldb --source $WORKSPACE/EmulatorPkg/Unix/lldbinit Host EmulatorPkg/build.sh:236:cp $WORKSPACE/EmulatorPkg/Unix/.gdbinit $BUILD_OUTPUT_DIR/DEBUG_$TARGET_TOOLS/$PROCESSOR EmulatorPkg/build.sh:241: /usr/bin/gdb $BUILD_ROOT_ARCH/Host -q -cd=$BUILD_ROOT_ARCH -x $WORKSPACE/EmulatorPkg/Unix/GdbRun EmulatorPkg/build.sh:247:build -p $WORKSPACE/EmulatorPkg/EmulatorPkg.dsc -a $PROCESSOR -b $BUILDTARGET -t $HOST_TOOLS -D UNIX_SEC_BUILD -n 3 clean EmulatorPkg/build.sh:248:build -p $WORKSPACE/EmulatorPkg/EmulatorPkg.dsc -a $PROCESSOR -b $BUILDTARGET -t $TARGET_TOOLS -n 3 clean EmulatorPkg/build.sh:252:make -C $WORKSPACE/BaseTools clean EmulatorPkg/build.sh:253:build -p $WORKSPACE/EmulatorPkg/EmulatorPkg.dsc -a $PROCESSOR -b $BUILDTARGET -t $HOST_TOOLS -D UNIX_SEC_BUILD -n 3 clean EmulatorPkg/build.sh:254:build -p $WORKSPACE/EmulatorPkg/EmulatorPkg.dsc -a $PROCESSOR -b $BUILDTARGET -t $TARGET_TOOLS -n 3 clean EmulatorPkg/build.sh:255:build -p $WORKSPACE/ShellPkg/ShellPkg.dsc -a IA32 -b $BUILDTARGET -t $TARGET_TOOLS -n 3 clean EmulatorPkg/build.sh:265: build -p $WORKSPACE/EmulatorPkg/EmulatorPkg.dsc $BUILD_OPTIONS -a $PROCESSOR -b $BUILDTARGET -t $TARGET_TOOLS -D BUILD_$ARCH_SIZE -D UNIX_SEC_BUILD $NETWORK_SUPPORT $BUILD_NEW_SHELL $BUILD_FAT -n 3 EmulatorPkg/build.sh:267: build -p $WORKSPACE/EmulatorPkg/EmulatorPkg.dsc $BUILD_OPTIONS -a $PROCESSOR -b $BUILDTARGET -t $HOST_TOOLS -D BUILD_$ARCH_SIZE -D UNIX_SEC_BUILD -D SKIP_MAIN_BUILD -n 3 modules EmulatorPkg/build.sh:268: build -p $WORKSPACE/EmulatorPkg/EmulatorPkg.dsc $BUILD_OPTIONS -a $PROCESSOR -b $BUILDTARGET -t $TARGET_TOOLS -D BUILD_$ARCH_SIZE $NETWORK_SUPPORT $BUILD_NEW_SHELL $BUILD_FAT -n 3 OvmfPkg/README:48:under the $WORKSPACE/Build/*/*/FV directory. The actual path will OvmfPkg/README:179:- Install the drivers into a directory called Intel3.5 in your WORKSPACE. OvmfPkg/ResetVector/ResetVector.inf:36: *_*_IA32_NASMB_FLAGS = -I$(WORKSPACE)/UefiCpuPkg/ResetVector/Vtf0/ OvmfPkg/ResetVector/ResetVector.inf:37: *_*_X64_NASMB_FLAGS = -I$(WORKSPACE)/UefiCpuPkg/ResetVector/Vtf0/ OvmfPkg/build.sh:22:if [ -z $WORKSPACE ]
Re: [edk2] BaseTools features: multiple workspaces
On Aug 5, 2015, at 12:16 PM, Jordan Justen jordan.l.jus...@intel.com wrote: On 2015-08-05 07:06:46, Gao, Liming wrote: Tim gave another idea to define multiple source locations in Platform DSC file. It doesn't conflict with this proposal. We can implement $(WORKSPACE_MULTIPLE) feature first, and evaluate DSC update. On the fixed tree layout, these two solutions can work. Once the end user reorganizes its tree layout, he needs to set $(WORKSPACE_MULTIPLE) env or update Platform DSC file, and build platform DSC. At one point Mike suggested updating target.txt to be able to add paths. I think this might be better than hard coding them into the dsc (source code) files. Tim, any thoughts on this? I’m not Tim, but PLEASE NOOO!! We don’t want “one tree per product”, we want multiple products per tree. target.txt is really helpful if you want to save typing on the command line, but that is about it. Now I have seen some vendors that do sill stuff like write a script that patches target.txt and then calls build.exe. I say silly as the script could have just passed the arguments build.exe directly, as target.txt is just the default value for the args of the build command. Thanks, Andrew Fish -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] BaseTools features: multiple workspaces
Agree with Andrew. Tim -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Andrew Fish Sent: Wednesday, August 05, 2015 1:22 PM To: Jordan Justen jordan.l.jus...@intel.com Cc: Paolo Bonzini pbonz...@redhat.com; edk2-devel@lists.01.org; Laszlo Ersek ler...@redhat.com; Tim Lewis tim.le...@insyde.com; Gao, Liming liming@intel.com Subject: Re: [edk2] BaseTools features: multiple workspaces On Aug 5, 2015, at 12:16 PM, Jordan Justen jordan.l.jus...@intel.com wrote: On 2015-08-05 07:06:46, Gao, Liming wrote: Tim gave another idea to define multiple source locations in Platform DSC file. It doesn't conflict with this proposal. We can implement $(WORKSPACE_MULTIPLE) feature first, and evaluate DSC update. On the fixed tree layout, these two solutions can work. Once the end user reorganizes its tree layout, he needs to set $(WORKSPACE_MULTIPLE) env or update Platform DSC file, and build platform DSC. At one point Mike suggested updating target.txt to be able to add paths. I think this might be better than hard coding them into the dsc (source code) files. Tim, any thoughts on this? I’m not Tim, but PLEASE NOOO!! We don’t want “one tree per product”, we want multiple products per tree. target.txt is really helpful if you want to save typing on the command line, but that is about it. Now I have seen some vendors that do sill stuff like write a script that patches target.txt and then calls build.exe. I say silly as the script could have just passed the arguments build.exe directly, as target.txt is just the default value for the args of the build command. Thanks, Andrew Fish -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 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] BaseTools features: multiple workspaces
On Aug 5, 2015, at 2:36 PM, Jordan Justen jordan.l.jus...@intel.com wrote: On 2015-08-05 12:51:47, Andrew Fish wrote: On Aug 5, 2015, at 12:40 PM, Jordan Justen jordan.l.jus...@intel.com wrote: Unless we do something about most of those references then WORKSPACE will have to be set to your 'edk2' tree. Therefore your Conf files must exist in your edk2 tree, and your build output must exist in your edk2 tree, and BaseTools must exist in your edk2 tree. Sorry I'm not following. In our local hack we do something like. What I meant is what if I want to have Build, Conf, BaseTools and package source code come from different directories. For example: Build: ~/udk/build Conf: /usr/lib/udk/2014/conf BaseTools: /usr/lib/udk/2014/bin udk packages: /usr/lib/udk/2014/src platform packages: ~/udk/platform and, the same platform should be buildable on windows: Build: C:\src\udk\build Conf: C:\udk\2014\conf BaseTools: C:\udk\2014\bin udk packages: C:\udk\2014\src platform packages: C:\src\udk\platform BaseTools/ - edk2 tools BuildResults/ - Build output edk2/ - Open source edk2 stuff Vendor/ - code from vendors, that is usually rooted in $(WORKSPACE). It doesn't seem like $WORKSPACE/EmulatorPkg exists. Since we've broken $WORKSPACE/EmulatorPkg and the like, making $WORKSPACE a path list doesn't break things further. So we set WORKSPACE_MULTIPLE = WORKSPACE/edk2;WORKSPACE/Vendor/Alpha;WORKSPACE/Vendor/Beta and we are good. Thus you can : Move the edk2/ code to any location you want down stream of WORKSPACE BuildResults is defined in DSC so it can be any location you want down stream of WORKSPACE. I take your feedback here and what I see is that you think of WORKSPACE more as the place where BaseTools, Build and Conf live, and less about where EDK II packages live. This is opposite of me, as I generally think of WORKSPACE as the place where EDK II package code lives. That's fine. I can adjust my thinking and abandon the notion that WORKSPACE refers to package source code. What if we instead add a new PACKAGES_PATH list, rather than WORKSPACE_MULTIPLE? At least it sounds better (terminology-wise) to me. I don’t have an issue shifting the name to PACKAGES_PATH if that helps folks figure out what we are trying to accomplish. Thanks, Andrew Fish -Jordan ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] BaseTools features: multiple workspaces
On 2015-08-05 13:21:37, Andrew Fish wrote: On Aug 5, 2015, at 12:16 PM, Jordan Justen jordan.l.jus...@intel.com wrote: On 2015-08-05 07:06:46, Gao, Liming wrote: Tim gave another idea to define multiple source locations in Platform DSC file. It doesn't conflict with this proposal. We can implement $(WORKSPACE_MULTIPLE) feature first, and evaluate DSC update. On the fixed tree layout, these two solutions can work. Once the end user reorganizes its tree layout, he needs to set $(WORKSPACE_MULTIPLE) env or update Platform DSC file, and build platform DSC. At one point Mike suggested updating target.txt to be able to add paths. I think this might be better than hard coding them into the dsc (source code) files. Tim, any thoughts on this? I’m not Tim, but PLEASE NOOO!! We don’t want “one tree per product”, we want multiple products per tree. target.txt is really helpful if you want to save typing on the command line, but that is about it. I happen to agree. I haven't used target.txt in years. I love being able to run these two commands easily in the same tree: $ OvmfPkg/build.sh $ EmulatorPkg/build.sh If anything, I'd like to see us make the Conf directory optional. (And use BaseTools/Conf by default.) Now I have seen some vendors that do sill stuff like write a script that patches target.txt and then calls build.exe. I say silly as the script could have just passed the arguments build.exe directly, as target.txt is just the default value for the args of the build command. Apparently we have a 'TargetTool' that helps with this? Who knew? (Not I ... seriously.) Anyway, I'm just responding to not wanting to bake hard coded package paths into the .dsc. Not that I like target.txt. :) -Jordan ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch] ShellPkg: Fix issue about ping fail with IPv4
Reviewed-by: Fu Siyuan siyuan...@intel.com
-Original Message-
From: Wu, Jiaxin
Sent: Thursday, August 06, 2015 12:08 PM
To: edk2-devel@lists.01.org
Cc: Fu, Siyuan; Ye, Ting
Subject: [Patch] ShellPkg: Fix issue about ping fail with IPv4
Fix issue about ping fail with IPv4, which is caused by the incorrect checksum
in request message.
Cc: Fu Siyuan siyuan...@intel.com
Cc: Ye Ting ting...@intel.com
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiaxin Wu jiaxin...@intel.com
---
ShellPkg/Library/UefiShellNetwork1CommandsLib/Ping.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/ShellPkg/Library/UefiShellNetwork1CommandsLib/Ping.c
b/ShellPkg/Library/UefiShellNetwork1CommandsLib/Ping.c
index 643be23..cc3c0c3 100644
--- a/ShellPkg/Library/UefiShellNetwork1CommandsLib/Ping.c
+++ b/ShellPkg/Library/UefiShellNetwork1CommandsLib/Ping.c
@@ -596,19 +596,19 @@ PingGenerateToken (
//
// Assembly echo request packet.
//
Request-Type=
(UINT8)(Private-IpChoice==PING_IP_CHOICE_IP6?ICMP_V6_ECHO_REQUEST:ICMP_V4_ECHO_REQUEST);
Request-Code= 0;
- Request-SequenceNum = SequenceNum;
- Request-TimeStamp = TimeStamp;
+ Request-SequenceNum = SequenceNum;
Request-Identifier = 0;
Request-Checksum= 0;
//
// Assembly token for transmit.
//
if (Private-IpChoice==PING_IP_CHOICE_IP6) {
+Request-TimeStamp = TimeStamp;
((EFI_IP6_TRANSMIT_DATA*)TxData)-ExtHdrsLength = 0;
((EFI_IP6_TRANSMIT_DATA*)TxData)-ExtHdrs = NULL;
((EFI_IP6_TRANSMIT_DATA*)TxData)-OverrideData= 0;
((EFI_IP6_TRANSMIT_DATA*)TxData)-DataLength =
Private-BufferSize;
((EFI_IP6_TRANSMIT_DATA*)TxData)-FragmentCount = 1;
@@ -626,10 +626,11 @@ PingGenerateToken (
((EFI_IP4_TRANSMIT_DATA*)TxData)-DestinationAddress.Addr[1] =
Private-DstAddress[1];
((EFI_IP4_TRANSMIT_DATA*)TxData)-DestinationAddress.Addr[2] =
Private-DstAddress[2];
((EFI_IP4_TRANSMIT_DATA*)TxData)-DestinationAddress.Addr[3] =
Private-DstAddress[3];
HeadSum = NetChecksum ((UINT8 *) Request, Private-BufferSize);
+Request-TimeStamp = TimeStamp;
TempChecksum = NetChecksum ((UINT8 *) Request-TimeStamp, sizeof
(UINT64));
Request-Checksum = (UINT16)(~NetAddChecksum (HeadSum, TempChecksum));
}
--
1.9.5.msysgit.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Error on executing shell command ifconfig
Did you use the default shell in ShellBinPkg? If so, you should rebuild latest shell in ShellPkg. Thanks. Jiaxin -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ye, Ting Sent: Thursday, August 6, 2015 8:26 AM To: Sharma Bhupesh; edk2-devel@lists.01.org; Leekha Shaveta Subject: Re: [edk2] Error on executing shell command ifconfig Do you know whether the LanIntelE1000Dxe works properly? You may type drivers in shell to check connecting status of UEFI network drivers. Best Regards, Ye Ting -Original Message- From: Sharma Bhupesh [mailto:bhupesh.sha...@freescale.com] Sent: Wednesday, August 05, 2015 6:43 PM To: Ye, Ting; edk2-devel@lists.01.org; Leekha Shaveta Subject: RE: Error on executing shell command ifconfig Hi Ye Ting, Thanks for your inputs. I tried adding the same as well and the following packages are now being added to the .dsc file: # # Networking stack # MdeModulePkg/Universal/Network/SnpDxe/SnpDxe.inf MdeModulePkg/Universal/Network/DpcDxe/DpcDxe.inf MdeModulePkg/Universal/Network/MnpDxe/MnpDxe.inf MdeModulePkg/Universal/Network/VlanConfigDxe/VlanConfigDxe.inf MdeModulePkg/Universal/Network/ArpDxe/ArpDxe.inf MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Dxe.inf MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Dxe.inf MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4ConfigDxe.inf MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Dxe.inf MdeModulePkg/Universal/Network/Udp4Dxe/Udp4Dxe.inf MdeModulePkg/Universal/Network/Tcp4Dxe/Tcp4Dxe.inf MdeModulePkg/Universal/Network/UefiPxeBcDxe/UefiPxeBcDxe.inf MdeModulePkg/Universal/Network/IScsiDxe/IScsiDxe.inf Also e1000/NIC card driver's efi is getting loaded . # Intel E1000 driver INF LS1043aRdbPkg/Drivers/LanIntelE1000Dxe/LanIntelE1000Dxe.inf Still I am getting same error: Shell ifconfig -l Error. The protocol 'gEfiIp4ConfigProtocolGuid' was required and not found (3B95AA31-3793-434B-8667-C8070892E05E). Can it be related to shell source/version? Or Lan/NIC/E1000 card driver? Any hints would be helpful. Regards, Bhupesh -Original Message- From: Ye, Ting [mailto:ting...@intel.com] Sent: Wednesday, August 05, 2015 2:14 PM To: Sharma Bhupesh-B45370; edk2-devel@lists.01.org; Leekha Shaveta-B20052 Subject: RE: Error on executing shell command ifconfig It looks SNP driver is missing. MdeModulePkg\Universal\Network\SnpDxe\SnpDxe.inf Best Regards, Ye Ting -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Sharma Bhupesh Sent: Wednesday, August 05, 2015 4:36 PM To: edk2-devel@lists.01.org; Leekha Shaveta Subject: [edk2] Error on executing shell command ifconfig Hi, I was trying to add Network stack in UEFI for a FSL SoC in order to run ping and ifconfig commands. For this I have added following inf in my fdf file: # Networking stack # INF MdeModulePkg/Universal/Network/DpcDxe/DpcDxe.inf INF MdeModulePkg/Universal/Network/ArpDxe/ArpDxe.inf INF MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Dxe.inf INF MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4ConfigDxe.inf INF MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Dxe.inf INF MdeModulePkg/Universal/Network/MnpDxe/MnpDxe.inf INF MdeModulePkg/Universal/Network/VlanConfigDxe/VlanConfigDxe.inf INF MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Dxe.inf INF MdeModulePkg/Universal/Network/Tcp4Dxe/Tcp4Dxe.inf INF MdeModulePkg/Universal/Network/Udp4Dxe/Udp4Dxe.inf INF MdeModulePkg/Universal/Network/UefiPxeBcDxe/UefiPxeBcDxe.inf INF MdeModulePkg/Universal/Network/IScsiDxe/IScsiDxe.inf # Intel E1000 driver INF LS1043aRdbPkg/Drivers/LanIntelE1000Dxe/LanIntelE1000Dxe.inf Also added required NetLib, DcpLib, and Protocol Guids. But when I run ifconfig -l command, I get following error: Shell ifconfig -l Error. The protocol 'gEfiIp4ConfigProtocolGuid' was required and not found (3B95AA31-3793-434B-8667-C8070892E05E). Also ping command is not showing anything Shell ping 192.168.1.15 Shell ping 192.168.1.15 Is something missed here? Thanks and Regards, Bhupesh ___ 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
[edk2] [PATCH 1/2] ShellPkg: Fix build failure in VS2015.
Initialize local variable before it is passed into a function by reference.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Kinney, Michael D michael.d.kin...@intel.com
Reviewed-by: Qiu Shumin shumin@intel.com
---
ShellPkg/Library/UefiShellDriver1CommandsLib/DrvCfg.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/ShellPkg/Library/UefiShellDriver1CommandsLib/DrvCfg.c
b/ShellPkg/Library/UefiShellDriver1CommandsLib/DrvCfg.c
index 7b5cca5..27b8873 100644
--- a/ShellPkg/Library/UefiShellDriver1CommandsLib/DrvCfg.c
+++ b/ShellPkg/Library/UefiShellDriver1CommandsLib/DrvCfg.c
@@ -2,7 +2,7 @@
Main file for DrvCfg shell Driver1 function.
(C) Copyright 2015 Hewlett-Packard Development Company, L.P.BR
- Copyright (c) 2010 - 2014, Intel Corporation. All rights reserved.BR
+ Copyright (c) 2010 - 2015, Intel Corporation. All rights reserved.BR
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
@@ -207,6 +207,7 @@ ConfigToFile(
return (SHELL_NOT_FOUND);
}
+ HiiHandle = NULL;
Status = ConvertHandleToHiiHandle(Handle, HiiHandle, HiiDatabase);
if (EFI_ERROR(Status)) {
ShellPrintHiiEx(
--
1.9.5.msysgit.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [Patch] ShellPkg: Fix issue about ping fail with IPv4
Fix issue about ping fail with IPv4, which is caused by the incorrect
checksum in request message.
Cc: Fu Siyuan siyuan...@intel.com
Cc: Ye Ting ting...@intel.com
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiaxin Wu jiaxin...@intel.com
---
ShellPkg/Library/UefiShellNetwork1CommandsLib/Ping.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/ShellPkg/Library/UefiShellNetwork1CommandsLib/Ping.c
b/ShellPkg/Library/UefiShellNetwork1CommandsLib/Ping.c
index 643be23..cc3c0c3 100644
--- a/ShellPkg/Library/UefiShellNetwork1CommandsLib/Ping.c
+++ b/ShellPkg/Library/UefiShellNetwork1CommandsLib/Ping.c
@@ -596,19 +596,19 @@ PingGenerateToken (
//
// Assembly echo request packet.
//
Request-Type=
(UINT8)(Private-IpChoice==PING_IP_CHOICE_IP6?ICMP_V6_ECHO_REQUEST:ICMP_V4_ECHO_REQUEST);
Request-Code= 0;
- Request-SequenceNum = SequenceNum;
- Request-TimeStamp = TimeStamp;
+ Request-SequenceNum = SequenceNum;
Request-Identifier = 0;
Request-Checksum= 0;
//
// Assembly token for transmit.
//
if (Private-IpChoice==PING_IP_CHOICE_IP6) {
+Request-TimeStamp = TimeStamp;
((EFI_IP6_TRANSMIT_DATA*)TxData)-ExtHdrsLength = 0;
((EFI_IP6_TRANSMIT_DATA*)TxData)-ExtHdrs = NULL;
((EFI_IP6_TRANSMIT_DATA*)TxData)-OverrideData= 0;
((EFI_IP6_TRANSMIT_DATA*)TxData)-DataLength =
Private-BufferSize;
((EFI_IP6_TRANSMIT_DATA*)TxData)-FragmentCount = 1;
@@ -626,10 +626,11 @@ PingGenerateToken (
((EFI_IP4_TRANSMIT_DATA*)TxData)-DestinationAddress.Addr[1] =
Private-DstAddress[1];
((EFI_IP4_TRANSMIT_DATA*)TxData)-DestinationAddress.Addr[2] =
Private-DstAddress[2];
((EFI_IP4_TRANSMIT_DATA*)TxData)-DestinationAddress.Addr[3] =
Private-DstAddress[3];
HeadSum = NetChecksum ((UINT8 *) Request, Private-BufferSize);
+Request-TimeStamp = TimeStamp;
TempChecksum = NetChecksum ((UINT8 *) Request-TimeStamp, sizeof
(UINT64));
Request-Checksum = (UINT16)(~NetAddChecksum (HeadSum, TempChecksum));
}
--
1.9.5.msysgit.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] MdeModulePkg DxeIpl: Add stack NX support
I am working on that. One thing is strange that StartupAllAPs is working well with my qemu by OVMF and even real machine. Anyway, there is mismatch between BSP and AP when PcdSetNxForStack is TRUE. As BSP and AP share same page table, 0xC080 has BIT11 set for BSP, AP needs to sync up the setting in CpuMp. I will come up a patch for that. Thanks, Star -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo Ersek Sent: Thursday, August 6, 2015 12:28 AM To: Andrew Fish Cc: Justen, Jordan L; edk2-de...@ml01.01.org; Yao, Jiewen; Chen Fan; Paolo Bonzini; Fan, Jeff; Zeng, Star Subject: Re: [edk2] [PATCH] MdeModulePkg DxeIpl: Add stack NX support On 08/05/15 18:18, Andrew Fish wrote: On Aug 5, 2015, at 8:41 AM, Laszlo Ersek ler...@redhat.com mailto:ler...@redhat.com wrote: On 07/31/15 14:22, Star Zeng wrote: This feature is added for UEFI spec that says Stack may be marked as non-executable in identity mapped page tables. A PCD PcdSetNxForStack is added to turn on/off this feature, and it is FALSE by default. Cc: Jiewen Yao jiewen@intel.com mailto:jiewen@intel.com Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng star.z...@intel.com mailto:star.z...@intel.com --- MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf | 3 +- MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c | 185 ++- MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c | 10 +- MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c | 160 +--- MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.h | 61 +++- MdeModulePkg/MdeModulePkg.dec| 11 +- MdeModulePkg/MdeModulePkg.uni| Bin 166792 - 168862 bytes 7 files changed, 392 insertions(+), 38 deletions(-) I tried to enable this feature in the OvmfPkg builds (all three of them). Good thing it is a PCD flag. I thought the same :) Unfortunately, I have found that a non-executable DXE stack breaks the EFI_MP_SERVICE_PROTOCOL.StartupAllAPs() function. (Which is provided by UefiCpuPkg/CpuDxe/CpuMp.c.) The virtual machine is re-set when that function is called. I would think it would just be the BSP stack that is set to NX. This could be a bug in the code, as the AP’s run off a different stack that is not NX, and it looks like the code gets copied to BootServices, and the AP startup code in ACPI NVS memory? I hope the respective package maintainers / feature developers will seize the opportunity to investigate this! :) I have the interest, but not the time, to dig into it right now. Thanks! Laszlo Thanks, Andrew Fish I presume the starup code for the APs resides in an area that happens to be marked non-executable (if this feature enabled), and that causes a fatal fault or some such when the APs get the startup IPI. Thanks Laszlo ___ edk2-devel mailing list edk2-devel@lists.01.org mailto: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] BaseTools features: multiple workspaces
On Aug 5, 2015, at 2:46 PM, Jordan Justen jordan.l.jus...@intel.com wrote: On 2015-08-05 13:21:37, Andrew Fish wrote: On Aug 5, 2015, at 12:16 PM, Jordan Justen jordan.l.jus...@intel.com wrote: On 2015-08-05 07:06:46, Gao, Liming wrote: Tim gave another idea to define multiple source locations in Platform DSC file. It doesn't conflict with this proposal. We can implement $(WORKSPACE_MULTIPLE) feature first, and evaluate DSC update. On the fixed tree layout, these two solutions can work. Once the end user reorganizes its tree layout, he needs to set $(WORKSPACE_MULTIPLE) env or update Platform DSC file, and build platform DSC. At one point Mike suggested updating target.txt to be able to add paths. I think this might be better than hard coding them into the dsc (source code) files. Tim, any thoughts on this? I’m not Tim, but PLEASE NOOO!! We don’t want “one tree per product”, we want multiple products per tree. target.txt is really helpful if you want to save typing on the command line, but that is about it. I happen to agree. I haven't used target.txt in years. I love being able to run these two commands easily in the same tree: $ OvmfPkg/build.sh $ EmulatorPkg/build.sh If anything, I'd like to see us make the Conf directory optional. (And use BaseTools/Conf by default.) Now I have seen some vendors that do sill stuff like write a script that patches target.txt and then calls build.exe. I say silly as the script could have just passed the arguments build.exe directly, as target.txt is just the default value for the args of the build command. Apparently we have a 'TargetTool' that helps with this? Who knew? (Not I ... seriously.) Anyway, I'm just responding to not wanting to bake hard coded package paths into the .dsc. It works well if you are moving things about under the existing WORKSPACE, like my example. You are basically just adding directory structure to the flat edk2 convention for packages. That is the use case that I, and I think Tim, care about the most. Thanks, Andrew Fish Not that I like target.txt. :) -Jordan ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] efi acpidump port
By the way, here it is on my personal github. Repo page URL: https://github.com/jnthsmth/edk2/tree/master/AcpicaPkg Clone URL: g...@github.com:jnthsmth/edk2.git Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jonathan Smith jonathan.d.sm...@intel.com Yay process. -Original Message- From: Laszlo Ersek [mailto:ler...@redhat.com] Sent: Thursday, July 30, 2015 7:59 AM To: Andrew Fish; Justen, Jordan L Cc: edk2-devel@lists.01.org; Smith, Jonathan D; Agyeman, Prince Subject: Re: [edk2] efi acpidump port On 07/30/15 01:27, Andrew Fish wrote: On Jul 29, 2015, at 4:11 PM, Jordan Justen jordan.l.jus...@intel.com wrote: On 2015-07-29 13:43:43, Smith, Jonathan D wrote: Attaching a zip of the files -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Smith, Jonathan D Sent: Wednesday, July 29, 2015 1:37 PM To: 'Andrew Fish'; 'edk2-devel@lists.01.org mailto:edk2-devel@lists.01.org' Subject: Re: [edk2] efi acpidump port Hi all, Let me know if the attachments to this message do not show up. I’ve elaborated the build metadata, reduced the ACPICA changes (moving alterations into additional files as needed), and verified that the compiled AcpicaPkg provides a correct implementation of acpidump that works for Minnow. To set up the EDK2 AcpicaPkg from the ACPICA sources: 1.) Go to https://acpica.org/downloads https://acpica.org/downloads and download aspia-unix-20150619.tarhttps://acpica.org/downloads%20and%20downloa d%20aspia-unix-20150619.tar https://acpica.org/downloads%20and%20download%20aspia-unix-20150619 .tar 2.) Extract the tar and put it in the root of edk2 as AcpicaPkg 3.) Apply acenv.patch to edk2\AcpicaPkg\source\include\platform\acenv.h or just add the two lines manually. 4.) Add the files AcpicaPkg.dec, AcpicaPkg.dsc, acpidump.inf, and acpi_main.c to the dir edk2\AcpicaPkg 5.) Add the file acedk2efi.h to the dir edk2\AcpicaPkg\source\include\platform This seems a little silly. Like the Intel email server removing the INF from the zip file? Seems silly to make a branch to add a single package. How do you add a subproject? Like the FatPkg? Forking off a branch in git is the cheapest thing one can do, for whatever development. The branch exists only in one's local git repo at that point, of course. Then, for sharing it with others, the branch can be pushed to another (public) repo, assuming the permissions are in place, eg. to one owned by the developer on github. Then others can fetch that branch if they'd like to play with it. One way to think about a git repo is commit store. It just holds commits, where each commit is cryptographically linked to (usually) one parent commit (more parents if the commit is a merge). Some commits are referenced by branch names. Pushing and pulling a branch is (conceptually) just (a) tossing around the exact commit that the branch points at, along with the branch name itself, and (b) making sure that all ancestors of the commit, recursively, exist on the recipient side too. Point (b) usually involves uploading a number of intermediary commits, in case of push, and downloading the same, in case of fetch. Commits that both sender and recipient repositories already share are not transferred. This suffices for the commit that is identified by the branch name being pushed or pulled to be *connected* in the recipient repository as well. Thanks Laszlo Thanks, Andrew Fish Maybe you can just fork edk2, make the required changes and provide a link to your branch? https://github.com/tianocore/edk2 https://github.com/tianocore/edk2 Also, what about 'Contributed-under'? (MdePkg/Contributions.txt) By the way, I think Prince (Cc'd) did a port of acpidump in the past, but never tried to release it externally. -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 0/9] OvmfPkg, ArmVirtPkg: SMBIOS 3.0, round 2
Series Reviewed-by: Jordan Justen jordan.l.jus...@intel.com On 2015-07-31 11:40:52, Laszlo Ersek wrote: The SMBIOS 3.x entry point is structurally different from the 2.x variant, therefore the current code used by OvmfPkg and ArmVirtPkg doesn't recognize an SMBIOS 3.0 entry point structure even if QEMU exports one. This series rectifies that. The first four patches implement Jordan's great idea: they refactor the code without any observable changes, unifying the currently duplicated QEMU SMBIOS entry point checks / version setting between OvmfPkg and ArmVirtPkg. Patches 5 to 7, inclusive, eliminate yet another instance of the entry point checks, this time the last one, from SmbiosPlatformDxe. Building on the centralized QEMU SMBIOS entry point examination, patches 8 and 9 add SMBIOS 3.0 support for real. The series builds at every stage. I regression-tested it with OVMF (2.8 entry point), and tested the 3.0 entry point support using Wei's QEMU series pending at http://thread.gmane.org/gmane.comp.emulators.qemu/353282, with a small QEMU fix on top (which I posted in that thread). As I wrote in that thread as well, I didn't test with dmidecode in an aarch64 Linux guest just yet; I used the smbiosview UEFI shell command in the guest. Public branch: https://github.com/lersek/edk2/commits/smbios30_round2. Wei, you can find a binary at http://people.redhat.com/~lersek/smbios30_round2_v1/QEMU_EFI.fd.xz, for testing any further QEMU changes. Cc: Ard Biesheuvel ard.biesheu...@linaro.org Cc: Wei Huang w...@redhat.com Cc: Jordan Justen jordan.l.jus...@intel.com Cc: Gabriel L. Somlo so...@cmu.edu Thanks Laszlo Laszlo Ersek (9): OvmfPkg: SmbiosVersionLib: add plugin for detecting SMBIOS version OvmfPkg: set SMBIOS version in DetectSmbiosVersionLib instead of PlatformPei ArmVirtPkg: set SMBIOS version in DetectSmbiosVersionLib instead of QemuFwCfgToPcdDxe ArmVirtPkg: revert ArmVirtPkg: add QemuFwCfgToPcdDxe OvmfPkg: introduce PcdQemuSmbiosValidated ArmVirtPkg/ArmVirtQemu.dsc: set default for PcdQemuSmbiosValidated OvmfPkg: SmbiosPlatformDxe: eliminate duplicate entry point validation ArmVirtPkg: set default for PcdSmbiosDocRev OvmfPkg: SmbiosVersionLib: recognize SMBIOS 3.x entry point ArmVirtPkg/ArmVirtQemu.dsc | 8 +- ArmVirtPkg/ArmVirtQemu.fdf | 2 - ArmVirtPkg/QemuFwCfgToPcdDxe/QemuFwCfgToPcd.c | 73 - ArmVirtPkg/QemuFwCfgToPcdDxe/QemuFwCfgToPcd.inf | 46 - OvmfPkg/Library/SmbiosVersionLib/DetectSmbiosVersionLib.c | 107 OvmfPkg/Library/SmbiosVersionLib/DetectSmbiosVersionLib.inf | 53 ++ OvmfPkg/OvmfPkg.dec | 1 + OvmfPkg/OvmfPkgIa32.dsc | 7 +- OvmfPkg/OvmfPkgIa32X64.dsc | 7 +- OvmfPkg/OvmfPkgX64.dsc | 7 +- OvmfPkg/PlatformPei/Platform.c | 39 --- OvmfPkg/PlatformPei/PlatformPei.inf | 2 - OvmfPkg/SmbiosPlatformDxe/Qemu.c| 30 ++ OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.inf | 4 + 14 files changed, 198 insertions(+), 188 deletions(-) create mode 100644 OvmfPkg/Library/SmbiosVersionLib/DetectSmbiosVersionLib.c create mode 100644 OvmfPkg/Library/SmbiosVersionLib/DetectSmbiosVersionLib.inf delete mode 100644 ArmVirtPkg/QemuFwCfgToPcdDxe/QemuFwCfgToPcd.c delete mode 100644 ArmVirtPkg/QemuFwCfgToPcdDxe/QemuFwCfgToPcd.inf -- 1.8.3.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Error on executing shell command ifconfig
Do you know whether the LanIntelE1000Dxe works properly? You may type drivers in shell to check connecting status of UEFI network drivers. Best Regards, Ye Ting -Original Message- From: Sharma Bhupesh [mailto:bhupesh.sha...@freescale.com] Sent: Wednesday, August 05, 2015 6:43 PM To: Ye, Ting; edk2-devel@lists.01.org; Leekha Shaveta Subject: RE: Error on executing shell command ifconfig Hi Ye Ting, Thanks for your inputs. I tried adding the same as well and the following packages are now being added to the .dsc file: # # Networking stack # MdeModulePkg/Universal/Network/SnpDxe/SnpDxe.inf MdeModulePkg/Universal/Network/DpcDxe/DpcDxe.inf MdeModulePkg/Universal/Network/MnpDxe/MnpDxe.inf MdeModulePkg/Universal/Network/VlanConfigDxe/VlanConfigDxe.inf MdeModulePkg/Universal/Network/ArpDxe/ArpDxe.inf MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Dxe.inf MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Dxe.inf MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4ConfigDxe.inf MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Dxe.inf MdeModulePkg/Universal/Network/Udp4Dxe/Udp4Dxe.inf MdeModulePkg/Universal/Network/Tcp4Dxe/Tcp4Dxe.inf MdeModulePkg/Universal/Network/UefiPxeBcDxe/UefiPxeBcDxe.inf MdeModulePkg/Universal/Network/IScsiDxe/IScsiDxe.inf Also e1000/NIC card driver's efi is getting loaded . # Intel E1000 driver INF LS1043aRdbPkg/Drivers/LanIntelE1000Dxe/LanIntelE1000Dxe.inf Still I am getting same error: Shell ifconfig -l Error. The protocol 'gEfiIp4ConfigProtocolGuid' was required and not found (3B95AA31-3793-434B-8667-C8070892E05E). Can it be related to shell source/version? Or Lan/NIC/E1000 card driver? Any hints would be helpful. Regards, Bhupesh -Original Message- From: Ye, Ting [mailto:ting...@intel.com] Sent: Wednesday, August 05, 2015 2:14 PM To: Sharma Bhupesh-B45370; edk2-devel@lists.01.org; Leekha Shaveta-B20052 Subject: RE: Error on executing shell command ifconfig It looks SNP driver is missing. MdeModulePkg\Universal\Network\SnpDxe\SnpDxe.inf Best Regards, Ye Ting -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Sharma Bhupesh Sent: Wednesday, August 05, 2015 4:36 PM To: edk2-devel@lists.01.org; Leekha Shaveta Subject: [edk2] Error on executing shell command ifconfig Hi, I was trying to add Network stack in UEFI for a FSL SoC in order to run ping and ifconfig commands. For this I have added following inf in my fdf file: # Networking stack # INF MdeModulePkg/Universal/Network/DpcDxe/DpcDxe.inf INF MdeModulePkg/Universal/Network/ArpDxe/ArpDxe.inf INF MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Dxe.inf INF MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4ConfigDxe.inf INF MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Dxe.inf INF MdeModulePkg/Universal/Network/MnpDxe/MnpDxe.inf INF MdeModulePkg/Universal/Network/VlanConfigDxe/VlanConfigDxe.inf INF MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Dxe.inf INF MdeModulePkg/Universal/Network/Tcp4Dxe/Tcp4Dxe.inf INF MdeModulePkg/Universal/Network/Udp4Dxe/Udp4Dxe.inf INF MdeModulePkg/Universal/Network/UefiPxeBcDxe/UefiPxeBcDxe.inf INF MdeModulePkg/Universal/Network/IScsiDxe/IScsiDxe.inf # Intel E1000 driver INF LS1043aRdbPkg/Drivers/LanIntelE1000Dxe/LanIntelE1000Dxe.inf Also added required NetLib, DcpLib, and Protocol Guids. But when I run ifconfig -l command, I get following error: Shell ifconfig -l Error. The protocol 'gEfiIp4ConfigProtocolGuid' was required and not found (3B95AA31-3793-434B-8667-C8070892E05E). Also ping command is not showing anything Shell ping 192.168.1.15 Shell ping 192.168.1.15 Is something missed here? Thanks and Regards, Bhupesh ___ 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
