2016-12-06 15:21:17 +00:00
|
|
|
DESCRIPTION = "OVMF - UEFI firmware for Qemu and KVM"
|
|
|
|
HOMEPAGE = "http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OVMF"
|
|
|
|
LICENSE = "BSD"
|
2016-12-20 07:47:21 +00:00
|
|
|
LICENSE_class-target = "${@bb.utils.contains('PACKAGECONFIG', 'secureboot', 'BSD & OpenSSL', 'BSD', d)}"
|
2016-12-06 15:21:17 +00:00
|
|
|
LIC_FILES_CHKSUM = "file://OvmfPkg/License.txt;md5=343dc88e82ff33d042074f62050c3496"
|
|
|
|
|
2016-12-20 07:47:21 +00:00
|
|
|
# Enabling Secure Boot adds a dependency on OpenSSL and implies
|
|
|
|
# compiling OVMF twice, so it is disabled by default. Distros
|
|
|
|
# may change that default.
|
|
|
|
PACKAGECONFIG ??= ""
|
|
|
|
PACKAGECONFIG[secureboot] = ",,,"
|
|
|
|
|
2016-12-06 15:21:17 +00:00
|
|
|
SRC_URI = "git://github.com/tianocore/edk2.git;branch=master \
|
|
|
|
file://0002-ovmf-update-path-to-native-BaseTools.patch \
|
|
|
|
file://0003-BaseTools-makefile-adjust-to-build-in-under-bitbake.patch \
|
2017-02-23 17:38:55 +00:00
|
|
|
file://VfrCompile-increase-path-length-limit.patch \
|
2017-04-21 20:55:22 +00:00
|
|
|
file://0001-MdeModulePkg-UefiHiiLib-Fix-incorrect-comparison-exp.patch \
|
2018-02-24 20:51:48 +00:00
|
|
|
file://0001-VfrCompile-fix-invalid-comparison-between-pointer-an.patch \
|
2016-12-06 15:21:17 +00:00
|
|
|
"
|
|
|
|
|
2016-12-20 07:47:21 +00:00
|
|
|
SRC_URI_append_class-target = " \
|
|
|
|
${@bb.utils.contains('PACKAGECONFIG', 'secureboot', 'http://www.openssl.org/source/openssl-1.0.2j.tar.gz;name=openssl;subdir=${S}/CryptoPkg/Library/OpensslLib', '', d)} \
|
ovmf: build image which enrolls standard keys
When booting a qemu virtual machine with ovmf.secboot, it comes up
with no keys installed and thus Secure Boot disabled. To lock down
the machine like a typical PC, one has to enroll the same keys
that PC vendors normally install, i.e. the ones from Microsoft.
This can be done manually (see
https://wiki.ubuntu.com/SecurityTeam/SecureBoot and
https://github.com/tianocore-docs/Docs/raw/master/White_Papers/A_Tour_Beyond_BIOS_into_UEFI_Secure_Boot_White_Paper.pdf) or automatically with the EnrollDefaultKeys.efi helper
from the Fedora ovmf rpm.
To use this with qemu:
$ bitbake ovmf-shell-image
...
$ runqemu serial nographic qemux86 ovmf-shell-image wic ovmf.secboot
...
UEFI Interactive Shell v2.1
EDK II
UEFI v2.60 (EDK II, 0x00010000)
Mapping table
FS0: Alias(s):HD2b:;BLK4:
PciRoot(0x0)/Pci(0x5,0x0)/HD(1,GPT,06AEF759-3982-4AF6-B517-70BA6304FC1C,0x800,0x566C)
BLK0: Alias(s):
PciRoot(0x0)/Pci(0x1,0x0)/Floppy(0x0)
BLK1: Alias(s):
PciRoot(0x0)/Pci(0x1,0x0)/Floppy(0x1)
BLK2: Alias(s):
PciRoot(0x0)/Pci(0x1,0x1)/Ata(0x0)
BLK3: Alias(s):
PciRoot(0x0)/Pci(0x5,0x0)
Press ESC in 1 seconds to skip startup.nsh or any other key to continue.
Shell> fs0:EnrollDefaultKeys.efi
info: SetupMode=1 SecureBoot=0 SecureBootEnable=0 CustomMode=0 VendorKeys=1
info: SetupMode=0 SecureBoot=1 SecureBootEnable=1 CustomMode=0 VendorKeys=0
info: success
Shell> reset
Remember that this will modify
deploy/images/qemux86/ovmf.secboot.qcow2, so make a copy and use the
full path of that copy instead of the "ovmf" argument if needed.
The ovmf-shell-image contains an EFI shell, which is what got started
here directly. After enrolling the keys, Secure Boot is active and the
same image cannot be booted anymore, so the BIOS goes through the
normal boot targets (including network boot, which can take a while to
time out), and ends up in the internal EFI shell. Trying to invoke
bootia32.efi (the shell from the image) or EnrollDefaultKeys.efi then
fails:
Shell> bootia32.efi
Command Error Status: Security Violation
The main purpose at the moment is to test that Secure Boot enforcement
really works. If we had a way to sign generated images, that part could
also be tested by booting in a locked down qemu instance.
0007-OvmfPkg-EnrollDefaultKeys-application-for-enrolling-.patch is
from
https://src.fedoraproject.org/cgit/rpms/edk2.git/tree/0007-OvmfPkg-EnrollDefaultKeys-application-for-enrolling-.patch?id=b1781931894bf2057464e634beed68b1e3218c9e
with one line changed to fix
https://bugzilla.redhat.com/show_bug.cgi?id=132502:
"EFI_STATUS Status = EFI_SUCCESS;" in EnrollListOfX509Certs() lacked
the initializer.
(From OE-Core rev: 1913ace7d0898b5a23a2dbdc574ab1d8648927c5)
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-12-21 08:18:05 +00:00
|
|
|
file://0007-OvmfPkg-EnrollDefaultKeys-application-for-enrolling-.patch \
|
2016-12-20 07:47:21 +00:00
|
|
|
"
|
|
|
|
|
2016-12-06 15:21:17 +00:00
|
|
|
SRCREV="4575a602ca6072ee9d04150b38bfb143cbff8588"
|
2016-12-20 07:47:21 +00:00
|
|
|
SRC_URI[openssl.md5sum] = "96322138f0b69e61b7212bc53d5e912b"
|
|
|
|
SRC_URI[openssl.sha256sum] = "e7aff292be21c259c6af26469c7a9b3ba26e9abaaffd325e3dccc9785256c431"
|
2016-12-06 15:21:17 +00:00
|
|
|
|
2016-12-16 14:07:29 +00:00
|
|
|
inherit deploy
|
|
|
|
|
ovmf_git.bb: enable parallel compilation
The Fedora srpm [1] seems to have no problems with parallel
compilation, so let's also use that for the target. The native
tools however indeed have dependency problems:
| test_Ecc_CParser (CheckPythonSyntax.Tests) ... gcc -o ../bin/EfiRom -L/fast/build/ostro/x86/tmp-glibc/sysroots/x86_64-linux/usr/lib -L/fast/build/ostro/x86/tmp-glibc/sysroots/x86_64-linux/lib -Wl,-rpath-link,/fast/build/ostro/x86/tmp-glibc/sysroots/x86_64-linux/usr/lib -Wl,-rpath-link,/fast/build/ostro/x86/tmp-glibc/sysroots/x86_64-linux/lib -Wl,-rpath,/fast/build/ostro/x86/tmp-glibc/sysroots/x86_64-linux/usr/lib -Wl,-rpath,/fast/build/ostro/x86/tmp-glibc/sysroots/x86_64-linux/lib -Wl,-O1 EfiRom.o -L../libs -lCommon
| /usr/bin/ld: cannot find -lCommon
| collect2: error: ld returned 1 exit status
ERROR: Task (virtual:native:.../meta/recipes-core/ovmf/ovmf_git.bb:do_compile) failed with exit code '1'
[1] https://src.fedoraproject.org/cgit/rpms/edk2.git/tree/edk2.spec
(From OE-Core rev: be307609a067b7d23dc2cd8e39e3a35f770bebc7)
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-12-19 16:02:43 +00:00
|
|
|
PARALLEL_MAKE_class-native = ""
|
2016-12-06 15:21:17 +00:00
|
|
|
|
|
|
|
S = "${WORKDIR}/git"
|
|
|
|
|
2016-12-16 14:07:29 +00:00
|
|
|
DEPENDS_class-native="util-linux-native iasl-native ossp-uuid-native qemu-native"
|
2016-12-06 15:21:17 +00:00
|
|
|
|
|
|
|
DEPENDS_class-target="ovmf-native"
|
|
|
|
|
2016-12-16 09:19:31 +00:00
|
|
|
DEPENDS_append = " nasm-native"
|
|
|
|
|
2016-12-06 15:21:17 +00:00
|
|
|
EDK_TOOLS_DIR="edk2_basetools"
|
|
|
|
|
|
|
|
# OVMF has trouble building with the default optimization of -O2.
|
|
|
|
BUILD_OPTIMIZATION="-pipe"
|
|
|
|
|
|
|
|
# OVMF supports IA only, although it could conceivably support ARM someday.
|
|
|
|
COMPATIBLE_HOST='(i.86|x86_64).*'
|
|
|
|
|
2016-12-20 07:47:21 +00:00
|
|
|
# Additional build flags for OVMF with Secure Boot.
|
|
|
|
# Fedora also uses "-D SMM_REQUIRE -D EXCLUDE_SHELL_FROM_FD".
|
|
|
|
OVMF_SECURE_BOOT_EXTRA_FLAGS ??= ""
|
|
|
|
OVMF_SECURE_BOOT_FLAGS = "-DSECURE_BOOT_ENABLE=TRUE ${OVMF_SECURE_BOOT_EXTRA_FLAGS}"
|
|
|
|
|
ovmf: fix toolchain selection
For the native tools, a static patch inserted gcc/g++/ld/ar while later
adding BUILD_LDFLAGS and BUILD_CFLAGS with sed. Now it's all done with sed,
which has the advantage that it uses the actual compile variables. However,
in practice those are the same.
More importantly, picking the build tools for the target was
broken. ovmf-native tried to insert TARGET_PREFIX into the tools
definition file, but that variable is empty in a native recipe. As a
result, "gcc" was used instead of "${HOST_PREFIX}gcc", leading to an
undesirable dependency on the host compiler and potentially
(probably?!) causing some of the build issues that were seen for ovmf.
The new approach is to override the tool selection in ovmf-native so
that the HOST_PREFIX env variable is used, which then gets exported
during do_compile for the target.
While at it, Python code that gets appened to do_patch only to call
shell functions gets replaced with the do_patch[postfuncs] mechanism.
Incremental builds now always use the tools definition from the
current ovmf-native; previously, only the initial build copied the
template file.
Probably the entire split into ovmf-native and ovmf could be
removed. This merely hasn't been attempted yet.
(From OE-Core rev: 23a12d87a6e82f80f4ccc1a01c707faa89ff7abd)
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-03-21 08:56:50 +00:00
|
|
|
do_patch[postfuncs] += "fix_basetools_location"
|
|
|
|
fix_basetools_location () {
|
2016-12-06 15:21:17 +00:00
|
|
|
}
|
ovmf: fix toolchain selection
For the native tools, a static patch inserted gcc/g++/ld/ar while later
adding BUILD_LDFLAGS and BUILD_CFLAGS with sed. Now it's all done with sed,
which has the advantage that it uses the actual compile variables. However,
in practice those are the same.
More importantly, picking the build tools for the target was
broken. ovmf-native tried to insert TARGET_PREFIX into the tools
definition file, but that variable is empty in a native recipe. As a
result, "gcc" was used instead of "${HOST_PREFIX}gcc", leading to an
undesirable dependency on the host compiler and potentially
(probably?!) causing some of the build issues that were seen for ovmf.
The new approach is to override the tool selection in ovmf-native so
that the HOST_PREFIX env variable is used, which then gets exported
during do_compile for the target.
While at it, Python code that gets appened to do_patch only to call
shell functions gets replaced with the do_patch[postfuncs] mechanism.
Incremental builds now always use the tools definition from the
current ovmf-native; previously, only the initial build copied the
template file.
Probably the entire split into ovmf-native and ovmf could be
removed. This merely hasn't been attempted yet.
(From OE-Core rev: 23a12d87a6e82f80f4ccc1a01c707faa89ff7abd)
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-03-21 08:56:50 +00:00
|
|
|
fix_basetools_location_class-target() {
|
|
|
|
# Replaces the fake path inserted by 0002-ovmf-update-path-to-native-BaseTools.patch.
|
|
|
|
# Necessary for finding the actual BaseTools from ovmf-native.
|
2016-12-06 15:21:17 +00:00
|
|
|
sed -i -e 's#BBAKE_EDK_TOOLS_PATH#${STAGING_BINDIR_NATIVE}/${EDK_TOOLS_DIR}#' ${S}/OvmfPkg/build.sh
|
|
|
|
}
|
|
|
|
|
ovmf: fix toolchain selection
For the native tools, a static patch inserted gcc/g++/ld/ar while later
adding BUILD_LDFLAGS and BUILD_CFLAGS with sed. Now it's all done with sed,
which has the advantage that it uses the actual compile variables. However,
in practice those are the same.
More importantly, picking the build tools for the target was
broken. ovmf-native tried to insert TARGET_PREFIX into the tools
definition file, but that variable is empty in a native recipe. As a
result, "gcc" was used instead of "${HOST_PREFIX}gcc", leading to an
undesirable dependency on the host compiler and potentially
(probably?!) causing some of the build issues that were seen for ovmf.
The new approach is to override the tool selection in ovmf-native so
that the HOST_PREFIX env variable is used, which then gets exported
during do_compile for the target.
While at it, Python code that gets appened to do_patch only to call
shell functions gets replaced with the do_patch[postfuncs] mechanism.
Incremental builds now always use the tools definition from the
current ovmf-native; previously, only the initial build copied the
template file.
Probably the entire split into ovmf-native and ovmf could be
removed. This merely hasn't been attempted yet.
(From OE-Core rev: 23a12d87a6e82f80f4ccc1a01c707faa89ff7abd)
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-03-21 08:56:50 +00:00
|
|
|
do_patch[postfuncs] += "fix_iasl"
|
|
|
|
fix_iasl() {
|
2016-12-06 15:21:17 +00:00
|
|
|
}
|
ovmf: fix toolchain selection
For the native tools, a static patch inserted gcc/g++/ld/ar while later
adding BUILD_LDFLAGS and BUILD_CFLAGS with sed. Now it's all done with sed,
which has the advantage that it uses the actual compile variables. However,
in practice those are the same.
More importantly, picking the build tools for the target was
broken. ovmf-native tried to insert TARGET_PREFIX into the tools
definition file, but that variable is empty in a native recipe. As a
result, "gcc" was used instead of "${HOST_PREFIX}gcc", leading to an
undesirable dependency on the host compiler and potentially
(probably?!) causing some of the build issues that were seen for ovmf.
The new approach is to override the tool selection in ovmf-native so
that the HOST_PREFIX env variable is used, which then gets exported
during do_compile for the target.
While at it, Python code that gets appened to do_patch only to call
shell functions gets replaced with the do_patch[postfuncs] mechanism.
Incremental builds now always use the tools definition from the
current ovmf-native; previously, only the initial build copied the
template file.
Probably the entire split into ovmf-native and ovmf could be
removed. This merely hasn't been attempted yet.
(From OE-Core rev: 23a12d87a6e82f80f4ccc1a01c707faa89ff7abd)
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-03-21 08:56:50 +00:00
|
|
|
fix_iasl_class-native() {
|
|
|
|
# iasl is not installed under /usr/bin when building with OE.
|
2016-12-06 15:21:17 +00:00
|
|
|
sed -i -e 's#/usr/bin/iasl#${STAGING_BINDIR_NATIVE}/iasl#' ${S}/BaseTools/Conf/tools_def.template
|
|
|
|
}
|
|
|
|
|
ovmf: fix toolchain selection
For the native tools, a static patch inserted gcc/g++/ld/ar while later
adding BUILD_LDFLAGS and BUILD_CFLAGS with sed. Now it's all done with sed,
which has the advantage that it uses the actual compile variables. However,
in practice those are the same.
More importantly, picking the build tools for the target was
broken. ovmf-native tried to insert TARGET_PREFIX into the tools
definition file, but that variable is empty in a native recipe. As a
result, "gcc" was used instead of "${HOST_PREFIX}gcc", leading to an
undesirable dependency on the host compiler and potentially
(probably?!) causing some of the build issues that were seen for ovmf.
The new approach is to override the tool selection in ovmf-native so
that the HOST_PREFIX env variable is used, which then gets exported
during do_compile for the target.
While at it, Python code that gets appened to do_patch only to call
shell functions gets replaced with the do_patch[postfuncs] mechanism.
Incremental builds now always use the tools definition from the
current ovmf-native; previously, only the initial build copied the
template file.
Probably the entire split into ovmf-native and ovmf could be
removed. This merely hasn't been attempted yet.
(From OE-Core rev: 23a12d87a6e82f80f4ccc1a01c707faa89ff7abd)
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-03-21 08:56:50 +00:00
|
|
|
# Inject CC and friends into the build. LINKER already is in GNUmakefile.
|
|
|
|
# Must be idempotent and thus remove old assignments that were inserted
|
|
|
|
# earlier.
|
|
|
|
do_patch[postfuncs] += "fix_toolchain"
|
|
|
|
fix_toolchain() {
|
|
|
|
sed -i \
|
|
|
|
-e '/^\(CC\|CXX\|AS\|AR\|LD\|LINKER\) =/d' \
|
|
|
|
-e '/^APPLICATION/a CC = ${CC}\nCXX = ${CXX}\nAS = ${AS}\nAR = ${AR}\nLD = ${LD}\nLINKER = $(CC)' \
|
|
|
|
${S}/BaseTools/Source/C/Makefiles/app.makefile
|
|
|
|
sed -i \
|
|
|
|
-e '/^\(CC\|CXX\|AS\|AR\|LD\)/d' \
|
|
|
|
-e '/^VFR_CPPFLAGS/a CC = ${CC}\nCXX = ${CXX}\nAS = ${AS}\nAR = ${AR}\nLD = ${LD}' \
|
|
|
|
${S}/BaseTools/Source/C/VfrCompile/GNUmakefile
|
|
|
|
}
|
|
|
|
fix_toolchain_append_class-native() {
|
|
|
|
# This tools_def.template is going to be used by the target ovmf and
|
|
|
|
# defines which compilers to use. For the GCC toolchain definitions,
|
|
|
|
# that will be ${HOST_PREFIX}gcc. However, "make" doesn't need that
|
|
|
|
# prefix.
|
|
|
|
#
|
|
|
|
# Injecting ENV(HOST_PREFIX) matches exporting that value as env
|
|
|
|
# variable in do_compile_class-target.
|
|
|
|
sed -i \
|
|
|
|
-e 's#\(ENV\|DEF\)(GCC.*_PREFIX)#ENV(HOST_PREFIX)#' \
|
|
|
|
-e 's#ENV(HOST_PREFIX)make#make#' \
|
|
|
|
${S}/BaseTools/Conf/tools_def.template
|
|
|
|
sed -i \
|
|
|
|
-e '/^\(LFLAGS\|CFLAGS\) +=/d' \
|
|
|
|
-e '/^LINKER/a LFLAGS += ${BUILD_LDFLAGS}\nCFLAGS += ${BUILD_CFLAGS}' \
|
|
|
|
${S}/BaseTools/Source/C/Makefiles/app.makefile \
|
|
|
|
${S}/BaseTools/Source/C/VfrCompile/GNUmakefile
|
2017-03-29 12:52:06 +00:00
|
|
|
# Linking with gold fails:
|
|
|
|
# internal error in do_layout, at ../../gold/object.cc:1821
|
|
|
|
# make: *** [.../OUTPUT/Facs.acpi] Error 1
|
|
|
|
# We intentionally hard-code the use of ld.bfd regardless of DISTRO_FEATURES
|
|
|
|
# to make ovmf-native reusable across distros.
|
|
|
|
sed -i \
|
|
|
|
-e 's#^\(DEFINE GCC.*DLINK.*FLAGS *=\)#\1 -fuse-ld=bfd#' \
|
|
|
|
${S}/BaseTools/Conf/tools_def.template
|
2016-12-06 15:21:17 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
GCC_VER="$(${CC} -v 2>&1 | tail -n1 | awk '{print $3}')"
|
|
|
|
|
|
|
|
fixup_target_tools() {
|
|
|
|
case ${1} in
|
|
|
|
4.4.*)
|
|
|
|
FIXED_GCCVER=GCC44
|
|
|
|
;;
|
|
|
|
4.5.*)
|
|
|
|
FIXED_GCCVER=GCC45
|
|
|
|
;;
|
|
|
|
4.6.*)
|
|
|
|
FIXED_GCCVER=GCC46
|
|
|
|
;;
|
|
|
|
4.7.*)
|
|
|
|
FIXED_GCCVER=GCC47
|
|
|
|
;;
|
|
|
|
4.8.*)
|
|
|
|
FIXED_GCCVER=GCC48
|
|
|
|
;;
|
|
|
|
4.9.*)
|
|
|
|
FIXED_GCCVER=GCC49
|
|
|
|
;;
|
|
|
|
*)
|
|
|
|
FIXED_GCCVER=GCC5
|
|
|
|
;;
|
|
|
|
esac
|
|
|
|
echo ${FIXED_GCCVER}
|
|
|
|
}
|
|
|
|
|
|
|
|
do_compile_class-native() {
|
|
|
|
oe_runmake -C ${S}/BaseTools
|
|
|
|
}
|
|
|
|
|
|
|
|
do_compile_class-target() {
|
|
|
|
export LFLAGS="${LDFLAGS}"
|
ovmf_git.bb: enable parallel compilation
The Fedora srpm [1] seems to have no problems with parallel
compilation, so let's also use that for the target. The native
tools however indeed have dependency problems:
| test_Ecc_CParser (CheckPythonSyntax.Tests) ... gcc -o ../bin/EfiRom -L/fast/build/ostro/x86/tmp-glibc/sysroots/x86_64-linux/usr/lib -L/fast/build/ostro/x86/tmp-glibc/sysroots/x86_64-linux/lib -Wl,-rpath-link,/fast/build/ostro/x86/tmp-glibc/sysroots/x86_64-linux/usr/lib -Wl,-rpath-link,/fast/build/ostro/x86/tmp-glibc/sysroots/x86_64-linux/lib -Wl,-rpath,/fast/build/ostro/x86/tmp-glibc/sysroots/x86_64-linux/usr/lib -Wl,-rpath,/fast/build/ostro/x86/tmp-glibc/sysroots/x86_64-linux/lib -Wl,-O1 EfiRom.o -L../libs -lCommon
| /usr/bin/ld: cannot find -lCommon
| collect2: error: ld returned 1 exit status
ERROR: Task (virtual:native:.../meta/recipes-core/ovmf/ovmf_git.bb:do_compile) failed with exit code '1'
[1] https://src.fedoraproject.org/cgit/rpms/edk2.git/tree/edk2.spec
(From OE-Core rev: be307609a067b7d23dc2cd8e39e3a35f770bebc7)
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-12-19 16:02:43 +00:00
|
|
|
PARALLEL_JOBS="${@ '${PARALLEL_MAKE}'.replace('-j', '-n')}"
|
2016-12-06 15:21:17 +00:00
|
|
|
OVMF_ARCH="X64"
|
|
|
|
if [ "${TARGET_ARCH}" != "x86_64" ] ; then
|
|
|
|
OVMF_ARCH="IA32"
|
|
|
|
fi
|
|
|
|
|
ovmf: fix toolchain selection
For the native tools, a static patch inserted gcc/g++/ld/ar while later
adding BUILD_LDFLAGS and BUILD_CFLAGS with sed. Now it's all done with sed,
which has the advantage that it uses the actual compile variables. However,
in practice those are the same.
More importantly, picking the build tools for the target was
broken. ovmf-native tried to insert TARGET_PREFIX into the tools
definition file, but that variable is empty in a native recipe. As a
result, "gcc" was used instead of "${HOST_PREFIX}gcc", leading to an
undesirable dependency on the host compiler and potentially
(probably?!) causing some of the build issues that were seen for ovmf.
The new approach is to override the tool selection in ovmf-native so
that the HOST_PREFIX env variable is used, which then gets exported
during do_compile for the target.
While at it, Python code that gets appened to do_patch only to call
shell functions gets replaced with the do_patch[postfuncs] mechanism.
Incremental builds now always use the tools definition from the
current ovmf-native; previously, only the initial build copied the
template file.
Probably the entire split into ovmf-native and ovmf could be
removed. This merely hasn't been attempted yet.
(From OE-Core rev: 23a12d87a6e82f80f4ccc1a01c707faa89ff7abd)
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-03-21 08:56:50 +00:00
|
|
|
# The build for the target uses BaseTools/Conf/tools_def.template
|
|
|
|
# from ovmf-native to find the compiler, which depends on
|
|
|
|
# exporting HOST_PREFIX.
|
|
|
|
export HOST_PREFIX="${HOST_PREFIX}"
|
|
|
|
|
|
|
|
# BaseTools/Conf gets copied to Conf, but only if that does not
|
|
|
|
# exist yet. To ensure that an updated template gets used during
|
|
|
|
# incremental builds, we need to remove the copy before we start.
|
|
|
|
rm -f `ls ${S}/Conf/*.txt | grep -v ReadMe.txt`
|
|
|
|
|
2016-12-16 14:07:29 +00:00
|
|
|
# ${WORKDIR}/ovmf is a well-known location where do_install and
|
|
|
|
# do_deploy will be able to find the files.
|
|
|
|
rm -rf ${WORKDIR}/ovmf
|
|
|
|
mkdir ${WORKDIR}/ovmf
|
|
|
|
OVMF_DIR_SUFFIX="X64"
|
|
|
|
if [ "${TARGET_ARCH}" != "x86_64" ] ; then
|
|
|
|
OVMF_DIR_SUFFIX="Ia32" # Note the different capitalization
|
|
|
|
fi
|
2016-12-06 15:21:17 +00:00
|
|
|
FIXED_GCCVER=$(fixup_target_tools ${GCC_VER})
|
2016-12-16 14:07:29 +00:00
|
|
|
bbnote FIXED_GCCVER is ${FIXED_GCCVER}
|
|
|
|
build_dir="${S}/Build/Ovmf$OVMF_DIR_SUFFIX/RELEASE_${FIXED_GCCVER}"
|
|
|
|
|
2016-12-20 07:47:21 +00:00
|
|
|
bbnote "Building without Secure Boot."
|
|
|
|
rm -rf ${S}/Build/Ovmf$OVMF_DIR_SUFFIX
|
ovmf_git.bb: enable parallel compilation
The Fedora srpm [1] seems to have no problems with parallel
compilation, so let's also use that for the target. The native
tools however indeed have dependency problems:
| test_Ecc_CParser (CheckPythonSyntax.Tests) ... gcc -o ../bin/EfiRom -L/fast/build/ostro/x86/tmp-glibc/sysroots/x86_64-linux/usr/lib -L/fast/build/ostro/x86/tmp-glibc/sysroots/x86_64-linux/lib -Wl,-rpath-link,/fast/build/ostro/x86/tmp-glibc/sysroots/x86_64-linux/usr/lib -Wl,-rpath-link,/fast/build/ostro/x86/tmp-glibc/sysroots/x86_64-linux/lib -Wl,-rpath,/fast/build/ostro/x86/tmp-glibc/sysroots/x86_64-linux/usr/lib -Wl,-rpath,/fast/build/ostro/x86/tmp-glibc/sysroots/x86_64-linux/lib -Wl,-O1 EfiRom.o -L../libs -lCommon
| /usr/bin/ld: cannot find -lCommon
| collect2: error: ld returned 1 exit status
ERROR: Task (virtual:native:.../meta/recipes-core/ovmf/ovmf_git.bb:do_compile) failed with exit code '1'
[1] https://src.fedoraproject.org/cgit/rpms/edk2.git/tree/edk2.spec
(From OE-Core rev: be307609a067b7d23dc2cd8e39e3a35f770bebc7)
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-12-19 16:02:43 +00:00
|
|
|
${S}/OvmfPkg/build.sh $PARALLEL_JOBS -a $OVMF_ARCH -b RELEASE -t ${FIXED_GCCVER}
|
2016-12-16 14:07:29 +00:00
|
|
|
ln ${build_dir}/FV/OVMF.fd ${WORKDIR}/ovmf/ovmf.fd
|
|
|
|
ln ${build_dir}/FV/OVMF_CODE.fd ${WORKDIR}/ovmf/ovmf.code.fd
|
|
|
|
ln ${build_dir}/FV/OVMF_VARS.fd ${WORKDIR}/ovmf/ovmf.vars.fd
|
ovmf: build image which enrolls standard keys
When booting a qemu virtual machine with ovmf.secboot, it comes up
with no keys installed and thus Secure Boot disabled. To lock down
the machine like a typical PC, one has to enroll the same keys
that PC vendors normally install, i.e. the ones from Microsoft.
This can be done manually (see
https://wiki.ubuntu.com/SecurityTeam/SecureBoot and
https://github.com/tianocore-docs/Docs/raw/master/White_Papers/A_Tour_Beyond_BIOS_into_UEFI_Secure_Boot_White_Paper.pdf) or automatically with the EnrollDefaultKeys.efi helper
from the Fedora ovmf rpm.
To use this with qemu:
$ bitbake ovmf-shell-image
...
$ runqemu serial nographic qemux86 ovmf-shell-image wic ovmf.secboot
...
UEFI Interactive Shell v2.1
EDK II
UEFI v2.60 (EDK II, 0x00010000)
Mapping table
FS0: Alias(s):HD2b:;BLK4:
PciRoot(0x0)/Pci(0x5,0x0)/HD(1,GPT,06AEF759-3982-4AF6-B517-70BA6304FC1C,0x800,0x566C)
BLK0: Alias(s):
PciRoot(0x0)/Pci(0x1,0x0)/Floppy(0x0)
BLK1: Alias(s):
PciRoot(0x0)/Pci(0x1,0x0)/Floppy(0x1)
BLK2: Alias(s):
PciRoot(0x0)/Pci(0x1,0x1)/Ata(0x0)
BLK3: Alias(s):
PciRoot(0x0)/Pci(0x5,0x0)
Press ESC in 1 seconds to skip startup.nsh or any other key to continue.
Shell> fs0:EnrollDefaultKeys.efi
info: SetupMode=1 SecureBoot=0 SecureBootEnable=0 CustomMode=0 VendorKeys=1
info: SetupMode=0 SecureBoot=1 SecureBootEnable=1 CustomMode=0 VendorKeys=0
info: success
Shell> reset
Remember that this will modify
deploy/images/qemux86/ovmf.secboot.qcow2, so make a copy and use the
full path of that copy instead of the "ovmf" argument if needed.
The ovmf-shell-image contains an EFI shell, which is what got started
here directly. After enrolling the keys, Secure Boot is active and the
same image cannot be booted anymore, so the BIOS goes through the
normal boot targets (including network boot, which can take a while to
time out), and ends up in the internal EFI shell. Trying to invoke
bootia32.efi (the shell from the image) or EnrollDefaultKeys.efi then
fails:
Shell> bootia32.efi
Command Error Status: Security Violation
The main purpose at the moment is to test that Secure Boot enforcement
really works. If we had a way to sign generated images, that part could
also be tested by booting in a locked down qemu instance.
0007-OvmfPkg-EnrollDefaultKeys-application-for-enrolling-.patch is
from
https://src.fedoraproject.org/cgit/rpms/edk2.git/tree/0007-OvmfPkg-EnrollDefaultKeys-application-for-enrolling-.patch?id=b1781931894bf2057464e634beed68b1e3218c9e
with one line changed to fix
https://bugzilla.redhat.com/show_bug.cgi?id=132502:
"EFI_STATUS Status = EFI_SUCCESS;" in EnrollListOfX509Certs() lacked
the initializer.
(From OE-Core rev: 1913ace7d0898b5a23a2dbdc574ab1d8648927c5)
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-12-21 08:18:05 +00:00
|
|
|
ln ${build_dir}/${OVMF_ARCH}/Shell.efi ${WORKDIR}/ovmf/
|
2016-12-20 07:47:21 +00:00
|
|
|
|
|
|
|
if ${@bb.utils.contains('PACKAGECONFIG', 'secureboot', 'true', 'false', d)}; then
|
|
|
|
# See CryptoPkg/Library/OpensslLib/Patch-HOWTO.txt and
|
|
|
|
# https://src.fedoraproject.org/cgit/rpms/edk2.git/tree/ for
|
|
|
|
# building with Secure Boot enabled.
|
|
|
|
bbnote "Building with Secure Boot."
|
|
|
|
rm -rf ${S}/Build/Ovmf$OVMF_DIR_SUFFIX
|
|
|
|
if ! [ -f ${S}/CryptoPkg/Library/OpensslLib/openssl-*/edk2-patch-applied ]; then
|
|
|
|
( cd ${S}/CryptoPkg/Library/OpensslLib/openssl-* && patch -p1 <$(echo ../EDKII_openssl-*.patch) && touch edk2-patch-applied )
|
|
|
|
fi
|
|
|
|
( cd ${S}/CryptoPkg/Library/OpensslLib/ && ./Install.sh )
|
|
|
|
${S}/OvmfPkg/build.sh $PARALLEL_JOBS -a $OVMF_ARCH -b RELEASE -t ${FIXED_GCCVER} ${OVMF_SECURE_BOOT_FLAGS}
|
|
|
|
ln ${build_dir}/FV/OVMF.fd ${WORKDIR}/ovmf/ovmf.secboot.fd
|
|
|
|
ln ${build_dir}/FV/OVMF_CODE.fd ${WORKDIR}/ovmf/ovmf.secboot.code.fd
|
ovmf: build image which enrolls standard keys
When booting a qemu virtual machine with ovmf.secboot, it comes up
with no keys installed and thus Secure Boot disabled. To lock down
the machine like a typical PC, one has to enroll the same keys
that PC vendors normally install, i.e. the ones from Microsoft.
This can be done manually (see
https://wiki.ubuntu.com/SecurityTeam/SecureBoot and
https://github.com/tianocore-docs/Docs/raw/master/White_Papers/A_Tour_Beyond_BIOS_into_UEFI_Secure_Boot_White_Paper.pdf) or automatically with the EnrollDefaultKeys.efi helper
from the Fedora ovmf rpm.
To use this with qemu:
$ bitbake ovmf-shell-image
...
$ runqemu serial nographic qemux86 ovmf-shell-image wic ovmf.secboot
...
UEFI Interactive Shell v2.1
EDK II
UEFI v2.60 (EDK II, 0x00010000)
Mapping table
FS0: Alias(s):HD2b:;BLK4:
PciRoot(0x0)/Pci(0x5,0x0)/HD(1,GPT,06AEF759-3982-4AF6-B517-70BA6304FC1C,0x800,0x566C)
BLK0: Alias(s):
PciRoot(0x0)/Pci(0x1,0x0)/Floppy(0x0)
BLK1: Alias(s):
PciRoot(0x0)/Pci(0x1,0x0)/Floppy(0x1)
BLK2: Alias(s):
PciRoot(0x0)/Pci(0x1,0x1)/Ata(0x0)
BLK3: Alias(s):
PciRoot(0x0)/Pci(0x5,0x0)
Press ESC in 1 seconds to skip startup.nsh or any other key to continue.
Shell> fs0:EnrollDefaultKeys.efi
info: SetupMode=1 SecureBoot=0 SecureBootEnable=0 CustomMode=0 VendorKeys=1
info: SetupMode=0 SecureBoot=1 SecureBootEnable=1 CustomMode=0 VendorKeys=0
info: success
Shell> reset
Remember that this will modify
deploy/images/qemux86/ovmf.secboot.qcow2, so make a copy and use the
full path of that copy instead of the "ovmf" argument if needed.
The ovmf-shell-image contains an EFI shell, which is what got started
here directly. After enrolling the keys, Secure Boot is active and the
same image cannot be booted anymore, so the BIOS goes through the
normal boot targets (including network boot, which can take a while to
time out), and ends up in the internal EFI shell. Trying to invoke
bootia32.efi (the shell from the image) or EnrollDefaultKeys.efi then
fails:
Shell> bootia32.efi
Command Error Status: Security Violation
The main purpose at the moment is to test that Secure Boot enforcement
really works. If we had a way to sign generated images, that part could
also be tested by booting in a locked down qemu instance.
0007-OvmfPkg-EnrollDefaultKeys-application-for-enrolling-.patch is
from
https://src.fedoraproject.org/cgit/rpms/edk2.git/tree/0007-OvmfPkg-EnrollDefaultKeys-application-for-enrolling-.patch?id=b1781931894bf2057464e634beed68b1e3218c9e
with one line changed to fix
https://bugzilla.redhat.com/show_bug.cgi?id=132502:
"EFI_STATUS Status = EFI_SUCCESS;" in EnrollListOfX509Certs() lacked
the initializer.
(From OE-Core rev: 1913ace7d0898b5a23a2dbdc574ab1d8648927c5)
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-12-21 08:18:05 +00:00
|
|
|
ln ${build_dir}/${OVMF_ARCH}/EnrollDefaultKeys.efi ${WORKDIR}/ovmf/
|
2016-12-20 07:47:21 +00:00
|
|
|
fi
|
2016-12-06 15:21:17 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
do_install_class-native() {
|
|
|
|
install -d ${D}/${bindir}/edk2_basetools
|
|
|
|
cp -r ${S}/BaseTools ${D}/${bindir}/${EDK_TOOLS_DIR}
|
|
|
|
}
|
|
|
|
|
|
|
|
do_install_class-target() {
|
ovmf: build image which enrolls standard keys
When booting a qemu virtual machine with ovmf.secboot, it comes up
with no keys installed and thus Secure Boot disabled. To lock down
the machine like a typical PC, one has to enroll the same keys
that PC vendors normally install, i.e. the ones from Microsoft.
This can be done manually (see
https://wiki.ubuntu.com/SecurityTeam/SecureBoot and
https://github.com/tianocore-docs/Docs/raw/master/White_Papers/A_Tour_Beyond_BIOS_into_UEFI_Secure_Boot_White_Paper.pdf) or automatically with the EnrollDefaultKeys.efi helper
from the Fedora ovmf rpm.
To use this with qemu:
$ bitbake ovmf-shell-image
...
$ runqemu serial nographic qemux86 ovmf-shell-image wic ovmf.secboot
...
UEFI Interactive Shell v2.1
EDK II
UEFI v2.60 (EDK II, 0x00010000)
Mapping table
FS0: Alias(s):HD2b:;BLK4:
PciRoot(0x0)/Pci(0x5,0x0)/HD(1,GPT,06AEF759-3982-4AF6-B517-70BA6304FC1C,0x800,0x566C)
BLK0: Alias(s):
PciRoot(0x0)/Pci(0x1,0x0)/Floppy(0x0)
BLK1: Alias(s):
PciRoot(0x0)/Pci(0x1,0x0)/Floppy(0x1)
BLK2: Alias(s):
PciRoot(0x0)/Pci(0x1,0x1)/Ata(0x0)
BLK3: Alias(s):
PciRoot(0x0)/Pci(0x5,0x0)
Press ESC in 1 seconds to skip startup.nsh or any other key to continue.
Shell> fs0:EnrollDefaultKeys.efi
info: SetupMode=1 SecureBoot=0 SecureBootEnable=0 CustomMode=0 VendorKeys=1
info: SetupMode=0 SecureBoot=1 SecureBootEnable=1 CustomMode=0 VendorKeys=0
info: success
Shell> reset
Remember that this will modify
deploy/images/qemux86/ovmf.secboot.qcow2, so make a copy and use the
full path of that copy instead of the "ovmf" argument if needed.
The ovmf-shell-image contains an EFI shell, which is what got started
here directly. After enrolling the keys, Secure Boot is active and the
same image cannot be booted anymore, so the BIOS goes through the
normal boot targets (including network boot, which can take a while to
time out), and ends up in the internal EFI shell. Trying to invoke
bootia32.efi (the shell from the image) or EnrollDefaultKeys.efi then
fails:
Shell> bootia32.efi
Command Error Status: Security Violation
The main purpose at the moment is to test that Secure Boot enforcement
really works. If we had a way to sign generated images, that part could
also be tested by booting in a locked down qemu instance.
0007-OvmfPkg-EnrollDefaultKeys-application-for-enrolling-.patch is
from
https://src.fedoraproject.org/cgit/rpms/edk2.git/tree/0007-OvmfPkg-EnrollDefaultKeys-application-for-enrolling-.patch?id=b1781931894bf2057464e634beed68b1e3218c9e
with one line changed to fix
https://bugzilla.redhat.com/show_bug.cgi?id=132502:
"EFI_STATUS Status = EFI_SUCCESS;" in EnrollListOfX509Certs() lacked
the initializer.
(From OE-Core rev: 1913ace7d0898b5a23a2dbdc574ab1d8648927c5)
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-12-21 08:18:05 +00:00
|
|
|
# Content for UEFI shell iso. We install the EFI shell as
|
|
|
|
# bootx64/ia32.efi because then it can be started even when the
|
|
|
|
# firmware itself does not contain it.
|
|
|
|
install -d ${D}/efi/boot
|
|
|
|
install ${WORKDIR}/ovmf/Shell.efi ${D}/efi/boot/boot${@ "ia32" if "${TARGET_ARCH}" != "x86_64" else "x64"}.efi
|
|
|
|
if ${@bb.utils.contains('PACKAGECONFIG', 'secureboot', 'true', 'false', d)}; then
|
|
|
|
install ${WORKDIR}/ovmf/EnrollDefaultKeys.efi ${D}
|
|
|
|
fi
|
2016-12-16 14:07:29 +00:00
|
|
|
}
|
2016-12-06 15:21:17 +00:00
|
|
|
|
ovmf: build image which enrolls standard keys
When booting a qemu virtual machine with ovmf.secboot, it comes up
with no keys installed and thus Secure Boot disabled. To lock down
the machine like a typical PC, one has to enroll the same keys
that PC vendors normally install, i.e. the ones from Microsoft.
This can be done manually (see
https://wiki.ubuntu.com/SecurityTeam/SecureBoot and
https://github.com/tianocore-docs/Docs/raw/master/White_Papers/A_Tour_Beyond_BIOS_into_UEFI_Secure_Boot_White_Paper.pdf) or automatically with the EnrollDefaultKeys.efi helper
from the Fedora ovmf rpm.
To use this with qemu:
$ bitbake ovmf-shell-image
...
$ runqemu serial nographic qemux86 ovmf-shell-image wic ovmf.secboot
...
UEFI Interactive Shell v2.1
EDK II
UEFI v2.60 (EDK II, 0x00010000)
Mapping table
FS0: Alias(s):HD2b:;BLK4:
PciRoot(0x0)/Pci(0x5,0x0)/HD(1,GPT,06AEF759-3982-4AF6-B517-70BA6304FC1C,0x800,0x566C)
BLK0: Alias(s):
PciRoot(0x0)/Pci(0x1,0x0)/Floppy(0x0)
BLK1: Alias(s):
PciRoot(0x0)/Pci(0x1,0x0)/Floppy(0x1)
BLK2: Alias(s):
PciRoot(0x0)/Pci(0x1,0x1)/Ata(0x0)
BLK3: Alias(s):
PciRoot(0x0)/Pci(0x5,0x0)
Press ESC in 1 seconds to skip startup.nsh or any other key to continue.
Shell> fs0:EnrollDefaultKeys.efi
info: SetupMode=1 SecureBoot=0 SecureBootEnable=0 CustomMode=0 VendorKeys=1
info: SetupMode=0 SecureBoot=1 SecureBootEnable=1 CustomMode=0 VendorKeys=0
info: success
Shell> reset
Remember that this will modify
deploy/images/qemux86/ovmf.secboot.qcow2, so make a copy and use the
full path of that copy instead of the "ovmf" argument if needed.
The ovmf-shell-image contains an EFI shell, which is what got started
here directly. After enrolling the keys, Secure Boot is active and the
same image cannot be booted anymore, so the BIOS goes through the
normal boot targets (including network boot, which can take a while to
time out), and ends up in the internal EFI shell. Trying to invoke
bootia32.efi (the shell from the image) or EnrollDefaultKeys.efi then
fails:
Shell> bootia32.efi
Command Error Status: Security Violation
The main purpose at the moment is to test that Secure Boot enforcement
really works. If we had a way to sign generated images, that part could
also be tested by booting in a locked down qemu instance.
0007-OvmfPkg-EnrollDefaultKeys-application-for-enrolling-.patch is
from
https://src.fedoraproject.org/cgit/rpms/edk2.git/tree/0007-OvmfPkg-EnrollDefaultKeys-application-for-enrolling-.patch?id=b1781931894bf2057464e634beed68b1e3218c9e
with one line changed to fix
https://bugzilla.redhat.com/show_bug.cgi?id=132502:
"EFI_STATUS Status = EFI_SUCCESS;" in EnrollListOfX509Certs() lacked
the initializer.
(From OE-Core rev: 1913ace7d0898b5a23a2dbdc574ab1d8648927c5)
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-12-21 08:18:05 +00:00
|
|
|
# This always gets packaged because ovmf-shell-image depends on it.
|
|
|
|
# This allows testing that recipe in all configurations because it
|
|
|
|
# can always be part of a world build.
|
|
|
|
#
|
|
|
|
# However, EnrollDefaultKeys.efi is only included when Secure Boot is enabled.
|
|
|
|
PACKAGES =+ "ovmf-shell-efi"
|
|
|
|
FILES_ovmf-shell-efi = " \
|
|
|
|
EnrollDefaultKeys.efi \
|
|
|
|
efi/ \
|
|
|
|
"
|
|
|
|
|
2016-12-16 14:07:29 +00:00
|
|
|
do_deploy() {
|
|
|
|
}
|
|
|
|
do_deploy[cleandirs] = "${DEPLOYDIR}"
|
|
|
|
do_deploy_class-target() {
|
|
|
|
# For use with "runqemu ovmf".
|
|
|
|
for i in \
|
|
|
|
ovmf \
|
|
|
|
ovmf.code \
|
|
|
|
ovmf.vars \
|
2016-12-20 07:47:21 +00:00
|
|
|
${@bb.utils.contains('PACKAGECONFIG', 'secureboot', 'ovmf.secboot ovmf.secboot.code', '', d)} \
|
2016-12-16 14:07:29 +00:00
|
|
|
; do
|
|
|
|
qemu-img convert -f raw -O qcow2 ${WORKDIR}/ovmf/$i.fd ${DEPLOYDIR}/$i.qcow2
|
|
|
|
done
|
2016-12-06 15:21:17 +00:00
|
|
|
}
|
2016-12-16 14:07:29 +00:00
|
|
|
addtask do_deploy after do_compile before do_build
|
2016-12-06 15:21:17 +00:00
|
|
|
|
|
|
|
BBCLASSEXTEND = "native"
|