Re: [OE-core] [PATCH] tune-i586-nlp: Add new tune file to support Quark/X1000 CPU
On 6/29/15 7:10 AM, Saul Wold wrote:
This tune file is needed to enable a GAS option specific to this cpu family
in order to disable the usage of lock prefix instructions.
Signed-off-by: Saul Wold s...@linux.intel.com
---
meta/conf/machine/include/tune-i586-nlp.inc | 19
+
1 file changed, 19 insertions(+)
create mode 100644 meta/conf/machine/include/tune-i586-nlp.inc
diff --git a/meta/conf/machine/include/tune-i586-nlp.inc
b/meta/conf/machine/include/tune-i586-nlp.inc
new file mode 100644
index 000..94e22c1
--- /dev/null
+++ b/meta/conf/machine/include/tune-i586-nlp.inc
@@ -0,0 +1,19 @@
+# Settings for the GCC(1) cpu-type quark:
+#
+#
+#
+DEFAULTTUNE ?= i586-nlp-32
+
+# Include the previous tune to pull in PACKAGE_EXTRA_ARCHS
+require conf/machine/include/x86/arch-x86.inc
+
+# x86 with no lock prefix
+TUNEVALID[i586-nlp] = IA32 with Lock Prefix omitted
+TUNE_CCARGS .= ${@bb.utils.contains(TUNE_FEATURES, i586-nlp,
-march=i586 -Wa,-momit-lock-prefix=yes, , d)}
+
+# Quark tune feature
+AVAILTUNES = i586-nlp-32
+TUNE_FEATURES_tune-i586-nlp-32 = ${TUNE_FEATURES_tune-x86} i586-nlp
+BASE_LIB_tune-i586-nlp-32 = lib
+TUNE_PKGARCH_tune-i586-nlp-32 = i586-nlp-32
+PACKAGE_EXTRA_ARCHS_tune-i586-nlp-32 = i586-nlp-32
I believe this explicit assignment, instead of appending to tune-i586,
addresses the issue Phil raised?
Reviewed-by: Darren Hart dvh...@linux.intel.com
--
Darren Hart
Intel Open Source Technology Center
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] core-image-kernel-dev: Define a correct subset of TEST_SUITES to run for this image
On 6/30/15 3:48 PM, Saul Wold wrote: Since this is image can be built with both poky and poky-lsb, ensure the correct s/is// tests are run in both cases, the auto detection does not quite work right in the poky-lsb case since not all the Posix cmdline utilites are added. Add connman and connman test for network sanity Signed-off-by: Saul Wold s...@linux.intel.com Acked-by: Darren Hart dvh...@linux.intel.com -- Darren Hart Intel Open Source Technology Center -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] tune-i586-nlp: Add new tune file to support Quark/X1000 CPU
On 6/23/15, 10:19 AM, Phil Blundell p...@pbcl.net wrote: On Tue, 2015-06-23 at 10:17 -0700, Darren Hart wrote: Hrm... The thing we need to avoid is quark machines accepting an i586 package in lieu of a i586-nlp package. I don't think that's a problem here is it? The PACKAGE_EXTRA_ARCHS makes it so the i586-nlp package can be used on machines that require i586, but not vice versa - correct? No, exactly the opposite to that. Right, duh. For some reason I was looking at this from the wrong angle yesterday I guess. -- Darren Hart Intel Open Source Technology Center -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] tune-i586-nlp: Add new tune file to support Quark/X1000 CPU
On 6/23/15, 9:02 AM, Richard Purdie richard.pur...@linuxfoundation.org
wrote:
On Tue, 2015-06-23 at 08:22 -0700, Saul Wold wrote:
This tune file is needed to enable a GAS option specific to this cpu
family
in order to disable the usage of lock prefix instructions.
Signed-off-by: Saul Wold s...@linux.intel.com
---
meta/conf/machine/include/tune-i586-nlp.inc | 20
1 file changed, 20 insertions(+)
create mode 100644 meta/conf/machine/include/tune-i586-nlp.inc
diff --git a/meta/conf/machine/include/tune-i586-nlp.inc
b/meta/conf/machine/include/tune-i586-nlp.inc
new file mode 100644
index 000..6815a16
--- /dev/null
+++ b/meta/conf/machine/include/tune-i586-nlp.inc
@@ -0,0 +1,20 @@
+#
+# Settings for the GAS(1) cpu-type quark/x1000 which has issues
+# with lock-prefix so use that option to omit them.
+#
+
+DEFAULTTUNE ?= i586-nlp
+
+# Include the previous tune to pull in PACKAGE_EXTRA_ARCHS
+require conf/machine/include/tune-i586.inc
+
+# x86 with no lock prefix
+TUNEVALID[nlp] = IA32 with Lock Prefix omitted
+TUNE_CCARGS .= ${@bb.utils.contains(TUNE_FEATURES, nlp,
-Wa,-momit-lock-prefix=yes, , d)}
+
+# Quark tune feature
+AVAILTUNES = i586-nlp
+TUNE_FEATURES_tune-i586-nlp = ${TUNE_FEATURES_tune-i586} nlp
+TUNE_PKGARCH_tune-i586-nlp = i586-nlp
+PACKAGE_EXTRA_ARCHS_tune-i586-nlp = ${PACKAGE_EXTRA_ARCHS_tune-i586}
i586-nlp
Since i586 doesn't work with this hardware, should this inherit the i586
tune?
Hrm... The thing we need to avoid is quark machines accepting an i586
package in lieu of a i586-nlp package. I don't think that's a problem here
is it? The PACKAGE_EXTRA_ARCHS makes it so the i586-nlp package can be
used on machines that require i586, but not vice versa - correct?
I don't see a conflict here, but maybe I'm missing something.
--
Darren Hart
Intel Open Source Technology Center
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] oe-git-proxy: Redirect error messages to STDERR
On 3/27/15, 10:17 AM, Juro Bystricky juro.bystri...@intel.com wrote: oe-git-proxy script needs socat. If socat is not found, an error message is issued on STDOUT. This leads to a misleading git message: fatal: protocol error: bad line length character: ERRO instead of the intended message: ERROR: socat binary not in PATH Redirecting the error message to STDERR fixes this issue. Signed-off-by: Juro Bystricky juro.bystri...@intel.com Thanks Juro, good fix. Reviewed-by: Darren Hart dvh...@linux.intel.com -- Darren Hart Intel Open Source Technology Center -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] fix '[[: not found' error message using dash
Hi Vincent,
On 1/12/15 2:10 PM, Vincent Génieux wrote:
This is a fix for https://bugzilla.yoctoproject.org/show_bug.cgi?id=7112
bash specific syntax '[[ test ]]' replaced with '[ test ]'.
Please use the tag:
Fixes [YOCTO 7112]
In the message body, on it's own line.
Signed-off-by: Vincent Génieux vincent2...@startigen.fr
Here it is customary to list the people you have been working with:
Cc: Darren Hart dvh...@linux.intel.com
Cc: Bruce Ashfield...
etc.
Also, ensure your mailer does actually Cc those people (git send-email
can do this automatically).
---
meta/classes/kernel.bbclass |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 70ed95b..2a6ec34 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -403,7 +403,7 @@ do_strip() {
gawk '{print $1}'`
for str in ${KERNEL_IMAGE_STRIP_EXTRA_SECTIONS}; do {
- if [[ $headers != *$str* ]]; then
+ if [ $headers != *$str* ]; then
bbwarn Section not found: $str;
fi
Content is correct. I presume this passes your testing with the dash shell?
Acked-by: Darren Hart dvh...@linux.intel.com
--
Darren Hart
Intel Open Source Technology Center
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] RFC: Further kernel build process changes?
On 1/7/15, 5:22 AM, Bruce Ashfield bruce.ashfi...@windriver.com wrote:
On 2015-01-07 7:26 AM, Richard Purdie wrote:
I'm hearing (somewhat justified) complaints that the recent kernel
changes have destablised builds. Part of the question is whether the
recent changes are as clear to users as they could be, we're also
running into some problems due to mixing kernel source and build
artefacts in some places and not in others.
And we've been bitten by the sheer diversity in the various additions
and tweaks to the kernel build process .. which when wading in to try
and make some improvements was always the risk :(
At this point I think it may be worth looking at making some more
invasive but decisive changes, specifically that:
STAGING_KERNEL_DIR moves
from sysroots/MACHINE/usr/src/kernel
to work-shared/MACHINE/kernel-source
This is to make it clearer that the source here is not under the control
of sstate. The reasons why we don't want it under the control of sstate
are in other emails.
I'm in agreement here.
I would prefer this approach as well.
The second change would be to split the kernel source into two:
work-shared/MACHINE/kernel-source
work-shared/MACHINE/kernel-build
where kernel-build is the kernel build output and kernel-source is kept
pristine.
This means the defconfig, the kernel-abiversion, System.map files and
output from make scripts would be in kernel-build.
Exactly. When setting up the minimal external module build environment,
to keep the impact in the shared directories small, I went with the
current approach.
Since we are breaking workflows with it .. this would be a good balance
between the old and new efforts. I started mocking this up over the
holidays
but lost a week due to illness. I'll continue running with this now.
Also in agreement here, keeping the sourcedir pristine should reduce
confusion and complexity elsewhere.
External module builds do work in this configuration *if* you pass in
the correct options e.g.:
make -C work-shared/MACHINE/kernel-source
O=work-shared/MACHINE/kernel-build M=${S}
I've put together a quick proof of concept of this below.
I was concerned about how this would impact hello-mod and recipes modeled
after it, however, in reviewing the patch below, it looks to have this
covered. I¹ll verify this just as soon as my workstation is available
(it¹s ³busy² updating sigh).
There are two other things up for discussion. There is of confusion on
how the kernel source gets into STAGING_KERNEL_DIR in the first place.
We've added in munging code which does this in kernel.bbclass,
linux-yocto also has its share of crazy mess in this regard.
:)
We could wipe the slate clean and require that people put a parameter
against the element in SRC_URI that represents the kernel indicating it
should be directly extracted to STAGING_KERNEL_DIR. There is a bitbake
issue with being unable to override the extraction directory at present
but that can be fixed. The upside is that it would be clean, relatively
clear and allow fragile code to be dropped. The downside is it means
tweaking all kernel recipes.
I¹m concerned about adding yet more complexity to the SRC_URI I don¹t
have a better proposal though. Part of this fix will need to include fixes
to the kernel-dev manual, I can take that on once we hash this out.
The second issue is that of the dependency to populate
STAGING_KERNEL_DIR which is now a depends flag on do_install. The
intent is to have kernelsrc.bbclass do this, looking at the things there
(such as setting S=), I suspect it may not be fit for purpose. We could
adjust the class to check for a variable and set up the dependency if
its set.
Anyhow, this does need thought and discussion but I'm putting it here as
a start to that, and to let people like Bruce see and experiment with
the code below.
I'll blend your RFC with what I have on the cooker today and see if I
can get a patch out ASAP.
I still think it is worth working through these issues and pushing
forward, we risk slipping deeper into the release if we drop everything
and start over.
As we all know, the code is complex and we have many workflows
to support, and I know I'm churning as fast as I can on fixes.
Bruce
A couple of first pass questions below prior to applying and testing
myself...
Cheers,
Richard
diff --git a/meta/classes/kernel-module-split.bbclass
b/meta/classes/kernel-module-split.bbclass
index 9a95b72..2d43b51 100644
--- a/meta/classes/kernel-module-split.bbclass
+++ b/meta/classes/kernel-module-split.bbclass
@@ -70,7 +70,7 @@ python split_kernel_module_packages () {
m = kerverrexp.match(kernelver)
if m:
kernelver_stripped = m.group(1)
-staging_kernel_dir = d.getVar(STAGING_KERNEL_DIR, True)
+staging_kernel_dir = d.getVar(STAGING_KERNEL_BUILDDIR, True)
system_map_file = %s/boot/System.map-%s % (dvar, kernelver)
if
[OE-core] master: qemu-native fails do_compile: unrecognized command line option -fstack-protector-strong¹
I'm seeing the following error attempting to build qemu-native for qemux86-64 from the master branch: ERROR: Logfile of failure stored in: /build/yocto/master/intel-corei7-64_20141008094748/build/tmp/work/x86_64-li nux/qemu-native/2.1.0-r0/temp/log.do_compile.737 Log data follows: | DEBUG: Executing shell function do_compile | NOTE: make -j 1 | GEN arm-linux-user/config-devices.mak | GEN arm-softmmu/config-devices.mak | GEN i386-linux-user/config-devices.mak | GEN i386-softmmu/config-devices.mak | GEN x86_64-linux-user/config-devices.mak | GEN x86_64-softmmu/config-devices.mak | GEN config-all-devices.mak | GEN config-host.h | GEN qemu-options.def | GEN qmp-commands.h | GEN qapi-types.h | GEN qapi-visit.h | GEN qapi-event.h | GEN trace/generated-events.h | GEN trace/generated-tracers.h | GEN tests/test-qapi-types.h | GEN tests/test-qapi-visit.h | GEN tests/test-qmp-commands.h | GEN tests/test-qapi-event.h | CCtests/qemu-iotests/socket_scm_helper.o | LINK tests/qemu-iotests/socket_scm_helper | g++: error: unrecognized command line option '-fstack-protector-strong' | /build/yocto/master/intel-corei7-64_20141008094748/build/tmp/work/x86_64-li nux/qemu-native/2.1.0-r0/qemu-2.1.0/rules.mak:88: recipe for target 'tests/qemu-iotests/socket_scm_helper' failed | make: *** [tests/qemu-iotests/socket_scm_helper] Error 1 | ERROR: oe_runmake failed | WARNING: exit code 1 from a shell command. | ERROR: Function failed: do_compile (log file is located at /build/yocto/master/intel-corei7-64_20141008094748/build/tmp/work/x86_64-li nux/qemu-native/2.1.0-r0/temp/log.do_compile.737) ERROR: Task 7 (virtual:native:/build/yocto/master/intel-corei7-64_20141008094748/poky/met a/recipes-devtools/qemu/qemu_2.1.0.bb, do_compile) failed with exit code '1' The key bit being: | g++: error: unrecognized command line option '-fstack-protector-strong' As this appears to be a toolchain versioning issue, I tested this independently: dvhart@rage:~ $ g++-4.8 -fstack-protector-strong test.c -o test g++-4.8: error: unrecognized command line option -fstack-protector-strong¹ dvhart@rage:~ $ g++-4.9 -fstack-protector-strong test.c -o test dvhart@rage:~ $ ./test Hello World! Sure enough, 4.9 supports this, and 4.8 does not. I'm looking into if this is a qemu-native configuration issue or something else... But if anyone already has a solution in hand, please let me know. -- Darren Hart Intel Open Source Technology Center -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] master: qemu-native fails do_compile: unrecognized command line option -fstack-protector-strong¹
On 10/8/14, 11:00, Darren Hart dvh...@linux.intel.com wrote: I'm seeing the following error attempting to build qemu-native for qemux86-64 from the master branch: ERROR: Logfile of failure stored in: /build/yocto/master/intel-corei7-64_20141008094748/build/tmp/work/x86_64-l i nux/qemu-native/2.1.0-r0/temp/log.do_compile.737 Log data follows: | DEBUG: Executing shell function do_compile | NOTE: make -j 1 | GEN arm-linux-user/config-devices.mak | GEN arm-softmmu/config-devices.mak | GEN i386-linux-user/config-devices.mak | GEN i386-softmmu/config-devices.mak | GEN x86_64-linux-user/config-devices.mak | GEN x86_64-softmmu/config-devices.mak | GEN config-all-devices.mak | GEN config-host.h | GEN qemu-options.def | GEN qmp-commands.h | GEN qapi-types.h | GEN qapi-visit.h | GEN qapi-event.h | GEN trace/generated-events.h | GEN trace/generated-tracers.h | GEN tests/test-qapi-types.h | GEN tests/test-qapi-visit.h | GEN tests/test-qmp-commands.h | GEN tests/test-qapi-event.h | CCtests/qemu-iotests/socket_scm_helper.o | LINK tests/qemu-iotests/socket_scm_helper | g++: error: unrecognized command line option '-fstack-protector-strong' | /build/yocto/master/intel-corei7-64_20141008094748/build/tmp/work/x86_64-l i nux/qemu-native/2.1.0-r0/qemu-2.1.0/rules.mak:88: recipe for target 'tests/qemu-iotests/socket_scm_helper' failed | make: *** [tests/qemu-iotests/socket_scm_helper] Error 1 | ERROR: oe_runmake failed | WARNING: exit code 1 from a shell command. | ERROR: Function failed: do_compile (log file is located at /build/yocto/master/intel-corei7-64_20141008094748/build/tmp/work/x86_64-l i nux/qemu-native/2.1.0-r0/temp/log.do_compile.737) ERROR: Task 7 (virtual:native:/build/yocto/master/intel-corei7-64_20141008094748/poky/me t a/recipes-devtools/qemu/qemu_2.1.0.bb, do_compile) failed with exit code '1' The key bit being: | g++: error: unrecognized command line option '-fstack-protector-strong' As this appears to be a toolchain versioning issue, I tested this independently: dvhart@rage:~ $ g++-4.8 -fstack-protector-strong test.c -o test g++-4.8: error: unrecognized command line option -fstack-protector-strong¹ dvhart@rage:~ $ g++-4.9 -fstack-protector-strong test.c -o test dvhart@rage:~ $ ./test Hello World! Sure enough, 4.9 supports this, and 4.8 does not. I'm looking into if this is a qemu-native configuration issue or something else... But if anyone already has a solution in hand, please let me know. This appears to be related to the Debian Jessie default g++ (4.8). If I set it to 4.9, the build continues. -- Darren Hart Intel Open Source Technology Center -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] kernel-yocto.bbclass: Fixup shell condition test syntax error
A warning is issued when run about an unexpected operator due to a
syntax error with an extra if empedded in the shell conditional. Remove
the extra if.
Signed-off-by: Darren Hart dvh...@linux.intel.com
Cc: Bruce Ashfield bruce.ashfi...@windriver.com
---
meta/classes/kernel-yocto.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/kernel-yocto.bbclass
b/meta/classes/kernel-yocto.bbclass
index 929d64a..7718f9a 100644
--- a/meta/classes/kernel-yocto.bbclass
+++ b/meta/classes/kernel-yocto.bbclass
@@ -296,7 +296,7 @@ do_validate_branches() {
force_srcrev=${SRCREV}
else
git cat-file -t ${machine_srcrev} /dev/null
- if [ if $? -ne 0 ]; then
+ if [ $? -ne 0 ]; then
bberror ${machine_srcrev} is not a valid commit ID.
bbfatal The kernel source tree may be out of sync
fi
--
2.1.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] daisy: runtime-reverse/udev-hwdb missing during do_rootfs
Hi all, I've hit the following on a custom image recipe (based on core-image): | Configuring run-postinsts. | | NOTE: Installing complementary packages ... | NOTE: Running intercept scripts: | NOTE: Executing write_package_manifest ... | DEBUG: Executing python function write_package_manifest | DEBUG: Python function write_package_manifest finished | NOTE: Executing license_create_manifest ... | DEBUG: Executing shell function license_create_manifest | ls: cannot access /build/yocto/daisy/intel-corei7-64_20140718205500/build/tmp/sysroots/intel- internal-corei7-64/pkgdata/runtime-reverse/udev-hwdb: No such file or directory | readlink: missing operand | Try 'readlink --help' for more information. | basename: missing operand | Try 'basename --help' for more information. | WARNING: exit code 1 from a shell command. | DEBUG: Python function do_rootfs finished | ERROR: Function failed: license_create_manifest (log file is located at /build/yocto/daisy/intel-corei7-64_20140718205500/build/tmp/work/intel_inte rnal_corei7_64-eywa-linux/core-image-minimal-initramfs/1.0-r0/temp/log.do_r ootfs.15414) ERROR: Task 150 (/build/yocto/daisy/intel-corei7-64_20140718205500/poky/meta/recipes-core/i mages/core-image-minimal-initramfs.bb, do_rootfs) failed with exit code '1' NOTE: Tasks Summary: Attempted 4727 tasks of which 4697 didn't need to be rerun and 1 failed. Waiting for 0 running tasks to finish: Using the daisy branch of the following layers (poky, meta-intel, and meta-oe layers): BBLAYERS ?= \ /build/yocto/daisy/intel-corei7-64_20140718205500/poky/meta \ /build/yocto/daisy/intel-corei7-64_20140718205500/poky/meta-yocto \ /build/yocto/daisy/intel-corei7-64_20140718205500/poky/meta-yocto-bsp \ BBLAYERS_NON_REMOVABLE ?= \ /build/yocto/daisy/intel-corei7-64_20140718205500/poky/meta \ /build/yocto/daisy/intel-corei7-64_20140718205500/poky/meta-yocto \ # Automatically generated by bitbake-shell (bs) BBLAYERS += /build/yocto/daisy/intel-corei7-64_20140718205500/poky/meta-yocto BBLAYERS += /build/yocto/daisy/intel-corei7-64_20140718205500/meta-openembedded/meta-n etworking BBLAYERS += /build/yocto/daisy/intel-corei7-64_20140718205500/meta-intel BBLAYERS += /build/yocto/daisy/intel-corei7-64_20140718205500/meta-openembedded/meta-x fce BBLAYERS += /build/yocto/daisy/intel-corei7-64_20140718205500/meta-openembedded/meta-o e BBLAYERS += /build/yocto/daisy/intel-corei7-64_20140718205500/meta-openembedded/meta-m ultimedia BBLAYERS += /build/yocto/daisy/intel-corei7-64_20140718205500/meta-openembedded/meta-g nome BBLAYERS += /build/yocto/daisy/intel-corei7-64_20140718205500/eywa/meta BBLAYERS += /build/yocto/daisy/intel-corei7-64_20140718205500/eywa/meta-intel-internal BBLAYERS += /build/yocto/daisy/intel-corei7-64_20140718205500/poky/meta Is this a known issue? Have others hit this or have a workaround? -- Darren Hart Open Source Technology Center darren.h...@intel.com Intel Corporation -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] daisy: runtime-reverse/udev-hwdb missing during do_rootfs
On 9/24/14, 10:58, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Wed, 2014-09-24 at 09:34 -0700, Darren Hart wrote: I've hit the following on a custom image recipe (based on core-image): | Configuring run-postinsts. | | NOTE: Installing complementary packages ... | NOTE: Running intercept scripts: | NOTE: Executing write_package_manifest ... | DEBUG: Executing python function write_package_manifest | DEBUG: Python function write_package_manifest finished | NOTE: Executing license_create_manifest ... | DEBUG: Executing shell function license_create_manifest | ls: cannot access /build/yocto/daisy/intel-corei7-64_20140718205500/build/tmp/sysroots/inte l- internal-corei7-64/pkgdata/runtime-reverse/udev-hwdb: No such file or directory | readlink: missing operand | Try 'readlink --help' for more information. | basename: missing operand | Try 'basename --help' for more information. | WARNING: exit code 1 from a shell command. | DEBUG: Python function do_rootfs finished | ERROR: Function failed: license_create_manifest (log file is located at /build/yocto/daisy/intel-corei7-64_20140718205500/build/tmp/work/intel_in te rnal_corei7_64-eywa-linux/core-image-minimal-initramfs/1.0-r0/temp/log.do _r ootfs.15414) ERROR: Task 150 (/build/yocto/daisy/intel-corei7-64_20140718205500/poky/meta/recipes-core /i mages/core-image-minimal-initramfs.bb, do_rootfs) failed with exit code '1' NOTE: Tasks Summary: Attempted 4727 tasks of which 4697 didn't need to be rerun and 1 failed. Waiting for 0 running tasks to finish: I don't know why it does this but I can perhaps give some pointers as to where to look. udev-hwdb was installed in the image. First question is whether that is actually in the build dependencies. bitbake core-image-minimal-initramfs -c rootfs -g, then grep task-depends.dot and see if udev is in there. This was due to switching between systemd in DISTRO_FEATURES and not. Cleaning systemd and udev and rebuilding resolved the issue. Lesson: use different tmp when changing DISTRO_FEATURES. -- Darren Hart Open Source Technology Center darren.h...@intel.com Intel Corporation -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] bzImage not included in rootfs
From: Chiz Chikwendu chiz.chikwe...@haemonetics.com Date: Thursday, September 11, 2014 at 5:08 To: Openembedded List (openembedded-core@lists.openembedded.org) openembedded-core@lists.openembedded.org Cc: Darren Hart darren.h...@intel.com Subject: bzImage not included in rootfs I am new to Openembedded (and yocto). Hi Chiz, For future reference, when sending email to public open source mailing lists, it's a good idea to use plain text and avoid HTML. Some lists will actually block all HTML email. I have built an image with poky build environment. I noticed that the kernel¹s bzImage is not included in the rootfs. How do I get the system to include ³bzImage² in the rootfs (boot/bzImage-)? I¹ve done some research, and I saw a note about setting the parameter: RDEPENDS_kernel-base = ³zImage² This should override the kernel settings and build the kernel into the rootfs. I tried it, however it is not working for me. Can anyone help? The kernel image is installed in /boot by the kernel-image package. Most images do not include this by default as many targets boot with the kernel located on a separate system partition. See the documentation for how to add new packages to existing image recipes using variables like: CORE_IMAGE_EXTRA_INSTALL += kernel-image http://www.yoctoproject.org/docs/1.6.1/dev-manual/dev-manual.html#usingpoky -extend-customimage-localconf -- Darren Hart Intel Open Source Technology Center -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Packaging kernel sources
On 9/10/14, 1:27, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Tue, 2014-09-09 at 17:42 -0700, Darren Hart wrote: I'm working on a project which needs to have the full kernel sources installed on the target. The kernel-dev package as defined by kernel.bbclass is heavily pruned to minimize packaging time and size and is intended to enable building of external modules on the target. Is there an accepted best-practice for how to get the full source packaged and installed? I can easily write a new recipe, linux-custom-source_git.bb, to install the sources, for example, without impacting the packaging time of virtual/kernel package. It would be nice in some respects for it to all come from the same recipe though, but I suspect the impact to the common-case where this is not need would be far too great. Personally, I'm leaning towards a couple of big changes in this area: a) binning the kernel-dev package and replacing it with some kind of separate full source recipe like this. The benefit is a fully functional on target source which is only built by people who care about it. This means for most users/builds, we no longer need to generate that huge package. The downside is a little more complexity for those that needs this but its not much. The other downside is that the most common use case (building external modules) would now require a lot more disk space than with just kernel-dev (something like 150 MB more iirc). b) binning the separate kernel staging dir and making it work more like the gcc shared work directory. This means external module builds and the tools like perf and so on would use this shared source directory. I was thinking along the same lines here as well. The benefit would be that we no longer have the huge install step in the main kernel recipe and the populate_sysroot step shinks in size. The downside has more impact here, the problem with shared work is that it cannot be removed once extracted since the system never knows when something else may need to use it. For gcc the argument was that we have so many users (gcc-cross-initial, gcc-cross, gcc-runtime, gcc-cross-canadian, gcc-crosssdk, gcc-crosssdk-initial and so on) that the multiple copies were far worse. For the kernel, we can argue that we have a ton of disk usage from it in the sysroot anyway so this change just makes things more efficient effectively. The other issue is that for shared work dirs, the stamps need to be kept in sync, if they step out, odd things happen (i.e. do_fetch, do_unpack, do_patch task checksums need to match for linux-yocto, perf, kernel modules and anything else using it). We may need to add some better error cases to catch problems. Not an insurmountable problem, just one that will likely need to be addressed. Good points. I do feel the whole situation with the current kernel size is out of control and badly affecting user experience. Yup. -- Darren Hart Open Source Technology Center darren.h...@intel.com Intel Corporation -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] Packaging kernel sources
Hi all, I'm working on a project which needs to have the full kernel sources installed on the target. The kernel-dev package as defined by kernel.bbclass is heavily pruned to minimize packaging time and size and is intended to enable building of external modules on the target. Is there an accepted best-practice for how to get the full source packaged and installed? I can easily write a new recipe, linux-custom-source_git.bb, to install the sources, for example, without impacting the packaging time of virtual/kernel package. It would be nice in some respects for it to all come from the same recipe though, but I suspect the impact to the common-case where this is not need would be far too great. Koen, I believe you had a solution for this with Angstrom? -- Darren Hart Intel Open Source Technology Center -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] kernelshark: Remove trace-cmd from the kernelshark package
On 7/18/14, 16:01, Darren Hart dvh...@linux.intel.com wrote:
Fixes [YOCTO 6550]
Images installing both trace-cmd and kernelshark would fail with:
error: file /usr/bin/trace-cmd conflicts between attempted installs of
kernelshark-1.2+git0+7055ffd37b-r3.core2_32 and
trace-cmd-1.2+git0+7055ffd37b-r3.core2_32
This patch removes ${bindir}/trace-cmd from the install prior to
packaging, as is already done with the ${datadir}.
Reported-by: California Sullivan california.l.sulli...@intel.com
Signed-off-by: Darren Hart dvh...@linux.intel.com
(cherry picked from commit eb08ae8f729ef77329892d19b23ddfdaa7953de0)
Apologies for the cherry-picked line, that shouldn't have appeared here.
Please remove prior to merge. I can resubmit if that is preferred.
--
Darren Hart Open Source Technology Center
darren.h...@intel.com Intel Corporation
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] mkefidisk.sh: Remove initrd entry for gummiboot
My previous patch adding gummiboot support was missing the line to remove the initrd line from the boot config. This was an oversight in copying over the grub setup to gummiboot. Add the necessary logic to remove it. Signed-off-by: Darren Hart dvh...@linux.intel.com --- scripts/contrib/mkefidisk.sh | 1 + 1 file changed, 1 insertion(+) diff --git a/scripts/contrib/mkefidisk.sh b/scripts/contrib/mkefidisk.sh index 7ec373e..ba2b563 100755 --- a/scripts/contrib/mkefidisk.sh +++ b/scripts/contrib/mkefidisk.sh @@ -355,6 +355,7 @@ if [ -d $GUMMI_ENTRIES ]; then echo ERROR: $GUMMI_CFG not found fi + sed -i /initrd /d $GUMMI_CFG sed -i s@ root=[^ ]*@ @ $GUMMI_CFG sed -i s@options *LABEL=boot @options LABEL=Boot root=$TARGET_ROOTFS ro rootwait quiet @ $GUMMI_CFG fi -- 1.9.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] kernelshark: Remove trace-cmd from the kernelshark package
On 7/21/14, 8:32, Richard Purdie richard.pur...@linuxfoundation.org
wrote:
On Mon, 2014-07-21 at 08:21 -0700, Darren Hart wrote:
On 7/18/14, 16:01, Darren Hart dvh...@linux.intel.com wrote:
Fixes [YOCTO 6550]
Images installing both trace-cmd and kernelshark would fail with:
error: file /usr/bin/trace-cmd conflicts between attempted installs of
kernelshark-1.2+git0+7055ffd37b-r3.core2_32 and
trace-cmd-1.2+git0+7055ffd37b-r3.core2_32
This patch removes ${bindir}/trace-cmd from the install prior to
packaging, as is already done with the ${datadir}.
Reported-by: California Sullivan california.l.sulli...@intel.com
Signed-off-by: Darren Hart dvh...@linux.intel.com
(cherry picked from commit eb08ae8f729ef77329892d19b23ddfdaa7953de0)
Apologies for the cherry-picked line, that shouldn't have appeared here.
Please remove prior to merge. I can resubmit if that is preferred.
Too late, its in...
Yeah, I saw that. My apologies, that was sloppy and unacceptable. I'll
correct this going forward.
--
Darren Hart Open Source Technology Center
darren.h...@intel.com Intel Corporation
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] mkefidisk.sh: Fix redirection to 1
The current script intends to redirect stderr to stdout, but instead
redirects to a file named 1. No doubt a regex replace error.
Replace all instances of 21 with 21.
Signed-off-by: Darren Hart dvh...@linux.intel.com
---
scripts/contrib/mkefidisk.sh | 38 +++---
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/scripts/contrib/mkefidisk.sh b/scripts/contrib/mkefidisk.sh
index 7ec373e..44ab8d5 100755
--- a/scripts/contrib/mkefidisk.sh
+++ b/scripts/contrib/mkefidisk.sh
@@ -257,22 +257,22 @@ echo
info Partitioning installation media ($DEVICE)
debug Deleting partition table on $DEVICE
-dd if=/dev/zero of=$DEVICE bs=512 count=2 $OUT 21 || die Failed to zero
beginning of $DEVICE
+dd if=/dev/zero of=$DEVICE bs=512 count=2 $OUT 21 || die Failed to zero
beginning of $DEVICE
debug Creating new partition table (MSDOS) on $DEVICE
-parted $DEVICE mklabel msdos $OUT 21 || die Failed to create MSDOS
partition table
+parted $DEVICE mklabel msdos $OUT 21 || die Failed to create MSDOS
partition table
debug Creating boot partition on $BOOTFS
-parted $DEVICE mkpart primary 0% $BOOT_SIZE $OUT 21 || die Failed to create
BOOT partition
+parted $DEVICE mkpart primary 0% $BOOT_SIZE $OUT 21 || die Failed to
create BOOT partition
debug Enabling boot flag on $BOOTFS
-parted $DEVICE set 1 boot on $OUT 21 || die Failed to enable boot flag
+parted $DEVICE set 1 boot on $OUT 21 || die Failed to enable boot flag
debug Creating ROOTFS partition on $ROOTFS
-parted $DEVICE mkpart primary $ROOTFS_START $ROOTFS_END $OUT 21 || die
Failed to create ROOTFS partition
+parted $DEVICE mkpart primary $ROOTFS_START $ROOTFS_END $OUT 21 || die
Failed to create ROOTFS partition
debug Creating swap partition on $SWAP
-parted $DEVICE mkpart primary $SWAP_START 100% $OUT 21 || die Failed to
create SWAP partition
+parted $DEVICE mkpart primary $SWAP_START 100% $OUT 21 || die Failed to
create SWAP partition
if [ $DEBUG -eq 1 ]; then
parted $DEVICE print
@@ -291,34 +291,34 @@ unmount_device || die Failed to unmount $DEVICE
partitions
info Formating partitions
debug Formatting $BOOTFS as vfat
if [ ! ${DEVICE#/dev/loop} = ${DEVICE} ]; then
- mkfs.vfat -I $BOOTFS -n EFI $OUT 21 || die Failed to format
$BOOTFS
+ mkfs.vfat -I $BOOTFS -n EFI $OUT 21 || die Failed to format
$BOOTFS
else
- mkfs.vfat $BOOTFS -n EFI $OUT 21 || die Failed to format $BOOTFS
+ mkfs.vfat $BOOTFS -n EFI $OUT 21 || die Failed to format $BOOTFS
fi
debug Formatting $ROOTFS as ext3
-mkfs.ext3 -F $ROOTFS -L ROOT $OUT 21 || die Failed to format $ROOTFS
+mkfs.ext3 -F $ROOTFS -L ROOT $OUT 21 || die Failed to format $ROOTFS
debug Formatting swap partition ($SWAP)
-mkswap $SWAP $OUT 21 || die Failed to prepare swap
+mkswap $SWAP $OUT 21 || die Failed to prepare swap
#
# Installing to $DEVICE
#
debug Mounting images and device in preparation for installation
-mount -o loop $HDDIMG $HDDIMG_MNT $OUT 21 || error Failed to mount $HDDIMG
-mount -o loop $HDDIMG_MNT/rootfs.img $HDDIMG_ROOTFS_MNT $OUT 21 || error
Failed to mount rootfs.img
-mount $ROOTFS $ROOTFS_MNT $OUT 21 || error Failed to mount $ROOTFS on
$ROOTFS_MNT
-mount $BOOTFS $BOOTFS_MNT $OUT 21 || error Failed to mount $BOOTFS on
$BOOTFS_MNT
+mount -o loop $HDDIMG $HDDIMG_MNT $OUT 21 || error Failed to mount $HDDIMG
+mount -o loop $HDDIMG_MNT/rootfs.img $HDDIMG_ROOTFS_MNT $OUT 21 || error
Failed to mount rootfs.img
+mount $ROOTFS $ROOTFS_MNT $OUT 21 || error Failed to mount $ROOTFS on
$ROOTFS_MNT
+mount $BOOTFS $BOOTFS_MNT $OUT 21 || error Failed to mount $BOOTFS on
$BOOTFS_MNT
info Preparing boot partition
EFIDIR=$BOOTFS_MNT/EFI/BOOT
-cp $HDDIMG_MNT/vmlinuz $BOOTFS_MNT $OUT 21 || error Failed to copy vmlinuz
+cp $HDDIMG_MNT/vmlinuz $BOOTFS_MNT $OUT 21 || error Failed to copy vmlinuz
# Copy the efi loader and configs (booti*.efi and grub.cfg if it exists)
-cp -r $HDDIMG_MNT/EFI $BOOTFS_MNT $OUT 21 || error Failed to copy EFI dir
+cp -r $HDDIMG_MNT/EFI $BOOTFS_MNT $OUT 21 || error Failed to copy EFI dir
# Silently ignore a missing gummiboot loader dir (we might just be a GRUB
image)
-cp -r $HDDIMG_MNT/loader $BOOTFS_MNT $OUT 21
+cp -r $HDDIMG_MNT/loader $BOOTFS_MNT $OUT 21
# Update the boot loaders configurations for an installed image
# Remove any existing root= kernel parameters and:
@@ -349,7 +349,7 @@ GUMMI_CFG=$GUMMI_ENTRIES/boot.conf
if [ -d $GUMMI_ENTRIES ]; then
info Configuring Gummiboot
# remove the install target if it exists
- rm $GUMMI_ENTRIES/install.conf $OUT 21
+ rm $GUMMI_ENTRIES/install.conf $OUT 21
if [ ! -e $GUMMI_CFG ]; then
echo ERROR: $GUMMI_CFG not found
@@ -366,7 +366,7 @@ fi
info Copying ROOTFS files (this may take a while)
-cp -a $HDDIMG_ROOTFS_MNT/* $ROOTFS_MNT $OUT 21 || die Root FS copy failed
+cp -a $HDDIMG_ROOTFS_MNT/* $ROOTFS_MNT $OUT 21 || die Root FS copy failed
echo $TARGET_SWAP swap
[OE-core] [PATCH 2/2] mkefidisk.sh: Add signal handling
Add basic signal handling to unmount and remove any temporary files.
Signed-off-by: Darren Hart dvh...@linux.intel.com
---
scripts/contrib/mkefidisk.sh | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/scripts/contrib/mkefidisk.sh b/scripts/contrib/mkefidisk.sh
index 44ab8d5..7d48b53 100755
--- a/scripts/contrib/mkefidisk.sh
+++ b/scripts/contrib/mkefidisk.sh
@@ -46,7 +46,9 @@ cleanup() {
if [ -d $TMPDIR ]; then
rm -rf $TMPDIR || error Failed to remove $TMPDIR
fi
+ exit $1
}
+trap cleanup HUP INT TERM
# Logging routines
WARNINGS=0
@@ -72,8 +74,7 @@ success() {
}
die() {
error $1
- cleanup
- exit 1
+ cleanup 1
}
debug() {
if [ $DEBUG -eq 1 ]; then
@@ -375,10 +376,6 @@ if [ -d $ROOTFS_MNT/etc/udev/ ] ; then
echo $TARGET_DEVICE $ROOTFS_MNT/etc/udev/mount.blacklist
fi
-
-# Call cleanup to unmount devices and images and remove the TMPDIR
-cleanup
-
echo
if [ $WARNINGS -ne 0 ] [ $ERRORS -eq 0 ]; then
echo ${YELLOW}Installation completed with warnings${CLEAR}
@@ -391,3 +388,6 @@ else
success Installation completed successfully
fi
echo
+
+# Call cleanup to unmount devices and images and remove the TMPDIR
+cleanup 0
--
2.0.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] mkefidisk.sh: Add signal handling
Please ignore this one (2/2), it rearranges output in a way that might
lead to someone pulling the USB key before the sync completes. I will
resend 2/2 of separately.
Apologies :/
On 7/21/14, 15:45, Darren Hart dvh...@linux.intel.com wrote:
Add basic signal handling to unmount and remove any temporary files.
Signed-off-by: Darren Hart dvh...@linux.intel.com
---
scripts/contrib/mkefidisk.sh | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/scripts/contrib/mkefidisk.sh b/scripts/contrib/mkefidisk.sh
index 44ab8d5..7d48b53 100755
--- a/scripts/contrib/mkefidisk.sh
+++ b/scripts/contrib/mkefidisk.sh
@@ -46,7 +46,9 @@ cleanup() {
if [ -d $TMPDIR ]; then
rm -rf $TMPDIR || error Failed to remove $TMPDIR
fi
+ exit $1
}
+trap cleanup HUP INT TERM
# Logging routines
WARNINGS=0
@@ -72,8 +74,7 @@ success() {
}
die() {
error $1
- cleanup
- exit 1
+ cleanup 1
}
debug() {
if [ $DEBUG -eq 1 ]; then
@@ -375,10 +376,6 @@ if [ -d $ROOTFS_MNT/etc/udev/ ] ; then
echo $TARGET_DEVICE $ROOTFS_MNT/etc/udev/mount.blacklist
fi
-
-# Call cleanup to unmount devices and images and remove the TMPDIR
-cleanup
-
echo
if [ $WARNINGS -ne 0 ] [ $ERRORS -eq 0 ]; then
echo ${YELLOW}Installation completed with warnings${CLEAR}
@@ -391,3 +388,6 @@ else
success Installation completed successfully
fi
echo
+
+# Call cleanup to unmount devices and images and remove the TMPDIR
+cleanup 0
--
2.0.0
--
Darren Hart Open Source Technology Center
darren.h...@intel.com Intel Corporation
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] mkefidisk.sh: Add signal handling
Add basic signal handling to unmount and remove any temporary files.
Correct a quoting issue with the die() function caught testing signal
handling.
Fix a minor typo in formatting output.
Signed-off-by: Darren Hart dvh...@linux.intel.com
---
scripts/contrib/mkefidisk.sh | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/scripts/contrib/mkefidisk.sh b/scripts/contrib/mkefidisk.sh
index 28cfb6d..b96b7d4 100755
--- a/scripts/contrib/mkefidisk.sh
+++ b/scripts/contrib/mkefidisk.sh
@@ -48,6 +48,8 @@ cleanup() {
fi
}
+trap 'die Signal Received, Aborting...' HUP INT TERM
+
# Logging routines
WARNINGS=0
ERRORS=0
@@ -71,7 +73,7 @@ success() {
echo ${GREEN}$1${CLEAR}
}
die() {
- error $1
+ error $1
cleanup
exit 1
}
@@ -288,7 +290,7 @@ unmount_device || die Failed to unmount $DEVICE partitions
#
# Format $DEVICE partitions
#
-info Formating partitions
+info Formatting partitions
debug Formatting $BOOTFS as vfat
if [ ! ${DEVICE#/dev/loop} = ${DEVICE} ]; then
mkfs.vfat -I $BOOTFS -n EFI $OUT 21 || die Failed to format
$BOOTFS
--
2.0.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] kernelshark: Remove trace-cmd from the kernelshark package
Fixes [YOCTO 6550]
Images installing both trace-cmd and kernelshark would fail with:
error: file /usr/bin/trace-cmd conflicts between attempted installs of
kernelshark-1.2+git0+7055ffd37b-r3.core2_32 and
trace-cmd-1.2+git0+7055ffd37b-r3.core2_32
This patch removes ${bindir}/trace-cmd from the install prior to
packaging, as is already done with the ${datadir}.
Reported-by: California Sullivan california.l.sulli...@intel.com
Signed-off-by: Darren Hart dvh...@linux.intel.com
(cherry picked from commit eb08ae8f729ef77329892d19b23ddfdaa7953de0)
---
meta/recipes-kernel/trace-cmd/kernelshark_1.2.bb | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/recipes-kernel/trace-cmd/kernelshark_1.2.bb
b/meta/recipes-kernel/trace-cmd/kernelshark_1.2.bb
index e64abe2..9af91c9 100644
--- a/meta/recipes-kernel/trace-cmd/kernelshark_1.2.bb
+++ b/meta/recipes-kernel/trace-cmd/kernelshark_1.2.bb
@@ -15,6 +15,7 @@ EXTRA_OEMAKE = 'CC=${CC}' 'AR=${AR}' 'prefix=${prefix}' gui
do_install() {
oe_runmake CC=${CC} AR=${AR} prefix=${prefix} DESTDIR=${D}
install_gui
+ rm ${D}${bindir}/trace-cmd
rm -rf ${D}${datadir}/trace-cmd
rmdir ${D}${datadir}
}
--
2.0.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/8] mkefidisk.sh: Add gummiboot support
On Wednesday, July 16, 2014 02:15:59 PM Darren Hart wrote: Fixes [YOCTO 6295] Add gummiboot support for images built using: EFI_PROVIDER=gummiboot Add conditional configuration for GRUB and gummiboot. Provide some messaging about which is being performed. Signed-off-by: Darren Hart dvh...@linux.intel.com --- scripts/contrib/mkefidisk.sh | 53 ++-- 1 file changed, 41 insertions(+), 12 deletions(-) diff --git a/scripts/contrib/mkefidisk.sh b/scripts/contrib/mkefidisk.sh index 0d0674b..9b13041 100755 --- a/scripts/contrib/mkefidisk.sh +++ b/scripts/contrib/mkefidisk.sh @@ -265,31 +265,60 @@ umount $HDDIMG_ROOTFS_MNT echo Preparing boot partition... EFIDIR=$BOOTFS_MNT/EFI/BOOT mkdir -p $EFIDIR -GRUBCFG=$EFIDIR/grub.cfg cp $HDDIMG_MNT/vmlinuz $BOOTFS_MNT -# Copy the efi loader and config (booti*.efi and grub.cfg) +# Copy the efi loader and configs (booti*.efi and grub.cfg if it exists) cp $HDDIMG_MNT/EFI/BOOT/* $EFIDIR +# Silently ignore a missing gummiboot loader dir (we might just be a GRUB image) +cp -r $HDDIMG_MNT/loader $BOOTFS_MNT 2 /dev/null -# Update grub config for the installed image -# Delete the install entry -sed -i /menuentry 'install'/,/^}/d $GRUBCFG -# Delete the initrd lines -sed -i /initrd /d $GRUBCFG -# Delete any LABEL= strings -sed -i s/ LABEL=[^ ]*/ / $GRUBCFG +# Update the boot loaders configurations for an installed image # Remove any existing root= kernel parameters and: # o Add a root= parameter with the target rootfs # o Specify ro so fsck can be run during boot # o Specify rootwait in case the target media is an asyncronous block device # such as MMC or USB disks # o Specify quiet to minimize boot time when using slow serial consoles -sed -i s@ root=[^ ]*@ @ $GRUBCFG -sed -i s@vmlinuz @vmlinuz root=$TARGET_ROOTFS ro rootwait quiet @ $GRUBCFG + +# Look for a GRUB installation +GRUB_CFG=$EFIDIR/grub.cfg +if [ -e $GRUB_CFG ]; then + echo Configuring GRUB + # Delete the install entry + sed -i /menuentry 'install'/,/^}/d $GRUB_CFG + # Delete the initrd lines + sed -i /initrd /d $GRUB_CFG + # Delete any LABEL= strings + sed -i s/ LABEL=[^ ]*/ / $GRUB_CFG + + sed -i s@ root=[^ ]*@ @ $GRUB_CFG + sed -i s@vmlinuz @vmlinuz root=$TARGET_ROOTFS ro rootwait quiet @ $GRUB_CFG +fi + +# Look for a gummiboot installation +GUMMI_ENTRIES=$BOOTFS_MNT/loader/entries +GUMMI_CFG=$GUMMI_ENTRIES/boot.conf +if [ -d $GUMMI_ENTRIES ]; then + echo Configuring Gummiboot + # remove the install target if it exists + rm $GUMMI_ENTRIES/install.conf /dev/null + + if [ ! -e $GUMMI_CFG ]; then + echo ERROR: $GUMMI_CFG not found + fi + Oops, this is missing: + sed -i /initrd /d $GUMMI_CFG I have updated this git branch with this change. -- Darren + sed -i s@ root=[^ ]*@ @ $GUMMI_CFG + sed -i s@options *LABEL=boot @options LABEL=Boot root=$TARGET_ROOTFS ro rootwait quiet @ $GUMMI_CFG +fi + +# Ensure we have at least one EFI bootloader configured +if [ ! -e $GRUB_CFG ] [ ! -e $GUMMI_CFG ]; then + echo ERROR: No EFI bootloader configuration found +fi umount $BOOTFS_MNT umount $HDDIMG_MNT rm -rf $TMPDIR sync -echo Installation complete. +echo Installation complete -- Darren Hart Intel Open Source Technology Center -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/8] mkefidisk.sh: Use all caps for volume names
Avoid some mkfs warnings by using all caps in the volume names.
Signed-off-by: Darren Hart dvh...@linux.intel.com
---
scripts/contrib/mkefidisk.sh | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/scripts/contrib/mkefidisk.sh b/scripts/contrib/mkefidisk.sh
index 1992d6c..959307a 100755
--- a/scripts/contrib/mkefidisk.sh
+++ b/scripts/contrib/mkefidisk.sh
@@ -208,14 +208,14 @@ unmount_device
echo
echo Formatting $BOOTFS as vfat...
if [ ! ${DEVICE#/dev/loop} = ${DEVICE} ]; then
- mkfs.vfat -I $BOOTFS -n efi
+ mkfs.vfat -I $BOOTFS -n EFI
else
- mkfs.vfat $BOOTFS -n efi
+ mkfs.vfat $BOOTFS -n EFI
fi
echo Formatting $ROOTFS as ext3...
-mkfs.ext3 $ROOTFS -L root
+mkfs.ext3 -F $ROOTFS -L ROOT
echo Formatting swap partition...($SWAP)
mkswap $SWAP
--
2.0.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/8] mkefidisk.sh: Add mount error checking
Provide reasonable feedabck if the mount commands fail. Signed-off-by: Darren Hart dvh...@linux.intel.com --- scripts/contrib/mkefidisk.sh | 4 1 file changed, 4 insertions(+) diff --git a/scripts/contrib/mkefidisk.sh b/scripts/contrib/mkefidisk.sh index 959307a..0d0674b 100755 --- a/scripts/contrib/mkefidisk.sh +++ b/scripts/contrib/mkefidisk.sh @@ -241,7 +241,11 @@ mkdir $ROOTFS_MNT mkdir $BOOTFS_MNT mount -o loop $HDDIMG $HDDIMG_MNT +if [ $? -ne 0 ]; then echo ERROR: Failed to mount $HDDIMG; fi + mount -o loop $HDDIMG_MNT/rootfs.img $HDDIMG_ROOTFS_MNT +if [ $? -ne 0 ]; then echo ERROR: Failed to mount rootfs.img; fi + mount $ROOTFS $ROOTFS_MNT mount $BOOTFS $BOOTFS_MNT -- 2.0.0 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/8] mkefidisk.sh: Add gummiboot support
Fixes [YOCTO 6295] Add gummiboot support for images built using: EFI_PROVIDER=gummiboot Add conditional configuration for GRUB and gummiboot. Provide some messaging about which is being performed. Signed-off-by: Darren Hart dvh...@linux.intel.com --- scripts/contrib/mkefidisk.sh | 53 ++-- 1 file changed, 41 insertions(+), 12 deletions(-) diff --git a/scripts/contrib/mkefidisk.sh b/scripts/contrib/mkefidisk.sh index 0d0674b..9b13041 100755 --- a/scripts/contrib/mkefidisk.sh +++ b/scripts/contrib/mkefidisk.sh @@ -265,31 +265,60 @@ umount $HDDIMG_ROOTFS_MNT echo Preparing boot partition... EFIDIR=$BOOTFS_MNT/EFI/BOOT mkdir -p $EFIDIR -GRUBCFG=$EFIDIR/grub.cfg cp $HDDIMG_MNT/vmlinuz $BOOTFS_MNT -# Copy the efi loader and config (booti*.efi and grub.cfg) +# Copy the efi loader and configs (booti*.efi and grub.cfg if it exists) cp $HDDIMG_MNT/EFI/BOOT/* $EFIDIR +# Silently ignore a missing gummiboot loader dir (we might just be a GRUB image) +cp -r $HDDIMG_MNT/loader $BOOTFS_MNT 2 /dev/null -# Update grub config for the installed image -# Delete the install entry -sed -i /menuentry 'install'/,/^}/d $GRUBCFG -# Delete the initrd lines -sed -i /initrd /d $GRUBCFG -# Delete any LABEL= strings -sed -i s/ LABEL=[^ ]*/ / $GRUBCFG +# Update the boot loaders configurations for an installed image # Remove any existing root= kernel parameters and: # o Add a root= parameter with the target rootfs # o Specify ro so fsck can be run during boot # o Specify rootwait in case the target media is an asyncronous block device # such as MMC or USB disks # o Specify quiet to minimize boot time when using slow serial consoles -sed -i s@ root=[^ ]*@ @ $GRUBCFG -sed -i s@vmlinuz @vmlinuz root=$TARGET_ROOTFS ro rootwait quiet @ $GRUBCFG + +# Look for a GRUB installation +GRUB_CFG=$EFIDIR/grub.cfg +if [ -e $GRUB_CFG ]; then + echo Configuring GRUB + # Delete the install entry + sed -i /menuentry 'install'/,/^}/d $GRUB_CFG + # Delete the initrd lines + sed -i /initrd /d $GRUB_CFG + # Delete any LABEL= strings + sed -i s/ LABEL=[^ ]*/ / $GRUB_CFG + + sed -i s@ root=[^ ]*@ @ $GRUB_CFG + sed -i s@vmlinuz @vmlinuz root=$TARGET_ROOTFS ro rootwait quiet @ $GRUB_CFG +fi + +# Look for a gummiboot installation +GUMMI_ENTRIES=$BOOTFS_MNT/loader/entries +GUMMI_CFG=$GUMMI_ENTRIES/boot.conf +if [ -d $GUMMI_ENTRIES ]; then + echo Configuring Gummiboot + # remove the install target if it exists + rm $GUMMI_ENTRIES/install.conf /dev/null + + if [ ! -e $GUMMI_CFG ]; then + echo ERROR: $GUMMI_CFG not found + fi + + sed -i s@ root=[^ ]*@ @ $GUMMI_CFG + sed -i s@options *LABEL=boot @options LABEL=Boot root=$TARGET_ROOTFS ro rootwait quiet @ $GUMMI_CFG +fi + +# Ensure we have at least one EFI bootloader configured +if [ ! -e $GRUB_CFG ] [ ! -e $GUMMI_CFG ]; then + echo ERROR: No EFI bootloader configuration found +fi umount $BOOTFS_MNT umount $HDDIMG_MNT rm -rf $TMPDIR sync -echo Installation complete. +echo Installation complete -- 2.0.0 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 8/8] mkefidisk.sh: Reduce output and add verbose flag
Remove superfluous output from commands, add a -v verbose flag, and
cleanup output.
Signed-off-by: Darren Hart dvh...@linux.intel.com
---
scripts/contrib/mkefidisk.sh | 114 +--
1 file changed, 67 insertions(+), 47 deletions(-)
diff --git a/scripts/contrib/mkefidisk.sh b/scripts/contrib/mkefidisk.sh
index 85e58ef..7ec373e 100755
--- a/scripts/contrib/mkefidisk.sh
+++ b/scripts/contrib/mkefidisk.sh
@@ -20,6 +20,10 @@
LANG=C
+# Set to 1 to enable additional output
+DEBUG=0
+OUT=/dev/null
+
#
# Defaults
#
@@ -30,7 +34,7 @@ SWAP_RATIO=5
# Cleanup after die()
cleanup() {
- echo Syncing and unmounting devices...
+ debug Syncing and unmounting devices
# Unmount anything we mounted
unmount $ROOTFS_MNT || error Failed to unmount $ROOTFS_MNT
unmount $BOOTFS_MNT || error Failed to unmount $BOOTFS_MNT
@@ -38,7 +42,7 @@ cleanup() {
unmount $HDDIMG_MNT || error Failed to unmount $HDDIMG_MNT
# Remove the TMPDIR
- echo Removing temporary files...
+ debug Removing temporary files
if [ -d $TMPDIR ]; then
rm -rf $TMPDIR || error Failed to remove $TMPDIR
fi
@@ -71,9 +75,15 @@ die() {
cleanup
exit 1
}
+debug() {
+ if [ $DEBUG -eq 1 ]; then
+ echo $1
+ fi
+}
usage() {
- echo Usage: $(basename $0) DEVICE HDDIMG TARGET_DEVICE
+ echo Usage: $(basename $0) [-v] DEVICE HDDIMG TARGET_DEVICE
+ echo-v: Verbose debug
echoDEVICE: The device to write the image to, e.g. /dev/sdh
echoHDDIMG: The hddimg file to generate the efi disk from
echoTARGET_DEVICE: The device the target will boot from, e.g.
/dev/mmcblk0
@@ -82,7 +92,6 @@ usage() {
image_details() {
IMG=$1
info Image details
- echo =
echo image: $(stat --printf '%N\n' $IMG)
echo size: $(stat -L --printf '%s bytes\n' $IMG)
echo modified: $(stat -L --printf '%y\n' $IMG)
@@ -95,7 +104,6 @@ device_details() {
BLOCK_SIZE=512
info Device details
- echo ==
echo device: $DEVICE
if [ -f /sys/class/block/$DEV/device/vendor ]; then
echo vendor: $(cat /sys/class/block/$DEV/device/vendor)
@@ -118,7 +126,7 @@ device_details() {
unmount_device() {
grep -q $DEVICE /proc/mounts
if [ $? -eq 0 ]; then
- warn $DEVICE listed in /proc/mounts, attempting to unmount...
+ warn $DEVICE listed in /proc/mounts, attempting to unmount
umount $DEVICE* 2/dev/null
return $?
fi
@@ -128,7 +136,7 @@ unmount_device() {
unmount() {
grep -q $1 /proc/mounts
if [ $? -eq 0 ]; then
- echo Unmounting $1...
+ debug Unmounting $1
umount $1
return $?
fi
@@ -138,11 +146,17 @@ unmount() {
#
# Parse and validate arguments
#
-if [ $# -ne 3 ]; then
+if [ $# -lt 3 ] || [ $# -gt 4 ]; then
usage
exit 1
fi
+if [ $1 = -v ]; then
+ DEBUG=1
+ OUT=1
+ shift
+fi
+
DEVICE=$1
HDDIMG=$2
TARGET_DEVICE=$3
@@ -230,34 +244,39 @@ fi
TARGET_ROOTFS=$TARGET_DEVICE${TARGET_PART_PREFIX}2
TARGET_SWAP=$TARGET_DEVICE${TARGET_PART_PREFIX}3
-echo *
-echo Boot partition size: $BOOT_SIZE MB ($BOOTFS)
-echo ROOTFS partition size: $ROOTFS_SIZE MB ($ROOTFS)
-echo Swap partition size: $SWAP_SIZE MB ($SWAP)
-echo *
-
-echo Deleting partition table on $DEVICE ...
-dd if=/dev/zero of=$DEVICE bs=512 count=2 /dev/null || die Failed to zero
beginning of $DEVICE
+echo
+info Boot partition size: $BOOT_SIZE MB ($BOOTFS)
+info ROOTFS partition size: $ROOTFS_SIZE MB ($ROOTFS)
+info Swap partition size: $SWAP_SIZE MB ($SWAP)
+echo
# Use MSDOS by default as GPT cannot be reliably distributed in disk image form
# as it requires the backup table to be on the last block of the device, which
# of course varies from device to device.
-echo Creating new partition table (MSDOS) on $DEVICE ...
-parted $DEVICE mklabel msdos || die Failed to create MSDOS partition table
-echo Creating boot partition on $BOOTFS
-parted $DEVICE mkpart primary 0% $BOOT_SIZE || die Failed to create BOOT
partition
+info Partitioning installation media ($DEVICE)
-echo Enabling boot flag on $BOOTFS
-parted $DEVICE set 1 boot on || die Failed to enable boot flag
+debug Deleting partition table on $DEVICE
+dd if=/dev/zero of=$DEVICE bs=512 count=2 $OUT 21 || die Failed to zero
beginning of $DEVICE
-echo Creating ROOTFS partition on $ROOTFS
-parted $DEVICE mkpart primary $ROOTFS_START $ROOTFS_END || die Failed to
create ROOTFS partition
+debug Creating new partition table (MSDOS) on $DEVICE
+parted $DEVICE mklabel msdos $OUT 21 || die Failed to create MSDOS
partition table
-echo Creating swap partition on $SWAP
-parted $DEVICE mkpart
[OE-core] [PATCH 4/8] mkefidisk.sh: Copy the EFI dir recursively
Rather than only copying the EFI/BOOT dir, copy the entire EFI dir recursively. This allows for custom configurations to be enabled implicitly with no extra work required. Signed-off-by: Darren Hart dvh...@linux.intel.com --- scripts/contrib/mkefidisk.sh | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/scripts/contrib/mkefidisk.sh b/scripts/contrib/mkefidisk.sh index 9b13041..98c43f5 100755 --- a/scripts/contrib/mkefidisk.sh +++ b/scripts/contrib/mkefidisk.sh @@ -264,11 +264,9 @@ umount $HDDIMG_ROOTFS_MNT echo Preparing boot partition... EFIDIR=$BOOTFS_MNT/EFI/BOOT -mkdir -p $EFIDIR - cp $HDDIMG_MNT/vmlinuz $BOOTFS_MNT # Copy the efi loader and configs (booti*.efi and grub.cfg if it exists) -cp $HDDIMG_MNT/EFI/BOOT/* $EFIDIR +cp -r $HDDIMG_MNT/EFI $BOOTFS_MNT # Silently ignore a missing gummiboot loader dir (we might just be a GRUB image) cp -r $HDDIMG_MNT/loader $BOOTFS_MNT 2 /dev/null -- 2.0.0 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 6/8] mkefidisk.sh: Add die() and cleanup() routines
Currently the script will attempt to continue even after a fatal error.
Add a die() routine which will abort in the case of a fatal error and
call a cleanup() routine to unmount any images or devices and remove the
TMPDIR.
Move the variable assignment and directory creation earlier in the
script, making it more obvious what we need to clean up.
Signed-off-by: Darren Hart dvh...@linux.intel.com
---
scripts/contrib/mkefidisk.sh | 115 +--
1 file changed, 68 insertions(+), 47 deletions(-)
diff --git a/scripts/contrib/mkefidisk.sh b/scripts/contrib/mkefidisk.sh
index 530b784..6cc6b78 100755
--- a/scripts/contrib/mkefidisk.sh
+++ b/scripts/contrib/mkefidisk.sh
@@ -28,6 +28,22 @@ BOOT_SIZE=20
# 5% for swap
SWAP_RATIO=5
+# Cleanup after die()
+cleanup() {
+ echo Syncing and unmounting devices...
+ # Unmount anything we mounted
+ unmount $ROOTFS_MNT || error Failed to unmount $ROOTFS_MNT
+ unmount $BOOTFS_MNT || error Failed to unmount $BOOTFS_MNT
+ unmount $HDDIMG_ROOTFS_MNT || error Failed to unmount
$HDDIMG_ROOTFS_MNT
+ unmount $HDDIMG_MNT || error Failed to unmount $HDDIMG_MNT
+
+ # Remove the TMPDIR
+ echo Removing temporary files...
+ if [ -d $TMPDIR ]; then
+ rm -rf $TMPDIR || error Failed to remove $TMPDIR
+ fi
+}
+
# Logging routines
WARNINGS=0
ERRORS=0
@@ -50,6 +66,11 @@ warn() {
success() {
echo ${GREEN}$1${CLEAR}
}
+die() {
+ error $1
+ cleanup
+ exit 1
+}
usage() {
echo Usage: $(basename $0) DEVICE HDDIMG TARGET_DEVICE
@@ -99,14 +120,20 @@ unmount_device() {
if [ $? -eq 0 ]; then
warn $DEVICE listed in /proc/mounts, attempting to unmount...
umount $DEVICE* 2/dev/null
- grep -q $DEVICE /proc/mounts
- if [ $? -eq 0 ]; then
- error Failed to unmount $DEVICE
- exit 1
- fi
+ return $?
fi
+ return 0
}
+unmount() {
+ grep -q $1 /proc/mounts
+ if [ $? -eq 0 ]; then
+ echo Unmounting $1...
+ umount $1
+ return $?
+ fi
+ return 0
+}
#
# Parse and validate arguments
@@ -126,23 +153,24 @@ if [ $? -eq 0 ]; then
fi
if [ ! -w $DEVICE ]; then
- error Device $DEVICE does not exist or is not writable
usage
- exit 1
+ die Device $DEVICE does not exist or is not writable
fi
if [ ! -e $HDDIMG ]; then
- error HDDIMG $HDDIMG does not exist
usage
- exit 1
+ die HDDIMG $HDDIMG does not exist
fi
+#
+# Ensure the hddimg is not mounted
+#
+unmount $HDDIMG || die Failed to unmount $HDDIMG
#
# Check if any $DEVICE partitions are mounted
#
-unmount_device
-
+unmount_device || die Failed to unmount $DEVICE
#
# Confirm device with user
@@ -158,12 +186,26 @@ fi
#
+# Prepare the temporary working space
+#
+TMPDIR=$(mktemp -d mkefidisk-XXX) || die Failed to create temporary mounting
directory.
+HDDIMG_MNT=$TMPDIR/hddimg
+HDDIMG_ROOTFS_MNT=$TMPDIR/hddimg_rootfs
+ROOTFS_MNT=$TMPDIR/rootfs
+BOOTFS_MNT=$TMPDIR/bootfs
+mkdir $HDDIMG_MNT || die Failed to create $HDDIMG_MNT
+mkdir $HDDIMG_ROOTFS_MNT || die Failed to create $HDDIMG_ROOTFS_MNT
+mkdir $ROOTFS_MNT || die Failed to create $ROOTFS_MNT
+mkdir $BOOTFS_MNT || die Failed to create $BOOTFS_MNT
+
+
+#
# Partition $DEVICE
#
DEVICE_SIZE=$(parted $DEVICE unit mb print | grep ^Disk | cut -d -f 3 | sed
-e s/MB//)
# If the device size is not reported there may not be a valid label
if [ $DEVICE_SIZE = ] ; then
- parted $DEVICE mklabel msdos
+ parted $DEVICE mklabel msdos || die Failed to create MSDOS partition
table
DEVICE_SIZE=$(parted $DEVICE unit mb print | grep ^Disk | cut -d -f
3 | sed -e s/MB//)
fi
SWAP_SIZE=$((DEVICE_SIZE*SWAP_RATIO/100))
@@ -195,25 +237,25 @@ echo Swap partition size: $SWAP_SIZE MB ($SWAP)
echo *
echo Deleting partition table on $DEVICE ...
-dd if=/dev/zero of=$DEVICE bs=512 count=2
+dd if=/dev/zero of=$DEVICE bs=512 count=2 /dev/null || die Failed to zero
beginning of $DEVICE
# Use MSDOS by default as GPT cannot be reliably distributed in disk image form
# as it requires the backup table to be on the last block of the device, which
# of course varies from device to device.
echo Creating new partition table (MSDOS) on $DEVICE ...
-parted $DEVICE mklabel msdos
+parted $DEVICE mklabel msdos || die Failed to create MSDOS partition table
echo Creating boot partition on $BOOTFS
-parted $DEVICE mkpart primary 0% $BOOT_SIZE
+parted $DEVICE mkpart primary 0% $BOOT_SIZE || die Failed to create BOOT
partition
echo Enabling boot flag on $BOOTFS
-parted $DEVICE set 1 boot on
+parted $DEVICE set 1 boot on || die Failed to enable boot flag
echo Creating ROOTFS partition on $ROOTFS
-parted $DEVICE mkpart primary $ROOTFS_START $ROOTFS_END
+parted
[OE-core] [PATCH 7/8] mkefidisk.sh: Make the rootfs copy the last step
Copying the rootfs is the most time intensive task. Move it last so if we are to encounter other errors, we do so quickly and error out. Signed-off-by: Darren Hart dvh...@linux.intel.com --- scripts/contrib/mkefidisk.sh | 22 -- 1 file changed, 12 insertions(+), 10 deletions(-) diff --git a/scripts/contrib/mkefidisk.sh b/scripts/contrib/mkefidisk.sh index 6cc6b78..85e58ef 100755 --- a/scripts/contrib/mkefidisk.sh +++ b/scripts/contrib/mkefidisk.sh @@ -294,16 +294,6 @@ mount -o loop $HDDIMG_MNT/rootfs.img $HDDIMG_ROOTFS_MNT || error Failed to moun mount $ROOTFS $ROOTFS_MNT || error Failed to mount $ROOTFS on $ROOTFS_MNT mount $BOOTFS $BOOTFS_MNT || error Failed to mount $BOOTFS on $BOOTFS_MNT -echo Copying ROOTFS files... -cp -a $HDDIMG_ROOTFS_MNT/* $ROOTFS_MNT || error Root FS copy failed - -echo $TARGET_SWAP swap swap defaults 0 0 $ROOTFS_MNT/etc/fstab - -# We dont want udev to mount our root device while we're booting... -if [ -d $ROOTFS_MNT/etc/udev/ ] ; then - echo $TARGET_DEVICE $ROOTFS_MNT/etc/udev/mount.blacklist -fi - echo Preparing boot partition... EFIDIR=$BOOTFS_MNT/EFI/BOOT cp $HDDIMG_MNT/vmlinuz $BOOTFS_MNT || error Failed to copy vmlinuz @@ -356,6 +346,18 @@ if [ ! -e $GRUB_CFG ] [ ! -e $GUMMI_CFG ]; then die No EFI bootloader configuration found fi + +info Copying ROOTFS files (this may take a while) +cp -a $HDDIMG_ROOTFS_MNT/* $ROOTFS_MNT || die Root FS copy failed + +echo $TARGET_SWAP swap swap defaults 0 0 $ROOTFS_MNT/etc/fstab + +# We dont want udev to mount our root device while we're booting... +if [ -d $ROOTFS_MNT/etc/udev/ ] ; then + echo $TARGET_DEVICE $ROOTFS_MNT/etc/udev/mount.blacklist +fi + + # Call cleanup to unmount devices and images and remove the TMPDIR cleanup -- 2.0.0 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 5/8] mkefidisk.sh: Improve logging
Add logging functions: error, warn, info, and success, using tput to add
color highlighting.
Use these routines throughout the script, replacing echo statements and
adding || error in several places to eliminate silent failures. Add a
simple exit block which checks for issues encountered while running.
Signed-off-by: Darren Hart dvh...@linux.intel.com
---
scripts/contrib/mkefidisk.sh | 92 +---
1 file changed, 60 insertions(+), 32 deletions(-)
diff --git a/scripts/contrib/mkefidisk.sh b/scripts/contrib/mkefidisk.sh
index 98c43f5..530b784 100755
--- a/scripts/contrib/mkefidisk.sh
+++ b/scripts/contrib/mkefidisk.sh
@@ -28,6 +28,29 @@ BOOT_SIZE=20
# 5% for swap
SWAP_RATIO=5
+# Logging routines
+WARNINGS=0
+ERRORS=0
+CLEAR=$(tput sgr0)
+INFO=$(tput bold)
+RED=$(tput setaf 1)$(tput bold)
+GREEN=$(tput setaf 2)$(tput bold)
+YELLOW=$(tput setaf 3)$(tput bold)
+info() {
+ echo ${INFO}$1${CLEAR}
+}
+error() {
+ ERRORS=$((ERRORS+1))
+ echo ${RED}$1${CLEAR}
+}
+warn() {
+ WARNINGS=$((WARNINGS+1))
+ echo ${YELLOW}$1${CLEAR}
+}
+success() {
+ echo ${GREEN}$1${CLEAR}
+}
+
usage() {
echo Usage: $(basename $0) DEVICE HDDIMG TARGET_DEVICE
echoDEVICE: The device to write the image to, e.g. /dev/sdh
@@ -37,7 +60,7 @@ usage() {
image_details() {
IMG=$1
- echo Image details
+ info Image details
echo =
echo image: $(stat --printf '%N\n' $IMG)
echo size: $(stat -L --printf '%s bytes\n' $IMG)
@@ -50,7 +73,7 @@ device_details() {
DEV=$1
BLOCK_SIZE=512
- echo Device details
+ info Device details
echo ==
echo device: $DEVICE
if [ -f /sys/class/block/$DEV/device/vendor ]; then
@@ -74,14 +97,13 @@ device_details() {
unmount_device() {
grep -q $DEVICE /proc/mounts
if [ $? -eq 0 ]; then
- echo -n $DEVICE listed in /proc/mounts, attempting to
unmount...
+ warn $DEVICE listed in /proc/mounts, attempting to unmount...
umount $DEVICE* 2/dev/null
grep -q $DEVICE /proc/mounts
if [ $? -eq 0 ]; then
- echo FAILED
+ error Failed to unmount $DEVICE
exit 1
fi
- echo OK
fi
}
@@ -104,13 +126,13 @@ if [ $? -eq 0 ]; then
fi
if [ ! -w $DEVICE ]; then
- echo ERROR: Device $DEVICE does not exist or is not writable
+ error Device $DEVICE does not exist or is not writable
usage
exit 1
fi
if [ ! -e $HDDIMG ]; then
- echo ERROR: HDDIMG $HDDIMG does not exist
+ error HDDIMG $HDDIMG does not exist
usage
exit 1
fi
@@ -127,7 +149,7 @@ unmount_device
#
image_details $HDDIMG
device_details $(basename $DEVICE)
-echo -n Prepare EFI image on $DEVICE [y/N]?
+echo -n ${INFO}Prepare EFI image on $DEVICE [y/N]?${CLEAR}
read RESPONSE
if [ $RESPONSE != y ]; then
echo Image creation aborted
@@ -208,17 +230,16 @@ unmount_device
echo
echo Formatting $BOOTFS as vfat...
if [ ! ${DEVICE#/dev/loop} = ${DEVICE} ]; then
- mkfs.vfat -I $BOOTFS -n EFI
+ mkfs.vfat -I $BOOTFS -n EFI || error Failed to format $BOOTFS
else
- mkfs.vfat $BOOTFS -n EFI
-
+ mkfs.vfat $BOOTFS -n EFI || error Failed to format $BOOTFS
fi
echo Formatting $ROOTFS as ext3...
-mkfs.ext3 -F $ROOTFS -L ROOT
+mkfs.ext3 -F $ROOTFS -L ROOT || error Failed to format $ROOTFS
echo Formatting swap partition...($SWAP)
-mkswap $SWAP
+mkswap $SWAP || error Failed to prepare swap
#
@@ -228,7 +249,7 @@ echo
echo Mounting images and device in preparation for installation...
TMPDIR=$(mktemp -d mkefidisk-XXX)
if [ $? -ne 0 ]; then
- echo ERROR: Failed to create temporary mounting directory.
+ error Failed to create temporary mounting directory.
exit 1
fi
HDDIMG_MNT=$TMPDIR/hddimg
@@ -240,17 +261,15 @@ mkdir $HDDIMG_ROOTFS_MNT
mkdir $ROOTFS_MNT
mkdir $BOOTFS_MNT
-mount -o loop $HDDIMG $HDDIMG_MNT
-if [ $? -ne 0 ]; then echo ERROR: Failed to mount $HDDIMG; fi
+mount -o loop $HDDIMG $HDDIMG_MNT || error Failed to mount $HDDIMG
-mount -o loop $HDDIMG_MNT/rootfs.img $HDDIMG_ROOTFS_MNT
-if [ $? -ne 0 ]; then echo ERROR: Failed to mount rootfs.img; fi
+mount -o loop $HDDIMG_MNT/rootfs.img $HDDIMG_ROOTFS_MNT || error Failed to
mount rootfs.img
-mount $ROOTFS $ROOTFS_MNT
-mount $BOOTFS $BOOTFS_MNT
+mount $ROOTFS $ROOTFS_MNT || error Failed to mount $ROOTFS on $ROOTFS_MNT
+mount $BOOTFS $BOOTFS_MNT || error Failed to mount $BOOTFS on $BOOTFS_MNT
echo Copying ROOTFS files...
-cp -a $HDDIMG_ROOTFS_MNT/* $ROOTFS_MNT
+cp -a $HDDIMG_ROOTFS_MNT/* $ROOTFS_MNT || error Root FS copy failed
echo $TARGET_SWAP swap swap defaults 0 0
$ROOTFS_MNT/etc/fstab
@@ -259,14 +278,14 @@ if [ -d $ROOTFS_MNT/etc/udev
[OE-core] [PATCH 0/8] mkefidisk updates and gummiboot support
mkefidisk was in need of some improvements. This adds gummiboot support, but also adds improved logging, output formatting, robustness, error trapping, cleanup, and verbosity control. The following changes since commit 03c6fd0caab0ea8dcc2e0c3ab827a287a4f36910: ltp: use foreign automake strictness (2014-07-16 10:31:17 +0100) are available in the git repository at: git://git.yoctoproject.org/poky-contrib dvhart/mkefidisk http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=dvhart/mkefidisk Darren Hart (8): mkefidisk.sh: Use all caps for volume names mkefidisk.sh: Add mount error checking mkefidisk.sh: Add gummiboot support mkefidisk.sh: Copy the EFI dir recursively mkefidisk.sh: Improve logging mkefidisk.sh: Add die() and cleanup() routines mkefidisk.sh: Make the rootfs copy the last step mkefidisk.sh: Reduce output and add verbose flag scripts/contrib/mkefidisk.sh | 306 --- 1 file changed, 204 insertions(+), 102 deletions(-) -- 2.0.0 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] mkefidisk.sh: Allow symlink for device
Allow the user to specify a symlink as the host device. If a link is used, mkefidisk will now dereference it and use the link target when looking for sysfs information. Signed-off-by: Darren Hart dvh...@linux.intel.com --- scripts/contrib/mkefidisk.sh | 5 + 1 file changed, 5 insertions(+) diff --git a/scripts/contrib/mkefidisk.sh b/scripts/contrib/mkefidisk.sh index c86849d..1992d6c 100755 --- a/scripts/contrib/mkefidisk.sh +++ b/scripts/contrib/mkefidisk.sh @@ -98,6 +98,11 @@ DEVICE=$1 HDDIMG=$2 TARGET_DEVICE=$3 +LINK=$(readlink $DEVICE) +if [ $? -eq 0 ]; then + DEVICE=$LINK +fi + if [ ! -w $DEVICE ]; then echo ERROR: Device $DEVICE does not exist or is not writable usage -- 2.0.0 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/1] i2c-tools: Add i2c-tools to the core
On 5/28/14, 1:42, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Tue, 2014-05-27 at 13:38 -0700, Darren Hart wrote: The following changes since commit f3d62a9eb9c47356e6150fdd55f790c159e620c7: eglinfo: updated to compile with mesa10+ (2014-05-27 16:11:55 +0100) are available in the git repository at: git://git.yoctoproject.org/poky-contrib dvhart/i2c-tools http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=dvhart/i2c-tools Darren Hart (1): i2c-tools: Add i2c-tools to the core meta/recipes-devtools/i2c-tools/files/Module.mk| 72 .../i2c-tools/i2c-tools-3.1.0/Module.mk| 72 meta/recipes-devtools/i2c-tools/i2c-tools_3.1.0.bb | 26 +++ 3 files changed, 170 insertions(+) create mode 100644 meta/recipes-devtools/i2c-tools/files/Module.mk create mode 100644 meta/recipes-devtools/i2c-tools/i2c-tools-3.1.0/Module.mk create mode 100644 meta/recipes-devtools/i2c-tools/i2c-tools_3.1.0.bb I merged this, I've said I wanted this patch for long enough to multiple people, thanks! :) I removed the duplicate Module.mk file... Oops, thanks. What follow-up is necessary/appropriate with meta-oe? -- Darren Hart Open Source Technology Center darren.h...@intel.com Intel Corporation -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] ddimage: Support Mac OS
On 5/24/14, 7:44, Koen Kooi k...@dominion.thruhere.net wrote: Op 23 mei 2014, om 06:28 heeft Darren Hart dvh...@linux.intel.com het volgende geschreven: Update the ddimage script to allow it to work on Mac OS too. The biggest difference is sysfs vs diskutil and in the syntax of the stat command between Mac OS and Linux, unfortunately. Workarounds using ls, cut, and columns got really fragile really quickly. Relying on stat and switching on uname seemed the more robust solution. Signed-off-by: Darren Hart dvh...@linux.intel.com --- scripts/contrib/ddimage | 25 - 1 file changed, 20 insertions(+), 5 deletions(-) diff --git a/scripts/contrib/ddimage b/scripts/contrib/ddimage index 93ebeaf..b66d0dd 100755 --- a/scripts/contrib/ddimage +++ b/scripts/contrib/ddimage @@ -1,7 +1,8 @@ #!/bin/sh -#BLACKLIST_DEVICES=/dev/sda /dev/sdb /dev/sdc /dev/sdd /dev/sde -BLACKLIST_DEVICES=/dev/sda +# Default to avoiding the first two disks on typical Linux and Mac OS installs +# Better safe than sorry :-) +BLACKLIST_DEVICES=/dev/sda /dev/sdb /dev/disk1 /dev/disk3 s/disk3/disk2/ Bah, indeed. Local change snuck through in my patch. Thanks. Will correct. -- Darren Hart Open Source Technology Center darren.h...@intel.com Intel Corporation -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] ddimage: Support Mac OS
Update the ddimage script to allow it to work on Mac OS too. The biggest
difference is sysfs vs diskutil and in the syntax of the stat command
between Mac OS and Linux, unfortunately. Workarounds using ls, cut, and
columns got really fragile really quickly. Relying on stat and switching
on uname seemed the more robust solution.
Signed-off-by: Darren Hart dvh...@linux.intel.com
Cc: Koen Kooi k...@dominion.thruhere.net
---
v2: Correct disk3 to disk2 in the default blacklist per Koen's feedback
scripts/contrib/ddimage | 25 -
1 file changed, 20 insertions(+), 5 deletions(-)
diff --git a/scripts/contrib/ddimage b/scripts/contrib/ddimage
index 93ebeaf..a503f11 100755
--- a/scripts/contrib/ddimage
+++ b/scripts/contrib/ddimage
@@ -1,7 +1,8 @@
#!/bin/sh
-#BLACKLIST_DEVICES=/dev/sda /dev/sdb /dev/sdc /dev/sdd /dev/sde
-BLACKLIST_DEVICES=/dev/sda
+# Default to avoiding the first two disks on typical Linux and Mac OS installs
+# Better safe than sorry :-)
+BLACKLIST_DEVICES=/dev/sda /dev/sdb /dev/disk1 /dev/disk2
# 1MB blocksize
BLOCKSIZE=1048576
@@ -14,9 +15,15 @@ image_details() {
IMG=$1
echo Image details
echo =
- echo image: $(stat --printf '%N\n' $IMG)
- echo size: $(stat -L --printf '%s bytes\n' $IMG)
- echo modified: $(stat -L --printf '%y\n' $IMG)
+ echo image: $(basename $IMG)
+ # stat format is different on Mac OS and Linux
+ if [ $(uname) = Darwin ]; then
+ echo size: $(stat -L -f '%z bytes' $IMG)
+ echo modified: $(stat -L -f '%Sm' $IMG)
+ else
+ echo size: $(stat -L -c '%s bytes' $IMG)
+ echo modified: $(stat -L -c '%y' $IMG)
+ fi
echo type: $(file -L -b $IMG)
echo
}
@@ -27,6 +34,14 @@ device_details() {
echo Device details
echo ==
+
+ # Collect disk info using diskutil on Mac OS
+ if [ $(uname) = Darwin ]; then
+ diskutil info $DEVICE | egrep (Device Node|Media Name|Total
Size)
+ return
+ fi
+
+ # Default / Linux information collection
echo device: $DEVICE
if [ -f /sys/class/block/$DEV/device/vendor ]; then
echo vendor: $(cat /sys/class/block/$DEV/device/vendor)
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] i2c-tools: Add i2c-tools to the core
The following changes since commit f3d62a9eb9c47356e6150fdd55f790c159e620c7: eglinfo: updated to compile with mesa10+ (2014-05-27 16:11:55 +0100) are available in the git repository at: git://git.yoctoproject.org/poky-contrib dvhart/i2c-tools http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=dvhart/i2c-tools Darren Hart (1): i2c-tools: Add i2c-tools to the core meta/recipes-devtools/i2c-tools/files/Module.mk| 72 .../i2c-tools/i2c-tools-3.1.0/Module.mk| 72 meta/recipes-devtools/i2c-tools/i2c-tools_3.1.0.bb | 26 +++ 3 files changed, 170 insertions(+) create mode 100644 meta/recipes-devtools/i2c-tools/files/Module.mk create mode 100644 meta/recipes-devtools/i2c-tools/i2c-tools-3.1.0/Module.mk create mode 100644 meta/recipes-devtools/i2c-tools/i2c-tools_3.1.0.bb -- 1.7.9.5 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Creating a machine specific recipe for config file
On 5/27/14, 11:35, Saul Wold s...@linux.intel.com wrote:
Folks,
We have had an open enhancement in the form of bugzilla #4011
(https://bugzilla.yoctoproject.org/show_bug.cgi?id=4011).
I am currently working on this and want to get some feedback regarding
the design, the below list of config files would move to one recipe in
recipes-bsp, which will reduce the number of .bbappends that a BSP
writer might need to create in order to customize the configuration of
the BSP.
Overall, my proposal is to move all the BSP related config files into
one recipe directory tree. Create a recipe that can have a package or
packages that are RRECOMMENDS on.
We have 2 choices on the packaging side:
1) 1 Package to rule them all (conffiles)
- RPROVIDES PN-conf
- conffile.bbclass
RRECOMMENDS = ${PN}-conf
# Can be overriden in recipe
CONFFILES_conffiles ?= ${PN}.conf
- Will provide files not needed on final image, small
amount of extra space used.
2) 1 package / conf file (${PN}-conf)
- exactly what's needed will be installed
- no needs for additional RPROVIDES
- More packaging overhead, package data might be bigger than actual
contents!
The status quo would suggest that Option 2 is more consistent with what
people expect of the build system. However, if we were to do this, one
might question why we should bother at all and not just leave it in the
hands of MACHINE-specific overrides for the packages we're configuring, as
is done today with alsa-state/asound.conf (for example).
What was your idea here - to replace the MACHINE-specific config for these
packages - or to augment it with an optional mega-config package?
I think it would help to provide a bit of background/motivation regarding
what exactly we're trying to accomplish with this. That would help me form
an opinion on 1 vs 2 anyway.
--
Darren Hart Open Source Technology Center
darren.h...@intel.com Intel Corporation
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] linux-yocto-dev: Dynamic SRCREV update
The current implementation would result in the default SRCREVs being
used by the fetcher, even though the anonymous python would update them
to AUTOREV. This appears to be something to do with early parsing
bitbake black magic.
This patch ensures the default is never assigned if we are actually
building the recipe by using a function to assign it in the first place.
The USE_DEFAULT* variables are removed as they are not necessary to
allow for overriding the SRCREVs.
The anonymous python parse check is moved closer to the top of the
recipe to be a bit more logically representative of its intended
purpose.
Signed-off-by: Darren Hart dvh...@linux.intel.com
---
meta/recipes-kernel/linux/linux-yocto-dev.bb | 29 ++
1 file changed, 11 insertions(+), 18 deletions(-)
diff --git a/meta/recipes-kernel/linux/linux-yocto-dev.bb
b/meta/recipes-kernel/linux/linux-yocto-dev.bb
index 5e09720..9b49eee 100644
--- a/meta/recipes-kernel/linux/linux-yocto-dev.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-dev.bb
@@ -11,37 +11,30 @@
inherit kernel
require recipes-kernel/linux/linux-yocto.inc
-USE_MACHINE_AUTOREV ?= 1
-USE_META_AUTOREV ?= 1
-
# provide this .inc to set specific revisions
include recipes-kernel/linux/linux-yocto-dev-revisions.inc
+# Skip processing of this recipe if it is not explicitly specified as the
+# PREFERRED_PROVIDER for virtual/kernel. This avoids network access required
+# by the use of AUTOREV SRCREVs, which are the default for this recipe.
+python () {
+if d.getVar(PREFERRED_PROVIDER_virtual/kernel, True) !=
linux-yocto-dev:
+raise bb.parse.SkipPackage(Set PREFERRED_PROVIDER_virtual/kernel to
linux-yocto-dev to enable it)
+}
+
KBRANCH = standard/base
KBRANCH_DEFAULT = ${KBRANCH}
KMETA = meta
-SRC_URI =
git://git.pokylinux.org/linux-yocto-dev.git;nocheckout=1;branch=${KBRANCH},${KMETA};name=machine,meta
+SRC_URI =
git://git.yoctoproject.org/linux-yocto-dev.git;bareclone=1;branch=${KBRANCH},${KMETA};name=machine,meta
# Set default SRCREVs. Both the machine and meta SRCREVs are statically set
# to the korg v3.7 tag, and hence prevent network access during parsing. If
# linux-yocto-dev is the preferred provider, they will be overridden to
# AUTOREV in following anonymous python routine and resolved when the
# variables are finalized.
-SRCREV_machine ?= 29594404d7fe73cd80eaa4ee8c43dcc53970c60e
-SRCREV_meta ?= 29594404d7fe73cd80eaa4ee8c43dcc53970c60e
-
-python () {
-if d.getVar(PREFERRED_PROVIDER_virtual/kernel, True) !=
linux-yocto-dev:
-raise bb.parse.SkipPackage(Set PREFERRED_PROVIDER_virtual/kernel to
linux-yocto-dev to enable it)
-else:
-# if the revisions have been changed from the defaults above we leave
them
-# alone. But if the defaults are left, we change to AUTOREV.
-if d.getVar(USE_MACHINE_AUTOREV, True) == 1:
-d.setVar(SRCREV_machine, ${AUTOREV})
-if d.getVar(USE_META_AUTOREV, True) == 1:
-d.setVar(SRCREV_meta, ${AUTOREV})
-}
+SRCREV_machine ?=
'${@oe.utils.conditional(PREFERRED_PROVIDER_virtual/kernel,
linux-yocto-dev, ${AUTOREV}, 29594404d7fe73cd80eaa4ee8c43dcc53970c60e,
d)}'
+SRCREV_meta ?= '${@oe.utils.conditional(PREFERRED_PROVIDER_virtual/kernel,
linux-yocto-dev, ${AUTOREV}, 29594404d7fe73cd80eaa4ee8c43dcc53970c60e,
d)}'
LINUX_VERSION ?= 3.14+
LINUX_VERSION_EXTENSION ?= -yoctodev-${LINUX_KERNEL_TYPE}
--
1.7.9.5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] poky-tiny: ensure that both poky and poky-tiny distro overrides are used
Thanks for digging into this one Saul, On 5/23/14, 11:16, Saul Wold wrote: [YOCTO #6353] We do need to include a brief blurb in the commit message about what the problem was and why this fixes it - it can't be contained entirely in the BZ. Signed-off-by: Saul Wold s...@linux.intel.com --- meta-yocto/conf/distro/poky-tiny.conf | 2 ++ 1 file changed, 2 insertions(+) diff --git a/meta-yocto/conf/distro/poky-tiny.conf b/meta-yocto/conf/distro/poky-tiny.conf index 2548d79..5b67e32 100644 --- a/meta-yocto/conf/distro/poky-tiny.conf +++ b/meta-yocto/conf/distro/poky-tiny.conf @@ -30,6 +30,8 @@ require conf/distro/poky.conf DISTRO = poky-tiny +DISTROOVERRIDES = poky:poky-tiny ^ Whitespace issue here? + # FIXME: consider adding a new tiny feature #DISTRO_FEATURES_append = tiny Thanks Saul, -- Darren Hart Open Source Technology Center darren.h...@intel.com Intel Corporation -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] ddimage: Support Mac OS
Darren Hart (1): ddimage: Support Mac OS scripts/contrib/ddimage | 25 - 1 file changed, 20 insertions(+), 5 deletions(-) -- 1.9.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] ddimage: Support Mac OS
Update the ddimage script to allow it to work on Mac OS too. The biggest
difference is sysfs vs diskutil and in the syntax of the stat command
between Mac OS and Linux, unfortunately. Workarounds using ls, cut, and
columns got really fragile really quickly. Relying on stat and switching
on uname seemed the more robust solution.
Signed-off-by: Darren Hart dvh...@linux.intel.com
---
scripts/contrib/ddimage | 25 -
1 file changed, 20 insertions(+), 5 deletions(-)
diff --git a/scripts/contrib/ddimage b/scripts/contrib/ddimage
index 93ebeaf..b66d0dd 100755
--- a/scripts/contrib/ddimage
+++ b/scripts/contrib/ddimage
@@ -1,7 +1,8 @@
#!/bin/sh
-#BLACKLIST_DEVICES=/dev/sda /dev/sdb /dev/sdc /dev/sdd /dev/sde
-BLACKLIST_DEVICES=/dev/sda
+# Default to avoiding the first two disks on typical Linux and Mac OS installs
+# Better safe than sorry :-)
+BLACKLIST_DEVICES=/dev/sda /dev/sdb /dev/disk1 /dev/disk3
# 1MB blocksize
BLOCKSIZE=1048576
@@ -14,9 +15,15 @@ image_details() {
IMG=$1
echo Image details
echo =
- echo image: $(stat --printf '%N\n' $IMG)
- echo size: $(stat -L --printf '%s bytes\n' $IMG)
- echo modified: $(stat -L --printf '%y\n' $IMG)
+ echo image: $(basename $IMG)
+ # stat format is different on Mac OS and Linux
+ if [ $(uname) = Darwin ]; then
+ echo size: $(stat -L -f '%z bytes' $IMG)
+ echo modified: $(stat -L -f '%Sm' $IMG)
+ else
+ echo size: $(stat -L -c '%s bytes' $IMG)
+ echo modified: $(stat -L -c '%y' $IMG)
+ fi
echo type: $(file -L -b $IMG)
echo
}
@@ -27,6 +34,14 @@ device_details() {
echo Device details
echo ==
+
+ # Collect disk info using diskutil on Mac OS
+ if [ $(uname) = Darwin ]; then
+ diskutil info $DEVICE | egrep (Device Node|Media Name|Total
Size)
+ return
+ fi
+
+ # Default / Linux information collection
echo device: $DEVICE
if [ -f /sys/class/block/$DEV/device/vendor ]; then
echo vendor: $(cat /sys/class/block/$DEV/device/vendor)
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] initramfs-live-install: avoid using grub.d/40_custom
On 5/19/14, 19:49, rongqing...@windriver.com wrote:
From: Robert Yang liezhi.y...@windriver.com
Hi Robert,
Just to clarify - there is no Patch 2/2 right?
We have this in recipes-bsp/grub/grub/40_custom:
[snip]
menuentry Linux {
set root=(hd0,1)
linux /vmlinuz root=__ROOTFS__ rw __CONSOLE__ __VIDEO_MODE__ __VGA_MODE__
quiet
}
[snip]
These lines are only for initrdscripts/files/init-install.sh, the side
effect is that it would make the target's grub-mkconfig doesn't work
well since the 40_custom will be installed to /etc/grub.d/40_custom, the
grub-mkconfig will run the 40_custom, and there will always be a
'menuentry Linux' menu in grub.cfg no matter it is valid or not, we
can do this in init-install.sh rather than grub to fix the problem,
which is also much simpler.
Signed-off-by: Robert Yang liezhi.y...@windriver.com
---
meta/recipes-core/initrdscripts/files/init-install.sh | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/meta/recipes-core/initrdscripts/files/init-install.sh
b/meta/recipes-core/initrdscripts/files/init-install.sh
index 8e433d5..0ede928 100644
--- a/meta/recipes-core/initrdscripts/files/init-install.sh
+++ b/meta/recipes-core/initrdscripts/files/init-install.sh
@@ -168,17 +168,16 @@ umount /src_root
# Handling of the target boot partition
mount $bootfs /boot
echo Preparing boot partition...
-if [ -f /etc/grub.d/40_custom ] ; then
+if [ -f /etc/grub.d/00_header ] ; then
echo Preparing custom grub2 menu...
GRUBCFG=/boot/grub/grub.cfg
mkdir -p $(dirname $GRUBCFG)
-cp /etc/grub.d/40_custom $GRUBCFG
-sed -i s@__ROOTFS__@$rootfs $rootwait@g $GRUBCFG
-sed -i s/__VIDEO_MODE__/$3/g $GRUBCFG
-sed -i s/__VGA_MODE__/$4/g $GRUBCFG
-sed -i s/__CONSOLE__/$5/g $GRUBCFG
-sed -i /#/d $GRUBCFG
-sed -i /exec tail/d $GRUBCFG
+cat $GRUBCFG _EOF
+menuentry Linux {
+set root=(hd0,1)
+linux /vmlinuz root=$rootfs $rootwait rw $5 $3 $4 quiet
+}
+_EOF
OK, seems like a reasonable incremental change. What becomes of the
40_custom file itself? Should that be removed from the grub recipe as well?
Does the BSP variable APPEND get incorporated here anywhere? It's
looking like it isn't - or maybe I'm missing it?
Thanks,
--
Darren Hart Open Source Technology Center
darren.h...@intel.com Intel Corporation
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] initramfs-live-install: avoid using grub.d/40_custom
On 5/21/14, 19:07, Robert Yang wrote:
On 05/22/2014 01:43 AM, Darren Hart wrote:
On 5/19/14, 19:49, rongqing...@windriver.com wrote:
From: Robert Yang liezhi.y...@windriver.com
Hi Robert,
Just to clarify - there is no Patch 2/2 right?
Hi Darren,
Thanks, there is [PATCH 2/2] grub-2.00: remove our 40_custom:
http://lists.openembedded.org/pipermail/openembedded-core/2014-May/092736.html
I'm a little busy recently, so Roy helped me forward porting this patch,
please see my comments below.
We have this in recipes-bsp/grub/grub/40_custom:
[snip]
menuentry Linux {
set root=(hd0,1)
linux /vmlinuz root=__ROOTFS__ rw __CONSOLE__ __VIDEO_MODE__
__VGA_MODE__
quiet
}
[snip]
These lines are only for initrdscripts/files/init-install.sh, the side
effect is that it would make the target's grub-mkconfig doesn't work
well since the 40_custom will be installed to /etc/grub.d/40_custom, the
grub-mkconfig will run the 40_custom, and there will always be a
'menuentry Linux' menu in grub.cfg no matter it is valid or not, we
can do this in init-install.sh rather than grub to fix the problem,
which is also much simpler.
Signed-off-by: Robert Yang liezhi.y...@windriver.com
---
meta/recipes-core/initrdscripts/files/init-install.sh | 15
+++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/meta/recipes-core/initrdscripts/files/init-install.sh
b/meta/recipes-core/initrdscripts/files/init-install.sh
index 8e433d5..0ede928 100644
--- a/meta/recipes-core/initrdscripts/files/init-install.sh
+++ b/meta/recipes-core/initrdscripts/files/init-install.sh
@@ -168,17 +168,16 @@ umount /src_root
# Handling of the target boot partition
mount $bootfs /boot
echo Preparing boot partition...
-if [ -f /etc/grub.d/40_custom ] ; then
+if [ -f /etc/grub.d/00_header ] ; then
echo Preparing custom grub2 menu...
GRUBCFG=/boot/grub/grub.cfg
mkdir -p $(dirname $GRUBCFG)
-cp /etc/grub.d/40_custom $GRUBCFG
-sed -i s@__ROOTFS__@$rootfs $rootwait@g $GRUBCFG
-sed -i s/__VIDEO_MODE__/$3/g $GRUBCFG
-sed -i s/__VGA_MODE__/$4/g $GRUBCFG
-sed -i s/__CONSOLE__/$5/g $GRUBCFG
-sed -i /#/d $GRUBCFG
-sed -i /exec tail/d $GRUBCFG
+cat $GRUBCFG _EOF
+menuentry Linux {
+set root=(hd0,1)
+linux /vmlinuz root=$rootfs $rootwait rw $5 $3 $4 quiet
+}
+_EOF
OK, seems like a reasonable incremental change. What becomes of the
40_custom
file itself? Should that be removed from the grub recipe as well?
I'm afraid that the grub's 40_custom should be kept as other distro does:
=== begin ===
#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries. Simply
type the
# menu entries you want to add after this comment. Be careful not to
change
# the 'exec tail' line above.
=== end ===
The problem is that recipes-bsp/grub/grub/40_custom has added unneeded
lines.
Got it.
Does the BSP variable APPEND get incorporated here anywhere? It's
looking like
it isn't - or maybe I'm missing it?
Sorry, what do you mean about this, please ?
The APPEND variable is used to define any kernel command line parameters
a BSP may need to boot and function properly. We should ensure these
parameters are carried through to the installation media. I don't see
them getting transferred over anywhere. See APPEND in the reference
manual or any of many of the BSPs for examples of what goes in there.
--
Darren Hart Open Source Technology Center
darren.h...@intel.com Intel Corporation
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] linux-yocto-custom: Use SRCREV_machine
The Yocto kernel tools look for SRCREV_machine in do_validate_branches,
if it's empty, it just returns and silently continues. This likely needs
at least a warning. However, this recipe should be using SRCREV_machine,
and not just SRCREV.
Signed-off-by: Darren Hart dvh...@linux.intel.com
Reported-by: Saul Wold s...@linux.intel.com
Cc: Bruce Ashfield bruce.ashfi...@windriver.com
---
.../recipes-kernel/linux/linux-yocto-custom.bb |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb
b/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb
index 4115d2f..42162f3 100644
--- a/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb
+++ b/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb
@@ -54,7 +54,7 @@ LINUX_VERSION_EXTENSION ?= -custom
# Override SRCREV to point to a different commit in a bbappend file to
# build a different release of the Linux kernel.
# tag: v3.4 76e10d158efb6d4516018846f60c2ab5501900bc
-SRCREV=76e10d158efb6d4516018846f60c2ab5501900bc
+SRCREV_machine=76e10d158efb6d4516018846f60c2ab5501900bc
PR = r1
PV = ${LINUX_VERSION}+git${SRCPV}
--
1.7.9.5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] linux-yocto-custom: Use SRCREV_machine
On 3/14/14, 20:51, Bruce Ashfield bruce.ashfi...@gmail.com wrote:
On Fri, Mar 14, 2014 at 5:15 PM, Darren Hart dvh...@linux.intel.com
wrote:
The Yocto kernel tools look for SRCREV_machine in do_validate_branches,
if it's empty, it just returns and silently continues. This likely needs
at least a warning. However, this recipe should be using SRCREV_machine,
and not just SRCREV.
Saul had a recipe using Linus' git tree and an old rev in master. It
worked in 1.3, but not in 1.5. He found that without setting
SRCREV_machine specifically, the wrong SRCREV would be checked out, and
the subsequent patches would fail to apply. Saul can provide specifics.
Happy to have this wait until we've spelled it out correctly.
--
Darren
I can't think of anything that breaks with this .. but my spidey
senses are tingling.
This log should tell us what actually broke in the end ? What failed
to build / work
or otherwise explode ?
Bruce
Signed-off-by: Darren Hart dvh...@linux.intel.com
Reported-by: Saul Wold s...@linux.intel.com
Cc: Bruce Ashfield bruce.ashfi...@windriver.com
---
.../recipes-kernel/linux/linux-yocto-custom.bb |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb
b/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb
index 4115d2f..42162f3 100644
--- a/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb
+++ b/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb
@@ -54,7 +54,7 @@ LINUX_VERSION_EXTENSION ?= -custom
# Override SRCREV to point to a different commit in a bbappend file to
# build a different release of the Linux kernel.
# tag: v3.4 76e10d158efb6d4516018846f60c2ab5501900bc
-SRCREV=76e10d158efb6d4516018846f60c2ab5501900bc
+SRCREV_machine=76e10d158efb6d4516018846f60c2ab5501900bc
PR = r1
PV = ${LINUX_VERSION}+git${SRCPV}
--
1.7.9.5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/3] classes: Add gummiboot class
On 3/7/14, 1:57, Stanacar, StefanX stefanx.stana...@intel.com wrote:
On Thu, 2014-03-06 at 14:36 -0800, Darren Hart wrote:
On 3/6/14, 10:15, Stefan Stanacar stefanx.stana...@intel.com wrote:
Adds a gummiboot class similar to grub-efi class and makes the
necessary
changes so it can be used for live/hddimg images as well.
One can set EFI_PROVIDER = gummiboot in local.conf to use gummiboot
instead of grub-efi.
Gummiboot requires some kernel options that are not enabled by default,
so one has to build
with KERNEL_FEATURES_append = cfg/efi-ext.
cfg/efi is insufficient?
cfg/efi doesn't have CONFIG_EFI_STUB=y which is required by gummiboot.
cfg/efi-ext adds more than that, it's true.
Weird... Although the STUB should probably be in efi rather than efi-ext.
I'm surprised gummiboot requires STUB... Since STUB is there to allow the
kernel to be booted directly, no bootloader required. I guess gummiboot is
slightly less than a boot loader :-)
I'd Ack a patch to move STUB from efi-ext to efi.
It's also a good idea to enable CONFIG_EFIVARS_FS, which is the
newer/better interface than CONFIG_EFI_VARS that cfg/efi-ext enables.
Hrm... OK, perhaps time to revisit those fragments and update them for
current usage.
--
Darren
The install scripts have been updated too, keeping the old behaviour
around,
but accounting for the new boot loader config files (if they exist).
It can be argued that the installer and bootimg are a bit wierd and not
necessarily correct,
but I wanted to have the exact same behviour with gummiboot.
With the default EFI_PROVIDER = grub-efi nothing changes, everthing
should be just as before.
I've tested live boot, install and normal boot on:
- FRI2
- genericx86-64 on NUC
with:
EFI_PROVIDER = gummiboot
KERNEL_FEATURES_append = cfg/efi-ext
in local.conf.
Signed-off-by: Stefan Stanacar stefanx.stana...@intel.com
Generally looks good. My only reservation is the same as for 2/3, should
we define an EFI interface rather than having to construct function
names
in the consumers of this class?
I don't have a strong opinion here, it just seemed the simplest way atm,
then adding another interface.
Cheers,
Stefan
--
Darren
---
meta/classes/gummiboot.bbclass | 112
+
.../initrdscripts/files/init-install-efi.sh| 51 +++---
2 files changed, 147 insertions(+), 16 deletions(-)
create mode 100644 meta/classes/gummiboot.bbclass
diff --git a/meta/classes/gummiboot.bbclass
b/meta/classes/gummiboot.bbclass
new file mode 100644
index 000..5c11286
--- /dev/null
+++ b/meta/classes/gummiboot.bbclass
@@ -0,0 +1,112 @@
+EFICLASS_FUNC_PREFIX = gummiboot
+
+do_bootimg[depends] += gummiboot:do_deploy
+do_bootdirectdisk[depends] += gummiboot:do_deploy
+
+EFIDIR = /EFI/BOOT
+
+GUMMIBOOT_CFG ?= ${S}/loader.conf
+GUMMIBOOT_ENTRIES ?=
+GUMMIBOOT_TIMEOUT ?= 10
+
+gummiboot_populate() {
+DEST=$1
+
+EFI_IMAGE=gummibootia32.efi
+DEST_EFI_IMAGE=bootia32.efi
+if [ ${TARGET_ARCH} = x86_64 ]; then
+EFI_IMAGE=gummibootx64.efi
+DEST_EFI_IMAGE=bootx64.efi
+fi
+
+install -d ${DEST}${EFIDIR}
+# gummiboot requires these paths for configuration files
+# they are not customizable so no point in new vars
+install -d ${DEST}/loader
+install -d ${DEST}/loader/entries
+install -m 0644 ${DEPLOY_DIR_IMAGE}/${EFI_IMAGE}
${DEST}${EFIDIR}/${DEST_EFI_IMAGE}
+install -m 0644 ${GUMMIBOOT_CFG} ${DEST}/loader/loader.conf
+for i in ${GUMMIBOOT_ENTRIES}; do
+install -m 0644 ${i} ${DEST}/loader/entries
+done
+}
+
+gummiboot_iso_populate() {
+iso_dir=$1
+gummiboot_populate $iso_dir
+mkdir -p ${EFIIMGDIR}/${EFIDIR}
+cp $iso_dir/${EFIDIR}/* ${EFIIMGDIR}${EFIDIR}
+cp $iso_dir/vmlinuz ${EFIIMGDIR}
+echo ${DEST_EFI_IMAGE} ${EFIIMGDIR}/startup.nsh
+if [ -f $iso_dir/initrd ] ; then
+cp $iso_dir/initrd ${EFIIMGDIR}
+fi
+}
+
+gummiboot_hddimg_populate() {
+gummiboot_populate $1
+}
+
+python build_gummiboot_cfg() {
+s = d.getVar(S, True)
+labels = d.getVar('LABELS', True)
+if not labels:
+bb.debug(1, LABELS not defined, nothing to do)
+return
+
+if labels == []:
+bb.debug(1, No labels, nothing to do)
+return
+
+cfile = d.getVar('GUMMIBOOT_CFG', True)
+try:
+ cfgfile = open(cfile, 'w')
+except OSError:
+raise bb.build.funcFailed('Unable to open %s' % (cfile))
+
+cfgfile.write('# Automatically created by OE\n')
+cfgfile.write('default %s\n' % (labels.split()[0]))
+timeout = d.getVar('GUMMIBOOT_TIMEOUT', True)
+if timeout:
+cfgfile.write('timeout %s\n' % timeout)
+else:
+cfgfile.write('timeout 10\n
Re: [OE-core] [PATCH 0/4] Add gummiboot boot manager alongside grub-efi
On 3/9/14, 9:04, Stefan Stanacar stefanx.stana...@intel.com wrote:
Hello,
This series adds recipes for gummiboot and a class allowing it to be used
as the boot loader for live/hddimg images.
Without changing EFI_PROVIDER, we have the same behaviour for EFI
machines.
Using EFI_PROVIDER = gummiboot an installed image will use gummiboot
instead
of grub-efi as it's boot manager.
I've tested this on FRI2, NUC and minnow (live USB boot and install from
USB and boot)
with EFI_PROVIDER = gummiboot and KERNEL_FEATURES_append =
cfg/efi-ext
in local.conf
This is a partial fix for YB#4082.
Changes in V2:
- split the first patch in two
- used ${B} instead of ${S} in gummiboot do_deploy
- change the function names in bootimg/grub-efi instead of using a
prefix
I've tested again the changes on top of master.
This series looks much improved to me. I think it can go in as it stands.
Acked-by: Darren Hart dvh...@linux.intel.com
One thing I would like to see improved it the definition of the efi class
interface. I don't know how we do something like an abstract base class in
bb-speak, but someone wanting to add another EFI class needs to be able to
learn what the required methods and arguments are. Also, efi_populate()
isn't one of those interfaces, and that should probably not use the
generic efi_ prefix as it is effectively a gummiboot or grub-efi private
method, and should be named accordingly.
But, those are nitpics that can be cleaned up over time as we polish and
extend this mechanism. Time to get this in and get some broader
use/testing.
Ultimately, I'd like to see gummiboot as the default, but I can also just
set that in meta-intel if others do not agree.
Thank you for you efforts here Stefan!
--
Darren Hart
Yocto Project - Linux Kernel
Intel Open Source Technology Center
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/3] bootimg/grub-efi.bbclass: allow using a different class for EFI images
On 3/6/14, 10:15, Stefan Stanacar stefanx.stana...@intel.com wrote:
Abstract away some names so one can select using EFI_PROVIDER a different
class than grub-efi for populating live images, basically allowing the use
of a different bootloader than grub-efi.
Signed-off-by: Stefan Stanacar stefanx.stana...@intel.com
---
meta/classes/boot-directdisk.bbclass | 7 ---
meta/classes/bootimg.bbclass | 9 +
meta/classes/grub-efi.bbclass| 6 ++
3 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/meta/classes/boot-directdisk.bbclass
b/meta/classes/boot-directdisk.bbclass
index 42b3415..c35b4bb 100644
--- a/meta/classes/boot-directdisk.bbclass
+++ b/meta/classes/boot-directdisk.bbclass
@@ -32,7 +32,8 @@ BOOTDD_VOLUME_ID ?= boot
BOOTDD_EXTRA_SPACE ?= 16384
EFI = ${@base_contains(MACHINE_FEATURES, efi, 1, 0, d)}
-EFI_CLASS = ${@base_contains(MACHINE_FEATURES, efi, grub-efi, ,
d)}
+EFI_PROVIDER ?= grub-efi
+EFI_CLASS = ${@base_contains(MACHINE_FEATURES, efi,
${EFI_PROVIDER}, , d)}
# Include legacy boot if MACHINE_FEATURES includes pcbios or if it
does not
# contain efi. This way legacy is supported by default if neither is
@@ -87,7 +88,7 @@ build_boot_dd() {
syslinux_hddimg_populate $HDDDIR
fi
if [ ${EFI} = 1 ]; then
- grubefi_hddimg_populate $HDDDIR
+ ${EFICLASS_FUNC_PREFIX}_hddimg_populate $HDDDIR
This seems like an odd way to call a function, via a constructed function
name. Would it make more sense to define an efi interface and only one
bbclass that implemented that interface? Such as grub-efi.bbclass or
gummiboot.bbclass?
This isn't my area of expertise, maybe some recipe/bitbake experts can
weigh in here...
--
Darren Hart
Yocto Project - Linux Kernel
Intel Open Source Technology Center
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/3] classes: Add gummiboot class
)
+entrycfg.write('\n')
+entrycfg.close()
+}
+
+python build_efi_cfg() {
+bb.build.exec_func(build_gummiboot_cfg, d)
+}
diff --git a/meta/recipes-core/initrdscripts/files/init-install-efi.sh
b/meta/recipes-core/initrdscripts/files/init-install-efi.sh
index 9846637..ed3221b 100644
--- a/meta/recipes-core/initrdscripts/files/init-install-efi.sh
+++ b/meta/recipes-core/initrdscripts/files/init-install-efi.sh
@@ -104,6 +104,7 @@ parted /dev/${device} mklabel gpt
echo Creating boot partition on $bootfs
parted /dev/${device} mkpart primary 0% $boot_size
+parted /dev/${device} set 1 boot on
echo Creating rootfs partition on $rootfs
parted /dev/${device} mkpart primary $rootfs_start $rootfs_end
@@ -149,23 +150,41 @@ mount $bootfs /ssd
EFIDIR=/ssd/EFI/BOOT
mkdir -p $EFIDIR
-GRUBCFG=$EFIDIR/grub.cfg
-
cp /media/$1/vmlinuz /ssd
-# Copy the efi loader and config (booti*.efi and grub.cfg)
-cp /media/$1/EFI/BOOT/* $EFIDIR
-
-# Update grub config for the installed image
-# Delete the install entry
-sed -i /menuentry 'install'/,/^}/d $GRUBCFG
-# Delete the initrd lines
-sed -i /initrd /d $GRUBCFG
-# Delete any LABEL= strings
-sed -i s/ LABEL=[^ ]*/ / $GRUBCFG
-# Delete any root= strings
-sed -i s/ root=[^ ]*/ / $GRUBCFG
-# Add the root= and other standard boot options
-sed -i s@linux /vmlinuz *@linux /vmlinuz root=$rootfs rw $rootwait
quiet @ $GRUBCFG
+# Copy the efi loader
+cp /media/$1/EFI/BOOT/*.efi $EFIDIR
+
+if [ -f /media/$1/EFI/BOOT/grub.cfg ]; then
+GRUBCFG=$EFIDIR/grub.cfg
+cp /media/$1/EFI/BOOT/grub.cfg $GRUBCFG
+# Update grub config for the installed image
+# Delete the install entry
+sed -i /menuentry 'install'/,/^}/d $GRUBCFG
+# Delete the initrd lines
+sed -i /initrd /d $GRUBCFG
+# Delete any LABEL= strings
+sed -i s/ LABEL=[^ ]*/ / $GRUBCFG
+# Delete any root= strings
+sed -i s/ root=[^ ]*/ / $GRUBCFG
+# Add the root= and other standard boot options
+sed -i s@linux /vmlinuz *@linux /vmlinuz root=$rootfs rw $rootwait
quiet @ $GRUBCFG
+fi
+
+if [ -d /media/$1/loader ]; then
+GUMMIBOOT_CFGS=/ssd/loader/entries/*.conf
+# copy config files for gummiboot
+cp -dr /media/$1/loader /ssd
+# delete the install entry
+rm -f /ssd/loader/entries/install.conf
+# delete the initrd lines
+sed -i /initrd /d $GUMMIBOOT_CFGS
+# delete any LABEL= strings
+sed -i s/ LABEL=[^ ]*/ / $GUMMIBOOT_CFGS
+# delete any root= strings
+sed -i s/ root=[^ ]*/ / $GUMMIBOOT_CFGS
+# add the root= and other standard boot options
+sed -i s@options *@options root=$rootfs rw $rootwait quiet @
$GUMMIBOOT_CFGS
+fi
umount /ssd
sync
--
1.8.5.3
--
Darren Hart
Yocto Project - Linux Kernel
Intel Open Source Technology Center
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/3] recipes-bsp: Add gummiboot and gnu-efi recipes
On 3/6/14, 10:15, Stefan Stanacar stefanx.stana...@intel.com wrote: gummiboot is is a simple UEFI boot manager (not a boot loader ;-) ) These recipes are imported from meta-intel with these changes: - drop PR and update configure options - gummiboot was upgraded to latest version A couple of notes: - If you wish you can install the gummiboot package on the target and use 'gummiboot install' to add the payload to the ESP (see gummiboot --help, just make sure the ESP partition has the boot flag on as gummiboot won't accept it otherwise). However the point of this recipe is to be used by bootimg.bbclass and generate images with gummiboot instead of grub-efi. - You need a kernel which has CONFIG_EFI_STUB=y at least - The default linux-yocto kernel config does not enable that, easiest way to enable is to build with KERNEL_FEATURES_append = cfg/efi-ext in local.conf Signed-off-by: Stefan Stanacar stefanx.stana...@intel.com I don't know if Saul or RP would prefer gnu-efi and gummiboot to arrive as separate patches, probably a good idea. But in general, I agree with this direction: Acked-by: Darren Hart dvh...@linux.intel.com Note: Added Koen on Cc, as he happens to also have been working on something similar in his spare time. --- .../gnu-efi/gnu-efi/parallel-make-archives.patch | 48 ++ .../gnu-efi/gnu-efi/parallel-make.patch| 22 ++ meta/recipes-bsp/gnu-efi/gnu-efi_3.0u.bb | 33 +++ meta/recipes-bsp/gummiboot/gummiboot_git.bb| 25 +++ 4 files changed, 128 insertions(+) create mode 100644 meta/recipes-bsp/gnu-efi/gnu-efi/parallel-make-archives.patch create mode 100644 meta/recipes-bsp/gnu-efi/gnu-efi/parallel-make.patch create mode 100644 meta/recipes-bsp/gnu-efi/gnu-efi_3.0u.bb create mode 100644 meta/recipes-bsp/gummiboot/gummiboot_git.bb diff --git a/meta/recipes-bsp/gnu-efi/gnu-efi/parallel-make-archives.patch b/meta/recipes-bsp/gnu-efi/gnu-efi/parallel-make-archives.patch new file mode 100644 index 000..e5b47c1 --- /dev/null +++ b/meta/recipes-bsp/gnu-efi/gnu-efi/parallel-make-archives.patch @@ -0,0 +1,48 @@ +Fix parallel make failure for archives + +Upstream-Status: Pending + +The lib and gnuefi makefiles were using the lib.a() form which compiles +and ar's as a pair instead of compiling all and then ar'ing which can +parallelize better. This was resulting in build failures on larger values +of -j. + +See http://www.chemie.fu-berlin.de/chemnet/use/info/make/make_toc.html#TOC105 +for details. + +Signed-off-by: Saul Wold s...@linux.intel.com +Signed-off-by: Darren Hart dvh...@linux.intel.com +--- +--- + gnuefi/Makefile |3 ++- + lib/Makefile|3 ++- + 2 files changed, 4 insertions(+), 2 deletions(-) + +Index: gnu-efi-3.0/lib/Makefile +=== +--- gnu-efi-3.0.orig/lib/Makefile gnu-efi-3.0/lib/Makefile +@@ -66,7 +66,8 @@ all: libsubdirs libefi.a + libsubdirs: + for sdir in $(SUBDIRS); do mkdir -p $$sdir; done + +-libefi.a: $(patsubst %,libefi.a(%),$(OBJS)) ++libefi.a: $(OBJS) ++ $(AR) rv $@ $(OBJS) + + clean: + rm -f libefi.a *~ $(OBJS) */*.o +Index: gnu-efi-3.0/gnuefi/Makefile +=== +--- gnu-efi-3.0.orig/gnuefi/Makefile gnu-efi-3.0/gnuefi/Makefile +@@ -51,7 +51,8 @@ TARGETS = crt0-efi-$(ARCH).o libgnuefi.a + + all: $(TARGETS) + +-libgnuefi.a: $(patsubst %,libgnuefi.a(%),$(OBJS)) ++libgnuefi.a: $(OBJS) ++ $(AR) rv $@ $(OBJS) + + clean: + rm -f $(TARGETS) *~ *.o $(OBJS) diff --git a/meta/recipes-bsp/gnu-efi/gnu-efi/parallel-make.patch b/meta/recipes-bsp/gnu-efi/gnu-efi/parallel-make.patch new file mode 100644 index 000..27c94e8 --- /dev/null +++ b/meta/recipes-bsp/gnu-efi/gnu-efi/parallel-make.patch @@ -0,0 +1,22 @@ +Fix parallel make failure + +Upstream-Status: Submitted [Maintainer directly] + +Add a missing dependency which resulted in a race leading to failure +on larger values of -j. + +Signed-off-by: Darren Hart dvh...@linux.intel.com + +Index: gnu-efi-3.0/Makefile +=== +--- gnu-efi-3.0.orig/Makefile gnu-efi-3.0/Makefile +@@ -42,6 +42,8 @@ include $(SRCDIR)/Make.defaults + + SUBDIRS = lib gnuefi inc apps + ++gnuefi: lib ++ + all: check_gcc $(SUBDIRS) + + $(SUBDIRS): diff --git a/meta/recipes-bsp/gnu-efi/gnu-efi_3.0u.bb b/meta/recipes-bsp/gnu-efi/gnu-efi_3.0u.bb new file mode 100644 index 000..0dbdba2 --- /dev/null +++ b/meta/recipes-bsp/gnu-efi/gnu-efi_3.0u.bb @@ -0,0 +1,33 @@ +SUMMARY = Libraries for producing EFI binaries +HOMEPAGE = http://sourceforge.net/projects/gnu-efi/; +SECTION = devel +LICENSE = GPLv2+ +LIC_FILES_CHKSUM = file://debian/copyright;md5=5fb358a180f484b285b0d99acdc29666 + +SRC_URI = http://downloads.sourceforge.net/gnu-efi/gnu-efi_3.0u.orig.tar.gz \ + file://parallel-make.patch \ + file://parallel-make
Re: [OE-core] [PATCH v2 1/2] kernel-yocto: Add do_diffconfig task
On 2/16/14, 13:40, João Henrique Ferreira de Freitas joa...@gmail.com wrote: Instead of using 'diff' command between two kernel config files, the task diffconfig does the job creating the file $WORKDIR/fragment.cfg that user should review and use. [YOCTO #3862] Signed-off-by: João Henrique Ferreira de Freitas joa...@gmail.com Acked-by: Darren Hart dvh...@linux.intel.com -- Darren Hart Yocto Project - Linux Kernel Intel Open Source Technology Center ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2 2/2] cml1.bbclass: Add diffconfig task to cml1
On 2/16/14, 13:40, João Henrique Ferreira de Freitas joa...@gmail.com wrote: diffconfig() is a new task that makes a diff between the old and new config files and writes to the fragment.cfg result file. menuconfig() always copy the original config file, so the user doesn't need to copy it. Signed-off-by: João Henrique Ferreira de Freitas joa...@gmail.com Acked-by: Darren Hart dvh...@linux.intel.com -- Darren Hart Yocto Project - Linux Kernel Intel Open Source Technology Center ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] cml1.bbclass: Add fragmentconfig task to cml1
On 2/14/14, 7:46, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Thu, 2014-02-13 at 11:00 -0800, Darren Hart wrote: On 2/13/14, 3:33, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Wed, 2014-02-12 at 22:20 -0200, João Henrique Ferreira de Freitas wrote: fragmentconfig() is a new task that makes a diff between the old and new config files and writes to the fragment.cfg result file. menuconfig() always copy the original config file, so the user doesn't need to copy it. Signed-off-by: João Henrique Ferreira de Freitas joa...@gmail.com --- meta/classes/cml1.bbclass | 35 +++ 1 file changed, 35 insertions(+) diff --git a/meta/classes/cml1.bbclass b/meta/classes/cml1.bbclass index e292ecb..2053361 100644 --- a/meta/classes/cml1.bbclass +++ b/meta/classes/cml1.bbclass One more thought on this. As this is currently linux-yocto specific, does it belong in cml1.bbclass? It may make sense in busybox as well, so maybe this is the right place. RP, do you have a preference? Its starting to head in a direction we could probably use a kern-tools.bbclass to keep the code in a common place. I wonder if something like kconfig.bbclass, rather than tying it to the linux-yocto tooling (as it doesn't use any of the tooling to create the fragment). Busybox could then use this, for example (not that it couldn't include kern-tools.bbclass, it just seems a bit less natural to do so). -- Darren Hart Yocto Project - Linux Kernel Intel Open Source Technology Center ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] cml1.bbclass: Add fragmentconfig task to cml1
On 2/13/14, 3:33, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Wed, 2014-02-12 at 22:20 -0200, João Henrique Ferreira de Freitas wrote: fragmentconfig() is a new task that makes a diff between the old and new config files and writes to the fragment.cfg result file. menuconfig() always copy the original config file, so the user doesn't need to copy it. Signed-off-by: João Henrique Ferreira de Freitas joa...@gmail.com --- meta/classes/cml1.bbclass | 35 +++ 1 file changed, 35 insertions(+) diff --git a/meta/classes/cml1.bbclass b/meta/classes/cml1.bbclass index e292ecb..2053361 100644 --- a/meta/classes/cml1.bbclass +++ b/meta/classes/cml1.bbclass One more thought on this. As this is currently linux-yocto specific, does it belong in cml1.bbclass? It may make sense in busybox as well, so maybe this is the right place. RP, do you have a preference? -- Darren Hart Yocto Project - Linux Kernel Intel Open Source Technology Center ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] cml1.bbclass: Add fragmentconfig task to cml1
On 2/12/14, 16:20, João Henrique Ferreira de Freitas joa...@gmail.com
wrote:
fragmentconfig() is a new task that makes a diff between the
old and new config files and writes to the fragment.cfg result file.
menuconfig() always copy the original config file, so the user
doesn't need to copy it.
Hi João,
Generally looks pretty good. Some comments below, mostly about usability
and robustness.
I do have reservations about the task name, partly because it's long and
hard to type I'm not coming up with something I like a lot better
though Maybe
$ bitbake linux-yocto -c diffcfg
Or
$ bitbake linux-yocto -c diffconfig
I like the latter because it is consistent in naming, actionconfig, with
menuconfig.
Signed-off-by: João Henrique Ferreira de Freitas joa...@gmail.com
---
meta/classes/cml1.bbclass | 35 +++
1 file changed, 35 insertions(+)
diff --git a/meta/classes/cml1.bbclass b/meta/classes/cml1.bbclass
index e292ecb..2053361 100644
--- a/meta/classes/cml1.bbclass
+++ b/meta/classes/cml1.bbclass
@@ -16,8 +16,12 @@ HOST_LOADLIBES = -lncurses
TERMINFO = ${STAGING_DATADIR_NATIVE}/terminfo
python do_menuconfig() {
+import os
+import shutil
+
try:
mtime = os.path.getmtime(.config)
+shutil.copy(.config, .config.orig)
except OSError:
mtime = 0
@@ -38,3 +42,34 @@ do_menuconfig[depends] +=
ncurses-native:do_populate_sysroot
do_menuconfig[nostamp] = 1
addtask menuconfig after do_configure
+python do_fragmentconfig() {
+import shutil
+import subprocess
+
+workdir = d.getVar('WORKDIR', True)
+fragment = workdir + '/fragment.cfg'
+configorig = '.config.orig'
+config = '.config'
+
+try:
+md5newconfig = bb.utils.md5_file(configorig)
+md5config = bb.utils.md5_file(config)
+isdiff = md5newconfig != md5config
+except OSError:
We should be doing something to indicate failure here.
+isdiff = 0
+
+if isdiff:
+bb.note(Dumping config fragment into: '%s'. % fragment)
+bb.note(new '%s' old '%s' % (md5newconfig,md5config))
Nit, add space after ,
+
+statement = 'diff -Nurp ' + configorig + ' ' + config + '| sed
-n s/^\+//p ' + fragment
+subprocess.call(statement, shell=True)
+
+shutil.copy(configorig, config)
We should be printing something to make it easy for the user to find the
fragment.
+else:
+if os.path.exists(fragment):
+os.unlink(fragment)
+}
+
+do_fragmentconfig[nostamp] = 1
+addtask fragmentconfig
--
1.8.3.2
--
Darren Hart
Yocto Project - Linux Kernel
Intel Open Source Technology Center
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] linux-yocto/3.10: integrate LTSI
On 2/7/14, 8:48, Bruce Ashfield bruce.ashfi...@windriver.com wrote: | ERROR: Function failed: do_compile (log file is located at /home/pokybuild/yocto-autobuilder-dev/yocto-slave/nightly-x86/build/b ui l d/tmp/work/qemux86-poky-linux/linux-yocto/3.10.25+gitAUTOINC+4d658aa5 80 _ 78d2a615b1-r0/temp/log.do_compile.1426) So since this is qemux86 that is failing, and Bruce has run the qemu builds - so are we using the right SRCREVs? Machine: 78d2a615b1 Meta: 4d658aa580 This can be seen on the AB http://autobuilder.yoctoproject.org/main/builders/nightly-x86/builds/2 0/ s teps/BuildImages/logs/stdio -- Darren ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] linux-yocto/3.10: integrate LTSI
On 2/7/14, 9:24, Bruce Ashfield bruce.ashfi...@windriver.com wrote: On 14-02-07 11:55 AM, Darren Hart wrote: On 2/7/14, 8:48, Bruce Ashfield bruce.ashfi...@windriver.com wrote: | ERROR: Function failed: do_compile (log file is located at /home/pokybuild/yocto-autobuilder-dev/yocto-slave/nightly-x86/build /b ui l d/tmp/work/qemux86-poky-linux/linux-yocto/3.10.25+gitAUTOINC+4d658a a5 80 _ 78d2a615b1-r0/temp/log.do_compile.1426) So since this is qemux86 that is failing, and Bruce has run the qemu builds - so are we using the right SRCREVs? Machine: 78d2a615b1 Meta: 4d658aa580 Sorry for the spam, but is this the same issue that Nitin' fixed upstream that that I integrated this week ? I have another pending commit that updates the SRCREVs again, but I was waiting on LTSI to make it in before sending it. No, this is failing with: | drivers/built-in.o: In function `gen6_update_ring_freq': | /build/yocto/master/qemux86_20140207091321/build/tmp/work/qemux86-poky-linu x/linux-yocto/3.10.25+gitAUTOINC+4d658aa580_78d2a615b1-r0/linux/drivers/gpu /drm/i915/intel_pm.c:3876: undefined reference to `cpufreq_cpu_get' | /build/yocto/master/qemux86_20140207091321/build/tmp/work/qemux86-poky-linu x/linux-yocto/3.10.25+gitAUTOINC+4d658aa580_78d2a615b1-r0/linux/drivers/gpu /drm/i915/intel_pm.c:3879: undefined reference to `cpufreq_cpu_put' The Kconfig fix from Nitin was for generic_chip.c, this is for i915 and pm. I'll update SRCREVs and see if this resolves itself. -- Darren ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] linux-yocto: Use PACKAGE_ARCH in build dir
The current linux-yocto build dir (B) includes MACHINE. This has been
appropriate as kernels are typically built machine-specific. We have
recently introduced an intel-common type kernel which can be shared
across multiple machines sharing a common base (intel-core2-32,
intel-corei7-64). In these cases, the kernel is built for a something
more generic than MACHINE, and the current mechanism results in
something like this when building for MACHINE=sys940x (using intel-common):
tmp/work/core2-32-intel-common-poky-linux/linux-yocto-dev/ \
3.13++gitAUTOINC+e5d23e7879_889c6bec6b-r0/linux-sys940x-noemgd-standard-build
Note the descrepancy between core2-32-intel-common and
linux-sys940x-noemgd-standard-build. This becomes counterintuitive at
the very least when switching to another machine and attempting to reuse
this build. This patch swaps MACHINE for PACKAGE_ARCH (which is
typically MACHINE_ARCH for linux-yocto), resulting in the following
build path:
tmp/work/core2-32-intel-common-poky-linux/linux-yocto-dev/ \
3.13++gitAUTOINC+e5d23e7879_889c6bec6b-r0/linux-core2-32-intel-common-standard-build
The impact to existing MACHINEs is a replace of - with _ if MACHINE
contains one or more - charachters.
Signed-off-by: Darren Hart dvh...@linux.intel.com
Cc: Bruce Ashfield bruce.ashfi...@windriver.com
Cc: Richard Purdie richard.pur...@linuxfoundation.org
---
meta/recipes-kernel/linux/linux-yocto.inc |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-kernel/linux/linux-yocto.inc
b/meta/recipes-kernel/linux/linux-yocto.inc
index 2bee042..4ed3188 100644
--- a/meta/recipes-kernel/linux/linux-yocto.inc
+++ b/meta/recipes-kernel/linux/linux-yocto.inc
@@ -31,7 +31,7 @@ inherit kernel
inherit kernel-yocto
require linux-dtb.inc
-B = ${WORKDIR}/linux-${MACHINE}-${LINUX_KERNEL_TYPE}-build
+B = ${WORKDIR}/linux-${PACKAGE_ARCH}-${LINUX_KERNEL_TYPE}-build
do_install_append(){
if [ -n ${KMETA} ]; then
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] linux-yocto: Use PACKAGE_ARCH in build dir
On 2/5/14, 20:30, Bruce Ashfield bruce.ashfi...@gmail.com wrote:
On Wed, Feb 5, 2014 at 11:02 PM, Darren Hart dvh...@linux.intel.com
wrote:
The current linux-yocto build dir (B) includes MACHINE. This has been
appropriate as kernels are typically built machine-specific. We have
recently introduced an intel-common type kernel which can be shared
across multiple machines sharing a common base (intel-core2-32,
intel-corei7-64). In these cases, the kernel is built for a something
more generic than MACHINE, and the current mechanism results in
something like this when building for MACHINE=sys940x (using
intel-common):
tmp/work/core2-32-intel-common-poky-linux/linux-yocto-dev/ \
3.13++gitAUTOINC+e5d23e7879_889c6bec6b-r0/linux-sys940x-noemgd-standard-b
uild
Note the descrepancy between core2-32-intel-common and
linux-sys940x-noemgd-standard-build. This becomes counterintuitive at
the very least when switching to another machine and attempting to reuse
this build. This patch swaps MACHINE for PACKAGE_ARCH (which is
typically MACHINE_ARCH for linux-yocto), resulting in the following
build path:
tmp/work/core2-32-intel-common-poky-linux/linux-yocto-dev/ \
3.13++gitAUTOINC+e5d23e7879_889c6bec6b-r0/linux-core2-32-intel-common-sta
ndard-build
The impact to existing MACHINEs is a replace of - with _ if MACHINE
contains one or more - charachters.
Signed-off-by: Darren Hart dvh...@linux.intel.com
Cc: Bruce Ashfield bruce.ashfi...@windriver.com
Cc: Richard Purdie richard.pur...@linuxfoundation.org
---
meta/recipes-kernel/linux/linux-yocto.inc |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-kernel/linux/linux-yocto.inc
b/meta/recipes-kernel/linux/linux-yocto.inc
index 2bee042..4ed3188 100644
--- a/meta/recipes-kernel/linux/linux-yocto.inc
+++ b/meta/recipes-kernel/linux/linux-yocto.inc
@@ -31,7 +31,7 @@ inherit kernel
inherit kernel-yocto
require linux-dtb.inc
-B = ${WORKDIR}/linux-${MACHINE}-${LINUX_KERNEL_TYPE}-build
+B = ${WORKDIR}/linux-${PACKAGE_ARCH}-${LINUX_KERNEL_TYPE}-build
But for truly machine specific kernel builds, won't this cause us
collisions ?
I don't see how. Note the build paths above. For truly machine-specifc
builds, the WORKDIR is already machine-specific (because the PACKAGE_ARCH
is MACHINE_ARCH), so there is no need to specify the MACHINE in the S or B
dirs really at all. In fact, just calling this linux-build without any
other modifier would be fine I think. What I attempted here was in keeping
with the intent of the design: identify what we are building for in the B
dir.
--
Darren
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC] 'EFI' machine feature
On Thu, 2014-01-23 at 13:17 +0100, Koen Kooi wrote: Hi, Hi Koen, While working on the ARM support for GRUB I noticed that the EFI support in OE-core is a mess. A lot of it is due to GRUB insisting on its byzantine config/install/skynet system and the rest is due to the EFI==x86 assumption. Some of the horrible not-really-native grub recipe wreakage was recently improved. But it is still rather arcane, agreed. The x86-ism was just a relic for that being where support was done first. So yes, all good stuff to see improved. To improve this I'd like to start with adding an 'efi' MACHINE_FEATURE, which will: There is an efi MACHINE_FEATURE - so you want to extend that one right? * Mask non-EFI configs like grub-pc/grub-uboot We need to be careful here. It is valid to build hybrid images which support both EFI and legacy PC boot (for example). We do this now with the EFI and PCBIOS MACHINE_FEATURES - see bootimg.bbclass. So on this one point, I'd say no, don't mask them. You can make them need to specify their own MACHINE_FEATURE though. * allow PACKAGECONFIG instead of distro/arch/machine overrides in grub2 * Activate logic in image classes to create a GPT EFI System Partition I'm not following this - but this isn't my area of expertise. How does PACKAGECONFIG help us here? Also, keep in mind that while good for use on the actual device, GPT is problematic on disk images as the spec requirs the backup table on the last LBA of the disk, so using a disk image of even a slightly different size on a physical disk will result in irritating errors on boot. MSDOS partition tables are better for disk images (unfortunatley). GPT is appropriate for tools like wic, however, which do deal with the physical device. Further steps to address EFI support would be: * integrate gummiboot into OE-core (meta-intel has an old version) Yes please. Take that recipe, bump the SRCREVs, and submit it to oe-core. We've made some improvements to gummiboot recently for cross compilation and such, it would be nice to see these incorporated. * deprecate grub-(not really)native In favor of what? gummiboot? I'm all in favor of that! * create an efi bbclass that does the above ESP dance and knows how to populate it further e.g. grub.cfg and bootloader-spec entries for gummiboot. The bootimg.bbclass does something along these lines and abstracts the various calls out to syslinux, grub, grub-efi, etc. Are you looking to expand this, replace it ? * postinst magic to update bootloader config on kernel upgrade Opinions/Flames/ACPI rants? Generally speaking, this looks like the right approach. -- Darren Hart Yocto Project - Linux Kernel Intel Open Source Technology Center ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] scripts/runqemu-internal: use -cpu core2duo for qemux86-64
On Tue, 2014-01-28 at 19:16 +0200, Stefan Stanacar wrote:
Now that the tune for qemux86-64 changed to core2-64 we need to
tell the emulator to use a proper CPU model. With the default setting
of qemu64 we'll get things like:
root@qemux86-64:~# smart --help
traps: python[758] trap invalid opcode ip:7f2af01f6be7 sp:7fff49466ef0
error:0 in strop.so[7f2af01f5000+6000]
Illegal instruction
If the tune for qemux86 changes, that needs to be updated too.
Signed-off-by: Stefan Stanacar stefanx.stana...@intel.com
---
scripts/runqemu-internal | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/scripts/runqemu-internal b/scripts/runqemu-internal
index e3b0729..0893107 100755
--- a/scripts/runqemu-internal
+++ b/scripts/runqemu-internal
@@ -388,6 +388,7 @@ fi
if [ $MACHINE = qemux86-64 ]; then
QEMU=qemu-system-x86_64
+CPU_SUBTYPE=core2duo
What is it set to by default? Just right?
if [ ! -z $vga_option ]; then
QEMU_UI_OPTIONS=$QEMU_UI_OPTIONS
else
@@ -395,7 +396,7 @@ if [ $MACHINE = qemux86-64 ]; then
fi
if [ ${FSTYPE:0:3} = ext -o $FSTYPE = btrfs ]; then
KERNCMDLINE=vga=0 uvesafb.mode_option=640x480-32 root=$DROOT rw
mem=$QEMU_MEMORY $KERNEL_NETWORK_CMD
-QEMUOPTIONS=$QEMU_NETWORK_CMD $ROOTFS_OPTIONS $QEMU_UI_OPTIONS
+QEMUOPTIONS=$QEMU_NETWORK_CMD -cpu $CPU_SUBTYPE $ROOTFS_OPTIONS
$QEMU_UI_OPTIONS
So what happens here when it is empty? -cpu '' ?
--
Darren Hart
Yocto Project - Linux Kernel
Intel Open Source Technology Center
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] scripts/runqemu-internal: use -cpu core2duo for qemux86-64
On Tue, 2014-01-28 at 01:33 -0800, Darren Hart wrote:
On Tue, 2014-01-28 at 19:16 +0200, Stefan Stanacar wrote:
Now that the tune for qemux86-64 changed to core2-64 we need to
tell the emulator to use a proper CPU model. With the default setting
of qemu64 we'll get things like:
root@qemux86-64:~# smart --help
traps: python[758] trap invalid opcode ip:7f2af01f6be7 sp:7fff49466ef0
error:0 in strop.so[7f2af01f5000+6000]
Illegal instruction
If the tune for qemux86 changes, that needs to be updated too.
Signed-off-by: Stefan Stanacar stefanx.stana...@intel.com
Nevermind, all the calls below are done in the same if block where the
CPU_SUBTYPE is set. This is fine.
Acked-by: Darren Hart dvh...@linux.intel.com
---
scripts/runqemu-internal | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/scripts/runqemu-internal b/scripts/runqemu-internal
index e3b0729..0893107 100755
--- a/scripts/runqemu-internal
+++ b/scripts/runqemu-internal
@@ -388,6 +388,7 @@ fi
if [ $MACHINE = qemux86-64 ]; then
QEMU=qemu-system-x86_64
+CPU_SUBTYPE=core2duo
What is it set to by default? Just right?
if [ ! -z $vga_option ]; then
QEMU_UI_OPTIONS=$QEMU_UI_OPTIONS
else
@@ -395,7 +396,7 @@ if [ $MACHINE = qemux86-64 ]; then
fi
if [ ${FSTYPE:0:3} = ext -o $FSTYPE = btrfs ]; then
KERNCMDLINE=vga=0 uvesafb.mode_option=640x480-32 root=$DROOT rw
mem=$QEMU_MEMORY $KERNEL_NETWORK_CMD
-QEMUOPTIONS=$QEMU_NETWORK_CMD $ROOTFS_OPTIONS $QEMU_UI_OPTIONS
+QEMUOPTIONS=$QEMU_NETWORK_CMD -cpu $CPU_SUBTYPE $ROOTFS_OPTIONS
$QEMU_UI_OPTIONS
So what happens here when it is empty? -cpu '' ?
--
Darren Hart
Yocto Project - Linux Kernel
Intel Open Source Technology Center
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 06/15] tune-corei7: Add support for cpu-type corei7
corei7 offers a significant advancement since the previous core2
cpu-type described in the tune-core2 file.
From the GCC(1):
Intel Core i7 CPU with 64-bit extensions, MMX, SSE, SSE2, SSE3,
SSSE3, SSE4.1 and SSE4.2 instruction set support.
This offers optimizations for Nehalem and Silvermont (e.g. Bay Trail)
CPUs (and beyond).
Signed-off-by: Darren Hart dvh...@linux.intel.com
Cc: Richard Purdie richard.pur...@intel.com
Cc: Paul Eggleton paul.eggle...@intel.com
Cc: Tom Zanussi tom.zanu...@intel.com
Cc: Nitin Kamble nitin.a.kam...@intel.com
Cc: Mark Hatle mark.ha...@windriver.com
Cc: Bruce Ashfield bruce.ashfi...@windriver.com
---
meta/conf/machine/include/tune-corei7.inc | 35 +
1 file changed, 35 insertions(+)
create mode 100644 meta/conf/machine/include/tune-corei7.inc
diff --git a/meta/conf/machine/include/tune-corei7.inc
b/meta/conf/machine/include/tune-corei7.inc
new file mode 100644
index 000..5464fed
--- /dev/null
+++ b/meta/conf/machine/include/tune-corei7.inc
@@ -0,0 +1,35 @@
+# Settings for the GCC(1) cpu-type corei7:
+#
+# Intel Core i7 CPU with 64-bit extensions, MMX, SSE, SSE2, SSE3, SSSE3,
SSE4.1
+# and SSE4.2 instruction set support.
+#
+# This tune is recommended for Intel Nehalem and Silvermont (e.g. Bay Trail)
CPUs
+# (and beyond).
+#
+DEFAULTTUNE ?= corei7-64
+
+# Pull in the previous tune in to pull in PACKAGE_EXTRA_ARCHS
+require conf/machine/include/tune-core2.inc
+
+# Extra tune features
+TUNEVALID[corei7] = Enable corei7 specific processor optimizations
+TUNE_CCARGS .= ${@bb.utils.contains(TUNE_FEATURES, corei7,
-march=corei7 -mtune=corei7 -mfpmath=sse -msse4.2, , d)}
+
+# Extra tune selections
+AVAILTUNES += corei7-32
+TUNE_FEATURES_tune-corei7-32 = ${TUNE_FEATURES_tune-x86} corei7
+BASE_LIB_tune-corei7-32 = lib
+TUNE_PKGARCH_tune-corei7-32 = corei7_32
+PACKAGE_EXTRA_ARCHS_tune-corei7-32 = ${PACKAGE_EXTRA_ARCHS_tune-core2}
corei7_32
+
+AVAILTUNES += corei7-64
+TUNE_FEATURES_tune-corei7-64 = ${TUNE_FEATURES_tune-x86-64} corei7
+BASE_LIB_tune-corei7-64 = lib64
+TUNE_PKGARCH_tune-corei7-64 = corei7_64
+PACKAGE_EXTRA_ARCHS_tune-corei7-64 = ${PACKAGE_EXTRA_ARCHS_tune-core2-64}
corei7_64
+
+AVAILTUNES += corei7-64-x32
+TUNE_FEATURES_tune-corei7-64-x32 = ${TUNE_FEATURES_tune-x86-64-x32} corei7
+BASE_LIB_tune-corei7-64-x32 = libx32
+TUNE_PKGARCH_tune-corei7-64-x32 = corei7_64_x32
+PACKAGE_EXTRA_ARCHS_tune-corei7-64-x32 =
${PACKAGE_EXTRA_ARCHS_tune-core2-64-x32} corei7_64_x32
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 01/15] x86: Replace ia32 with x86 when referring to the generic architecture
ia32 implies 32bit, while these files provide descriptions for IA32,
X86_64, and X32 architectures. The term x86 fits this used better
without resorting to using the term Intel which isn't quite right as
it excludes things like the tune-c3 file describing a Via CPU.
Signed-off-by: Darren Hart dvh...@linux.intel.com
Cc: Richard Purdie richard.pur...@intel.com
Cc: Paul Eggleton paul.eggle...@intel.com
Cc: Tom Zanussi tom.zanu...@intel.com
Cc: Nitin Kamble nitin.a.kam...@intel.com
Cc: Mark Hatle mark.ha...@windriver.com
Cc: Bruce Ashfield bruce.ashfi...@windriver.com
---
meta/conf/machine/include/tune-c3.inc |2 +-
meta/conf/machine/include/tune-i586.inc|2 +-
meta/conf/machine/include/tune-x86_64.inc |2 +-
.../include/{ia32-base.inc = x86-base.inc}| 16
meta/conf/machine/include/{ia32 = x86}/README |6 +++---
.../{ia32/arch-ia32.inc = x86/arch-x86.inc} |2 +-
6 files changed, 15 insertions(+), 15 deletions(-)
rename meta/conf/machine/include/{ia32-base.inc = x86-base.inc} (75%)
rename meta/conf/machine/include/{ia32 = x86}/README (81%)
rename meta/conf/machine/include/{ia32/arch-ia32.inc = x86/arch-x86.inc} (97%)
diff --git a/meta/conf/machine/include/tune-c3.inc
b/meta/conf/machine/include/tune-c3.inc
index 18865b7..fafc28a 100644
--- a/meta/conf/machine/include/tune-c3.inc
+++ b/meta/conf/machine/include/tune-c3.inc
@@ -1,4 +1,4 @@
-require conf/machine/include/ia32/arch-ia32.inc
+require conf/machine/include/x86/arch-x86.inc
TUNEVALID[c3] = VIA Cyrix III or VIA C3 specific optimizations
TUNECONFLICTS[c3] = m64 mx32
diff --git a/meta/conf/machine/include/tune-i586.inc
b/meta/conf/machine/include/tune-i586.inc
index 4542b9b..a315b35 100644
--- a/meta/conf/machine/include/tune-i586.inc
+++ b/meta/conf/machine/include/tune-i586.inc
@@ -1,6 +1,6 @@
DEFAULTTUNE ?= i586
-require conf/machine/include/ia32/arch-ia32.inc
+require conf/machine/include/x86/arch-x86.inc
# Extra tune features
TUNEVALID[i586] = Enable i586 specific processor optimizations
diff --git a/meta/conf/machine/include/tune-x86_64.inc
b/meta/conf/machine/include/tune-x86_64.inc
index 31e06da..ae48124 100644
--- a/meta/conf/machine/include/tune-x86_64.inc
+++ b/meta/conf/machine/include/tune-x86_64.inc
@@ -1,4 +1,4 @@
DEFAULTTUNE ?= x86-64
-require conf/machine/include/ia32/arch-ia32.inc
+require conf/machine/include/x86/arch-x86.inc
diff --git a/meta/conf/machine/include/ia32-base.inc
b/meta/conf/machine/include/x86-base.inc
similarity index 75%
rename from meta/conf/machine/include/ia32-base.inc
rename to meta/conf/machine/include/x86-base.inc
index e15f927..421bdee 100644
--- a/meta/conf/machine/include/ia32-base.inc
+++ b/meta/conf/machine/include/x86-base.inc
@@ -1,5 +1,5 @@
#
-# base machine settings for ia32-architecture BSPs
+# Base machine settings for Intel architecture BSPs
#
#
@@ -25,28 +25,28 @@ PREFERRED_VERSION_linux-yocto ??= 3.0%
#
# XSERVER subcomponents, used to build the XSERVER variable
#
-XSERVER_IA32_BASE = xserver-xorg \
+XSERVER_INTEL_BASE = xserver-xorg \
xf86-input-mouse \
xf86-input-keyboard \
xf86-input-evdev \
xf86-input-synaptics \
-XSERVER_IA32_EXT = \
+XSERVER_INTEL_EXT = \
${@base_contains('DISTRO_FEATURES', 'opengl',
'xserver-xorg-extension-glx', '', d)} \
xserver-xorg-module-libint10 \
-XSERVER_IA32_I915 = xf86-video-intel \
+XSERVER_INTEL_I915 = xf86-video-intel \
${@base_contains('DISTRO_FEATURES', 'opengl', 'mesa-driver-i915',
'', d)} \
-XSERVER_IA32_I965 = xf86-video-intel \
+XSERVER_INTEL_I965 = xf86-video-intel \
${@base_contains('DISTRO_FEATURES', 'opengl', 'mesa-driver-i965',
'', d)} \
-XSERVER_IA32_VESA = xf86-video-vesa
+XSERVER_INTEL_VESA = xf86-video-vesa
-XSERVER_IA32_FBDEV = xf86-video-fbdev
+XSERVER_INTEL_FBDEV = xf86-video-fbdev
-XSERVER_IA32_MODESETTING = xf86-video-modesetting
+XSERVER_INTEL_MODESETTING = xf86-video-modesetting
diff --git a/meta/conf/machine/include/ia32/README
b/meta/conf/machine/include/x86/README
similarity index 81%
rename from meta/conf/machine/include/ia32/README
rename to meta/conf/machine/include/x86/README
index 8f80a5b..d8b6793 100644
--- a/meta/conf/machine/include/ia32/README
+++ b/meta/conf/machine/include/x86/README
@@ -1,12 +1,12 @@
2012/03/30 - Mark Hatle mark.ha...@windriver.com
- Initial version
-Most of the items for the IA architecture are defined in the single
-arch-ia32 file.
+Most of the items for the Intel architectures are defined in the single
+arch-x86 file.
Three ABIs are define, m32, mx32 and m64.
-The following is the list of ia32 specific variables:
+The following is the list of intel specific variables:
X86ARCH32 - This is the 32-bit architecture GNU canonical arch, TUNE_ARCH.
diff --git a/meta/conf/machine/include/ia32/arch-ia32.inc
b/meta
[OE-core] [PATCH 11/15] qemux86_64: Use the core2-64 tune
As x86_64 has been demoted to an ABI definition rather than a concrete tune file, replace it with core2-64 for the qemux86-64 machine. Signed-off-by: Darren Hart dvh...@linux.intel.com --- meta/conf/machine/qemux86-64.conf |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/meta/conf/machine/qemux86-64.conf b/meta/conf/machine/qemux86-64.conf index c572225..6533e56 100644 --- a/meta/conf/machine/qemux86-64.conf +++ b/meta/conf/machine/qemux86-64.conf @@ -8,7 +8,8 @@ PREFERRED_PROVIDER_virtual/libgles1 ?= mesa PREFERRED_PROVIDER_virtual/libgles2 ?= mesa require conf/machine/include/qemu.inc -require conf/machine/include/tune-x86_64.inc +DEFAULTTUNE ?= core2-64 +require conf/machine/include/tune-core2.inc KERNEL_IMAGETYPE = bzImage -- 1.7.9.5 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 00/15] Update x86 tune files
All,
The following lays the groundwork for some rethinking of support for x86
platforms. In particular, the meta-intel layer will undergo some major
refactoring once this is merged. We believe it is of value to keep as much
of the tune files available in oe-core as possible, rather than isolating
them all in meta-intel.
This series renames the x86-related tune files, documents best practices,
updates the core2 tune file, adds a corei7 tune file, and updates the dependent
machine configs. This spans oe-core and poky and I feel is best viewed as a
whole. Please forgive the cross-post.
The new corei7 tune file applies to Nehalem and Silvermont (Bay Trail) CPUs
which support up to SSE4.2. This provides an appropriate demarcation line while
maximizing compatibility as well as including optimal support for the current
generation of the embedded CPUs (Bay Trail) by including it in the new tune. AVX
(Sandy Bridge and beyond) is not included as that would not apply to Bay Trail,
although it can easily be added in a corei7-avx tune file as an additional
patch for users who care more about the last few percent of performance over
compatibility and consolidation.
An important note and likely a point of contention: The core2 update changes the
core2 arch to core2-32, making the 32 bit explicit rather than implied in order
to provide a consistent naming scheme going forward with newer tunes where
64 bit would be logical assumption if not explicitly stated. See patch 5/15 for
details on this bit.
Finally, update the machines dependent on these tune files to use the new names.
As we remove x86_64, the 64b x86 machines now build as core2-64 for maximum
compatibility.
For reference, the corei7-64 tune defines:
TARGET_CC_ARCH= -m64 -march=corei7 -mtune=corei7 -mfpmath=sse -msse4.2
While the corei2-32 tune defines:
TARGET_CC_ARCH= -m32 -march=core2 -mtune=core2 -msse3 -mfpmath=sse
The following changes since commit 6e7047434fc1570146ebc94254412b99b1c4cab4:
poky.ent: Fixed broken OE_LISTS_URL. (2014-01-21 21:58:03 +)
are available in the git repository at:
git://git.yoctoproject.org/poky-contrib dvhart/intel-tune-ng-v3
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=dvhart/intel-tune-ng-v3
Darren Hart (15):
x86: Replace ia32 with x86 when referring to the generic architecture
i586: Only add the current tune to PACKAGE_EXTRA_ARCHS
tune-core2: Replace -mtune=generic with -mtune=core2
tune-core2: Only add the current ARCH to PACKAGE_EXTRA_ARCHS
tune: Make 32b or 64b explicit in tune name for core2
tune-corei7: Add support for cpu-type corei7
tune: Remove tune-x86_64.inc
tune: README: Whitespace cleanup
tune: README: Document best practice
tune: README: Typographical corrections
qemux86_64: Use the core2-64 tune
genericx86: Use the core2 tune file
genericx86-64: Use the core2-64 tune
genericx86: Use new x86 tune files
generixx86: Use require instead of include
meta-yocto-bsp/conf/machine/genericx86-64.conf |5 +-
meta-yocto-bsp/conf/machine/genericx86.conf|5 +-
.../conf/machine/include/genericx86-common.inc |2 +-
meta/conf/machine/include/README | 109
meta/conf/machine/include/tune-c3.inc |2 +-
meta/conf/machine/include/tune-core2.inc | 23 +++--
meta/conf/machine/include/tune-corei7.inc | 35 +++
meta/conf/machine/include/tune-i586.inc|4 +-
meta/conf/machine/include/tune-x86_64.inc |4 -
.../include/{ia32-base.inc = x86-base.inc}| 16 +--
meta/conf/machine/include/{ia32 = x86}/README |6 +-
.../{ia32/arch-ia32.inc = x86/arch-x86.inc} |2 +-
meta/conf/machine/qemux86-64.conf |3 +-
13 files changed, 139 insertions(+), 77 deletions(-)
create mode 100644 meta/conf/machine/include/tune-corei7.inc
delete mode 100644 meta/conf/machine/include/tune-x86_64.inc
rename meta/conf/machine/include/{ia32-base.inc = x86-base.inc} (75%)
rename meta/conf/machine/include/{ia32 = x86}/README (81%)
rename meta/conf/machine/include/{ia32/arch-ia32.inc = x86/arch-x86.inc} (97%)
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 09/15] tune: README: Document best practice
Describe the expected usage of base architecture tune files and arch-specific files, specifically the stacking of generations. Signed-off-by: Darren Hart dvh...@linux.intel.com Cc: Richard Purdie richard.pur...@intel.com Cc: Paul Eggleton paul.eggle...@intel.com Cc: Tom Zanussi tom.zanu...@intel.com Cc: Nitin Kamble nitin.a.kam...@intel.com Cc: Mark Hatle mark.ha...@windriver.com Cc: Bruce Ashfield bruce.ashfi...@windriver.com --- meta/conf/machine/include/README | 19 +++ 1 file changed, 19 insertions(+) diff --git a/meta/conf/machine/include/README b/meta/conf/machine/include/README index 65d0942..6c390ad 100644 --- a/meta/conf/machine/include/README +++ b/meta/conf/machine/include/README @@ -1,6 +1,9 @@ 2012/03/30 - Mark Hatle mark.ha...@windriver.com - Initial Revision + +Introduction + The individual CPU, and ABI tunings are contained in this directory. A number of local and global variables are used to control the way the tunings are setup and how they work together to specify an optimized @@ -79,3 +82,19 @@ configured in the same way that TUNE_CCARGS is. BASE_LIB_tune-tune - The /lib location for a specific ABI. This is used in a multilib configuration to place the libraries in the correct, non-conflicting locations. + + +Best Practice += +The tune infrastructure is designed to be hierarchical. When writing a +new tune file for a fast-forward CPU architecture (one that supports +everything from a previous generation), it is recommended to require the +previous generation tune file and specify PACKAGE_EXTRA_ARCHS using the +previous generation's override and appending the new tune. Note that +only one previous tune file should be included to avoid mutiple includes +of the base arch which could lead to a broken configuration due to +multiple prepend and append assignments. + +For example, for x86, there is a common x86/arch-x86.inc which is +included in the base i586 tune file. The core2 tune builds +on that, and corei7 builds on core2. -- 1.7.9.5 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 10/15] tune: README: Typographical corrections
No new content, just correcting a few typographical errors.
Signed-off-by: Darren Hart dvh...@linux.intel.com
Cc: Richard Purdie richard.pur...@intel.com
Cc: Paul Eggleton paul.eggle...@intel.com
Cc: Tom Zanussi tom.zanu...@intel.com
Cc: Nitin Kamble nitin.a.kam...@intel.com
Cc: Mark Hatle mark.ha...@windriver.com
Cc: Bruce Ashfield bruce.ashfi...@windriver.com
---
meta/conf/machine/include/README |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/meta/conf/machine/include/README b/meta/conf/machine/include/README
index 6c390ad..d66130a 100644
--- a/meta/conf/machine/include/README
+++ b/meta/conf/machine/include/README
@@ -53,10 +53,10 @@ list should be dynamic! i.e.
${@bb.utils.contains(TUNE_FEATURES, feature, cflag, !cflag, d)}
TUNE_ARCH - The GNU canonical arch for a specific architecture. i.e.
-arm, armeb, mips, mips64, etc. This value is by bitbake to setup
+arm, armeb, mips, mips64, etc. This value is used by bitbake to setup
configure. TUNE_ARCH definitions are specific to a given architecture.
-They may be a single static definitions, or may be dynamically adjusted.
-See each architectures README for details for that CPU family.
+They may be a single static definition, or may be dynamically adjusted.
+See each architecture's README for details for that CPU family.
TUNE_PKGARCH - The package architecture used by the packaging systems to
define the architecture, abi and tuning of a particular package.
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 02/15] i586: Only add the current tune to PACKAGE_EXTRA_ARCHS
The generic x86 build supports i586 by default, so this specific tune
file technically doesn't add any specific ARCHes to PACKAGE_EXTRA_ARCHS.
For consistency, append the current tune to PACKAGE_EXTRA_ARCHS.
Since we do not have specific tune files for i386 and i486, just drop
them.
These could be added to tune-x86 version if there is a need to
maintain them, but they really do not belong here.
Signed-off-by: Darren Hart dvh...@linux.intel.com
Cc: Richard Purdie richard.pur...@intel.com
Cc: Paul Eggleton paul.eggle...@intel.com
Cc: Tom Zanussi tom.zanu...@intel.com
Cc: Nitin Kamble nitin.a.kam...@intel.com
Cc: Mark Hatle mark.ha...@windriver.com
Cc: Bruce Ashfield bruce.ashfi...@windriver.com
---
meta/conf/machine/include/tune-i586.inc |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/conf/machine/include/tune-i586.inc
b/meta/conf/machine/include/tune-i586.inc
index a315b35..5fbb3c7 100644
--- a/meta/conf/machine/include/tune-i586.inc
+++ b/meta/conf/machine/include/tune-i586.inc
@@ -11,4 +11,4 @@ AVAILTUNES += i586
TUNE_FEATURES_tune-i586 = ${TUNE_FEATURES_tune-x86} i586
BASE_LIB_tune-i586 = lib
TUNE_PKGARCH_tune-i586 = i586
-PACKAGE_EXTRA_ARCHS_tune-i586 = ${PACKAGE_EXTRA_ARCHS_tune-x86} i386 i486
i586
+PACKAGE_EXTRA_ARCHS_tune-i586 = ${PACKAGE_EXTRA_ARCHS_tune-x86} i586
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 14/15] genericx86: Use new x86 tune files
Use the new names for the x86 tunes files (x86 instead of ia32). Signed-off-by: Darren Hart dvh...@linux.intel.com --- .../conf/machine/include/genericx86-common.inc |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta-yocto-bsp/conf/machine/include/genericx86-common.inc b/meta-yocto-bsp/conf/machine/include/genericx86-common.inc index c5ef358..8b24c18 100644 --- a/meta-yocto-bsp/conf/machine/include/genericx86-common.inc +++ b/meta-yocto-bsp/conf/machine/include/genericx86-common.inc @@ -1,4 +1,4 @@ -include conf/machine/include/ia32-base.inc +include conf/machine/include/x86-base.inc MACHINE_FEATURES += wifi efi pcbios PREFERRED_PROVIDER_virtual/kernel ?= linux-yocto -- 1.7.9.5 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 03/15] tune-core2: Replace -mtune=generic with -mtune=core2
-march specifies which ISA to use. -mtune specifies which cpu-type to
optimize instruction ordering for, but not which ISA to use. There are
times when it may make sense to specify mtune=generic and use a more
specific march, such as core2, but the opposite makes little sense at
all: use cpu-type specific ISA, but order the instructions
generically. While the -mtune is implied by -march, gcc does not verify
it is using -mtune=core2 with:
gcc -Q -march=core2 --help=target
Explicitly specify -mtune=core2 to be sure.
Add a comment header describing the CPUs targeted by this tune file.
Signed-off-by: Darren Hart dvh...@linux.intel.com
Cc: Richard Purdie richard.pur...@intel.com
Cc: Paul Eggleton paul.eggle...@intel.com
Cc: Tom Zanussi tom.zanu...@intel.com
Cc: Nitin Kamble nitin.a.kam...@intel.com
Cc: Mark Hatle mark.ha...@windriver.com
Cc: Bruce Ashfield bruce.ashfi...@windriver.com
---
meta/conf/machine/include/tune-core2.inc | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/meta/conf/machine/include/tune-core2.inc
b/meta/conf/machine/include/tune-core2.inc
index 85b6924..3b25197 100644
--- a/meta/conf/machine/include/tune-core2.inc
+++ b/meta/conf/machine/include/tune-core2.inc
@@ -1,10 +1,18 @@
+# Settings for the GCC(1) cpu-type core2:
+#
+# Intel Core2 CPU with 64-bit extensions, MMX, SSE, SSE2, SSE3 and SSSE3
+# instruction set support.
+#
+# This tune is recommended for the Intel Core 2 CPU family, including Conroe,
+# Merom and beyond, as well as the first Atom CPUs, Diamondville, and beyond.
+#
DEFAULTTUNE ?= core2
require conf/machine/include/tune-i586.inc
# Extra tune features
TUNEVALID[core2] = Enable core2 specific processor optimizations
-TUNE_CCARGS .= ${@bb.utils.contains(TUNE_FEATURES, core2, -march=core2
-msse3 -mtune=generic -mfpmath=sse, , d)}
+TUNE_CCARGS .= ${@bb.utils.contains(TUNE_FEATURES, core2, -march=core2
-mtune=core2 -msse3 -mfpmath=sse, , d)}
# Extra tune selections
AVAILTUNES += core2
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 15/15] generixx86: Use require instead of include
Use require instead of include to avoid silent errors when the required tune files change name or are moved. It's going to fail anyway, it might as well fail with an error message that is immediately helpful. Signed-off-by: Darren Hart dvh...@linux.intel.com --- meta-yocto-bsp/conf/machine/genericx86-64.conf |4 ++-- meta-yocto-bsp/conf/machine/genericx86.conf|4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/meta-yocto-bsp/conf/machine/genericx86-64.conf b/meta-yocto-bsp/conf/machine/genericx86-64.conf index a6154cd..f76e35a 100644 --- a/meta-yocto-bsp/conf/machine/genericx86-64.conf +++ b/meta-yocto-bsp/conf/machine/genericx86-64.conf @@ -4,5 +4,5 @@ #@DESCRIPTION: Machine configuration for generic X86_64 (64-bit) PCs and servers. Supports a moderately wide range of drivers that should boot and be usable on typical hardware. DEFAULTTUNE ?= core2-64 -include conf/machine/include/tune-core2.inc -include conf/machine/include/genericx86-common.inc +require conf/machine/include/tune-core2.inc +require conf/machine/include/genericx86-common.inc diff --git a/meta-yocto-bsp/conf/machine/genericx86.conf b/meta-yocto-bsp/conf/machine/genericx86.conf index 549fc8e..2642cab 100644 --- a/meta-yocto-bsp/conf/machine/genericx86.conf +++ b/meta-yocto-bsp/conf/machine/genericx86.conf @@ -4,5 +4,5 @@ #@DESCRIPTION: Machine configuration for generic X86 (32-bit) PCs. Supports a moderately wide range of drivers that should boot and be usable on typical hardware. DEFAULTTUNE ?= core2-32 -include conf/machine/include/tune-core2.inc -include conf/machine/include/genericx86-common.inc +require conf/machine/include/tune-core2.inc +require conf/machine/include/genericx86-common.inc -- 1.7.9.5 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 08/15] tune: README: Whitespace cleanup
Before making content changes, cleanup the various whitespace errors in
this file. Mostly end-of-line whitepsace.
Signed-off-by: Darren Hart dvh...@linux.intel.com
Cc: Richard Purdie richard.pur...@intel.com
Cc: Paul Eggleton paul.eggle...@intel.com
Cc: Tom Zanussi tom.zanu...@intel.com
Cc: Nitin Kamble nitin.a.kam...@intel.com
Cc: Mark Hatle mark.ha...@windriver.com
Cc: Bruce Ashfield bruce.ashfi...@windriver.com
---
meta/conf/machine/include/README | 88 +++---
1 file changed, 44 insertions(+), 44 deletions(-)
diff --git a/meta/conf/machine/include/README b/meta/conf/machine/include/README
index e4b59c9..65d0942 100644
--- a/meta/conf/machine/include/README
+++ b/meta/conf/machine/include/README
@@ -1,27 +1,27 @@
2012/03/30 - Mark Hatle mark.ha...@windriver.com
- Initial Revision
-The individual CPU, and ABI tunings are contained in this directory. A
-number of local and global variables are used to control the way the
-tunings are setup and how they work together to specify an optimized
+The individual CPU, and ABI tunings are contained in this directory. A
+number of local and global variables are used to control the way the
+tunings are setup and how they work together to specify an optimized
configuration.
-The following is brief summary of the generic components that are used
+The following is brief summary of the generic components that are used
in these tunings.
-AVAILTUNES - This is a list of all of the tuning definitions currently
-available in the system. Not all tunes in this list may be compatible
-with the machine configuration, or each other in a multilib
-configuration. Each tuning file can add to this list using +=, but
+AVAILTUNES - This is a list of all of the tuning definitions currently
+available in the system. Not all tunes in this list may be compatible
+with the machine configuration, or each other in a multilib
+configuration. Each tuning file can add to this list using +=, but
should never replace the list using =.
-DEFAULTTUNE - This specifies the tune to use for a particular build.
-Each tune should specify a reasonable default, which can be overriden by
-a machine or multilib configuration. The specified tune must be listed
+DEFAULTTUNE - This specifies the tune to use for a particular build.
+Each tune should specify a reasonable default, which can be overriden by
+a machine or multilib configuration. The specified tune must be listed
in the AVAILTUNES.
-TUNEVALID[feature] - The feature is defined with a human readable
-explanation for what it does. All architectural, cpu, abi, etc tuning
+TUNEVALID[feature] - The feature is defined with a human readable
+explanation for what it does. All architectural, cpu, abi, etc tuning
features must be defined using TUNEVALID.
TUNECONFLICTS[feature] - A list of features which conflict with feature.
@@ -31,51 +31,51 @@ tuning ends up with features which conflict with each other.
TUNE_FEATURES - This is automatically defined as TUNE_FEATURES_tune-tune.
See TUNE_FEATURES_tune-tune for more information.
-TUNE_FEATURES_tune-tune - Specify the features used to describe a
-specific tune. This is a list of features that a tune support, each
-feature must be in the TUNEVALID list. Note: the tune and a given
-feature name may be the same, but they have different purposes. Only
-features may be used to change behavior, while tunes are used to
+TUNE_FEATURES_tune-tune - Specify the features used to describe a
+specific tune. This is a list of features that a tune support, each
+feature must be in the TUNEVALID list. Note: the tune and a given
+feature name may be the same, but they have different purposes. Only
+features may be used to change behavior, while tunes are used to
describe an overall set of features.
-ABIEXTENSION - An ABI extension may be specified by a specific feature
-or other tuning setting, such as TARGET_FPU. Any ABI extensions either
-need to be defined in the architectures base arch file, i.e.
-ABIEXTENSION = eabi in the arm case, or appended to in specific tune
+ABIEXTENSION - An ABI extension may be specified by a specific feature
+or other tuning setting, such as TARGET_FPU. Any ABI extensions either
+need to be defined in the architectures base arch file, i.e.
+ABIEXTENSION = eabi in the arm case, or appended to in specific tune
files with a .=. Spaces are not allowed in this variable.
-TUNE_CCARGS - Setup the cflags based on the TUNE_FEATURES settings.
-These should be additive when defined using +=. All items in this
-list should be dynamic! i.e.
+TUNE_CCARGS - Setup the cflags based on the TUNE_FEATURES settings.
+These should be additive when defined using +=. All items in this
+list should be dynamic! i.e.
${@bb.utils.contains(TUNE_FEATURES, feature, cflag, !cflag, d)}
-TUNE_ARCH - The GNU canonical arch for a specific architecture. i.e.
-arm, armeb, mips, mips64, etc. This value is by bitbake
[OE-core] [PATCH 13/15] genericx86-64: Use the core2-64 tune
As x86_64 has been demoted to an ABI definition rather than a concrete tune file, replace it with core2-64 for the genericx86-64 machine. Signed-off-by: Darren Hart dvh...@linux.intel.com --- meta-yocto-bsp/conf/machine/genericx86-64.conf |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/meta-yocto-bsp/conf/machine/genericx86-64.conf b/meta-yocto-bsp/conf/machine/genericx86-64.conf index 56e9bb6..a6154cd 100644 --- a/meta-yocto-bsp/conf/machine/genericx86-64.conf +++ b/meta-yocto-bsp/conf/machine/genericx86-64.conf @@ -3,5 +3,6 @@ #@DESCRIPTION: Machine configuration for generic X86_64 (64-bit) PCs and servers. Supports a moderately wide range of drivers that should boot and be usable on typical hardware. -include conf/machine/include/tune-x86_64.inc +DEFAULTTUNE ?= core2-64 +include conf/machine/include/tune-core2.inc include conf/machine/include/genericx86-common.inc -- 1.7.9.5 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 12/15] genericx86: Use the core2 tune file
Aside from the movbe and specialized instruction scheduling for the lack of out-of-order scheduling in the older Atom CPUs, the core2 tune covers these CPUs adequately. Since the current atom tune just uses core2 anyway, go ahead and make this explicit here. Signed-off-by: Darren Hart dvh...@linux.intel.com --- meta-yocto-bsp/conf/machine/genericx86.conf |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/meta-yocto-bsp/conf/machine/genericx86.conf b/meta-yocto-bsp/conf/machine/genericx86.conf index 9d29f62..549fc8e 100644 --- a/meta-yocto-bsp/conf/machine/genericx86.conf +++ b/meta-yocto-bsp/conf/machine/genericx86.conf @@ -3,5 +3,6 @@ #@DESCRIPTION: Machine configuration for generic X86 (32-bit) PCs. Supports a moderately wide range of drivers that should boot and be usable on typical hardware. -include conf/machine/include/tune-atom.inc +DEFAULTTUNE ?= core2-32 +include conf/machine/include/tune-core2.inc include conf/machine/include/genericx86-common.inc -- 1.7.9.5 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 05/15] tune: Make 32b or 64b explicit in tune name for core2
Core2 has both a 32b and a 64b variant. Currently, core2 implies 32b,
while core2_64 is the 64b version. This implicit 32b mode will become
confusing in later architectures, such as corei7, where it would be
natural for people to assume corei7 meant 64 bit.
Rather than carrying forward an implicit 32b mode and rather than
changing the naming scheme part way through the architecture hiearchy,
make the 32b and 64b variant explicit in the tune name by changing core2
to core2_32.
Signed-off-by: Darren Hart dvh...@linux.intel.com
---
meta/conf/machine/include/tune-core2.inc | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/meta/conf/machine/include/tune-core2.inc
b/meta/conf/machine/include/tune-core2.inc
index 2500a74..11517dc 100644
--- a/meta/conf/machine/include/tune-core2.inc
+++ b/meta/conf/machine/include/tune-core2.inc
@@ -6,7 +6,7 @@
# This tune is recommended for the Intel Core 2 CPU family, including Conroe,
# Merom and beyond, as well as the first Atom CPUs, Diamondville, and beyond.
#
-DEFAULTTUNE ?= core2
+DEFAULTTUNE ?= core2-32
# Include the previous tune to pull in PACKAGE_EXTRA_ARCHS
require conf/machine/include/tune-i586.inc
@@ -16,11 +16,11 @@ TUNEVALID[core2] = Enable core2 specific processor
optimizations
TUNE_CCARGS .= ${@bb.utils.contains(TUNE_FEATURES, core2, -march=core2
-mtune=core2 -msse3 -mfpmath=sse, , d)}
# Extra tune selections
-AVAILTUNES += core2
-TUNE_FEATURES_tune-core2 = ${TUNE_FEATURES_tune-x86} core2
-BASE_LIB_tune-core2 = lib
-TUNE_PKGARCH_tune-core2 = core2
-PACKAGE_EXTRA_ARCHS_tune-core2 = ${PACKAGE_EXTRA_ARCHS_tune-i586} core2
+AVAILTUNES += core2-32
+TUNE_FEATURES_tune-core2-32 = ${TUNE_FEATURES_tune-x86} core2
+BASE_LIB_tune-core2-32 = lib
+TUNE_PKGARCH_tune-core2-32 = core2_32
+PACKAGE_EXTRA_ARCHS_tune-core2-32 = ${PACKAGE_EXTRA_ARCHS_tune-i586} core2_32
AVAILTUNES += core2-64
TUNE_FEATURES_tune-core2-64 = ${TUNE_FEATURES_tune-x86-64} core2
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 04/15] tune-core2: Only add the current ARCH to PACKAGE_EXTRA_ARCHS
Inherit the PACKAGE_EXTRA_ARCHS from i586 and only explicitly add core2
here.
Signed-off-by: Darren Hart dvh...@linux.intel.com
Cc: Richard Purdie richard.pur...@intel.com
Cc: Paul Eggleton paul.eggle...@intel.com
Cc: Tom Zanussi tom.zanu...@intel.com
Cc: Nitin Kamble nitin.a.kam...@intel.com
Cc: Mark Hatle mark.ha...@windriver.com
Cc: Bruce Ashfield bruce.ashfi...@windriver.com
---
meta/conf/machine/include/tune-core2.inc |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/meta/conf/machine/include/tune-core2.inc
b/meta/conf/machine/include/tune-core2.inc
index 3b25197..2500a74 100644
--- a/meta/conf/machine/include/tune-core2.inc
+++ b/meta/conf/machine/include/tune-core2.inc
@@ -8,6 +8,7 @@
#
DEFAULTTUNE ?= core2
+# Include the previous tune to pull in PACKAGE_EXTRA_ARCHS
require conf/machine/include/tune-i586.inc
# Extra tune features
@@ -19,7 +20,7 @@ AVAILTUNES += core2
TUNE_FEATURES_tune-core2 = ${TUNE_FEATURES_tune-x86} core2
BASE_LIB_tune-core2 = lib
TUNE_PKGARCH_tune-core2 = core2
-PACKAGE_EXTRA_ARCHS_tune-core2 = ${PACKAGE_EXTRA_ARCHS_tune-x86} i386 i486
i586 i686 core2
+PACKAGE_EXTRA_ARCHS_tune-core2 = ${PACKAGE_EXTRA_ARCHS_tune-i586} core2
AVAILTUNES += core2-64
TUNE_FEATURES_tune-core2-64 = ${TUNE_FEATURES_tune-x86-64} core2
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 12/15] genericx86: Use the core2 tune file
On Tue, 2014-01-21 at 23:58 +0100, Martin Jansa wrote: On Tue, Jan 21, 2014 at 02:39:58PM -0800, Darren Hart wrote: Aside from the movbe and specialized instruction scheduling for the lack of out-of-order scheduling in the older Atom CPUs, the core2 tune covers these CPUs adequately. Since the current atom tune just uses core2 anyway, go ahead and make this explicit here. Signed-off-by: Darren Hart dvh...@linux.intel.com --- meta-yocto-bsp/conf/machine/genericx86.conf |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/meta-yocto-bsp/conf/machine/genericx86.conf b/meta-yocto-bsp/conf/machine/genericx86.conf index 9d29f62..549fc8e 100644 --- a/meta-yocto-bsp/conf/machine/genericx86.conf +++ b/meta-yocto-bsp/conf/machine/genericx86.conf This isn't for oe-core, is it? Nope. I called this out in the cover letter. It spans oe-core and poky, but I felt they were best viewed as a whole, rather than splitting them apart and worrying about the order in which they were applied. I understand the desire to not cross post and generally agree and avoid it - on rare occasions such as this, it seems the least awful way to go about it... @@ -3,5 +3,6 @@ #@DESCRIPTION: Machine configuration for generic X86 (32-bit) PCs. Supports a moderately wide range of drivers that should boot and be usable on typical hardware. -include conf/machine/include/tune-atom.inc +DEFAULTTUNE ?= core2-32 +include conf/machine/include/tune-core2.inc include conf/machine/include/genericx86-common.inc -- 1.7.9.5 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel signature.asc Description: This is a digitally signed message part ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 01/15] x86: Replace ia32 with x86 when referring to the generic architecture
On Tue, 2014-01-21 at 23:55 +0100, Martin Jansa wrote:
On Tue, Jan 21, 2014 at 02:39:47PM -0800, Darren Hart wrote:
ia32 implies 32bit, while these files provide descriptions for IA32,
X86_64, and X32 architectures. The term x86 fits this used better
without resorting to using the term Intel which isn't quite right as
it excludes things like the tune-c3 file describing a Via CPU.
Signed-off-by: Darren Hart dvh...@linux.intel.com
Cc: Richard Purdie richard.pur...@intel.com
Cc: Paul Eggleton paul.eggle...@intel.com
Cc: Tom Zanussi tom.zanu...@intel.com
Cc: Nitin Kamble nitin.a.kam...@intel.com
Cc: Mark Hatle mark.ha...@windriver.com
Cc: Bruce Ashfield bruce.ashfi...@windriver.com
---
meta/conf/machine/include/tune-c3.inc |2 +-
meta/conf/machine/include/tune-i586.inc|2 +-
meta/conf/machine/include/tune-x86_64.inc |2 +-
.../include/{ia32-base.inc = x86-base.inc}| 16
meta/conf/machine/include/{ia32 = x86}/README |6 +++---
.../{ia32/arch-ia32.inc = x86/arch-x86.inc} |2 +-
6 files changed, 15 insertions(+), 15 deletions(-)
rename meta/conf/machine/include/{ia32-base.inc = x86-base.inc} (75%)
rename meta/conf/machine/include/{ia32 = x86}/README (81%)
rename meta/conf/machine/include/{ia32/arch-ia32.inc = x86/arch-x86.inc}
(97%)
diff --git a/meta/conf/machine/include/tune-c3.inc
b/meta/conf/machine/include/tune-c3.inc
index 18865b7..fafc28a 100644
--- a/meta/conf/machine/include/tune-c3.inc
+++ b/meta/conf/machine/include/tune-c3.inc
@@ -1,4 +1,4 @@
-require conf/machine/include/ia32/arch-ia32.inc
+require conf/machine/include/x86/arch-x86.inc
TUNEVALID[c3] = VIA Cyrix III or VIA C3 specific optimizations
TUNECONFLICTS[c3] = m64 mx32
diff --git a/meta/conf/machine/include/tune-i586.inc
b/meta/conf/machine/include/tune-i586.inc
index 4542b9b..a315b35 100644
--- a/meta/conf/machine/include/tune-i586.inc
+++ b/meta/conf/machine/include/tune-i586.inc
@@ -1,6 +1,6 @@
DEFAULTTUNE ?= i586
-require conf/machine/include/ia32/arch-ia32.inc
+require conf/machine/include/x86/arch-x86.inc
# Extra tune features
TUNEVALID[i586] = Enable i586 specific processor optimizations
diff --git a/meta/conf/machine/include/tune-x86_64.inc
b/meta/conf/machine/include/tune-x86_64.inc
index 31e06da..ae48124 100644
--- a/meta/conf/machine/include/tune-x86_64.inc
+++ b/meta/conf/machine/include/tune-x86_64.inc
@@ -1,4 +1,4 @@
DEFAULTTUNE ?= x86-64
-require conf/machine/include/ia32/arch-ia32.inc
+require conf/machine/include/x86/arch-x86.inc
diff --git a/meta/conf/machine/include/ia32-base.inc
b/meta/conf/machine/include/x86-base.inc
similarity index 75%
rename from meta/conf/machine/include/ia32-base.inc
rename to meta/conf/machine/include/x86-base.inc
index e15f927..421bdee 100644
--- a/meta/conf/machine/include/ia32-base.inc
+++ b/meta/conf/machine/include/x86-base.inc
@@ -1,5 +1,5 @@
#
-# base machine settings for ia32-architecture BSPs
+# Base machine settings for Intel architecture BSPs
does it apply for AMD, Cyrix as well?
Blarg, yes it does. Apologies. I had originally done some of this in
meta-intel and was persuaded it was better to do this in oe-core. I
missed removing some of the intel-isms. Thanks for catching this.
Replacing INTEL with X86 for everything that isn't a specific recipe
name (xf86-video-intel). Thanks Martin.
Will include in the inevitable v2.
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
signature.asc
Description: This is a digitally signed message part
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 00/15] Update x86 tune files
On Tue, 2014-01-21 at 14:40 -0800, Darren Hart wrote: All, The following lays the groundwork for some rethinking of support for x86 platforms. In particular, the meta-intel layer will undergo some major refactoring once this is merged. We believe it is of value to keep as much of the tune files available in oe-core as possible, rather than isolating them all in meta-intel. This series renames the x86-related tune files, documents best practices, updates the core2 tune file, adds a corei7 tune file, and updates the dependent machine configs. This spans oe-core and poky and I feel is best viewed as a whole. Please forgive the cross-post. The new corei7 tune file applies to Nehalem and Silvermont (Bay Trail) CPUs which support up to SSE4.2. This provides an appropriate demarcation line while maximizing compatibility as well as including optimal support for the current generation of the embedded CPUs (Bay Trail) by including it in the new tune. AVX (Sandy Bridge and beyond) is not included as that would not apply to Bay Trail, although it can easily be added in a corei7-avx tune file as an additional patch for users who care more about the last few percent of performance over compatibility and consolidation. An important note and likely a point of contention: The core2 update changes the core2 arch to core2-32, making the 32 bit explicit rather than implied in order to provide a consistent naming scheme going forward with newer tunes where 64 bit would be logical assumption if not explicitly stated. See patch 5/15 for details on this bit. Finally, update the machines dependent on these tune files to use the new names. As we remove x86_64, the 64b x86 machines now build as core2-64 for maximum compatibility. I missed a couple things I'm getting to now: * the yocto-bsp substrates * the inclusion of XSERVER_IA32_* in the genericx86 BSPs * the eglibc-ld.inc file I need some help here, but am updating the core2 references and adding corei7... do we really have to do this for every tune file!?!? * profile-manual core2 references Coming in v2 -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 01/19] x86: Replace ia32 with x86 when referring to the generic architecture
ia32 implies 32bit, while these files provide descriptions for IA32,
X86_64, and X32 architectures. The term x86 fits this used better
without resorting to using the term Intel which isn't quite right as
it excludes things like the tune-c3 file describing a Via CPU.
Signed-off-by: Darren Hart dvh...@linux.intel.com
Cc: Richard Purdie richard.pur...@linuxfoundation.org
Cc: Paul Eggleton paul.eggle...@intel.com
Cc: Tom Zanussi tom.zanu...@intel.com
Cc: Nitin Kamble nitin.a.kam...@intel.com
Cc: Mark Hatle mark.ha...@windriver.com
Cc: Bruce Ashfield bruce.ashfi...@windriver.com
Cc: Martin Jansa martin.ja...@gmail.com
---
meta/conf/machine/include/tune-c3.inc |2 +-
meta/conf/machine/include/tune-i586.inc|2 +-
meta/conf/machine/include/tune-x86_64.inc |2 +-
.../include/{ia32-base.inc = x86-base.inc}| 18 +-
meta/conf/machine/include/{ia32 = x86}/README |6 +++---
.../{ia32/arch-ia32.inc = x86/arch-x86.inc} |2 +-
6 files changed, 16 insertions(+), 16 deletions(-)
rename meta/conf/machine/include/{ia32-base.inc = x86-base.inc} (72%)
rename meta/conf/machine/include/{ia32 = x86}/README (81%)
rename meta/conf/machine/include/{ia32/arch-ia32.inc = x86/arch-x86.inc} (97%)
diff --git a/meta/conf/machine/include/tune-c3.inc
b/meta/conf/machine/include/tune-c3.inc
index 18865b7..fafc28a 100644
--- a/meta/conf/machine/include/tune-c3.inc
+++ b/meta/conf/machine/include/tune-c3.inc
@@ -1,4 +1,4 @@
-require conf/machine/include/ia32/arch-ia32.inc
+require conf/machine/include/x86/arch-x86.inc
TUNEVALID[c3] = VIA Cyrix III or VIA C3 specific optimizations
TUNECONFLICTS[c3] = m64 mx32
diff --git a/meta/conf/machine/include/tune-i586.inc
b/meta/conf/machine/include/tune-i586.inc
index 4542b9b..a315b35 100644
--- a/meta/conf/machine/include/tune-i586.inc
+++ b/meta/conf/machine/include/tune-i586.inc
@@ -1,6 +1,6 @@
DEFAULTTUNE ?= i586
-require conf/machine/include/ia32/arch-ia32.inc
+require conf/machine/include/x86/arch-x86.inc
# Extra tune features
TUNEVALID[i586] = Enable i586 specific processor optimizations
diff --git a/meta/conf/machine/include/tune-x86_64.inc
b/meta/conf/machine/include/tune-x86_64.inc
index 31e06da..ae48124 100644
--- a/meta/conf/machine/include/tune-x86_64.inc
+++ b/meta/conf/machine/include/tune-x86_64.inc
@@ -1,4 +1,4 @@
DEFAULTTUNE ?= x86-64
-require conf/machine/include/ia32/arch-ia32.inc
+require conf/machine/include/x86/arch-x86.inc
diff --git a/meta/conf/machine/include/ia32-base.inc
b/meta/conf/machine/include/x86-base.inc
similarity index 72%
rename from meta/conf/machine/include/ia32-base.inc
rename to meta/conf/machine/include/x86-base.inc
index e15f927..d6c4d60 100644
--- a/meta/conf/machine/include/ia32-base.inc
+++ b/meta/conf/machine/include/x86-base.inc
@@ -1,9 +1,9 @@
#
-# base machine settings for ia32-architecture BSPs
+# Base machine settings for X86 architecture BSPs
#
#
-# common settings for Intel-based machines
+# common settings for X86 machines
#
MACHINE_FEATURES += screen keyboard pci usbhost ext2 ext3 x86 \
acpi serial usbgadget alsa
@@ -25,28 +25,28 @@ PREFERRED_VERSION_linux-yocto ??= 3.0%
#
# XSERVER subcomponents, used to build the XSERVER variable
#
-XSERVER_IA32_BASE = xserver-xorg \
+XSERVER_X86_BASE = xserver-xorg \
xf86-input-mouse \
xf86-input-keyboard \
xf86-input-evdev \
xf86-input-synaptics \
-XSERVER_IA32_EXT = \
+XSERVER_X86_EXT = \
${@base_contains('DISTRO_FEATURES', 'opengl',
'xserver-xorg-extension-glx', '', d)} \
xserver-xorg-module-libint10 \
-XSERVER_IA32_I915 = xf86-video-intel \
+XSERVER_X86_I915 = xf86-video-intel \
${@base_contains('DISTRO_FEATURES', 'opengl', 'mesa-driver-i915',
'', d)} \
-XSERVER_IA32_I965 = xf86-video-intel \
+XSERVER_X86_I965 = xf86-video-intel \
${@base_contains('DISTRO_FEATURES', 'opengl', 'mesa-driver-i965',
'', d)} \
-XSERVER_IA32_VESA = xf86-video-vesa
+XSERVER_X86_VESA = xf86-video-vesa
-XSERVER_IA32_FBDEV = xf86-video-fbdev
+XSERVER_X86_FBDEV = xf86-video-fbdev
-XSERVER_IA32_MODESETTING = xf86-video-modesetting
+XSERVER_X86_MODESETTING = xf86-video-modesetting
diff --git a/meta/conf/machine/include/ia32/README
b/meta/conf/machine/include/x86/README
similarity index 81%
rename from meta/conf/machine/include/ia32/README
rename to meta/conf/machine/include/x86/README
index 8f80a5b..d8b6793 100644
--- a/meta/conf/machine/include/ia32/README
+++ b/meta/conf/machine/include/x86/README
@@ -1,12 +1,12 @@
2012/03/30 - Mark Hatle mark.ha...@windriver.com
- Initial version
-Most of the items for the IA architecture are defined in the single
-arch-ia32 file.
+Most of the items for the Intel architectures are defined in the single
+arch-x86 file.
Three ABIs are define, m32, mx32 and m64.
-The following
[OE-core] [PATCH 16/19] yocto-bsp: Update substrate to use the new x86 tune files
Update the substrates to use x86-base instead of ia32-base and core2-64
instead of x86-64. Update the core2 bit to include the DEFAULTTUNE to be
explicit.
Signed-off-by: Darren Hart dvh...@linux.intel.com
Cc: Richard Purdie richard.pur...@linuxfoundation.org
Cc: Paul Eggleton paul.eggle...@intel.com
Cc: Tom Zanussi tom.zanu...@intel.com
Cc: Nitin Kamble nitin.a.kam...@intel.com
Cc: Mark Hatle mark.ha...@windriver.com
Cc: Bruce Ashfield bruce.ashfi...@windriver.com
Cc: Martin Jansa martin.ja...@gmail.com
---
.../arch/i386/conf/machine/{{=machine}}.conf | 13 +++--
.../arch/x86_64/conf/machine/{{=machine}}.conf | 15 ---
2 files changed, 15 insertions(+), 13 deletions(-)
diff --git
a/scripts/lib/bsp/substrate/target/arch/i386/conf/machine/{{=machine}}.conf
b/scripts/lib/bsp/substrate/target/arch/i386/conf/machine/{{=machine}}.conf
index b06ba12..2fff9b7 100644
--- a/scripts/lib/bsp/substrate/target/arch/i386/conf/machine/{{=machine}}.conf
+++ b/scripts/lib/bsp/substrate/target/arch/i386/conf/machine/{{=machine}}.conf
@@ -23,9 +23,10 @@ require conf/machine/include/tune-i586.inc
{{ if tunefile == tune_atom: }}
require conf/machine/include/tune-atom.inc
{{ if tunefile == tune_core2: }}
+DEFAULTTUNE=core2-32
require conf/machine/include/tune-core2.inc
-require conf/machine/include/ia32-base.inc
+require conf/machine/include/x86-base.inc
MACHINE_FEATURES += wifi efi pcbios
@@ -46,14 +47,14 @@ MACHINE_FEATURES += wifi efi pcbios
{{ if xserver == y and kernel_choice != linux-yocto_3.4 and kernel_choice
!= linux-yocto_3.10 and kernel_choice != custom: xserver_choice =
xserver_i915 }}
{{ if xserver == y: }}
-XSERVER ?= ${XSERVER_IA32_BASE} \
- ${XSERVER_IA32_EXT} \
+XSERVER ?= ${XSERVER_X86_BASE} \
+ ${XSERVER_X86_EXT} \
{{ if xserver == y and xserver_choice == xserver_vesa: }}
- ${XSERVER_IA32_VESA} \
+ ${XSERVER_X86_VESA} \
{{ if xserver == y and xserver_choice == xserver_i915: }}
- ${XSERVER_IA32_I915} \
+ ${XSERVER_X86_I915} \
{{ if xserver == y and xserver_choice == xserver_i965: }}
- ${XSERVER_IA32_I965} \
+ ${XSERVER_X86_I965} \
{{ if xserver == y: }}
diff --git
a/scripts/lib/bsp/substrate/target/arch/x86_64/conf/machine/{{=machine}}.conf
b/scripts/lib/bsp/substrate/target/arch/x86_64/conf/machine/{{=machine}}.conf
index 2bf2226..6685d07 100644
---
a/scripts/lib/bsp/substrate/target/arch/x86_64/conf/machine/{{=machine}}.conf
+++
b/scripts/lib/bsp/substrate/target/arch/x86_64/conf/machine/{{=machine}}.conf
@@ -14,8 +14,9 @@ PREFERRED_PROVIDER_virtual/kernel ?= {{=preferred_kernel}}
PREFERRED_PROVIDER_virtual/kernel ?= {{=preferred_kernel}}
PREFERRED_VERSION_{{=preferred_kernel}} ?= {{=preferred_kernel_version}}%
-require conf/machine/include/tune-x86_64.inc
-require conf/machine/include/ia32-base.inc
+DEFAULTTUNE ?= core2-64
+require conf/machine/include/tune-core2.inc
+require conf/machine/include/x86-base.inc
MACHINE_FEATURES += wifi efi pcbios
@@ -28,14 +29,14 @@ MACHINE_FEATURES += wifi efi pcbios
{{ input type:choice val:xserver_i915 msg:i915 xserver support }}
{{ input type:choice val:xserver_i965 msg:i965 xserver support }}
{{ if xserver == y: }}
-XSERVER ?= ${XSERVER_IA32_BASE} \
- ${XSERVER_IA32_EXT} \
+XSERVER ?= ${XSERVER_X86_BASE} \
+ ${XSERVER_X86_EXT} \
{{ if xserver == y and xserver_choice == xserver_vesa: }}
- ${XSERVER_IA32_VESA} \
+ ${XSERVER_X86_VESA} \
{{ if xserver == y and xserver_choice == xserver_i915: }}
- ${XSERVER_IA32_I915} \
+ ${XSERVER_X86_I915} \
{{ if xserver == y and xserver_choice == xserver_i965: }}
- ${XSERVER_IA32_I965} \
+ ${XSERVER_X86_I965} \
{{ if xserver == y: }}
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 02/19] i586: Only add the current tune to PACKAGE_EXTRA_ARCHS
The generic x86 build supports i586 by default, so this specific tune
file technically doesn't add any specific ARCHes to PACKAGE_EXTRA_ARCHS.
For consistency, append the current tune to PACKAGE_EXTRA_ARCHS.
Since we do not have specific tune files for i386 and i486, just drop
them.
These could be added to tune-x86 version if there is a need to
maintain them, but they really do not belong here.
Signed-off-by: Darren Hart dvh...@linux.intel.com
Cc: Richard Purdie richard.pur...@linuxfoundation.org
Cc: Paul Eggleton paul.eggle...@intel.com
Cc: Tom Zanussi tom.zanu...@intel.com
Cc: Nitin Kamble nitin.a.kam...@intel.com
Cc: Mark Hatle mark.ha...@windriver.com
Cc: Bruce Ashfield bruce.ashfi...@windriver.com
Cc: Martin Jansa martin.ja...@gmail.com
---
meta/conf/machine/include/tune-i586.inc |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/conf/machine/include/tune-i586.inc
b/meta/conf/machine/include/tune-i586.inc
index a315b35..5fbb3c7 100644
--- a/meta/conf/machine/include/tune-i586.inc
+++ b/meta/conf/machine/include/tune-i586.inc
@@ -11,4 +11,4 @@ AVAILTUNES += i586
TUNE_FEATURES_tune-i586 = ${TUNE_FEATURES_tune-x86} i586
BASE_LIB_tune-i586 = lib
TUNE_PKGARCH_tune-i586 = i586
-PACKAGE_EXTRA_ARCHS_tune-i586 = ${PACKAGE_EXTRA_ARCHS_tune-x86} i386 i486
i586
+PACKAGE_EXTRA_ARCHS_tune-i586 = ${PACKAGE_EXTRA_ARCHS_tune-x86} i586
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2 00/19] Update x86 tune files
All,
The following lays the groundwork for some rethinking of support for x86
platforms. In particular, the meta-intel layer will undergo some major
refactoring once this is merged. We believe it is of value to keep as much
of the tune files available in oe-core as possible, rather than isolating
them all in meta-intel.
This series renames the x86-related tune files, documents best practices,
updates the core2 tune file, adds a corei7 tune file, and updates the dependent
machine configs. This spans oe-core and poky and I feel it is best viewed as a
whole. Please forgive the cross-post.
The new corei7 tune file applies to Nehalem and Silvermont (Bay Trail) CPUs
which support up to SSE4.2. This provides an appropriate demarcation line while
maximizing compatibility as well as including optimal support for the current
generation of the embedded CPUs (Bay Trail) by including it in the new tune. AVX
(Sandy Bridge and beyond) is not included as that would not apply to Bay Trail,
although it can easily be added in a corei7-avx tune file as an additional
patch for users who care more about the last few percent of performance over
compatibility and consolidation.
An important note and likely a point of contention: The core2 update changes the
core2 arch to core2-32, making the 32 bit explicit rather than implied in order
to provide a consistent naming scheme going forward with newer tunes where
64 bit would be logical assumption if not explicitly stated. See patch 5/15 for
details on this bit.
Update the machines dependent on these tune files to use the new names.
As we remove x86_64, the 64b x86 machines now build as core2-64 for maximum
compatibility.
For reference, the corei7-64 tune defines:
TARGET_CC_ARCH= -m64 -march=corei7 -mtune=corei7 -mfpmath=sse -msse4.2
While the corei2-32 tune defines:
TARGET_CC_ARCH= -m32 -march=core2 -mtune=core2 -msse3 -mfpmath=sse
v2:
o Replace Intel with X86 in the x86-base.inc per Martin Jansa's review
o Update the yocto-bsp substrate templates for core2 and corei7 tunes
o Update the profile-manual documentation for core2-32 terminology
o Add eglibc-ld.inc patch this one needs review
The following changes since commit 6e7047434fc1570146ebc942V54412b99b1c4cab4:
poky.ent: Fixed broken OE_LISTS_URL. (2014-01-21 21:58:03 +)
are available in the git repository at:
git://git.yoctoproject.org/poky-contrib dvhart/x86-tune-ng-v2
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=dvhart/x86-tune-ng-v2
Darren Hart (19):
x86: Replace ia32 with x86 when referring to the generic architecture
i586: Only add the current tune to PACKAGE_EXTRA_ARCHS
tune-core2: Replace -mtune=generic with -mtune=core2
tune-core2: Only add the current ARCH to PACKAGE_EXTRA_ARCHS
tune: Make 32b or 64b explicit in tune name for core2
tune-corei7: Add support for cpu-type corei7
tune: Remove tune-x86_64.inc
tune: README: Whitespace cleanup
tune: README: Document best practice
tune: README: Typographical corrections
qemux86_64: Use the core2-64 tune
genericx86: Use the core2 tune file
genericx86-64: Use the core2-64 tune
genericx86: Use new x86 tune files
genericx86: Use require instead of include
yocto-bsp: Update substrate to use the new x86 tune files
eglibc-ld.inc: Update the inc file to match the new x86 tune
doc: Update profile-manual to use new core2_32 tune name
yocto-bsp: Add core2 and corei7 tune choice to x86_64
.../profile-manual/profile-manual-usage.xml|8 +-
meta-yocto-bsp/conf/machine/genericx86-64.conf |5 +-
meta-yocto-bsp/conf/machine/genericx86.conf|5 +-
.../conf/machine/include/genericx86-common.inc | 16 +--
meta/conf/machine/include/README | 109
meta/conf/machine/include/tune-c3.inc |2 +-
meta/conf/machine/include/tune-core2.inc | 23 +++--
meta/conf/machine/include/tune-corei7.inc | 35 +++
meta/conf/machine/include/tune-i586.inc|4 +-
meta/conf/machine/include/tune-x86_64.inc |4 -
.../include/{ia32-base.inc = x86-base.inc}| 18 ++--
meta/conf/machine/include/{ia32 = x86}/README |6 +-
.../{ia32/arch-ia32.inc = x86/arch-x86.inc} |2 +-
meta/conf/machine/qemux86-64.conf |3 +-
meta/recipes-core/eglibc/eglibc-ld.inc |4 +-
.../arch/i386/conf/machine/{{=machine}}.conf | 13 +--
.../arch/x86_64/conf/machine/{{=machine}}.conf | 23 +++--
17 files changed, 177 insertions(+), 103 deletions(-)
create mode 100644 meta/conf/machine/include/tune-corei7.inc
delete mode 100644 meta/conf/machine/include/tune-x86_64.inc
rename meta/conf/machine/include/{ia32-base.inc = x86-base.inc} (72%)
rename meta/conf/machine/include/{ia32 = x86}/README (81%)
rename meta/conf/machine/include/{ia32/arch-ia32.inc = x86/arch-x86.inc} (97%)
--
1.7.9.5
[OE-core] [PATCH 13/19] genericx86-64: Use the core2-64 tune
As x86_64 has been demoted to an ABI definition rather than a concrete tune file, replace it with core2-64 for the genericx86-64 machine. Signed-off-by: Darren Hart dvh...@linux.intel.com Cc: Richard Purdie richard.pur...@linuxfoundation.org Cc: Paul Eggleton paul.eggle...@intel.com Cc: Tom Zanussi tom.zanu...@intel.com Cc: Nitin Kamble nitin.a.kam...@intel.com Cc: Mark Hatle mark.ha...@windriver.com Cc: Bruce Ashfield bruce.ashfi...@windriver.com Cc: Martin Jansa martin.ja...@gmail.com Cc: Ross Burton ross.bur...@intel.com --- meta-yocto-bsp/conf/machine/genericx86-64.conf |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/meta-yocto-bsp/conf/machine/genericx86-64.conf b/meta-yocto-bsp/conf/machine/genericx86-64.conf index 56e9bb6..a6154cd 100644 --- a/meta-yocto-bsp/conf/machine/genericx86-64.conf +++ b/meta-yocto-bsp/conf/machine/genericx86-64.conf @@ -3,5 +3,6 @@ #@DESCRIPTION: Machine configuration for generic X86_64 (64-bit) PCs and servers. Supports a moderately wide range of drivers that should boot and be usable on typical hardware. -include conf/machine/include/tune-x86_64.inc +DEFAULTTUNE ?= core2-64 +include conf/machine/include/tune-core2.inc include conf/machine/include/genericx86-common.inc -- 1.7.9.5 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 12/19] genericx86: Use the core2 tune file
Aside from the movbe and specialized instruction scheduling for the lack of out-of-order scheduling in the older Atom CPUs, the core2 tune covers these CPUs adequately. Since the current atom tune just uses core2 anyway, go ahead and make this explicit here. Signed-off-by: Darren Hart dvh...@linux.intel.com Cc: Richard Purdie richard.pur...@linuxfoundation.org Cc: Paul Eggleton paul.eggle...@intel.com Cc: Tom Zanussi tom.zanu...@intel.com Cc: Nitin Kamble nitin.a.kam...@intel.com Cc: Mark Hatle mark.ha...@windriver.com Cc: Bruce Ashfield bruce.ashfi...@windriver.com Cc: Martin Jansa martin.ja...@gmail.com Cc: Ross Burton ross.bur...@intel.com --- meta-yocto-bsp/conf/machine/genericx86.conf |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/meta-yocto-bsp/conf/machine/genericx86.conf b/meta-yocto-bsp/conf/machine/genericx86.conf index 9d29f62..549fc8e 100644 --- a/meta-yocto-bsp/conf/machine/genericx86.conf +++ b/meta-yocto-bsp/conf/machine/genericx86.conf @@ -3,5 +3,6 @@ #@DESCRIPTION: Machine configuration for generic X86 (32-bit) PCs. Supports a moderately wide range of drivers that should boot and be usable on typical hardware. -include conf/machine/include/tune-atom.inc +DEFAULTTUNE ?= core2-32 +include conf/machine/include/tune-core2.inc include conf/machine/include/genericx86-common.inc -- 1.7.9.5 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 10/19] tune: README: Typographical corrections
No new content, just correcting a few typographical errors.
Signed-off-by: Darren Hart dvh...@linux.intel.com
Cc: Richard Purdie richard.pur...@linuxfoundation.org
Cc: Paul Eggleton paul.eggle...@intel.com
Cc: Tom Zanussi tom.zanu...@intel.com
Cc: Nitin Kamble nitin.a.kam...@intel.com
Cc: Mark Hatle mark.ha...@windriver.com
Cc: Bruce Ashfield bruce.ashfi...@windriver.com
Cc: Martin Jansa martin.ja...@gmail.com
---
meta/conf/machine/include/README |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/meta/conf/machine/include/README b/meta/conf/machine/include/README
index 6c390ad..d66130a 100644
--- a/meta/conf/machine/include/README
+++ b/meta/conf/machine/include/README
@@ -53,10 +53,10 @@ list should be dynamic! i.e.
${@bb.utils.contains(TUNE_FEATURES, feature, cflag, !cflag, d)}
TUNE_ARCH - The GNU canonical arch for a specific architecture. i.e.
-arm, armeb, mips, mips64, etc. This value is by bitbake to setup
+arm, armeb, mips, mips64, etc. This value is used by bitbake to setup
configure. TUNE_ARCH definitions are specific to a given architecture.
-They may be a single static definitions, or may be dynamically adjusted.
-See each architectures README for details for that CPU family.
+They may be a single static definition, or may be dynamically adjusted.
+See each architecture's README for details for that CPU family.
TUNE_PKGARCH - The package architecture used by the packaging systems to
define the architecture, abi and tuning of a particular package.
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 09/19] tune: README: Document best practice
Describe the expected usage of base architecture tune files and arch-specific files, specifically the stacking of generations. Signed-off-by: Darren Hart dvh...@linux.intel.com Cc: Richard Purdie richard.pur...@linuxfoundation.org Cc: Paul Eggleton paul.eggle...@intel.com Cc: Tom Zanussi tom.zanu...@intel.com Cc: Nitin Kamble nitin.a.kam...@intel.com Cc: Mark Hatle mark.ha...@windriver.com Cc: Bruce Ashfield bruce.ashfi...@windriver.com Cc: Martin Jansa martin.ja...@gmail.com --- meta/conf/machine/include/README | 19 +++ 1 file changed, 19 insertions(+) diff --git a/meta/conf/machine/include/README b/meta/conf/machine/include/README index 65d0942..6c390ad 100644 --- a/meta/conf/machine/include/README +++ b/meta/conf/machine/include/README @@ -1,6 +1,9 @@ 2012/03/30 - Mark Hatle mark.ha...@windriver.com - Initial Revision + +Introduction + The individual CPU, and ABI tunings are contained in this directory. A number of local and global variables are used to control the way the tunings are setup and how they work together to specify an optimized @@ -79,3 +82,19 @@ configured in the same way that TUNE_CCARGS is. BASE_LIB_tune-tune - The /lib location for a specific ABI. This is used in a multilib configuration to place the libraries in the correct, non-conflicting locations. + + +Best Practice += +The tune infrastructure is designed to be hierarchical. When writing a +new tune file for a fast-forward CPU architecture (one that supports +everything from a previous generation), it is recommended to require the +previous generation tune file and specify PACKAGE_EXTRA_ARCHS using the +previous generation's override and appending the new tune. Note that +only one previous tune file should be included to avoid mutiple includes +of the base arch which could lead to a broken configuration due to +multiple prepend and append assignments. + +For example, for x86, there is a common x86/arch-x86.inc which is +included in the base i586 tune file. The core2 tune builds +on that, and corei7 builds on core2. -- 1.7.9.5 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 03/19] tune-core2: Replace -mtune=generic with -mtune=core2
-march specifies which ISA to use. -mtune specifies which cpu-type to
optimize instruction ordering for, but not which ISA to use. There are
times when it may make sense to specify mtune=generic and use a more
specific march, such as core2, but the opposite makes little sense at
all: use cpu-type specific ISA, but order the instructions
generically. While the -mtune is implied by -march, gcc does not verify
it is using -mtune=core2 with:
gcc -Q -march=core2 --help=target
Explicitly specify -mtune=core2 to be sure.
Add a comment header describing the CPUs targeted by this tune file.
Signed-off-by: Darren Hart dvh...@linux.intel.com
Cc: Richard Purdie richard.pur...@linuxfoundation.org
Cc: Paul Eggleton paul.eggle...@intel.com
Cc: Tom Zanussi tom.zanu...@intel.com
Cc: Nitin Kamble nitin.a.kam...@intel.com
Cc: Mark Hatle mark.ha...@windriver.com
Cc: Bruce Ashfield bruce.ashfi...@windriver.com
Cc: Martin Jansa martin.ja...@gmail.com
---
meta/conf/machine/include/tune-core2.inc | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/meta/conf/machine/include/tune-core2.inc
b/meta/conf/machine/include/tune-core2.inc
index 85b6924..3b25197 100644
--- a/meta/conf/machine/include/tune-core2.inc
+++ b/meta/conf/machine/include/tune-core2.inc
@@ -1,10 +1,18 @@
+# Settings for the GCC(1) cpu-type core2:
+#
+# Intel Core2 CPU with 64-bit extensions, MMX, SSE, SSE2, SSE3 and SSSE3
+# instruction set support.
+#
+# This tune is recommended for the Intel Core 2 CPU family, including Conroe,
+# Merom and beyond, as well as the first Atom CPUs, Diamondville, and beyond.
+#
DEFAULTTUNE ?= core2
require conf/machine/include/tune-i586.inc
# Extra tune features
TUNEVALID[core2] = Enable core2 specific processor optimizations
-TUNE_CCARGS .= ${@bb.utils.contains(TUNE_FEATURES, core2, -march=core2
-msse3 -mtune=generic -mfpmath=sse, , d)}
+TUNE_CCARGS .= ${@bb.utils.contains(TUNE_FEATURES, core2, -march=core2
-mtune=core2 -msse3 -mfpmath=sse, , d)}
# Extra tune selections
AVAILTUNES += core2
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 07/19] tune: Remove tune-x86_64.inc
The tune-x86_64.inc file is conceptually flawed. x86_64 is more akin to the x86 and x86-32 ABIs defined in arch-x86.inc than it is a concrete tune file, such as i586 or core2 - to the extent that everything but the default tune is defined in the arch-x86.inc file. This becomes very apparant when attempting to include tune-x86_64.inc in the x86 tune hierarchy. Remove the tune-x86_64.inc tune file in favor of it being an ABI definition in arch-x86.inc and relying on the linear hierarchy of concrete cpu-types in tune-i586, tune-core2, and tune-corei7. core2_64 should suffice in lieu of x86_64 for all but a couple esoteric corner cases involving older pre-core2 CPUs. In these cases, if they exist at all, the BSP can replace the include tune-x86_64.inc with arch-x86.inc and set the default tune to x86_64. Signed-off-by: Darren Hart dvh...@linux.intel.com Cc: Richard Purdie richard.pur...@linuxfoundation.org Cc: Paul Eggleton paul.eggle...@intel.com Cc: Tom Zanussi tom.zanu...@intel.com Cc: Nitin Kamble nitin.a.kam...@intel.com Cc: Mark Hatle mark.ha...@windriver.com Cc: Bruce Ashfield bruce.ashfi...@windriver.com Cc: Martin Jansa martin.ja...@gmail.com --- meta/conf/machine/include/tune-x86_64.inc |4 1 file changed, 4 deletions(-) delete mode 100644 meta/conf/machine/include/tune-x86_64.inc diff --git a/meta/conf/machine/include/tune-x86_64.inc b/meta/conf/machine/include/tune-x86_64.inc deleted file mode 100644 index ae48124..000 --- a/meta/conf/machine/include/tune-x86_64.inc +++ /dev/null @@ -1,4 +0,0 @@ -DEFAULTTUNE ?= x86-64 - -require conf/machine/include/x86/arch-x86.inc - -- 1.7.9.5 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 15/19] genericx86: Use require instead of include
Use require instead of include to avoid silent errors when the required tune files change name or are moved. It's going to fail anyway, it might as well fail with an error message that is immediately helpful. Signed-off-by: Darren Hart dvh...@linux.intel.com Cc: Richard Purdie richard.pur...@linuxfoundation.org Cc: Paul Eggleton paul.eggle...@intel.com Cc: Tom Zanussi tom.zanu...@intel.com Cc: Nitin Kamble nitin.a.kam...@intel.com Cc: Mark Hatle mark.ha...@windriver.com Cc: Bruce Ashfield bruce.ashfi...@windriver.com Cc: Martin Jansa martin.ja...@gmail.com Cc: Ross Burton ross.bur...@intel.com --- meta-yocto-bsp/conf/machine/genericx86-64.conf |4 ++-- meta-yocto-bsp/conf/machine/genericx86.conf|4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/meta-yocto-bsp/conf/machine/genericx86-64.conf b/meta-yocto-bsp/conf/machine/genericx86-64.conf index a6154cd..f76e35a 100644 --- a/meta-yocto-bsp/conf/machine/genericx86-64.conf +++ b/meta-yocto-bsp/conf/machine/genericx86-64.conf @@ -4,5 +4,5 @@ #@DESCRIPTION: Machine configuration for generic X86_64 (64-bit) PCs and servers. Supports a moderately wide range of drivers that should boot and be usable on typical hardware. DEFAULTTUNE ?= core2-64 -include conf/machine/include/tune-core2.inc -include conf/machine/include/genericx86-common.inc +require conf/machine/include/tune-core2.inc +require conf/machine/include/genericx86-common.inc diff --git a/meta-yocto-bsp/conf/machine/genericx86.conf b/meta-yocto-bsp/conf/machine/genericx86.conf index 549fc8e..2642cab 100644 --- a/meta-yocto-bsp/conf/machine/genericx86.conf +++ b/meta-yocto-bsp/conf/machine/genericx86.conf @@ -4,5 +4,5 @@ #@DESCRIPTION: Machine configuration for generic X86 (32-bit) PCs. Supports a moderately wide range of drivers that should boot and be usable on typical hardware. DEFAULTTUNE ?= core2-32 -include conf/machine/include/tune-core2.inc -include conf/machine/include/genericx86-common.inc +require conf/machine/include/tune-core2.inc +require conf/machine/include/genericx86-common.inc -- 1.7.9.5 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 11/19] qemux86_64: Use the core2-64 tune
As x86_64 has been demoted to an ABI definition rather than a concrete tune file, replace it with core2-64 for the qemux86-64 machine. Signed-off-by: Darren Hart dvh...@linux.intel.com Cc: Richard Purdie richard.pur...@linuxfoundation.org Cc: Paul Eggleton paul.eggle...@intel.com Cc: Tom Zanussi tom.zanu...@intel.com Cc: Nitin Kamble nitin.a.kam...@intel.com Cc: Mark Hatle mark.ha...@windriver.com Cc: Bruce Ashfield bruce.ashfi...@windriver.com Cc: Martin Jansa martin.ja...@gmail.com --- meta/conf/machine/qemux86-64.conf |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/meta/conf/machine/qemux86-64.conf b/meta/conf/machine/qemux86-64.conf index c572225..6533e56 100644 --- a/meta/conf/machine/qemux86-64.conf +++ b/meta/conf/machine/qemux86-64.conf @@ -8,7 +8,8 @@ PREFERRED_PROVIDER_virtual/libgles1 ?= mesa PREFERRED_PROVIDER_virtual/libgles2 ?= mesa require conf/machine/include/qemu.inc -require conf/machine/include/tune-x86_64.inc +DEFAULTTUNE ?= core2-64 +require conf/machine/include/tune-core2.inc KERNEL_IMAGETYPE = bzImage -- 1.7.9.5 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 14/19] genericx86: Use new x86 tune files
Use the new names for the x86 tunes files (x86 instead of ia32).
Signed-off-by: Darren Hart dvh...@linux.intel.com
Cc: Richard Purdie richard.pur...@linuxfoundation.org
Cc: Paul Eggleton paul.eggle...@intel.com
Cc: Tom Zanussi tom.zanu...@intel.com
Cc: Nitin Kamble nitin.a.kam...@intel.com
Cc: Mark Hatle mark.ha...@windriver.com
Cc: Bruce Ashfield bruce.ashfi...@windriver.com
Cc: Martin Jansa martin.ja...@gmail.com
Cc: Ross Burton ross.bur...@intel.com
---
.../conf/machine/include/genericx86-common.inc | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/meta-yocto-bsp/conf/machine/include/genericx86-common.inc
b/meta-yocto-bsp/conf/machine/include/genericx86-common.inc
index c5ef358..66bfd19 100644
--- a/meta-yocto-bsp/conf/machine/include/genericx86-common.inc
+++ b/meta-yocto-bsp/conf/machine/include/genericx86-common.inc
@@ -1,16 +1,16 @@
-include conf/machine/include/ia32-base.inc
+include conf/machine/include/x86-base.inc
MACHINE_FEATURES += wifi efi pcbios
PREFERRED_PROVIDER_virtual/kernel ?= linux-yocto
PREFERRED_VERSION_linux-yocto ?= 3.10%
PREFERRED_PROVIDER_virtual/xserver ?= xserver-xorg
-XSERVER ?= ${XSERVER_IA32_BASE} \
-${XSERVER_IA32_EXT} \
-${XSERVER_IA32_I915} \
-${XSERVER_IA32_I965} \
-${XSERVER_IA32_FBDEV} \
-${XSERVER_IA32_VESA} \
-${XSERVER_IA32_MODESETTING} \
+XSERVER ?= ${XSERVER_X86_BASE} \
+${XSERVER_X86_EXT} \
+${XSERVER_X86_I915} \
+${XSERVER_X86_I965} \
+${XSERVER_X86_FBDEV} \
+${XSERVER_X86_VESA} \
+${XSERVER_X86_MODESETTING} \
MACHINE_EXTRA_RRECOMMENDS += linux-firmware v86d eee-acpi-scripts
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 06/19] tune-corei7: Add support for cpu-type corei7
corei7 offers a significant advancement since the previous core2
cpu-type described in the tune-core2 file.
From the GCC(1):
Intel Core i7 CPU with 64-bit extensions, MMX, SSE, SSE2, SSE3,
SSSE3, SSE4.1 and SSE4.2 instruction set support.
This offers optimizations for Nehalem and Silvermont (e.g. Bay Trail)
CPUs (and beyond).
Signed-off-by: Darren Hart dvh...@linux.intel.com
Cc: Richard Purdie richard.pur...@linuxfoundation.org
Cc: Paul Eggleton paul.eggle...@intel.com
Cc: Tom Zanussi tom.zanu...@intel.com
Cc: Nitin Kamble nitin.a.kam...@intel.com
Cc: Mark Hatle mark.ha...@windriver.com
Cc: Bruce Ashfield bruce.ashfi...@windriver.com
Cc: Martin Jansa martin.ja...@gmail.com
---
meta/conf/machine/include/tune-corei7.inc | 35 +
1 file changed, 35 insertions(+)
create mode 100644 meta/conf/machine/include/tune-corei7.inc
diff --git a/meta/conf/machine/include/tune-corei7.inc
b/meta/conf/machine/include/tune-corei7.inc
new file mode 100644
index 000..5464fed
--- /dev/null
+++ b/meta/conf/machine/include/tune-corei7.inc
@@ -0,0 +1,35 @@
+# Settings for the GCC(1) cpu-type corei7:
+#
+# Intel Core i7 CPU with 64-bit extensions, MMX, SSE, SSE2, SSE3, SSSE3,
SSE4.1
+# and SSE4.2 instruction set support.
+#
+# This tune is recommended for Intel Nehalem and Silvermont (e.g. Bay Trail)
CPUs
+# (and beyond).
+#
+DEFAULTTUNE ?= corei7-64
+
+# Pull in the previous tune in to pull in PACKAGE_EXTRA_ARCHS
+require conf/machine/include/tune-core2.inc
+
+# Extra tune features
+TUNEVALID[corei7] = Enable corei7 specific processor optimizations
+TUNE_CCARGS .= ${@bb.utils.contains(TUNE_FEATURES, corei7,
-march=corei7 -mtune=corei7 -mfpmath=sse -msse4.2, , d)}
+
+# Extra tune selections
+AVAILTUNES += corei7-32
+TUNE_FEATURES_tune-corei7-32 = ${TUNE_FEATURES_tune-x86} corei7
+BASE_LIB_tune-corei7-32 = lib
+TUNE_PKGARCH_tune-corei7-32 = corei7_32
+PACKAGE_EXTRA_ARCHS_tune-corei7-32 = ${PACKAGE_EXTRA_ARCHS_tune-core2}
corei7_32
+
+AVAILTUNES += corei7-64
+TUNE_FEATURES_tune-corei7-64 = ${TUNE_FEATURES_tune-x86-64} corei7
+BASE_LIB_tune-corei7-64 = lib64
+TUNE_PKGARCH_tune-corei7-64 = corei7_64
+PACKAGE_EXTRA_ARCHS_tune-corei7-64 = ${PACKAGE_EXTRA_ARCHS_tune-core2-64}
corei7_64
+
+AVAILTUNES += corei7-64-x32
+TUNE_FEATURES_tune-corei7-64-x32 = ${TUNE_FEATURES_tune-x86-64-x32} corei7
+BASE_LIB_tune-corei7-64-x32 = libx32
+TUNE_PKGARCH_tune-corei7-64-x32 = corei7_64_x32
+PACKAGE_EXTRA_ARCHS_tune-corei7-64-x32 =
${PACKAGE_EXTRA_ARCHS_tune-core2-64-x32} corei7_64_x32
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 08/19] tune: README: Whitespace cleanup
Before making content changes, cleanup the various whitespace errors in
this file. Mostly end-of-line whitepsace.
Signed-off-by: Darren Hart dvh...@linux.intel.com
Cc: Richard Purdie richard.pur...@linuxfoundation.org
Cc: Paul Eggleton paul.eggle...@intel.com
Cc: Tom Zanussi tom.zanu...@intel.com
Cc: Nitin Kamble nitin.a.kam...@intel.com
Cc: Mark Hatle mark.ha...@windriver.com
Cc: Bruce Ashfield bruce.ashfi...@windriver.com
Cc: Martin Jansa martin.ja...@gmail.com
---
meta/conf/machine/include/README | 88 +++---
1 file changed, 44 insertions(+), 44 deletions(-)
diff --git a/meta/conf/machine/include/README b/meta/conf/machine/include/README
index e4b59c9..65d0942 100644
--- a/meta/conf/machine/include/README
+++ b/meta/conf/machine/include/README
@@ -1,27 +1,27 @@
2012/03/30 - Mark Hatle mark.ha...@windriver.com
- Initial Revision
-The individual CPU, and ABI tunings are contained in this directory. A
-number of local and global variables are used to control the way the
-tunings are setup and how they work together to specify an optimized
+The individual CPU, and ABI tunings are contained in this directory. A
+number of local and global variables are used to control the way the
+tunings are setup and how they work together to specify an optimized
configuration.
-The following is brief summary of the generic components that are used
+The following is brief summary of the generic components that are used
in these tunings.
-AVAILTUNES - This is a list of all of the tuning definitions currently
-available in the system. Not all tunes in this list may be compatible
-with the machine configuration, or each other in a multilib
-configuration. Each tuning file can add to this list using +=, but
+AVAILTUNES - This is a list of all of the tuning definitions currently
+available in the system. Not all tunes in this list may be compatible
+with the machine configuration, or each other in a multilib
+configuration. Each tuning file can add to this list using +=, but
should never replace the list using =.
-DEFAULTTUNE - This specifies the tune to use for a particular build.
-Each tune should specify a reasonable default, which can be overriden by
-a machine or multilib configuration. The specified tune must be listed
+DEFAULTTUNE - This specifies the tune to use for a particular build.
+Each tune should specify a reasonable default, which can be overriden by
+a machine or multilib configuration. The specified tune must be listed
in the AVAILTUNES.
-TUNEVALID[feature] - The feature is defined with a human readable
-explanation for what it does. All architectural, cpu, abi, etc tuning
+TUNEVALID[feature] - The feature is defined with a human readable
+explanation for what it does. All architectural, cpu, abi, etc tuning
features must be defined using TUNEVALID.
TUNECONFLICTS[feature] - A list of features which conflict with feature.
@@ -31,51 +31,51 @@ tuning ends up with features which conflict with each other.
TUNE_FEATURES - This is automatically defined as TUNE_FEATURES_tune-tune.
See TUNE_FEATURES_tune-tune for more information.
-TUNE_FEATURES_tune-tune - Specify the features used to describe a
-specific tune. This is a list of features that a tune support, each
-feature must be in the TUNEVALID list. Note: the tune and a given
-feature name may be the same, but they have different purposes. Only
-features may be used to change behavior, while tunes are used to
+TUNE_FEATURES_tune-tune - Specify the features used to describe a
+specific tune. This is a list of features that a tune support, each
+feature must be in the TUNEVALID list. Note: the tune and a given
+feature name may be the same, but they have different purposes. Only
+features may be used to change behavior, while tunes are used to
describe an overall set of features.
-ABIEXTENSION - An ABI extension may be specified by a specific feature
-or other tuning setting, such as TARGET_FPU. Any ABI extensions either
-need to be defined in the architectures base arch file, i.e.
-ABIEXTENSION = eabi in the arm case, or appended to in specific tune
+ABIEXTENSION - An ABI extension may be specified by a specific feature
+or other tuning setting, such as TARGET_FPU. Any ABI extensions either
+need to be defined in the architectures base arch file, i.e.
+ABIEXTENSION = eabi in the arm case, or appended to in specific tune
files with a .=. Spaces are not allowed in this variable.
-TUNE_CCARGS - Setup the cflags based on the TUNE_FEATURES settings.
-These should be additive when defined using +=. All items in this
-list should be dynamic! i.e.
+TUNE_CCARGS - Setup the cflags based on the TUNE_FEATURES settings.
+These should be additive when defined using +=. All items in this
+list should be dynamic! i.e.
${@bb.utils.contains(TUNE_FEATURES, feature, cflag, !cflag, d)}
-TUNE_ARCH - The GNU canonical arch for a specific architecture. i.e.
-arm, armeb
[OE-core] [PATCH 19/19] yocto-bsp: Add core2 and corei7 tune choice to x86_64
Update the x86_64 architecture bsp creator to include choices for core2
and corei7 tune files.
Signed-off-by: Darren Hart dvh...@linux.intel.com
Cc: Richard Purdie richard.pur...@linuxfoundation.org
Cc: Paul Eggleton paul.eggle...@intel.com
Cc: Tom Zanussi tom.zanu...@intel.com
Cc: Nitin Kamble nitin.a.kam...@intel.com
Cc: Mark Hatle mark.ha...@windriver.com
Cc: Bruce Ashfield bruce.ashfi...@windriver.com
Cc: Martin Jansa martin.ja...@gmail.com
---
.../arch/x86_64/conf/machine/{{=machine}}.conf |8
1 file changed, 8 insertions(+)
diff --git
a/scripts/lib/bsp/substrate/target/arch/x86_64/conf/machine/{{=machine}}.conf
b/scripts/lib/bsp/substrate/target/arch/x86_64/conf/machine/{{=machine}}.conf
index 6685d07..53e8e92 100644
---
a/scripts/lib/bsp/substrate/target/arch/x86_64/conf/machine/{{=machine}}.conf
+++
b/scripts/lib/bsp/substrate/target/arch/x86_64/conf/machine/{{=machine}}.conf
@@ -14,8 +14,16 @@ PREFERRED_PROVIDER_virtual/kernel ?= {{=preferred_kernel}}
PREFERRED_PROVIDER_virtual/kernel ?= {{=preferred_kernel}}
PREFERRED_VERSION_{{=preferred_kernel}} ?= {{=preferred_kernel_version}}%
+{{ input type:choicelist name:tunefile prio:40 msg:Which machine tuning
would you like to use? default:tune_core2 }}
+{{ input type:choice val:tune_core2 msg:Core2 tuning optimizations }}
+{{ input type:choice val:tune_corei7 msg:Corei7 tuning optimizations }}
+{{ if tunefile == tune_core2: }}
DEFAULTTUNE ?= core2-64
require conf/machine/include/tune-core2.inc
+{{ if tunefile == tune_corei7: }}
+DEFAULTTUNE ?= corei7-64
+require conf/machine/include/tune-corei7.inc
+
require conf/machine/include/x86-base.inc
MACHINE_FEATURES += wifi efi pcbios
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 18/19] doc: Update profile-manual to use new core2_32 tune name
Replace core2 with core2_32 where appropriate for the new x86 tune naming. Signed-off-by: Darren Hart dvh...@linux.intel.com Cc: Scott Rifenbark scott.m.rifenb...@intel.com Cc: Richard Purdie richard.pur...@linuxfoundation.org Cc: Paul Eggleton paul.eggle...@intel.com Cc: Tom Zanussi tom.zanu...@intel.com Cc: Nitin Kamble nitin.a.kam...@intel.com Cc: Mark Hatle mark.ha...@windriver.com Cc: Bruce Ashfield bruce.ashfi...@windriver.com Cc: Martin Jansa martin.ja...@gmail.com --- .../profile-manual/profile-manual-usage.xml|8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/documentation/profile-manual/profile-manual-usage.xml b/documentation/profile-manual/profile-manual-usage.xml index faae645..5577b1b 100644 --- a/documentation/profile-manual/profile-manual-usage.xml +++ b/documentation/profile-manual/profile-manual-usage.xml @@ -381,13 +381,13 @@ build/tmp/deploy/rpm/* on the host system. Find the busybox-dbg-...rpm file and copy it to the target. For example: literallayout class='monospaced' - [trz@empanada core2]$ scp /home/trz/yocto/crownbay-tracing-dbg/build/tmp/deploy/rpm/core2/busybox-dbg-1.20.2-r2.core2.rpm root@192.168.1.31: + [trz@empanada core2]$ scp /home/trz/yocto/crownbay-tracing-dbg/build/tmp/deploy/rpm/core2_32/busybox-dbg-1.20.2-r2.core2_32.rpm root@192.168.1.31: root@192.168.1.31's password: - busybox-dbg-1.20.2-r2.core2.rpm 100% 1826KB 1.8MB/s 00:01 + busybox-dbg-1.20.2-r2.core2_32.rpm 100% 1826KB 1.8MB/s 00:01 /literallayout Now install the debug rpm on the target: literallayout class='monospaced' - root@crownbay:~# rpm -i busybox-dbg-1.20.2-r2.core2.rpm + root@crownbay:~# rpm -i busybox-dbg-1.20.2-r2.core2_32.rpm /literallayout Now that the debuginfo is installed, we see that the busybox entries now display their functions symbolically: @@ -3024,7 +3024,7 @@ First cd into the build directory that contains the hello executable: literallayout class='monospaced' - $ cd build/tmp/work/core2-poky-linux/lttng-ust/2.0.5-r0/git/tests/hello/.libs + $ cd build/tmp/work/core2_32-poky-linux/lttng-ust/2.0.5-r0/git/tests/hello/.libs /literallayout Copy that over to the target machine: literallayout class='monospaced' -- 1.7.9.5 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 05/19] tune: Make 32b or 64b explicit in tune name for core2
Core2 has both a 32b and a 64b variant. Currently, core2 implies 32b,
while core2_64 is the 64b version. This implicit 32b mode will become
confusing in later architectures, such as corei7, where it would be
natural for people to assume corei7 meant 64 bit.
Rather than carrying forward an implicit 32b mode and rather than
changing the naming scheme part way through the architecture hiearchy,
make the 32b and 64b variant explicit in the tune name by changing core2
to core2_32.
Signed-off-by: Darren Hart dvh...@linux.intel.com
Cc: Richard Purdie richard.pur...@linuxfoundation.org
Cc: Paul Eggleton paul.eggle...@intel.com
Cc: Tom Zanussi tom.zanu...@intel.com
Cc: Nitin Kamble nitin.a.kam...@intel.com
Cc: Mark Hatle mark.ha...@windriver.com
Cc: Bruce Ashfield bruce.ashfi...@windriver.com
Cc: Martin Jansa martin.ja...@gmail.com
---
meta/conf/machine/include/tune-core2.inc | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/meta/conf/machine/include/tune-core2.inc
b/meta/conf/machine/include/tune-core2.inc
index 2500a74..11517dc 100644
--- a/meta/conf/machine/include/tune-core2.inc
+++ b/meta/conf/machine/include/tune-core2.inc
@@ -6,7 +6,7 @@
# This tune is recommended for the Intel Core 2 CPU family, including Conroe,
# Merom and beyond, as well as the first Atom CPUs, Diamondville, and beyond.
#
-DEFAULTTUNE ?= core2
+DEFAULTTUNE ?= core2-32
# Include the previous tune to pull in PACKAGE_EXTRA_ARCHS
require conf/machine/include/tune-i586.inc
@@ -16,11 +16,11 @@ TUNEVALID[core2] = Enable core2 specific processor
optimizations
TUNE_CCARGS .= ${@bb.utils.contains(TUNE_FEATURES, core2, -march=core2
-mtune=core2 -msse3 -mfpmath=sse, , d)}
# Extra tune selections
-AVAILTUNES += core2
-TUNE_FEATURES_tune-core2 = ${TUNE_FEATURES_tune-x86} core2
-BASE_LIB_tune-core2 = lib
-TUNE_PKGARCH_tune-core2 = core2
-PACKAGE_EXTRA_ARCHS_tune-core2 = ${PACKAGE_EXTRA_ARCHS_tune-i586} core2
+AVAILTUNES += core2-32
+TUNE_FEATURES_tune-core2-32 = ${TUNE_FEATURES_tune-x86} core2
+BASE_LIB_tune-core2-32 = lib
+TUNE_PKGARCH_tune-core2-32 = core2_32
+PACKAGE_EXTRA_ARCHS_tune-core2-32 = ${PACKAGE_EXTRA_ARCHS_tune-i586} core2_32
AVAILTUNES += core2-64
TUNE_FEATURES_tune-core2-64 = ${TUNE_FEATURES_tune-x86-64} core2
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
