[OE-core] [PATCH 1/6] unfs3: Add a NFSv3 user mode server for use with runqemu
The user mode nfs server allows the use of runqemu without any root
privileges and may even be accelerated with kvm.
Example:
runqemu-extract-sdk
tmp-eglibc/deploy/images/qemux86-64/core-image-minimal-qemux86-64.tar.bz2 rootfs
runqemu qemux86-64 `pwd`/rootfs nographic slirp kvm
[YOCTO #5639]
Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
meta/files/common-licenses/unfs3 | 24 +++
.../unfs3/unfs3/alternate_rpc_ports.patch | 156
.../unfs3/unfs3/fix_compile_warning.patch | 16 ++
.../fix_pid_race_parent_writes_child_pid.patch | 47 ++
.../unfs3/unfs3/fix_warnings.patch | 51 +++
.../unfs3/force_4_byte_long_on_64_bit_host.patch | 39 +
.../unfs3/unfs3/relative_max_socket_path_len.patch | 70 +
.../unfs3/unfs3/rename_fh_cache.patch | 62
.../unfs3/unfs3/tcp_no_delay.patch | 50 +++
.../unfs3/unfs3/unfs3_parallel_build.patch | 36 +
meta/recipes-devtools/unfs3/unfs3_0.9.22.bb| 48 ++
11 files changed, 599 insertions(+)
create mode 100644 meta/files/common-licenses/unfs3
create mode 100644 meta/recipes-devtools/unfs3/unfs3/alternate_rpc_ports.patch
create mode 100644 meta/recipes-devtools/unfs3/unfs3/fix_compile_warning.patch
create mode 100644
meta/recipes-devtools/unfs3/unfs3/fix_pid_race_parent_writes_child_pid.patch
create mode 100644 meta/recipes-devtools/unfs3/unfs3/fix_warnings.patch
create mode 100644
meta/recipes-devtools/unfs3/unfs3/force_4_byte_long_on_64_bit_host.patch
create mode 100644
meta/recipes-devtools/unfs3/unfs3/relative_max_socket_path_len.patch
create mode 100644 meta/recipes-devtools/unfs3/unfs3/rename_fh_cache.patch
create mode 100644 meta/recipes-devtools/unfs3/unfs3/tcp_no_delay.patch
create mode 100644 meta/recipes-devtools/unfs3/unfs3/unfs3_parallel_build.patch
create mode 100644 meta/recipes-devtools/unfs3/unfs3_0.9.22.bb
diff --git a/meta/files/common-licenses/unfs3 b/meta/files/common-licenses/unfs3
new file mode 100644
index 000..7f2b53f
--- /dev/null
+++ b/meta/files/common-licenses/unfs3
@@ -0,0 +1,24 @@
+UNFS3 user-space NFSv3 server
+(C) 2003, Pascal Schmidt unfs3-ser...@ewetel.net
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions are met:
+
+1. Redistributions of source code must retain the above copyright notice,
+ this list of conditions and the following disclaimer.
+2. Redistributions in binary form must reproduce the above copyright notice,
+ this list of conditions and the following disclaimer in the documentation
+ and/or other materials provided with the distribution.
+3. The name of the author may not be used to endorse or promote products
+ derived from this software without specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR IMPLIED
+WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO
+EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
+PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
+OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
+WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
+OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
+ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
diff --git a/meta/recipes-devtools/unfs3/unfs3/alternate_rpc_ports.patch
b/meta/recipes-devtools/unfs3/unfs3/alternate_rpc_ports.patch
new file mode 100644
index 000..8634121
--- /dev/null
+++ b/meta/recipes-devtools/unfs3/unfs3/alternate_rpc_ports.patch
@@ -0,0 +1,156 @@
+Add ability to specify rcp port numbers
+
+In order to run more than one unfs server on a host system, you must
+be able to specify alternate rpc port numbers.
+
+Jason Wessel jason.wes...@windriver.com
+
+---
+ daemon.c | 44 +++-
+ mount.c |4 ++--
+ 2 files changed, 33 insertions(+), 15 deletions(-)
+
+--- a/daemon.c
b/daemon.c
+@@ -75,6 +75,8 @@ int opt_testconfig = FALSE;
+ struct in_addr opt_bind_addr;
+ int opt_readable_executables = FALSE;
+ char *opt_pid_file = NULL;
++int nfs_prog = NFS3_PROGRAM;
++int mount_prog = MOUNTPROG;
+
+ /* Register with portmapper? */
+ int opt_portmapper = TRUE;
+@@ -202,7 +204,7 @@ static void remove_pid_file(void)
+ static void parse_options(int argc, char **argv)
+ {
+ int opt = 0;
+-char *optstring = bcC:de:hl:m:n:prstTuwi:;
++char *optstring = bcC:de:hl:m:n:prstTuwi:x:y:;
+
+ while (opt != -1) {
+ opt = getopt(argc, argv, optstring);
+@@ -257,8 +259,24 @@ static void parse_options(int argc, char
+ printf
+ (\t-r
[OE-core] [PATCH 3/6] runqemu: Use the newer unfs3 for serving user space nfs
From: Saul Wold s...@linux.intel.com This new version correctly handles the 64bit ext3 / ext4 issues we were seeing with the older unfs-server which did not handle 64bit file systems correctly, producing the duplicate cookies. [YOCTO #5639] Signed-off-by: Saul Wold s...@linux.intel.com --- scripts/runqemu-export-rootfs | 53 - scripts/runqemu-internal |2 +- 2 files changed, 6 insertions(+), 49 deletions(-) diff --git a/scripts/runqemu-export-rootfs b/scripts/runqemu-export-rootfs index bbdaf5b..2d87996 100755 --- a/scripts/runqemu-export-rootfs +++ b/scripts/runqemu-export-rootfs @@ -88,8 +88,7 @@ MOUNT_PORT=$[ 3048 + 2 * $NFS_INSTANCE ] ## For debugging you would additionally add ## --debug all -MOUNTD_OPTS=--allow-non-root --mount-pid $MOUNTPID -f $EXPORTS --rmtab $RMTAB --prog $NFS_MOUNTPROG -r -P $MOUNT_PORT -NFSD_OPTS=--allow-non-root --nfs-pid $NFSPID -f $EXPORTS --prog $NFS_NFSPROG -P $NFS_PORT -r +UNFSD_OPTS=-p -N -i $NFSPID -e $EXPORTS -x $NFS_NFSPROG -n $NFS_PORT -y $NFS_MOUNTPROG -m $MOUNT_PORT # Setup the exports file if [ $1 = start ]; then @@ -115,53 +114,18 @@ case $1 in exit 1 fi - echo Starting User Mode rpc.mountd - echo $PSEUDO $PSEUDO_OPTS $OECORE_NATIVE_SYSROOT/usr/sbin/rpc.mountd $MOUNTD_OPTS - $PSEUDO $PSEUDO_OPTS $OECORE_NATIVE_SYSROOT/usr/sbin/rpc.mountd $MOUNTD_OPTS - if [ ! $? = 0 ]; then - echo = - echo Error starting MOUNTD - echo = - if [ ! x$RPCBIND_RUNNING = x ] ; then - echo If you see an error above that says: - echo RPC: Authentication error; why = Client credential too weak - echo You need to add the -i option when running rpcbind - echo === - echo For recent Fedora/RedHat hosts: - echo Add RPCBIND_ARGS=-i to /etc/sysconfig/rpcbind - echo or - echo Add RPCBIND_OPTIONS=-i to /etc/sysconfig/rpcbind - echo Then run as root: /etc/init.d/rpcbind restart - echo === - echo For recent Debian/Ubuntu hosts: - echo Add OPTIONS=\-i -w\ to /etc/default/rpcbind - echo sudo service portmap restart - fi - - exit 1 - fi - echo Starting User Mode nfsd - echo $PSEUDO $PSEUDO_OPTS $OECORE_NATIVE_SYSROOT/usr/sbin/rpc.nfsd $NFSD_OPTS - $PSEUDO $PSEUDO_OPTS $OECORE_NATIVE_SYSROOT/usr/sbin/rpc.nfsd $NFSD_OPTS + echo $PSEUDO $PSEUDO_OPTS $OECORE_NATIVE_SYSROOT/usr/sbin/unfsd $UNFSD_OPTS + $PSEUDO $PSEUDO_OPTS $OECORE_NATIVE_SYSROOT/usr/sbin/unfsd $UNFSD_OPTS if [ ! $? = 0 ]; then echo Error starting nfsd exit 1 fi - # Check to make sure everything started ok. - if [ ! -f $MOUNTPID ]; then - echo rpc.mountd did not start correctly - exit 1 - fi +Check to make sure everything started ok. if [ ! -f $NFSPID ]; then echo rpc.nfsd did not start correctly exit 1 fi - ps -fp `cat $MOUNTPID` /dev/null 2 /dev/null - if [ ! $? = 0 ]; then - echo rpc.mountd did not start correctly - exit 1 - fi ps -fp `cat $NFSPID` /dev/null 2 /dev/null if [ ! $? = 0 ]; then echo rpc.nfsd did not start correctly @@ -169,16 +133,9 @@ case $1 in fi echo echo On your target please remember to add the following options for NFS - echo nfsroot=IP_ADDRESS:$NFS_EXPORT_DIR,nfsvers=2,mountprog=$NFS_MOUNTPROG,nfsprog=$NFS_NFSPROG,udp + echo nfsroot=IP_ADDRESS:$NFS_EXPORT_DIR,nfsvers=3,port=$NFSD_PORT,mountprog=$MOUNTD_RPCPORT,nfsprog=$NFSD_RPCPORT,udp,mountport=$MOUNTD_PORT ;; stop) - if [ -f $MOUNTPID ]; then - echo Stopping rpc.mountd - kill `cat $MOUNTPID` - rm -f $MOUNTPID - else - echo No PID file, not stopping rpc.mountd - fi if [ -f $NFSPID ]; then echo Stopping rpc.nfsd kill `cat $NFSPID` diff --git a/scripts/runqemu-internal b/scripts/runqemu-internal index 284b88c..cecb527 100755 --- a/scripts/runqemu-internal +++ b/scripts/runqemu-internal @@ -308,7 +308,7 @@ if [ $FSTYPE = nfs ]; then NFSD_RPCPORT=$[ 1 + $NFS_INSTANCE ] NFSD_PORT=$[ 3049 + 2 * $NFS_INSTANCE ] MOUNTD_PORT=$[ 3048 + 2 * $NFS_INSTANCE ] - UNFS_OPTS=nfsvers=2,mountprog=$MOUNTD_RPCPORT,nfsprog=$NFSD_RPCPORT,udp,port=$NFSD_PORT,mountport=$MOUNTD_PORT +
[OE-core] [PATCH 5/6] runqemu-export-rootfs: update for unfs3
The unfs3 no longer has an rpc.mountd component. There is just a single server for mountd and nfsd requests. This means changing the name of the server in the scripts that check for it. [YOCTO #5639] Signed-off-by: Jason Wessel jason.wes...@windriver.com --- scripts/runqemu-export-rootfs |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/scripts/runqemu-export-rootfs b/scripts/runqemu-export-rootfs index 2d87996..79403ab 100755 --- a/scripts/runqemu-export-rootfs +++ b/scripts/runqemu-export-rootfs @@ -46,8 +46,8 @@ if [ -z $SYSROOT_SETUP_SCRIPT ]; then fi . $SYSROOT_SETUP_SCRIPT -if [ ! -e $OECORE_NATIVE_SYSROOT/usr/sbin/rpc.mountd ]; then - echo Error: Unable to find rpc.mountd binary in $OECORE_NATIVE_SYSROOT/usr/sbin/ +if [ ! -e $OECORE_NATIVE_SYSROOT/usr/sbin/unfsd ]; then + echo Error: Unable to find unfsd binary in $OECORE_NATIVE_SYSROOT/usr/sbin/ if [ x$OECORE_DISTRO_VERSION = x ]; then echo Have you run 'bitbake meta-ide-support'? -- 1.7.9.5 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] grub-efi.bbclass: Fix startup.nsh to work on more EFI revs
Some revs of the EFI firmware + shell do not automatically setup the
path in a such a way as to execute a binary without an absolute
reference like FS0:\EFI\BOOT\bootx64.efi. All the versions that I
have tested work properly by simply calling the binary which is in the
EFI\BOOT directory by name like bootx64.efi.
The error you see on the console looks like the following:
startup.nsh EFI\BOOT\bootx64.efi
'EFI\BOOT\bootx64.efi' is not recognized as an internal or external command,
operable program, or batch file
Shell
This patch simply drops the EFI\BOOT for greater compatibility.
Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
meta/classes/grub-efi.bbclass |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/grub-efi.bbclass b/meta/classes/grub-efi.bbclass
index 96fb98b..0809ec6 100644
--- a/meta/classes/grub-efi.bbclass
+++ b/meta/classes/grub-efi.bbclass
@@ -48,7 +48,7 @@ grubefi_iso_populate() {
mkdir -p ${EFIIMGDIR}/${EFIDIR}
cp $iso_dir/${EFIDIR}/* ${EFIIMGDIR}${EFIDIR}
cp $iso_dir/vmlinuz ${EFIIMGDIR}
- echo EFI\\BOOT\\${GRUB_IMAGE} ${EFIIMGDIR}/startup.nsh
+ echo ${GRUB_IMAGE} ${EFIIMGDIR}/startup.nsh
if [ -f $iso_dir/initrd ] ; then
cp $iso_dir/initrd ${EFIIMGDIR}
fi
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] syslinux.bbclass: Fix default serial port string
The default value of SYSLINUX_SERIAL_TTY is not correct. It should be console=ttyS0,115200 else the boot string generated in the syslinux menus for the serial choice is not correct. The kernel boot parameters will get set to: /vmlinuz initrd=/initrd LABEL=boot root=/dev/ram0 ttyS0,115200 Note that the above is missing the console= The default value will now work the same as the value found in grub-efi.bbclass. Signed-off-by: Jason Wessel jason.wes...@windriver.com --- meta/classes/syslinux.bbclass |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/classes/syslinux.bbclass b/meta/classes/syslinux.bbclass index 944bd92..2a5b766 100644 --- a/meta/classes/syslinux.bbclass +++ b/meta/classes/syslinux.bbclass @@ -27,7 +27,7 @@ SYSLINUXDIR = / # a console=...some_tty... SYSLINUX_DEFAULT_CONSOLE ?= SYSLINUX_SERIAL ?= 0 115200 -SYSLINUX_SERIAL_TTY ?= ttyS0,115200 +SYSLINUX_SERIAL_TTY ?= console=ttyS0,115200 ISO_BOOTIMG = isolinux/isolinux.bin ISO_BOOTCAT = isolinux/boot.cat MKISOFS_OPTIONS = -no-emul-boot -boot-load-size 4 -boot-info-table -- 1.7.9.5 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] mtools, syslinux: add ability to compile with nativesdk
For regenerating and ISO or EFI boot image the nativesdk needs mtools
and syslinux.
Both recipes are patched in one patch since syslinux requires
mtools.
Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
meta/recipes-devtools/mtools/mtools_3.9.9.bb|9 +++--
meta/recipes-devtools/mtools/mtools_4.0.18.bb | 12 +---
meta/recipes-devtools/syslinux/syslinux_6.01.bb |2 +-
3 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/meta/recipes-devtools/mtools/mtools_3.9.9.bb
b/meta/recipes-devtools/mtools/mtools_3.9.9.bb
index 2213c17..8678a8b 100644
--- a/meta/recipes-devtools/mtools/mtools_3.9.9.bb
+++ b/meta/recipes-devtools/mtools/mtools_3.9.9.bb
@@ -9,8 +9,12 @@ LICENSE = GPLv2+
LIC_FILES_CHKSUM = file://COPYING;md5=92b58ec77696788ce278b044d2a8e9d3
PR = r6
-RDEPENDS_${PN} = glibc-gconv-ibm850
-RRECOMMENDS_${PN} = \
+targetdepgconv =
+targetdepgconv_class-target = glibc-gconv-ibm850
+RDEPENDS_${PN} = ${targetdepgconv}
+
+targetrecgconv =
+targetrecgconv_class-target = \
glibc-gconv-ibm437 \
glibc-gconv-ibm737 \
glibc-gconv-ibm775 \
@@ -26,6 +30,7 @@ RRECOMMENDS_${PN} = \
glibc-gconv-ibm866 \
glibc-gconv-ibm869 \
+RRECOMMENDS_${PN} = ${targetrecgconv}
#http://mtools.linux.lu/mtools-${PV}.tar.gz
SRC_URI =
http://downloads.yoctoproject.org/mirror/sources/mtools-${PV}.tar.gz \
diff --git a/meta/recipes-devtools/mtools/mtools_4.0.18.bb
b/meta/recipes-devtools/mtools/mtools_4.0.18.bb
index dcd6066..602b3c0 100644
--- a/meta/recipes-devtools/mtools/mtools_4.0.18.bb
+++ b/meta/recipes-devtools/mtools/mtools_4.0.18.bb
@@ -6,8 +6,12 @@ LICENSE = GPLv3
LIC_FILES_CHKSUM = file://COPYING;md5=d32239bcb673463ab874e80d47fae504
-RDEPENDS_${PN} = glibc-gconv-ibm850
-RRECOMMENDS_${PN} = \
+targetdepgconv =
+targetdepgconv_class-target = glibc-gconv-ibm850
+RDEPENDS_${PN} = ${targetdepgconv}
+
+targetrecgconv =
+targetrecgconv_class-target = \
glibc-gconv-ibm437 \
glibc-gconv-ibm737 \
glibc-gconv-ibm775 \
@@ -23,6 +27,8 @@ RRECOMMENDS_${PN} = \
glibc-gconv-ibm866 \
glibc-gconv-ibm869 \
+RRECOMMENDS_${PN} = ${targetrecgconv}
+
SRC_URI[md5sum] = a23646617546bf6ad56f061d8b283c85
SRC_URI[sha256sum] =
59e9cf80885399c4f229e5d87e49c0c2bfeec044e1386d59fcd0b0aead6b2f85
@@ -37,4 +43,4 @@ EXTRA_OECONF = --without-x
PARALLEL_MAKEINST =
-BBCLASSEXTEND = native
+BBCLASSEXTEND = native nativesdk
diff --git a/meta/recipes-devtools/syslinux/syslinux_6.01.bb
b/meta/recipes-devtools/syslinux/syslinux_6.01.bb
index 4438ea8..c6e83b5 100644
--- a/meta/recipes-devtools/syslinux/syslinux_6.01.bb
+++ b/meta/recipes-devtools/syslinux/syslinux_6.01.bb
@@ -65,4 +65,4 @@ FILES_${PN}-dev += ${datadir}/${BPN}/com32/lib*${SOLIBS}
${datadir}/${BPN}/com3
FILES_${PN}-staticdev += ${datadir}/${BPN}/com32/lib*.a
${libdir}/${BPN}/com32/lib*.a
FILES_${PN}-misc = ${datadir}/${BPN}/* ${libdir}/${BPN}/* ${bindir}/*
-BBCLASSEXTEND = native
+BBCLASSEXTEND = native nativesdk
--
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] mtools, syslinux: add ability to compile with nativesdk
On 10/30/2013 06:47 PM, Khem Raj wrote:
On Wed, Oct 30, 2013 at 3:48 PM, Jason Wessel
jason.wes...@windriver.com wrote:
For regenerating and ISO or EFI boot image the nativesdk needs mtools
and syslinux.
Both recipes are patched in one patch since syslinux requires
mtools.
as they depend on eglibc/glibc only. Can you also make sure that they
get flagged when building
systems with non-eglibc C libraries.
Is there an example in a recipe of what you are talking about?
I saw in another recipe:
python __anonymous() {
if d.getVar(TARGET_OS, True) != linux:
return
if d.getVar(TCLIBC, True) == eglibc:
raise bb.parse.SkipPackage(libiconv is provided for use with uClibc
only - eglibc already provides iconv)
}
Or is there a build test I should be using to test with uClibc for when things
like this change in general?
Thanks,
Jason.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] syslinux.bbclass: Fix default serial port string
The default value of SYSLINUX_SERIAL_TTY is not correct. It should be console=ttyS0,115200 else the boot string generated in the syslinux menus for the serial choice is not correct. The kernel boot parameters will get set to: /vmlinuz initrd=/initrd LABEL=boot root=/dev/ram0 ttyS0,115200 Note that the above is missing the console= The default value will now work the same as the value found in grub-efi.bbclass. Signed-off-by: Jason Wessel jason.wes...@windriver.com --- meta/classes/syslinux.bbclass |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/classes/syslinux.bbclass b/meta/classes/syslinux.bbclass index 944bd92..2a5b766 100644 --- a/meta/classes/syslinux.bbclass +++ b/meta/classes/syslinux.bbclass @@ -27,7 +27,7 @@ SYSLINUXDIR = / # a console=...some_tty... SYSLINUX_DEFAULT_CONSOLE ?= SYSLINUX_SERIAL ?= 0 115200 -SYSLINUX_SERIAL_TTY ?= ttyS0,115200 +SYSLINUX_SERIAL_TTY ?= console=ttyS0,115200 ISO_BOOTIMG = isolinux/isolinux.bin ISO_BOOTCAT = isolinux/boot.cat MKISOFS_OPTIONS = -no-emul-boot -boot-load-size 4 -boot-info-table -- 1.7.9.5 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] kernel.bbclass: Allow INITRAMFS_TASK to trigger copy initramfs code
Activating the INITRAMFS_TASK can cause circular dependencies, but
that is up to the end user to resolve in recipes. The INITRAMFS_TASK
should also trigger immediate linking of the cpio task in the first
compile pass. This was a subtle regression introduced by: 609d5a9ab
(kernel.bbclass, image.bbclass: Implement kernel INITRAMFS dependency
and bundling).
This patch restores the previous behavior and only affects the
INITRAMFS_TASK which is not set by any of the default build profiles
in oe-core.
Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
meta/classes/kernel.bbclass |6 ++
1 file changed, 6 insertions(+)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 8cf66ce..73c525f 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -156,6 +156,12 @@ kernel_do_compile() {
# different initramfs image. The way to do that in the kernel
# is to specify:
# make ...args... CONFIG_INITRAMFS_SOURCE=some_other_initramfs.cpio
+ if [ $use_alternate_initrd = ] [ ${INITRAMFS_TASK} != ] ;
then
+ # The old style way of copying an prebuilt image and building it
+ # is turned on via INTIRAMFS_TASK !=
+ copy_initramfs
+
use_alternate_initrd=CONFIG_INITRAMFS_SOURCE=${B}/usr/${INITRAMFS_IMAGE}-${MACHINE}.cpio
+ fi
oe_runmake ${KERNEL_IMAGETYPE_FOR_MAKE} ${KERNEL_ALT_IMAGETYPE}
CC=${KERNEL_CC} LD=${KERNEL_LD} ${KERNEL_EXTRA_ARGS} $use_alternate_initrd
if test ${KERNEL_IMAGETYPE_FOR_MAKE}.gz = ${KERNEL_IMAGETYPE}; then
gzip -9c ${KERNEL_IMAGETYPE_FOR_MAKE} ${KERNEL_OUTPUT}
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [v2 PATCH] kernel.bbclass, image.bbclass: Implement kernel INITRAMFS dependency and bundling
On 09/27/2013 04:05 AM, Richard Purdie wrote: On Fri, 2013-09-27 at 10:07 +0200, Andrea Adami wrote: On Sat, Aug 24, 2013 at 7:15 PM, Richard Purdie richard.pur...@linuxfoundation.org wrote: With 1.5 approaching I'd like to have the issue solved as soon as possible. Richard, when is deadline for core-patches? Basically ASAP. The next release build is the start of next week but any patches going into that need to have been run through an autobuilder cycle first. This is the first I've heard of the problem, other than some comments about possible problems on irc. Can someone please open up a bug for this and clearly describe what used to work and now doesn't and what the possible fixes or workarounds are? I don't think anyone likes regressions however if we don't have the open bug, its very hard to track. You say you've talked to Bruce/Jason but why didn't the discussion happen on the mailing list? That way others may have been able to help and now I could read back the list and see for myself what the issue is. As it is, I simply don't know other than the need to set a new variable which is hinted at above... What was needed most was a defect detailing the configuration setup. The reason I have not hit this problem nor any of the other autobuilders was that it required a very specific way to setup the recipes to depend on each other, but not circularly. Andrea sent full details to Bruce, who sent them to me and I built it this morning. It took very little time to isolate the problem but it was one of those oh so subtle issues (patch is sent to oe-core). Perhaps in the future we can just get a Bugzilla opened right away. I don't like regressions either. :-) Andrea replied to me in IRC, I'll test the new patch soon. Cheers, Jason. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] kernel.bbclass: Allow INITRAMFS_TASK to trigger copy initramfs code
On 09/27/2013 04:06 PM, Andrea Adami wrote: | DEBUG: Executing shell function do_compile | Copying initramfs into ./usr ... | cp: cannot create regular file '/oe/oe-core/build/tmp-eglibc/work/poodle-oe-linux-gnueabi/linux-yocto-tiny-kexecboot/3.10.11+gitAUTOINC+dad2b7e1ce_e1aa804148-r0/linux-poodle-tiny-build/usr/.': I suppose that one makes sense given that the compile directory might not exist. My testing did not show this problem because my working env was dirty. Thanks for the report, your fix is perfectly fine. I'll send a v2. Jason. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [v2 PATCH] kernel.bbclass: Allow INITRAMFS_TASK to trigger copy initramfs code
Activating the INITRAMFS_TASK can cause circular dependencies, but
that is up to the end user to resolve in recipes. The INITRAMFS_TASK
should also trigger immediate linking of the cpio task in the first
compile pass. This was a subtle regression introduced by: 609d5a9ab
(kernel.bbclass, image.bbclass: Implement kernel INITRAMFS dependency
and bundling).
This patch restores the previous behavior and only affects the
INITRAMFS_TASK which is not set by any of the default build profiles
in oe-core.
Reviewed-by: Andrea Adami andrea.ad...@gmail.com
Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
meta/classes/kernel.bbclass |8
1 file changed, 8 insertions(+)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 8cf66ce..4acfb7e 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -83,6 +83,8 @@ KERNEL_IMAGETYPE_FOR_MAKE = ${@(lambda s: s[:-3] if s[-3:]
== .gz else s)(d.g
copy_initramfs() {
echo Copying initramfs into ./usr ...
+ # In case the directory is not created yet from the first pass compile:
+ mkdir -p ${B}/usr
# Find and use the first initramfs image archive type we find
rm -f ${B}/usr/${INITRAMFS_IMAGE}-${MACHINE}.cpio
for img in cpio.gz cpio.lzo cpio.lzma cpio.xz; do
@@ -156,6 +158,12 @@ kernel_do_compile() {
# different initramfs image. The way to do that in the kernel
# is to specify:
# make ...args... CONFIG_INITRAMFS_SOURCE=some_other_initramfs.cpio
+ if [ $use_alternate_initrd = ] [ ${INITRAMFS_TASK} != ] ;
then
+ # The old style way of copying an prebuilt image and building it
+ # is turned on via INTIRAMFS_TASK !=
+ copy_initramfs
+
use_alternate_initrd=CONFIG_INITRAMFS_SOURCE=${B}/usr/${INITRAMFS_IMAGE}-${MACHINE}.cpio
+ fi
oe_runmake ${KERNEL_IMAGETYPE_FOR_MAKE} ${KERNEL_ALT_IMAGETYPE}
CC=${KERNEL_CC} LD=${KERNEL_LD} ${KERNEL_EXTRA_ARGS} $use_alternate_initrd
if test ${KERNEL_IMAGETYPE_FOR_MAKE}.gz = ${KERNEL_IMAGETYPE}; then
gzip -9c ${KERNEL_IMAGETYPE_FOR_MAKE} ${KERNEL_OUTPUT}
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] mkefidisk.sh: Allow using a loopback mounted file
There is no reason not allow writing of direct boot disk images for
testing with simulators. The easy way is to add loop back writing
capabilities.
Example:
qemu-img create -f raw bigdisk 4G
dev=`sudo losetup -f`
sudo losetup $dev bigdisk
mkefidisk.sh $dev
tmp-eglibc/deploy/images/qemux86/core-image-minimal-qemux86.hddimg /dev/sda
sudo losetup -d $dev
Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
scripts/contrib/mkefidisk.sh |9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/scripts/contrib/mkefidisk.sh b/scripts/contrib/mkefidisk.sh
index af06b4b..224a146 100755
--- a/scripts/contrib/mkefidisk.sh
+++ b/scripts/contrib/mkefidisk.sh
@@ -142,7 +142,7 @@ SWAP_START=$((ROOTFS_END))
# MMC devices use a partition prefix character 'p'
PART_PREFIX=
-if [ ! ${DEVICE#/dev/mmcblk} = ${DEVICE} ]; then
+if [ ! ${DEVICE#/dev/mmcblk} = ${DEVICE} ] || [ !
${TARGET_DEVICE#/dev/loop} = ${DEVICE} ]; then
PART_PREFIX=p
fi
BOOTFS=$DEVICE${PART_PREFIX}1
@@ -197,7 +197,12 @@ unmount_device
#
echo
echo Formatting $BOOTFS as vfat...
-mkfs.vfat $BOOTFS -n efi
+if [ ! ${DEVICE#/dev/loop} = ${DEVICE} ]; then
+ mkfs.vfat -I $BOOTFS -n efi
+else
+ mkfs.vfat $BOOTFS -n efi
+
+fi
echo Formatting $ROOTFS as ext3...
mkfs.ext3 $ROOTFS -L root
--
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] mkefidisk.sh: Allow using a loopback mounted file
On 09/26/2013 05:45 PM, Darren Hart wrote:
On Thu, 2013-09-26 at 17:34 -0500, Jason Wessel wrote:
There is no reason not allow writing of direct boot disk images for
Nit:^ to
testing with simulators. The easy way is to add loop back writing
capabilities.
Just note here that the /dev/loop device has the same partition prefix
as mmc devices and requires special mkfs arguments.
Example:
qemu-img create -f raw bigdisk 4G
dev=`sudo losetup -f`
sudo losetup $dev bigdisk
mkefidisk.sh $dev
tmp-eglibc/deploy/images/qemux86/core-image-minimal-qemux86.hddimg /dev/sda
sudo losetup -d $dev
Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
scripts/contrib/mkefidisk.sh |9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/scripts/contrib/mkefidisk.sh b/scripts/contrib/mkefidisk.sh
index af06b4b..224a146 100755
--- a/scripts/contrib/mkefidisk.sh
+++ b/scripts/contrib/mkefidisk.sh
@@ -142,7 +142,7 @@ SWAP_START=$((ROOTFS_END))
# MMC devices use a partition prefix character 'p'
PART_PREFIX=
-if [ ! ${DEVICE#/dev/mmcblk} = ${DEVICE} ]; then
+if [ ! ${DEVICE#/dev/mmcblk} = ${DEVICE} ] || [ !
${TARGET_DEVICE#/dev/loop} = ${DEVICE} ]; then
I think you meant to use ${DEVICE#/dev/loop} here? Not TARGET_DEVICE?
Right you are. It worked by accident eh?
I'll send another patch.
Jason.
--
Darren
PART_PREFIX=p
fi
BOOTFS=$DEVICE${PART_PREFIX}1
@@ -197,7 +197,12 @@ unmount_device
#
echo
echo Formatting $BOOTFS as vfat...
-mkfs.vfat $BOOTFS -n efi
+if [ ! ${DEVICE#/dev/loop} = ${DEVICE} ]; then
+mkfs.vfat -I $BOOTFS -n efi
+else
+mkfs.vfat $BOOTFS -n efi
+
+fi
echo Formatting $ROOTFS as ext3...
mkfs.ext3 $ROOTFS -L root
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [v2 PATCH] mkefidisk.sh: Allow using a loopback mounted file
It should be possible to generate a disk to a file using a loopback
device with mkefidisk.sh, which is useful for booting simulators. To
make this possible the partitions for the loop back need to work
similarly to the mmc devices. The mkfs.vfat also requires and
additional argument to force it to write to something other then a
real disk.
Example:
qemu-img create -f raw bigdisk 4G
dev=`sudo losetup -f`
sudo losetup $dev bigdisk
mkefidisk.sh $dev
tmp-eglibc/deploy/images/qemux86/core-image-minimal-qemux86.hddimg /dev/sda
sudo losetup -d $dev
Note:
Also a bug was fixed in the mkefidisk.sh where if the disk you are
writing to initially has an invalid label the size of the first
partition will be computed incorrectly. For the simulator disk
creation this is generally always the case, but this can happen with
real hardware as well.
Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
scripts/contrib/mkefidisk.sh | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/scripts/contrib/mkefidisk.sh b/scripts/contrib/mkefidisk.sh
index af06b4b..c86849d 100755
--- a/scripts/contrib/mkefidisk.sh
+++ b/scripts/contrib/mkefidisk.sh
@@ -134,6 +134,11 @@ fi
# 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
+ 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))
ROOTFS_SIZE=$((DEVICE_SIZE-BOOT_SIZE-SWAP_SIZE))
ROOTFS_START=$((BOOT_SIZE))
@@ -142,7 +147,7 @@ SWAP_START=$((ROOTFS_END))
# MMC devices use a partition prefix character 'p'
PART_PREFIX=
-if [ ! ${DEVICE#/dev/mmcblk} = ${DEVICE} ]; then
+if [ ! ${DEVICE#/dev/mmcblk} = ${DEVICE} ] || [ ! ${DEVICE#/dev/loop} =
${DEVICE} ]; then
PART_PREFIX=p
fi
BOOTFS=$DEVICE${PART_PREFIX}1
@@ -197,7 +202,12 @@ unmount_device
#
echo
echo Formatting $BOOTFS as vfat...
-mkfs.vfat $BOOTFS -n efi
+if [ ! ${DEVICE#/dev/loop} = ${DEVICE} ]; then
+ mkfs.vfat -I $BOOTFS -n efi
+else
+ mkfs.vfat $BOOTFS -n efi
+
+fi
echo Formatting $ROOTFS as ext3...
mkfs.ext3 $ROOTFS -L root
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [v3 PATCH 0/9] Improved EFI boot support
On 09/20/2013 12:11 PM, Darren Hart wrote: So with these now upstream, I'm hitting the following after removing NO_ISO=1 from the MinnowBoard machine config. Is anything missing? Have you validated this is working for you after the merge? Only the first 2 patches in the series were actually merged, and the patches that provide the functionality you are looking for are not yet merged. Does that mean that I should post the remaining 7 patches again? I don't know if it was the intent to only partially merge things or not. Perhaps Saul is still doing some testing because 2 of the 9 patches (the 2 that were merged) came from his unified pull to Richard. Cheers, Jason. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [v2 PATCH 5/7] bootimage.bbclass, grub-efi.bbclass: Improve EFI PCBIOS+EFI ISO support
On 09/16/2013 12:30 PM, Darren Hart wrote:
On Fri, 2013-09-13 at 19:09 -0500, Jason Wessel wrote:
-if [ ${PCBIOS} = 1 ]; then
+# EFI only
+if [ ${PCBIOS} != 1 ] [ ${EFI} = 1 ] ; then
+mkdir -p ${ISODIR}/${ISOLINUXDIR}
+install -m 0644 ${STAGING_DATADIR}/syslinux/isolinux.bin
${ISODIR}${ISOLINUXDIR}
If it's EFI-only, we copy isolinux.bin over? I was under the impression
isolinux.bin was a PCBIOS thing (specifically an executable that
wouldn't even work in an EFI environment). How is this used with an
EFI-only image? What am I missing?
There is a bug/feature in the isohybrid that requires it to be in the catalog.
I couldn't figure out how to work around it, so I left it in there. The EFI
firmware skips right over it anyway. I can add a comment to the bbclass to
this effect.
+fi
+
+if [ ${PCBIOS} = 1 ] [ ${EFI} != 1 ] ; then
+# PCBIOS only media
mkisofs -V ${BOOTIMG_VOLUME_ID} \
-o ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.iso \
-b ${ISO_BOOTIMG} -c ${ISO_BOOTCAT} -r \
${MKISOFS_OPTIONS} ${ISODIR}
else
-bbnote EFI-only ISO images are untested, please provide
feedback.
-mkisofs -V ${BOOTIMG_VOLUME_ID} \
+# EFI only OR EFI+PCIBIOS
Nit: s/PCIBIOS/PCBIOS/
Oops, all fixed in v3. :-)
Jason.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [v2 PATCH 7/7] bootimage.bbclass, zisofs-tools-native: add ability to compress ISO images
On 09/16/2013 12:57 PM, Darren Hart wrote:
On Fri, 2013-09-13 at 19:09 -0500, Jason Wessel wrote:
+COMPRESSISO ?=
Would an explicit '0' here be better?
That is fine by me.
+
+do_install() {
+oe_runmake install INSTALLROOT=${D} bindir=${bindir}
+}
Does EXTRA_OEMAKE not work here? I see it isn't listed in the reference
manual for the install step (just the compile step), so perhaps not.
Just wanted to check.
It does not work. I could patch the Makefile to make it work but I don't think
it is worth it, vs just leaving things unchanged for future uprev ease.
Cheers,
Jason.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 5/5] grub-efi.bbclass: Add serial and graphics menu options
On 09/16/2013 12:49 PM, Darren Hart wrote: On Fri, 2013-09-13 at 16:58 -0500, Jason Wessel wrote: On 09/12/2013 03:09 PM, Darren Hart wrote: On Thu, 2013-09-12 at 14:52 -0500, Jason Wessel wrote: On 09/12/2013 01:16 PM, Darren Hart wrote: On Thu, 2013-09-12 at 12:19 -0500, Jason Wessel wrote: ... +GRUB_SERIAL ?= console=ttyS0,115200 ... I'm not very familiar with the cfgfile for menus and such, so I don't have much to add. The one thing that catches me by surprise is the need for the serial device. On EFI systems, grub here uses the EFI console service, so if that uses the serial port you get it for free, no need for GRUB to try and use it directly. In fact does the above not cause some kind of conflict between the EFI console service and grub serial? In part that is why it is optional. With respect to the serial bits, these are only the kernel boot arguments we are talking about. It Hrm this should be handled with APPEND parameter from the machine configs, not a new GRUB_SERIAL statement Well there is a problem with that. You only have 1 APPEND, but I need 2 options. The whole point is the ability to add SERIAL or Graphics I don't follow. Do you mean you need both serial and VGA? That is still handled by the single variable. Take the FRI2 for example: APPEND += console=ttyPCH1,115200 console=tty0 With what you have here, it seems to me this will be ignored and GRUB will instead pass console=ttyS0,115200 - which will not work on the FRI2. This is fixed in the new series. The auto menu is intended to offer the end user the choice of which is their default console. Obviously you can emit text to both, but you only get one selected as the default input device. It might not be obvious but we use mingetty and selectively use the console. The whole alternate boot thing is completely optional. Now if you set the SERIAL stuff to be . It might even be better to point this out more directly by changing the variable names to something like ALT_CONSOLE... console access for early boot all the way through user space hand off and seamlessly picking things up later in user space with mingetty etc... This option is mainly used for the installer media and to provide a consistent look and feel regardless if you come from EFI or a PCIBIOS + syslinux. SYSLINUX also has some recipe-specific console options, but those are due to the syntax differences and are used to specify how syslinux talks to the device, while this appears to be Linux kernel syntax (console=ttyS0) rather than grub syntax (serial --unit=0 --speed=115200)... and yet I don't see the console=ttyS0 being passed to the kernel so I am confused. Where does the GRUB_SERIAL content actually get used? I mean besides the creation of the btypes array This is addressed to, but we may yet go another round to clean up the understanding of things. A v3 to arrive soon. Cheers, Jason. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [v3 PATCH 1/9] bootimage.bbclass: Move fat image creation into a function
In order to call the fat image creation multiple times it needs to be
in its own function. A future commit will make use of the new
function to additionally create EFI image files for use with an ISO.
[YOCTO #4100]
[YOCTO #1913]
Signed-off-by: Jason Wessel jason.wes...@windriver.com
Reviewed-by: Darren Hart dvh...@linux.intel.com
---
meta/classes/bootimg.bbclass | 110 ++
1 file changed, 58 insertions(+), 52 deletions(-)
diff --git a/meta/classes/bootimg.bbclass b/meta/classes/bootimg.bbclass
index 90a241d..bd211fb 100644
--- a/meta/classes/bootimg.bbclass
+++ b/meta/classes/bootimg.bbclass
@@ -111,6 +111,63 @@ build_iso() {
ln -s ${IMAGE_NAME}.iso ${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.iso
}
+build_fat_img() {
+ FATSOURCEDIR=$1
+ FATIMG=$2
+
+ # Calculate the size required for the final image including the
+ # data and filesystem overhead.
+ # Sectors: 512 bytes
+ # Blocks: 1024 bytes
+
+ # Determine the sector count just for the data
+ SECTORS=$(expr $(du --apparent-size -ks ${FATSOURCEDIR} | cut -f 1) \*
2)
+
+ # Account for the filesystem overhead. This includes directory
+ # entries in the clusters as well as the FAT itself.
+ # Assumptions:
+ # FAT32 (12 or 16 may be selected by mkdosfs, but the extra
+ # padding will be minimal on those smaller images and not
+ # worth the logic here to caclulate the smaller FAT sizes)
+ #16 entries per directory
+ # 8.3 filenames only
+
+ # 32 bytes per dir entry
+ DIR_BYTES=$(expr $(find ${FATSOURCEDIR} | tail -n +2 | wc -l) \* 32)
+ # 32 bytes for every end-of-directory dir entry
+ DIR_BYTES=$(expr $DIR_BYTES + $(expr $(find ${FATSOURCEDIR} -type d |
tail -n +2 | wc -l) \* 32))
+ # 4 bytes per FAT entry per sector of data
+ FAT_BYTES=$(expr $SECTORS \* 4)
+ # 4 bytes per FAT entry per end-of-cluster list
+ FAT_BYTES=$(expr $FAT_BYTES + $(expr $(find ${FATSOURCEDIR} -type d |
tail -n +2 | wc -l) \* 4))
+
+ # Use a ceiling function to determine FS overhead in sectors
+ DIR_SECTORS=$(expr $(expr $DIR_BYTES + 511) / 512)
+ # There are two FATs on the image
+ FAT_SECTORS=$(expr $(expr $(expr $FAT_BYTES + 511) / 512) \* 2)
+ SECTORS=$(expr $SECTORS + $(expr $DIR_SECTORS + $FAT_SECTORS))
+
+ # Determine the final size in blocks accounting for some padding
+ BLOCKS=$(expr $(expr $SECTORS / 2) + ${BOOTIMG_EXTRA_SPACE})
+
+ # Ensure total sectors is an integral number of sectors per
+ # track or mcopy will complain. Sectors are 512 bytes, and we
+ # generate images with 32 sectors per track. This calculation is
+ # done in blocks, thus the mod by 16 instead of 32.
+ BLOCKS=$(expr $BLOCKS + $(expr 16 - $(expr $BLOCKS % 16)))
+
+ # mkdosfs will sometimes use FAT16 when it is not appropriate,
+ # resulting in a boot failure from SYSLINUX. Use FAT32 for
+ # images larger than 512MB, otherwise let mkdosfs decide.
+ if [ $(expr $BLOCKS / 1024) -gt 512 ]; then
+ FATSIZE=-F 32
+ fi
+
+ mkdosfs ${FATSIZE} -n ${BOOTIMG_VOLUME_ID} -S 512 -C ${FATIMG} ${BLOCKS}
+ # Copy FATSOURCEDIR recursively into the image file directly
+ mcopy -i ${FATIMG} -s ${FATSOURCEDIR}/* ::/
+}
+
build_hddimg() {
# Create an HDD image
if [ ${NOHDD} != 1 ] ; then
@@ -123,58 +180,7 @@ build_hddimg() {
grubefi_hddimg_populate
fi
- # Calculate the size required for the final image including the
- # data and filesystem overhead.
- # Sectors: 512 bytes
- # Blocks: 1024 bytes
-
- # Determine the sector count just for the data
- SECTORS=$(expr $(du --apparent-size -ks ${HDDDIR} | cut -f 1)
\* 2)
-
- # Account for the filesystem overhead. This includes directory
- # entries in the clusters as well as the FAT itself.
- # Assumptions:
- # FAT32 (12 or 16 may be selected by mkdosfs, but the extra
- # padding will be minimal on those smaller images and not
- # worth the logic here to caclulate the smaller FAT sizes)
- #16 entries per directory
- # 8.3 filenames only
-
- # 32 bytes per dir entry
- DIR_BYTES=$(expr $(find ${HDDDIR} | tail -n +2 | wc -l) \* 32)
- # 32 bytes for every end-of-directory dir entry
- DIR_BYTES=$(expr $DIR_BYTES + $(expr $(find ${HDDDIR} -type d |
tail -n +2 | wc -l) \* 32))
- # 4 bytes per FAT entry per sector of data
- FAT_BYTES=$(expr $SECTORS \* 4)
- # 4 bytes per FAT entry per end-of-cluster list
- FAT_BYTES=$(expr $FAT_BYTES + $(expr $(find ${HDDDIR} -type d |
tail -n
[OE-core] [v3 PATCH 4/9] syslinux.bbclass, syslinux: Update to syslinux 6.01
A newer version of syslinux is required for an EFI enabled isohybrid.
This is used for the the capability to generate 3 types of ISO images,
all of which can be booted off a USB device or HDD if copied with dd.
1) PC BIOS only ISO
2) EFI only ISO
3) EFI + PC BIOS ISO
The syslinux.bbclass required a minor tweak because a few .c32
libraries require dynamic loading from the created media as of
syslinux 5 and up. This was a good time to also fix the
duplication of the AUTO_SYSLINUXMENU block.
[YOCTO #4100]
Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
meta/classes/syslinux.bbclass | 21 +++-
.../{syslinux_4.07.bb = syslinux_6.01.bb} | 26
2 files changed, 25 insertions(+), 22 deletions(-)
rename meta/recipes-devtools/syslinux/{syslinux_4.07.bb = syslinux_6.01.bb}
(63%)
diff --git a/meta/classes/syslinux.bbclass b/meta/classes/syslinux.bbclass
index dae6609..223e4dc 100644
--- a/meta/classes/syslinux.bbclass
+++ b/meta/classes/syslinux.bbclass
@@ -36,28 +36,25 @@ syslinux_populate() {
# Install the config files
install -m 0644 ${SYSLINUXCFG} ${DEST}${BOOTDIR}/${CFGNAME}
+ if [ ${AUTO_SYSLINUXMENU} = 1 ] ; then
+ install -m 0644 ${STAGING_DATADIR}/syslinux/vesamenu.c32
${DEST}${BOOTDIR}/vesamenu.c32
+ install -m 0444 ${STAGING_DATADIR}/syslinux/libcom32.c32
${DEST}${BOOTDIR}/libcom32.c32
+ install -m 0444 ${STAGING_DATADIR}/syslinux/libutil.c32
${DEST}${BOOTDIR}/libutil.c32
+ if [ ${SYSLINUX_SPLASH} != ] ; then
+ install -m 0644 ${SYSLINUX_SPLASH}
${DEST}${BOOTDIR}/splash.lss
+ fi
+ fi
}
syslinux_iso_populate() {
syslinux_populate ${ISODIR} ${ISOLINUXDIR} isolinux.cfg
install -m 0644 ${STAGING_DATADIR}/syslinux/isolinux.bin
${ISODIR}${ISOLINUXDIR}
- if [ ${AUTO_SYSLINUXMENU} = 1 ] ; then
- install -m 0644 ${STAGING_DATADIR}/syslinux/vesamenu.c32
${ISODIR}${ISOLINUXDIR}/vesamenu.c32
- if [ ${SYSLINUX_SPLASH} != ] ; then
- install -m 0644 ${SYSLINUX_SPLASH}
${ISODIR}${ISOLINUXDIR}/splash.lss
- fi
- fi
+ install -m 0644 ${STAGING_DATADIR}/syslinux/ldlinux.c32
${ISODIR}${ISOLINUXDIR}
}
syslinux_hddimg_populate() {
syslinux_populate ${HDDDIR} ${SYSLINUXDIR} syslinux.cfg
install -m 0444 ${STAGING_DATADIR}/syslinux/ldlinux.sys
${HDDDIR}${SYSLINUXDIR}/ldlinux.sys
- if [ ${AUTO_SYSLINUXMENU} = 1 ] ; then
- install -m 0644 ${STAGING_DATADIR}/syslinux/vesamenu.c32
${HDDDIR}${SYSLINUXDIR}/vesamenu.c32
- if [ ${SYSLINUX_SPLASH} != ] ; then
- install -m 0644 ${SYSLINUX_SPLASH}
${HDDDIR}${SYSLINUXDIR}/splash.lss
- fi
- fi
}
syslinux_hddimg_install() {
diff --git a/meta/recipes-devtools/syslinux/syslinux_4.07.bb
b/meta/recipes-devtools/syslinux/syslinux_6.01.bb
similarity index 63%
rename from meta/recipes-devtools/syslinux/syslinux_4.07.bb
rename to meta/recipes-devtools/syslinux/syslinux_6.01.bb
index bba5dda..4438ea8 100644
--- a/meta/recipes-devtools/syslinux/syslinux_4.07.bb
+++ b/meta/recipes-devtools/syslinux/syslinux_6.01.bb
@@ -2,19 +2,21 @@ DESCRIPTION = A multi-purpose linux bootloader
HOMEPAGE = http://syslinux.zytor.com/;
LICENSE = GPLv2+
LIC_FILES_CHKSUM = file://COPYING;md5=0636e73ff0215e8d672dc4c32c317bb3 \
-
file://README;beginline=35;endline=41;md5=f7249a750bc692d1048b2626752aa415
+
file://README;beginline=35;endline=41;md5=558f2c71cb1fb9ba511ccd4858e48e8a
# If you really want to run syslinux, you need mtools. We just want the
# ldlinux.* stuff for now, so skip mtools-native
DEPENDS = nasm-native util-linux
-PR = r0
-SRC_URI =
${KERNELORG_MIRROR}/linux/utils/boot/syslinux/4.xx/syslinux-${PV}.tar.bz2
+SRC_URI =
${KERNELORG_MIRROR}/linux/utils/boot/syslinux/6.xx/syslinux-${PV}.tar.bz2
-SRC_URI[md5sum] = 9ff6e1b94efab931fb4717b600d88779
-SRC_URI[sha256sum] =
1240a4e4219b518bdaef78931b6e901befeff35e6894ac6db785115848a7a05a
+SRC_URI[md5sum] = 6945ee89e29119d459baed4937bbc534
+SRC_URI[sha256sum] =
83a04cf81e6a46b80ee5a321926eea095af3498b04317e3674b46c125c7a5b43
COMPATIBLE_HOST = '(x86_64|i.86).*-(linux|freebsd.*)'
+# Don't let the sanity checker trip on the 32 bit real mode BIOS binaries
+INSANE_SKIP_${PN}-misc = arch
+INSANE_SKIP_${PN}-chain = arch
EXTRA_OEMAKE = \
BINDIR=${bindir} SBINDIR=${sbindir} LIBDIR=${libdir} \
@@ -28,21 +30,25 @@ do_configure() {
sed -e 's,win32/\S*,,g' -i Makefile
# clean installer executables included in source tarball
- oe_runmake clean
+ oe_runmake clean firmware=efi32 EFIINC=${includedir}
+ # NOTE: There is a temporary work around above to specify
+ # the efi32 as the firmware else the pre-built bios
+ # files get erased contrary
[OE-core] [v3 PATCH 0/9] Improved EFI boot support
V3 - Add comment about isolinux.bin required in EFI only case - Fix typo of PCIBIOS - PCBIOS - Change COMPRESSISO ?= - COMPRESSISO ?= 0 for the default - Add comment to EFI/ISO syslinux.bbclass to clarify workaround with EFI only case and hybrid boot - Add patch to fix syslinux serial and menu problems - Add patch to fix boot-directdisk.bbclass * Two new patches are 7 8, the zisofs patch moved from 7 - 9 V2 - Added reference to YOCTO #1913 for per Darren - Remove PR number from cdrtools uprev - Added Saul's change to cdrtools to get rid of STAGE_TEMP - made the builtin grub cfg file copied from a SRC_URI - upreved syslinux to 6.01 - Use the new isohybrid command from syslinux which can now generate EFI enabled ISO's which can boot directly when dd'ed to a USB or HDD device. - Dropped any references to efi or pcbios in the qemu* configs - Added the zisofs patch to the end of the series instead of depending on it, in case it is dropped later. - git -format-patch -M20% is your friend for seeing the delta on recipe upgrades :-) YAY, with the new version of syslinux it is now possible to build a single live ISO image which can boot in legacy mode or EFI on optical media or USB devices. We still have to create 2 ISO's one for 32bit EFI systems and one for 64bit EFI systems but this is also true of all other Linux distributions today as well. Jason. --- The goal of this patch set is to put the EFI ISO boot method on par with the ISO PCBIOS boot method. This also allows for the creation of a single ISO image which can boot in legacy boot mode or EFI boot mode. In order to make this possible the cdrtools needed an update to the very latest and this brings in an license change. Given that change it was not entirely clear to me if we needed to leave the older package around. I opted to remove the older package recipe since there was no clean way to fail in the case you wanted to build EFI boot media. The bbnote that was previously in the bootimg.bbclass about EFI only media being untested was a bit of an understatement, as the images would not even build without errors due to the call to isohybrid. I removed any such warnings because that path has been fully vetted now. Cheers, Jason. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [v3 PATCH 6/9] grub-efi.bbclass: Add serial and graphics menu options
The syslinux.bbclass already has support for automatically generated
serial and graphics menu choices. This patch adds the same concept to
the grub-efi menu. That makes it possible to generate a single image
which can boot on a PCBIOS or EFI firmware with consistent looking
boot options.
[YOCTO #4100]
Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
meta/classes/grub-efi.bbclass | 41 +++--
1 file changed, 27 insertions(+), 14 deletions(-)
diff --git a/meta/classes/grub-efi.bbclass b/meta/classes/grub-efi.bbclass
index c21babb..ffbcf4c 100644
--- a/meta/classes/grub-efi.bbclass
+++ b/meta/classes/grub-efi.bbclass
@@ -9,6 +9,7 @@
# External variables
# ${INITRD} - indicates a filesystem image to use as an initrd (optional)
# ${ROOTFS} - indicates a filesystem image to include as the root filesystem
(optional)
+# ${GRUB_GFXSERIAL} - set this to 1 to have graphics and serial in the boot
menu
# ${LABELS} - a list of targets for the automatic config
# ${APPEND} - an override list of append strings for each label
# ${GRUB_OPTS} - additional options to add to the config, ';' delimited #
(optional)
@@ -16,6 +17,7 @@
do_bootimg[depends] += grub-efi-${TRANSLATED_TARGET_ARCH}-native:do_deploy
+GRUB_SERIAL ?= console=ttyS0,115200
GRUBCFG = ${S}/grub.cfg
GRUB_TIMEOUT ?= 10
#FIXME: build this from the machine config
@@ -63,6 +65,8 @@ python build_grub_cfg() {
bb.error(WORKDIR not defined, unable to package)
return
+gfxserial = d.getVar('GRUB_GFXSERIAL', True) or
+
labels = d.getVar('LABELS', True)
if not labels:
bb.debug(1, LABELS not defined, nothing to do)
@@ -96,6 +100,12 @@ python build_grub_cfg() {
else:
cfgfile.write('timeout=50\n')
+if gfxserial == 1:
+btypes = [ [ graphics console, ],
+[ serial console, d.getVar('GRUB_SERIAL', True) or ] ]
+else:
+btypes = [ [ , ] ]
+
for label in labels.split():
localdata = d.createCopy()
@@ -103,24 +113,27 @@ python build_grub_cfg() {
if not overrides:
raise bb.build.FuncFailed('OVERRIDES not defined')
-localdata.setVar('OVERRIDES', label + ':' + overrides)
-bb.data.update_data(localdata)
+for btype in btypes:
+localdata.setVar('OVERRIDES', label + ':' + overrides)
+bb.data.update_data(localdata)
-cfgfile.write('\nmenuentry \'%s\'{\n' % (label))
-if label == install:
-label = install-efi
-cfgfile.write('linux /vmlinuz LABEL=%s' % (label))
+cfgfile.write('\nmenuentry \'%s%s\'{\n' % (label, btype[0]))
+lb = label
+if label == install:
+lb = install-efi
+cfgfile.write('linux /vmlinuz LABEL=%s' % (lb))
-append = localdata.getVar('APPEND', True)
-initrd = localdata.getVar('INITRD', True)
+append = localdata.getVar('APPEND', True)
+initrd = localdata.getVar('INITRD', True)
-if append:
-cfgfile.write('%s' % (append))
-cfgfile.write('\n')
+if append:
+cfgfile.write('%s' % (append))
+cfgfile.write(' %s' % btype[1])
+cfgfile.write('\n')
-if initrd:
-cfgfile.write('initrd /initrd')
-cfgfile.write('\n}\n')
+if initrd:
+cfgfile.write('initrd /initrd')
+cfgfile.write('\n}\n')
cfgfile.close()
}
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [v3 PATCH 7/9] syslinux.bbclass: Fix hard coding of console=tty*
The SYSLINUX_SERIAL variable was hard coded and occasionally needs to
be different for the kernel argument vs the syslinux argument.
In the auto-generated boot mode console=tty0 was hard coded, and this
is not needed at all, and causes problems in some cases if a end user
wanted to change the console=... via the kernel boot argument APPEND
mechanism. The default can be forced with SYSLINUX_DEFAULT_CONSOLE
for systems that need a special specification to enable the frame
buffer instead of a serial port.
[YOCTO #3944]
Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
meta/classes/syslinux.bbclass | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/meta/classes/syslinux.bbclass b/meta/classes/syslinux.bbclass
index 223e4dc..91b9731 100644
--- a/meta/classes/syslinux.bbclass
+++ b/meta/classes/syslinux.bbclass
@@ -12,7 +12,9 @@
# ${APPEND} - an override list of append strings for each label
# ${SYSLINUX_OPTS} - additional options to add to the syslinux file ';'
delimited
# ${SYSLINUX_SPLASH} - A background for the vga boot menu if using the boot
menu
+# ${SYSLINUX_DEFAULT_CONSOLE} - set to console=ttyX to change kernel boot
default console
# ${SYSLINUX_SERIAL} - Set an alternate serial port or turn off serial with
empty string
+# ${SYSLINUX_SERIAL_TTY} - Set alternate console=tty... kernel boot argument
do_bootimg[depends] += syslinux:do_populate_sysroot \
syslinux-native:do_populate_sysroot
@@ -21,7 +23,11 @@ SYSLINUXCFG = ${S}/syslinux.cfg
ISOLINUXDIR = /isolinux
SYSLINUXDIR = /
+# The kernel has an internal default console, which you can override with
+# a console=...some_tty...
+SYSLINUX_DEFAULT_CONSOLE ?=
SYSLINUX_SERIAL ?= 0 115200
+SYSLINUX_SERIAL_TTY ?= ttyS0,115200
ISO_BOOTIMG = isolinux/isolinux.bin
ISO_BOOTCAT = isolinux/boot.cat
MKISOFS_OPTIONS = -no-emul-boot -boot-load-size 4 -boot-info-table
@@ -102,6 +108,8 @@ python build_syslinux_cfg () {
cfgfile.write('%s\n' % opt)
cfgfile.write('ALLOWOPTIONS 1\n');
+syslinux_default_console = d.getVar('SYSLINUX_DEFAULT_CONSOLE', True)
+syslinux_serial_tty = d.getVar('SYSLINUX_SERIAL_TTY', True)
syslinux_serial = d.getVar('SYSLINUX_SERIAL', True)
if syslinux_serial:
cfgfile.write('SERIAL %s\n' % syslinux_serial)
@@ -144,10 +152,10 @@ python build_syslinux_cfg () {
localdata.setVar('OVERRIDES', label + ':' + overrides)
bb.data.update_data(localdata)
-btypes = [ [ , console=tty0 ] ]
+btypes = [ [ , syslinux_default_console ] ]
if menu and syslinux_serial:
-btypes = [ [ Graphics console , console=tty0 ],
-[ Serial console , console=ttyS0,115200 ] ]
+btypes = [ [ Graphics console , syslinux_default_console ],
+[ Serial console , syslinux_serial_tty ] ]
for btype in btypes:
cfgfile.write('LABEL %s%s\nKERNEL /vmlinuz\n' % (btype[0], label))
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [v3 PATCH 5/9] bootimage.bbclass, grub-efi.bbclass: Improve EFI PCBIOS+EFI ISO support
Using the latest mkisofs it is possible to generate 3 different types
of ISO images, which can be used in various scenarios.
1) PCBIOS Only ISO
- This option remains unchanged by this commit
- Uses syslinux menus
- Can be directly copied with dd to a USB device
- Can be burned to optical media
2) EFI Only ISO
- Uses grub 2 menus
- Can be burned to optical media
- If you want to use this image on a USB device
extra steps must be taken in order to format the USB
device with fat32, and copy an EFI loader which will
in turn load the iso image
3) PCBIOS / EFI ISO
- This is a hybrid image ISO that will work for case 1 or 2
as above with the same restrictions and boot menu types
depending on what type of firmware is installed on
the hardware or depending on if EFI or Legacy Boot is
enabled on some UEFI firmwares.
The syslinux.bbclass is now always required because that is where the
isohybrid dependencies come from as well as the configuration data for
the isohybrid. The isohybrid is the secret sauce which allows the ISO
to work as optical media or as a disk image on USB or a HDD/SSD.
[YOCTO #4100]
Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
meta/classes/bootimg.bbclass | 35 +++
meta/classes/grub-efi.bbclass |8
2 files changed, 31 insertions(+), 12 deletions(-)
diff --git a/meta/classes/bootimg.bbclass b/meta/classes/bootimg.bbclass
index bd211fb..fdd4ea9 100644
--- a/meta/classes/bootimg.bbclass
+++ b/meta/classes/bootimg.bbclass
@@ -32,6 +32,7 @@ EXCLUDE_FROM_WORLD = 1
HDDDIR = ${S}/hddimg
ISODIR = ${S}/iso
+EFIIMGDIR = ${S}/efi_img
BOOTIMG_VOLUME_ID ?= boot
BOOTIMG_EXTRA_SPACE ?= 512
@@ -48,15 +49,10 @@ def pcbios(d):
pcbios = base_contains(MACHINE_FEATURES, efi, 0, 1, d)
return pcbios
-def pcbios_class(d):
-if d.getVar(PCBIOS, True) == 1:
-return syslinux
-return
-
PCBIOS = ${@pcbios(d)}
-PCBIOS_CLASS = ${@pcbios_class(d)}
-inherit ${PCBIOS_CLASS}
+# The syslinux is required for the isohybrid command and boot catalog
+inherit syslinux
inherit ${EFI_CLASS}
populate() {
@@ -90,21 +86,36 @@ build_iso() {
fi
if [ ${EFI} = 1 ]; then
grubefi_iso_populate
+ build_fat_img ${EFIIMGDIR} ${ISODIR}/efi.img
fi
- if [ ${PCBIOS} = 1 ]; then
+ # EFI only
+ if [ ${PCBIOS} != 1 ] [ ${EFI} = 1 ] ; then
+ # Work around bug in isohybrid where it requires isolinux.bin
+ # In the boot catalog, even though it is not used
+ mkdir -p ${ISODIR}/${ISOLINUXDIR}
+ install -m 0644 ${STAGING_DATADIR}/syslinux/isolinux.bin
${ISODIR}${ISOLINUXDIR}
+ fi
+
+ if [ ${PCBIOS} = 1 ] [ ${EFI} != 1 ] ; then
+ # PCBIOS only media
mkisofs -V ${BOOTIMG_VOLUME_ID} \
-o ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.iso \
-b ${ISO_BOOTIMG} -c ${ISO_BOOTCAT} -r \
${MKISOFS_OPTIONS} ${ISODIR}
else
- bbnote EFI-only ISO images are untested, please provide
feedback.
- mkisofs -V ${BOOTIMG_VOLUME_ID} \
+ # EFI only OR EFI+PCBIOS
+ mkisofs -A ${BOOTIMG_VOLUME_ID} -V ${BOOTIMG_VOLUME_ID} \
-o ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.iso \
- -r ${ISODIR}
+ -b ${ISO_BOOTIMG} -c ${ISO_BOOTCAT} \
+ -r ${MKISOFS_OPTIONS} \
+ -eltorito-alt-boot -eltorito-platform efi \
+ -b efi.img -no-emul-boot \
+ ${ISODIR}
+ isohybrid_args=-u
fi
- isohybrid ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.iso
+ isohybrid $isohybrid_args ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.iso
cd ${DEPLOY_DIR_IMAGE}
rm -f ${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.iso
diff --git a/meta/classes/grub-efi.bbclass b/meta/classes/grub-efi.bbclass
index c6f5d4e..c21babb 100644
--- a/meta/classes/grub-efi.bbclass
+++ b/meta/classes/grub-efi.bbclass
@@ -41,6 +41,14 @@ grubefi_populate() {
grubefi_iso_populate() {
grubefi_populate ${ISODIR}
+ # Build a EFI directory to create efi.img
+ mkdir -p ${EFIIMGDIR}/${EFIDIR}
+ cp ${ISODIR}/${EFIDIR}/* ${EFIIMGDIR}${EFIDIR}
+ cp ${ISODIR}/vmlinuz ${EFIIMGDIR}
+ echo EFI\\BOOT\\${GRUB_IMAGE} ${EFIIMGDIR}/startup.nsh
+ if [ -f ${ISODIR}/initrd ] ; then
+ cp ${ISODIR}/initrd ${EFIIMGDIR}
+ fi
}
grubefi_hddimg_populate() {
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [v3 PATCH 2/9] cdrtools-native: Update from 3.00 to 3.01a17
The update is needed to support generation of EFI boot images that
work with optical media. Specifically the -eltorito-platform efi
capability for mkisofs is needed.
[YOCTO #4100]
Signed-off-by: Jason Wessel jason.wes...@windriver.com
Reviewed-by: Darren Hart dvh...@linux.intel.com
---
...s-native_3.00.bb = cdrtools-native_3.01a17.bb} | 22 +++-
1 file changed, 8 insertions(+), 14 deletions(-)
rename meta/recipes-devtools/cdrtools/{cdrtools-native_3.00.bb =
cdrtools-native_3.01a17.bb} (47%)
diff --git a/meta/recipes-devtools/cdrtools/cdrtools-native_3.00.bb
b/meta/recipes-devtools/cdrtools/cdrtools-native_3.01a17.bb
similarity index 47%
rename from meta/recipes-devtools/cdrtools/cdrtools-native_3.00.bb
rename to meta/recipes-devtools/cdrtools/cdrtools-native_3.01a17.bb
index 7e4c381..2ae3f4a 100644
--- a/meta/recipes-devtools/cdrtools/cdrtools-native_3.00.bb
+++ b/meta/recipes-devtools/cdrtools/cdrtools-native_3.01a17.bb
@@ -5,26 +5,20 @@ SUMMARY = A set of tools for CD recording, including
cdrecord
DESCRIPTION = A set of tools for CD recording, including cdrecord
HOMEPAGE = http://cdrecord.berlios.de/private/cdrecord.html;
SECTION = console/utils
-LICENSE = GPLv2
-LIC_FILES_CHKSUM = file://COPYING;md5=8d16123ffd39e649a5e4a6bc1de60e6d
-PR = r0
+LICENSE = GPLv2 CDDL-1.0 LGPLv2.1+
+LIC_FILES_CHKSUM = file://COPYING;md5=32f68170be424c2cd64804337726b312
-SRC_URI = ftp://ftp.berlios.de/pub/cdrecord/cdrtools-${PV}.tar.bz2 \
- file://no_usr_src.patch
+SRC_URI = ftp://ftp.berlios.de/pub/cdrecord/alpha/cdrtools-${PV}.tar.bz2;
-SRC_URI[md5sum] = f9fbab08fbd458b0d2312976d8c5f558
-SRC_URI[sha256sum] =
7f9cb64820055573b880f77b2f16662a512518336ba95ab49228a1617973423d
+SRC_URI[md5sum] = 4cef9db0cf15a770c52d65b00bbee2db
+SRC_URI[sha256sum] =
3d613965b213ad83e4be0ba2535e784901839ea4d11a20a2beb6765f0eb76dfa
-inherit native
+S = ${WORKDIR}/cdrtools-3.01
-STAGE_TEMP = ${WORKDIR}/image-temp
+inherit native
FILESPATH = ${FILE_DIRNAME}/cdrtools-native/
do_install() {
- install -d ${STAGE_TEMP}
- make install INS_BASE=${STAGE_TEMP}
-
- install -d ${D}${bindir}/
- install ${STAGE_TEMP}/bin/* ${D}${bindir}/
+ make install GMAKE_NOWARN=true INS_BASE=${prefix} DESTDIR=${D}
}
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [v3 PATCH 3/9] grub-efi-native: Add support for EFI ISO images
The iso9660 file system support needs to be added to grub in order to
be able to correctly find the grub.cfg. The grub commands to locate
the grub.cfg also needs to be encoded into grub's default
configuration.
This change allows the resulting grub binary to work both in the hard
drive / USB boot case or the optical media boot case.
[YOCTO #4100]
Signed-off-by: Jason Wessel jason.wes...@windriver.com
Reviewed-by: Darren Hart dvh...@linux.intel.com
---
meta/recipes-bsp/grub/files/cfg |2 ++
meta/recipes-bsp/grub/grub-efi-native_2.00.bb |7 +--
2 files changed, 7 insertions(+), 2 deletions(-)
create mode 100644 meta/recipes-bsp/grub/files/cfg
diff --git a/meta/recipes-bsp/grub/files/cfg b/meta/recipes-bsp/grub/files/cfg
new file mode 100644
index 000..e47
--- /dev/null
+++ b/meta/recipes-bsp/grub/files/cfg
@@ -0,0 +1,2 @@
+search.file /EFI/BOOT/grub.cfg root
+set prefix=($root)/EFI/BOOT
diff --git a/meta/recipes-bsp/grub/grub-efi-native_2.00.bb
b/meta/recipes-bsp/grub/grub-efi-native_2.00.bb
index 2d3d68a..04973b5 100644
--- a/meta/recipes-bsp/grub/grub-efi-native_2.00.bb
+++ b/meta/recipes-bsp/grub/grub-efi-native_2.00.bb
@@ -23,6 +23,7 @@ PR = r2
PN := grub-efi-${TRANSLATED_TARGET_ARCH}-native
SRC_URI = ftp://ftp.gnu.org/gnu/grub/grub-${PV}.tar.gz \
+ file://cfg \
file://grub-2.00-fpmath-sse-387-fix.patch \
file://grub-2.00-fix-enable_execute_stack-check.patch \
file://grub-2.00-disable-help2man.patch \
@@ -66,9 +67,11 @@ EXTRA_OECONF = --with-platform=efi --disable-grub-mkfont \
--enable-liblzma=no --enable-device-mapper=no
--enable-libzfs=no
do_mkimage() {
- ./grub-mkimage -p /EFI/BOOT -d ./grub-core/ \
+ # Search for the grub.cfg on the local boot media by using the
+ # built in cfg file provided via this recipe
+ ./grub-mkimage -c ../cfg -p /EFI/BOOT -d ./grub-core/ \
-O ${GRUB_TARGET}-efi -o ./${GRUB_IMAGE} \
- boot linux ext2 fat serial part_msdos part_gpt normal
efi_gop
+ boot linux ext2 fat serial part_msdos part_gpt normal
efi_gop iso9660 search
}
addtask mkimage after do_compile before do_install
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [v3 PATCH 9/9] bootimage.bbclass, zisofs-tools-native: add ability to compress ISO images
The mkzftree is needed to allow ISO images to be compressed with
minimal runtime overhead. Below is an example of the savings on a
core-image-minimal.
Before ls -l:
24117248 core-image-minimal-qemux86-64.iso
Using the mkzftree ls -l:
16777216 core-image-minimal-qemux86-64.iso
Signed-off-by: Jason Wessel jason.wes...@windriver.com
Reviewed-by: Darren Hart dvh...@linux.intel.com
---
meta/classes/bootimg.bbclass | 24 +---
.../zisofs-tools/zisofs-tools-native_1.0.8.bb | 19
2 files changed, 40 insertions(+), 3 deletions(-)
create mode 100644
meta/recipes-devtools/zisofs-tools/zisofs-tools-native_1.0.8.bb
diff --git a/meta/classes/bootimg.bbclass b/meta/classes/bootimg.bbclass
index ede6e21..395085d 100644
--- a/meta/classes/bootimg.bbclass
+++ b/meta/classes/bootimg.bbclass
@@ -19,13 +19,15 @@
# External variables (also used by syslinux.bbclass)
# ${INITRD} - indicates a filesystem image to use as an initrd (optional)
+# ${COMPRESSISO} - Transparent compress ISO, reduce size ~40% if set to 1
# ${NOISO} - skip building the ISO image if set to 1
# ${NOHDD} - skip building the HDD image if set to 1
# ${ROOTFS} - indicates a filesystem image to include as the root filesystem
(optional)
do_bootimg[depends] += dosfstools-native:do_populate_sysroot \
mtools-native:do_populate_sysroot \
-cdrtools-native:do_populate_sysroot
+cdrtools-native:do_populate_sysroot \
+
${@oe.utils.ifelse(d.getVar('COMPRESSISO'),'zisofs-tools-native:do_populate_sysroot','')}
PACKAGES =
EXCLUDE_FROM_WORLD = 1
@@ -33,6 +35,8 @@ EXCLUDE_FROM_WORLD = 1
HDDDIR = ${S}/hddimg
ISODIR = ${S}/iso
EFIIMGDIR = ${S}/efi_img
+COMPACT_ISODIR = ${S}/iso.z
+COMPRESSISO ?= 0
BOOTIMG_VOLUME_ID ?= boot
BOOTIMG_EXTRA_SPACE ?= 512
@@ -97,18 +101,32 @@ build_iso() {
install -m 0644 ${STAGING_DATADIR}/syslinux/isolinux.bin
${ISODIR}${ISOLINUXDIR}
fi
+ if [ ${COMPRESSISO} = 1 ] ; then
+ # create compact directory, compress iso
+ mkdir -p ${COMPACT_ISODIR}
+ mkzftree -z 9 -p 4 -F ${ISODIR}/rootfs.img
${COMPACT_ISODIR}/rootfs.img
+
+ # move compact iso to iso, then remove compact directory
+ mv ${COMPACT_ISODIR}/rootfs.img ${ISODIR}/rootfs.img
+ rm -Rf ${COMPACT_ISODIR}
+ mkisofs_compress_opts=-R -z -D -l
+ else
+ mkisofs_compress_opts=-r
+ fi
+
if [ ${PCBIOS} = 1 ] [ ${EFI} != 1 ] ; then
# PCBIOS only media
mkisofs -V ${BOOTIMG_VOLUME_ID} \
-o ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.iso \
- -b ${ISO_BOOTIMG} -c ${ISO_BOOTCAT} -r \
+ -b ${ISO_BOOTIMG} -c ${ISO_BOOTCAT} \
+ $mkisofs_compress_opts \
${MKISOFS_OPTIONS} ${ISODIR}
else
# EFI only OR EFI+PCBIOS
mkisofs -A ${BOOTIMG_VOLUME_ID} -V ${BOOTIMG_VOLUME_ID} \
-o ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.iso \
-b ${ISO_BOOTIMG} -c ${ISO_BOOTCAT} \
- -r ${MKISOFS_OPTIONS} \
+ $mkisofs_compress_opts ${MKISOFS_OPTIONS} \
-eltorito-alt-boot -eltorito-platform efi \
-b efi.img -no-emul-boot \
${ISODIR}
diff --git a/meta/recipes-devtools/zisofs-tools/zisofs-tools-native_1.0.8.bb
b/meta/recipes-devtools/zisofs-tools/zisofs-tools-native_1.0.8.bb
new file mode 100644
index 000..1501307
--- /dev/null
+++ b/meta/recipes-devtools/zisofs-tools/zisofs-tools-native_1.0.8.bb
@@ -0,0 +1,19 @@
+# zisofs-tools-native OE build file
+# Copyright (C) 1989, 1991 Free Software Foundation, Inc.
+SUMMARY = A set of tools for iso file compression
+DESCRIPTION = A set of tools for iso file compression
+HOMEPAGE = http://http://freecode.com/projects/zisofs-tools;
+SECTION = console/utils
+LICENSE = GPLv2
+LIC_FILES_CHKSUM = file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f
+
+SRC_URI =
http://pkgs.fedoraproject.org/repo/pkgs/zisofs-tools/zisofs-tools-${PV}.tar.bz2/2d0ed8c9a1f60b45f949b136f9be1f6c/zisofs-tools-${PV}.tar.bz2;
+
+SRC_URI[md5sum] = 2d0ed8c9a1f60b45f949b136f9be1f6c
+SRC_URI[sha256sum] =
ae4e53e4914934d41660248fb59d3c8761f1f1fd180d5ec993c17ddb3afd04f3
+
+inherit native
+
+do_install() {
+ oe_runmake install INSTALLROOT=${D} bindir=${bindir}
+}
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [v3 PATCH 8/9] boot-directdisk.bbclass: Fix media generation problems with vmdk
The various populate methods need to accept a path as an argument vs
using hard expanded variables. In the case of the boot-directdisk
class it uses a different path for HDDDIR but it gets eclipsed by the
the class definition at the point in time ${HDDDIR} gets expanded.
The logical fix is to pass the arguments to the functions as opposed
to using globally expanded variables from the class definitions.
This patch changes 3 things:
1) syslinux_hddimg_populate takes an argument for the destination
2) syslinux_iso_populate takes an argument for the destination
3) populate is changed to boot_direct_populate because there
was a conflict with it overriding the populate in bootimg.bbclass
[YOCTO #3994]
Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
meta/classes/boot-directdisk.bbclass | 16
meta/classes/bootimg.bbclass |8
meta/classes/grub-efi.bbclass| 13 +++--
meta/classes/syslinux.bbclass| 12 +++-
4 files changed, 26 insertions(+), 23 deletions(-)
diff --git a/meta/classes/boot-directdisk.bbclass
b/meta/classes/boot-directdisk.bbclass
index 4b9d7bd..c58c6f0 100644
--- a/meta/classes/boot-directdisk.bbclass
+++ b/meta/classes/boot-directdisk.bbclass
@@ -61,15 +61,15 @@ DISK_SIGNATURE ?= ${DISK_SIGNATURE_GENERATED}
SYSLINUX_ROOT ?= root=/dev/sda2
SYSLINUX_TIMEOUT ?= 10
-populate() {
- DEST=$1
- install -d ${DEST}
+boot_direct_populate() {
+ dest=$1
+ install -d $dest
# Install bzImage, initrd, and rootfs.img in DEST for all loaders to
use.
- install -m 0644 ${STAGING_KERNEL_DIR}/bzImage ${DEST}/vmlinuz
+ install -m 0644 ${STAGING_KERNEL_DIR}/bzImage $dest/vmlinuz
if [ -n ${INITRD} ] [ -s ${INITRD} ]; then
- install -m 0644 ${INITRD} ${DEST}/initrd
+ install -m 0644 ${INITRD} $dest/initrd
fi
}
@@ -79,13 +79,13 @@ build_boot_dd() {
HDDIMG=${S}/hdd.image
IMAGE=${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.hdddirect
- populate ${HDDDIR}
+ boot_direct_populate $HDDDIR
if [ ${PCBIOS} = 1 ]; then
- syslinux_hddimg_populate
+ syslinux_hddimg_populate $HDDDIR
fi
if [ ${EFI} = 1 ]; then
- grubefi_hddimg_populate
+ grubefi_hddimg_populate $HDDDIR
fi
BLOCKS=`du -bks $HDDDIR | cut -f 1`
diff --git a/meta/classes/bootimg.bbclass b/meta/classes/bootimg.bbclass
index fdd4ea9..ede6e21 100644
--- a/meta/classes/bootimg.bbclass
+++ b/meta/classes/bootimg.bbclass
@@ -82,10 +82,10 @@ build_iso() {
populate ${ISODIR}
if [ ${PCBIOS} = 1 ]; then
- syslinux_iso_populate
+ syslinux_iso_populate ${ISODIR}
fi
if [ ${EFI} = 1 ]; then
- grubefi_iso_populate
+ grubefi_iso_populate ${ISODIR}
build_fat_img ${EFIIMGDIR} ${ISODIR}/efi.img
fi
@@ -185,10 +185,10 @@ build_hddimg() {
populate ${HDDDIR}
if [ ${PCBIOS} = 1 ]; then
- syslinux_hddimg_populate
+ syslinux_hddimg_populate ${HDDDIR}
fi
if [ ${EFI} = 1 ]; then
- grubefi_hddimg_populate
+ grubefi_hddimg_populate ${HDDDIR}
fi
build_fat_img ${HDDDIR} ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.hddimg
diff --git a/meta/classes/grub-efi.bbclass b/meta/classes/grub-efi.bbclass
index ffbcf4c..cd6651e 100644
--- a/meta/classes/grub-efi.bbclass
+++ b/meta/classes/grub-efi.bbclass
@@ -42,19 +42,20 @@ grubefi_populate() {
}
grubefi_iso_populate() {
- grubefi_populate ${ISODIR}
+ iso_dir=$1
+ grubefi_populate $iso_dir
# Build a EFI directory to create efi.img
mkdir -p ${EFIIMGDIR}/${EFIDIR}
- cp ${ISODIR}/${EFIDIR}/* ${EFIIMGDIR}${EFIDIR}
- cp ${ISODIR}/vmlinuz ${EFIIMGDIR}
+ cp $iso_dir/${EFIDIR}/* ${EFIIMGDIR}${EFIDIR}
+ cp $iso_dir/vmlinuz ${EFIIMGDIR}
echo EFI\\BOOT\\${GRUB_IMAGE} ${EFIIMGDIR}/startup.nsh
- if [ -f ${ISODIR}/initrd ] ; then
- cp ${ISODIR}/initrd ${EFIIMGDIR}
+ if [ -f $iso_dir/initrd ] ; then
+ cp $iso_dir/initrd ${EFIIMGDIR}
fi
}
grubefi_hddimg_populate() {
- grubefi_populate ${HDDDIR}
+ grubefi_populate $1
}
python build_grub_cfg() {
diff --git a/meta/classes/syslinux.bbclass b/meta/classes/syslinux.bbclass
index 91b9731..944bd92 100644
--- a/meta/classes/syslinux.bbclass
+++ b/meta/classes/syslinux.bbclass
@@ -53,14 +53,16 @@ syslinux_populate() {
}
syslinux_iso_populate() {
- syslinux_populate ${ISODIR} ${ISOLINUXDIR} isolinux.cfg
- install -m 0644 ${STAGING_DATADIR}/syslinux/isolinux.bin
${ISODIR}${ISOLINUXDIR}
- install -m 0644 ${STAGING_DATADIR}/syslinux/ldlinux.c32
${ISODIR}${ISOLINUXDIR}
+ iso_dir=$1
Re: [OE-core] [v2 PATCH 4/7] syslinux.bbclass, syslinux: Update to syslinux 6.01
On 09/14/2013 03:05 AM, Martin Jansa wrote: On Fri, Sep 13, 2013 at 07:09:00PM -0500, Jason Wessel wrote: A newer version of syslinux is required for an EFI enabled isohybrid. This is used for the the capability to generate 3 types of ISO images, all of which can be booted off a USB device or HDD if copied with dd. 1) PC BIOS only ISO 2) EFI only ISO 3) EFI + PC BIOS ISO The syslinux.bbclass required a minor tweak because ldlinux.c32 is dynamically loaded and needs to be in the created media as of syslinux 5 and up. Hi Jason, can you please look at https://bugzilla.yoctoproject.org/show_bug.cgi?id=3944 ? I can look at fixing the defect, but there is no description of how to use the directdisk to see the problem. Could you provide an example? I added the directdisk to IMAGE_FSTYPES, but didn't get a .directdisk in the deploy directory so that is not how it works. Also I think the right solution is to simply call syslinux_hddimg_populate() from the directdisk class vs having copied code for the install of the syslinux specific files (that is how 1/2 the problem occurred in the first place). Back to this particular patch, the ldlinux.c32 change does not affect the bootdirect class. The ldlinux.c32 is only required for isolinux and the copy is contained with in the inherited syslinux class. Cheers, Jason. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 5/5] grub-efi.bbclass: Add serial and graphics menu options
On 09/12/2013 03:09 PM, Darren Hart wrote:
On Thu, 2013-09-12 at 14:52 -0500, Jason Wessel wrote:
On 09/12/2013 01:16 PM, Darren Hart wrote:
On Thu, 2013-09-12 at 12:19 -0500, Jason Wessel wrote:
The syslinux.bbclass already has support for automatically generated
serial and graphics menu choices. This patch adds the same concept to
the grub-efi menu. That makes it possible to generate a single image
which can boot on a PCBIOS or EFI firmware with consistent looking
boot options.
[YOCTO #4100]
Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
meta/classes/grub-efi.bbclass | 41
-
meta/conf/machine/qemux86-64.conf |2 +-
meta/conf/machine/qemux86.conf|2 ++
3 files changed, 30 insertions(+), 15 deletions(-)
diff --git a/meta/classes/grub-efi.bbclass b/meta/classes/grub-efi.bbclass
index c6f5d4e..c07e4a1 100644
--- a/meta/classes/grub-efi.bbclass
+++ b/meta/classes/grub-efi.bbclass
@@ -9,6 +9,7 @@
# External variables
# ${INITRD} - indicates a filesystem image to use as an initrd (optional)
# ${ROOTFS} - indicates a filesystem image to include as the root
filesystem (optional)
+# ${GRUB_GFXSERIAL} - set this to 1 to have graphics and serial in the
boot menu
# ${LABELS} - a list of targets for the automatic config
# ${APPEND} - an override list of append strings for each label
# ${GRUB_OPTS} - additional options to add to the config, ';' delimited #
(optional)
@@ -16,6 +17,7 @@
do_bootimg[depends] +=
grub-efi-${TRANSLATED_TARGET_ARCH}-native:do_deploy
+GRUB_SERIAL ?= console=ttyS0,115200
...
I'm not very familiar with the cfgfile for menus and such, so I don't
have much to add. The one thing that catches me by surprise is the need
for the serial device. On EFI systems, grub here uses the EFI console
service, so if that uses the serial port you get it for free, no need
for GRUB to try and use it directly. In fact does the above not
cause some kind of conflict between the EFI console service and grub
serial?
In part that is why it is optional. With respect to the serial bits,
these are only the kernel boot arguments we are talking about. It
Hrm this should be handled with APPEND parameter from the machine
configs, not a new GRUB_SERIAL statement
Well there is a problem with that. You only have 1 APPEND, but I need 2
options. The whole point is the ability to add SERIAL or Graphics console
access for early boot all the way through user space hand off and seamlessly
picking things up later in user space with mingetty etc...
This option is mainly used for the installer media and to provide a consistent
look and feel regardless if you come from EFI or a PCIBIOS + syslinux.
doesn't seem that there is a primary display interface for the HCDP
in the EFI firmware I have. Additionally, the kernel throws the EFI
serial console under the bus at ACPI probe time, while this certainly
could also be a bug in the firmware I have on my test board, the only
way to keep the serial port alive for a login and the kernel boot
information was to specify console=ttyS0...
Hrm interesting. I guess we'll just need to test more broadly.
Indeed the kernel should be using it's own console= parameter, but
again, that should come from the APPEND_machine variable.
I have yet another system I need to try this on which has a much newer
UEFI and a serial port, but I thought it would be best to get
something out there that covers the buggy firmwares as well which
can be built optionally.
Agreed, so long as it doesn't break the common case.
The common case is not broken. This is something you have to turn on in the
image or local.conf.
The new patches will available soon for the whole series as soon as all the
test hardware has booted in legacy and efi mode.
Cheers,
Jason.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [v2 PATCH 1/7] bootimage.bbclass: Move fat image creation into a function
In order to call the fat image creation multiple times it needs to be
in its own function. A future commit will make use of the new
function to additionally create EFI image files for use with an ISO.
[YOCTO #4100]
[YOCTO #1913]
Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
meta/classes/bootimg.bbclass | 110 ++
1 file changed, 58 insertions(+), 52 deletions(-)
diff --git a/meta/classes/bootimg.bbclass b/meta/classes/bootimg.bbclass
index 90a241d..bd211fb 100644
--- a/meta/classes/bootimg.bbclass
+++ b/meta/classes/bootimg.bbclass
@@ -111,6 +111,63 @@ build_iso() {
ln -s ${IMAGE_NAME}.iso ${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.iso
}
+build_fat_img() {
+ FATSOURCEDIR=$1
+ FATIMG=$2
+
+ # Calculate the size required for the final image including the
+ # data and filesystem overhead.
+ # Sectors: 512 bytes
+ # Blocks: 1024 bytes
+
+ # Determine the sector count just for the data
+ SECTORS=$(expr $(du --apparent-size -ks ${FATSOURCEDIR} | cut -f 1) \*
2)
+
+ # Account for the filesystem overhead. This includes directory
+ # entries in the clusters as well as the FAT itself.
+ # Assumptions:
+ # FAT32 (12 or 16 may be selected by mkdosfs, but the extra
+ # padding will be minimal on those smaller images and not
+ # worth the logic here to caclulate the smaller FAT sizes)
+ #16 entries per directory
+ # 8.3 filenames only
+
+ # 32 bytes per dir entry
+ DIR_BYTES=$(expr $(find ${FATSOURCEDIR} | tail -n +2 | wc -l) \* 32)
+ # 32 bytes for every end-of-directory dir entry
+ DIR_BYTES=$(expr $DIR_BYTES + $(expr $(find ${FATSOURCEDIR} -type d |
tail -n +2 | wc -l) \* 32))
+ # 4 bytes per FAT entry per sector of data
+ FAT_BYTES=$(expr $SECTORS \* 4)
+ # 4 bytes per FAT entry per end-of-cluster list
+ FAT_BYTES=$(expr $FAT_BYTES + $(expr $(find ${FATSOURCEDIR} -type d |
tail -n +2 | wc -l) \* 4))
+
+ # Use a ceiling function to determine FS overhead in sectors
+ DIR_SECTORS=$(expr $(expr $DIR_BYTES + 511) / 512)
+ # There are two FATs on the image
+ FAT_SECTORS=$(expr $(expr $(expr $FAT_BYTES + 511) / 512) \* 2)
+ SECTORS=$(expr $SECTORS + $(expr $DIR_SECTORS + $FAT_SECTORS))
+
+ # Determine the final size in blocks accounting for some padding
+ BLOCKS=$(expr $(expr $SECTORS / 2) + ${BOOTIMG_EXTRA_SPACE})
+
+ # Ensure total sectors is an integral number of sectors per
+ # track or mcopy will complain. Sectors are 512 bytes, and we
+ # generate images with 32 sectors per track. This calculation is
+ # done in blocks, thus the mod by 16 instead of 32.
+ BLOCKS=$(expr $BLOCKS + $(expr 16 - $(expr $BLOCKS % 16)))
+
+ # mkdosfs will sometimes use FAT16 when it is not appropriate,
+ # resulting in a boot failure from SYSLINUX. Use FAT32 for
+ # images larger than 512MB, otherwise let mkdosfs decide.
+ if [ $(expr $BLOCKS / 1024) -gt 512 ]; then
+ FATSIZE=-F 32
+ fi
+
+ mkdosfs ${FATSIZE} -n ${BOOTIMG_VOLUME_ID} -S 512 -C ${FATIMG} ${BLOCKS}
+ # Copy FATSOURCEDIR recursively into the image file directly
+ mcopy -i ${FATIMG} -s ${FATSOURCEDIR}/* ::/
+}
+
build_hddimg() {
# Create an HDD image
if [ ${NOHDD} != 1 ] ; then
@@ -123,58 +180,7 @@ build_hddimg() {
grubefi_hddimg_populate
fi
- # Calculate the size required for the final image including the
- # data and filesystem overhead.
- # Sectors: 512 bytes
- # Blocks: 1024 bytes
-
- # Determine the sector count just for the data
- SECTORS=$(expr $(du --apparent-size -ks ${HDDDIR} | cut -f 1)
\* 2)
-
- # Account for the filesystem overhead. This includes directory
- # entries in the clusters as well as the FAT itself.
- # Assumptions:
- # FAT32 (12 or 16 may be selected by mkdosfs, but the extra
- # padding will be minimal on those smaller images and not
- # worth the logic here to caclulate the smaller FAT sizes)
- #16 entries per directory
- # 8.3 filenames only
-
- # 32 bytes per dir entry
- DIR_BYTES=$(expr $(find ${HDDDIR} | tail -n +2 | wc -l) \* 32)
- # 32 bytes for every end-of-directory dir entry
- DIR_BYTES=$(expr $DIR_BYTES + $(expr $(find ${HDDDIR} -type d |
tail -n +2 | wc -l) \* 32))
- # 4 bytes per FAT entry per sector of data
- FAT_BYTES=$(expr $SECTORS \* 4)
- # 4 bytes per FAT entry per end-of-cluster list
- FAT_BYTES=$(expr $FAT_BYTES + $(expr $(find ${HDDDIR} -type d |
tail -n +2 | wc -l) \* 4))
-
- # Use
[OE-core] [v2 PATCH 2/7] cdrtools-native: Update from 3.00 to 3.01a17
The update is needed to support generation of EFI boot images that
work with optical media. Specifically the -eltorito-platform efi
capability for mkisofs is needed.
[YOCTO #4100]
Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
...s-native_3.00.bb = cdrtools-native_3.01a17.bb} | 22 +++-
1 file changed, 8 insertions(+), 14 deletions(-)
rename meta/recipes-devtools/cdrtools/{cdrtools-native_3.00.bb =
cdrtools-native_3.01a17.bb} (47%)
diff --git a/meta/recipes-devtools/cdrtools/cdrtools-native_3.00.bb
b/meta/recipes-devtools/cdrtools/cdrtools-native_3.01a17.bb
similarity index 47%
rename from meta/recipes-devtools/cdrtools/cdrtools-native_3.00.bb
rename to meta/recipes-devtools/cdrtools/cdrtools-native_3.01a17.bb
index 7e4c381..2ae3f4a 100644
--- a/meta/recipes-devtools/cdrtools/cdrtools-native_3.00.bb
+++ b/meta/recipes-devtools/cdrtools/cdrtools-native_3.01a17.bb
@@ -5,26 +5,20 @@ SUMMARY = A set of tools for CD recording, including
cdrecord
DESCRIPTION = A set of tools for CD recording, including cdrecord
HOMEPAGE = http://cdrecord.berlios.de/private/cdrecord.html;
SECTION = console/utils
-LICENSE = GPLv2
-LIC_FILES_CHKSUM = file://COPYING;md5=8d16123ffd39e649a5e4a6bc1de60e6d
-PR = r0
+LICENSE = GPLv2 CDDL-1.0 LGPLv2.1+
+LIC_FILES_CHKSUM = file://COPYING;md5=32f68170be424c2cd64804337726b312
-SRC_URI = ftp://ftp.berlios.de/pub/cdrecord/cdrtools-${PV}.tar.bz2 \
- file://no_usr_src.patch
+SRC_URI = ftp://ftp.berlios.de/pub/cdrecord/alpha/cdrtools-${PV}.tar.bz2;
-SRC_URI[md5sum] = f9fbab08fbd458b0d2312976d8c5f558
-SRC_URI[sha256sum] =
7f9cb64820055573b880f77b2f16662a512518336ba95ab49228a1617973423d
+SRC_URI[md5sum] = 4cef9db0cf15a770c52d65b00bbee2db
+SRC_URI[sha256sum] =
3d613965b213ad83e4be0ba2535e784901839ea4d11a20a2beb6765f0eb76dfa
-inherit native
+S = ${WORKDIR}/cdrtools-3.01
-STAGE_TEMP = ${WORKDIR}/image-temp
+inherit native
FILESPATH = ${FILE_DIRNAME}/cdrtools-native/
do_install() {
- install -d ${STAGE_TEMP}
- make install INS_BASE=${STAGE_TEMP}
-
- install -d ${D}${bindir}/
- install ${STAGE_TEMP}/bin/* ${D}${bindir}/
+ make install GMAKE_NOWARN=true INS_BASE=${prefix} DESTDIR=${D}
}
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [v2 PATCH 4/7] syslinux.bbclass, syslinux: Update to syslinux 6.01
A newer version of syslinux is required for an EFI enabled isohybrid.
This is used for the the capability to generate 3 types of ISO images,
all of which can be booted off a USB device or HDD if copied with dd.
1) PC BIOS only ISO
2) EFI only ISO
3) EFI + PC BIOS ISO
The syslinux.bbclass required a minor tweak because ldlinux.c32 is
dynamically loaded and needs to be in the created media as of syslinux
5 and up.
[YOCTO #4100]
Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
meta/classes/syslinux.bbclass |1 +
.../{syslinux_4.07.bb = syslinux_6.01.bb} | 26
2 files changed, 17 insertions(+), 10 deletions(-)
rename meta/recipes-devtools/syslinux/{syslinux_4.07.bb = syslinux_6.01.bb}
(63%)
diff --git a/meta/classes/syslinux.bbclass b/meta/classes/syslinux.bbclass
index 501bc6d..da7f716 100644
--- a/meta/classes/syslinux.bbclass
+++ b/meta/classes/syslinux.bbclass
@@ -41,6 +41,7 @@ syslinux_populate() {
syslinux_iso_populate() {
syslinux_populate ${ISODIR} ${ISOLINUXDIR} isolinux.cfg
install -m 0644 ${STAGING_DATADIR}/syslinux/isolinux.bin
${ISODIR}${ISOLINUXDIR}
+ install -m 0644 ${STAGING_DATADIR}/syslinux/ldlinux.c32
${ISODIR}${ISOLINUXDIR}
if [ ${AUTO_SYSLINUXMENU} = 1 ] ; then
install -m 0644 ${STAGING_DATADIR}/syslinux/vesamenu.c32
${ISODIR}${ISOLINUXDIR}/vesamenu.c32
if [ ${SYSLINUX_SPLASH} != ] ; then
diff --git a/meta/recipes-devtools/syslinux/syslinux_4.07.bb
b/meta/recipes-devtools/syslinux/syslinux_6.01.bb
similarity index 63%
rename from meta/recipes-devtools/syslinux/syslinux_4.07.bb
rename to meta/recipes-devtools/syslinux/syslinux_6.01.bb
index bba5dda..4438ea8 100644
--- a/meta/recipes-devtools/syslinux/syslinux_4.07.bb
+++ b/meta/recipes-devtools/syslinux/syslinux_6.01.bb
@@ -2,19 +2,21 @@ DESCRIPTION = A multi-purpose linux bootloader
HOMEPAGE = http://syslinux.zytor.com/;
LICENSE = GPLv2+
LIC_FILES_CHKSUM = file://COPYING;md5=0636e73ff0215e8d672dc4c32c317bb3 \
-
file://README;beginline=35;endline=41;md5=f7249a750bc692d1048b2626752aa415
+
file://README;beginline=35;endline=41;md5=558f2c71cb1fb9ba511ccd4858e48e8a
# If you really want to run syslinux, you need mtools. We just want the
# ldlinux.* stuff for now, so skip mtools-native
DEPENDS = nasm-native util-linux
-PR = r0
-SRC_URI =
${KERNELORG_MIRROR}/linux/utils/boot/syslinux/4.xx/syslinux-${PV}.tar.bz2
+SRC_URI =
${KERNELORG_MIRROR}/linux/utils/boot/syslinux/6.xx/syslinux-${PV}.tar.bz2
-SRC_URI[md5sum] = 9ff6e1b94efab931fb4717b600d88779
-SRC_URI[sha256sum] =
1240a4e4219b518bdaef78931b6e901befeff35e6894ac6db785115848a7a05a
+SRC_URI[md5sum] = 6945ee89e29119d459baed4937bbc534
+SRC_URI[sha256sum] =
83a04cf81e6a46b80ee5a321926eea095af3498b04317e3674b46c125c7a5b43
COMPATIBLE_HOST = '(x86_64|i.86).*-(linux|freebsd.*)'
+# Don't let the sanity checker trip on the 32 bit real mode BIOS binaries
+INSANE_SKIP_${PN}-misc = arch
+INSANE_SKIP_${PN}-chain = arch
EXTRA_OEMAKE = \
BINDIR=${bindir} SBINDIR=${sbindir} LIBDIR=${libdir} \
@@ -28,21 +30,25 @@ do_configure() {
sed -e 's,win32/\S*,,g' -i Makefile
# clean installer executables included in source tarball
- oe_runmake clean
+ oe_runmake clean firmware=efi32 EFIINC=${includedir}
+ # NOTE: There is a temporary work around above to specify
+ # the efi32 as the firmware else the pre-built bios
+ # files get erased contrary to the doc/distib.txt
+ # In the future this should be bios and not efi32.
}
do_compile() {
# Rebuild only the installer; keep precompiled bootloaders
# as per author's request (doc/distrib.txt)
- oe_runmake CC=${CC} ${CFLAGS} LDFLAGS=${LDFLAGS} installer
+ oe_runmake CC=${CC} ${CFLAGS} LDFLAGS=${LDFLAGS} firmware=bios
installer
}
do_install() {
- oe_runmake install INSTALLROOT=${D}
+ oe_runmake install INSTALLROOT=${D} firmware=bios
install -d ${D}${datadir}/syslinux/
- install -m 644 ${S}/core/ldlinux.sys ${D}${datadir}/syslinux/
- install -m 644 ${S}/core/ldlinux.bss ${D}${datadir}/syslinux/
+ install -m 644 ${S}/bios/core/ldlinux.sys ${D}${datadir}/syslinux/
+ install -m 644 ${S}/bios/core/ldlinux.bss ${D}${datadir}/syslinux/
}
PACKAGES += ${PN}-extlinux ${PN}-mbr ${PN}-chain ${PN}-pxelinux
${PN}-isolinux ${PN}-misc
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [v2 PATCH 5/7] bootimage.bbclass, grub-efi.bbclass: Improve EFI PCBIOS+EFI ISO support
Using the latest mkisofs it is possible to generate 3 different types
of ISO images, which can be used in various scenarios.
1) PCBIOS Only ISO
- This option remains unchanged by this commit
- Uses syslinux menus
- Can be directly copied with dd to a USB device
- Can be burned to optical media
2) EFI Only ISO
- Uses grub 2 menus
- Can be burned to optical media
- If you want to use this image on a USB device
extra steps must be taken in order to format the USB
device with fat32, and copy an EFI loader which will
in turn load the iso image
3) PCBIOS / EFI ISO
- This is a hybrid image ISO that will work for case 1 or 2
as above with the same restrictions and boot menu types
depending on what type of firmware is installed on
the hardware or depending on if EFI or Legacy Boot is
enabled on some UEFI firmwares.
The syslinux.bbclass is now always required because that is where the
isohybrid dependencies come from as well as the configuration data for
the isohybrid. The isohybrid is the secret sauce which allows the ISO
to work as optical media or as a disk image on USB or a HDD/SSD.
[YOCTO #4100]
Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
meta/classes/bootimg.bbclass | 33 +
meta/classes/grub-efi.bbclass |8
2 files changed, 29 insertions(+), 12 deletions(-)
diff --git a/meta/classes/bootimg.bbclass b/meta/classes/bootimg.bbclass
index bd211fb..756a287 100644
--- a/meta/classes/bootimg.bbclass
+++ b/meta/classes/bootimg.bbclass
@@ -32,6 +32,7 @@ EXCLUDE_FROM_WORLD = 1
HDDDIR = ${S}/hddimg
ISODIR = ${S}/iso
+EFIIMGDIR = ${S}/efi_img
BOOTIMG_VOLUME_ID ?= boot
BOOTIMG_EXTRA_SPACE ?= 512
@@ -48,15 +49,10 @@ def pcbios(d):
pcbios = base_contains(MACHINE_FEATURES, efi, 0, 1, d)
return pcbios
-def pcbios_class(d):
-if d.getVar(PCBIOS, True) == 1:
-return syslinux
-return
-
PCBIOS = ${@pcbios(d)}
-PCBIOS_CLASS = ${@pcbios_class(d)}
-inherit ${PCBIOS_CLASS}
+# The syslinux is required for the isohybrid command and boot catalog
+inherit syslinux
inherit ${EFI_CLASS}
populate() {
@@ -90,21 +86,34 @@ build_iso() {
fi
if [ ${EFI} = 1 ]; then
grubefi_iso_populate
+ build_fat_img ${EFIIMGDIR} ${ISODIR}/efi.img
fi
- if [ ${PCBIOS} = 1 ]; then
+ # EFI only
+ if [ ${PCBIOS} != 1 ] [ ${EFI} = 1 ] ; then
+ mkdir -p ${ISODIR}/${ISOLINUXDIR}
+ install -m 0644 ${STAGING_DATADIR}/syslinux/isolinux.bin
${ISODIR}${ISOLINUXDIR}
+ fi
+
+ if [ ${PCBIOS} = 1 ] [ ${EFI} != 1 ] ; then
+ # PCBIOS only media
mkisofs -V ${BOOTIMG_VOLUME_ID} \
-o ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.iso \
-b ${ISO_BOOTIMG} -c ${ISO_BOOTCAT} -r \
${MKISOFS_OPTIONS} ${ISODIR}
else
- bbnote EFI-only ISO images are untested, please provide
feedback.
- mkisofs -V ${BOOTIMG_VOLUME_ID} \
+ # EFI only OR EFI+PCIBIOS
+ mkisofs -A ${BOOTIMG_VOLUME_ID} -V ${BOOTIMG_VOLUME_ID} \
-o ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.iso \
- -r ${ISODIR}
+ -b ${ISO_BOOTIMG} -c ${ISO_BOOTCAT} \
+ -r ${MKISOFS_OPTIONS} \
+ -eltorito-alt-boot -eltorito-platform efi \
+ -b efi.img -no-emul-boot \
+ ${ISODIR}
+ isohybrid_args=-u
fi
- isohybrid ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.iso
+ isohybrid $isohybrid_args ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.iso
cd ${DEPLOY_DIR_IMAGE}
rm -f ${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.iso
diff --git a/meta/classes/grub-efi.bbclass b/meta/classes/grub-efi.bbclass
index c6f5d4e..c21babb 100644
--- a/meta/classes/grub-efi.bbclass
+++ b/meta/classes/grub-efi.bbclass
@@ -41,6 +41,14 @@ grubefi_populate() {
grubefi_iso_populate() {
grubefi_populate ${ISODIR}
+ # Build a EFI directory to create efi.img
+ mkdir -p ${EFIIMGDIR}/${EFIDIR}
+ cp ${ISODIR}/${EFIDIR}/* ${EFIIMGDIR}${EFIDIR}
+ cp ${ISODIR}/vmlinuz ${EFIIMGDIR}
+ echo EFI\\BOOT\\${GRUB_IMAGE} ${EFIIMGDIR}/startup.nsh
+ if [ -f ${ISODIR}/initrd ] ; then
+ cp ${ISODIR}/initrd ${EFIIMGDIR}
+ fi
}
grubefi_hddimg_populate() {
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [v2 PATCH 0/7] Improved EFI boot support
V2
- Added reference to YOCTO #1913 for per Darren
- Remove PR number from cdrtools uprev
- Added Saul's change to cdrtools to get rid of STAGE_TEMP
- made the builtin grub cfg file copied from a SRC_URI
- upreved syslinux to 6.01
- Use the new isohybrid command from syslinux which can now
generate EFI enabled ISO's which can boot directly when
dd'ed to a USB or HDD device.
- Dropped any references to efi or pcbios in the qemu* configs
- Added the zisofs patch to the end of the series instead
of depending on it, in case it is dropped later.
- git -format-patch -M20% is your friend for seeing the
delta on recipe upgrades :-)
YAY, with the new version of syslinux it is now possible to
build a single live ISO image which can boot in legacy mode
or EFI on optical media or USB devices.
We still have to create 2 ISO's one for 32bit EFI systems and one for
64bit EFI systems but this is also true of all other Linux
distributions today as well.
Jason.
---
The goal of this patch set is to put the EFI ISO boot method on par
with the ISO PCBIOS boot method. This also allows for the creation of
a single ISO image which can boot in legacy boot mode or EFI boot
mode.
In order to make this possible the cdrtools needed an update to the
very latest and this brings in an license change. Given that change
it was not entirely clear to me if we needed to leave the older
package around. I opted to remove the older package recipe since
there was no clean way to fail in the case you wanted to build EFI
boot media.
The bbnote that was previously in the bootimg.bbclass about EFI only
media being untested was a bit of an understatement, as the images
would not even build without errors due to the call to isohybrid. I
removed any such warnings because that path has been fully vetted now.
Cheers,
Jason.
The following changes since commit b26157a8b575aa7b5c96ffe782fc23ec0920311c:
libnewt-python: Don't write a whiptail package (2013-09-12 08:23:35 +0100)
are available in the git repository at:
. master
for you to fetch changes up to a0d1b567277fdf370cc121720c0c4f30839da01b:
bootimage.bbclass, zisofs-tools-native: add ability to compress ISO images
(2013-09-13 19:05:37 -0500)
Jason Wessel (7):
bootimage.bbclass: Move fat image creation into a function
cdrtools-native: Update from 3.00 to 3.01a17
grub-efi-native: Add support for EFI ISO images
syslinux.bbclass,syslinux: Update to syslinux 6.01
bootimage.bbclass,grub-efi.bbclass: Improve EFI PCBIOS+EFI ISO support
grub-efi.bbclass: Add serial and graphics menu options
bootimage.bbclass, zisofs-tools-native: add ability to compress ISO images
meta/classes/bootimg.bbclass | 165
meta/classes/grub-efi.bbclass | 49 --
meta/classes/syslinux.bbclass |1 +
meta/recipes-bsp/grub/files/cfg|2 +
meta/recipes-bsp/grub/grub-efi-native_2.00.bb |7 +-
.../cdrtools/cdrtools-native_3.00.bb | 30
.../cdrtools/cdrtools-native_3.01a17.bb| 24 +++
.../{syslinux_4.07.bb = syslinux_6.01.bb} | 26 +--
.../zisofs-tools/zisofs-tools-native_1.0.8.bb | 19 +++
9 files changed, 201 insertions(+), 122 deletions(-)
create mode 100644 meta/recipes-bsp/grub/files/cfg
delete mode 100644 meta/recipes-devtools/cdrtools/cdrtools-native_3.00.bb
create mode 100644 meta/recipes-devtools/cdrtools/cdrtools-native_3.01a17.bb
rename meta/recipes-devtools/syslinux/{syslinux_4.07.bb = syslinux_6.01.bb}
(63%)
create mode 100644
meta/recipes-devtools/zisofs-tools/zisofs-tools-native_1.0.8.bb
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [v2 PATCH 7/7] bootimage.bbclass, zisofs-tools-native: add ability to compress ISO images
The mkzftree is needed to allow ISO images to be compressed with
minimal runtime overhead. Below is an example of the savings on a
core-image-minimal.
Before ls -l:
24117248 core-image-minimal-qemux86-64.iso
Using the mkzftree ls -l:
16777216 core-image-minimal-qemux86-64.iso
Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
meta/classes/bootimg.bbclass | 24 +---
.../zisofs-tools/zisofs-tools-native_1.0.8.bb | 19
2 files changed, 40 insertions(+), 3 deletions(-)
create mode 100644
meta/recipes-devtools/zisofs-tools/zisofs-tools-native_1.0.8.bb
diff --git a/meta/classes/bootimg.bbclass b/meta/classes/bootimg.bbclass
index 756a287..e9e4e8d 100644
--- a/meta/classes/bootimg.bbclass
+++ b/meta/classes/bootimg.bbclass
@@ -19,13 +19,15 @@
# External variables (also used by syslinux.bbclass)
# ${INITRD} - indicates a filesystem image to use as an initrd (optional)
+# ${COMPRESSISO} - Transparent compress ISO, reduce size ~40% if set to 1
# ${NOISO} - skip building the ISO image if set to 1
# ${NOHDD} - skip building the HDD image if set to 1
# ${ROOTFS} - indicates a filesystem image to include as the root filesystem
(optional)
do_bootimg[depends] += dosfstools-native:do_populate_sysroot \
mtools-native:do_populate_sysroot \
-cdrtools-native:do_populate_sysroot
+cdrtools-native:do_populate_sysroot \
+
${@oe.utils.ifelse(d.getVar('COMPRESSISO'),'zisofs-tools-native:do_populate_sysroot','')}
PACKAGES =
EXCLUDE_FROM_WORLD = 1
@@ -33,6 +35,8 @@ EXCLUDE_FROM_WORLD = 1
HDDDIR = ${S}/hddimg
ISODIR = ${S}/iso
EFIIMGDIR = ${S}/efi_img
+COMPACT_ISODIR = ${S}/iso.z
+COMPRESSISO ?=
BOOTIMG_VOLUME_ID ?= boot
BOOTIMG_EXTRA_SPACE ?= 512
@@ -95,18 +99,32 @@ build_iso() {
install -m 0644 ${STAGING_DATADIR}/syslinux/isolinux.bin
${ISODIR}${ISOLINUXDIR}
fi
+ if [ ${COMPRESSISO} = 1 ] ; then
+ # create compact directory, compress iso
+ mkdir -p ${COMPACT_ISODIR}
+ mkzftree -z 9 -p 4 -F ${ISODIR}/rootfs.img
${COMPACT_ISODIR}/rootfs.img
+
+ # move compact iso to iso, then remove compact directory
+ mv ${COMPACT_ISODIR}/rootfs.img ${ISODIR}/rootfs.img
+ rm -Rf ${COMPACT_ISODIR}
+ mkisofs_compress_opts=-R -z -D -l
+ else
+ mkisofs_compress_opts=-r
+ fi
+
if [ ${PCBIOS} = 1 ] [ ${EFI} != 1 ] ; then
# PCBIOS only media
mkisofs -V ${BOOTIMG_VOLUME_ID} \
-o ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.iso \
- -b ${ISO_BOOTIMG} -c ${ISO_BOOTCAT} -r \
+ -b ${ISO_BOOTIMG} -c ${ISO_BOOTCAT} \
+ $mkisofs_compress_opts \
${MKISOFS_OPTIONS} ${ISODIR}
else
# EFI only OR EFI+PCIBIOS
mkisofs -A ${BOOTIMG_VOLUME_ID} -V ${BOOTIMG_VOLUME_ID} \
-o ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.iso \
-b ${ISO_BOOTIMG} -c ${ISO_BOOTCAT} \
- -r ${MKISOFS_OPTIONS} \
+ $mkisofs_compress_opts ${MKISOFS_OPTIONS} \
-eltorito-alt-boot -eltorito-platform efi \
-b efi.img -no-emul-boot \
${ISODIR}
diff --git a/meta/recipes-devtools/zisofs-tools/zisofs-tools-native_1.0.8.bb
b/meta/recipes-devtools/zisofs-tools/zisofs-tools-native_1.0.8.bb
new file mode 100644
index 000..1501307
--- /dev/null
+++ b/meta/recipes-devtools/zisofs-tools/zisofs-tools-native_1.0.8.bb
@@ -0,0 +1,19 @@
+# zisofs-tools-native OE build file
+# Copyright (C) 1989, 1991 Free Software Foundation, Inc.
+SUMMARY = A set of tools for iso file compression
+DESCRIPTION = A set of tools for iso file compression
+HOMEPAGE = http://http://freecode.com/projects/zisofs-tools;
+SECTION = console/utils
+LICENSE = GPLv2
+LIC_FILES_CHKSUM = file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f
+
+SRC_URI =
http://pkgs.fedoraproject.org/repo/pkgs/zisofs-tools/zisofs-tools-${PV}.tar.bz2/2d0ed8c9a1f60b45f949b136f9be1f6c/zisofs-tools-${PV}.tar.bz2;
+
+SRC_URI[md5sum] = 2d0ed8c9a1f60b45f949b136f9be1f6c
+SRC_URI[sha256sum] =
ae4e53e4914934d41660248fb59d3c8761f1f1fd180d5ec993c17ddb3afd04f3
+
+inherit native
+
+do_install() {
+ oe_runmake install INSTALLROOT=${D} bindir=${bindir}
+}
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [v2 PATCH 6/7] grub-efi.bbclass: Add serial and graphics menu options
The syslinux.bbclass already has support for automatically generated
serial and graphics menu choices. This patch adds the same concept to
the grub-efi menu. That makes it possible to generate a single image
which can boot on a PCBIOS or EFI firmware with consistent looking
boot options.
[YOCTO #4100]
Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
meta/classes/grub-efi.bbclass | 41 +++--
1 file changed, 27 insertions(+), 14 deletions(-)
diff --git a/meta/classes/grub-efi.bbclass b/meta/classes/grub-efi.bbclass
index c21babb..ffbcf4c 100644
--- a/meta/classes/grub-efi.bbclass
+++ b/meta/classes/grub-efi.bbclass
@@ -9,6 +9,7 @@
# External variables
# ${INITRD} - indicates a filesystem image to use as an initrd (optional)
# ${ROOTFS} - indicates a filesystem image to include as the root filesystem
(optional)
+# ${GRUB_GFXSERIAL} - set this to 1 to have graphics and serial in the boot
menu
# ${LABELS} - a list of targets for the automatic config
# ${APPEND} - an override list of append strings for each label
# ${GRUB_OPTS} - additional options to add to the config, ';' delimited #
(optional)
@@ -16,6 +17,7 @@
do_bootimg[depends] += grub-efi-${TRANSLATED_TARGET_ARCH}-native:do_deploy
+GRUB_SERIAL ?= console=ttyS0,115200
GRUBCFG = ${S}/grub.cfg
GRUB_TIMEOUT ?= 10
#FIXME: build this from the machine config
@@ -63,6 +65,8 @@ python build_grub_cfg() {
bb.error(WORKDIR not defined, unable to package)
return
+gfxserial = d.getVar('GRUB_GFXSERIAL', True) or
+
labels = d.getVar('LABELS', True)
if not labels:
bb.debug(1, LABELS not defined, nothing to do)
@@ -96,6 +100,12 @@ python build_grub_cfg() {
else:
cfgfile.write('timeout=50\n')
+if gfxserial == 1:
+btypes = [ [ graphics console, console=tty0 ],
+[ serial console, d.getVar('GRUB_SERIAL', True) or ] ]
+else:
+btypes = [ [ , ] ]
+
for label in labels.split():
localdata = d.createCopy()
@@ -103,24 +113,27 @@ python build_grub_cfg() {
if not overrides:
raise bb.build.FuncFailed('OVERRIDES not defined')
-localdata.setVar('OVERRIDES', label + ':' + overrides)
-bb.data.update_data(localdata)
+for btype in btypes:
+localdata.setVar('OVERRIDES', label + ':' + overrides)
+bb.data.update_data(localdata)
-cfgfile.write('\nmenuentry \'%s\'{\n' % (label))
-if label == install:
-label = install-efi
-cfgfile.write('linux /vmlinuz LABEL=%s' % (label))
+cfgfile.write('\nmenuentry \'%s%s\'{\n' % (label, btype[0]))
+lb = label
+if label == install:
+lb = install-efi
+cfgfile.write('linux /vmlinuz LABEL=%s' % (lb))
-append = localdata.getVar('APPEND', True)
-initrd = localdata.getVar('INITRD', True)
+append = localdata.getVar('APPEND', True)
+initrd = localdata.getVar('INITRD', True)
-if append:
-cfgfile.write('%s' % (append))
-cfgfile.write('\n')
+if append:
+cfgfile.write('%s' % (append))
+cfgfile.write(' %s' % btype[1])
+cfgfile.write('\n')
-if initrd:
-cfgfile.write('initrd /initrd')
-cfgfile.write('\n}\n')
+if initrd:
+cfgfile.write('initrd /initrd')
+cfgfile.write('\n}\n')
cfgfile.close()
}
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [v2 PATCH 3/7] grub-efi-native: Add support for EFI ISO images
The iso9660 file system support needs to be added to grub in order to
be able to correctly find the grub.cfg. The grub commands to locate
the grub.cfg also needs to be encoded into grub's default
configuration.
This change allows the resulting grub binary to work both in the hard
drive / USB boot case or the optical media boot case.
[YOCTO #4100]
Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
meta/recipes-bsp/grub/files/cfg |2 ++
meta/recipes-bsp/grub/grub-efi-native_2.00.bb |7 +--
2 files changed, 7 insertions(+), 2 deletions(-)
create mode 100644 meta/recipes-bsp/grub/files/cfg
diff --git a/meta/recipes-bsp/grub/files/cfg b/meta/recipes-bsp/grub/files/cfg
new file mode 100644
index 000..e47
--- /dev/null
+++ b/meta/recipes-bsp/grub/files/cfg
@@ -0,0 +1,2 @@
+search.file /EFI/BOOT/grub.cfg root
+set prefix=($root)/EFI/BOOT
diff --git a/meta/recipes-bsp/grub/grub-efi-native_2.00.bb
b/meta/recipes-bsp/grub/grub-efi-native_2.00.bb
index 2d3d68a..04973b5 100644
--- a/meta/recipes-bsp/grub/grub-efi-native_2.00.bb
+++ b/meta/recipes-bsp/grub/grub-efi-native_2.00.bb
@@ -23,6 +23,7 @@ PR = r2
PN := grub-efi-${TRANSLATED_TARGET_ARCH}-native
SRC_URI = ftp://ftp.gnu.org/gnu/grub/grub-${PV}.tar.gz \
+ file://cfg \
file://grub-2.00-fpmath-sse-387-fix.patch \
file://grub-2.00-fix-enable_execute_stack-check.patch \
file://grub-2.00-disable-help2man.patch \
@@ -66,9 +67,11 @@ EXTRA_OECONF = --with-platform=efi --disable-grub-mkfont \
--enable-liblzma=no --enable-device-mapper=no
--enable-libzfs=no
do_mkimage() {
- ./grub-mkimage -p /EFI/BOOT -d ./grub-core/ \
+ # Search for the grub.cfg on the local boot media by using the
+ # built in cfg file provided via this recipe
+ ./grub-mkimage -c ../cfg -p /EFI/BOOT -d ./grub-core/ \
-O ${GRUB_TARGET}-efi -o ./${GRUB_IMAGE} \
- boot linux ext2 fat serial part_msdos part_gpt normal
efi_gop
+ boot linux ext2 fat serial part_msdos part_gpt normal
efi_gop iso9660 search
}
addtask mkimage after do_compile before do_install
--
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 5/5] grub-efi.bbclass: Add serial and graphics menu options
On 09/12/2013 01:01 PM, Saul Wold wrote:
On 09/12/2013 10:19 AM, Jason Wessel wrote:
The syslinux.bbclass already has support for automatically generated
serial and graphics menu choices. This patch adds the same concept to
the grub-efi menu. That makes it possible to generate a single image
which can boot on a PCBIOS or EFI firmware with consistent looking
boot options.
[YOCTO #4100]
Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
meta/classes/grub-efi.bbclass | 41
-
meta/conf/machine/qemux86-64.conf |2 +-
meta/conf/machine/qemux86.conf|2 ++
3 files changed, 30 insertions(+), 15 deletions(-)
diff --git a/meta/classes/grub-efi.bbclass b/meta/classes/grub-efi.bbclass
index c6f5d4e..c07e4a1 100644
--- a/meta/classes/grub-efi.bbclass
+++ b/meta/classes/grub-efi.bbclass
@@ -9,6 +9,7 @@
# External variables
# ${INITRD} - indicates a filesystem image to use as an initrd (optional)
# ${ROOTFS} - indicates a filesystem image to include as the root
filesystem (optional)
+# ${GRUB_GFXSERIAL} - set this to 1 to have graphics and serial in the boot
menu
# ${LABELS} - a list of targets for the automatic config
# ${APPEND} - an override list of append strings for each label
# ${GRUB_OPTS} - additional options to add to the config, ';' delimited #
(optional)
@@ -16,6 +17,7 @@
do_bootimg[depends] +=
grub-efi-${TRANSLATED_TARGET_ARCH}-native:do_deploy
+GRUB_SERIAL ?= console=ttyS0,115200
GRUBCFG = ${S}/grub.cfg
GRUB_TIMEOUT ?= 10
#FIXME: build this from the machine config
@@ -55,6 +57,8 @@ python build_grub_cfg() {
bb.error(WORKDIR not defined, unable to package)
return
+gfxserial = d.getVar('GRUB_GFXSERIAL', True) or
+
labels = d.getVar('LABELS', True)
if not labels:
bb.debug(1, LABELS not defined, nothing to do)
@@ -88,6 +92,12 @@ python build_grub_cfg() {
else:
cfgfile.write('timeout=50\n')
+if gfxserial == 1:
+btypes = [ [ graphics console, console=tty0 ],
+[ serial console, d.getVar('GRUB_SERIAL', True) or ] ]
+else:
+btypes = [ [ , ] ]
+
for label in labels.split():
localdata = d.createCopy()
@@ -95,24 +105,27 @@ python build_grub_cfg() {
if not overrides:
raise bb.build.FuncFailed('OVERRIDES not defined')
-localdata.setVar('OVERRIDES', label + ':' + overrides)
-bb.data.update_data(localdata)
+for btype in btypes:
+localdata.setVar('OVERRIDES', label + ':' + overrides)
+bb.data.update_data(localdata)
-cfgfile.write('\nmenuentry \'%s\'{\n' % (label))
-if label == install:
-label = install-efi
-cfgfile.write('linux /vmlinuz LABEL=%s' % (label))
+cfgfile.write('\nmenuentry \'%s%s\'{\n' % (label, btype[0]))
+lb = label
+if label == install:
+lb = install-efi
+cfgfile.write('linux /vmlinuz LABEL=%s' % (lb))
-append = localdata.getVar('APPEND', True)
-initrd = localdata.getVar('INITRD', True)
+append = localdata.getVar('APPEND', True)
+initrd = localdata.getVar('INITRD', True)
-if append:
-cfgfile.write('%s' % (append))
-cfgfile.write('\n')
+if append:
+cfgfile.write('%s' % (append))
+cfgfile.write(' %s' % btype[1])
+cfgfile.write('\n')
-if initrd:
-cfgfile.write('initrd /initrd')
-cfgfile.write('\n}\n')
+if initrd:
+cfgfile.write('initrd /initrd')
+cfgfile.write('\n}\n')
cfgfile.close()
}
diff --git a/meta/conf/machine/qemux86-64.conf
b/meta/conf/machine/qemux86-64.conf
index c572225..6f68410 100644
--- a/meta/conf/machine/qemux86-64.conf
+++ b/meta/conf/machine/qemux86-64.conf
@@ -21,6 +21,6 @@ XSERVER = xserver-xorg \
xf86-input-evdev \
xf86-video-vmware
-MACHINE_FEATURES += x86
+MACHINE_FEATURES += x86 efi
MACHINE_ESSENTIAL_EXTRA_RDEPENDS += v86d
diff --git a/meta/conf/machine/qemux86.conf b/meta/conf/machine/qemux86.conf
index 94ee573..57a9a50 100644
--- a/meta/conf/machine/qemux86.conf
+++ b/meta/conf/machine/qemux86.conf
@@ -22,5 +22,7 @@ XSERVER = xserver-xorg \
xf86-video-vmware
MACHINE_FEATURES += x86
+MACHINE_FEATURES += efi
+#MACHINE_FEATURES += pcbios
Did you intend to keep the commented out like vs what you did above in
x86-64?
MACHINE_ESSENTIAL_EXTRA_RDEPENDS += v86d
Will this affect the genericx86* also?
Doh! That isn't even supposed to be in there. I was just using the qemu
targets to build some generic images and then run them on qemu + some real hw +
Tiano UEFI core images. It is possible that we can just start building pcbios
and efi
Re: [OE-core] [PATCH 4/5] bootimage.bbclass: Improve EFI PCBIOS+EFI ISO support
On 09/12/2013 01:09 PM, Darren Hart wrote:
On Thu, 2013-09-12 at 12:19 -0500, Jason Wessel wrote:
Using the latest mkisofs it is possible to generate 3 different types
of ISO images, which can be used in various scenarios.
1) PCBIOS Only ISO
- This option remains unchanged by this commit
- Uses syslinux menus
- Can be directly copied with dd to a USB device
- Can be burned to optical media
2) EFI Only ISO
- Uses grub 2 menus
- Can be burned to optical media
- If you want to use this image on a USB device
extra steps must be taken in order to format the USB
device with fat32, and copy an EFI loader which will
in turn load the iso image
3) PCBIOS / EFI ISO
- This is a hybrid image ISO that will work for case 1 or 2
as above with the same restrictions and boot menu types
depending on what type of firmware is installed on
the hardware or depending on if EFI or Legacy Boot is
enabled on some UEFI firmwares.
[YOCTO #4100]
Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
meta/classes/bootimg.bbclass | 37 ++---
1 file changed, 34 insertions(+), 3 deletions(-)
diff --git a/meta/classes/bootimg.bbclass b/meta/classes/bootimg.bbclass
index 2ed7017..b4301e8 100644
--- a/meta/classes/bootimg.bbclass
+++ b/meta/classes/bootimg.bbclass
@@ -35,6 +35,7 @@ EXCLUDE_FROM_WORLD = 1
HDDDIR = ${S}/hddimg
ISODIR = ${S}/iso
+EFIIMGDIR = ${S}/efi_img
COMPACT_ISODIR = ${S}/iso.z
BOOTIMG_VOLUME_ID ?= boot
@@ -109,19 +110,49 @@ build_iso() {
mkisofs_opts=-R -z -D -l
fi
Am I missing a patch? I don't have this mkisofs_opts in my
bootimg.bbclass
Yes
How are $mkisofs_opts and ${MKISOFS_OPTIONS} related? Do we need both?
Yes.
I built this patch set on top of the zisofs support I posted a day or so ago.
I'll include that patch in the series next time, else it would create merge
conflicts.
The piece from the other patch is:
+ if [ ${COMPRESSISO} = 1 ] ; then
+ # create compact directory, compress iso
+ mkdir -p ${COMPACT_ISODIR}
+ mkzftree -z 9 -p 4 -F ${ISODIR}/rootfs.img
${COMPACT_ISODIR}/rootfs.img
+
+ # move compact iso to iso, then remove compact directory
+ mv ${COMPACT_ISODIR}/rootfs.img ${ISODIR}/rootfs.img
+ rm -Rf ${COMPACT_ISODIR}
+ mkisofs_opts=-r
+ else
+ mkisofs_opts=-R -z -D -l
+ fi
+
The zisofs is a big win for some folks because it will cut their image size in
1/2 so they can use single layer media instead of dual layer media for example.
-if [ ${PCBIOS} = 1 ]; then
+if [ ${EFI} = 1 ] ; then
+# Build a EFI directory to create efi.img
+mkdir -p ${EFIIMGDIR}/${EFIDIR}
+cp ${ISODIR}/${EFIDIR}/* ${EFIIMGDIR}${EFIDIR}
+cp ${ISODIR}/vmlinuz ${EFIIMGDIR}
+GRUB_IMAGE=bootia32.efi
+if [ ${TARGET_ARCH} = x86_64 ]; then
+GRUB_IMAGE=bootx64.efi
+fi
+echo EFI\\BOOT\\${GRUB_IMAGE} ${EFIIMGDIR}/startup.nsh
+if [ -f ${ISODIR}/initrd ] ; then
+cp ${ISODIR}/initrd ${EFIIMGDIR}
+fi
+build_fat_img ${EFIIMGDIR} ${ISODIR}/efi.img
+fi
+
+# Three ways to build the media
+if [ ${PCBIOS} = 1 -a ${EFI} = 1 ]; then
Per the Dash as BinSh wiki, the -a syntax is discouraged, best practices
seem to be the use of and || instead:
if ([ ${PCBIOS} = 1 ] [ ${EFI} = 1 ]); then
Noted for the future :-)
+# 1) Build EFI + PCBIOS hybrid
+mkisofs -A ${BOOTIMG_VOLUME_ID} -V ${BOOTIMG_VOLUME_ID} \
+-o ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.iso \
+-b ${ISO_BOOTIMG} -c ${ISO_BOOTCAT} $mkisofs_opts \
+${MKISOFS_OPTIONS} \
+-eltorito-alt-boot -eltorito-platform efi \
+-b efi.img -no-emul-boot \
+${ISODIR}
Has this been verified on any 32 bit PCBIOS platforms?
Yes, on tunnel creek based hardware.
It was my understanding the many 32 bit PCBIOS systems had very buggy
el-torito support and didn't deal well with multiple el-torito images on
the same disk. Although... looking at the command above, I'm not sure
you're doing this with mutliple images. Do you have the syslinux and the
efi image combined in the same efi.img?
My testing showed it worked for both EFI only and EFI+PCBIOS. In the case of
the EFI+PCBIOS image there are two eltorito images, but in the case of the EFI
only, there is only one, so at least you have two options. The Fedora install
media uses the EFI+PCBIOS style image, so if that booted on the hardware you
had problems with, this will too.
Has this been verified to work on USB media?
The image only works
Re: [OE-core] [PATCH 5/5] grub-efi.bbclass: Add serial and graphics menu options
On 09/12/2013 01:16 PM, Darren Hart wrote:
On Thu, 2013-09-12 at 12:19 -0500, Jason Wessel wrote:
The syslinux.bbclass already has support for automatically generated
serial and graphics menu choices. This patch adds the same concept to
the grub-efi menu. That makes it possible to generate a single image
which can boot on a PCBIOS or EFI firmware with consistent looking
boot options.
[YOCTO #4100]
Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
meta/classes/grub-efi.bbclass | 41
-
meta/conf/machine/qemux86-64.conf |2 +-
meta/conf/machine/qemux86.conf|2 ++
3 files changed, 30 insertions(+), 15 deletions(-)
diff --git a/meta/classes/grub-efi.bbclass b/meta/classes/grub-efi.bbclass
index c6f5d4e..c07e4a1 100644
--- a/meta/classes/grub-efi.bbclass
+++ b/meta/classes/grub-efi.bbclass
@@ -9,6 +9,7 @@
# External variables
# ${INITRD} - indicates a filesystem image to use as an initrd (optional)
# ${ROOTFS} - indicates a filesystem image to include as the root
filesystem (optional)
+# ${GRUB_GFXSERIAL} - set this to 1 to have graphics and serial in the boot
menu
# ${LABELS} - a list of targets for the automatic config
# ${APPEND} - an override list of append strings for each label
# ${GRUB_OPTS} - additional options to add to the config, ';' delimited #
(optional)
@@ -16,6 +17,7 @@
do_bootimg[depends] += grub-efi-${TRANSLATED_TARGET_ARCH}-native:do_deploy
+GRUB_SERIAL ?= console=ttyS0,115200
GRUBCFG = ${S}/grub.cfg
GRUB_TIMEOUT ?= 10
#FIXME: build this from the machine config
@@ -55,6 +57,8 @@ python build_grub_cfg() {
bb.error(WORKDIR not defined, unable to package)
return
+gfxserial = d.getVar('GRUB_GFXSERIAL', True) or
+
labels = d.getVar('LABELS', True)
if not labels:
bb.debug(1, LABELS not defined, nothing to do)
@@ -88,6 +92,12 @@ python build_grub_cfg() {
else:
cfgfile.write('timeout=50\n')
+if gfxserial == 1:
+btypes = [ [ graphics console, console=tty0 ],
+[ serial console, d.getVar('GRUB_SERIAL', True) or ] ]
+else:
+btypes = [ [ , ] ]
+
for label in labels.split():
localdata = d.createCopy()
@@ -95,24 +105,27 @@ python build_grub_cfg() {
if not overrides:
raise bb.build.FuncFailed('OVERRIDES not defined')
-localdata.setVar('OVERRIDES', label + ':' + overrides)
-bb.data.update_data(localdata)
+for btype in btypes:
+localdata.setVar('OVERRIDES', label + ':' + overrides)
+bb.data.update_data(localdata)
-cfgfile.write('\nmenuentry \'%s\'{\n' % (label))
-if label == install:
-label = install-efi
-cfgfile.write('linux /vmlinuz LABEL=%s' % (label))
+cfgfile.write('\nmenuentry \'%s%s\'{\n' % (label, btype[0]))
+lb = label
+if label == install:
+lb = install-efi
+cfgfile.write('linux /vmlinuz LABEL=%s' % (lb))
-append = localdata.getVar('APPEND', True)
-initrd = localdata.getVar('INITRD', True)
+append = localdata.getVar('APPEND', True)
+initrd = localdata.getVar('INITRD', True)
-if append:
-cfgfile.write('%s' % (append))
-cfgfile.write('\n')
+if append:
+cfgfile.write('%s' % (append))
+cfgfile.write(' %s' % btype[1])
+cfgfile.write('\n')
-if initrd:
-cfgfile.write('initrd /initrd')
-cfgfile.write('\n}\n')
+if initrd:
+cfgfile.write('initrd /initrd')
+cfgfile.write('\n}\n')
cfgfile.close()
}
I'm not very familiar with the cfgfile for menus and such, so I don't
have much to add. The one thing that catches me by surprise is the need
for the serial device. On EFI systems, grub here uses the EFI console
service, so if that uses the serial port you get it for free, no need
for GRUB to try and use it directly. In fact does the above not
cause some kind of conflict between the EFI console service and grub
serial?
In part that is why it is optional. With respect to the serial bits, these
are only the kernel boot arguments we are talking about. It doesn't seem that
there is a primary display interface for the HCDP in the EFI firmware I have.
Additionally, the kernel throws the EFI serial console under the bus at ACPI
probe time, while this certainly could also be a bug in the firmware I have on
my test board, the only way to keep the serial port alive for a login and the
kernel boot information was to specify console=ttyS0...
I have yet another system I need to try this on which has a much newer UEFI and
a serial port, but I thought it would be best to get something out there that
covers the buggy firmwares as well
[OE-core] [PATCH 1/5] bootimage.bbclass: Move fat image creation into a function
In order to call the fat image creation multiple times it needs to be
in its own function. A future commit will make use of the new
function to additionally create EFI image files for use with an ISO.
[YOCTO #4100]
Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
meta/classes/bootimg.bbclass | 110 ++
1 file changed, 58 insertions(+), 52 deletions(-)
diff --git a/meta/classes/bootimg.bbclass b/meta/classes/bootimg.bbclass
index b312e0d..2ed7017 100644
--- a/meta/classes/bootimg.bbclass
+++ b/meta/classes/bootimg.bbclass
@@ -128,6 +128,63 @@ build_iso() {
ln -s ${IMAGE_NAME}.iso ${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.iso
}
+build_fat_img() {
+ FATSOURCEDIR=$1
+ FATIMG=$2
+
+ # Calculate the size required for the final image including the
+ # data and filesystem overhead.
+ # Sectors: 512 bytes
+ # Blocks: 1024 bytes
+
+ # Determine the sector count just for the data
+ SECTORS=$(expr $(du --apparent-size -ks ${FATSOURCEDIR} | cut -f 1) \*
2)
+
+ # Account for the filesystem overhead. This includes directory
+ # entries in the clusters as well as the FAT itself.
+ # Assumptions:
+ # FAT32 (12 or 16 may be selected by mkdosfs, but the extra
+ # padding will be minimal on those smaller images and not
+ # worth the logic here to caclulate the smaller FAT sizes)
+ #16 entries per directory
+ # 8.3 filenames only
+
+ # 32 bytes per dir entry
+ DIR_BYTES=$(expr $(find ${FATSOURCEDIR} | tail -n +2 | wc -l) \* 32)
+ # 32 bytes for every end-of-directory dir entry
+ DIR_BYTES=$(expr $DIR_BYTES + $(expr $(find ${FATSOURCEDIR} -type d |
tail -n +2 | wc -l) \* 32))
+ # 4 bytes per FAT entry per sector of data
+ FAT_BYTES=$(expr $SECTORS \* 4)
+ # 4 bytes per FAT entry per end-of-cluster list
+ FAT_BYTES=$(expr $FAT_BYTES + $(expr $(find ${FATSOURCEDIR} -type d |
tail -n +2 | wc -l) \* 4))
+
+ # Use a ceiling function to determine FS overhead in sectors
+ DIR_SECTORS=$(expr $(expr $DIR_BYTES + 511) / 512)
+ # There are two FATs on the image
+ FAT_SECTORS=$(expr $(expr $(expr $FAT_BYTES + 511) / 512) \* 2)
+ SECTORS=$(expr $SECTORS + $(expr $DIR_SECTORS + $FAT_SECTORS))
+
+ # Determine the final size in blocks accounting for some padding
+ BLOCKS=$(expr $(expr $SECTORS / 2) + ${BOOTIMG_EXTRA_SPACE})
+
+ # Ensure total sectors is an integral number of sectors per
+ # track or mcopy will complain. Sectors are 512 bytes, and we
+ # generate images with 32 sectors per track. This calculation is
+ # done in blocks, thus the mod by 16 instead of 32.
+ BLOCKS=$(expr $BLOCKS + $(expr 16 - $(expr $BLOCKS % 16)))
+
+ # mkdosfs will sometimes use FAT16 when it is not appropriate,
+ # resulting in a boot failure from SYSLINUX. Use FAT32 for
+ # images larger than 512MB, otherwise let mkdosfs decide.
+ if [ $(expr $BLOCKS / 1024) -gt 512 ]; then
+ FATSIZE=-F 32
+ fi
+
+ mkdosfs ${FATSIZE} -n ${BOOTIMG_VOLUME_ID} -S 512 -C ${FATIMG} ${BLOCKS}
+ # Copy FATSOURCEDIR recursively into the image file directly
+ mcopy -i ${FATIMG} -s ${FATSOURCEDIR}/* ::/
+}
+
build_hddimg() {
# Create an HDD image
if [ ${NOHDD} != 1 ] ; then
@@ -140,58 +197,7 @@ build_hddimg() {
grubefi_hddimg_populate
fi
- # Calculate the size required for the final image including the
- # data and filesystem overhead.
- # Sectors: 512 bytes
- # Blocks: 1024 bytes
-
- # Determine the sector count just for the data
- SECTORS=$(expr $(du --apparent-size -ks ${HDDDIR} | cut -f 1)
\* 2)
-
- # Account for the filesystem overhead. This includes directory
- # entries in the clusters as well as the FAT itself.
- # Assumptions:
- # FAT32 (12 or 16 may be selected by mkdosfs, but the extra
- # padding will be minimal on those smaller images and not
- # worth the logic here to caclulate the smaller FAT sizes)
- #16 entries per directory
- # 8.3 filenames only
-
- # 32 bytes per dir entry
- DIR_BYTES=$(expr $(find ${HDDDIR} | tail -n +2 | wc -l) \* 32)
- # 32 bytes for every end-of-directory dir entry
- DIR_BYTES=$(expr $DIR_BYTES + $(expr $(find ${HDDDIR} -type d |
tail -n +2 | wc -l) \* 32))
- # 4 bytes per FAT entry per sector of data
- FAT_BYTES=$(expr $SECTORS \* 4)
- # 4 bytes per FAT entry per end-of-cluster list
- FAT_BYTES=$(expr $FAT_BYTES + $(expr $(find ${HDDDIR} -type d |
tail -n +2 | wc -l) \* 4))
-
- # Use a ceiling function
[OE-core] [PATCH 3/5] grub-efi-native: Add support for EFI ISO images
The iso9660 file system support needs to be added to grub in order to
be able to correctly find the grub.cfg. The grub commands to locate
the grub.cfg also needs to be encoded into grub's default
configuration.
This change allows the resulting grub binary to work both in the hard
drive / USB boot case or the optical media boot case.
[YOCTO #4100]
Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
meta/recipes-bsp/grub/grub-efi-native_2.00.bb |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-bsp/grub/grub-efi-native_2.00.bb
b/meta/recipes-bsp/grub/grub-efi-native_2.00.bb
index 2d3d68a..3cff838 100644
--- a/meta/recipes-bsp/grub/grub-efi-native_2.00.bb
+++ b/meta/recipes-bsp/grub/grub-efi-native_2.00.bb
@@ -66,9 +66,13 @@ EXTRA_OECONF = --with-platform=efi --disable-grub-mkfont \
--enable-liblzma=no --enable-device-mapper=no
--enable-libzfs=no
do_mkimage() {
- ./grub-mkimage -p /EFI/BOOT -d ./grub-core/ \
+ # Search for the grub.cfg on the local boot media with built in config
file
+ echo 'search.file /EFI/BOOT/grub.cfg root' cfg
+ echo 'set prefix=($root)/EFI/BOOT' cfg
+
+ ./grub-mkimage -c cfg -p /EFI/BOOT -d ./grub-core/ \
-O ${GRUB_TARGET}-efi -o ./${GRUB_IMAGE} \
- boot linux ext2 fat serial part_msdos part_gpt normal
efi_gop
+ boot linux ext2 fat serial part_msdos part_gpt normal
efi_gop iso9660 search
}
addtask mkimage after do_compile before do_install
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/5] Improved EFI boot support
The goal of this patch set is to put the EFI ISO boot method on par
with the ISO PCBIOS boot method. This also allows for the creation of
a single ISO image which can boot in legacy boot mode or EFI boot
mode.
In order to make this possible the cdrtools needed an update to the
very latest and this brings in an license change. Given that change
it was not entirely clear to me if we needed to leave the older
package around. I opted to remove the older package recipe since
there was no clean way to fail in the case you wanted to build EFI
boot media.
The bbnote that was previously in the bootimg.bbclass about EFI only
media being untested was a bit of an understatement, as the images
would not even build without errors due to the call to isohybrid. I
removed any such warnings because that path has been fully vetted now.
Cheers,
Jason.
Jason Wessel (5):
bootimage.bbclass: Move fat image creation into a function
cdrtools-native: Update from 3.00 to 3.01a17
grub-efi-native: Add support for EFI ISO images
bootimage.bbclass: Improve EFI PCBIOS+EFI ISO support
grub-efi.bbclass: Add serial and graphics menu options
meta/classes/bootimg.bbclass | 147
meta/classes/grub-efi.bbclass | 41 --
meta/conf/machine/qemux86-64.conf |2 +-
meta/conf/machine/qemux86.conf |2 +
meta/recipes-bsp/grub/grub-efi-native_2.00.bb |8 +-
...s-native_3.00.bb = cdrtools-native_3.01a17.bb} | 13 +-
6 files changed, 135 insertions(+), 78 deletions(-)
rename meta/recipes-devtools/cdrtools/{cdrtools-native_3.00.bb =
cdrtools-native_3.01a17.bb} (64%)
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 5/5] grub-efi.bbclass: Add serial and graphics menu options
The syslinux.bbclass already has support for automatically generated
serial and graphics menu choices. This patch adds the same concept to
the grub-efi menu. That makes it possible to generate a single image
which can boot on a PCBIOS or EFI firmware with consistent looking
boot options.
[YOCTO #4100]
Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
meta/classes/grub-efi.bbclass | 41 -
meta/conf/machine/qemux86-64.conf |2 +-
meta/conf/machine/qemux86.conf|2 ++
3 files changed, 30 insertions(+), 15 deletions(-)
diff --git a/meta/classes/grub-efi.bbclass b/meta/classes/grub-efi.bbclass
index c6f5d4e..c07e4a1 100644
--- a/meta/classes/grub-efi.bbclass
+++ b/meta/classes/grub-efi.bbclass
@@ -9,6 +9,7 @@
# External variables
# ${INITRD} - indicates a filesystem image to use as an initrd (optional)
# ${ROOTFS} - indicates a filesystem image to include as the root filesystem
(optional)
+# ${GRUB_GFXSERIAL} - set this to 1 to have graphics and serial in the boot
menu
# ${LABELS} - a list of targets for the automatic config
# ${APPEND} - an override list of append strings for each label
# ${GRUB_OPTS} - additional options to add to the config, ';' delimited #
(optional)
@@ -16,6 +17,7 @@
do_bootimg[depends] += grub-efi-${TRANSLATED_TARGET_ARCH}-native:do_deploy
+GRUB_SERIAL ?= console=ttyS0,115200
GRUBCFG = ${S}/grub.cfg
GRUB_TIMEOUT ?= 10
#FIXME: build this from the machine config
@@ -55,6 +57,8 @@ python build_grub_cfg() {
bb.error(WORKDIR not defined, unable to package)
return
+gfxserial = d.getVar('GRUB_GFXSERIAL', True) or
+
labels = d.getVar('LABELS', True)
if not labels:
bb.debug(1, LABELS not defined, nothing to do)
@@ -88,6 +92,12 @@ python build_grub_cfg() {
else:
cfgfile.write('timeout=50\n')
+if gfxserial == 1:
+btypes = [ [ graphics console, console=tty0 ],
+[ serial console, d.getVar('GRUB_SERIAL', True) or ] ]
+else:
+btypes = [ [ , ] ]
+
for label in labels.split():
localdata = d.createCopy()
@@ -95,24 +105,27 @@ python build_grub_cfg() {
if not overrides:
raise bb.build.FuncFailed('OVERRIDES not defined')
-localdata.setVar('OVERRIDES', label + ':' + overrides)
-bb.data.update_data(localdata)
+for btype in btypes:
+localdata.setVar('OVERRIDES', label + ':' + overrides)
+bb.data.update_data(localdata)
-cfgfile.write('\nmenuentry \'%s\'{\n' % (label))
-if label == install:
-label = install-efi
-cfgfile.write('linux /vmlinuz LABEL=%s' % (label))
+cfgfile.write('\nmenuentry \'%s%s\'{\n' % (label, btype[0]))
+lb = label
+if label == install:
+lb = install-efi
+cfgfile.write('linux /vmlinuz LABEL=%s' % (lb))
-append = localdata.getVar('APPEND', True)
-initrd = localdata.getVar('INITRD', True)
+append = localdata.getVar('APPEND', True)
+initrd = localdata.getVar('INITRD', True)
-if append:
-cfgfile.write('%s' % (append))
-cfgfile.write('\n')
+if append:
+cfgfile.write('%s' % (append))
+cfgfile.write(' %s' % btype[1])
+cfgfile.write('\n')
-if initrd:
-cfgfile.write('initrd /initrd')
-cfgfile.write('\n}\n')
+if initrd:
+cfgfile.write('initrd /initrd')
+cfgfile.write('\n}\n')
cfgfile.close()
}
diff --git a/meta/conf/machine/qemux86-64.conf
b/meta/conf/machine/qemux86-64.conf
index c572225..6f68410 100644
--- a/meta/conf/machine/qemux86-64.conf
+++ b/meta/conf/machine/qemux86-64.conf
@@ -21,6 +21,6 @@ XSERVER = xserver-xorg \
xf86-input-evdev \
xf86-video-vmware
-MACHINE_FEATURES += x86
+MACHINE_FEATURES += x86 efi
MACHINE_ESSENTIAL_EXTRA_RDEPENDS += v86d
diff --git a/meta/conf/machine/qemux86.conf b/meta/conf/machine/qemux86.conf
index 94ee573..57a9a50 100644
--- a/meta/conf/machine/qemux86.conf
+++ b/meta/conf/machine/qemux86.conf
@@ -22,5 +22,7 @@ XSERVER = xserver-xorg \
xf86-video-vmware
MACHINE_FEATURES += x86
+MACHINE_FEATURES += efi
+#MACHINE_FEATURES += pcbios
MACHINE_ESSENTIAL_EXTRA_RDEPENDS += v86d
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 4/5] bootimage.bbclass: Improve EFI PCBIOS+EFI ISO support
Using the latest mkisofs it is possible to generate 3 different types
of ISO images, which can be used in various scenarios.
1) PCBIOS Only ISO
- This option remains unchanged by this commit
- Uses syslinux menus
- Can be directly copied with dd to a USB device
- Can be burned to optical media
2) EFI Only ISO
- Uses grub 2 menus
- Can be burned to optical media
- If you want to use this image on a USB device
extra steps must be taken in order to format the USB
device with fat32, and copy an EFI loader which will
in turn load the iso image
3) PCBIOS / EFI ISO
- This is a hybrid image ISO that will work for case 1 or 2
as above with the same restrictions and boot menu types
depending on what type of firmware is installed on
the hardware or depending on if EFI or Legacy Boot is
enabled on some UEFI firmwares.
[YOCTO #4100]
Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
meta/classes/bootimg.bbclass | 37 ++---
1 file changed, 34 insertions(+), 3 deletions(-)
diff --git a/meta/classes/bootimg.bbclass b/meta/classes/bootimg.bbclass
index 2ed7017..b4301e8 100644
--- a/meta/classes/bootimg.bbclass
+++ b/meta/classes/bootimg.bbclass
@@ -35,6 +35,7 @@ EXCLUDE_FROM_WORLD = 1
HDDDIR = ${S}/hddimg
ISODIR = ${S}/iso
+EFIIMGDIR = ${S}/efi_img
COMPACT_ISODIR = ${S}/iso.z
BOOTIMG_VOLUME_ID ?= boot
@@ -109,19 +110,49 @@ build_iso() {
mkisofs_opts=-R -z -D -l
fi
- if [ ${PCBIOS} = 1 ]; then
+ if [ ${EFI} = 1 ] ; then
+ # Build a EFI directory to create efi.img
+ mkdir -p ${EFIIMGDIR}/${EFIDIR}
+ cp ${ISODIR}/${EFIDIR}/* ${EFIIMGDIR}${EFIDIR}
+ cp ${ISODIR}/vmlinuz ${EFIIMGDIR}
+ GRUB_IMAGE=bootia32.efi
+ if [ ${TARGET_ARCH} = x86_64 ]; then
+ GRUB_IMAGE=bootx64.efi
+ fi
+ echo EFI\\BOOT\\${GRUB_IMAGE} ${EFIIMGDIR}/startup.nsh
+ if [ -f ${ISODIR}/initrd ] ; then
+ cp ${ISODIR}/initrd ${EFIIMGDIR}
+ fi
+ build_fat_img ${EFIIMGDIR} ${ISODIR}/efi.img
+ fi
+
+ # Three ways to build the media
+ if [ ${PCBIOS} = 1 -a ${EFI} = 1 ]; then
+ # 1) Build EFI + PCBIOS hybrid
+ mkisofs -A ${BOOTIMG_VOLUME_ID} -V ${BOOTIMG_VOLUME_ID} \
+ -o ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.iso \
+ -b ${ISO_BOOTIMG} -c ${ISO_BOOTCAT} $mkisofs_opts \
+ ${MKISOFS_OPTIONS} \
+ -eltorito-alt-boot -eltorito-platform efi \
+ -b efi.img -no-emul-boot \
+ ${ISODIR}
+ elif [ ${PCBIOS} = 1 ] ; then
+ # 2) Build PCBIOS only media
mkisofs -V ${BOOTIMG_VOLUME_ID} \
-o ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.iso \
-b ${ISO_BOOTIMG} -c ${ISO_BOOTCAT} $mkisofs_opts \
${MKISOFS_OPTIONS} ${ISODIR}
else
- bbnote EFI-only ISO images are untested, please provide
feedback.
mkisofs -V ${BOOTIMG_VOLUME_ID} \
-o ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.iso \
+ -eltorito-alt-boot -eltorito-platform efi \
+ -b efi.img -no-emul-boot \
-r ${ISODIR}
fi
- isohybrid ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.iso
+ if [ ${PCBIOS} = 1 ]; then
+ isohybrid ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.iso
+ fi
cd ${DEPLOY_DIR_IMAGE}
rm -f ${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.iso
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/5] cdrtools-native: Update from 3.00 to 3.01a17
The update is needed to support generation of EFI boot images that
work with optical media. Specifically the -eltorito-platform efi
capability for mkisofs is needed.
[YOCTO #4100]
Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
.../cdrtools/cdrtools-native_3.00.bb | 30 ---
.../cdrtools/cdrtools-native_3.01a17.bb| 31
2 files changed, 31 insertions(+), 30 deletions(-)
delete mode 100644 meta/recipes-devtools/cdrtools/cdrtools-native_3.00.bb
create mode 100644 meta/recipes-devtools/cdrtools/cdrtools-native_3.01a17.bb
diff --git a/meta/recipes-devtools/cdrtools/cdrtools-native_3.00.bb
b/meta/recipes-devtools/cdrtools/cdrtools-native_3.00.bb
deleted file mode 100644
index 7e4c381..000
--- a/meta/recipes-devtools/cdrtools/cdrtools-native_3.00.bb
+++ /dev/null
@@ -1,30 +0,0 @@
-# cdrtools-native OE build file
-# Copyright (C) 2004-2006, Advanced Micro Devices, Inc. All Rights Reserved
-# Released under the MIT license (see packages/COPYING)
-SUMMARY = A set of tools for CD recording, including cdrecord
-DESCRIPTION = A set of tools for CD recording, including cdrecord
-HOMEPAGE = http://cdrecord.berlios.de/private/cdrecord.html;
-SECTION = console/utils
-LICENSE = GPLv2
-LIC_FILES_CHKSUM = file://COPYING;md5=8d16123ffd39e649a5e4a6bc1de60e6d
-PR = r0
-
-SRC_URI = ftp://ftp.berlios.de/pub/cdrecord/cdrtools-${PV}.tar.bz2 \
- file://no_usr_src.patch
-
-SRC_URI[md5sum] = f9fbab08fbd458b0d2312976d8c5f558
-SRC_URI[sha256sum] =
7f9cb64820055573b880f77b2f16662a512518336ba95ab49228a1617973423d
-
-inherit native
-
-STAGE_TEMP = ${WORKDIR}/image-temp
-
-FILESPATH = ${FILE_DIRNAME}/cdrtools-native/
-
-do_install() {
- install -d ${STAGE_TEMP}
- make install INS_BASE=${STAGE_TEMP}
-
- install -d ${D}${bindir}/
- install ${STAGE_TEMP}/bin/* ${D}${bindir}/
-}
diff --git a/meta/recipes-devtools/cdrtools/cdrtools-native_3.01a17.bb
b/meta/recipes-devtools/cdrtools/cdrtools-native_3.01a17.bb
new file mode 100644
index 000..4a7a160
--- /dev/null
+++ b/meta/recipes-devtools/cdrtools/cdrtools-native_3.01a17.bb
@@ -0,0 +1,31 @@
+# cdrtools-native OE build file
+# Copyright (C) 2004-2006, Advanced Micro Devices, Inc. All Rights Reserved
+# Released under the MIT license (see packages/COPYING)
+SUMMARY = A set of tools for CD recording, including cdrecord
+DESCRIPTION = A set of tools for CD recording, including cdrecord
+HOMEPAGE = http://cdrecord.berlios.de/private/cdrecord.html;
+SECTION = console/utils
+LICENSE = GPLv2 CDDL-1.0 LGPLv2.1+
+LIC_FILES_CHKSUM = file://COPYING;md5=32f68170be424c2cd64804337726b312
+PR = r0
+
+SRC_URI = ftp://ftp.berlios.de/pub/cdrecord/alpha/cdrtools-${PV}.tar.bz2;
+
+SRC_URI[md5sum] = 4cef9db0cf15a770c52d65b00bbee2db
+SRC_URI[sha256sum] =
3d613965b213ad83e4be0ba2535e784901839ea4d11a20a2beb6765f0eb76dfa
+
+S = ${WORKDIR}/cdrtools-3.01
+
+inherit native
+
+STAGE_TEMP = ${WORKDIR}/image-temp
+
+FILESPATH = ${FILE_DIRNAME}/cdrtools-native/
+
+do_install() {
+ install -d ${STAGE_TEMP}
+ make install INS_BASE=${STAGE_TEMP}
+
+ install -d ${D}${bindir}/
+ install ${STAGE_TEMP}/bin/* ${D}${bindir}/
+}
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] bootimage.bbclass, zisofs-tools-native: add ability to compress ISO images
The mkzftree is needed to allow ISO images to be compressed with
minimal runtime overhead. Below is an example of the savings on a
core-image-minimal.
Before ls -l:
24117248 core-image-minimal-qemux86-64.iso
Using the mkzftree ls -l:
16777216 core-image-minimal-qemux86-64.iso
Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
meta/classes/bootimg.bbclass | 21 ++--
.../zisofs-tools/zisofs-tools-native_1.0.8.bb | 26
2 files changed, 45 insertions(+), 2 deletions(-)
create mode 100644
meta/recipes-devtools/zisofs-tools/zisofs-tools-native_1.0.8.bb
diff --git a/meta/classes/bootimg.bbclass b/meta/classes/bootimg.bbclass
index 90a241d..b312e0d 100644
--- a/meta/classes/bootimg.bbclass
+++ b/meta/classes/bootimg.bbclass
@@ -19,19 +19,23 @@
# External variables (also used by syslinux.bbclass)
# ${INITRD} - indicates a filesystem image to use as an initrd (optional)
+# ${COMPRESSISO}
# ${NOISO} - skip building the ISO image if set to 1
# ${NOHDD} - skip building the HDD image if set to 1
# ${ROOTFS} - indicates a filesystem image to include as the root filesystem
(optional)
+COMPRESSISO ?=
do_bootimg[depends] += dosfstools-native:do_populate_sysroot \
mtools-native:do_populate_sysroot \
-cdrtools-native:do_populate_sysroot
+cdrtools-native:do_populate_sysroot \
+
${@oe.utils.ifelse(d.getVar('COMPRESSISO'),'zisofs-tools-native:do_populate_sysroot','')}
PACKAGES =
EXCLUDE_FROM_WORLD = 1
HDDDIR = ${S}/hddimg
ISODIR = ${S}/iso
+COMPACT_ISODIR = ${S}/iso.z
BOOTIMG_VOLUME_ID ?= boot
BOOTIMG_EXTRA_SPACE ?= 512
@@ -92,10 +96,23 @@ build_iso() {
grubefi_iso_populate
fi
+ if [ ${COMPRESSISO} = 1 ] ; then
+ # create compact directory, compress iso
+ mkdir -p ${COMPACT_ISODIR}
+ mkzftree -z 9 -p 4 -F ${ISODIR}/rootfs.img
${COMPACT_ISODIR}/rootfs.img
+
+ # move compact iso to iso, then remove compact directory
+ mv ${COMPACT_ISODIR}/rootfs.img ${ISODIR}/rootfs.img
+ rm -Rf ${COMPACT_ISODIR}
+ mkisofs_opts=-r
+ else
+ mkisofs_opts=-R -z -D -l
+ fi
+
if [ ${PCBIOS} = 1 ]; then
mkisofs -V ${BOOTIMG_VOLUME_ID} \
-o ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.iso \
- -b ${ISO_BOOTIMG} -c ${ISO_BOOTCAT} -r \
+ -b ${ISO_BOOTIMG} -c ${ISO_BOOTCAT} $mkisofs_opts \
${MKISOFS_OPTIONS} ${ISODIR}
else
bbnote EFI-only ISO images are untested, please provide
feedback.
diff --git a/meta/recipes-devtools/zisofs-tools/zisofs-tools-native_1.0.8.bb
b/meta/recipes-devtools/zisofs-tools/zisofs-tools-native_1.0.8.bb
new file mode 100644
index 000..b590854
--- /dev/null
+++ b/meta/recipes-devtools/zisofs-tools/zisofs-tools-native_1.0.8.bb
@@ -0,0 +1,26 @@
+# zisofs-tools-native OE build file
+# Copyright (C) 1989, 1991 Free Software Foundation, Inc.
+SUMMARY = A set of tools for iso file compression
+DESCRIPTION = A set of tools for iso file compression
+HOMEPAGE = http://http://freecode.com/projects/zisofs-tools;
+SECTION = console/utils
+LICENSE = GPLv2
+LIC_FILES_CHKSUM = file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f
+PR = r0
+
+SRC_URI =
http://pkgs.fedoraproject.org/repo/pkgs/zisofs-tools/zisofs-tools-${PV}.tar.bz2/2d0ed8c9a1f60b45f949b136f9be1f6c/zisofs-tools-${PV}.tar.bz2;
+
+SRC_URI[md5sum] = 2d0ed8c9a1f60b45f949b136f9be1f6c
+SRC_URI[sha256sum] =
ae4e53e4914934d41660248fb59d3c8761f1f1fd180d5ec993c17ddb3afd04f3
+
+inherit native
+
+STAGE_TEMP = ${WORKDIR}/image-temp
+
+do_install() {
+ install -d ${STAGE_TEMP}
+ make install INSTALLROOT=${STAGE_TEMP}
+
+ install -d ${D}${bindir}/
+ install ${STAGE_TEMP}/usr/bin/* ${D}${bindir}/
+}
--
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] bootimage.bbclass, zisofs-tools-native: add ability to compress ISO images
On 09/11/2013 06:15 PM, Khem Raj wrote:
On Wednesday, September 11, 2013, Jason Wessel jason.wes...@windriver.com
mailto:jason.wes...@windriver.com wrote:
The mkzftree is needed to allow ISO images to be compressed with
minimal runtime overhead. Below is an example of the savings on a
core-image-minimal.
Before ls -l:
24117248 core-image-minimal-qemux86-64.iso
Using the mkzftree ls -l:
16777216 core-image-minimal-qemux86-64.iso
Signed-off-by: Jason Wessel jason.wes...@windriver.com
mailto:jason.wes...@windriver.com
---
meta/classes/bootimg.bbclass | 21 ++--
.../zisofs-tools/zisofs-tools-native_1.0.8.bb
http://zisofs-tools-native_1.0.8.bb | 26
2 files changed, 45 insertions(+), 2 deletions(-)
create mode 100644
meta/recipes-devtools/zisofs-tools/zisofs-tools-native_1.0.8.bb
http://zisofs-tools-native_1.0.8.bb
diff --git a/meta/classes/bootimg.bbclass b/meta/classes/bootimg.bbclass
index 90a241d..b312e0d 100644
--- a/meta/classes/bootimg.bbclass
+++ b/meta/classes/bootimg.bbclass
@@ -19,19 +19,23 @@
# External variables (also used by syslinux.bbclass)
# ${INITRD} - indicates a filesystem image to use as an initrd (optional)
+# ${COMPRESSISO}
# ${NOISO} - skip building the ISO image if set to 1
# ${NOHDD} - skip building the HDD image if set to 1
# ${ROOTFS} - indicates a filesystem image to include as the root
filesystem (optional)
+COMPRESSISO ?=
do_bootimg[depends] += dosfstools-native:do_populate_sysroot \
mtools-native:do_populate_sysroot \
-cdrtools-native:do_populate_sysroot
+cdrtools-native:do_populate_sysroot \
+
${@oe.utils.ifelse(d.getVar('COMPRESSISO'),'zisofs-tools-native:do_populate_sysroot','')}
PACKAGES =
EXCLUDE_FROM_WORLD = 1
HDDDIR = ${S}/hddimg
ISODIR = ${S}/iso
+COMPACT_ISODIR = ${S}/iso.z
BOOTIMG_VOLUME_ID ?= boot
BOOTIMG_EXTRA_SPACE ?= 512
@@ -92,10 +96,23 @@ build_iso() {
grubefi_iso_populate
fi
+ if [ ${COMPRESSISO} = 1 ] ; then
+ # create compact directory, compress iso
+ mkdir -p ${COMPACT_ISODIR}
+ mkzftree -z 9 -p 4 -F ${ISODIR}/rootfs.img
${COMPACT_ISODIR}/rootfs.img
+
+ # move compact iso to iso, then remove compact directory
+ mv ${COMPACT_ISODIR}/rootfs.img ${ISODIR}/rootfs.img
+ rm -Rf ${COMPACT_ISODIR}
+ mkisofs_opts=-r
+ else
+ mkisofs_opts=-R -z -D -l
+ fi
+
if [ ${PCBIOS} = 1 ]; then
mkisofs -V ${BOOTIMG_VOLUME_ID} \
-o ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.iso \
- -b ${ISO_BOOTIMG} -c ${ISO_BOOTCAT} -r \
+ -b ${ISO_BOOTIMG} -c ${ISO_BOOTCAT} $mkisofs_opts \
${MKISOFS_OPTIONS} ${ISODIR}
else
bbnote EFI-only ISO images are untested, please provide
feedback.
diff --git a/meta/recipes-devtools/zisofs-tools/zisofs-tools-native_1.0.8.bb
http://zisofs-tools-native_1.0.8.bb
b/meta/recipes-devtools/zisofs-tools/zisofs-tools-native_1.0.8.bb
http://zisofs-tools-native_1.0.8.bb
new file mode 100644
index 000..b590854
--- /dev/null
+++ b/meta/recipes-devtools/zisofs-tools/zisofs-tools-native_1.0.8.bb
http://zisofs-tools-native_1.0.8.bb
@@ -0,0 +1,26 @@
+# zisofs-tools-native OE build file
+# Copyright (C) 1989, 1991 Free Software Foundation, Inc.
+SUMMARY = A set of tools for iso file compression
+DESCRIPTION = A set of tools for iso file compression
+HOMEPAGE = http://http://freecode.com/projects/zisofs-tools;
+SECTION = console/utils
+LICENSE = GPLv2
+LIC_FILES_CHKSUM = file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f
+PR = r0
+
+SRC_URI =
http://pkgs.fedoraproject.org/repo/pkgs/zisofs-tools/zisofs-tools-${PV}.tar.bz2/2d0ed8c9a1f60b45f949b136f9be1f6c/zisofs-tools-${PV}.tar.bz2
http://pkgs.fedoraproject.org/repo/pkgs/zisofs-tools/zisofs-tools-$%7BPV%7D.tar.bz2/2d0ed8c9a1f60b45f949b136f9be1f6c/zisofs-tools-$%7BPV%7D.tar.bz2
+
+SRC_URI[md5sum] = 2d0ed8c9a1f60b45f949b136f9be1f6c
+SRC_URI[sha256sum] =
ae4e53e4914934d41660248fb59d3c8761f1f1fd180d5ec993c17ddb3afd04f3
+
+inherit native
+
+STAGE_TEMP = ${WORKDIR}/image-temp
+
+do_install() {
+ install -d ${STAGE_TEMP}
+ make install INSTALLROOT=${STAGE_TEMP}
why cant INSTALLROOT be pointing to ${D}
Not being the originator of this patch, I took a look and it is all a game to
not copy the man page and ensure that ${bindir} is used.
I'll send a v2 shortly and catch this kind of problem in the future.
Thanks,
Jason.
+
+ install -d ${D}${bindir}/
+ install ${STAGE_TEMP}/usr/bin/* ${D}${bindir}/
+}
--
1.7.9.5
___
Openembedded-core mailing list
[OE-core] [PATCH v2] bootimage.bbclass, zisofs-tools-native: add ability to compress ISO images
The mkzftree is needed to allow ISO images to be compressed with
minimal runtime overhead. Below is an example of the savings on a
core-image-minimal.
Before ls -l:
24117248 core-image-minimal-qemux86-64.iso
Using the mkzftree ls -l:
16777216 core-image-minimal-qemux86-64.iso
Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
meta/classes/bootimg.bbclass | 21 ++--
.../zisofs-tools/zisofs-tools-native_1.0.8.bb | 21
2 files changed, 40 insertions(+), 2 deletions(-)
create mode 100644
meta/recipes-devtools/zisofs-tools/zisofs-tools-native_1.0.8.bb
diff --git a/meta/classes/bootimg.bbclass b/meta/classes/bootimg.bbclass
index 90a241d..b312e0d 100644
--- a/meta/classes/bootimg.bbclass
+++ b/meta/classes/bootimg.bbclass
@@ -19,19 +19,23 @@
# External variables (also used by syslinux.bbclass)
# ${INITRD} - indicates a filesystem image to use as an initrd (optional)
+# ${COMPRESSISO}
# ${NOISO} - skip building the ISO image if set to 1
# ${NOHDD} - skip building the HDD image if set to 1
# ${ROOTFS} - indicates a filesystem image to include as the root filesystem
(optional)
+COMPRESSISO ?=
do_bootimg[depends] += dosfstools-native:do_populate_sysroot \
mtools-native:do_populate_sysroot \
-cdrtools-native:do_populate_sysroot
+cdrtools-native:do_populate_sysroot \
+
${@oe.utils.ifelse(d.getVar('COMPRESSISO'),'zisofs-tools-native:do_populate_sysroot','')}
PACKAGES =
EXCLUDE_FROM_WORLD = 1
HDDDIR = ${S}/hddimg
ISODIR = ${S}/iso
+COMPACT_ISODIR = ${S}/iso.z
BOOTIMG_VOLUME_ID ?= boot
BOOTIMG_EXTRA_SPACE ?= 512
@@ -92,10 +96,23 @@ build_iso() {
grubefi_iso_populate
fi
+ if [ ${COMPRESSISO} = 1 ] ; then
+ # create compact directory, compress iso
+ mkdir -p ${COMPACT_ISODIR}
+ mkzftree -z 9 -p 4 -F ${ISODIR}/rootfs.img
${COMPACT_ISODIR}/rootfs.img
+
+ # move compact iso to iso, then remove compact directory
+ mv ${COMPACT_ISODIR}/rootfs.img ${ISODIR}/rootfs.img
+ rm -Rf ${COMPACT_ISODIR}
+ mkisofs_opts=-r
+ else
+ mkisofs_opts=-R -z -D -l
+ fi
+
if [ ${PCBIOS} = 1 ]; then
mkisofs -V ${BOOTIMG_VOLUME_ID} \
-o ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.iso \
- -b ${ISO_BOOTIMG} -c ${ISO_BOOTCAT} -r \
+ -b ${ISO_BOOTIMG} -c ${ISO_BOOTCAT} $mkisofs_opts \
${MKISOFS_OPTIONS} ${ISODIR}
else
bbnote EFI-only ISO images are untested, please provide
feedback.
diff --git a/meta/recipes-devtools/zisofs-tools/zisofs-tools-native_1.0.8.bb
b/meta/recipes-devtools/zisofs-tools/zisofs-tools-native_1.0.8.bb
new file mode 100644
index 000..39360a8
--- /dev/null
+++ b/meta/recipes-devtools/zisofs-tools/zisofs-tools-native_1.0.8.bb
@@ -0,0 +1,21 @@
+# zisofs-tools-native OE build file
+# Copyright (C) 1989, 1991 Free Software Foundation, Inc.
+SUMMARY = A set of tools for iso file compression
+DESCRIPTION = A set of tools for iso file compression
+HOMEPAGE = http://http://freecode.com/projects/zisofs-tools;
+SECTION = console/utils
+LICENSE = GPLv2
+LIC_FILES_CHKSUM = file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f
+PR = r0
+
+SRC_URI =
http://pkgs.fedoraproject.org/repo/pkgs/zisofs-tools/zisofs-tools-${PV}.tar.bz2/2d0ed8c9a1f60b45f949b136f9be1f6c/zisofs-tools-${PV}.tar.bz2;
+
+SRC_URI[md5sum] = 2d0ed8c9a1f60b45f949b136f9be1f6c
+SRC_URI[sha256sum] =
ae4e53e4914934d41660248fb59d3c8761f1f1fd180d5ec993c17ddb3afd04f3
+
+inherit native
+
+do_install() {
+ install -d ${D}${bindir}
+ make install INSTALLROOT=${D} bindir=${bindir}
+}
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [v2 PATCH] kernel.bbclass, image.bbclass: Implement kernel INITRAMFS dependency and bundling
On 08/23/2013 01:16 AM, Khem Raj wrote: On Thu, Aug 22, 2013 at 4:04 PM, Jason Wessel jason.wes...@windriver.com wrote: This patch aims to fix the following two cases for the INITRAMFS generation. 1) Allow an image recipe to specify a paired INITRAMFS recipe such as core-image-minimal-initramfs. This allows building a base image which always generates the needed initramfs image in one step 2) Allow building a single binary which contains a kernel and the initramfs. I think this could be a bit simpler. Have a full kernel image recipe ( kernel + initramfs) separate. It fits into the equation nicely. The final image can bundle initramfs which has modules from practically same kernel build is staged step 1 of kernel build which automatically happens today for any image build. The changes I put together are work around the circular dependency problem. Staging and using another recipe is certainly an option. What I really wanted to do was have just another image type not unlike cpio, ext3, etc... But this was not possible because there was no way to get back to the point that the kernel could be re-linked and make the call to the kernel methods and get the context correct. I had tried using the internal method for exec_task from the image recipe context but there appeared to be no direct way to get this to work. The new recipe for kernel+initramfs requires the existing kernel recipes and tweaks the .config to enable INITRAMFS_IMAGE You can share the sources for both stages where kernel is built like gcc is putting the sources under work-shared and building all gcc recipes out of this location. Ideally we could use the sysroot to regenerate the combined image, but this was not low hanging fruit. If we came up with a way to generate the combined kernel+initramfs image directly from the sysroot this could easily be controlled by just having it as an IMAGE_FEATURE as opposed to making distinct image types. Jason. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [v2 PATCH] kernel.bbclass, image.bbclass: Implement kernel INITRAMFS dependency and bundling
This patch aims to fix the following two cases for the INITRAMFS generation.
1) Allow an image recipe to specify a paired INITRAMFS recipe such
as core-image-minimal-initramfs. This allows building a base
image which always generates the needed initramfs image in one step
2) Allow building a single binary which contains a kernel and
the initramfs.
A key requirement of the initramfs is to be able to add kernel
modules. The current implementation of the INITRAMFS_IMAGE variable
has a circular dependency when using kernel modules in the initramfs
image.bb file that is caused by kernel.bbclass trying to build the
initramfs before the kernel's do_install rule.
The solution for this problem is to have the kernel's
do_bundle_initramfs_image task depend on the do_rootfs from the
INITRAMFS_IMAGE and not some intermediate point. The image.bbclass
will also sets up dependencies to make the initramfs creation task run
last.
The code to bundle the kernel and initramfs together has been added.
At a high level, all it is doing is invoking a second compilation of
the kernel but changing the value of CONFIG_INITRAMFS_SOURCE to point
to the generated initramfs from the image recipe.
[YOCTO #4072]
Signed-off-by: Jason Wessel jason.wes...@windriver.com
Acked-by: Bruce Ashfield bruce.ashfi...@windriver.com
---
meta/classes/image.bbclass | 12 ++
meta/classes/kernel.bbclass | 96 +--
meta/conf/local.conf.sample | 20 +
3 files changed, 116 insertions(+), 12 deletions(-)
diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index 909702a..23967ec 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -130,6 +130,10 @@ python () {
d.setVar('MULTILIB_VENDORS', ml_vendor_list)
check_image_features(d)
+initramfs_image = d.getVar('INITRAMFS_IMAGE', True) or
+if initramfs_image != :
+d.appendVarFlag('do_build', 'depends', %s:do_bundle_initramfs %
d.getVar('PN', True))
+d.appendVarFlag('do_bundle_initramfs', 'depends', %s:do_rootfs %
initramfs_image)
}
#
@@ -629,3 +633,11 @@ do_package_write_deb[noexec] = 1
do_package_write_rpm[noexec] = 1
addtask rootfs before do_build
+# Allow the kernel to be repacked with the initramfs and boot image file as a
single file
+do_bundle_initramfs[depends] += virtual/kernel:do_bundle_initramfs
+do_bundle_initramfs[nostamp] = 1
+do_bundle_initramfs[noexec] = 1
+do_bundle_initramfs () {
+ :
+}
+addtask bundle_initramfs after do_rootfs
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index e039dfc..8cf66ce 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -9,6 +9,7 @@ INHIBIT_DEFAULT_DEPS = 1
KERNEL_IMAGETYPE ?= zImage
INITRAMFS_IMAGE ?=
INITRAMFS_TASK ?=
+INITRAMFS_IMAGE_BUNDLE ?=
python __anonymous () {
kerneltype = d.getVar('KERNEL_IMAGETYPE', True) or ''
@@ -19,7 +20,15 @@ python __anonymous () {
image = d.getVar('INITRAMFS_IMAGE', True)
if image:
-d.setVar('INITRAMFS_TASK', '${INITRAMFS_IMAGE}:do_rootfs')
+d.appendVarFlag('do_bundle_initramfs', 'depends', '
${INITRAMFS_IMAGE}:do_rootfs')
+
+# NOTE: setting INITRAMFS_TASK is for backward compatibility
+# The preferred method is to set INITRAMFS_IMAGE, because
+# this INITRAMFS_TASK has circular dependency problems
+# if the initramfs requires kernel modules
+image_task = d.getVar('INITRAMFS_TASK', True)
+if image_task:
+d.appendVarFlag('do_configure', 'depends', ' ${INITRAMFS_TASK}')
}
inherit kernel-arch deploy
@@ -72,9 +81,82 @@ KERNEL_SRC_PATH = /usr/src/kernel
KERNEL_IMAGETYPE_FOR_MAKE = ${@(lambda s: s[:-3] if s[-3:] == .gz else
s)(d.getVar('KERNEL_IMAGETYPE', True))}
+copy_initramfs() {
+ echo Copying initramfs into ./usr ...
+ # Find and use the first initramfs image archive type we find
+ rm -f ${B}/usr/${INITRAMFS_IMAGE}-${MACHINE}.cpio
+ for img in cpio.gz cpio.lzo cpio.lzma cpio.xz; do
+ if [ -e
${DEPLOY_DIR_IMAGE}/${INITRAMFS_IMAGE}-${MACHINE}.$img ]; then
+ cp
${DEPLOY_DIR_IMAGE}/${INITRAMFS_IMAGE}-${MACHINE}.$img ${B}/usr/.
+ case $img in
+ *gz)
+ echo gzip decompressing image
+ gunzip -f
${B}/usr/${INITRAMFS_IMAGE}-${MACHINE}.$img
+ break
+ ;;
+ *lzo)
+ echo lzo decompressing image
+ lzop -df
${B}/usr/${INITRAMFS_IMAGE}-${MACHINE}.$img
+ break
+ ;;
+ *lzma)
+ echo lzma decompressing image
+ lzmash -df
${B}/usr/${INITRAMFS_IMAGE}-${MACHINE}.$img
[OE-core] [PATCH] kernel.bbclass, image.bbclass: Implement kernel INITRAMFS dependency and bundling
This patch aims to fix the following two cases for the INITRAMFS generation.
1) Allow an image recipe to specify a paired INITRAMFS recipe such
as core-image-minimal-initramfs. This allows building a base
image which always generates the needed initramfs image in one step
2) Allow building a single binary which contains a kernel and
the initramfs.
A key requirement of the initramfs is to be able to add kernel
modules. The current implementation of the INITRAMFS_IMAGE variable
has a circular dependency when using kernel modules in the initramfs
image.bb file that is caused by kernel.bbclass trying to build the
initramfs before the kernel's do_install rule.
The solution for this problem is to have the kernel's
do_bundle_initramfs_image task depend on the do_rootfs from the
INITRAMFS_IMAGE and not some intermediate point. The image.bbclass
will also sets up dependencies to make the initramfs creation task run
last.
The code to bundle the kernel and initramfs together has been added.
At a high level, all it is doing is invoking a second compilation of
the kernel but changing the value of CONFIG_INITRAMFS_SOURCE to point
to the generated initramfs from the image recipe.
Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
meta/classes/image.bbclass | 12 ++
meta/classes/kernel.bbclass | 96 +--
meta/conf/local.conf.sample | 20 +
3 files changed, 116 insertions(+), 12 deletions(-)
diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index 116bd22..78c25db 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -140,6 +140,10 @@ python () {
d.setVar('MULTILIB_VENDORS', ml_vendor_list)
check_image_features(d)
+initramfs_image = d.getVar('INITRAMFS_IMAGE', True) or
+if initramfs_image != :
+d.appendVarFlag('do_build', 'depends', %s:do_bundle_initramfs %
d.getVar('PN', True))
+d.appendVarFlag('do_bundle_initramfs', 'depends', %s:do_rootfs %
initramfs_image)
}
#
@@ -614,3 +618,11 @@ do_package_write_deb[noexec] = 1
do_package_write_rpm[noexec] = 1
addtask rootfs before do_build
+# Allow the kernel to be repacked with the initramfs and boot image file as a
single file
+do_bundle_initramfs[depends] += virtual/kernel:do_bundle_initramfs
+do_bundle_initramfs[nostamp] = 1
+do_bundle_initramfs[noexec] = 1
+do_bundle_initramfs () {
+ :
+}
+addtask bundle_initramfs after do_rootfs
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index e039dfc..8cf66ce 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -9,6 +9,7 @@ INHIBIT_DEFAULT_DEPS = 1
KERNEL_IMAGETYPE ?= zImage
INITRAMFS_IMAGE ?=
INITRAMFS_TASK ?=
+INITRAMFS_IMAGE_BUNDLE ?=
python __anonymous () {
kerneltype = d.getVar('KERNEL_IMAGETYPE', True) or ''
@@ -19,7 +20,15 @@ python __anonymous () {
image = d.getVar('INITRAMFS_IMAGE', True)
if image:
-d.setVar('INITRAMFS_TASK', '${INITRAMFS_IMAGE}:do_rootfs')
+d.appendVarFlag('do_bundle_initramfs', 'depends', '
${INITRAMFS_IMAGE}:do_rootfs')
+
+# NOTE: setting INITRAMFS_TASK is for backward compatibility
+# The preferred method is to set INITRAMFS_IMAGE, because
+# this INITRAMFS_TASK has circular dependency problems
+# if the initramfs requires kernel modules
+image_task = d.getVar('INITRAMFS_TASK', True)
+if image_task:
+d.appendVarFlag('do_configure', 'depends', ' ${INITRAMFS_TASK}')
}
inherit kernel-arch deploy
@@ -72,9 +81,82 @@ KERNEL_SRC_PATH = /usr/src/kernel
KERNEL_IMAGETYPE_FOR_MAKE = ${@(lambda s: s[:-3] if s[-3:] == .gz else
s)(d.getVar('KERNEL_IMAGETYPE', True))}
+copy_initramfs() {
+ echo Copying initramfs into ./usr ...
+ # Find and use the first initramfs image archive type we find
+ rm -f ${B}/usr/${INITRAMFS_IMAGE}-${MACHINE}.cpio
+ for img in cpio.gz cpio.lzo cpio.lzma cpio.xz; do
+ if [ -e
${DEPLOY_DIR_IMAGE}/${INITRAMFS_IMAGE}-${MACHINE}.$img ]; then
+ cp
${DEPLOY_DIR_IMAGE}/${INITRAMFS_IMAGE}-${MACHINE}.$img ${B}/usr/.
+ case $img in
+ *gz)
+ echo gzip decompressing image
+ gunzip -f
${B}/usr/${INITRAMFS_IMAGE}-${MACHINE}.$img
+ break
+ ;;
+ *lzo)
+ echo lzo decompressing image
+ lzop -df
${B}/usr/${INITRAMFS_IMAGE}-${MACHINE}.$img
+ break
+ ;;
+ *lzma)
+ echo lzma decompressing image
+ lzmash -df
${B}/usr/${INITRAMFS_IMAGE}-${MACHINE}.$img
+ break
Re: [OE-core] [PATCH] libpcre, ncurses: Fix problems expanding the IMAGE_INSTALL package groups
On 04/23/2013 12:00 PM, Richard Purdie wrote:
On Tue, 2013-04-23 at 11:08 -0500, Jason Wessel wrote:
The ncurses and libpcre packages were generating the following errors
as a result of not specifing the PACKAGES_DYNAMIC correctly. These
errors only appear when using the IMAGE_INSTALL list that has been
expanded by the hob or from the pkgdata.
ERROR: Nothing RPROVIDES 'ncurses-libtinfo'
ERROR: Nothing RPROVIDES 'libpcreposix'
Signed-off-by: Jason Wessel jason.wes...@windriver.com
Signed-off-by: Mark Hatle mark.ha...@windriver.com
---
meta/recipes-core/ncurses/ncurses.inc|2 ++
meta/recipes-support/libpcre/libpcre_8.32.bb |2 ++
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/meta/recipes-core/ncurses/ncurses.inc
b/meta/recipes-core/ncurses/ncurses.inc
index bcb9c94..78ff153 100644
--- a/meta/recipes-core/ncurses/ncurses.inc
+++ b/meta/recipes-core/ncurses/ncurses.inc
@@ -42,6 +42,8 @@ EXCONFIG_ARGS_virtclass-nativesdk = \
--with-chtype='long' \
--with-mmask-t='long'
+PACKAGES_DYNAMIC = ^${PN}-.*
+
# Fall back to the host termcap / terminfo for -nativesdk and -native
# The reality is a work around for strange problems with things like
# bitbake -c menuconfig busybox where it cannot find the terminfo
This makes sense since its doing dynamic package splitting.
diff --git a/meta/recipes-support/libpcre/libpcre_8.32.bb
b/meta/recipes-support/libpcre/libpcre_8.32.bb
index 4d17741..71cc119 100644
--- a/meta/recipes-support/libpcre/libpcre_8.32.bb
+++ b/meta/recipes-support/libpcre/libpcre_8.32.bb
@@ -26,6 +26,8 @@ inherit autotools binconfig
PARALLEL_MAKE =
+PACKAGES_DYNAMIC = ^${PN}.*
+
EXTRA_OECONF = \
--enable-newline-is-lf \
--enable-rebuild-chartables \
However this does not. libpcreposix is clearly listed in PACKAGES. Was
this based on an older recipe and can someone check this is needed on
master?
I'll double check on this and submit a new patch. This was originally against
the libpcre 8.21 from YP 1.2.
Jason.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCHv3] oe.terminal: add tmux classes
On 04/04/2013 07:44 PM, Christopher Larson wrote:
From: Christopher Larson chris_lar...@mentor.com
This adds two new Terminal classes. It's separated into two, so that opening
a split inside a tmux window is preferred to the other terminal types, but
opening a tmux session is prioritized only slightly higher than screen.
- tmuxrunning: Open a new pane in the current running tmux window. Requires
that the TMUX variable be added to the env whitelist to use it.
- tmux: Open a new tmux session
Signed-off-by: Christopher Larson chris_lar...@mentor.com
---
meta/lib/oe/terminal.py | 38 ++
1 file changed, 38 insertions(+)
diff --git a/meta/lib/oe/terminal.py b/meta/lib/oe/terminal.py
index 2e23d59..e52863f 100644
--- a/meta/lib/oe/terminal.py
+++ b/meta/lib/oe/terminal.py
@@ -142,6 +142,44 @@ class TmuxNewSession(Terminal):
else:
logger.warn(msg)
+class TmuxRunning(Terminal):
+Open a new pane in the current running tmux window
+name = 'tmux-running'
+command = 'tmux split-window {command}'
+priority = 2.75
+
+def __init__(self, sh_cmd, title=None, env=None, d=None):
+if not bb.utils.which(os.getenv('PATH'), 'tmux'):
+raise UnsupportedTerminal('tmux is not installed')
+
+if not os.getenv('TMUX'):
+raise UnsupportedTerminal('tmux is not running')
+
+Terminal.__init__(self, sh_cmd, title, env, d)
When we chatted yesterday I didn't fully understand how the Tmux Running piece
worked. Now I get it, you run tmux and then start a build with in that
session and just join back to it when the TMUX var is set because that is how
TMUX does internal communications setup. I have to admit that is pretty slick.
:-)
It seems to me we can just fold these two classes together and drive it off the
TMUX variable. This way we can just have one OE TERMINAL type, and if you
don't want the behavior to engage of the split you just unset TMUX before you
build. I believe that this covers all the cases you care about, and would
allow for the simplistic case I care about where I just set OE_TERMINAL=tmux to
work for both cases. I would recommend we just patch up the bitbake.conf BBHASH
pieces all in one shot with this patch so their is nothing special anyone has
to do to make use of this.
Would you be ok with that?
Further work that I'll probably consider doing if no one else does it first is
to add tmux-native so we always have it as the fall back for getting to patch
failures and such on a remote build server.
Cheers,
Jason.
+
+class Tmux(Terminal):
+Start a new tmux session and window
+command = 'tmux new -d -s devshell -n devshell {command}'
+priority = 0.75
+
+def __init__(self, sh_cmd, title=None, env=None, d=None):
+if not bb.utils.which(os.getenv('PATH'), 'tmux'):
+raise UnsupportedTerminal('tmux is not installed')
+
+# TODO: consider using a 'devshell' session shared amongst all
+# devshells, if it's already there, add a new window to it.
+window_name = 'devshell-%i' % os.getpid()
+
+self.command = 'tmux new -d -s {0} -n {0}
{{command}}'.format(window_name)
+Terminal.__init__(self, sh_cmd, title, env, d)
+
+attach_cmd = 'tmux att -t {0}'.format(window_name)
+msg = 'Tmux started. Please connect in another terminal with `tmux
att -t {0}`'.format(window_name)
+if d:
+bb.event.fire(bb.event.LogExecTTY(msg, attach_cmd, 0.5, 10), d)
+else:
+logger.warn(msg)
+
class Custom(Terminal):
command = 'false' # This is a placeholder
priority = 3
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCHv3] oe.terminal: add tmux classes
On 04/05/2013 09:20 AM, Chris Larson wrote:
On Fri, Apr 5, 2013 at 6:55 AM, Jason Wessel jason.wes...@windriver.com
mailto:jason.wes...@windriver.com wrote:
On 04/04/2013 07:44 PM, Christopher Larson wrote:
From: Christopher Larson chris_lar...@mentor.com
mailto:chris_lar...@mentor.com
This adds two new Terminal classes. It's separated into two, so that
opening
a split inside a tmux window is preferred to the other terminal types,
but
opening a tmux session is prioritized only slightly higher than screen.
- tmuxrunning: Open a new pane in the current running tmux window.
Requires
that the TMUX variable be added to the env whitelist to use it.
- tmux: Open a new tmux session
Signed-off-by: Christopher Larson chris_lar...@mentor.com
mailto:chris_lar...@mentor.com
---
meta/lib/oe/terminal.py | 38 ++
1 file changed, 38 insertions(+)
diff --git a/meta/lib/oe/terminal.py b/meta/lib/oe/terminal.py
index 2e23d59..e52863f 100644
--- a/meta/lib/oe/terminal.py
+++ b/meta/lib/oe/terminal.py
@@ -142,6 +142,44 @@ class TmuxNewSession(Terminal):
else:
logger.warn(msg)
+class TmuxRunning(Terminal):
+Open a new pane in the current running tmux window
+name = 'tmux-running'
+command = 'tmux split-window {command}'
+priority = 2.75
+
+def __init__(self, sh_cmd, title=None, env=None, d=None):
+if not bb.utils.which(os.getenv('PATH'), 'tmux'):
+raise UnsupportedTerminal('tmux is not installed')
+
+if not os.getenv('TMUX'):
+raise UnsupportedTerminal('tmux is not running')
+
+Terminal.__init__(self, sh_cmd, title, env, d)
When we chatted yesterday I didn't fully understand how the Tmux Running
piece worked. Now I get it, you run tmux and then start a build with in
that session and just join back to it when the TMUX var is set because that
is how TMUX does internal communications setup. I have to admit that is
pretty slick. :-)
It seems to me we can just fold these two classes together and drive it
off the TMUX variable. This way we can just have one OE TERMINAL type, and
if you don't want the behavior to engage of the split you just unset TMUX
before you build. I believe that this covers all the cases you care about,
and would allow for the simplistic case I care about where I just set
OE_TERMINAL=tmux to work for both cases. I would recommend we just patch up
the bitbake.conf BBHASH pieces all in one shot with this patch so their is
nothing special anyone has to do to make use of this.
Would you be ok with that?
Further work that I'll probably consider doing if no one else does it
first is to add tmux-native so we always have it as the fall back for getting
to patch failures and such on a remote build server.
The problem with combining them is they'd be stuck at the same priority,
which makes 'auto' less useful. In the case where DISPLAY and TMUX are both
set, I think it makes more sense to prefer to interact with the running tmux
session rather than spawning a new xterm, yet spawning a new tmux session
should be kept at the same priority as screen to meet user expectations.
A decent compromise, to make the explicit OE_TERMINAL=tmux case more useful,
would be to merge the tmuxrunning bits into tmux, but still keep the
independent tmuxrunning class for the 'auto' case. Thoughts on that?
Based on how the auto list processing works your latest proposed solution seems
like the most reasonable choice.
Thanks,
Jason.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] ncurses, busybox, cml1.bbclass: Fix menuconfig display corruption
Previously there was a change to the ncurses compile to make it more
like the typical way it was compiled on a host system. This fixed a
whole class of host machines, but masked the real underlying problem
with the display corruption issues and menuconfig.
The corner case that led to the discovery that the wrong curses.h file
was getting used was when there was no curses libraries at all on one
of the development hosts. What had happened before was that
/usr/include/curses.h on the host system had to match closely enough
to the curses.h in the sysroot and then linking against the sysroot
version of curses.so was ok (meaning no display corruption). But on
some systems with ncurses.h vs curses.h such as SuSE hosts, there were
still issues.
If we fix the root of the problem and force the mconf and lxdialog to
use the correct headers and libraries from the sysroot there is no
further issues and the menuconfig target works properly. It also
means we can back out the custom compilation flags to the ncurses
recipe because they are no longer needed.
For the kernel part of the menuconfig / nconfig changes it will be
merged separately and this is all based on:
https://lkml.org/lkml/2013/3/3/103
Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
meta/classes/cml1.bbclass |5 +-
.../busybox-1.20.2/busybox-cross-menuconfig.patch | 69
meta/recipes-core/busybox/busybox_1.20.2.bb|3 +-
meta/recipes-core/ncurses/ncurses.inc | 14
4 files changed, 74 insertions(+), 17 deletions(-)
create mode 100644
meta/recipes-core/busybox/busybox-1.20.2/busybox-cross-menuconfig.patch
diff --git a/meta/classes/cml1.bbclass b/meta/classes/cml1.bbclass
index bb95639..94d5582 100644
--- a/meta/classes/cml1.bbclass
+++ b/meta/classes/cml1.bbclass
@@ -9,10 +9,11 @@ addtask configure after do_unpack do_patch before do_compile
inherit terminal
-OE_TERMINAL_EXPORTS += HOST_EXTRACFLAGS HOSTLDFLAGS HOST_LOADLIBES TERMINFO
+OE_TERMINAL_EXPORTS += HOST_EXTRACFLAGS HOSTLDFLAGS CROSS_CURSES_LIB
CROSS_CURSES_INC TERMINFO
HOST_EXTRACFLAGS = ${BUILD_CFLAGS} ${BUILD_LDFLAGS}
HOSTLDFLAGS = ${BUILD_LDFLAGS}
-HOST_LOADLIBES = -lncurses
+CROSS_CURSES_LIB = -lncurses -ltinfo
+CROSS_CURSES_INC = '-DCURSES_LOC=curses.h'
TERMINFO = ${STAGING_DATADIR_NATIVE}/terminfo
python do_menuconfig() {
diff --git
a/meta/recipes-core/busybox/busybox-1.20.2/busybox-cross-menuconfig.patch
b/meta/recipes-core/busybox/busybox-1.20.2/busybox-cross-menuconfig.patch
new file mode 100644
index 000..c0784d5
--- /dev/null
+++ b/meta/recipes-core/busybox/busybox-1.20.2/busybox-cross-menuconfig.patch
@@ -0,0 +1,69 @@
+From: Jason Wessel jason.wes...@windriver.com
+Date: Sun, 3 Mar 2013 12:31:40 -0600
+Subject: [PATCH] menuconfig,check-lxdiaglog.sh: Allow specification of ncurses
location
+
+[ based on: https://lkml.org/lkml/2013/3/3/103 ]
+
+This patch syncs up with the way the menuconfig ncurses / curses
+is detected and the HOST_EXTRACFLAGS works in the Linux kernel
+and it allows the menuconfig to work with a sysroot version
+of the curses libraries.
+
+---
+
+In some cross build environments such as the Yocto Project build
+environment it provides an ncurses library that is compiled
+differently than the host's version. This causes display corruption
+problems when the host's curses includes are used instead of the
+includes from the provided compiler are overridden. There is a second
+case where there is no curses libraries at all on the host system and
+menuconfig will just fail entirely.
+
+The solution is simply to allow an override variable in
+check-lxdialog.sh for environments such as the Yocto Project. Adding
+a CROSS_CURSES_LIB and CROSS_CURSES_INC solves the issue and allowing
+compiling and linking against the right headers and libraries.
+
+Signed-off-by: Jason Wessel jason.wes...@windriver.com
+cc: Michal Marek mma...@suse.cz
+cc: linux-kbu...@vger.kernel.org
+---
+ scripts/kconfig/lxdialog/Makefile |2 +-
+ scripts/kconfig/lxdialog/check-lxdialog.sh |8
+ 2 files changed, 9 insertions(+), 1 deletion(-)
+
+--- a/scripts/kconfig/lxdialog/check-lxdialog.sh
b/scripts/kconfig/lxdialog/check-lxdialog.sh
+@@ -4,6 +4,10 @@
+ # What library to link
+ ldflags()
+ {
++ if [ x$CROSS_CURSES_LIB != x ]; then
++ echo $CROSS_CURSES_LIB
++ exit
++ fi
+ for ext in so a dylib ; do
+ for lib in ncursesw ncurses curses ; do
+ $cc -print-file-name=lib${lib}.${ext} | grep -q /
+@@ -19,6 +23,10 @@ ldflags()
+ # Where is ncurses.h?
+ ccflags()
+ {
++ if [ x$CROSS_CURSES_INC != x ]; then
++ echo $CROSS_CURSES_INC
++ exit
++ fi
+ if [ -f /usr/include/ncursesw/ncurses.h ]; then
+ echo '-I/usr/include/ncursesw -DCURSES_LOC=ncurses.h'
+ elif [ -f /usr/include/ncursesw/curses.h ]; then
+--- a/scripts/kconfig
Re: [OE-core] [PATCH] ncurses, busybox, cml1.bbclass: Fix menuconfig display corruption
On 03/04/2013 03:21 PM, Jason Wessel wrote: Previously there was a change to the ncurses compile to make it more like the typical way it was compiled on a host system. This fixed a whole class of host machines, but masked the real underlying problem with the display corruption issues and menuconfig. The corner case that led to the discovery that the wrong curses.h file was getting used was when there was no curses libraries at all on one of the development hosts. What had happened before was that /usr/include/curses.h on the host system had to match closely enough to the curses.h in the sysroot and then linking against the sysroot version of curses.so was ok (meaning no display corruption). But on some systems with ncurses.h vs curses.h such as SuSE hosts, there were still issues. If we fix the root of the problem and force the mconf and lxdialog to use the correct headers and libraries from the sysroot there is no further issues and the menuconfig target works properly. It also means we can back out the custom compilation flags to the ncurses recipe because they are no longer needed. For the kernel part of the menuconfig / nconfig changes it will be merged separately and this is all based on: https://lkml.org/lkml/2013/3/3/103 Probably best to hold off merging this until we see if the kernel patch is accepted upstream. This is more of an RFC and to raise further awareness of the problem and the fact that we have a solution now that the root cause is well understood on the menuconfig corruption. Cheers, Jason. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] syslinux.bbclass: Add a default serial console option and real boot menu support
On 02/27/2013 07:52 PM, Saul Wold wrote:
On 02/26/2013 06:04 PM, Jason Wessel wrote:
syslinux_iso_populate() {
syslinux_populate ${ISODIR} ${ISOLINUXDIR} isolinux.cfg
install -m 0644 ${STAGING_LIBDIR}/syslinux/isolinux.bin
${ISODIR}${ISOLINUXDIR}
+if [ x${AUTO_SYSLINUXMENU} = x1 ] ; then
I believe that the convention is for these string tests to be quoted,
here and below.
No problem. I'll fix that. Someone's mail server was hoarding mail for bulk
delivery (I'll assume it was mine given the influx in the past 24 hours). I
didn't get this until yesterday but it looks like it was sent last week.
I'll send a v2 of the patch shortly.
Cheers,
Jason.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] ncurses, busybox, cml1.bbclass: Fix menuconfig display corruption
On 03/04/2013 04:11 PM, Trevor Woerner wrote: Is this a proposed fix for bug 3898? https://bugzilla.yoctoproject.org/show_bug.cgi?id=3898 Absolutely this would fix that defect. Jason. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] syslinux.bbclass: Add a default serial console option and real boot menu support
The previous syslinux menu code did not support using both a serial
and vga console, but this has worked for years in syslinux so there is
no reason not to take advantage of it. The previous menu looked like:
---
Linux Boot Menu
The following targets are available on this image:
boot: None
install: None
---
This commit makes it look something more like a traditional grub menu
on both the serial console and vga console as well as providing the
option to continue on using either the serial or vga console with the
correct kernel arguments.
You can see the screen shots attached to the bugzilla.
https://bugzilla.yoctoproject.org/show_bug.cgi?id=3944
[ YOCTO #3944 ]
Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
meta/classes/syslinux.bbclass | 128 -
1 files changed, 49 insertions(+), 79 deletions(-)
diff --git a/meta/classes/syslinux.bbclass b/meta/classes/syslinux.bbclass
index c4596bf..0b90eab 100644
--- a/meta/classes/syslinux.bbclass
+++ b/meta/classes/syslinux.bbclass
@@ -11,15 +11,17 @@
# ${LABELS} - a list of targets for the automatic config
# ${APPEND} - an override list of append strings for each label
# ${SYSLINUX_OPTS} - additional options to add to the syslinux file ';'
delimited
+# ${SYSLINUX_SPLASH} - A background for the vga boot menu if using the boot
menu
+# ${SYSLINUX_SERIAL} - Set an alternate serial port or turn off serial with
empty string
do_bootimg[depends] += syslinux:do_populate_sysroot \
syslinux-native:do_populate_sysroot
SYSLINUXCFG = ${S}/syslinux.cfg
-SYSLINUXMENU = ${S}/menu
ISOLINUXDIR = /isolinux
SYSLINUXDIR = /
+SYSLINUX_SERIAL ?= 0 115200
ISO_BOOTIMG = isolinux/isolinux.bin
ISO_BOOTCAT = isolinux/boot.cat
MKISOFS_OPTIONS = -no-emul-boot -boot-load-size 4 -boot-info-table
@@ -34,82 +36,34 @@ syslinux_populate() {
# Install the config files
install -m 0644 ${SYSLINUXCFG} ${DEST}${BOOTDIR}/${CFGNAME}
- if [ -f ${SYSLINUXMENU} ]; then
- install -m 0644 ${SYSLINUXMENU} ${DEST}${BOOTDIR}
- fi
}
syslinux_iso_populate() {
syslinux_populate ${ISODIR} ${ISOLINUXDIR} isolinux.cfg
install -m 0644 ${STAGING_LIBDIR}/syslinux/isolinux.bin
${ISODIR}${ISOLINUXDIR}
+ if [ ${AUTO_SYSLINUXMENU} = 1 ] ; then
+ install -m 0644 ${STAGING_LIBDIR}/syslinux/vesamenu.c32
${ISODIR}${ISOLINUXDIR}/vesamenu.c32
+ if [ ${SYSLINUX_SPLASH} != ] ; then
+ install -m 0644 ${SYSLINUX_SPLASH}
${ISODIR}${ISOLINUXDIR}/splash.lss
+ fi
+ fi
}
syslinux_hddimg_populate() {
syslinux_populate ${HDDDIR} ${SYSLINUXDIR} syslinux.cfg
install -m 0444 ${STAGING_LIBDIR}/syslinux/ldlinux.sys
${HDDDIR}${SYSLINUXDIR}/ldlinux.sys
+ if [ ${AUTO_SYSLINUXMENU} = 1 ] ; then
+ install -m 0644 ${STAGING_LIBDIR}/syslinux/vesamenu.c32
${HDDDIR}${SYSLINUXDIR}/vesamenu.c32
+ if [ ${SYSLINUX_SPLASH} != ] ; then
+ install -m 0644 ${SYSLINUX_SPLASH}
${HDDDIR}${SYSLINUXDIR}/splash.lss
+ fi
+ fi
}
syslinux_hddimg_install() {
syslinux ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.hddimg
}
-python build_syslinux_menu () {
-import copy
-import sys
-
-workdir = d.getVar('WORKDIR', True)
-if not workdir:
-bb.error(WORKDIR is not defined)
-return
-
-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('SYSLINUXMENU', True)
-if not cfile:
-raise bb.build.FuncFailed('Unable to read SYSLINUXMENU')
-
-try:
-cfgfile = file(cfile, 'w')
-except OSError:
-raise bb.build.funcFailed('Unable to open %s' % (cfile))
-
-# Beep the speaker and Clear the screen
-cfgfile.write('\x07\x0C')
-
-# The title should be configurable
-cfgfile.write('Linux Boot Menu\n')
-cfgfile.write('The following targets are available on this image:\n')
-cfgfile.write('\n')
-
-for label in labels.split():
-from copy import deepcopy
-localdata = deepcopy(d)
-
-overrides = localdata.getVar('OVERRIDES')
-if not overrides:
-raise bb.build.FuncFailed('OVERRIDES not defined')
-overrides = localdata.expand(overrides)
-
-localdata.setVar('OVERRIDES', label + ':' + overrides)
-bb.data.update_data(localdata)
-
-usage = localdata.getVar('USAGE', True)
-cfgfile.write(' \x0F\x30\x3E%16s\x0F\x30\x37: ' % (label))
-cfgfile.write('%s\n' % (usage))
-
-del localdata
-
-cfgfile.write('\n')
-cfgfile.close()
-}
-
python
[OE-core] [PATCH] qemu.inc: Non deterministic compile of qemu
When you using a qemuppc target and sstate you might end up with
the problem:
qemu-system-ppc: error while loading shared libraries:
libfdt.so.1: cannot open shared object file: No such file or directory
The way you can force this to happen assuming you are using sstate is
as follows:
bitbake dtc-native
bitbake -c cleansstate qemu-native
bitbake qemu-native
bitbake -c clean dtc-native
Now go start qemu and it will fail. The solution is to always build
the dtc libraries since they are used and needed by the qemuppc
simulator.
Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
meta/recipes-devtools/qemu/qemu.inc |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-devtools/qemu/qemu.inc
b/meta/recipes-devtools/qemu/qemu.inc
index 6c44b31..eb60d43 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -2,8 +2,8 @@ DESCRIPTION = open source processor emulator
HOMEPAGE = http://qemu.org;
LICENSE = GPLv2 LGPLv2.1
DEPENDS = glib-2.0 zlib alsa-lib virtual/libx11 pixman
-DEPENDS_class-native = zlib-native alsa-lib-native glib-2.0-native
pixman-native
-DEPENDS_class-nativesdk = nativesdk-zlib nativesdk-libsdl nativesdk-glib-2.0
nativesdk-pixman
+DEPENDS_class-native = zlib-native alsa-lib-native glib-2.0-native
pixman-native dtc-native
+DEPENDS_class-nativesdk = nativesdk-zlib nativesdk-libsdl nativesdk-glib-2.0
nativesdk-pixman nativesdk-dtc
RDEPENDS_${PN}_class-nativesdk = nativesdk-libsdl
require qemu-targets.inc
--
1.7.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] syslinux.bbclass: Add a default serial console option and real boot menu support
On 02/27/2013 05:51 AM, Trevor Woerner wrote: On Tue, Feb 26, 2013 at 9:04 PM, Jason Wessel jason.wes...@windriver.com wrote: You can see the screen shots attached to the bugzilla. https://bugzilla.yoctoproject.org/show_bug.cgi?id=3944 [ YOCTO #3944 ] Is the Windriver logo on the VGA example optional? The Wind River logo is purely an example. It is not actually included in the commit. If you build the commit I published you get what ever the internal splash that is part of isolinux. To be more specific, if you don't provide a SYSLINUX_SPLASH = location of some lss file in your local.conf you get the internal default which has nothing to do with Wind River's logo. I published an example to show that it can be done because other vendors would also likely want to include their own boot splash. Jason. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] syslinux.bbclass: Add a default serial console option and real boot menu support
The previous syslinux menu code did not support using both a serial
and vga console, but this has worked for years in syslinux so there is
no reason not to take advantage of it. The previous menu looked like:
---
Linux Boot Menu
The following targets are available on this image:
boot: None
install: None
---
This commit makes it look something more like a traditional grub menu
on both the serial console and vga console as well as providing the
option to continue on using either the serial or vga console with the
correct kernel arguments.
You can see the screen shots attached to the bugzilla.
https://bugzilla.yoctoproject.org/show_bug.cgi?id=3944
[ YOCTO #3944 ]
Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
meta/classes/syslinux.bbclass | 128 -
1 files changed, 49 insertions(+), 79 deletions(-)
diff --git a/meta/classes/syslinux.bbclass b/meta/classes/syslinux.bbclass
index c4596bf..c6a5a15 100644
--- a/meta/classes/syslinux.bbclass
+++ b/meta/classes/syslinux.bbclass
@@ -11,15 +11,17 @@
# ${LABELS} - a list of targets for the automatic config
# ${APPEND} - an override list of append strings for each label
# ${SYSLINUX_OPTS} - additional options to add to the syslinux file ';'
delimited
+# ${SYSLINUX_SPLASH} - A background for the vga boot menu if using the boot
menu
+# ${SYSLINUX_SERIAL} - Set an alternate serial port or turn off serial with
empty string
do_bootimg[depends] += syslinux:do_populate_sysroot \
syslinux-native:do_populate_sysroot
SYSLINUXCFG = ${S}/syslinux.cfg
-SYSLINUXMENU = ${S}/menu
ISOLINUXDIR = /isolinux
SYSLINUXDIR = /
+SYSLINUX_SERIAL ?= 0 115200
ISO_BOOTIMG = isolinux/isolinux.bin
ISO_BOOTCAT = isolinux/boot.cat
MKISOFS_OPTIONS = -no-emul-boot -boot-load-size 4 -boot-info-table
@@ -34,82 +36,34 @@ syslinux_populate() {
# Install the config files
install -m 0644 ${SYSLINUXCFG} ${DEST}${BOOTDIR}/${CFGNAME}
- if [ -f ${SYSLINUXMENU} ]; then
- install -m 0644 ${SYSLINUXMENU} ${DEST}${BOOTDIR}
- fi
}
syslinux_iso_populate() {
syslinux_populate ${ISODIR} ${ISOLINUXDIR} isolinux.cfg
install -m 0644 ${STAGING_LIBDIR}/syslinux/isolinux.bin
${ISODIR}${ISOLINUXDIR}
+ if [ x${AUTO_SYSLINUXMENU} = x1 ] ; then
+ install -m 0644
${STAGING_DIR}/${MACHINE}/usr/share/syslinux/vesamenu.c32
${ISODIR}${ISOLINUXDIR}/vesamenu.c32
+ if [ x${SYSLINUX_SPLASH} != x ] ; then
+ install -m 0644 ${SYSLINUX_SPLASH}
${ISODIR}${ISOLINUXDIR}/splash.lss
+ fi
+ fi
}
syslinux_hddimg_populate() {
syslinux_populate ${HDDDIR} ${SYSLINUXDIR} syslinux.cfg
install -m 0444 ${STAGING_LIBDIR}/syslinux/ldlinux.sys
${HDDDIR}${SYSLINUXDIR}/ldlinux.sys
+ if [ x${AUTO_SYSLINUXMENU} = x1 ] ; then
+ install -m 0644
${STAGING_DIR}/${MACHINE}/usr/share/syslinux/vesamenu.c32
${HDDDIR}${SYSLINUXDIR}/vesamenu.c32
+ if [ x${SYSLINUX_SPLASH} != x ] ; then
+ install -m 0644 ${SYSLINUX_SPLASH}
${HDDDIR}${SYSLINUXDIR}/splash.lss
+ fi
+ fi
}
syslinux_hddimg_install() {
syslinux ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.hddimg
}
-python build_syslinux_menu () {
-import copy
-import sys
-
-workdir = d.getVar('WORKDIR', True)
-if not workdir:
-bb.error(WORKDIR is not defined)
-return
-
-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('SYSLINUXMENU', True)
-if not cfile:
-raise bb.build.FuncFailed('Unable to read SYSLINUXMENU')
-
-try:
-cfgfile = file(cfile, 'w')
-except OSError:
-raise bb.build.funcFailed('Unable to open %s' % (cfile))
-
-# Beep the speaker and Clear the screen
-cfgfile.write('\x07\x0C')
-
-# The title should be configurable
-cfgfile.write('Linux Boot Menu\n')
-cfgfile.write('The following targets are available on this image:\n')
-cfgfile.write('\n')
-
-for label in labels.split():
-from copy import deepcopy
-localdata = deepcopy(d)
-
-overrides = localdata.getVar('OVERRIDES')
-if not overrides:
-raise bb.build.FuncFailed('OVERRIDES not defined')
-overrides = localdata.expand(overrides)
-
-localdata.setVar('OVERRIDES', label + ':' + overrides)
-bb.data.update_data(localdata)
-
-usage = localdata.getVar('USAGE', True)
-cfgfile.write(' \x0F\x30\x3E%16s\x0F\x30\x37: ' % (label))
-cfgfile.write('%s\n' % (usage))
-
-del localdata
-
-cfgfile.write('\n
[OE-core] [denzil] qemu-0.15.1: Fix fault with v86d when using -nographic
When using the qemu-0.15.1 with -nographic and a typical OE image, you
will get a segmentation fault in v86d when the guest OS is booting.
It will look like:
v86d[42]: segfault at 0 ip 0040171a sp 7fff5d11bad8 error 4 in
v86d[40+1a000]
Sometimes this is fatal to the guest, sometimes it is not, either way
it was fixed by the upstream qemu commit:
6023d832480e6713e5ae81d3b74f53e6306f3a1b
(disable automatic loading of sgabios when -nographic)
Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
...tomatic-loading-of-sgabios-when-nographic.patch | 38
meta/recipes-devtools/qemu/qemu_0.15.1.bb |3 +-
2 files changed, 40 insertions(+), 1 deletions(-)
create mode 100644
meta/recipes-devtools/qemu/qemu-0.15.1/qemu-disable-automatic-loading-of-sgabios-when-nographic.patch
diff --git
a/meta/recipes-devtools/qemu/qemu-0.15.1/qemu-disable-automatic-loading-of-sgabios-when-nographic.patch
b/meta/recipes-devtools/qemu/qemu-0.15.1/qemu-disable-automatic-loading-of-sgabios-when-nographic.patch
new file mode 100644
index 000..6908b08
--- /dev/null
+++
b/meta/recipes-devtools/qemu/qemu-0.15.1/qemu-disable-automatic-loading-of-sgabios-when-nographic.patch
@@ -0,0 +1,38 @@
+From 6023d832480e6713e5ae81d3b74f53e6306f3a1b Mon Sep 17 00:00:00 2001
+From: Paolo Bonzini pbonz...@redhat.com
+Date: Thu, 3 Nov 2011 16:00:22 +0100
+Subject: [PATCH] disable automatic loading of sgabios when -nographic
+
+sgabios hasn't gotten a lot of coverage since it was not shipped. For 1.0,
+let's disable the automatic loading of the option ROM in -nographic
+mode. We can put it back for 1.1.
+
+Signed-off-by: Paolo Bonzini pbonz...@redhat.com
+Signed-off-by: Anthony Liguori aligu...@us.ibm.com
+---
+ hw/pc.c |9 -
+ 1 files changed, 0 insertions(+), 9 deletions(-)
+
+diff --git a/hw/pc.c b/hw/pc.c
+index 25bfa85..3015671 100644
+--- a/hw/pc.c
b/hw/pc.c
+@@ -1103,15 +1103,6 @@ void pc_vga_init(PCIBus *pci_bus)
+ isa_vga_init();
+ }
+ }
+-
+-/*
+- * sga does not suppress normal vga output. So a machine can have both a
+- * vga card and sga manually enabled. Output will be seen on both.
+- * For nographic case, sga is enabled at all times
+- */
+-if (display_type == DT_NOGRAPHIC) {
+-isa_create_simple(sga);
+-}
+ }
+
+ static void cpu_request_exit(void *opaque, int irq, int level)
+--
+1.7.1
+
diff --git a/meta/recipes-devtools/qemu/qemu_0.15.1.bb
b/meta/recipes-devtools/qemu/qemu_0.15.1.bb
index 54f746b..4abe13d 100644
--- a/meta/recipes-devtools/qemu/qemu_0.15.1.bb
+++ b/meta/recipes-devtools/qemu/qemu_0.15.1.bb
@@ -3,7 +3,7 @@ require qemu.inc
LIC_FILES_CHKSUM = file://COPYING;md5=441c28d2cf86e15a37fa47e15a72fbac \
file://COPYING.LIB;endline=24;md5=c04def7ae38850e7d3ef548588159913
-PR = r7
+PR = r8
FILESPATH = ${FILE_DIRNAME}/qemu-${PV}
FILESDIR = ${WORKDIR}
@@ -20,6 +20,7 @@ SRC_URI = \
file://arm-bgr.patch \
file://a4d1f142542935b90d2eb30f3aead4edcf455fe6.patch \
file://0001-ppc64-Fix-linker-script.patch \
+file://qemu-disable-automatic-loading-of-sgabios-when-nographic.patch \
# Only use the GL passthrough patches for native/nativesdk versions
--
1.7.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] genext2fs.inc: Add nativesdk build capability
In order to generate new disk images for ext(2,3,4) which contain root
file systems we do not want to rely on the host's genext2fs which may
have different arguments and features, so allow the nativesdk
genext2fs binary to be built.
Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
meta/recipes-devtools/genext2fs/genext2fs.inc |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-devtools/genext2fs/genext2fs.inc
b/meta/recipes-devtools/genext2fs/genext2fs.inc
index 8bf2fce..0e39068 100644
--- a/meta/recipes-devtools/genext2fs/genext2fs.inc
+++ b/meta/recipes-devtools/genext2fs/genext2fs.inc
@@ -13,4 +13,4 @@ S = ${WORKDIR}/genext2fs-${PV}
inherit autotools
-BBCLASSEXTEND = native
+BBCLASSEXTEND = native nativesdk
--
1.7.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] util-linux: Add ability to compile with nativesdk
Some of the tools in the util-linux are used for disk and text file
operations in the nativesdk so as to get around different versions
that may exist on the host system.
Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
meta/recipes-core/util-linux/util-linux.inc | 90 +++--
meta/recipes-core/util-linux/util-linux_2.22.2.bb |3 +-
2 files changed, 49 insertions(+), 44 deletions(-)
diff --git a/meta/recipes-core/util-linux/util-linux.inc
b/meta/recipes-core/util-linux/util-linux.inc
index 10439c0..8955430 100644
--- a/meta/recipes-core/util-linux/util-linux.inc
+++ b/meta/recipes-core/util-linux/util-linux.inc
@@ -20,6 +20,7 @@ LIC_FILES_CHKSUM =
file://README.licensing;md5=9c920d811858a74b67a36ba23cbaa95f
inherit autotools gettext pkgconfig
DEPENDS = zlib ncurses
DEPENDS_append_class-native = lzo-native
+DEPENDS_append_class-nativesdk = lzo-native
SRC_URI =
${KERNELORG_MIRROR}/linux/utils/util-linux/v${MAJOR_VERSION}/util-linux-${PV}.tar.bz2
\
file://MCONFIG \
@@ -28,12 +29,12 @@ SRC_URI =
${KERNELORG_MIRROR}/linux/utils/util-linux/v${MAJOR_VERSION}/util-lin
file://swapargs.h \
-PACKAGES =+ util-linux-agetty util-linux-fdisk util-linux-cfdisk
util-linux-sfdisk \
- util-linux-swaponoff util-linux-losetup util-linux-umount \
- util-linux-mount util-linux-readprofile util-linux-libblkid \
- util-linux-libblkid-dev util-linux-libuuid util-linux-libuuid-dev
\
- util-linux-uuidgen util-linux-lscpu util-linux-fsck
util-linux-blkid \
- util-linux-mkfs util-linux-mcookie util-linux-reset
+PACKAGES =+ ${PN}-agetty ${PN}-fdisk ${PN}-cfdisk ${PN}-sfdisk \
+ ${PN}-swaponoff ${PN}-losetup ${PN}-umount \
+ ${PN}-mount ${PN}-readprofile ${PN}-libblkid \
+ ${PN}-libblkid-dev ${PN}-libuuid ${PN}-libuuid-dev \
+ ${PN}-uuidgen ${PN}-lscpu ${PN}-fsck ${PN}-blkid \
+ ${PN}-mkfs ${PN}-mcookie ${PN}-reset
EXTRA_OECONF = --libdir=${base_libdir} --disable-use-tty-group \
--disable-makeinstall-chown --enable-elvtune --enable-init \
@@ -46,44 +47,47 @@ EXTRA_OECONF = --libdir=${base_libdir}
--disable-use-tty-group \
EXTRA_OECONF_append_class-native = --disable-login --disable-su
+EXTRA_OECONF_append_class-nativesdk = --disable-login --disable-su
FILES_${PN}-doc += ${datadir}/getopt/getopt-*.*
-FILES_util-linux-agetty = ${base_sbindir}/agetty
-FILES_util-linux-fdisk = ${base_sbindir}/fdisk.${BPN}
-FILES_util-linux-cfdisk = ${base_sbindir}/cfdisk
-FILES_util-linux-sfdisk = ${sbindir}/sfdisk
-FILES_util-linux-swaponoff = ${base_sbindir}/swapon.${BPN}
${base_sbindir}/swapoff.${BPN}
-FILES_util-linux-losetup = ${base_sbindir}/losetup.${BPN}
-FILES_util-linux-mount = ${base_bindir}/mount.${BPN}
-FILES_util-linux-mcookie = ${bindir}/mcookie
-FILES_util-linux-umount = ${base_bindir}/umount.${BPN}
-FILES_util-linux-readprofile = ${base_sbindir}/readprofile.${BPN}
-FILES_util-linux-uuidgen = ${bindir}/uuidgen
-FILES_util-linux-reset = ${base_bindir}/reset
-
-FILES_util-linux-libblkid = ${base_libdir}/libblkid.so.*
-FILES_util-linux-libblkid-dev = ${base_libdir}/libblkid.so
${base_libdir}/libblkid.la ${includedir}/blkid ${libdir}/pkgconfig/blkid.pc
-FILES_util-linux-libuuid = ${base_libdir}/libuuid.so.*
-FILES_util-linux-libuuid-dev = ${base_libdir}/libuuid.so
${base_libdir}/libuuid.la ${includedir}/uuid ${libdir}/pkgconfig/uuid.pc
-FILES_util-linux-lscpu = ${bindir}/lscpu
-
-FILES_util-linux-fsck = ${base_sbindir}/fsck*
-FILES_util-linux-mkfs = ${sbindir}/mkfs
+FILES_${PN}-agetty = ${base_sbindir}/agetty
+FILES_${PN}-fdisk = ${base_sbindir}/fdisk.${BPN}
+FILES_${PN}-cfdisk = ${base_sbindir}/cfdisk
+FILES_${PN}-sfdisk = ${sbindir}/sfdisk
+FILES_${PN}-swaponoff = ${base_sbindir}/swapon.${BPN}
${base_sbindir}/swapoff.${BPN}
+FILES_${PN}-losetup = ${base_sbindir}/losetup.${BPN}
+FILES_${PN}-mount = ${base_bindir}/mount.${BPN}
+FILES_${PN}-mcookie = ${bindir}/mcookie
+FILES_${PN}-umount = ${base_bindir}/umount.${BPN}
+FILES_${PN}-readprofile = ${base_sbindir}/readprofile.${BPN}
+FILES_${PN}-uuidgen = ${bindir}/uuidgen
+FILES_${PN}-reset = ${base_bindir}/reset
+
+FILES_${PN}-libblkid = ${base_libdir}/libblkid.so.*
+FILES_${PN}-libblkid-dev = ${base_libdir}/libblkid.so
${base_libdir}/libblkid.la ${includedir}/blkid ${libdir}/pkgconfig/blkid.pc
+FILES_${PN}-libuuid = ${base_libdir}/libuuid.so.*
+FILES_${PN}-libuuid-dev = ${base_libdir}/libuuid.so ${base_libdir}/libuuid.la
${includedir}/uuid ${libdir}/pkgconfig/uuid.pc
+FILES_${PN}-lscpu = ${bindir}/lscpu
+
+FILES_${PN}-fsck = ${base_sbindir}/fsck*
+FILES_${PN}-mkfs = ${sbindir}/mkfs
# Util-linux' blkid replaces the e2fsprogs one
-FILES_util-linux-blkid = ${base_sbindir}/blkid*
-RCONFLICTS_util-linux-blkid = e2fsprogs-blkid
-RREPLACES_util-linux-blkid = e2fsprogs-blkid
+FILES_${PN}-blkid = ${base_sbindir}/blkid*
+RCONFLICTS_${PN}-blkid = e2fsprogs
Re: [OE-core] [PATCH v2 0/3] relocate_sdk.py: improvements
On 02/12/2013 04:24 AM, Laurentiu Palcu wrote: On 02/12/2013 12:19 PM, Jason Wessel wrote: For what ever reason I never received the original mails, else I absolutely would have responded. This is the first response I have received from the oe-core list in months in fact. I believe you... It happened to me too not to receive replies to my own patches. :/ Hard to say where the mail went other than the black hole. We too have had black hole issues, but I had always assumed it was on anti-spam filter side with our local mail server. As a side point it occurred to me that I never answered your other question, which was about what qemu we were using. At the time I hit the problem with the silent .interp corruption it was the qemu from denzil. Silent corruption is never fun to find or deal with, we had just ended up with binary that segmentation faulted some of the time. One time through trying to figure out what the root of the problem was more than enough. I figured I never wanted anyone else to have to debug that problem again, which the origin of these patches. ;-) Cheers, Jason. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH v3 1/3] relocate_sdk.py: Fix corruption of sdk binaries
There are two cases of corruption that the relocate_sdk.py was not correctly dealing with. 1) SDK Extras should be left alone Extra external binaries included in an SDK that were linked against the host's version of /usr/lib/ld-so.so should not get a relocation applied. In the case that was discovered these were LSB compliant binaries that already worked on many hosts. 2) If the interp section is too small generate an error In the case of the qemu user code, it was using its own .ld file to link the executables which overrides the default in the nativesdk binutils. This generated host executables which had a interp section that was too small to relocate. Now the relocate_sdk.py will print an error and continue on such that the error can be fixed by a developer without having to do the difficult task of debugging why it is crashing or not loading correctly. Signed-off-by: Jason Wessel jason.wes...@windriver.com --- scripts/relocate_sdk.py | 13 +++-- 1 files changed, 11 insertions(+), 2 deletions(-) diff --git a/scripts/relocate_sdk.py b/scripts/relocate_sdk.py index 74bb7a5..45d2c24 100755 --- a/scripts/relocate_sdk.py +++ b/scripts/relocate_sdk.py @@ -66,7 +66,7 @@ def parse_elf_header(): e_ehsize, e_phentsize, e_phnum, e_shentsize, e_shnum, e_shstrndx =\ hdr_struct.unpack(elf_header[16:hdr_size]) -def change_interpreter(): +def change_interpreter(elf_file_name): if arch == 32: ph_struct = struct.Struct() else: @@ -89,7 +89,16 @@ def change_interpreter(): if p_type == 3: # PT_INTERP section f.seek(p_offset) +# External SDKs with mixed pre-compiled binaries should not get +# relocated so look for some variant of /lib +fname = f.read(11) +if fname.startswith(/lib/) or fname.startswith(/lib64/) or fname.startswith(/lib32/) or fname.startswith(/usr/lib32/) or fname.startswith(/usr/lib32/) or fname.startswith(/usr/lib64/): +break +if (len(new_dl_path) = p_filesz): +print ERROR: could not relocate %s, interp size = %i and %i is needed. % (elf_file_name, p_memsz, len(new_dl_path) + 1) +break dl_path = new_dl_path + \0 * (p_filesz - len(new_dl_path)) +f.seek(p_offset) f.write(dl_path) break @@ -199,7 +208,7 @@ for e in executables_list: arch = get_arch() if arch: parse_elf_header() -change_interpreter() +change_interpreter(e) change_dl_sysdirs() change permissions back -- 1.7.1 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH v3 3/3] relocate_sdk.py: allow relocate_sdk.py to work with python 2.4.x
Avoid the chicken / egg problem of an SDK that provides a working python but requires that version of python to extract itself. The RHEL 5.x systems and some other enterprise Linux systems ship with python 2.4.x as the default python. We need to at least be able to extract work executables even if we never use the the host provided python again. Signed-off-by: Jason Wessel jason.wes...@windriver.com --- scripts/relocate_sdk.py | 26 +- 1 files changed, 13 insertions(+), 13 deletions(-) diff --git a/scripts/relocate_sdk.py b/scripts/relocate_sdk.py index 45d2c24..1d7bbb3 100755 --- a/scripts/relocate_sdk.py +++ b/scripts/relocate_sdk.py @@ -55,22 +55,22 @@ def parse_elf_header(): if arch == 32: # 32bit -hdr_struct = struct.Struct(HHILLLIHH) +hdr_fmt = HHILLLIHH hdr_size = 52 else: # 64bit -hdr_struct = struct.Struct(HHIQQQIHH) +hdr_fmt = HHIQQQIHH hdr_size = 64 e_type, e_machine, e_version, e_entry, e_phoff, e_shoff, e_flags,\ e_ehsize, e_phentsize, e_phnum, e_shentsize, e_shnum, e_shstrndx =\ -hdr_struct.unpack(elf_header[16:hdr_size]) +struct.unpack(hdr_fmt, elf_header[16:hdr_size]) def change_interpreter(elf_file_name): if arch == 32: -ph_struct = struct.Struct() +ph_fmt = else: -ph_struct = struct.Struct(IIQQ) +ph_fmt = IIQQ look for PT_INTERP section for i in range(0,e_phnum): @@ -79,11 +79,11 @@ def change_interpreter(elf_file_name): if arch == 32: # 32bit p_type, p_offset, p_vaddr, p_paddr, p_filesz,\ -p_memsz, p_flags, p_align = ph_struct.unpack(ph_hdr) +p_memsz, p_flags, p_align = struct.unpack(ph_fmt, ph_hdr) else: # 64bit p_type, p_flags, p_offset, p_vaddr, p_paddr, \ -p_filesz, p_memsz, p_align = ph_struct.unpack(ph_hdr) +p_filesz, p_memsz, p_align = struct.unpack(ph_fmt, ph_hdr) change interpreter if p_type == 3: @@ -104,9 +104,9 @@ def change_interpreter(elf_file_name): def change_dl_sysdirs(): if arch == 32: -sh_struct = struct.Struct(II) +sh_fmt = II else: -sh_struct = struct.Struct(IIIIQQ) +sh_fmt = IIIIQQ read section string table f.seek(e_shoff + e_shstrndx * e_shentsize) @@ -127,7 +127,7 @@ def change_dl_sysdirs(): sh_hdr = f.read(e_shentsize) sh_name, sh_type, sh_flags, sh_addr, sh_offset, sh_size, sh_link,\ -sh_info, sh_addralign, sh_entsize = sh_struct.unpack(sh_hdr) +sh_info, sh_addralign, sh_entsize = struct.unpack(sh_fmt, sh_hdr) name = sh_strtab[sh_name:sh_strtab.find(\0, sh_name)] @@ -181,7 +181,7 @@ def change_dl_sysdirs(): # MAIN if len(sys.argv) 4: -exit(-1) +sys.exit(-1) new_prefix = sys.argv[1] new_dl_path = sys.argv[2] @@ -196,14 +196,14 @@ for e in executables_list: try: f = open(e, r+b) -except IOError as ioex: +except IOError, ioex: if ioex.errno == errno.ETXTBSY: print(Could not open %s. File used by another process.\nPlease \ make sure you exit all processes that might use any SDK \ binaries. % e) else: print(Could not open %s: %s(%d) % (e, ioex.strerror, ioex.errno)) -exit(-1) +sys.exit(-1) arch = get_arch() if arch: -- 1.7.1 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH v3 2/3] populate_sdk_base.bbclass: Improve debugging capabilities for SDK installer
After having to debug the SDK installer a few times in
addition to the relocation code the following patch was created
to improve the capabilities around debugging the SDK installer.
1) Add a verbose mode -D which set a set -x to see what
the SDK installer is doing.
2) Add a mode -S to save the relocation scripts for the purpose
of debugging them in conjunction with -D
3) Add a mode -R to not execute the relocation scripts for the
purpose of debugging the relocations.
Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
meta/classes/populate_sdk_base.bbclass | 48
1 files changed, 42 insertions(+), 6 deletions(-)
diff --git a/meta/classes/populate_sdk_base.bbclass
b/meta/classes/populate_sdk_base.bbclass
index c025d40..923f925 100644
--- a/meta/classes/populate_sdk_base.bbclass
+++ b/meta/classes/populate_sdk_base.bbclass
@@ -136,7 +136,10 @@ DEFAULT_INSTALL_DIR=${SDKPATH}
SUDO_EXEC=
target_sdk_dir=
answer=
-while getopts :yd: OPT; do
+relocate=1
+savescripts=0
+verbose=0
+while getopts :yd:DRS OPT; do
case $OPT in
y)
answer=Y
@@ -145,15 +148,33 @@ while getopts :yd: OPT; do
d)
target_sdk_dir=$OPTARG
;;
+ D)
+ verbose=1
+ ;;
+ R)
+ relocate=0
+ savescripts=1
+ ;;
+ S)
+ savescripts=1
+ ;;
*)
echo Usage: $(basename $0) [-y] [-d dir]
echo -y Automatic yes to all prompts
echo -d dir Install the SDK to dir
+ echo Advanced DEBUGGING ONLY OPTIONS
+ echo -S Save relocation scripts
+ echo -R Do not relocate executables
+ echo -D use set -x to see what is going on
exit 1
;;
esac
done
+if [ $verbose = 1 ] ; then
+ set -x
+fi
+
printf Enter target directory for SDK (default: $DEFAULT_INSTALL_DIR):
if [ $target_sdk_dir = ]; then
read target_sdk_dir
@@ -231,10 +252,23 @@ if [ $dl_path = ] ; then
exit 1
fi
executable_files=$($SUDO_EXEC find $native_sysroot -type f -perm +111)
-$SUDO_EXEC ${env_setup_script%/*}/relocate_sdk.py $target_sdk_dir $dl_path
$executable_files
-if [ $? -ne 0 ]; then
- echo SDK could not be set up. Relocate script failed. Abort!
- exit 1
+
+tdir=`mktemp -d`
+if [ x$tdir = x ] ; then
+ echo SDK relocate failed, could not create a temporary directory
+ exit 1
+fi
+echo #!/bin/bash $tdir/relocate_sdk.sh
+echo exec ${env_setup_script%/*}/relocate_sdk.py $target_sdk_dir $dl_path
$executable_files $tdir/relocate_sdk.sh
+$SUDO_EXEC mv $tdir/relocate_sdk.sh ${env_setup_script%/*}/relocate_sdk.sh
+$SUDO_EXEC chmod 755 ${env_setup_script%/*}/relocate_sdk.sh
+rm -rf $tdir
+if [ $relocate = 1 ] ; then
+ $SUDO_EXEC ${env_setup_script%/*}/relocate_sdk.sh
+ if [ $? -ne 0 ]; then
+ echo SDK could not be set up. Relocate script failed. Abort!
+ exit 1
+ fi
fi
# replace ${SDKPATH} with the new prefix in all text files: configs/scripts/etc
@@ -249,7 +283,9 @@ echo done
# delete the relocating script, so that user is forced to re-run the installer
# if he/she wants another location for the sdk
-$SUDO_EXEC rm ${env_setup_script%/*}/relocate_sdk.py
+if [ $savescripts = 0 ] ; then
+ $SUDO_EXEC rm ${env_setup_script%/*}/relocate_sdk.py
${env_setup_script%/*}/relocate_sdk.sh
+fi
echo SDK has been successfully set up and is ready to be used.
--
1.7.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH v3 0/3] relocate_sdk.py: improvements
New in v3 are all the fixes recommended by Laurentiu Palcu * Fix sudo exec problem * Preserve padding in the .interp section --- Now that I have had to debug the SDK relocator on multiple occasions I figure it might be nice to get the patches upstreamed. This last time through fixing the python 2.4.x compatibility was very easy using the prior two patches to allow me to do so. The idea here is to increase the portability of the relocator because once the SDK is installed/relocated, generally speaking it is working well on old and new hosts. Thanks, Jason. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] libtool-native_2.4.2.bb: Always use /bin/sed for SED
If you never use sstate and always build everything from scratch you
will never see this problem. However, if you use sstate and build
directories that last a long time eventually you can end up with the
scenario where libtool gets a hard coded path in it for sed, and sed
may not exist. The reason you don't see this problem to often if you
generally build from scratch is that libtool builds before sed and
will pickup the host's /bin/sed.
The way to reproduce the issue is:
bitbake some_image
bitbake -c cleansstate libtool-native
bitbake sed-native
bitbake libtool-native
bitbake -c clean sed-native
bitbake ANY_PACKAGE_THAT_USES_LIBTOOL_NATIVE
In my case I used modphp, which doesn't exist in the oe-core. You will
end up with a strange looking error like:
| make[1]: *** [buckets/apr_buckets_alloc.lo] Error 1
|
/opt/build/bitbake_build/tmp/sysroots/x86_64-linux/usr/bin/x86_64-linux-libtool:
line 981: /opt/build/bitbake_build/tmp/sysroots/x86_64-linux//bin/sed: No such
file or directory
The solution is to always use /bin/sed for libtool-native.
Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
.../libtool/libtool-native_2.4.2.bb|3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-devtools/libtool/libtool-native_2.4.2.bb
b/meta/recipes-devtools/libtool/libtool-native_2.4.2.bb
index f12e6a1..18188ef 100644
--- a/meta/recipes-devtools/libtool/libtool-native_2.4.2.bb
+++ b/meta/recipes-devtools/libtool/libtool-native_2.4.2.bb
@@ -2,12 +2,13 @@ require libtool-${PV}.inc
DEPENDS =
-PR = ${INC_PR}.0
+PR = ${INC_PR}.1
SRC_URI += file://prefix.patch
inherit native
EXTRA_OECONF = --with-libtool-sysroot=${STAGING_DIR_NATIVE}
+CACHED_CONFIGUREVARS += ac_cv_path_SED=/bin/sed
do_configure_prepend () {
# Remove any existing libtool m4 since old stale versions would break
--
1.7.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2 2/3] populate_sdk_base.bbclass: Improve debugging capabilities for SDK installer
After having to debug the SDK installer a few times in
addition to the relocation code the following patch was created
to improve the capabilities around debugging the SDK installer.
1) Add a verbose mode -D which set a set -x to see what
the SDK installer is doing.
2) Add a mode -S to save the relocation scripts for the purpose
of debugging them in conjunction with -D
3) Add a mode -R to not execute the relocation scripts for the
purpose of debugging the relocations.
Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
meta/classes/populate_sdk_base.bbclass | 40 +++
1 files changed, 34 insertions(+), 6 deletions(-)
diff --git a/meta/classes/populate_sdk_base.bbclass
b/meta/classes/populate_sdk_base.bbclass
index c025d40..310b7cf 100644
--- a/meta/classes/populate_sdk_base.bbclass
+++ b/meta/classes/populate_sdk_base.bbclass
@@ -136,7 +136,10 @@ DEFAULT_INSTALL_DIR=${SDKPATH}
SUDO_EXEC=
target_sdk_dir=
answer=
-while getopts :yd: OPT; do
+relocate=1
+savescripts=0
+verbose=0
+while getopts :yd:DRS OPT; do
case $OPT in
y)
answer=Y
@@ -145,15 +148,33 @@ while getopts :yd: OPT; do
d)
target_sdk_dir=$OPTARG
;;
+ D)
+ verbose=1
+ ;;
+ R)
+ relocate=0
+ savescripts=1
+ ;;
+ S)
+ savescripts=1
+ ;;
*)
echo Usage: $(basename $0) [-y] [-d dir]
echo -y Automatic yes to all prompts
echo -d dir Install the SDK to dir
+ echo Advanced DEBUGGING ONLY OPTIONS
+ echo -S Save relocation scripts
+ echo -R Do not relocate executables
+ echo -D use set -x to see what is going on
exit 1
;;
esac
done
+if [ $verbose = 1 ] ; then
+ set -x
+fi
+
printf Enter target directory for SDK (default: $DEFAULT_INSTALL_DIR):
if [ $target_sdk_dir = ]; then
read target_sdk_dir
@@ -231,10 +252,15 @@ if [ $dl_path = ] ; then
exit 1
fi
executable_files=$($SUDO_EXEC find $native_sysroot -type f -perm +111)
-$SUDO_EXEC ${env_setup_script%/*}/relocate_sdk.py $target_sdk_dir $dl_path
$executable_files
-if [ $? -ne 0 ]; then
- echo SDK could not be set up. Relocate script failed. Abort!
- exit 1
+echo #!/bin/bash ${env_setup_script%/*}/relocate_sdk.sh
+echo exec $SUDO_EXEC ${env_setup_script%/*}/relocate_sdk.py $target_sdk_dir
$dl_path $executable_files ${env_setup_script%/*}/relocate_sdk.sh
+chmod 755 ${env_setup_script%/*}/relocate_sdk.sh
+if [ $relocate = 1 ] ; then
+ ${env_setup_script%/*}/relocate_sdk.sh
+ if [ $? -ne 0 ]; then
+ echo SDK could not be set up. Relocate script failed. Abort!
+ exit 1
+ fi
fi
# replace ${SDKPATH} with the new prefix in all text files: configs/scripts/etc
@@ -249,7 +275,9 @@ echo done
# delete the relocating script, so that user is forced to re-run the installer
# if he/she wants another location for the sdk
-$SUDO_EXEC rm ${env_setup_script%/*}/relocate_sdk.py
+if [ $savescripts = 0 ] ; then
+ $SUDO_EXEC rm ${env_setup_script%/*}/relocate_sdk.py
${env_setup_script%/*}/relocate_sdk.sh
+fi
echo SDK has been successfully set up and is ready to be used.
--
1.7.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2 1/3] relocate_sdk.py: Fix corruption of sdk binaries
There are two cases of corruption that the relocate_sdk.py was not correctly dealing with. 1) SDK Extras should be left alone Extra external binaries included in an SDK that were linked against the host's version of /usr/lib/ld-so.so should not get a relocation applied. In the case that was discovered these were LSB compliant binaries that already worked on many hosts. 2) If the interp section is too small generate an error In the case of the qemu user code, it was using its own .ld file to link the executables which overrides the default in the nativesdk binutils. This generated host executables which had a interp section that was too small to relocate. Now the relocate_sdk.py will print an error and continue on such that the error can be fixed by a developer without having to do the difficult task of debugging why it is crashing or not loading correctly. Signed-off-by: Jason Wessel jason.wes...@windriver.com --- scripts/relocate_sdk.py | 15 --- 1 files changed, 12 insertions(+), 3 deletions(-) diff --git a/scripts/relocate_sdk.py b/scripts/relocate_sdk.py index 74bb7a5..6f3530d 100755 --- a/scripts/relocate_sdk.py +++ b/scripts/relocate_sdk.py @@ -66,7 +66,7 @@ def parse_elf_header(): e_ehsize, e_phentsize, e_phnum, e_shentsize, e_shnum, e_shstrndx =\ hdr_struct.unpack(elf_header[16:hdr_size]) -def change_interpreter(): +def change_interpreter(elf_file_name): if arch == 32: ph_struct = struct.Struct() else: @@ -89,7 +89,16 @@ def change_interpreter(): if p_type == 3: # PT_INTERP section f.seek(p_offset) -dl_path = new_dl_path + \0 * (p_filesz - len(new_dl_path)) +dl_path = new_dl_path + \0 +# External SDKs with mixed pre-compiled binaries should not get +# relocated so look for some variant of /lib +fname = f.read(11) +if fname.startswith(/lib/) or fname.startswith(/lib64/) or fname.startswith(/lib32/) or fname.startswith(/usr/lib32/) or fname.startswith(/usr/lib32/) or fname.startswith(/usr/lib64/): +break +if (len(dl_path) = p_memsz): +print ERROR: could not relocate %s, interp size = %i and %i is needed. % (elf_file_name, p_memsz, len(dl_path)) +break +f.seek(p_offset) f.write(dl_path) break @@ -199,7 +208,7 @@ for e in executables_list: arch = get_arch() if arch: parse_elf_header() -change_interpreter() +change_interpreter(e) change_dl_sysdirs() change permissions back -- 1.7.1 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2 3/3] relocate_sdk.py: allow relocate_sdk.py to work with python 2.4.x
Avoid the chicken / egg problem of an SDK that provides a working python but requires that version of python to extract itself. The RHEL 5.x systems and some other enterprise Linux systems ship with python 2.4.x as the default python. We need to at least be able to extract work executables even if we never use the the host provided python again. Signed-off-by: Jason Wessel jason.wes...@windriver.com --- scripts/relocate_sdk.py | 26 +- 1 files changed, 13 insertions(+), 13 deletions(-) diff --git a/scripts/relocate_sdk.py b/scripts/relocate_sdk.py index 6f3530d..b7e579d 100755 --- a/scripts/relocate_sdk.py +++ b/scripts/relocate_sdk.py @@ -55,22 +55,22 @@ def parse_elf_header(): if arch == 32: # 32bit -hdr_struct = struct.Struct(HHILLLIHH) +hdr_fmt = HHILLLIHH hdr_size = 52 else: # 64bit -hdr_struct = struct.Struct(HHIQQQIHH) +hdr_fmt = HHIQQQIHH hdr_size = 64 e_type, e_machine, e_version, e_entry, e_phoff, e_shoff, e_flags,\ e_ehsize, e_phentsize, e_phnum, e_shentsize, e_shnum, e_shstrndx =\ -hdr_struct.unpack(elf_header[16:hdr_size]) +struct.unpack(hdr_fmt, elf_header[16:hdr_size]) def change_interpreter(elf_file_name): if arch == 32: -ph_struct = struct.Struct() +ph_fmt = else: -ph_struct = struct.Struct(IIQQ) +ph_fmt = IIQQ look for PT_INTERP section for i in range(0,e_phnum): @@ -79,11 +79,11 @@ def change_interpreter(elf_file_name): if arch == 32: # 32bit p_type, p_offset, p_vaddr, p_paddr, p_filesz,\ -p_memsz, p_flags, p_align = ph_struct.unpack(ph_hdr) +p_memsz, p_flags, p_align = struct.unpack(ph_fmt, ph_hdr) else: # 64bit p_type, p_flags, p_offset, p_vaddr, p_paddr, \ -p_filesz, p_memsz, p_align = ph_struct.unpack(ph_hdr) +p_filesz, p_memsz, p_align = struct.unpack(ph_fmt, ph_hdr) change interpreter if p_type == 3: @@ -104,9 +104,9 @@ def change_interpreter(elf_file_name): def change_dl_sysdirs(): if arch == 32: -sh_struct = struct.Struct(II) +sh_fmt = II else: -sh_struct = struct.Struct(IIIIQQ) +sh_fmt = IIIIQQ read section string table f.seek(e_shoff + e_shstrndx * e_shentsize) @@ -127,7 +127,7 @@ def change_dl_sysdirs(): sh_hdr = f.read(e_shentsize) sh_name, sh_type, sh_flags, sh_addr, sh_offset, sh_size, sh_link,\ -sh_info, sh_addralign, sh_entsize = sh_struct.unpack(sh_hdr) +sh_info, sh_addralign, sh_entsize = struct.unpack(sh_fmt, sh_hdr) name = sh_strtab[sh_name:sh_strtab.find(\0, sh_name)] @@ -181,7 +181,7 @@ def change_dl_sysdirs(): # MAIN if len(sys.argv) 4: -exit(-1) +sys.exit(-1) new_prefix = sys.argv[1] new_dl_path = sys.argv[2] @@ -196,14 +196,14 @@ for e in executables_list: try: f = open(e, r+b) -except IOError as ioex: +except IOError, ioex: if ioex.errno == errno.ETXTBSY: print(Could not open %s. File used by another process.\nPlease \ make sure you exit all processes that might use any SDK \ binaries. % e) else: print(Could not open %s: %s(%d) % (e, ioex.strerror, ioex.errno)) -exit(-1) +sys.exit(-1) arch = get_arch() if arch: -- 1.7.1 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2 0/3] relocate_sdk.py: improvements
Now that I have had to debug the SDK relocator on multiple occasions I figure it might be nice to get the patches upstreamed. This last time through fixing the python 2.4.x compatibility was very easy using the prior two patches to allow me to do so. The idea here is to increase the portability of the relocator because once the SDK is installed/relocated, generally speaking it is working well on old and new hosts. Thanks, Jason. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] ncurses.inc: Fix display corruption and add fallback for sstate compiled paths
CQID: WIND00402979
Display corruption was occurring on 64 bit hosts using menuconfig for
the kernel and busybox with the ncurses-native or ncurses-nativesdk
because the configure arguments were not sufficient vs the expected
use from the upstream source.
Also changed in this commit is to provide a fallback to the hard
compiled paths for the terminfo and termcap. Eventually this needs to
be fixed another way if we want a truly portable SDK because any SDK
that is relocated or native binaries pulled out of the sstate can end
up referencing terminfo files that no longer are in the same location.
Because the host system has terminfo files that ncurses will happily
use we might as well have a fall back to buy some time for a better
fix, vs having thing just not work occasionally when using sstate.
Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
meta/recipes-core/ncurses/ncurses.inc | 32 +---
1 files changed, 29 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-core/ncurses/ncurses.inc
b/meta/recipes-core/ncurses/ncurses.inc
index 5fdd994..9250e9d 100644
--- a/meta/recipes-core/ncurses/ncurses.inc
+++ b/meta/recipes-core/ncurses/ncurses.inc
@@ -6,7 +6,7 @@ LIC_FILES_CHKSUM =
file://ncurses/base/version.c;beginline=1;endline=27;md5=cbc
SECTION = libs
DEPENDS = ncurses-native
DEPENDS_class-native =
-INC_PR = r13
+INC_PR = r14
inherit autotools binconfig multilib_header
@@ -29,6 +29,31 @@ BUILD_CPPFLAGS += -D_GNU_SOURCE
# natives don't generally look in base_libdir
base_libdir_class-native = ${libdir}
+# Display corruption occurs on 64 bit hosts without these settings
+# This was derrived from the upstream debian ncurses which uses
+# these settings for 32 and 64 bit hosts.
+EXCONFIG_ARGS =
+EXCONFIG_ARGS_virtclass-native = \
+ --disable-lp64 \
+ --with-chtype='long' \
+ --with-mmask-t='long'
+EXCONFIG_ARGS_virtclass-nativesdk = \
+ --disable-lp64 \
+ --with-chtype='long' \
+ --with-mmask-t='long'
+
+# Fall back to the host termcap / terminfo for -nativesdk and -native
+# The reality is a work around for strange problems with things like
+# bitbake -c menuconfig busybox where it cannot find the terminfo
+# because the sstate had a hard coded search path. Until this is fixed
+# another way this is deemed good enough.
+EX_TERMCAP =
+EX_TERMCAP_virtclass-native = :/etc/termcap:/usr/share/misc/termcap
+EX_TERMCAP_virtclass-nativesdk = :/etc/termcap:/usr/share/misc/termcap
+EX_TERMINFO =
+EX_TERMINFO_virtclass-native =
:/etc/terminfo:/usr/share/misc/terminfo:/lib/terminfo
+EX_TERMINFO_virtclass-nativesdk =
:/etc/terminfo:/usr/share/misc/terminfo:/lib/terminfo
+
# Helper function for do_configure to allow multiple configurations
# $1 the directory to run configure in
# $@ the arguments to pass to configure
@@ -44,8 +69,8 @@ ncurses_configure() {
--enable-hard-tabs \
--enable-xmc-glitch \
--enable-colorfgbg \
- --with-termpath='${sysconfdir}/termcap:${datadir}/misc/termcap'
\
-
--with-terminfo-dirs='${sysconfdir}/terminfo:${datadir}/terminfo' \
+
--with-termpath='${sysconfdir}/termcap:${datadir}/misc/termcap${EX_TERMCAP}' \
+
--with-terminfo-dirs='${sysconfdir}/terminfo:${datadir}/terminfo${EX_TERMINFO}'
\
--with-shared \
--disable-big-core \
--program-prefix= \
@@ -54,6 +79,7 @@ ncurses_configure() {
--enable-sigwinch \
--enable-pc-files \
--disable-rpath-hack \
+ ${EXCONFIG_ARGS} \
--with-manpage-format=normal \
$@ || return 1
cd ..
--
1.7.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] relocate_sdk.py: Fix corruption of sdk binaries
On 01/24/2013 06:38 PM, Jason Wessel wrote: There are two cases of corruption that the relocate_sdk.py was not correctly dealing with. 1) SDK Extras should be left alone Extra external binaries included in an SDK that were linked against the host's version of /usr/lib/ld-so.so should not get a relocation applied. In the case that was discovered these were LSB compliant binaries that already worked on many hosts. 2) If the interp section is too small generate an error In the case of the qemu user code, it was using its own .ld file to link the executables which overrides the default in the nativesdk binutils. This generated host executables which had a interp section that was too small to relocate. Now the relocate_sdk.py will print an error and continue on such that the error can be fixed by a developer without having to do the difficult task of debugging why it is crashing or not loading correctly. Signed-off-by: Jason Wessel jason.wes...@windriver.com --- scripts/relocate_sdk.py | 17 + 1 files changed, 13 insertions(+), 4 deletions(-) diff --git a/scripts/relocate_sdk.py b/scripts/relocate_sdk.py index 74bb7a5..3e3181f 100755 --- a/scripts/relocate_sdk.py +++ b/scripts/relocate_sdk.py @@ -66,7 +66,7 @@ def parse_elf_header(): e_ehsize, e_phentsize, e_phnum, e_shentsize, e_shnum, e_shstrndx =\ hdr_struct.unpack(elf_header[16:hdr_size]) -def change_interpreter(): +def change_interpreter(elf_file_name): if arch == 32: ph_struct = struct.Struct() else: @@ -89,8 +89,17 @@ def change_interpreter(): if p_type == 3: # PT_INTERP section f.seek(p_offset) -dl_path = new_dl_path + \0 * (p_filesz - len(new_dl_path)) -f.write(dl_path) +dl_path = new_dl_path + \0 +# External SDKs with mixed pre-compiled binaries should not get +# relocated so look for some variant of /lib +fname = f.read(11) +if fname.startswith(/lib/) or fname.startswith(/lib64/) or fname.startswith(/lib32/) or fname.startswith(/usr/lib32/) or fname.startswith(/usr/lib32/) or fname.startswith(/usr/lib64/): +break +if (len(dl_path) = p_memsz): +print ERROR: could not relocate %s, interp size = %i and %i is needed. % (elf_file_name, p_memsz, len(dl_path)) +break +f.seek(p_offset) +f.write(dl_path ) oops... Need a yocto check patch for python white space eh? Attached is the fixed version. Cheers, Jason. 0001-relocate_sdk.py-Fix-corruption-of-sdk-binaries.patch Description: application/mbox ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] relocate_sdk.py: Fix corruption of sdk binaries
There are two cases of corruption that the relocate_sdk.py was not correctly dealing with. 1) SDK Extras should be left alone Extra external binaries included in an SDK that were linked against the host's version of /usr/lib/ld-so.so should not get a relocation applied. In the case that was discovered these were LSB compliant binaries that already worked on many hosts. 2) If the interp section is too small generate an error In the case of the qemu user code, it was using its own .ld file to link the executables which overrides the default in the nativesdk binutils. This generated host executables which had a interp section that was too small to relocate. Now the relocate_sdk.py will print an error and continue on such that the error can be fixed by a developer without having to do the difficult task of debugging why it is crashing or not loading correctly. Signed-off-by: Jason Wessel jason.wes...@windriver.com --- scripts/relocate_sdk.py | 17 + 1 files changed, 13 insertions(+), 4 deletions(-) diff --git a/scripts/relocate_sdk.py b/scripts/relocate_sdk.py index 74bb7a5..3e3181f 100755 --- a/scripts/relocate_sdk.py +++ b/scripts/relocate_sdk.py @@ -66,7 +66,7 @@ def parse_elf_header(): e_ehsize, e_phentsize, e_phnum, e_shentsize, e_shnum, e_shstrndx =\ hdr_struct.unpack(elf_header[16:hdr_size]) -def change_interpreter(): +def change_interpreter(elf_file_name): if arch == 32: ph_struct = struct.Struct() else: @@ -89,8 +89,17 @@ def change_interpreter(): if p_type == 3: # PT_INTERP section f.seek(p_offset) -dl_path = new_dl_path + \0 * (p_filesz - len(new_dl_path)) -f.write(dl_path) +dl_path = new_dl_path + \0 +# External SDKs with mixed pre-compiled binaries should not get +# relocated so look for some variant of /lib +fname = f.read(11) +if fname.startswith(/lib/) or fname.startswith(/lib64/) or fname.startswith(/lib32/) or fname.startswith(/usr/lib32/) or fname.startswith(/usr/lib32/) or fname.startswith(/usr/lib64/): +break +if (len(dl_path) = p_memsz): +print ERROR: could not relocate %s, interp size = %i and %i is needed. % (elf_file_name, p_memsz, len(dl_path)) +break +f.seek(p_offset) +f.write(dl_path ) break def change_dl_sysdirs(): @@ -199,7 +208,7 @@ for e in executables_list: arch = get_arch() if arch: parse_elf_header() -change_interpreter() +change_interpreter(e) change_dl_sysdirs() change permissions back -- 1.7.1 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] populate_sdk_base.bbclass: Improve debugging capabilities for SDK installer
After having to debug the SDK installer a few times in
addition to the relocation code the following patch was created
to improve the capabilities around debugging the SDK installer.
1) Add a verbose mode -D which set a set -x to see what
the SDK installer is doing.
2) Add a mode -S to save the relocation scripts for the purpose
of debugging them in conjunction with -D
3) Add a mode -R to not execute the relocation scripts for the
purpose of debugging the relocations.
Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
meta/classes/populate_sdk_base.bbclass | 40 +++
1 files changed, 34 insertions(+), 6 deletions(-)
diff --git a/meta/classes/populate_sdk_base.bbclass
b/meta/classes/populate_sdk_base.bbclass
index c587af8..9321445 100644
--- a/meta/classes/populate_sdk_base.bbclass
+++ b/meta/classes/populate_sdk_base.bbclass
@@ -136,7 +136,10 @@ DEFAULT_INSTALL_DIR=${SDKPATH}
SUDO_EXEC=
target_sdk_dir=
answer=
-while getopts :yd: OPT; do
+relocate=1
+savescripts=0
+verbose=0
+while getopts :yd:DRS OPT; do
case $OPT in
y)
answer=Y
@@ -145,15 +148,33 @@ while getopts :yd: OPT; do
d)
target_sdk_dir=$OPTARG
;;
+ D)
+ verbose=1
+ ;;
+ R)
+ relocate=0
+ savescripts=1
+ ;;
+ S)
+ savescripts=1
+ ;;
*)
echo Usage: $(basename $0) [-y] [-d dir]
echo -y Automatic yes to all prompts
echo -d dir Install the SDK to dir
+ echo Advanced DEBUGGING ONLY OPTIONS
+ echo -S Save relocation scripts
+ echo -R Do not relocate executables
+ echo -D use set -x to see what is going on
exit 1
;;
esac
done
+if [ $verbose = 1 ] ; then
+ set -x
+fi
+
printf Enter target directory for SDK (default: $DEFAULT_INSTALL_DIR):
if [ $target_sdk_dir = ]; then
read target_sdk_dir
@@ -231,10 +252,15 @@ if [ $dl_path = ] ; then
exit 1
fi
executable_files=$($SUDO_EXEC find $native_sysroot -type f -perm +111)
-$SUDO_EXEC ${env_setup_script%/*}/relocate_sdk.py $target_sdk_dir $dl_path
$executable_files
-if [ $? -ne 0 ]; then
- echo SDK could not be set up. Relocate script failed. Abort!
- exit 1
+echo #!/bin/bash ${env_setup_script%/*}/relocate_sdk.sh
+echo exec $SUDO_EXEC ${env_setup_script%/*}/relocate_sdk.py $target_sdk_dir
$dl_path $executable_files ${env_setup_script%/*}/relocate_sdk.sh
+chmod 755 ${env_setup_script%/*}/relocate_sdk.sh
+if [ $relocate = 1 ] ; then
+ ${env_setup_script%/*}/relocate_sdk.sh
+ if [ $? -ne 0 ]; then
+ echo SDK could not be set up. Relocate script failed. Abort!
+ exit 1
+ fi
fi
# replace ${SDKPATH} with the new prefix in all text files: configs/scripts/etc
@@ -249,7 +275,9 @@ echo done
# delete the relocating script, so that user is forced to re-run the installer
# if he/she wants another location for the sdk
-$SUDO_EXEC rm ${env_setup_script%/*}/relocate_sdk.py
+if [ $savescripts = 0 ] ; then
+ $SUDO_EXEC rm ${env_setup_script%/*}/relocate_sdk.py
${env_setup_script%/*}/relocate_sdk.sh
+fi
echo SDK has been successfully set up and is ready to be used.
--
1.7.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] populate_sdk_base.bbclass: Work around bugs with gnu tar 1.24
The gnu tar versions less than 1.24 pose a problem with the SDK
extraction. A typical SDK will have hard links. The SDK is created
with a newer version of tar but extracted with the host version of tar
which may be much older. The specific defect is that older version of
gnu tar do not properly handle the --strip-components= argument when
processing hard links and the paths do not get properly truncated and
hooked up with the corresponding real file payloads. This leads to
errors like the following during the SDK install:
tar: sysroots/qemux86-yocto-linux/usr/bin/getconf: Cannot hard link to
`./opt/yocto/SDK-qemux86/sysroots/qemux86-yocto-linux/usr/bin/POSIX_V6_ILP32_OFFBIG':
No such file or directory
The simple way to work around the problem is to just not save the path
information that is going to get chopped off anyway. This has the
added benefit that it saves a small amount of space in the tar archive
as well.
Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
meta/classes/populate_sdk_base.bbclass |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/meta/classes/populate_sdk_base.bbclass
b/meta/classes/populate_sdk_base.bbclass
index c1756e8..da846b4 100644
--- a/meta/classes/populate_sdk_base.bbclass
+++ b/meta/classes/populate_sdk_base.bbclass
@@ -113,7 +113,7 @@ fakeroot create_sdk_files() {
fakeroot tar_sdk() {
# Package it up
mkdir -p ${SDK_DEPLOY}
- cd ${SDK_OUTPUT}
+ cd ${SDK_OUTPUT}/${SDKPATH}
tar --owner=root --group=root -cj
--file=${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.tar.bz2 .
}
@@ -130,7 +130,6 @@ if [ $INST_ARCH != $SDK_ARCH ]; then
fi
DEFAULT_INSTALL_DIR=${SDKPATH}
-COMPONENTS_LEN=$(echo .${SDKPATH} | sed s/\// /g | wc -w)
SUDO_EXEC=
target_sdk_dir=
answer=
@@ -212,7 +211,7 @@ fi
payload_offset=$(($(grep -na -m1 ^MARKER:$ $0|cut -d':' -f1) + 1))
printf Extracting SDK...
-tail -n +$payload_offset $0| $SUDO_EXEC tar xj
--strip-components=$COMPONENTS_LEN -C $target_sdk_dir
+tail -n +$payload_offset $0| $SUDO_EXEC tar xj -C $target_sdk_dir
echo done
printf Setting it up...
--
1.7.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] populate_sdk_base.bbclass: make failure to find ld-linux.so a hard error
The shell archive that populates the external SDK should fail if it
cannot find the ld-linux.so else it will corrupt all binaries because
a random path will be used from the list of executables when dl_path
is empty.
Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
meta/classes/populate_sdk_base.bbclass |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/meta/classes/populate_sdk_base.bbclass
b/meta/classes/populate_sdk_base.bbclass
index ac34c32..73bd44d 100644
--- a/meta/classes/populate_sdk_base.bbclass
+++ b/meta/classes/populate_sdk_base.bbclass
@@ -176,6 +176,10 @@ done
# fix dynamic loader paths in all ELF SDK binaries
native_sysroot=$(cat $env_setup_script |grep OECORE_NATIVE_SYSROOT|cut -d'='
-f2|tr -d '')
dl_path=$(find $native_sysroot/lib -name ld-linux*)
+if [ $dl_path = ] ; then
+ echo SDK could not be set up. Relocate script to find ld-linux.so.
Abort!
+ exit 1
+fi
executable_files=$(find $native_sysroot -type f -perm +111)
${env_setup_script%/*}/relocate_sdk.py $target_sdk_dir $dl_path
$executable_files
if [ $? -ne 0 ]; then
--
1.7.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] populate_sdk_base.bbclass: make failure to find ld-linux.so a hard error
On 11/30/2012 01:34 PM, Jason Wessel wrote:
The shell archive that populates the external SDK should fail if it
cannot find the ld-linux.so else it will corrupt all binaries because
a random path will be used from the list of executables when dl_path
is empty.
Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
meta/classes/populate_sdk_base.bbclass | 4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/meta/classes/populate_sdk_base.bbclass
b/meta/classes/populate_sdk_base.bbclass
index ac34c32..73bd44d 100644
--- a/meta/classes/populate_sdk_base.bbclass
+++ b/meta/classes/populate_sdk_base.bbclass
@@ -176,6 +176,10 @@ done
# fix dynamic loader paths in all ELF SDK binaries
native_sysroot=$(cat $env_setup_script |grep OECORE_NATIVE_SYSROOT|cut -d'='
-f2|tr -d '')
dl_path=$(find $native_sysroot/lib -name ld-linux*)
+if [ $dl_path = ] ; then
+ echo SDK could not be set up. Relocate script to find ld-linux.so. Abort!
Ooops Should be.
+echo SDK could not be set up. Relocate script unable to find ld-linux.so.
Abort!
+ exit 1
+fi
executable_files=$(find $native_sysroot -type f -perm +111)
${env_setup_script%/*}/relocate_sdk.py $target_sdk_dir $dl_path
$executable_files
if [ $? -ne 0 ]; then
Jason.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] cml1.bbclass: Convert tab indentation in python functions into four-space
Based on the previous commit 604d46c686d06d62d5a07b9c7f4fa170f99307d8
(Convert tab indentation in python functions into four-space), the
cml.bbclass was not converted, and in order to properly extend it
with external bbappend's it needs to be converted.
Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
meta/classes/cml1.bbclass | 28 ++--
1 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/meta/classes/cml1.bbclass b/meta/classes/cml1.bbclass
index 37ed792..ba44196 100644
--- a/meta/classes/cml1.bbclass
+++ b/meta/classes/cml1.bbclass
@@ -15,23 +15,23 @@ HOSTLDFLAGS = ${BUILD_LDFLAGS}
HOST_LOADLIBES = -lncurses
python do_menuconfig() {
-try:
-mtime = os.path.getmtime(.config)
-except OSError:
-mtime = 0
+try:
+mtime = os.path.getmtime(.config)
+except OSError:
+mtime = 0
-oe_terminal(${SHELL} -c \make menuconfig; if [ $? -ne 0 ]; then echo
'Command failed.'; printf 'Press any key to continue... '; read r; fi\,
'${PN} Configuration', d)
+oe_terminal(${SHELL} -c \make menuconfig; if [ $? -ne 0 ]; then echo
'Command failed.'; printf 'Press any key to continue... '; read r; fi\,
'${PN} Configuration', d)
-# FIXME this check can be removed when the minimum bitbake version has
been bumped
-if hasattr(bb.build, 'write_taint'):
-try:
-newmtime = os.path.getmtime(.config)
-except OSError:
-newmtime = 0
+# FIXME this check can be removed when the minimum bitbake version has
been bumped
+if hasattr(bb.build, 'write_taint'):
+try:
+newmtime = os.path.getmtime(.config)
+except OSError:
+newmtime = 0
-if newmtime mtime:
-bb.note(Configuration changed, recompile will be forced)
-bb.build.write_taint('do_compile', d)
+if newmtime mtime:
+bb.note(Configuration changed, recompile will be forced)
+bb.build.write_taint('do_compile', d)
}
do_menuconfig[depends] += ncurses-native:do_populate_sysroot
do_menuconfig[nostamp] = 1
--
1.7.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] packageinfo.bbclass: Fix crash in hob
The hob internally fails after executing a build and invoking
the hob a second time when it tries to use the values found in
BUILDDIR/tmp/pkgdata/*/runtime/*
The internal failure of the hob will manifest itself as
stating Populated recipes 99% forever after selecting
a machine just after starting the hob interface.
The internal trace looks like:
Traceback (most recent call last):
File packageinfo_handler(e), line 24, in packageinfo_handler
KeyError: 'PKGV'
It is a result of using an override for a package version for
pieces of the toolchain, in the bb file e.g.
PKGV_gdb-dbg = 1234.5678
The work around for now is to populate the sdata PKGV value
and to assign the pkgv variable with the correct value
from the values found in the pkgdata store.
Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
meta/classes/packageinfo.bbclass |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/meta/classes/packageinfo.bbclass b/meta/classes/packageinfo.bbclass
index 26cce60..53965e4 100644
--- a/meta/classes/packageinfo.bbclass
+++ b/meta/classes/packageinfo.bbclass
@@ -18,7 +18,12 @@ python packageinfo_handler () {
sdata = oe.packagedata.read_pkgdatafile(root + pkgname)
sdata['PKG'] = pkgname
pkgrename = sdata['PKG_%s' % pkgname]
-pkgv = sdata['PKGV'].replace('-', '+')
+try:
+pkgv = sdata['PKGV']
+except:
+ sdata['PKGV'] = sdata['PKGV_%s' % pkgname]
+pkgv = sdata['PKGV']
+pkgv = pkgv.replace('-', '+')
pkgr = sdata['PKGR']
# We found there are some renaming issue with certain
architecture.
# For example, armv7a-vfp-neon, it will use armv7a in
the rpm file. This is the workaround for it.
--
1.7.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] packageinfo.bbclass: Fix crash in hob
On 09/06/2012 03:36 PM, Paul Eggleton wrote:
On Thursday 06 September 2012 13:53:54 Jason Wessel wrote:
The hob internally fails after executing a build and invoking
the hob a second time when it tries to use the values found in
BUILDDIR/tmp/pkgdata/*/runtime/*
The internal failure of the hob will manifest itself as
stating Populated recipes 99% forever after selecting
a machine just after starting the hob interface.
The internal trace looks like:
Traceback (most recent call last):
File packageinfo_handler(e), line 24, in packageinfo_handler
KeyError: 'PKGV'
It is a result of using an override for a package version for
pieces of the toolchain, in the bb file e.g.
PKGV_gdb-dbg = 1234.5678
The work around for now is to populate the sdata PKGV value
and to assign the pkgv variable with the correct value
from the values found in the pkgdata store.
Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
meta/classes/packageinfo.bbclass | 7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/meta/classes/packageinfo.bbclass
b/meta/classes/packageinfo.bbclass index 26cce60..53965e4 100644
--- a/meta/classes/packageinfo.bbclass
+++ b/meta/classes/packageinfo.bbclass
@@ -18,7 +18,12 @@ python packageinfo_handler () {
sdata = oe.packagedata.read_pkgdatafile(root +
pkgname) sdata['PKG'] = pkgname
pkgrename = sdata['PKG_%s' % pkgname]
- pkgv = sdata['PKGV'].replace('-', '+')
+ try:
+ pkgv = sdata['PKGV']
+ except:
+ sdata['PKGV'] = sdata['PKGV_%s' % pkgname]
+ pkgv = sdata['PKGV']
+ pkgv = pkgv.replace('-', '+')
pkgr = sdata['PKGR']
# We found there are some renaming issue with
certain architecture. # For example, armv7a-vfp-neon, it will use armv7a in
the rpm file. This is the workaround for it.
Rather than a blanket try...except which could catch other errors I would
suggest using .get() to which you can supply a default value if no such key
exists in the dict.
I'm afraid I didn't get around to determining whether we should be recording
these package name overrides in the pkgdata files today, I will check into
that
tomorrow.
Honestly I don't care how we fix it, and I believe the fix I proposed
should be changed over to the writer side. If nothing else this patch
is meant to illustrate or call out the problem.
You'll note I had to actually set the sdata['PKGV'] because it turns
out it is used directly elsewhere in the hob and things started
falling over without fixing it. This leads us to the possibility that
the writer of the data store is probably wrong, at least for PKGV
anyway. On the other hand there might be other implicit assumptions
that are broken.
What I find odd is that this does work when the pkgdata store is not
there which leads me to believe it was never written out properly in
the first place or the data isn't always needed. The hob, to me looks
like a piece of spaghetti, so without further investigation I cannot
make a concise claim about the correct fix. I am hoping someone else
might take a further look at it who knows more about the hob
interface.
Jason.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [RFC PATCH 0/1] package.bbclass, task.bbclass: Allow doc-pkgs in EXTRA_IMAGE_FEATURES
This is an RFC because I am not entirely sure this is the right way to fix this problem. The problem specifically is that of getting the doc-pkgs package group to work properly. After getting a fix for this, it will be possible to update the Yocto documentation to reflect the working doc-pkgs IMAGE_FEATURE. Testing shows that it works as desired, but it is not clear if there is any architectural side effects. Thanks, Jason. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [RFC PATCH 1/1] package.bbclass, task.bbclass: Allow doc-pkgs in EXTRA_IMAGE_FEATURES
The doc-pkgs package group is defined, but some of the plumbing is
missing to allow it to work like the dbg-pkgs and dev-pkgs. This
patch adds the plumbing to allow you to specify doc-pkgs to install
all the documentation packages that correspond to the other installed
packages on the target file system in a similar manner to the dbg-pkgs.
[Yocto #2614]
Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
meta/classes/package.bbclass |4
meta/classes/task.bbclass |2 +-
meta/conf/bitbake.conf|2 +-
meta/recipes-core/tasks/task-core-boot.bb |1 +
4 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
index 10c2f0a..3145f88 100644
--- a/meta/classes/package.bbclass
+++ b/meta/classes/package.bbclass
@@ -1616,6 +1616,8 @@ python package_depchains() {
depend = depend.replace('-dev', '')
if depend.endswith('-dbg'):
depend = depend.replace('-dbg', '')
+ if depend.endswith('-doc'):
+ depend = depend.replace('-doc', '')
pkgname = getname(depend, suffix)
#bb.note(Adding %s for %s % (pkgname, depend))
if pkgname not in rreclist:
@@ -1637,6 +1639,8 @@ python package_depchains() {
depend = depend.replace('-dev', '')
if depend.endswith('-dbg'):
depend = depend.replace('-dbg', '')
+ if depend.endswith('-doc'):
+ depend = depend.replace('-doc', '')
pkgname = getname(depend, suffix)
#bb.note(Adding %s for %s % (pkgname, depend))
if pkgname not in rreclist:
diff --git a/meta/classes/task.bbclass b/meta/classes/task.bbclass
index 22c2fd3..0704b42 100644
--- a/meta/classes/task.bbclass
+++ b/meta/classes/task.bbclass
@@ -20,7 +20,7 @@ python () {
packages = d.getVar('PACKAGES', True).split()
genpackages = []
for pkg in packages:
-for postfix in ['-dbg', '-dev']:
+for postfix in ['-dbg', '-dev', '-doc']:
genpackages.append(pkg+postfix)
d.setVar('PACKAGES', ' '.join(packages+genpackages))
}
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 97930a7..f60aafe 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -233,7 +233,7 @@ HOMEPAGE = unknown
# Ensure that -dev packages recommend the corresponding -dev packages of their
# deps, and the same for -dbg.
DEPCHAIN_PRE =
-DEPCHAIN_POST = -dev -dbg
+DEPCHAIN_POST = -dev -dbg -doc
DEPENDS =
RDEPENDS =
diff --git a/meta/recipes-core/tasks/task-core-boot.bb
b/meta/recipes-core/tasks/task-core-boot.bb
index 6487436..7ca2098 100644
--- a/meta/recipes-core/tasks/task-core-boot.bb
+++ b/meta/recipes-core/tasks/task-core-boot.bb
@@ -28,6 +28,7 @@ PACKAGES = \
task-core-boot \
task-core-boot-dbg \
task-core-boot-dev \
+task-core-boot-doc \
RDEPENDS_task-core-boot = \
--
1.7.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] lsof: Fix cross 32 - 64bit ranlib host contamination problem
When building on a 32bit host OS and building 64 bit binaries,
the cross ar and ranlib must be called, or you get an error
as follows:
x86_64-wrs-linux-gcc-m64 --sysroot=/opt/build/tmp/sysroots/qemux86-64 -o
lsof dfile.o dmnt.o dnode.o dproc.o dsock.o dstore.o arg.o main.o misc.o node.o
print.o proc.o store.o usage.o util.o -Wl,-O1 -Wl,--hash-style=gnu
-Wl,--as-needed -L./lib -llsof
./lib/liblsof.a: could not read symbols: Archive has no index; run ranlib to
add one
collect2: error: ld returned 1 exit status
Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
meta/recipes-extended/lsof/lsof_4.85.bb |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-extended/lsof/lsof_4.85.bb
b/meta/recipes-extended/lsof/lsof_4.85.bb
index 8f25e24..5823725 100644
--- a/meta/recipes-extended/lsof/lsof_4.85.bb
+++ b/meta/recipes-extended/lsof/lsof_4.85.bb
@@ -3,7 +3,7 @@ DESCRIPTION = Lsof is a Unix-specific diagnostic tool. \
Its name stands for LiSt Open Files, and it does just that.
SECTION = devel
LICENSE = BSD
-PR = r0
+PR = r1
SRC_URI = ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/lsof_${PV}.tar.bz2;
@@ -29,6 +29,8 @@ LSOF_OS_libc-glibc = linux
export LSOF_INCLUDE = ${STAGING_INCDIR}
do_configure () {
+ export LSOF_AR=${AR} cr
+ export LSOF_RANLIB=${RANLIB}
yes | ./Configure ${LSOF_OS}
}
--
1.7.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] libnewt: Fix cross link using autoconf detected AR
If building on 32bit host and creating 64bit libraries, the target
package builds should not invoke the 32bit hosts's ar. Specifically
you will get an error message like:
x86_64-linux-gcc-m64 --sysroot=/opt/qemux86-64/tmp/sysroots/qemux86-64 -g
-o test test.o libnewt.a -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -lslang
libnewt.a: could not read symbols: Archive has no index; run ranlib to add one
collect2: error: ld returned 1 exit status
Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
meta/recipes-extended/newt/files/cross_ar.patch | 51 +++
meta/recipes-extended/newt/libnewt_0.52.14.bb |5 +-
2 files changed, 54 insertions(+), 2 deletions(-)
create mode 100644 meta/recipes-extended/newt/files/cross_ar.patch
diff --git a/meta/recipes-extended/newt/files/cross_ar.patch
b/meta/recipes-extended/newt/files/cross_ar.patch
new file mode 100644
index 000..f67239a
--- /dev/null
+++ b/meta/recipes-extended/newt/files/cross_ar.patch
@@ -0,0 +1,51 @@
+Fix cross link using autoconf detected AR
+
+If building on 32bit host and creating 64bit libraries, the target
+package builds should not invoke the 32bit hosts's ar. Specifically
+you will get an error message like:
+
+x86_64-linux-gcc-m64 --sysroot=/opt/qemux86-64/tmp/sysroots/qemux86-64 -g
-o test test.o libnewt.a -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -lslang
+libnewt.a: could not read symbols: Archive has no index; run ranlib to add one
+collect2: error: ld returned 1 exit status
+
+Signed-off-by: Jason Wessel jason.wes...@windriver.com
+
+Upstream-Status: Pending
+
+---
+ Makefile.in |3 ++-
+ configure.ac |4
+ 2 files changed, 6 insertions(+), 1 deletion(-)
+
+--- a/Makefile.in
b/Makefile.in
+@@ -7,6 +7,7 @@ CFLAGS = @CFLAGS@
+ LDFLAGS = @LDFLAGS@
+ CPPFLAGS = -D_GNU_SOURCE @CPPFLAGS@
+ GNU_LD = @GNU_LD@
++AR = @AR@
+
+ VERSION = @VERSION@
+ TAG = r$(subst .,-,$(VERSION))
+@@ -95,7 +96,7 @@ whiptcl.so: $(WHIPTCLOBJS) $(LIBNEWTSH)
+ $(CC) -shared $(SHCFLAGS) $(LDFLAGS) -o whiptcl.so $(WHIPTCLOBJS) -L.
-lnewt $(LIBTCL) -lpopt $(LIBS)
+
+ $(LIBNEWT): $(LIBOBJS)
+- ar rv $@ $^
++ $(AR) rv $@ $^
+
+ newt.o $(SHAREDDIR)/newt.o: newt.c Makefile
+
+--- a/configure.ac
b/configure.ac
+@@ -14,6 +14,10 @@ AC_PROG_CC
+ AC_PROG_INSTALL
+ AC_PROG_LN_S
+ AC_PROG_GREP
++AN_MAKEVAR([AR], [AC_PROG_AR])
++AN_PROGRAM([ar], [AC_PROG_AR])
++AC_DEFUN([AC_PROG_AR], [AC_CHECK_TOOL(AR, ar, :)])
++AC_PROG_AR
+
+ # Are we using GNU ld?
+ AC_MSG_CHECKING([for GNU ld])
diff --git a/meta/recipes-extended/newt/libnewt_0.52.14.bb
b/meta/recipes-extended/newt/libnewt_0.52.14.bb
index 8a89eb7..0208695 100644
--- a/meta/recipes-extended/newt/libnewt_0.52.14.bb
+++ b/meta/recipes-extended/newt/libnewt_0.52.14.bb
@@ -17,11 +17,12 @@ LIC_FILES_CHKSUM =
file://COPYING;md5=55ca817ccb7d5b5b66355690e9abc605
# slang needs to be = 2.2
DEPENDS = slang popt
-PR = r0
+PR = r1
SRC_URI = https://fedorahosted.org/releases/n/e/newt/newt-${PV}.tar.gz \
file://remove_slang_include.patch \
- file://fix_SHAREDDIR.patch
+ file://fix_SHAREDDIR.patch \
+ file://cross_ar.patch
SRC_URI[md5sum] = eb78c6bb658b92ec7198908b5b8d0e37
SRC_URI[sha256sum] =
f70f4f58baa60388ddf2e39249ffb00898fb40f2b2767e42e2ab51fe4b40978e
--
1.7.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] v86d: Fix cross link using host-cross ar
If building on 32bit host and creating 64bit libraries, the target
package builds should not invoke the 32bit hosts's ar. Specifically
you will get an error message like:
x86_64-linux-gcc -m64 --sysroot=/opt/qemux86-64/tmp/sysroots/qemux86-64
-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -Llibs/x86emu v86_x86emu.o
v86_mem.o v86_common.o v86.o -lx86emu -o v86d
libs/x86emu/libx86emu.a: could not read symbols: Archive has no index; run
ranlib to add one
collect2: error: ld returned 1 exit status
Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
meta/recipes-bsp/v86d/v86d/ar-from-env.patch | 33 ++
meta/recipes-bsp/v86d/v86d_0.1.10.bb |5 ++-
2 files changed, 36 insertions(+), 2 deletions(-)
create mode 100644 meta/recipes-bsp/v86d/v86d/ar-from-env.patch
diff --git a/meta/recipes-bsp/v86d/v86d/ar-from-env.patch
b/meta/recipes-bsp/v86d/v86d/ar-from-env.patch
new file mode 100644
index 000..1dcbc71
--- /dev/null
+++ b/meta/recipes-bsp/v86d/v86d/ar-from-env.patch
@@ -0,0 +1,33 @@
+Fix cross link using host-cross ar
+
+If building on 32bit host and creating 64bit libraries, the target
+package builds should not invoke the 32bit hosts's ar. Specifically
+you will get an error message like:
+
+x86_64-linux-gcc -m64 --sysroot=/opt/qemux86-64/tmp/sysroots/qemux86-64
-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -Llibs/x86emu v86_x86emu.o
v86_mem.o v86_common.o v86.o -lx86emu -o v86d
+libs/x86emu/libx86emu.a: could not read symbols: Archive has no index; run
ranlib to add one
+collect2: error: ld returned 1 exit status
+
+Signed-off-by: Jason Wessel jason.wes...@windriver.com
+
+Upstream-Status: Pending
+
+---
+ libs/x86emu/Makefile |6 +-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+--- a/libs/x86emu/Makefile
b/libs/x86emu/Makefile
+@@ -1,7 +1,11 @@
+ OBJS = decode.o fpu.o ops.o ops2.o prim_ops.o sys.o
+
++ifeq ($(AR),)
++ AR = ar
++endif
++
+ libx86emu.a: $(OBJS)
+- ar rv $@ $+
++ $(AR) rv $@ $+
+
+ %.o: %.c
+ $(CC) -c $(CFLAGS) -o $@ $
diff --git a/meta/recipes-bsp/v86d/v86d_0.1.10.bb
b/meta/recipes-bsp/v86d/v86d_0.1.10.bb
index 70db6ad..ce1fe7a 100644
--- a/meta/recipes-bsp/v86d/v86d_0.1.10.bb
+++ b/meta/recipes-bsp/v86d/v86d_0.1.10.bb
@@ -7,10 +7,11 @@ LIC_FILES_CHKSUM =
file://README;md5=94ac1971e4f2309dc322d598e7b1f7dd
DEPENDS = virtual/kernel
RRECOMMENDS_${PN} = kernel-module-uvesafb
-PR = r0
+PR = r1
SRC_URI =
http://dev.gentoo.org/~spock/projects/uvesafb/archive/v86d-${PV}.tar.bz2 \
- file://fbsetup
+ file://fbsetup \
+ file://ar-from-env.patch
SRC_URI[md5sum] = 51c792ba7b874ad8c43f0d3da4cfabe0
SRC_URI[sha256sum] =
634964ae18ef68c8493add2ce150e3b4502badeb0d9194b4bd81241d25e6735c
--
1.7.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] perl: Allow perl to cross build and native build in a directory named t
On 06/05/2012 03:25 PM, Flanagan, Elizabeth wrote: On Mon, Jun 4, 2012 at 11:47 AM, Jason Wessel jason.wes...@windriver.com wrote: If any directory in leading up to your tmp directory has the name t perl will fail to build with a very cryptic error shown below: Jason, I'm currently testing this patch and it seems to be causing failures during do_compile for poky-tiny http://autobuilder.yoctoproject.org:8010/builders/nightly-tiny/builds/71/steps/shell_35/logs/stdio | /bin/ln -s perldelta.pod pod/perl5142delta.pod | ./miniperl -Ilib autodoc.pl | make[1]: ./miniperl: Command not found | make[1]: *** [pod/perlintern.pod] Error 127 | make[1]: Leaving directory `/srv/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-tiny/build/build/tmp/work/i586-poky-linux/perl-5.14.2-r7/perl-5.14.2' | make: *** [perl] Error 2 | ERROR: oe_runmake failed Did this work before the patch was applied? If miniperl cannot be found it usually indicates some other kind of other perl configuration problem. How do you setup poky-tiny? The http URL you pointed me to doesn't have the local.conf in it. Or is it the case you set those environment variables and then try to execute a build? Thanks, Jason. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] perl: Allow perl to cross build and native build in a directory named t
If any directory in leading up to your tmp directory has the name t
perl will fail to build with a very cryptic error shown below:
pod/buildtoc: no pods at pod/buildtoc line 305.
make[1]: *** [pod/perltoc.pod] Error 255
This is a result of the perl file checking making an assumption
that it is only looking at files and directories with in the perl
source directory. This assumption fails with the way bitbake
sets up perl to properly cross compile.
Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
.../perl/perl-5.14.2/perl-build-in-t-dir.patch | 42
meta/recipes-devtools/perl/perl-native_5.14.2.bb |5 ++-
meta/recipes-devtools/perl/perl_5.14.2.bb |3 +-
3 files changed, 47 insertions(+), 3 deletions(-)
create mode 100644
meta/recipes-devtools/perl/perl-5.14.2/perl-build-in-t-dir.patch
diff --git a/meta/recipes-devtools/perl/perl-5.14.2/perl-build-in-t-dir.patch
b/meta/recipes-devtools/perl/perl-5.14.2/perl-build-in-t-dir.patch
new file mode 100644
index 000..16064ed
--- /dev/null
+++ b/meta/recipes-devtools/perl/perl-5.14.2/perl-build-in-t-dir.patch
@@ -0,0 +1,42 @@
+Upstream-Status:Pending
+
+Perl cannot cross build in a path containing a directory that has the
+name of t. As an example, you can make the perl build fail with
+mkdir -p /tmp/build/t, go to the directory, unpack the sources,
+configure and cross build.
+
+You get an error like the following:
+pod/buildtoc: no pods at pod/buildtoc line 305.
+make[1]: *** [pod/perltoc.pod] Error 255
+
+The fix is to strip off the top directory that you are building in and
+then execute all the same logic as before against the path relative to
+the build directory.
+
+Signed-off-by: Jason Wessel jason.wes...@windriver.com
+---
+ pod/buildtoc |4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/pod/buildtoc
b/pod/buildtoc
+@@ -274,8 +274,10 @@ if ($Build{toc}) {
+ find \getpods = abs_from_top('lib/');
+
+ sub getpods {
++my $Top = $FindBin::Bin;
+ if (/\.p(od|m)$/) {
+ my $file = $File::Find::name;
++ $file =~ s!^$Top!!;
+ return if $file =~ qr!/lib/Pod/Functions.pm\z!; # Used only by pod
itself
+ return if $file =~ m!(?:^|/)t/!;
+ return if $file =~ m!lib/Attribute/Handlers/demo/!;
+@@ -283,7 +285,7 @@ if ($Build{toc}) {
+ return if $file =~ m!lib/Math/BigInt/t/!;
+ return if $file =~ m!/Devel/PPPort/[Hh]arness|lib/Devel/Harness!i;
+ return if $file =~ m!XS/(?:APItest|Typemap)!;
+- my $pod = $file;
++ my $pod = $file = $File::Find::name;
+ return if $pod =~ s/pm$/pod/ -e $pod;
+ unless (open my $f, '', $_) {
+ warn $0: bogus $file: $!;
diff --git a/meta/recipes-devtools/perl/perl-native_5.14.2.bb
b/meta/recipes-devtools/perl/perl-native_5.14.2.bb
index c904c37..df8f058 100644
--- a/meta/recipes-devtools/perl/perl-native_5.14.2.bb
+++ b/meta/recipes-devtools/perl/perl-native_5.14.2.bb
@@ -4,7 +4,7 @@ SECTION = libs
LICENSE = Artistic-1.0 | GPL-1.0
LIC_FILES_CHKSUM = file://Copying;md5=2b4c6ffbcfcbdee469f02565f253d81a \
file://Artistic;md5=f921793d03cc6d63ec4b15e9be8fd3f8
-PR = r0
+PR = r1
LIC_FILES_CHKSUM = file://Copying;md5=2b4c6ffbcfcbdee469f02565f253d81a \
file://Artistic;md5=f921793d03cc6d63ec4b15e9be8fd3f8
@@ -14,7 +14,8 @@ SRC_URI = http://www.cpan.org/src/5.0/perl-${PV}.tar.gz \
file://perl-configpm-switch.patch \
file://native-nopacklist.patch \
file://native-perlinc.patch \
- file://MM_Unix.pm.patch
+ file://MM_Unix.pm.patch \
+ file://perl-build-in-t-dir.patch
SRC_URI[md5sum] = 3306fbaf976dcebdcd49b2ac0be00eb9
SRC_URI[sha256sum] =
6488359573bd7d41761bf935f66f827dc220fb3df961ef9b775d51fbd66548d3
diff --git a/meta/recipes-devtools/perl/perl_5.14.2.bb
b/meta/recipes-devtools/perl/perl_5.14.2.bb
index 809fc72..2452a44 100644
--- a/meta/recipes-devtools/perl/perl_5.14.2.bb
+++ b/meta/recipes-devtools/perl/perl_5.14.2.bb
@@ -7,7 +7,7 @@ LIC_FILES_CHKSUM =
file://Copying;md5=2b4c6ffbcfcbdee469f02565f253d81a \
# We need gnugrep (for -I)
DEPENDS = virtual/db grep-native
DEPENDS += gdbm zlib
-PR = r6
+PR = r7
# 5.10.1 has Module::Build built-in
PROVIDES += libmodule-build-perl
@@ -65,6 +65,7 @@ SRC_URI = http://www.cpan.org/src/5.0/perl-${PV}.tar.gz \
file://perl-enable-gdbm.patch \
file://cross-generate_uudmap.patch \
file://fix_bad_rpath.patch \
+ file://perl-build-in-t-dir.patch \
\
file://config.sh \
file://config.sh-32 \
--
1.7.10
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] ccache: Separate out into its own class
On 05/29/2012 07:29 AM, Richard Purdie wrote: Currently, ccache is used if it is present. When building from scratch it gives no performance improvement and creates a ton of empty directories even when its not in use. This change moves ccache support to a bbclass file which the user can choose to enable. This should make builds more determinstic and make it easier/clearer to the end user when its being used and when it is not. Are the sstate sums the same with and without the use of the new bbclass ccache? It is not clear to me that this is or is not the case based on this single commit header. Jason. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] recipes-devtools/qemu/qemu.inc: Add jpeg as a dependency
If you use a shared state cache and build a large file system, followed by a small one, the qemu will be built with jpeg support. Building ultra small file systems leaves out jpeg as a dependency for the host tool, and when using a sstate cache you end up with the following error using runqemu: qemu: error while loading shared libraries: libjpeg.so.8: cannot open shared object file: No such file or directory The work around is to execute: bitbake jpeg-native Signed-off-by: Jason Wessel jason.wes...@windriver.com --- meta/recipes-devtools/qemu/qemu.inc |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/meta/recipes-devtools/qemu/qemu.inc b/meta/recipes-devtools/qemu/qemu.inc index 93325c3..bd9e5bf 100644 --- a/meta/recipes-devtools/qemu/qemu.inc +++ b/meta/recipes-devtools/qemu/qemu.inc @@ -1,7 +1,7 @@ DESCRIPTION = open source processor emulator HOMEPAGE = http://qemu.org; LICENSE = GPLv2 LGPLv2.1 -DEPENDS = glib-2.0 zlib alsa-lib virtual/libx11 +DEPENDS = glib-2.0 zlib alsa-lib virtual/libx11 jpeg # QEMU_TARGETS is overridable variable QEMU_TARGETS ?= arm i386 mips mipsel mips64 mips64el ppc sh4 x86_64 -- 1.7.1 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] recipes-devtools/qemu/qemu.inc: Add jpeg as a dependency
On 05/22/2012 01:46 PM, Saul Wold wrote: On 05/22/2012 11:06 AM, Jason Wessel wrote: If you use a shared state cache and build a large file system, followed by a small one, the qemu will be built with jpeg support. Is jpeg optional for qemu? Do you know why it's included in the first place? Can it be disabled via a --disable in the configure stage? Yes to both. Looks like you have already patched it a different way. I guess if someone needs the libjpeg they'll bbappend away. Thanks, Jason. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] ncurses: Disable parallel make
On 05/16/2012 09:01 PM, Xiaofeng Yan wrote:
On 2012年05月16日 19:02, Saul Wold wrote:
On 05/16/2012 01:10 PM, xiaofeng@windriver.com wrote:
From: Xiaofeng Yanxiaofeng@windriver.com
Ncurses failure non-gplv3 build by race issue. So disable parallel \
make when building this package.
This is not the best approach as you disable PARALLEL_MAKE for both
non-gplv3 and gplv3 versions. Further, we want to get rid of [M1]
setting as much as possible, so this patch is not helping that.
Did you try running on a large many core machine? It might help if you
have some other builds going also to stress the machine.
Sau!
Thanks for your reply. The most cores I have are eight. I also set
PARALLEL_MAKE=j1000 and 1. I think I need try to find new way for
fixing bugs.
Do you have an error file from a failed build (and ideally the failed build
directory)? Having diagnosed many problems like this in the past, it is
easiest to look for the failure case and add some sleep statement in the
Makefile to get it to trigger every time in the same way.
The two most common problems are:
1) autoconf re-runs due to time stamps or partially patched files
2) a generated file is reported as missing
In the first case it, it will often be some error with a .h missing or some
other strange error about a header in the compilation and it is a result of
only having a partial file because it is getting regenerated at the time.
In the second case you just find the file's rule in the Makefile and add an if
statement in the Make target goal if it is a multi-object rule to look for the
problem object and sleep a bit. I have yet to see a case I couldn't reproduce
the results by following the strategy of some forcing some extra delay. You
probably won't have to go to this length, but there was one time I even wrote a
C wrapper around a command to add some sleep controlled by an environment
variable to prove config.h was getting removed and regenerated. Example:
#include stdio.h
#include stdlib.h
#include string.h
#include unistd.h
int main(int argc, char *const argv[]) {
char *lookfor;
if (argc = 2) {
lookfor = getenv(LOOKFORSLEEP);
if (lookfor strcmp(argv[1], lookfor) == 0) {
if (argc = 3 strcmp(argv[2], config.h) == 0) {
unlink(config.h);
printf(Special sleep on command %s\n, lookfor);
sleep(2);
}
}
}
execv(/bin/sh, argv);
return 0;
}
Best of luck,
Jason.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/2] RFC - CCACHE_DIR to not impact sstate
On 05/13/2012 09:47 PM, Chris Larson wrote: On Sun, May 13, 2012 at 7:28 PM, Jason Wessel jason.wes...@windriver.com wrote: I am not exactly sure how to fix this, so I thought I might ask in the form of a working patch. The problem is that I want to use an external CCACHE_DIR on some build servers, but use the defaults on others. Ultimately the sstate sums should be the same in either case, but they are not due to the way that bitbake tracks the export variables for inclusion i the sum dependencies. My example test is to simply set CCACHE_DIR = /tmp/ccache in the local.conf and recompile the quilt-native package. I ended up adding another check to the dependency generator because simply trying to use unexport had undesired effects. If there is a better or correct way of fixing this such that CCACHE_DIR will not impact the sstate sum, I would really like to know how to do this. :-) Add it to BB_HASHBASE_WHITELIST next to other variables like TMPDIR, FILE, and BBPATH. Many thanks for the response, this definitely works for the CCACHE_DIR case. I do have a question however. With the patch I had created I was also able to add new exported variables to the local.conf like CCACHE_DISABLE on demand Example: export CCACHE_DISABLE = 1 CCACHE_DISABLE[undep] = 1 I would like to be able to do the same thing with the BB_HASHBASE_WHITELIST, like: export CCACHE_DISABLE = 1 BB_HASHBASE_WHITELIST += CCACHE_DISABLE My question is if it would be ok to move the hashbase setup above all the requires *.conf lines such that this possible? Thanks, Jason. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
