Re: [OE-core] [PATCH] u-boot: fix beaglebone boot issue with large kernel images
On Thu, 2014-04-17 at 15:05 -0400, Denys Dmytriyenko wrote:
From: Denys Dmytriyenko de...@ti.com
Fix beaglebone boot issue with large kernel images overwriting Device Tree.
See very detailed comments inside the patch.
The original patch is being reviewed upstream and is targeting mainline U-boot
version 2014.07. This is the adaptation of the patch for 2013.07 version we
use
Signed-off-by: Denys Dmytriyenko de...@ti.com
Thank you Denys, this works great. With a new u-boot.img I could boot
any kernel that before wouldn't boot.
Cheers,
Stefan
---
...h-Add-use-DEFAULT_LINUX_BOOT_ENV-environm.patch | 74
++
meta/recipes-bsp/u-boot/u-boot_2013.07.bb | 4 +-
2 files changed, 77 insertions(+), 1 deletion(-)
create mode 100644
meta/recipes-bsp/u-boot/files/0001-am335x_evm.h-Add-use-DEFAULT_LINUX_BOOT_ENV-environm.patch
diff --git
a/meta/recipes-bsp/u-boot/files/0001-am335x_evm.h-Add-use-DEFAULT_LINUX_BOOT_ENV-environm.patch
b/meta/recipes-bsp/u-boot/files/0001-am335x_evm.h-Add-use-DEFAULT_LINUX_BOOT_ENV-environm.patch
new file mode 100644
index 000..77e35bb
--- /dev/null
+++
b/meta/recipes-bsp/u-boot/files/0001-am335x_evm.h-Add-use-DEFAULT_LINUX_BOOT_ENV-environm.patch
@@ -0,0 +1,74 @@
+From 5701384cea4a829b772bf7a96a74825b58c22385 Mon Sep 17 00:00:00 2001
+From: Denys Dmytriyenko de...@ti.com
+Date: Thu, 17 Apr 2014 12:25:40 -0400
+Subject: [PATCH] am335x_evm.h: Add, use DEFAULT_LINUX_BOOT_ENV environment
+ string
+
+Modified version of the patch currently being reviewed for mainline:
+http://patchwork.ozlabs.org/patch/334861/
+
+To deal with a reoccurring problem properly we need to specify addresses
+for the Linux kernel, Flatted Device Tree and ramdisk that obey the
+constraints within the kernel's Documentation/arm/Booting file but also
+make sure that we relocate things within a valid address range.
+
+Signed-off-by: Denys Dmytriyenko de...@ti.com
+Signed-off-by: Tom Rini tr...@ti.com
+
+Upstream-Status: Pending
+---
+ include/configs/am335x_evm.h | 31 ++-
+ 1 file changed, 26 insertions(+), 5 deletions(-)
+
+diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
+index c5a6d4b..01e32b3 100644
+--- a/include/configs/am335x_evm.h
b/include/configs/am335x_evm.h
+@@ -54,10 +54,7 @@
+ #define CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
+ #ifndef CONFIG_SPL_BUILD
+ #define CONFIG_EXTRA_ENV_SETTINGS \
+-loadaddr=0x8020\0 \
+-fdtaddr=0x80F8\0 \
+-fdt_high=0x\0 \
+-rdaddr=0x8100\0 \
++DEFAULT_LINUX_BOOT_ENV \
+ bootdir=/boot\0 \
+ bootfile=uImage\0 \
+ fdtfile=undefined\0 \
+@@ -197,7 +194,31 @@
+ #define CONFIG_SYS_MEMTEST_END (CONFIG_SYS_MEMTEST_START \
+ + (8 * 1024 * 1024))
+
+-#define CONFIG_SYS_LOAD_ADDR0x8100 /* Default load
address */
++/*
++ * Our DDR memory always starts at 0x8000 and U-Boot shall have
++ * relocated itself to higher in memory by the time this value is used.
++ * However, set this to a 32MB offset to allow for easier Linux kernel
++ * booting as the default is often used as the kernel load address.
++ */
++#define CONFIG_SYS_LOAD_ADDR0x8200 /* Default load
address */
++
++/*
++ * We setup defaults based on constraints from the Linux kernel, which
should
++ * also be safe elsewhere. We have the default load at 32MB into DDR (for
++ * the kernel), FDT above 128MB (the maximum location for the end of the
++ * kernel), and the ramdisk 512KB above that (allowing for hopefully never
++ * seen large trees). We say all of this must be within the first 256MB
++ * as that will normally be within the kernel lowmem and thus visible via
++ * bootm_size and we only run on platforms with 256MB or more of memory.
++ */
++#define DEFAULT_LINUX_BOOT_ENV \
++loadaddr=0x8200\0 \
++kernel_addr_r=0x8200\0 \
++fdtaddr=0x8800\0 \
++fdt_addr_r=0x8800\0 \
++rdaddr=0x8808\0 \
++ramdisk_addr_r=0x8808\0 \
++bootm_size=0x1000\0
+
+ #define CONFIG_MMC
+ #define CONFIG_GENERIC_MMC
+--
+1.9.2
+
diff --git a/meta/recipes-bsp/u-boot/u-boot_2013.07.bb
b/meta/recipes-bsp/u-boot/u-boot_2013.07.bb
index 3141a2d..f8a8856 100644
--- a/meta/recipes-bsp/u-boot/u-boot_2013.07.bb
+++ b/meta/recipes-bsp/u-boot/u-boot_2013.07.bb
@@ -16,7 +16,9 @@ SRCREV = 62c175fbb8a0f9a926c88294ea9f7e88eb898f6c
PV = v2013.07+git${SRCPV}
-SRC_URI = git://git.denx.de/u-boot.git;branch=master
+SRC_URI = git://git.denx.de/u-boot.git;branch=master \
+
file://0001-am335x_evm.h-Add-use-DEFAULT_LINUX_BOOT_ENV-environm.patch \
+
S = ${WORKDIR}/git
--
1.9.2
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
Re: [OE-core] [PATCH] scripts/send-error-report: simple hack to use proxy from the enviroment
Actually I'll send v2 which should work for HTTP Basic Authentication
too.
On Fri, 2014-04-11 at 18:54 +0300, Stefan Stanacar wrote:
People behind a proxy couldn't send an error report to an upstream server,
this should fix the issue if they use a proxy that doesn't require
authentication,
and it's correctly exported in the enviroment.
There are probbaly better ways to fix this (urllib2, proxy connect,
a command line option for proxy) but those require more changes than
I feel confortable doing now.
Signed-off-by: Stefan Stanacar stefanx.stana...@intel.com
---
scripts/send-error-report | 27 +--
1 file changed, 21 insertions(+), 6 deletions(-)
diff --git a/scripts/send-error-report b/scripts/send-error-report
index 3734b61..0bce8b6 100755
--- a/scripts/send-error-report
+++ b/scripts/send-error-report
@@ -8,6 +8,24 @@
import httplib, urllib, os, sys, json
+from urllib2 import _parse_proxy as parseproxy
+
+
+def handle_connection(server, data):
+params = urllib.urlencode({'data': data})
+headers = {Content-type: application/json}
+
+if os.environ.get(http_proxy) or os.environ.get(HTTP_PROXY):
+proxy = parseproxy(os.environ.get(http_proxy) or
os.environ.get(HTTP_PROXY))
+if proxy[1] or proxy[2]:
+raise Exception(http proxies that require
authentication are not supported for now.)
+conn = httplib.HTTPConnection(proxy[3])
+conn.request(POST, http://%s/ClientPost/; % server,
params, headers)
+else:
+conn = httplib.HTTPConnection(server)
+conn.request(POST, /ClientPost/, params, headers)
+
+return conn
def sendData(json_file, server):
@@ -45,10 +63,7 @@ def sendData(json_file, server):
return
try:
-params = urllib.urlencode({'data': data})
-headers = {Content-type: application/json}
-conn = httplib.HTTPConnection(server)
-conn.request(POST, /ClientPost/, params, headers)
+conn = handle_connection(server, data)
response = conn.getresponse()
print response.status, response.reason
res = response.read()
@@ -59,8 +74,8 @@ def sendData(json_file, server):
with open(%s.response.html % json_file, w) as f:
f.write(res)
conn.close()
-except:
-print(Server connection failed)
+except Exception as e:
+print(Server connection failed: %s % e)
else:
print(No data file found.)
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] lsbtest: fix comparison bashism
On Sun, 2014-03-30 at 18:55 -0400, Trevor Woerner wrote: On 03/11/14 11:40, Stefan Stanacar wrote: == is a bashism use = instead. But the first line of this script is: #/bin/bash Shouldn't a bash script be allowed to have bash-isms??! I was referring to the recipe which shouldn't have bash-isms. Yes, the recipe installs a script which has /bin/bash, but I didn't saw any harm in fixing that too. Cheers, Stefan -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] core-image-lsb: enforce pam as a needed distro feature
On Mon, 2014-03-31 at 10:58 +0100, Richard Purdie wrote: On Mon, 2014-03-31 at 12:51 +0300, Cristian Iorga wrote: core-image-lsb only gave a warning: WARNING: Building libpam but 'pam' isn't in DISTRO_FEATURES, PAM won't work correctly when the proper DISTRO was not set for it. default choice would be DISTRO = poky-lsb, but not necessarily, depending on each custom distro. This fix will enforce the proper usage of pam as a distro feature for core-image-lsb by giving an error instead of just a warning. Fixes [YOCTO #6073] Signed-off-by: Cristian Iorga cristian.io...@intel.com --- meta/recipes-extended/images/core-image-lsb.bb | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/meta/recipes-extended/images/core-image-lsb.bb b/meta/recipes-extended/images/core-image-lsb.bb index ed316a6..ab61c6e 100644 --- a/meta/recipes-extended/images/core-image-lsb.bb +++ b/meta/recipes-extended/images/core-image-lsb.bb @@ -9,4 +9,6 @@ IMAGE_INSTALL = \ packagegroup-core-lsb \ -inherit core-image +inherit core-image distro_features_check + +REQUIRED_DISTRO_FEATURES = pam I have a feeling the autobuilder builds core-image-lsb in situations where DISTRO=poky, although I could be wrong. Have you checked? FWIW, all the -lsb buildsets are done with DISTRO=poky-lsb on the AB. Unfortuntely we do have one problematic build. So the answer to your question is: we don't have core-image-lsb builds with DISTRO=poky but we do have a lib64-core-image-lsb-sdk image built with DISTRO=poky and no pam in DISTRO_FEATURES, see the last build on nightly-multilib... :( Cheers, Stefan Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH 4/4] lib/oeqa: add a test target controller for EFI targets
Hi Otavio, On Thu, 2014-03-20 at 18:08 -0300, Otavio Salvador wrote: On Thu, Mar 20, 2014 at 1:29 PM, Stefan Stanacar stefanx.stana...@intel.com wrote: +# test rootfs + kernel +self.rootfs = os.path.join(d.getVar(DEPLOY_DIR_IMAGE, True), d.getVar(IMAGE_LINK_NAME, True) + '.tar.gz') +self.kernel = os.path.join(d.getVar(DEPLOY_DIR_IMAGE, True), d.getVar(KERNEL_IMAGETYPE)) +if not os.path.isfile(self.rootfs): +# we could've checked that IMAGE_FSTYPES contains tar.gz but the config for running testimage might not be +# the same as the config with which the image was build, ie +# you bitbake core-image-sato with IMAGE_FSTYPES += tar.gz +# and your autobuilder overwrites the config, adds the test bits and runs bitbake core-image-sato -c testimage +bb.fatal(No rootfs found. Did you build the image ?\nIf yes, did you build it with IMAGE_FSTYPES += \tar.gz\ ? \ + \nExpected path: %s % self.rootfs) Couldn't testimage class add it? Nope... testimage task can be triggered in two ways: from testimage.bbclass or testimage-auto.bbclass, that means: - manually: you have already built your image, then add INHERIT += testimage in local.conf and run bitbake image -c testimage (the AB does it this way). The testimage task does not have a depends on do_rootfs, so it won't create a tar.gz rootfs if IMAGE_FSTYPES wasn't added to local.conf at build time. - automatically: you add TEST_IMAGE = 1 in local.conf before bitbake image. That's a hidden inherit in image.bbclass that inherits testimage-auto that does depend on rootfs. We want to support both cases... So checking that tar.gz is IMAGE_FSTYPES doesn't mean that the image actually was built with that. Also, tar.gz might not be there although the image was built with that (The AB has two different build steps for build and running tests, and in between the config can be overwritten). +if not os.path.isfile(self.kernel): +bb.fatal(No kernel found. Expected path: %s % self.kernel) + +# if the user knows what he's doing, then by all means... +# test-rootfs.tar.gz and test-kernel are hardcoded names in other places +# they really have to be used like that in commands though +cmds = d.getVar(TEST_DEPLOY_CMDS, True) +if cmds: +self.deploy_cmds = cmds.split(\n) Good. +else: +self.deploy_cmds = [ +'mount -L boot /boot', +'mkdir -p /mnt/testrootfs', +'mount -L testrootfs /mnt/testrootfs', +'modprobe efivarfs', +'mount -t efivarfs efivarfs /sys/firmware/efi/efivars', +'cp ~/test-kernel /boot', +'rm -rf /mnt/testrootfs/*', +'tar xzvf ~/test-rootfs.tar.gz -C /mnt/testrootfs', How target see those files? NFS? Nope, see below in _deploy. Those files are scp'ed from the build machine to the target. self.master.copy_to(self.rootfs, ~/test-rootfs.tar.gz) self.master.copy_to(self.kernel, ~/test-kernel) for cmd in self.deploy_cmds: self.master.run(cmd) +r'printf \x07\x00\x00\x00\x74\x00\x65\x00\x73\x00\x74\x00\x00\x00 /sys/firmware/efi/efivars/LoaderEntryOneShot-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f' Can you elaborate this? Seems too 'black magic' for me. Okay so one of the reasons this GenericEfi target requires that the master image deployed uses gummiboot is because of that. gummiboot actually reads and obeys system EFI variables. [1] One of those variables is LoaderEntryOneShot which tells it to boot a label (kernel + rootfs) once and only once so this how we know that we always get back to the master/good image. [1] Some EFI variables control the loader or exported the loaders state to the started operating system. The vendor UUID 4a67b082-0a4c-41cf-b6c7-440b29bb8c4f and the variable names are supposed to be shared across all loaders implementations which follow this scheme of configuration: http://freedesktop.org/wiki/Software/gummiboot/ Accessing the EFI vars subsystem is done in two ways: - old sysfs-efivars interface (CONFIG_EFI_VARS), populated at /sys/firmware/efi/vars, which has some limitations (basically you need another tool to read/write) - new efivarfs interface (CONFIG_EFIVAR_FS), typically mounted like this: mount -t efivarfs efivarfs /sys/firmware/efi/efivars It was added in 3.8 intended as a replacement for the sysfs-efivars interface, has no maximum per-variable size limitation and supports UEFI Secure Boot variables. You can read more about that at: http://uefidk.intel.com/blog/accessing-uefi-variables-linux#sthash.2wI28Mkn.dpuf The first four bytes are EFI_VARIABLE_NON_VOLATILE, EFI_VARIABLE_BOOTSERVICE_ACCESS and EFI_VARIABLE_RUNTIME_ACCESS bits set in the attribute
Re: [OE-core] [poky] [RFC PATCH v2 0/3] Master image generation and testing
Hi Paul,
On Wed, 2014-03-19 at 19:05 +, Paul Eggleton wrote:
Hi Stefan,
On Monday 17 March 2014 17:42:13 Stefan Stanacar wrote:
This is what I currently use for doing automated deployment
for a genericx86-64 image. More details on the commit
messages. There is nothing particular to genericx86-64,
it should work on any EFI-enabled device with gummiboot as bootloader.
Changes since v2:
- droped the kernel options patch, the required options are now in the
default config fragments. You still neeed to build with an updated SRCREV
though, as the kernel recipes haven't picked up the changes yet.
(SRCREV_meta_pn-linux-yocto = ${AUTOREV} in local.conf)
- impove a bit the master image recipe (inherit core-image and add to
IMAGE_INSTALL instead of overwriting IMAGE_INSTALL, that ensures we pick up
the correct modules, as core-image brings in packagegroup-base-extended)
- tweaks and fixes for GenericEfi - I did a complete test run for a NUC
device connected to a web power strip. The powercontrol command is an
expect script that does ssh on a device which controls the power strip
(this is particular to a network setup that I can't control). It still
works for the no power command available case.
Also see YB#1596 and it's sub-bug #5614 for a bit of background.
Any comments, questions, most welcome.
Cheers,
Stefan
Please review the following changes for suitability for inclusion. If you
have any objections or suggestions for improvement, please respond to the
patches. If you agree with the changes, please provide your Acked-by.
The following changes since commit 92155fde2079251739f455bca599a52cd21ef12b:
bitbake: runqueue: Don't error if we never setup workers (2014-03-17
15:04:46 +)
are available in the git repository at:
git://git.yoctoproject.org/poky-contrib stefans/masterimage
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=stefans/masterimag
e
Looks good. Some review comments:
* Is all of packagegroup-core-full-cmdline really needed for the master image
or just some specific utilities that it pulls in?
No, just some specific utilities. I'm gonna change that to only those.
* Could we have TEST_POWERCONTROL_EXTRA_ARGS so that TEST_POWERCONTROL_CMD
can
be set generically for the user's setup and extra machine-specific arguments
(such as serial port numbers or other identifiers) can be set easily on a per-
machine basis if needed?
Okay, will change that.
* I wonder if TEST_DEPLOY_CMDS should be lower-case since it would be most
easily defined as a function i.e. testimage_deploy_cmds() { ... } than a
traditional variable. (Reading it is exactly the same i.e. d.getVar().)
I'd like to keep that configurable from .conf files. I did changed it be
splitted by \n.
All of this seems generic enough that I think the better place for it would
be
OE-Core rather than meta-yocto-bsp. If you could apply these changes on top
of
OE-Core and send v3 to the OE-Core mailing list that would be great.
Okay, great. I'll move everything from meta-yocto-bsp to meta and
re-send.
Cheers,
Stefan
Thanks,
Paul
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] testimage: dont use DNS lookup for qemu based testimages
On Tue, 2014-03-18 at 17:31 -0700, Saul Wold wrote:
Signed-off-by: Saul Wold s...@linux.intel.com
---
meta/classes/testimage.bbclass | 10 ++
1 file changed, 10 insertions(+)
diff --git a/meta/classes/testimage.bbclass b/meta/classes/testimage.bbclass
index 691c7f6..ee028e1 100644
--- a/meta/classes/testimage.bbclass
+++ b/meta/classes/testimage.bbclass
@@ -45,6 +45,16 @@ TESTIMAGEDEPENDS_qemuall =
qemu-native:do_populate_sysroot qemu-helper-native:d
TESTIMAGELOCK = ${TMPDIR}/testimage.lock
TESTIMAGELOCK_qemuall =
+IMAGE_POSTPROCESS_COMMAND_qemuall += fix_dns_lookup_for_qemu
+
I might be wrong, but this won't have any effect with the default
(manual) way we use testimage. The testimage class isn't in the global
inherit, so that IMAGE_POSTPROCESS_COMMAND won't run as the image isn't
reconstructed.
The AB does: bitbake core-image-sato on one step and then adds INHERIT
+=testimage in local.conf in the next step and runs bitbake
core-image-sato -c testimage, no more do_rootfs here.
As it this it will only work with testimage-auto when you have
TEST_IMAGE=1 in local.conf in the first build step so you only need to
do bitbake core-image-sato and do_testimage gets run after do_rootfs,
but we don't use this. And the fix should work for running the task
manually too.
I liked v1, I don't really see what the problem was there. No mattter
the way you run our qemu images, you still have to set a proper DNS, and
have network connectivity in the image (which usually involves the host
too) so defaulting to UseDNS no for qemu images seems a sensible default
to me.
Cheers,
Stefan
+fix_dns_lookup_for_qemu() {
+ if [ -e ${IMAGE_ROOTFS}${sysconfdir}/ssh/sshd_config ]; then
+ sed -i -e 's:#UseDNS yes:UseDNS no:'
${IMAGE_ROOTFS}${sysconfdir}/ssh/sshd_config
+ fi
+}
+
+EXPORT_FUNCTIONS fix_dns_lookup_for_qemu
+
python do_testimage() {
testimage_main(d)
}
--
1.8.3.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/3] classes: Add gummiboot class
On Wed, 2014-03-12 at 07:18 +0100, Koen Kooi wrote:
Op 11 mrt. 2014, om 22:38 heeft Darren Hart dvh...@linux.intel.com het
volgende geschreven:
On 3/7/14, 1:57, Stanacar, StefanX stefanx.stana...@intel.com wrote:
On Thu, 2014-03-06 at 14:36 -0800, Darren Hart wrote:
On 3/6/14, 10:15, Stefan Stanacar stefanx.stana...@intel.com wrote:
Adds a gummiboot class similar to grub-efi class and makes the
necessary
changes so it can be used for live/hddimg images as well.
One can set EFI_PROVIDER = gummiboot in local.conf to use gummiboot
instead of grub-efi.
Gummiboot requires some kernel options that are not enabled by default,
so one has to build
with KERNEL_FEATURES_append = cfg/efi-ext.
cfg/efi is insufficient?
cfg/efi doesn't have CONFIG_EFI_STUB=y which is required by gummiboot.
cfg/efi-ext adds more than that, it's true.
Weird... Although the STUB should probably be in efi rather than efi-ext.
I'm surprised gummiboot requires STUB... Since STUB is there to allow the
kernel to be booted directly, no bootloader required. I guess gummiboot is
slightly less than a boot loader :-)
The gummiboot docs still claim to support both 'linux' and 'efi', so it's
supposed to work.
The site claims that Linux kernels need to be built with
CONFIG_EFI_STUB, and without that for me it wouldn't boot.
What you're saying is for the config file
From the site:
efi executable EFI image
options options to pass to the EFI image / kernel command line
linux linux kernel image (gummiboot still requires the kernel to have an
EFI stub)
initrd initramfs image (gummiboot just adds this as option initrd=)
Cheers,
Stefan
regards,
Koen
I'd Ack a patch to move STUB from efi-ext to efi.
It's also a good idea to enable CONFIG_EFIVARS_FS, which is the
newer/better interface than CONFIG_EFI_VARS that cfg/efi-ext enables.
Hrm... OK, perhaps time to revisit those fragments and update them for
current usage.
--
Darren
The install scripts have been updated too, keeping the old behaviour
around,
but accounting for the new boot loader config files (if they exist).
It can be argued that the installer and bootimg are a bit wierd and not
necessarily correct,
but I wanted to have the exact same behviour with gummiboot.
With the default EFI_PROVIDER = grub-efi nothing changes, everthing
should be just as before.
I've tested live boot, install and normal boot on:
- FRI2
- genericx86-64 on NUC
with:
EFI_PROVIDER = gummiboot
KERNEL_FEATURES_append = cfg/efi-ext
in local.conf.
Signed-off-by: Stefan Stanacar stefanx.stana...@intel.com
Generally looks good. My only reservation is the same as for 2/3, should
we define an EFI interface rather than having to construct function
names
in the consumers of this class?
I don't have a strong opinion here, it just seemed the simplest way atm,
then adding another interface.
Cheers,
Stefan
--
Darren
---
meta/classes/gummiboot.bbclass | 112
+
.../initrdscripts/files/init-install-efi.sh| 51 +++---
2 files changed, 147 insertions(+), 16 deletions(-)
create mode 100644 meta/classes/gummiboot.bbclass
diff --git a/meta/classes/gummiboot.bbclass
b/meta/classes/gummiboot.bbclass
new file mode 100644
index 000..5c11286
--- /dev/null
+++ b/meta/classes/gummiboot.bbclass
@@ -0,0 +1,112 @@
+EFICLASS_FUNC_PREFIX = gummiboot
+
+do_bootimg[depends] += gummiboot:do_deploy
+do_bootdirectdisk[depends] += gummiboot:do_deploy
+
+EFIDIR = /EFI/BOOT
+
+GUMMIBOOT_CFG ?= ${S}/loader.conf
+GUMMIBOOT_ENTRIES ?=
+GUMMIBOOT_TIMEOUT ?= 10
+
+gummiboot_populate() {
+DEST=$1
+
+EFI_IMAGE=gummibootia32.efi
+DEST_EFI_IMAGE=bootia32.efi
+if [ ${TARGET_ARCH} = x86_64 ]; then
+EFI_IMAGE=gummibootx64.efi
+DEST_EFI_IMAGE=bootx64.efi
+fi
+
+install -d ${DEST}${EFIDIR}
+# gummiboot requires these paths for configuration files
+# they are not customizable so no point in new vars
+install -d ${DEST}/loader
+install -d ${DEST}/loader/entries
+install -m 0644 ${DEPLOY_DIR_IMAGE}/${EFI_IMAGE}
${DEST}${EFIDIR}/${DEST_EFI_IMAGE}
+install -m 0644 ${GUMMIBOOT_CFG} ${DEST}/loader/loader.conf
+for i in ${GUMMIBOOT_ENTRIES}; do
+install -m 0644 ${i} ${DEST}/loader/entries
+done
+}
+
+gummiboot_iso_populate() {
+iso_dir=$1
+gummiboot_populate $iso_dir
+mkdir -p ${EFIIMGDIR}/${EFIDIR}
+cp $iso_dir/${EFIDIR}/* ${EFIIMGDIR}${EFIDIR}
+cp $iso_dir/vmlinuz ${EFIIMGDIR}
+echo ${DEST_EFI_IMAGE} ${EFIIMGDIR}/startup.nsh
+if [ -f $iso_dir/initrd ] ; then
+cp $iso_dir/initrd
Re: [OE-core] libm accuracy, eglibc compared to glibc
Hello,
I just want to point out that this looks very similar to a qemuppc
machine bug we've seen before with libm and floor() call:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=4854
It was fixed with:
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=2a48e9007cc92fedfdb6919411859fb943eacc94
HTH,
Stefan
On Wed, 2014-03-12 at 15:30 +, Mats Kärrman wrote:
Hi,
I face a problem with libm. With my Dora build the following assertion
doesn't hold:
sqrt( pow( sqrt( 2.0 ), 4.0 ) ) == 2.0
1) With my old OE-classic / glibc-2.9 / PowerPC-hf it holds.
2) With my Debian desktop PC / glibc-2.17 / amd64 it holds.
3) With my new OE-core Dora / eglibc-2.18 / PowerPC-hf it doesn't hold.
Close enough one can think but the standardized test case I run requires the
result to be 2.0.
A simple test program:
#include stdio.h
#include math.h
int main(){
double two = 2.0;
double four = 4.0;
double s1 = sqrt(two);
printf(sqrt(%.20f) = %.20f\n, two, s1);
double p = pow(s1, four);
printf(pow(%.20f, %.20f) = %.20f\n, s1, four, p);
double s2 = sqrt(p);
printf(sqrt(%.20f) = %.20f\n, p, s2);
}
results from 1 and 2 (identical):
sqrt(2.) = 1.41421356237309514547
pow(1.41421356237309514547, 4.) = 4.00088818
sqrt(4.00088818) = 2.
results from 3:
sqrt(2.) = 1.41421356237309492343
pow(1.41421356237309492343, 4.) = 3.99866773
sqrt(3.99866773) = 1.99955591
Does anyone know if this is a known feature of eglibc or know any other
reason
for this difference?
Best Regards,
Mats
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/3] recipes-bsp: Add gummiboot and gnu-efi recipes
On Sun, 2014-03-09 at 00:00 -0800, Saul Wold wrote: On 03/06/2014 10:15 AM, Stefan Stanacar wrote: gummiboot is is a simple UEFI boot manager (not a boot loader ;-) ) These recipes are imported from meta-intel with these changes: - drop PR and update configure options - gummiboot was upgraded to latest version A couple of notes: - If you wish you can install the gummiboot package on the target and use 'gummiboot install' to add the payload to the ESP (see gummiboot --help, just make sure the ESP partition has the boot flag on as gummiboot won't accept it otherwise). However the point of this recipe is to be used by bootimg.bbclass and generate images with gummiboot instead of grub-efi. - You need a kernel which has CONFIG_EFI_STUB=y at least - The default linux-yocto kernel config does not enable that, easiest way to enable is to build with KERNEL_FEATURES_append = cfg/efi-ext in local.conf Signed-off-by: Stefan Stanacar stefanx.stana...@intel.com --- .../gnu-efi/gnu-efi/parallel-make-archives.patch | 48 ++ .../gnu-efi/gnu-efi/parallel-make.patch| 22 ++ meta/recipes-bsp/gnu-efi/gnu-efi_3.0u.bb | 33 +++ meta/recipes-bsp/gummiboot/gummiboot_git.bb| 25 +++ 4 files changed, 128 insertions(+) create mode 100644 meta/recipes-bsp/gnu-efi/gnu-efi/parallel-make-archives.patch create mode 100644 meta/recipes-bsp/gnu-efi/gnu-efi/parallel-make.patch create mode 100644 meta/recipes-bsp/gnu-efi/gnu-efi_3.0u.bb create mode 100644 meta/recipes-bsp/gummiboot/gummiboot_git.bb diff --git a/meta/recipes-bsp/gnu-efi/gnu-efi/parallel-make-archives.patch b/meta/recipes-bsp/gnu-efi/gnu-efi/parallel-make-archives.patch new file mode 100644 index 000..e5b47c1 --- /dev/null +++ b/meta/recipes-bsp/gnu-efi/gnu-efi/parallel-make-archives.patch @@ -0,0 +1,48 @@ +Fix parallel make failure for archives + +Upstream-Status: Pending + +The lib and gnuefi makefiles were using the lib.a() form which compiles +and ar's as a pair instead of compiling all and then ar'ing which can +parallelize better. This was resulting in build failures on larger values +of -j. + +See http://www.chemie.fu-berlin.de/chemnet/use/info/make/make_toc.html#TOC105 +for details. + +Signed-off-by: Saul Wold s...@linux.intel.com +Signed-off-by: Darren Hart dvh...@linux.intel.com +--- +--- + gnuefi/Makefile |3 ++- + lib/Makefile|3 ++- + 2 files changed, 4 insertions(+), 2 deletions(-) + +Index: gnu-efi-3.0/lib/Makefile +=== +--- gnu-efi-3.0.orig/lib/Makefile gnu-efi-3.0/lib/Makefile +@@ -66,7 +66,8 @@ all: libsubdirs libefi.a + libsubdirs: + for sdir in $(SUBDIRS); do mkdir -p $$sdir; done + +-libefi.a: $(patsubst %,libefi.a(%),$(OBJS)) ++libefi.a: $(OBJS) ++ $(AR) rv $@ $(OBJS) + + clean: + rm -f libefi.a *~ $(OBJS) */*.o +Index: gnu-efi-3.0/gnuefi/Makefile +=== +--- gnu-efi-3.0.orig/gnuefi/Makefile gnu-efi-3.0/gnuefi/Makefile +@@ -51,7 +51,8 @@ TARGETS = crt0-efi-$(ARCH).o libgnuefi.a + + all: $(TARGETS) + +-libgnuefi.a: $(patsubst %,libgnuefi.a(%),$(OBJS)) ++libgnuefi.a: $(OBJS) ++ $(AR) rv $@ $(OBJS) + + clean: + rm -f $(TARGETS) *~ *.o $(OBJS) diff --git a/meta/recipes-bsp/gnu-efi/gnu-efi/parallel-make.patch b/meta/recipes-bsp/gnu-efi/gnu-efi/parallel-make.patch new file mode 100644 index 000..27c94e8 --- /dev/null +++ b/meta/recipes-bsp/gnu-efi/gnu-efi/parallel-make.patch @@ -0,0 +1,22 @@ +Fix parallel make failure + +Upstream-Status: Submitted [Maintainer directly] + +Add a missing dependency which resulted in a race leading to failure +on larger values of -j. + +Signed-off-by: Darren Hart dvh...@linux.intel.com + +Index: gnu-efi-3.0/Makefile +=== +--- gnu-efi-3.0.orig/Makefile gnu-efi-3.0/Makefile +@@ -42,6 +42,8 @@ include $(SRCDIR)/Make.defaults + + SUBDIRS = lib gnuefi inc apps + ++gnuefi: lib ++ + all: check_gcc $(SUBDIRS) + + $(SUBDIRS): diff --git a/meta/recipes-bsp/gnu-efi/gnu-efi_3.0u.bb b/meta/recipes-bsp/gnu-efi/gnu-efi_3.0u.bb new file mode 100644 index 000..0dbdba2 --- /dev/null +++ b/meta/recipes-bsp/gnu-efi/gnu-efi_3.0u.bb @@ -0,0 +1,33 @@ +SUMMARY = Libraries for producing EFI binaries +HOMEPAGE = http://sourceforge.net/projects/gnu-efi/; +SECTION = devel +LICENSE = GPLv2+ +LIC_FILES_CHKSUM = file://debian/copyright;md5=5fb358a180f484b285b0d99acdc29666 + +SRC_URI = http://downloads.sourceforge.net/gnu-efi/gnu-efi_3.0u.orig.tar.gz \ + file://parallel-make.patch \ +
Re: [OE-core] [PATCH 0/4] Add gummiboot boot manager alongside grub-efi
I've forgot to add v2 to the subject lines :(
I'll resend with that added.
On Sun, 2014-03-09 at 18:04 +0200, Stefan Stanacar wrote:
Hello,
This series adds recipes for gummiboot and a class allowing it to be used
as the boot loader for live/hddimg images.
Without changing EFI_PROVIDER, we have the same behaviour for EFI machines.
Using EFI_PROVIDER = gummiboot an installed image will use gummiboot instead
of grub-efi as it's boot manager.
I've tested this on FRI2, NUC and minnow (live USB boot and install from USB
and boot)
with EFI_PROVIDER = gummiboot and KERNEL_FEATURES_append = cfg/efi-ext
in local.conf
This is a partial fix for YB#4082.
Changes in V2:
- split the first patch in two
- used ${B} instead of ${S} in gummiboot do_deploy
- change the function names in bootimg/grub-efi instead of using a
prefix
I've tested again the changes on top of master.
Cheers,
Stefan
The following changes since commit abe417e22b1b55c60f722ca434f9d382ef87:
classes/uboot-config: ignore doc varflag (2014-03-07 15:05:09 +)
are available in the git repository at:
git://git.yoctoproject.org/poky-contrib stefans/gummiboot
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=stefans/gummiboot
Stefan Stanacar (4):
recipes-bsp: add gnu-efi recipe
recipes-bsp: Add gummiboot recipe
bootimg/grub-efi.bbclass: allow using a different class for EFI images
classes: Add gummiboot class
meta/classes/boot-directdisk.bbclass | 7 +-
meta/classes/bootimg.bbclass | 9 +-
meta/classes/grub-efi.bbclass | 12 +--
meta/classes/gummiboot.bbclass | 114
+
.../gnu-efi/gnu-efi/parallel-make-archives.patch | 48 +
.../gnu-efi/gnu-efi/parallel-make.patch| 22
meta/recipes-bsp/gnu-efi/gnu-efi_3.0u.bb | 33 ++
meta/recipes-bsp/gummiboot/gummiboot_git.bb| 25 +
.../initrdscripts/files/init-install-efi.sh| 51 ++---
9 files changed, 292 insertions(+), 29 deletions(-)
create mode 100644 meta/classes/gummiboot.bbclass
create mode 100644
meta/recipes-bsp/gnu-efi/gnu-efi/parallel-make-archives.patch
create mode 100644 meta/recipes-bsp/gnu-efi/gnu-efi/parallel-make.patch
create mode 100644 meta/recipes-bsp/gnu-efi/gnu-efi_3.0u.bb
create mode 100644 meta/recipes-bsp/gummiboot/gummiboot_git.bb
--
1.8.5.3
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/3] classes: Add gummiboot class
On Thu, 2014-03-06 at 14:36 -0800, Darren Hart wrote:
On 3/6/14, 10:15, Stefan Stanacar stefanx.stana...@intel.com wrote:
Adds a gummiboot class similar to grub-efi class and makes the necessary
changes so it can be used for live/hddimg images as well.
One can set EFI_PROVIDER = gummiboot in local.conf to use gummiboot
instead of grub-efi.
Gummiboot requires some kernel options that are not enabled by default,
so one has to build
with KERNEL_FEATURES_append = cfg/efi-ext.
cfg/efi is insufficient?
cfg/efi doesn't have CONFIG_EFI_STUB=y which is required by gummiboot.
cfg/efi-ext adds more than that, it's true.
It's also a good idea to enable CONFIG_EFIVARS_FS, which is the
newer/better interface than CONFIG_EFI_VARS that cfg/efi-ext enables.
The install scripts have been updated too, keeping the old behaviour
around,
but accounting for the new boot loader config files (if they exist).
It can be argued that the installer and bootimg are a bit wierd and not
necessarily correct,
but I wanted to have the exact same behviour with gummiboot.
With the default EFI_PROVIDER = grub-efi nothing changes, everthing
should be just as before.
I've tested live boot, install and normal boot on:
- FRI2
- genericx86-64 on NUC
with:
EFI_PROVIDER = gummiboot
KERNEL_FEATURES_append = cfg/efi-ext
in local.conf.
Signed-off-by: Stefan Stanacar stefanx.stana...@intel.com
Generally looks good. My only reservation is the same as for 2/3, should
we define an EFI interface rather than having to construct function names
in the consumers of this class?
I don't have a strong opinion here, it just seemed the simplest way atm,
then adding another interface.
Cheers,
Stefan
--
Darren
---
meta/classes/gummiboot.bbclass | 112
+
.../initrdscripts/files/init-install-efi.sh| 51 +++---
2 files changed, 147 insertions(+), 16 deletions(-)
create mode 100644 meta/classes/gummiboot.bbclass
diff --git a/meta/classes/gummiboot.bbclass
b/meta/classes/gummiboot.bbclass
new file mode 100644
index 000..5c11286
--- /dev/null
+++ b/meta/classes/gummiboot.bbclass
@@ -0,0 +1,112 @@
+EFICLASS_FUNC_PREFIX = gummiboot
+
+do_bootimg[depends] += gummiboot:do_deploy
+do_bootdirectdisk[depends] += gummiboot:do_deploy
+
+EFIDIR = /EFI/BOOT
+
+GUMMIBOOT_CFG ?= ${S}/loader.conf
+GUMMIBOOT_ENTRIES ?=
+GUMMIBOOT_TIMEOUT ?= 10
+
+gummiboot_populate() {
+DEST=$1
+
+EFI_IMAGE=gummibootia32.efi
+DEST_EFI_IMAGE=bootia32.efi
+if [ ${TARGET_ARCH} = x86_64 ]; then
+EFI_IMAGE=gummibootx64.efi
+DEST_EFI_IMAGE=bootx64.efi
+fi
+
+install -d ${DEST}${EFIDIR}
+# gummiboot requires these paths for configuration files
+# they are not customizable so no point in new vars
+install -d ${DEST}/loader
+install -d ${DEST}/loader/entries
+install -m 0644 ${DEPLOY_DIR_IMAGE}/${EFI_IMAGE}
${DEST}${EFIDIR}/${DEST_EFI_IMAGE}
+install -m 0644 ${GUMMIBOOT_CFG} ${DEST}/loader/loader.conf
+for i in ${GUMMIBOOT_ENTRIES}; do
+install -m 0644 ${i} ${DEST}/loader/entries
+done
+}
+
+gummiboot_iso_populate() {
+iso_dir=$1
+gummiboot_populate $iso_dir
+mkdir -p ${EFIIMGDIR}/${EFIDIR}
+cp $iso_dir/${EFIDIR}/* ${EFIIMGDIR}${EFIDIR}
+cp $iso_dir/vmlinuz ${EFIIMGDIR}
+echo ${DEST_EFI_IMAGE} ${EFIIMGDIR}/startup.nsh
+if [ -f $iso_dir/initrd ] ; then
+cp $iso_dir/initrd ${EFIIMGDIR}
+fi
+}
+
+gummiboot_hddimg_populate() {
+gummiboot_populate $1
+}
+
+python build_gummiboot_cfg() {
+s = d.getVar(S, True)
+labels = d.getVar('LABELS', True)
+if not labels:
+bb.debug(1, LABELS not defined, nothing to do)
+return
+
+if labels == []:
+bb.debug(1, No labels, nothing to do)
+return
+
+cfile = d.getVar('GUMMIBOOT_CFG', True)
+try:
+ cfgfile = open(cfile, 'w')
+except OSError:
+raise bb.build.funcFailed('Unable to open %s' % (cfile))
+
+cfgfile.write('# Automatically created by OE\n')
+cfgfile.write('default %s\n' % (labels.split()[0]))
+timeout = d.getVar('GUMMIBOOT_TIMEOUT', True)
+if timeout:
+cfgfile.write('timeout %s\n' % timeout)
+else:
+cfgfile.write('timeout 10\n')
+cfgfile.close()
+
+for label in labels.split():
+localdata = d.createCopy()
+
+overrides = localdata.getVar('OVERRIDES', True)
+if not overrides:
+raise bb.build.FuncFailed('OVERRIDES not defined')
+
+entryfile = %s/%s.conf % (s, label)
+d.appendVar(GUMMIBOOT_ENTRIES, + entryfile)
+try:
+entrycfg = open(entryfile, w)
+except OSError:
+raise bb.build.funcFailed('Unable to open %s' %
Re: [OE-core] [PATCH] lib/oeqa: allow a layer to provide it's own TEST_TARGET class
Hi Sipke,
On Thu, 2014-01-23 at 14:48 +1000, Sipke Vriend wrote:
Hi Stefan,
I have started using this patch in master to extend test targets to our
bsp layer, and it works well. Thanks.
Will the extension of a controllers.py file work for multiple bsp layers
in a single build/conf/bblayers.conf?
I did a quick test and think that the first controller.py found is the
only one extended. If this is true then the current implementation
could get a false negative for a given TEST_TARGET, if more than one
layer implements controllers.py.
Good catch!
You are right, only the first one found is imported (and that probably
has to do with how imports are made and the order of layers - lib/ is
added to pythonpath for all layers AFAIK)
I tried a minor modification which assumes each testtarget class is in
its own file with the name testtarget.py (lower case). This extended
across multiple layers, assuming no duplication of test target names. I
put them in the utils directory for the test, but they could go into a
controllers folder as that might make more sense.
Looks good, and yes, a oeqa.controllers package might make more sense.
Now, the only thing that bothers me is using testtarget's value as the
filename (as it is now it was supposed to be the class name). Naming
things is hard...
Anyway, could you please send it as a patch?
Cheers,
Stefan
diff --git a/meta/lib/oeqa/targetcontrol.py b/meta/lib/oeqa/targetcontrol.py
index 757f9d3..d7cab7e 100644
--- a/meta/lib/oeqa/targetcontrol.py
+++ b/meta/lib/oeqa/targetcontrol.py
@@ -28,10 +28,11 @@ def get_target_controller(d):
except AttributeError:
# nope, perhaps a layer defined one
try:
-module = __import__(oeqa.utils.controllers,
globals(), locals(), [testtarget])
+modulename = oeqa.utils.{0}.format(testtarget.lower())
+module = __import__(modulename, globals(), locals(),
[testtarget])
controller = getattr(module, testtarget)
except ImportError as e:
-bb.fatal(Failed to import oeqa.utils.controllers:\n%s
% traceback.format_exc())
+bb.fatal(Failed to import
{0}:\n{1}.format(modulename,traceback.format_exc()))
except AttributeError:
bb.fatal(\%s\ is not a valid value for TEST_TARGET
% testtarget)
return controller(d)
Cheers
Sipke
On 16/01/2014 10:48 PM, Stefan Stanacar wrote:
Allows a layer to define new classes inlayer/lib/oeqa/utils/controllers.py
and completely control or extend deployment of a target. (core currently
has QemuTarget and SimpleRemoteTarget).
The value of TEST_TARGET must be the name of the new class.
Signed-off-by: Stefan Stanacarstefanx.stana...@intel.com
---
meta/lib/oeqa/targetcontrol.py | 23 +++
meta/lib/oeqa/utils/__init__.py | 3 +++
2 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/meta/lib/oeqa/targetcontrol.py b/meta/lib/oeqa/targetcontrol.py
index dee38ec..757f9d3 100644
--- a/meta/lib/oeqa/targetcontrol.py
+++ b/meta/lib/oeqa/targetcontrol.py
@@ -8,18 +8,33 @@ import os
import shutil
import subprocess
import bb
-
+import traceback
from oeqa.utils.sshcontrol import SSHControl
from oeqa.utils.qemurunner import QemuRunner
def get_target_controller(d):
-if d.getVar(TEST_TARGET, True) == qemu:
+testtarget = d.getVar(TEST_TARGET, True)
+# old, simple names
+if testtarget == qemu:
return QemuTarget(d)
-elif d.getVar(TEST_TARGET, True) == simpleremote:
+elif testtarget == simpleremote:
return SimpleRemoteTarget(d)
else:
-bb.fatal(Please set a valid TEST_TARGET)
+# use the class name
+try:
+# is it a core class defined here?
+controller = getattr(__name__, testtarget)
+except AttributeError:
+# nope, perhaps a layer defined one
+try:
+module = __import__(oeqa.utils.controllers, globals(),
locals(), [testtarget])
+controller = getattr(module, testtarget)
+except ImportError as e:
+bb.fatal(Failed to import oeqa.utils.controllers:\n%s %
traceback.format_exc())
+except AttributeError:
+bb.fatal(\%s\ is not a valid value for TEST_TARGET %
testtarget)
+return controller(d)
class BaseTarget(object):
diff --git a/meta/lib/oeqa/utils/__init__.py
b/meta/lib/oeqa/utils/__init__.py
index e69de29..8eda927 100644
--- a/meta/lib/oeqa/utils/__init__.py
+++ b/meta/lib/oeqa/utils/__init__.py
@@ -0,0 +1,3 @@
+# Enable other layers to have modules in the same named directory
+from pkgutil import extend_path
+__path__ = extend_path(__path__, __name__)
This email and any attachments are intended for the sole use
Re: [OE-core] [PATCH] lib/oeqa: sshcontrol: Allow alternate port for SSHControl
On Thu, 2014-01-23 at 10:35 +1000, Sipke Vriend wrote: Add an optional parameter to SSHControl so the user can specify and alternate port to the default (22). Signed-off-by: Sipke Vriend sipke.vri...@xilinx.com --- meta/lib/oeqa/utils/sshcontrol.py |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/meta/lib/oeqa/utils/sshcontrol.py b/meta/lib/oeqa/utils/sshcontrol.py index a0dcf02..7bdf2e7 100644 --- a/meta/lib/oeqa/utils/sshcontrol.py +++ b/meta/lib/oeqa/utils/sshcontrol.py @@ -13,7 +13,7 @@ import select class SSHControl(object): -def __init__(self, ip=None, timeout=300, logfile=None): +def __init__(self, ip=None, timeout=300, logfile=None, port=None): self.ip = ip self.timeout = timeout self._starttime = None @@ -26,6 +26,8 @@ class SSHControl(object): '-o', 'LogLevel=ERROR' ] self.ssh = ['ssh', '-l', 'root'] + self.ssh_options +if port is not None: Nitpicking really, but 'if port:' would have been nicer ;-) Cheers, Stefan +self.ssh = self.ssh + ['-p', str(port)] def log(self, msg): if self.logfile: ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC OE-core/meta/lib] BSP Specific Qemurunner
On Thu, 2014-01-09 at 00:01 +, Sipke Vriend wrote: On Wednesday, 8 January 2014 11:53 PM Paul Eggleton wrote: On Wednesday 08 January 2014 13:12:41 Richard Purdie wrote: On Tue, 2014-01-07 at 22:59 +, Sipke Vriend wrote: Hi Richard, -Original Message- On Wednesday, 8 January 2014 12:00 AM, Richard Purdie wrote: On Tue, 2014-01-07 at 03:09 +, Sipke Vriend wrote: Hi, This RFC is a proposal to allow BSP layers to setup qemu with their specific requirements for the testimage oe-core functionality. The suggested changes will be exercised by the bitbake -c testimage image command. Similarly to the oeqa test cases this proposal extends the meta/lib/oeqa python modules to allow inclusion of python utility scripts in the BSP layers. Any BSP layer wishing to supply their own qemu setup would need to create an appropriate meta-bsplayer/lib/oeqa/utils/machinestarter.py The effect is that the lib/oeqa/utils/qemurunner will either allow the bsp layer provided machinestarter to spawn qemu or if not provided, spawn qemu via runqemu as currently. An example bsp layer is available here: https://github.com/sipke/meta-xilinx/tree/sipke/qemurunner with all required additions in the meta-xilinx/lib directory. This RFC is triggered by and indirectly related to Bugzilla report runqemu shouldn't hard-code machine knowledge https://bugzilla.yoctoproject.org/show_bug.cgi?id=4827 Why would we do this rather than improve runqemu to be extendable from BSP layers? Proposing as an additional way to launch qemu for oeqa testimage functionality, Improving runqemu can and probably should still happen. To consider: * it keeps testimage functionality (for bsp layers specific things) in the lib directly (similar to test cases) and as python. * testing (via testimage) may have a different requirement to that of running runqemu on the command line, so an alternate way to launch qemu could be useful. * should this approach of extending the oeqa testimage functionality into bsp layers be accepted, this could allow also for bsp specific hardware setup for testimage functionality in bsp layers. Primary aim is a solution which allows the bsp layer to control the setup of qemu (and eventually hardware) for testimage functionality. This is a proposal towards that goal. I thought Stefan was already also working on something towards this goal. I'd like to ensure we don't end up with two things doing the same thing. Stefan? Agreed. One solution is desired. Happy to coordinate with and assist Stefan, either implementing part of a solution (proposed one or another) and/or testing whatever Stefan comes up with against our bsp layer. I'm sorry for replying so late, this has been a slow week. I'm a bit confused because last time I checked I wasn't working on something similar :) (layer-controlled qemu/bsp setup), but I'm happy to help. I've looked at the patches themselves, and they are okay, but I'm not sure a layer-specific qemu setup for testimage is what we should do in the long term. Now, I can see the problem you are trying to fix here and why you need this... I always assumed that a BSP layer is mostly about real hw and that runqemu will deal with any qemu machine. So, as Richard said, we should probably fix runqemu. Now, I really like the idea of a layer-controlled/extendable target setup (be it qemu or hardware) and I think we should allow a layer to extend lib/oeqa/targetcontrol.py and provide (or extend) its own TEST_TARGET (besides qemu and simpleremote). That will prove more useful for hw stuff and it will allow a layer to completely control deployment of a qemu target too (deploy, start, stop, running commands, etc). E.g: perhaps a layer doesn't like the use of the ext3 images for qemu and needs to use something else. Thoughts? Cheers, Stefan ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] What package installs a C compiler on my target?
On Wed, 2014-01-08 at 16:05 +0100, Mike Looijmans wrote: On 01/08/2014 02:50 PM, Philip Balister wrote: On 01/08/2014 08:24 AM, Mike Looijmans wrote: Probably a silly question that has been asked a thousand times, but my searches on Google only give me the answer to the wrong question (how to build FOR the target, which I already know how to do). I want to run the C compiler on the board itself. That is, a GCC that runs on the board and compiles (and links etc.) C code for that board. What package(s) do I need to build and install to accomplish this? From one of my images: IMAGE_FEATURES += splash ssh-server-openssh tools-sdk \ tools-debug debug-tweaks \ dev-pkgs dbg-pkgs \ looks like tools-sdk is the one you want. dev- and dbg- packages might also be helpful, but will make the image larger. Especially the debug ones. $ bitbake tools-sdk ERROR: Nothing PROVIDES 'tools-sdk' So I guess it's a package that's provided in another layer (I have oe-core and most of meta-oe). No, tools-sdk it's not a bitbake target/package, it's an image feature that you need to add it to your image, e.g in local.conf: IMAGE_FEATURES_append = tools-sdk You'll probably want to add dev-pkgs too (that will install the devel packages/headers) The glory details are in core-image.bbclass, basically tools-sdk installs packagegroup-core-sdk and packagegroup-core-standalone-sdk-target. These are actually targets that you can build. If you want to see exactly on which packages these groups depend on you can have a look at meta/recipes-core/packagegroups/packagegroup-core*sdk*.bb recipes. Cheers, Stefan So far, the following set I've derived through trial and error seems to come close: TARGET_COMPILER_TOOLS = \ binutils \ binutils-symlinks \ cpp \ cpp-symlinks \ g++ \ g++-symlinks \ gcc \ gcc-symlinks \ make \ packagegroup-core-standalone-sdk-target \ This allows a basic hello world to compile on target in C and C++ code. Make wasn't really required, but it's very convenient to have... I'm mostly surprised that there wasn't a packagegroup to contain this set. It increased the image size to about 130MB, but in this particular case, that won't be a problem. Anyway, thanks for the tips all. Guess this list may be useful to others... Mike. Met vriendelijke groet / kind regards, Mike Looijmans TOPIC Embedded Systems Eindhovenseweg 32-C, NL-5683 KH Best Postbus 440, NL-5680 AK Best Telefoon: (+31) – (0)499 - 33.69.79 Telefax: (+31) - (0)499 - 33.69.70 E-mail: mike.looijm...@topic.nl Website: www.topic.nl Dit e-mail bericht en de eventueel daarbij behorende bijlagen zijn uitsluitend bestemd voor de geadresseerde, zoals die blijkt uit het e-mail bericht en/of de bijlagen. Er kunnen gegevens met betrekking tot een derde instaan. Indien u als niet-geadresseerde dit bericht en de bijlagen ontvangt, terwijl u niet bevoegd of gemachtigd bent om dit bericht namens de geadresseerde te ontvangen, wordt u verzocht de afzender hierover direct te informeren en het e-mail bericht met de bijlagen te vernietigen. Ieder gebruik van de inhoud van het e-mail bericht, waaronder de daarbij behorende bijlagen, door een ander dan de geadresseerde is onrechtmatig jegens ons dan wel de eventueel in het e-mail bericht of de bijlagen voorkomende andere personen. TOPIC Embedded Systems is niet aansprakelijk voor enigerlei schade voortvloeiend uit het gebruik en/of acceptatie van dit e-mail bericht of de daarbij behorende bijlagen. The contents of this message, as well as any enclosures, are addressed personally to, and thus solely intended for the addressee. They may contain information regarding a third party. A recipient who is neither the addressee, nor empowered to receive this message on behalf of the addressee, is kindly requested to immediately inform the sender of receipt, and to destroy the message and the enclosures. Any use of the contents of this message and/or the enclosures by any other person than the addressee or person who is empowered to receive this message, is illegal towards the sender and/or the aforementioned third party. TOPIC Embedded Systems is not liable for any damage as a result of the use and/or acceptance of this message and as well as any enclosures. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] openssh: use volatiles for managing /var/run/sshd
Hi Ming,
On Fri, 2013-09-13 at 17:10 +0800, Ming Liu wrote:
It fixes the following failure:
fatal: Missing privilege separation directory: /var/run/sshd
when sshd is started through xinetd.
With this patch applied, openssh doesn't start anymore in standard
images (e.g. core-image-sato-sdk)
root@qemux86-64:~# /etc/init.d/sshd restart
/var/run/sshd must be owned by root and not group or world-writable.
Cheers,
Stefan
Signed-off-by: Ming Liu ming@windriver.com
---
.../openssh/openssh-6.2p2/volatiles.99_sshd|1 +
meta/recipes-connectivity/openssh/openssh_6.2p2.bb |8 ++--
2 files changed, 7 insertions(+), 2 deletions(-)
create mode 100644
meta/recipes-connectivity/openssh/openssh-6.2p2/volatiles.99_sshd
diff --git
a/meta/recipes-connectivity/openssh/openssh-6.2p2/volatiles.99_sshd
b/meta/recipes-connectivity/openssh/openssh-6.2p2/volatiles.99_sshd
new file mode 100644
index 000..86e7f6f
--- /dev/null
+++ b/meta/recipes-connectivity/openssh/openssh-6.2p2/volatiles.99_sshd
@@ -0,0 +1 @@
+d sshd sshd 0755 /var/run/sshd none
diff --git a/meta/recipes-connectivity/openssh/openssh_6.2p2.bb
b/meta/recipes-connectivity/openssh/openssh_6.2p2.bb
index 3a7f50d..bb5c79e 100644
--- a/meta/recipes-connectivity/openssh/openssh_6.2p2.bb
+++ b/meta/recipes-connectivity/openssh/openssh_6.2p2.bb
@@ -29,7 +29,8 @@ SRC_URI =
ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-${PV}.tar.
${@base_contains('DISTRO_FEATURES', 'pam', '${PAM_SRC_URI}', '',
d)} \
file://sshd.socket \
file://sshd@.service \
- file://sshdgenkeys.service
+ file://sshdgenkeys.service \
+ file://volatiles.99_sshd
PAM_SRC_URI = file://sshd
@@ -92,6 +93,9 @@ do_install_append () {
install -m 0755 ${WORKDIR}/init ${D}${sysconfdir}/init.d/sshd
rm -f ${D}${bindir}/slogin ${D}${datadir}/Ssh.bin
rmdir ${D}${localstatedir}/run/sshd ${D}${localstatedir}/run
${D}${localstatedir}
+ install -d ${D}/${sysconfdir}/default/volatiles
+ install -m 644 ${WORKDIR}/volatiles.99_sshd
${D}/${sysconfdir}/default/volatiles/99_sshd
+
# Create config files for read-only rootfs
install -d ${D}${sysconfdir}/ssh
install -m 644 ${WORKDIR}/sshd_config
${D}${sysconfdir}/ssh/sshd_config_readonly
@@ -116,7 +120,7 @@ PACKAGES =+ ${PN}-keygen ${PN}-scp ${PN}-ssh ${PN}-sshd
${PN}-sftp ${PN}-misc $
FILES_${PN}-scp = ${bindir}/scp.${BPN}
FILES_${PN}-ssh = ${bindir}/ssh.${BPN} ${sysconfdir}/ssh/ssh_config
FILES_${PN}-sshd = ${sbindir}/sshd ${sysconfdir}/init.d/sshd
-FILES_${PN}-sshd += ${sysconfdir}/ssh/moduli ${sysconfdir}/ssh/sshd_config
${sysconfdir}/ssh/sshd_config_readonly
+FILES_${PN}-sshd += ${sysconfdir}/ssh/moduli ${sysconfdir}/ssh/sshd_config
${sysconfdir}/ssh/sshd_config_readonly
${sysconfdir}/default/volatiles/99_sshd
FILES_${PN}-sftp = ${bindir}/sftp
FILES_${PN}-sftp-server = ${libexecdir}/sftp-server
FILES_${PN}-misc = ${bindir}/ssh* ${libexecdir}/ssh*
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] qemu: add recommend of kernel-modules for all qemu machines
On Thu, 2013-09-05 at 11:45 +0100, Burton, Ross wrote: On 5 September 2013 11:20, Burton, Ross ross.bur...@intel.com wrote: I've also decided that maybe systemd isn't being quite as clever as it should and maybe fixing it there is the real fix. s/systemd/Linux/. The bug is that doing a df on a qemu systemd image results in it attempting to automount /proc/sys/fs/binfmt_misc. The automount unit has ConditionPathExists=/proc/sys/fs/binfmt_misc/ to stop it attempting to automount when binfmt is disabled but hooray Linux if binfmt_misc is a module that directory exists even when the module isn't actually loaded, giving a no such device error when accessed. The intention here I believe is so that an access to that directory can invoke an automounter (systemd, in this case) which can then load the modules and mount the virtual filesystem. There appear to be two options. 1) The QA scripts ignore any binfmt_misc unit mounts failing 2) systemd RRECOMMENDS kernel-module-binfmt-misc (the third option of teaching systemd how to recognise this situation and refuse to start the unit appears impossible) I honestly like second option more. And the third even better :) (sure changing the test to ignore binfmt_misc unit from systemctl --failed output can be easily done, but seems like just hiding the fail to me). I just tested that the third option can be done (for this case at least) by changing ConditionPathExists=/proc/sys/fs/binfmt_misc/ to ConditionDirectoryNotEmpty=/proc/sys/fs/binfmt_misc/ for proc-sys-fs-binfmt_misc.automount unit file and df doesn't complain as it doesn't attempt to automount anymore. On a system which does have that module loaded there are two files there so that's why the condition works. Cheers, Stefan (CCing Stefan for his input) To be honest I'm leaning towards (1) right now as binfmt_misc is only required in specific situations. Ross ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH 5/8] lib/oeqa/utils/qemurunner.py: class to handle qemu instance
Hi Colin, On Mon, 2013-08-05 at 21:50 +0200, Colin Walters wrote: On Fri, 2013-06-28 at 13:04 +0300, Stefan Stanacar wrote: +self.streampath = '/tmp/qemuconnection.%s' % os.getpid() That's a security problem on shared machines. I know this is a late reply, sorry, I missed the email back then. This has been changed since then to something else (but the reasons were different) http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=0ba78c1162bb125850a0ee504ca6fbe5bf21247f That's a tcp socket localhost only now, random high port (calls bind with 127.0.0.1, 0 so the os chooses the port). +bb.note(Reached login banner) +console.write(root\n) +(index, match, text) = console.expect([r(root@[\w-]+:~#)],10) So I forget if I've mentioned this here, but what I do for the gnome-ostree testing is at boot time, use a qcow2 overlay disk to write a custom systemd service that exports the journal over a virtio-serial channel. Then I look for specific MESSAGE_IDs in the journal. This is extremely reliable, no parsing of log messages etc. That sounds really cool, nice job! I might be wrong but doesn't that require virtio support in the target kernel (which is something we can't expect to have)? Cheers, Stefan See: https://rwmj.wordpress.com/2013/07/19/half-baked-ideas-ocr-vm-console-to-diagnose-state-and-errors/ ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] qemu: update dependency of native package
-Original Message-
From: openembedded-core-boun...@lists.openembedded.org
[mailto:openembedded-core-boun...@lists.openembedded.org] On
Behalf Of Richard Purdie
Sent: Friday, August 16, 2013 1:48 PM
To: Kai Kang
Cc: openembedded-core@lists.openembedded.org;
zhangle.y...@windriver.com
Subject: Re: [OE-core] [PATCH 1/1] qemu: update dependency of native
package
On Fri, 2013-08-16 at 18:05 +0800, Kai Kang wrote:
[YOCTO #4973]
It fails to start qemu with core-image-sato on Fedora 19. The error
message shows:
Could not initialize SDL(No available video device) - exiting
Add dependecy libxext-native to qemu-native to fix this error.
Signed-off-by: Kai Kang kai.k...@windriver.com
---
meta/recipes-devtools/qemu/qemu.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-devtools/qemu/qemu.inc b/meta/recipes-
devtools/qemu/qemu.inc
index 97e9b7b..a96e00c 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -2,7 +2,7 @@ DESCRIPTION = open source processor emulator
HOMEPAGE = http://qemu.org;
LICENSE = GPLv2 LGPLv2.1
DEPENDS = glib-2.0 zlib alsa-lib virtual/libx11 pixman dtc libsdl
-DEPENDS_class-native = zlib-native alsa-lib-native glib-2.0-native
pixman-native dtc-native
+DEPENDS_class-native = zlib-native alsa-lib-native glib-2.0-native
pixman-native dtc-native libxext-native
DEPENDS_class-nativesdk = nativesdk-zlib nativesdk-libsdl nativesdk-
glib-2.0 nativesdk-pixman nativesdk-dtc
RDEPENDS_${PN}_class-nativesdk = nativesdk-libsdl
This is one of the ugly dependencies we've tried to ignore.
We basically assume if your build machine has graphics, you have the
devel headers/libs there and qemu will autodetect and include graphics
support. Equally, if your build machine doesn't, it just won't build
graphics support. In general most people seem happy with this even if
its imperfect.
But, but... I do have libxext and libxext-devel installed... (and minimal works
just fine as the bug says)
libXext-1.3.2-1.fc19.x86_64
libXext-devel-1.3.2-1.fc19.x86_64
Also strace shows:
open(/lib64/libXext.so.6, O_RDONLY|O_CLOEXEC) = 11
read(11, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0`7`U1\0\0\0..., 832) =
832
fstat(11, {st_mode=S_IFREG|0755, st_size=77376, ...}) = 0
mmap(NULL, 2169112, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 11, 0) =
0x7f0a493ee000
mprotect(0x7f0a493ff000, 2093056, PROT_NONE) = 0
mmap(0x7f0a495fe000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 11, 0x1) = 0x7f0a495fe000
close(11) = 0
The F18 system which doesn't have a problem with sato has:
libXext-1.3.1-3.20130524gitdfe6e1f3b.fc18.x86_64
libXext-devel-1.3.1-3.20130524gitdfe6e1f3b.fc18.x86_64
Cheers,
Stefan
Adding libxext-native upsets this balance a little...
Cheers,
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [CONSOLIDATED PULL 00/24] Review ACK
On Tue, 2013-08-13 at 07:36 -0700, Saul Wold wrote: Paul, Ross: We are still in Review and ACK mode, so please take a look at this. I have included the dpkg fix for Fedora 19. This also has some patch for the QA Tests and Paul's Gstreamer patches. Saul, you always move too fast for me :) I was looking on MUT build on AB and some hosts (Debian) seemed to failed constantly getting IP, and I took me a while to find the problem. Stefan Stanacar (3): oeqa/utils/qemurunner: get ip old fashioned way and use tcp serial console Sent v2 of that and updated the original branch, changing ps to use -ww as I discovered the hard way that it behaves differently. ps man page says: If ps can not determine display width, as when output is redirected (piped) into a file or another command, the output width is undefined (it may be 80, unlimited, determined by the TERM variable, and so on). Seems distro has an effect too... Cheers, Stefan ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] base-files: remove symbolic link from /etc/mtab to /proc/mounts
On Wed, 2013-07-31 at 16:46 +0800, ChenQi wrote:
On 07/31/2013 04:19 PM, Chunrong Guo wrote:
*If /etc/mtab is a symlink to /proc/self/mounts,
mounting fails because addmntent returns an error.
As a consequence, the Private directory is unusable
because /proc/self/mounts is read-only feature.
Could you please detail your environment a little bit?
Where does this error come from?
I'm curios as well. Also can you please test this on a real hw? Try to
boot and/or install an image on atom-pc, I suspect it will fail.
Thanks,
Stefan
Besides, if you're going to make this change, please take a read-only
rootfs into consideration. There should be more to fix.
Best Regards,
Chen Qi
Signed-off-by: Chunrong Guo b40...@freescale.com
---
meta/recipes-core/base-files/base-files_3.0.14.bb |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-core/base-files/base-files_3.0.14.bb
b/meta/recipes-core/base-files/base-files_3.0.14.bb
index 054fefa..1843bdd 100644
--- a/meta/recipes-core/base-files/base-files_3.0.14.bb
+++ b/meta/recipes-core/base-files/base-files_3.0.14.bb
@@ -100,7 +100,6 @@ do_install () {
install -m 0644 ${WORKDIR}/host.conf ${D}${sysconfdir}/host.conf
install -m 0644 ${WORKDIR}/motd ${D}${sysconfdir}/motd
- ln -sf /proc/mounts ${D}${sysconfdir}/mtab
}
do_install_basefilesissue () {
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 4/4] oeqa/runtime/xorg: use the right ps command for xorg test
On Tue, 2013-07-30 at 11:35 +0300, Stefan Stanacar wrote: Use our determined ps command, otherwise test fails for images with procps. Signed-off-by: Stefan Stanacar stefanx.stana...@intel.com self.streampath = '/tmp/qemuconnection.%s' % os.getpid() -self.qemuparams = 'bootparams=console=tty1 console=ttyS0,115200n8 qemuparams=-serial unix:%s,server,nowait' % self.streampath +self.qemuparams = 'nographic bootparams=console=tty1 console=ttyS0,115200n8 qemuparams=-serial unix:%s,server,nowait' % self.streampath This was unintentional, I'll resend. Regards, Stefan self.qemupid = None self.ip = None ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] How to solve the make 3.82 issue at sanity check time?
On Wed, 2013-07-24 at 09:33 +0200, Giuseppe Condorelli wrote: Hi All, given that the make v. 3.82 is broken, as the sanity check highlights, which is the best solution to allow Fedora users (as I am) to go ahead with the build? I don't like to avoid sanity checks or to use an older version of sanity.bbclass. Please let me know, currently this issue is blocking for me. Fedora pushed updates for make in F17 18 (19 wasn't broken afaik) so you should just update your system. (yum update make should do the trick). Alternatively you can bitbake buildtools-tarball on an working system (or disable the sanity check before, touch conf/sanity.conf) and install that on your system (if you are on F16 which isn't updated anymore) Cheers, Stefan Cheers, Giuseppe ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] How to solve the make 3.82 issue at sanity check time?
On Wed, 2013-07-24 at 11:43 +0200, Giuseppe Condorelli wrote: Hi Paul, I saw it early this morning (reading the previous thread) but I've not put it in the right attention I think. Now I've installed the sdk using that script and a run is still ongoing. I'll let you know. I ask the same to you: are you sure the FC17 and ahead have solved the make issue? I'm running F19 and didn't ran into any problems. I also have an F18 machine that works which has make-3.82-14.fc18.x86_64 (this was the update that fixed the problem, pushed two weeks ago). And according to https://admin.fedoraproject.org/updates/FEDORA-2013-11295/make-3.82-14.fc17?_csrf_token=9e2949b0095b56c00b217d0b00e77e28df2bb7ba and https://admin.fedoraproject.org/updates/make?_csrf_token=9e2949b0095b56c00b217d0b00e77e28df2bb7ba the same patch was pushed for F17 make on the same day as F18, so that should work too. Cheers, Stefan Many thanks, Cheers. Giuseppe 2013/7/24 Paul Barker p...@paulbarker.me.uk On 24 July 2013 09:47, Giuseppe Condorelli giuseppe.condore...@gmail.com wrote: Many thanks for the quick reply Stefan, For completion, I'm working on FC16. Indeed (before sending the mail) I tried downloading the make rpm for FC17 (rpmfind.net) and to use it (accordingly unpackaged under my personal directory, updating the PATH) with the same failure. Can this sound strange for you? As you know, which are the make versions Fedora has released for the FC17/18? I think at the moment the build of the buildtools-tarball will be the way I'll follow, temporary disabling the sanity check. Cheers, Giuseppe As stated in a previous thread, there's a snapshot of the buildtools at http://autobuilder.yoctoproject.org/pub/nightly/CURRENT/buildtools/ which might work for you. It should install a known good set of tools including make. This could be a good test for it. -- Paul Barker Email: p...@paulbarker.me.uk http://www.paulbarker.me.uk ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH v2 3/8] lib/oeqa/utils/sshcontrol.py: helper module for running remote commands
Hi Colin, On Sun, 2013-07-07 at 17:55 -0400, Colin Walters wrote: On Fri, 2013-07-05 at 12:27 +0300, Stefan Stanacar wrote: +actualcmd = ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -l root %s '%s' % (self.host, cmd) This is going to fail if cmd contains a single quote. Personally, I *always* pass around subprocess arguments as an array. Anything else is going to lead to quoting problems. You're right, I just sent a patch that drops that and doesn't use shlex anymore. Thanks, Stefan ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH 0/8] Proposed implementation of a new runtime tests framework
On Wed, 2013-07-03 at 23:51 -0700, Saul Wold wrote: Tired this out today and got the following: ERROR: Function failed: Failed to start qemu. You should check the task log and the qemu boot log (qemu log is /srv/ssd/sgw/builds/world/tmp/work/qemux86_64-poky-linux/core-image-sato/1.0-r0/testimage/qemu_boot_log.20130704065001) ERROR: Logfile of failure stored in: /srv/ssd/sgw/builds/world/tmp/work/qemux86_64-poky-linux/core-image-sato/1.0-r0/temp/log.do_testimage.18354 Log data follows: | DEBUG: Executing python function do_testimage | NOTE: Test modules ['oeqa.runtime.ping', 'oeqa.runtime.ssh', 'oeqa.runtime.connman', 'oeqa.runtime.rpm', 'oeqa.runtime.smart', 'oeqa.runtime.xorg', 'oeqa.runtime.dmesg'] On a second look, this shouldn't be none: | NOTE: DISPLAY value: None Because this happens: | Running qemu-system-x86_64... | /srv/ssd/sgw/builds/world/tmp/sysroots/x86_64-linux/usr/bin/qemu-system-x86_64 -kernel /srv/ssd/sgw/builds/world/tmp/deploy/images/bzImage-qemux86-64.bin -net nic,vlan=0 -net tap,vlan=0,ifname=tap0,script=no,downscript=no -hda /srv/ssd/sgw/builds/world/tmp/deploy/images/core-image-sato-qemux86-64.ext3 -show-cursor -usb -usbdevice wacom-tablet -vga vmware -no-reboot -snapshot -serial unix:/tmp/qemuconnection.18354,server,nowait -m 128 --append vga=0 uvesafb.mode_option=640x480-32 root=/dev/hda rw mem=128M ip=192.168.7.2::192.168.7.1:255.255.255.0 oprofile.timer=1 console=ttyS0 | Could not initialize SDL(No available video device) - exiting Can you export DISPLAY before running the task? But don't use DISPLAY=localhost:1 use DISPLAY=:1 (see my other mail). Cheers, Stefan ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] xkeyboard-config: Remove xkbcomp from RDEPENDS_${PN}
On Tue, 2013-05-07 at 09:43 -0600, Gary Thomas wrote: On 2013-05-07 09:23, Burton, Ross wrote: On 7 May 2013 16:13, Gary Thomas g...@mlbassoc.com wrote: It looks like the package(s) you're referring to are the X server. Too bad you didn't provide those patches as well as images which use X are currently broken (at least mine are) Yeah, I noticed that when browsing mail over breakfast but dropped the ball in actually saying on the list. Add a dependency to it in xserver-xorg. I'll put something together shortly. I didn't noticed your reply until now, I just sent a patch... :) ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] postinst does not finish
On Wed, 2013-04-17 at 09:28 +0100, Paul Eggleton wrote: On Tuesday 16 April 2013 23:42:08 Khem Raj wrote: On Apr 16, 2013, at 11:28 PM, Andreas Müller schnitzelt...@googlemail.com wrote: sorry again me with another issue. I updated all layers from master few hours ago and built from scratch. On first boot with systemd postinst never finishes. I see only: [** } A start job is running for Run pending postinsts and ** are moving around. Does anybody else face this one? ran into same issue. I disabled post installs to run on boot Could you guys please try to debug this and find out what is hanging here, because with core-image-minimal and systemd I don't see this problem, the run- postinsts script finishes as expected. Works for me too: core-image-sato and systemd, qemux86, PACKAGE_CLASSES = package_ipk. I do see that message but it doesn't hang, it finishes pretty quick. Cheers, Paul ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH V4 2/3] connman-conf: configures connman in qemu machines
What about network in Build Appliance image? Blacklisting eth interfaces
affects build appliance image too (because it's built as qemux86-64 machine
usually).
Or someone who doesn't use the runqemu script and she doesn't pass a static ip
to qemu because she wants to use a dhcp server (eg: dnsmasq over a bridge which
contains preconfigured tun/tap devices, think server enviroment where you want
to run multiple yocto vms)
An ugly fix for BA can be:
diff --git a/meta/recipes-core/images/build-appliance-image.bb
b/meta/recipes-core/images/build-appliance-image.bb
index 2359eca..b8255ac 100644
--- a/meta/recipes-core/images/build-appliance-image.bb
+++ b/meta/recipes-core/images/build-appliance-image.bb
@@ -64,6 +64,8 @@ fakeroot do_populate_poky_src () {
# Use Clearlooks GTK+ theme
mkdir -p ${IMAGE_ROOTFS}/etc/gtk-2.0
echo 'gtk-theme-name = Clearlooks' ${IMAGE_ROOTFS}/etc/gtk-2.0/gtkrc
+
+rm -rf ${IMAGE_ROOTFS}/etc/connman/main.conf
}
IMAGE_PREPROCESS_COMMAND += do_populate_poky_src;
--
Stefan Stanacar
Yocto QA
OTC, SSD
-Original Message-
From: openembedded-core-boun...@lists.openembedded.org
[mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of Saul Wold
Sent: Tuesday, January 15, 2013 10:25 PM
To: Martin Jansa
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH V4 2/3] connman-conf: configures connman in qemu
machines
On 01/15/2013 12:21 PM, Martin Jansa wrote:
On Tue, Jan 15, 2013 at 10:08:46PM +0200, Cristian Iorga wrote:
For qemu machines, connman should not configure
virtual wired interfaces. Wired interfaces (eth0)
are assigned static IP addresses by the virtual machine
manager (qemu). This packages places the eth0 interface in
a list of blacklisted interfaces, forbiding connman
administering wired interfaces for qemu machines.
Again wrong order,
3/3 should be 1st
2/3 2nd
1/3 3rd
I have re-ordered this in my consolidated pull MUT staging area, saw
that right away!
Sau!
Cheers,
Signed-off-by: Cristian Iorga cristian.io...@intel.com
---
meta/conf/layer.conf |1 +
meta/recipes-connectivity/connman/connman-conf.bb| 18
++
.../connman/connman-conf/qemuall/main.conf |3 +++
3 files changed, 22 insertions(+)
create mode 100644 meta/recipes-connectivity/connman/connman-conf.bb
create mode 100644
meta/recipes-connectivity/connman/connman-conf/qemuall/main.conf
diff --git a/meta/conf/layer.conf b/meta/conf/layer.conf
index 78ceae9..3259e5c 100644
--- a/meta/conf/layer.conf
+++ b/meta/conf/layer.conf
@@ -22,6 +22,7 @@ SIGGEN_EXCLUDERECIPES_ABISAFE += \
shadow-securetty \
opkg-config-base \
netbase \
+ connman-conf \
formfactor \
xserver-xf86-config \
pointercal \
diff --git a/meta/recipes-connectivity/connman/connman-conf.bb
b/meta/recipes-connectivity/connman/connman-conf.bb
new file mode 100644
index 000..7c7ef26
--- /dev/null
+++ b/meta/recipes-connectivity/connman/connman-conf.bb
@@ -0,0 +1,18 @@
+#connman config to ignore wired interfaces on qemu machines
+
+LICENSE = GPLv2
+LIC_FILES_CHKSUM =
file://${COREBASE}/meta/files/common-licenses/GPL-2.0;md5=801f80980d171dd6425610833a22dbe6
+
+SRC_URI_append_qemuall = file://main.conf
+
+PR = r0
+
+PACKAGE_ARCH = ${MACHINE_ARCH}
+
+do_install() {
+#Blacklist ethn network interface in case of qemu* machines
+if test -e ${WORKDIR}/main.conf; then
+install -d ${D}${sysconfdir}/connman
+install -m 0644 ${WORKDIR}/main.conf ${D}${sysconfdir}/connman
+fi
+}
diff --git
a/meta/recipes-connectivity/connman/connman-conf/qemuall/main.conf
b/meta/recipes-connectivity/connman/connman-conf/qemuall/main.conf
new file mode 100644
index 000..01973e7
--- /dev/null
+++ b/meta/recipes-connectivity/connman/connman-conf/qemuall/main.conf
@@ -0,0 +1,3 @@
+[General]
+
+NetworkInterfaceBlacklist = eth
--
1.7.10.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
