Re: [OE-core] [RFC PATCH 4/4] lib/oeqa: add a test target controller for EFI targets
On Fri, Mar 21, 2014 at 5:57 AM, Stanacar, StefanX
wrote:
> On Thu, 2014-03-20 at 18:08 -0300, Otavio Salvador wrote:
>> On Thu, Mar 20, 2014 at 1:29 PM, Stefan Stanacar
>> 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 -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
> . 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).
Ok.
>> > +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)
What happens if the image is bigger than RAM size?
>> > +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.
So it is misnamed. GummiBootEfi would be clearer.
> [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 sy
Re: [OE-core] OpenEmbedded and musl-libc
On 21 March 2014 18:22, Khem Raj wrote: > On Fri, Mar 21, 2014 at 5:34 AM, Paul Barker wrote: >> Hi all, >> >> musl-libc hit version 1.0.0 yesterday and is starting to look good to >> me. It's basically a really small but very functional libc that would >> suit embedded environments very well as an alternative to >> eglibc/uclibc. I'm personally very interested in using it in my >> projects and I also think it could fit in well with the aims of >> poky-tiny. >> >> http://www.etalabs.net/compare_libcs.html gives some pretty useful info. >> >> I'm basically emailing to see if anyone else is interested in this or >> if anyone has looked at using it before in OpenEmbedded as a google >> for previous discussions didn't turn anything up. >> >> I'm currently very busy between various projects so I don't have time >> to hack together a musl-libc recipe myself but I should have time to >> help test it. > > it has been under my radar for a while. I have actually locally made > toolchains with > clang+musl and it seems to be coming along. its licensed differently thats > the biggest attraction for folks who do static linking. Otherwise it still > doesnt yet support variety of architectures that other libcs support. given > now we have kconfig for eglibc too may be it fills in the nommu gap much > like uclibc does today. I have some plans for 1.7 for adding it to OE > may be in a layer > of its own first and then migrate it to OE-core > Yea, that's the sort of approach I was expecting. Getting musl to build is the easy bit, making it usable as the system libc for an entire image is the difficult bit. I think at least initially we'd need a few bbappends in a meta-musl layer to fix packages which don't compile out-of-the-box with musl. I don't think musl fills the nommu gap though - from the comparison page I linked to it says musl doesn't support mmu-less microcontrollers. -- 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
Re: [OE-core] OpenEmbedded and musl-libc
On Fri, Mar 21, 2014 at 5:34 AM, Paul Barker wrote: > Hi all, > > musl-libc hit version 1.0.0 yesterday and is starting to look good to > me. It's basically a really small but very functional libc that would > suit embedded environments very well as an alternative to > eglibc/uclibc. I'm personally very interested in using it in my > projects and I also think it could fit in well with the aims of > poky-tiny. > > http://www.etalabs.net/compare_libcs.html gives some pretty useful info. > > I'm basically emailing to see if anyone else is interested in this or > if anyone has looked at using it before in OpenEmbedded as a google > for previous discussions didn't turn anything up. > > I'm currently very busy between various projects so I don't have time > to hack together a musl-libc recipe myself but I should have time to > help test it. it has been under my radar for a while. I have actually locally made toolchains with clang+musl and it seems to be coming along. its licensed differently thats the biggest attraction for folks who do static linking. Otherwise it still doesnt yet support variety of architectures that other libcs support. given now we have kconfig for eglibc too may be it fills in the nommu gap much like uclibc does today. I have some plans for 1.7 for adding it to OE may be in a layer of its own first and then migrate it to OE-core > > Thanks, > > -- > 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
[OE-core] [PATCH 2/2] gtk-engines: move engine schemas to a dedicated package
The GTK+ engine schemas are not insignicant in size but also mostly useless.
Put them in a sub-package instead of PN so they only get installed when
explicitly required.
Signed-off-by: Ross Burton
---
meta/recipes-gnome/gtk-engines/gtk-engines_2.20.2.bb |3 +++
1 file changed, 3 insertions(+)
diff --git a/meta/recipes-gnome/gtk-engines/gtk-engines_2.20.2.bb
b/meta/recipes-gnome/gtk-engines/gtk-engines_2.20.2.bb
index 5255f00..33b6afe 100644
--- a/meta/recipes-gnome/gtk-engines/gtk-engines_2.20.2.bb
+++ b/meta/recipes-gnome/gtk-engines/gtk-engines_2.20.2.bb
@@ -10,6 +10,7 @@ DEPENDS = "intltool-native gtk+"
PR = "r3"
+PACKAGES += "${PN}-schemas"
PACKAGES_DYNAMIC += "^gtk-engine-.* ^gtk-theme-.*"
RDEPENDS_gtk-theme-redmond = "gtk-engine-redmond95"
@@ -21,8 +22,10 @@ RDEPENDS_gtk-theme-thinice = "gtk-engine-thinice"
RDEPENDS_gtk-theme-industrial = "gtk-engine-industrial"
RDEPENDS_gtk-theme-clearlooks = "gtk-engine-clearlooks"
+FILES_${PN} = ""
FILES_${PN}-dev += "${libdir}/gtk-2.0/*/engines/*.la"
FILES_${PN}-dbg += "${libdir}/gtk-2.0/*/engines/.debug"
+FILES_${PN}-schemas = "${datadir}/gtk-engines/*.xml"
CFLAGS_prepend = "-DHAVE_ANIMATION "
--
1.7.10.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] gtk-engines: don't inherit gtk-icon-cache
This was accidently left in and can be removed.
Signed-off-by: Ross Burton
---
meta/recipes-gnome/gtk-engines/gtk-engines_2.20.2.bb |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-gnome/gtk-engines/gtk-engines_2.20.2.bb
b/meta/recipes-gnome/gtk-engines/gtk-engines_2.20.2.bb
index 940d130..5255f00 100644
--- a/meta/recipes-gnome/gtk-engines/gtk-engines_2.20.2.bb
+++ b/meta/recipes-gnome/gtk-engines/gtk-engines_2.20.2.bb
@@ -26,7 +26,7 @@ FILES_${PN}-dbg += "${libdir}/gtk-2.0/*/engines/.debug"
CFLAGS_prepend = "-DHAVE_ANIMATION "
-inherit gnomebase gtk-icon-cache
+inherit gnomebase
python populate_packages_prepend() {
engines_root = os.path.join(d.getVar('libdir', True),
"gtk-2.0/2.10.0/engines")
--
1.7.10.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v3 2/2] classes/image: ignore modules.dep changing during multilib image construction
Since we now run depmod when building images (as the postinst that does
this is now on kernel-base instead of kernel-image) it is possible to
have this file different between the two halves of the multilib image,
and the code that checks for such differences detects this and fails.
Whitelist this file to avoid the failure.
Related to fix for [YOCTO #5392].
Signed-off-by: Paul Eggleton
---
meta/classes/image.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index 3436624..9fe2786 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -269,7 +269,7 @@ insert_feed_uris () {
done
}
-MULTILIBRE_ALLOW_REP =.
"${base_bindir}|${base_sbindir}|${bindir}|${sbindir}|${libexecdir}|${sysconfdir}|${nonarch_base_libdir}/udev|"
+MULTILIBRE_ALLOW_REP =.
"${base_bindir}|${base_sbindir}|${bindir}|${sbindir}|${libexecdir}|${sysconfdir}|${nonarch_base_libdir}/udev|/lib/modules/[^/]*/modules.dep|"
MULTILIB_CHECK_FILE = "${WORKDIR}/multilib_check.py"
MULTILIB_TEMP_ROOTFS = "${WORKDIR}/multilib"
--
1.8.5.3
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v3 1/2] classes/kernel: move module postinst commands to kernel-base
Since kernel-base is the package that contains the files that depmod
needs to run, we should be running depmod from the kernel-base
postinstall rather than kernel-image.
Fixes [YOCTO #5392].
Signed-off-by: Paul Eggleton
---
meta/classes/kernel.bbclass | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 6953109..19b159b 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -362,8 +362,7 @@ ALLOW_EMPTY_kernel-image = "1"
ALLOW_EMPTY_kernel-modules = "1"
DESCRIPTION_kernel-modules = "Kernel modules meta package"
-pkg_postinst_kernel-image () {
- update-alternatives --install /${KERNEL_IMAGEDEST}/${KERNEL_IMAGETYPE}
${KERNEL_IMAGETYPE} ${KERNEL_IMAGETYPE}-${KERNEL_VERSION} ${KERNEL_PRIORITY} ||
true
+pkg_postinst_kernel-base () {
if [ ! -e "$D/lib/modules/${KERNEL_VERSION}" ]; then
mkdir -p $D/lib/modules/${KERNEL_VERSION}
fi
@@ -374,6 +373,10 @@ pkg_postinst_kernel-image () {
fi
}
+pkg_postinst_kernel-image () {
+ update-alternatives --install /${KERNEL_IMAGEDEST}/${KERNEL_IMAGETYPE}
${KERNEL_IMAGETYPE} ${KERNEL_IMAGETYPE}-${KERNEL_VERSION} ${KERNEL_PRIORITY} ||
true
+}
+
pkg_postrm_kernel-image () {
update-alternatives --remove ${KERNEL_IMAGETYPE}
${KERNEL_IMAGETYPE}-${KERNEL_VERSION} || true
}
--
1.8.5.3
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v3 0/2] Fix for kernel depmod postinstall
The other fixes from "Misc fixes" branch were merged; this one needed an additional fix for the multilib changed file detection, which has been added in v3. The following changes since commit ef2ba0a17a4fbd0e0c43c144f43d1d40de23697e: gtk-engines: removed gnome inheritance (2014-03-21 17:14:53 +) are available in the git repository at: git://git.openembedded.org/openembedded-core-contrib paule/fixes5 http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=paule/fixes5 Paul Eggleton (2): classes/kernel: move module postinst commands to kernel-base classes/image: ignore modules.dep changing during multilib image construction meta/classes/image.bbclass | 2 +- meta/classes/kernel.bbclass | 7 +-- 2 files changed, 6 insertions(+), 3 deletions(-) -- 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] wic: Add SD/MMC-Cards support to '--ondisk' param
On Tue, 2014-03-18 at 13:05 -0300, João Henrique Ferreira de Freitas
wrote:
> The special case when wic is set up to use SD/MMC-Cards in place
> of sdX disks is not handled properly.
>
> Append 'p' to the rootdev when disk is SD/MMC-Cards fix this situation.
This is missing your Signed-off-by. Other than that,
Acked-by: Tom Zanussi
> ---
> scripts/lib/mic/imager/direct.py | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/scripts/lib/mic/imager/direct.py
> b/scripts/lib/mic/imager/direct.py
> index f8c300c..1f2f8fc 100644
> --- a/scripts/lib/mic/imager/direct.py
> +++ b/scripts/lib/mic/imager/direct.py
> @@ -345,10 +345,14 @@ class DirectImageCreator(BaseImageCreator):
> parts = self._get_parts()
> for num, p in enumerate(parts, 1):
> if p.mountpoint == "/":
> +part = ''
> +if p.disk.startswith('mmcblk'):
> +part = 'p'
> +
> if self._ptable_format == 'msdos' and num > 3:
> -rootdev = "/dev/%s%-d" % (p.disk, num + 1)
> +rootdev = "/dev/%s%s%-d" % (p.disk, part, num + 1)
> else:
> -rootdev = "/dev/%s%-d" % (p.disk, num)
> +rootdev = "/dev/%s%s%-d" % (p.disk, part, num)
> root_part_uuid = p.part_type
>
> return (rootdev, root_part_uuid)
> --
> 1.8.3.2
>
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] libm accuracy, eglibc compared to glibc -- solved
On Fri, Mar 21, 2014 at 9:45 AM, Mark Hatle wrote:
> On 3/21/14, 7:10 AM, Mats Kärrman wrote:
>>
>> Hi,
>>
>> On: Thursday, March 13, 2014 11:36 AM, Mats Kärrman wrote:
>>>
>>> My "home made" hard float tune for PowerPC looks like this:
>>>
>>> --
>>> # Tune for the e300c3 core
>>> require conf/machine/include/tune-ppce300c3.inc
>>>
>>> # Use hardware floating point
>>> AVAILTUNES += "ppce300c3hf"
>>> TUNE_FEATURES_tune-ppce300c3hf = "m32 fpu-hard ppce300c3"
>>> TUNE_PKGARCH_tune-ppce300c3hf = "ppce300c3hf"
>>> PACKAGE_EXTRA_ARCHS_tune-ppce300c3hf =
>>> "${PACKAGE_EXTRA_ARCHS_tune-powerpc} ppce300c3hf"
>>> DEFAULTTUNE = "ppce300c3hf"
>>> --
>>>
>>
>> I found the reason for the error (deviance) in the sqrt function. glibc
>> has
>> special code for PowerPC 603e core (e300 is an optimized variant of 603e).
>> By adding the following line to the tuning I now get the same result as
>> for all other environments that I've tried:
>>
>> GLIBC_EXTRA_OECONF += "${@bb.utils.contains("TUNE_FEATURES", "ppce300c3",
>> "-with-cpu=603e", "", d)}"
>>
>> Does anyone know about the reason for having soft-float as the default and
>> only available alternative for e300c2/3 tunings?
>
>
> My guess is because e300 e300c2 were both soft-float designs. And e300c3 is
> the first hard float design.
>
> The e300c3 should inherit and use the 603e directly. This includes
> definiting the TUNE_FEATURES that the 603e does. If it doesn't do that, I'd
> suggest it's a mistake.
>
> The default 603e tune should include:
>
> GLIBC_EXTRA_OECONF += "${@bb.utils.contains("TUNE_FEATURES", "ppc603e",
> "-with-cpu=603e", "", d)}"
>
> or similar already -- and should already be hard float enabled. (ppc603e
> soft-float should be the alternative -- as it is significantly rarer and the
> deviation.)
alternatively we should define fpu Iplies in glibc for e300c3,
>
>
>> Would it be worthwhile to send a patch to add the hf tuning to OE-core?
>
>
> As the e300c3 should be hard float, we shouldn't have the 'hf' designation.
> Otherwise, we should ensure the e300c3 tune is correctly configured.
may be for now controlling it in tune file is a quicker fix.
>
>
>> In that case what tests should be performed before that and what (related)
>> tests are performed by the OE auto-builder?
>>
>> BR // Mats
>>
>
> --
> ___
> 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 0/6 V3] refactor the archiver*.bbclass
On Fri, 2014-03-14 at 23:03 +0800, Robert Yang wrote: > > On 03/14/2014 01:45 AM, Burton, Ross wrote: > > On 11 March 2014 17:08, Robert Yang wrote: > >> Robert Yang (6): > >>classes/archive*.bbclass: remove archive-*-source.bbclass > >>archiver.bbclass: refactor it > >>package_rpm.bbclass: archive the source to srpm package > >>archiver.bbclass: move a few code to copyleft_compliance.bbclass > >>local.conf.sample.extended: update for the archiver > >>patch.bbclass: do_patch: unset TMPDIR from environment > > > > This series appears to work for me and doesn't cause rebuilds (after > > removing the patch change, as that obviously does). Can anyone else > > who actively uses the archiver verify that it still works for them? > > > > Thank you very much for the testing and suggestions, I've updated it > a little: > > * Remove the [PATCH 6/6] which is used for unset the TMPDIR, we can fix >it in another thread as bug 5968 describes since it doesn't affect the >archiver. > > * Modified the do_ar_configured a little and tested the "bitbake >core-image-sato world meta-toolchain", it worked well. > > Here is the repo: (the same repo as before) > >git://git.openembedded.org/openembedded-core-contrib rbt/archiver_v3 > > http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=rbt/archiver_v3 > > Robert Yang (5): >classes/archive*.bbclass: remove archive-*-source.bbclass >archiver.bbclass: refactor it >package_rpm.bbclass: archive the source to srpm package >archiver.bbclass: move a few code to copyleft_compliance.bbclass >local.conf.sample.extended: update for the archiver I'm going to merge this into master (its queued in master-next for final testing) but this is on the condition that we work on follow up patches to the issues raised during review. Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] libm accuracy, eglibc compared to glibc -- solved
On 3/21/14, 7:10 AM, Mats Kärrman wrote:
Hi,
On: Thursday, March 13, 2014 11:36 AM, Mats Kärrman wrote:
My "home made" hard float tune for PowerPC looks like this:
--
# Tune for the e300c3 core
require conf/machine/include/tune-ppce300c3.inc
# Use hardware floating point
AVAILTUNES += "ppce300c3hf"
TUNE_FEATURES_tune-ppce300c3hf = "m32 fpu-hard ppce300c3"
TUNE_PKGARCH_tune-ppce300c3hf = "ppce300c3hf"
PACKAGE_EXTRA_ARCHS_tune-ppce300c3hf = "${PACKAGE_EXTRA_ARCHS_tune-powerpc}
ppce300c3hf"
DEFAULTTUNE = "ppce300c3hf"
--
I found the reason for the error (deviance) in the sqrt function. glibc has
special code for PowerPC 603e core (e300 is an optimized variant of 603e).
By adding the following line to the tuning I now get the same result as
for all other environments that I've tried:
GLIBC_EXTRA_OECONF += "${@bb.utils.contains("TUNE_FEATURES", "ppce300c3", "-with-cpu=603e",
"", d)}"
Does anyone know about the reason for having soft-float as the default and
only available alternative for e300c2/3 tunings?
My guess is because e300 e300c2 were both soft-float designs. And e300c3 is the
first hard float design.
The e300c3 should inherit and use the 603e directly. This includes definiting
the TUNE_FEATURES that the 603e does. If it doesn't do that, I'd suggest it's a
mistake.
The default 603e tune should include:
GLIBC_EXTRA_OECONF += "${@bb.utils.contains("TUNE_FEATURES", "ppc603e",
"-with-cpu=603e", "", d)}"
or similar already -- and should already be hard float enabled. (ppc603e
soft-float should be the alternative -- as it is significantly rarer and the
deviation.)
Would it be worthwhile to send a patch to add the hf tuning to OE-core?
As the e300c3 should be hard float, we shouldn't have the 'hf' designation.
Otherwise, we should ensure the e300c3 tune is correctly configured.
In that case what tests should be performed before that and what (related)
tests are performed by the OE auto-builder?
BR // Mats
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] classes/image: disable pam nullok_secure with debug-tweaks
If you want passwordless logins to work with pam enabled, then you can't
have "nullok_secure" enabled on pam_unix entries. Add some
postprocessing to change these to "nullok" when debug-tweaks is in
IMAGE_FEATURES, in order to make passwordless logins with PAM work
again.
Fixes [YOCTO #5973].
Signed-off-by: Paul Eggleton
---
meta/classes/image.bbclass | 4
1 file changed, 4 insertions(+)
diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index 9a04288..3436624 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -298,6 +298,10 @@ ssh_allow_empty_password () {
printf '\nDROPBEAR_EXTRA_ARGS="-B"\n' >>
${IMAGE_ROOTFS}${sysconfdir}/default/dropbear
fi
fi
+
+ if [ -d ${IMAGE_ROOTFS}${sysconfdir}/pam.d ] ; then
+ sed -i 's/nullok_secure/nullok/'
${IMAGE_ROOTFS}${sysconfdir}/pam.d/*
+ fi
}
# Enable postinst logging if debug-tweaks is enabled
--
1.8.5.3
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] Fix passwordless logins with pam enabled
The following change since commit eb53ae4a5702dbd65b6e340bbd3ae4566157c081: gnome-doc-utils: removed gconf inheritance (2014-03-21 12:05:33 +) is available in the git repository at: git://git.openembedded.org/openembedded-core-contrib paule/pam-nullok http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=paule/pam-nullok Paul Eggleton (1): classes/image: disable pam nullok_secure with debug-tweaks meta/classes/image.bbclass | 4 1 file changed, 4 insertions(+) -- 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 0/5] wic: Add --rootfs option to --source param
On Sat, 2014-03-15 at 18:17 -0300, João Henrique Ferreira de Freitas wrote: > Hi, > > These patchs allows the user create the following directdisk-multi-rootfs.wks > file: > > part /boot --source bootimg-pcbios --ondisk sda --fstype=msdos \ > --label boot --active --align 1024 > part / --source rootfs --ondisk sda --fstype=ext3 --label primary --align > 1024 > > part /standby --source rootfs --rootfs= \ > --ondisk sda --fstype=ext3 --label secondary --align 1024 > > bootloader --timeout=0 --append="rootwait rootfstype=ext3 video=vesafb > vga=0x318 console=tty0" > > The special thing is the /standby partition. Which using rootfs with > a extra '--rootfs' argument instruct the RootfsPlugin what should be > the rootfs directory to be used to create the partition. > > It is a very simple features that let users to customize your partition > setup. I thought in the case where we have two rootfs (like active and > standby, e.g used to software update). Or the odd cases when a special > partition need to be create to hold whatever files. > > The workflow of wic use remains the same. All the config needs to be done > in .wks file. > > To test I used as a rootfs created by 'bitbkae > core-image-minimal-dev' > (e.g: > /srv/build/yocto/master/tmp/work/genericx86-poky-linux/core-image-minimal-dev/1.0-r0/rootfs). > Hi João, This is a nice generalization of the --source plugin for the rootfs and it does allow users to create .wks files that address a particular image's needs with hard-coded paths to rootfs dirs, which I think is something that the tool does need to be able to handle. However, I think we also need to be able to create more general-purpose .wks files that don't hard-code the directories but instead take the directory names from the command-line. Currently what we have for that purpose is: wic create ... --rootfs-dir /some/rootfs/dir And because we only support one rootfs partition at the moment, that --rootfs-dir automatically gets assigned to the single --source rootfs: part / --source rootfs --ondisk sda --fstype=ext3 --label primary --align 1024 Generalizing that to multiple directories could look something like this: wic create ... --rootfs-dir /some/rootfs/dir --rootfs-dir /some/other/rootfs/dir That would assign the first to the / partition and the second to the /standby partition if using this in the .wks file: part / --source rootfs --ondisk sda --fstype=ext3 --label primary --align 1024 part /standby --source rootfs --rootfs= \ --ondisk sda --fstype=ext3 --label secondary --align 1024 The problem is that we're relying on ordering between the .wks file and the command-line, and what if we're also using the -e param? - that assumes the --rootfs-dir is coming from the image file. I'd rather just ignore -e altogether when thinking about this, since it's really just a usability hack and I don't think it should drive the overall interface. In any case, I think the connection between a command-line param and the line in the .wks file should be explicit, but I'm not sure about the best way do do that, maybe something like: wic create ... --rootfs-dir rootfs1=/some/rootfs/dir --rootfs-dir rootfs2=/some/other/rootfs/dir part / --source rootfs --rootfs-dir="rootfs1" --ondisk sda --fstype=ext3 --label primary --align 1024 part /standby --source rootfs --rootfs-dir="rootfs2" \ --ondisk sda --fstype=ext3 --label secondary --align 1024 In the above case, 'rootfs1' and 'rootfs2' provide the connection (and could be named anything, they're just strings). The default, as is currently the case, is if --source rootfs is used alone and no --rootfs-dir is specified for that line in the .wks file, in which case the rootfs dir is automatically supplied by the --rootfs-dir /some/rootfs/dir (or from the rootfs in the -e image). Your current hard-coded secondary use case would still work without any explicit named params - /standby would use --rootfs-dir=/some/rootfs/dir and / would use either the rootfs from either -e or -r: wic create ... hard-coded-path.wks -e core-image-minimal or wic create ... hard-coded-path.wks -r /some/rootfs/dir part / --source rootfs --ondisk sda --fstype=ext3 --label primary --align 1024 part /standby --source rootfs --rootfs-dir=/some/rootfs/dir \ --ondisk sda --fstype=ext3 --label secondary --align 1024 And we can still use a default rootfs dir with a named dir for the other partition: wic create ... -e core-image-minimal rootfs2=/some/other/rootfs/dir or wic create ... --rootfs-dir /some/rootfs/dir --rootfs-dir rootfs2=/some/other/rootfs/dir part / --source rootfs --ondisk sda --fstype=ext3 --label primary --align 1024 part /standby --source rootfs --rootfs-dir="rootfs2" \ --ondisk sda --fstype=ext3 --label secondary --align 1024 So I guess that's what make sense to me, but I'd be happy to hear other ideas. In any case, at minimum I think that you should change the syntax from --rootf
Re: [OE-core] [PATCH] Add init script (sysv) support for busybox's ntpd
On Fri, Mar 21, 2014 at 01:59:15PM +, Laszlo Papp wrote: > On Thu, Mar 20, 2014 at 7:59 PM, Burton, Ross wrote: > > On 20 March 2014 19:01, Laszlo Papp wrote: > >> This init script is adding support for sysv and no more. This is also > >> indicated in the first line of the commit message. I am sorry, but I > >> will not test it systemd and with other systems > > > > You're not being asked to test with systemd. You're being asked to > > add LSB-standard sysvinit-specific headers to a sysvinit script. > > In my understanding, people were referring to two issues: > > 1) not working with systemd and what not compat modes. This is not > something I will test any soon. Other people already know it's causing the issues without LSB headers, so if you just add them, you don't need to test it with systemd, other people who care about systemd will do that for you or at least be OK with adding this script, because it will have LSB headers (so it should work fine in systemd world). > 2) It is not consistent, whereas if I take a look into busybox, the > consistency is what I do, apparently. > > I would like to quote from the Fedora wiki for instance: > > "LSB Headers are not required for Fedora SysV-style initscripts, but > they may be used. There is no requirement in the LSB certification for > any system scripts to be LSB compliant, and it can cause issues with > ordering." > > So what is wrong about it without systemd and other compat modes? If > it is that big a deal (i.e. blocker), perhaps it is better to document > it in the contribution guideline as a generic trap. > -- > ___ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] OpenEmbedded and musl-libc
On 21 March 2014 13:10, Burton, Ross wrote: > On 21 March 2014 12:34, Paul Barker wrote: >> I'm currently very busy between various projects so I don't have time >> to hack together a musl-libc recipe myself but I should have time to >> help test it. > > I saw that yesterday too and thought it could be interesting for > Yocto. I'm curious as to why it's better than uclibc though > (genuinely curious, I know little about uclibc beyond "it's smaller"). > > Ross Looking at what they say: Better standards compliance, different license, better for static linking, full UTF-8 support, strong fail-safe guarantees. I am taking that at face value as I haven't really done my own comparison of glibc/uclibc/musl. I've been following the news of musl development for a while though and I like the direction they're heading in. Thanks, -- 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
Re: [OE-core] [PATCH] Add init script (sysv) support for busybox's ntpd
On Thu, Mar 20, 2014 at 7:59 PM, Burton, Ross wrote: > On 20 March 2014 19:01, Laszlo Papp wrote: >> This init script is adding support for sysv and no more. This is also >> indicated in the first line of the commit message. I am sorry, but I >> will not test it systemd and with other systems > > You're not being asked to test with systemd. You're being asked to > add LSB-standard sysvinit-specific headers to a sysvinit script. In my understanding, people were referring to two issues: 1) not working with systemd and what not compat modes. This is not something I will test any soon. 2) It is not consistent, whereas if I take a look into busybox, the consistency is what I do, apparently. I would like to quote from the Fedora wiki for instance: "LSB Headers are not required for Fedora SysV-style initscripts, but they may be used. There is no requirement in the LSB certification for any system scripts to be LSB compliant, and it can cause issues with ordering." So what is wrong about it without systemd and other compat modes? If it is that big a deal (i.e. blocker), perhaps it is better to document it in the contribution guideline as a generic trap. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [yocto] OpenEmbedded and musl-libc
> > > I saw that yesterday too and thought it could be interesting for > Yocto. I'm curious as to why it's better than uclibc though > (genuinely curious, I know little about uclibc beyond "it's smaller"). > It been a while since I've reviewed uclibc, but doesn't it break a lot of software with its vfork only paradigm? Seth -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] OpenEmbedded and musl-libc
On 21 March 2014 12:34, Paul Barker wrote: > I'm currently very busy between various projects so I don't have time > to hack together a musl-libc recipe myself but I should have time to > help test it. I saw that yesterday too and thought it could be interesting for Yocto. I'm curious as to why it's better than uclibc though (genuinely curious, I know little about uclibc beyond "it's smaller"). Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] OpenEmbedded and musl-libc
Hi all, musl-libc hit version 1.0.0 yesterday and is starting to look good to me. It's basically a really small but very functional libc that would suit embedded environments very well as an alternative to eglibc/uclibc. I'm personally very interested in using it in my projects and I also think it could fit in well with the aims of poky-tiny. http://www.etalabs.net/compare_libcs.html gives some pretty useful info. I'm basically emailing to see if anyone else is interested in this or if anyone has looked at using it before in OpenEmbedded as a google for previous discussions didn't turn anything up. I'm currently very busy between various projects so I don't have time to hack together a musl-libc recipe myself but I should have time to help test it. Thanks, -- 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
Re: [OE-core] libm accuracy, eglibc compared to glibc -- solved
Hi,
On: Thursday, March 13, 2014 11:36 AM, Mats Kärrman wrote:
> My "home made" hard float tune for PowerPC looks like this:
>
> --
> # Tune for the e300c3 core
> require conf/machine/include/tune-ppce300c3.inc
>
> # Use hardware floating point
> AVAILTUNES += "ppce300c3hf"
> TUNE_FEATURES_tune-ppce300c3hf = "m32 fpu-hard ppce300c3"
> TUNE_PKGARCH_tune-ppce300c3hf = "ppce300c3hf"
> PACKAGE_EXTRA_ARCHS_tune-ppce300c3hf = "${PACKAGE_EXTRA_ARCHS_tune-powerpc}
> ppce300c3hf"
> DEFAULTTUNE = "ppce300c3hf"
> --
>
I found the reason for the error (deviance) in the sqrt function. glibc has
special code for PowerPC 603e core (e300 is an optimized variant of 603e).
By adding the following line to the tuning I now get the same result as
for all other environments that I've tried:
GLIBC_EXTRA_OECONF += "${@bb.utils.contains("TUNE_FEATURES", "ppce300c3",
"-with-cpu=603e", "", d)}"
Does anyone know about the reason for having soft-float as the default and
only available alternative for e300c2/3 tunings?
Would it be worthwhile to send a patch to add the hf tuning to OE-core?
In that case what tests should be performed before that and what (related)
tests are performed by the OE auto-builder?
BR // Mats
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/3] classes/kernel: move module postinst commands to kernel-base
On Thu, 2014-03-20 at 15:15 +, Paul Eggleton wrote: > Since kernel-base is the package that contains the files that depmod > needs to run, we should be running depmod from the kernel-base > postinstall rather than kernel-image. > > Fixes [YOCTO #5392]. > > Signed-off-by: Paul Eggleton > --- > meta/classes/kernel.bbclass | 7 +-- > 1 file changed, 5 insertions(+), 2 deletions(-) I think this might have triggered: http://autobuilder.yoctoproject.org/main/builders/nightly-multilib/builds/105/steps/BuildImages_3/logs/stdio 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
> 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 -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
. 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_VAR
[OE-core] [PATCH v2] kernel-arch.bbclass: add arm64 support to U-Boot architecture map
to define UBOOT_ARCH, we map kernel architectures to U-Boot architectures.
In the case of arm64 kernel, we should map to arm U-boot architecture.
This patch add the exception rule to the map_uboot_arch function.
Signed-off-by: Fathi Boudra
---
meta/classes/kernel-arch.bbclass | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/classes/kernel-arch.bbclass b/meta/classes/kernel-arch.bbclass
index 6a6ad91..bbcfa15 100644
--- a/meta/classes/kernel-arch.bbclass
+++ b/meta/classes/kernel-arch.bbclass
@@ -40,6 +40,7 @@ def map_uboot_arch(a, d):
if re.match('p(pc|owerpc)(|64)', a): return 'ppc'
elif re.match('i.86$', a): return 'x86'
+elif re.match('arm64$', a): return 'arm'
return a
export UBOOT_ARCH = "${@map_uboot_arch(d.getVar('ARCH', True), d)}"
--
1.8.1.2
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
