gmane.comp.handhelds.openembedded

Re: [oe] Where do I override DISTRO_FEATURES?

Otavio Salvador — 2012-05-17T00:35:55

Which udev?

Re: [oe] Where do I override DISTRO_FEATURES?

Khem Raj — 2012-05-16T21:19:39

I have had systemd work with 2.6.34 Koen has some options he mentions
you need to enable in kconfig

http://dominion.thruhere.net/koen/cms/recommended-kernel-config-options-for-a-modern-angstrom-system

Re: [oe] Where do I override DISTRO_FEATURES?

R U Local — 2012-05-16T20:55:33

Dear Thilo, Anyone else,
How did you get oe-core/Angstrom-v2012x to build a working system using a 2.6.37 kernel?
I'm in a similar position using TI AM3517. The latest angstrom is built around systemd which requires a 2.6.38 or better kernel.
I've had to reluctantly revert back to oe-classic and angstrom 2011.03.
Any hints on getting oe-core/Angstrom-v2012x working with a 2.6.37 kernel would be great.

Cheers Mike.

-----Original Message-----
From: openembedded-devel-bounces< at >lists.openembedded.org [mailto:openembedded-devel-bounces< at >lists.openembedded.org] On Behalf Of Thilo Fromm
Sent: Wednesday, 16 May 2012 20:38
To: openembedded-devel< at >lists.openembedded.org
Subject: Re: [oe] Where do I override DISTRO_FEATURES?

Hello Koen,


We're using angstrom-v2012.x.conf from the git HEAD since we want to stay with latest and greatest for now. angstrom-v2012.x.conf is using gold. It's OK, really, I think I can handle the gcc-4.5 configure build problem.

Regards,
Thilo

--
Dipl.-Ing (FH) Thilo Fromm, MSc., Embedded Sy

[oe] [meta-oe][RFC] libnl: upgrade to 3.2.9 and fix upgrade path

Martin Jansa — 2012-05-16T20:53:00

* COPYING change is only formal from
  http://git.infradead.org/users/tgr/libnl.git/commitdiff/c857625be074a7b9ef6adbcdde986a0b23aae901

Signed-off-by: Martin Jansa <Martin.Jansa< at >gmail.com>
---
 .../libnl/{libnl_3.2.3.bb => libnl_3.2.9.bb}       |   14 +++++++++-----
 1 files changed, 9 insertions(+), 5 deletions(-)
 rename meta-oe/recipes-support/libnl/{libnl_3.2.3.bb => libnl_3.2.9.bb} (74%)

diff --git a/meta-oe/recipes-support/libnl/libnl_3.2.3.bb b/meta-oe/recipes-support/libnl/libnl_3.2.9.bb
similarity index 74%
rename from meta-oe/recipes-support/libnl/libnl_3.2.3.bb
rename to meta-oe/recipes-support/libnl/libnl_3.2.9.bb
index 38d34bf..11b901c 100644
--- a/meta-oe/recipes-support/libnl/libnl_3.2.3.bb
+++ b/meta-oe/recipes-support/libnl/libnl_3.2.9.bb
< at >< at > -5,14 +5,14 < at >< at > SECTION = "libs/network"
 PE = "1"
 
 LICENSE = "LGPLv2.1"
-LIC_FILES_CHKSUM = "file://COPYING;md5=2b41e13261a330ee784153ecbb6a82bc"
+LIC_FILES_CHKSUM = "file://COPYING;md5=4fbd65380cdd255951079008b364516c"
 
 DEPENDS = "flex-native biso

Re: [oe] [meta-oe][PATCH] systemd.bbclass: drop postrm,use prerm instead

Otavio Salvador — 2012-05-16T18:11:41

On Wed, May 16, 2012 at 1:56 PM, Andreas Oberritter
<obi< at >opendreambox.org> wrote:

Acked-by: Otavio Salvador <otavio< at >ossystems.com.br>

Re: [oe] [toolchain-layer][pull-request] Remove old toolchainrecipes

Khem Raj — 2012-05-16T18:08:03

then use the default gcc that angstrom head is using which is 4.7 and also be
ready to experience some bugs as well yes -mno-unaligned-access is
needed for kernel
in some cases but eventually I think new kernel should be able to handle them

Re: [oe] [meta-oe][PATCH] libnl: bump PE

Martin Jansa — 2012-05-16T17:52:24

upgrade path would be even better if someone adds RREPLACES/RCONFLICTS
magic to resolve this:

 * check_data_file_clashes: Package libnl-3-200 wants to install file /etc/libnl/pktloc
   But that file is already provided by package  * libnl2

Cheers,

[oe] [meta-oe][PATCH] systemd.bbclass: drop postrm,use prerm instead

Andreas Oberritter — 2012-05-16T16:56:01

* Calling "systemctl disable" from postrm is too late and
  causes the following error:

| Failed to issue method call: No such file or directory

* Messing with $D is not needed in *rm scripts.

Signed-off-by: Andreas Oberritter <obi< at >opendreambox.org>
---
 meta-oe/classes/systemd.bbclass |   15 ++-------------
 1 file changed, 2 insertions(+), 13 deletions(-)

diff --git a/meta-oe/classes/systemd.bbclass b/meta-oe/classes/systemd.bbclass
index db35717..1edd1e4 100644
--- a/meta-oe/classes/systemd.bbclass
+++ b/meta-oe/classes/systemd.bbclass
< at >< at > -15,12 +15,7 < at >< at > fi
 }
 
 systemd_prerm() {
-if [ -z "$D" ]; then
-    systemctl stop ${SYSTEMD_SERVICE}
-fi
-}
-
-systemd_postrm() {
+systemctl stop ${SYSTEMD_SERVICE}
 systemctl disable ${SYSTEMD_SERVICE}
 }
 
< at >< at > -93,7 +88,7 < at >< at > do_install_append() {
 
 python populate_packages_prepend () {
 def systemd_generate_package_scripts(pkg):
-bb.debug(1, 'adding systemd calls to postinst/postrm for %s' % pkg)
+bb.debug(1, 'adding systemd calls to postinst/prerm for %s'

Re: [oe] [toolchain-layer][pull-request] Remove old toolchainrecipes

Thilo Fromm — 2012-05-16T16:47:55

Hello Khem,


Thanks for the warning, Khem, but I'm well aware of this, I just had
my first round: making gcc-4.5 + eglibc build with the Binutils gold
linker. There is an issue in gcc/configure[.ac]. I won this time :)
(see <https://github.com/DFE/HidaV/blob/master/meta-hidav/recipes-devtools/gcc/gcc-4.5/gcc-4.5-detect-gold-linker-version-correctly.patch>


Actually we'd like to stay on HEAD and build our own distribution on
top of that. Hence I'm more interested in getting ti81xx-psp-2.6.37 to
work with gcc-4.7. I'll try Martin Jansa's hint
(-mno-unaligned-access) next.

Regards,
Thilo

Re: [oe] [toolchain-layer][pull-request] Remove old toolchainrecipes

Khem Raj — 2012-05-16T16:18:37

btw. angstrom/master will be using gcc 4.7 so you are on your own if you use
4.5 with angstrom/master and it can be a long battle. Best course for you is to
use 2012.05 angstrom stable where you will get gcc 4.5 from toolchain-layer
and it will be maintained there if any issues found. So you dont need
to duplicate
the efforts.

_______________________________________________
Openembedded-devel mailing list
Openembedded-devel< at >lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: [oe] [toolchain-layer][pull-request] Remove old toolchainrecipes

Khem Raj — 2012-05-16T16:13:10

how so ? can you stick with denzil stable branch if you so heavily depend on 4.5
and meanwhile let the software stack for these SOCs ported to newer gcc
or is there anything that you absolutely need from master ?


You only get a heavily patched 2.6.37 kernel from TI for

[oe] [meta-oe][PATCH] libnl: bump PE

Martin Jansa — 2012-05-16T15:18:14

* libnl-2 in oe-core has PE 1, so in order to have upgrade patch from libnl-2 to libnl-3 we need PE 1 here too

Signed-off-by: Martin Jansa <Martin.Jansa< at >gmail.com>
---
 meta-oe/recipes-support/libnl/libnl_3.2.3.bb |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/meta-oe/recipes-support/libnl/libnl_3.2.3.bb b/meta-oe/recipes-support/libnl/libnl_3.2.3.bb
index 190ea4c..38d34bf 100644
--- a/meta-oe/recipes-support/libnl/libnl_3.2.3.bb
+++ b/meta-oe/recipes-support/libnl/libnl_3.2.3.bb
< at >< at > -2,6 +2,8 < at >< at > DESCRIPTION = "libnl is a library for applications dealing with netlink sockets.
 HOMEPAGE = "http://www.infradead.org/~tgr/libnl/"
 SECTION = "libs/network"
 
+PE = "1"
+
 LICENSE = "LGPLv2.1"
 LIC_FILES_CHKSUM = "file://COPYING;md5=2b41e13261a330ee784153ecbb6a82bc"

Re: [oe] [toolchain-layer][pull-request] Remove old toolchainrecipes

Thilo Fromm — 2012-05-16T15:03:22

Hello Gary,

[ ti81xx-psp-2.6.37 defconfig ]

This is subject to speculation. David Illies, our TI field application
engineer, keeps telling us that 3.2 will be supported "eventually". I
personally don't think they ever will - the commit history in their
public git does not look like anyone is doing any portage work. Plus
3.2, the version they keep mentioning, is starting to smell oldish as
well. I would very much like to see support for dm81xx in something
_current_, but it's unrealistic given previous experiences with TI.


Thanks, looks like I'll need it :)  By the way, we successfully pulled
gcc-4.5 in our layer and are building with gcc-4.5 on angstrom-v2012.x
right now. Since you're on 8148 as well, and in case you would like to
stay up-to-date on what we're doing, just check
https://github.com/DFE/HidaV from time to time.

Regards,
Thilo

[oe] packages built but not deployed - RECALL

Mats Kärrman — 2012-05-16T13:28:50

Sorry, I'm too tired...
the packages are called libcunit... and not cunit... that I was looking for.
// Mats
________________________________________
From: Mats Kärrman
Sent: Wednesday, May 16, 2012 2:48 PM
To: openembedded-devel< at >lists.openembedded.org
Subject: packages built but not deployed

Hi,

I have made an OE-classic recipe for CUnit, see below, that I'm using together with 2011.03-maintenance and a "headless" Angstrom image.
There was one complication; the source folder inside the source tar contains upper-case letters but there is a rule in do_package_stage that only accepts lower case letters in the recipe name. The explicit setting of "S" below together with using only lower case letters for the recipe seemed to solve this problem.

cunit_2.1-2.bb:
------------------------------------------------------------------
DESCRIPTION = "Automated testing framework for 'C'."
HOMEPAGE = "http://sourceforge.net/projects/cunit/"
PRIORITY = "optional"
SECTION = "libs"
LICENSE = "LGPLv2"
PR = "r0"

inherit aut

[oe] packages built but not deployed

Mats Kärrman — 2012-05-16T12:48:48

Hi,

I have made an OE-classic recipe for CUnit, see below, that I'm using together with 2011.03-maintenance and a "headless" Angstrom image.
There was one complication; the source folder inside the source tar contains upper-case letters but there is a rule in do_package_stage that only accepts lower case letters in the recipe name. The explicit setting of "S" below together with using only lower case letters for the recipe seemed to solve this problem.

cunit_2.1-2.bb:
------------------------------------------------------------------
DESCRIPTION = "Automated testing framework for 'C'."
HOMEPAGE = "http://sourceforge.net/projects/cunit/"
PRIORITY = "optional"
SECTION = "libs"
LICENSE = "LGPLv2"
PR = "r0"

inherit autotools

# Recipe name must be all lower case because of do_package_stage rule but source
# tar uses uppercase in source code folder name, hence:
S = "${WORKDIR}/CUnit-${PV}"

SRC_URI = " \
    ${SOURCEFORGE_MIRROR}/project/cunit/CUnit/2.1-2/CUnit-2.1-2-src.tar.bz2;name=cunit \
    "

SRC_URI[cun

Re: [oe] [toolchain-layer][pull-request] Remove old toolchainrecipes

Gary Thomas — 2012-05-16T12:44:38

Fair enough, I was just pointing out a possible source of your pain :-)

BTW, do you know if TI ever plans on updating the kernel?  2.6.37 is so
painfully old...


Good luck

Re: [oe] [toolchain-layer][pull-request] Remove old toolchainrecipes

Thilo Fromm — 2012-05-16T12:41:22

Hello Gary,


Thanks, but I don't think I will disable most of the debugging
features for now. We have e.g. memory leak reports by the kernel
memchecker in ext4. Given the pitiful state of linux-ti81xx-psp_2.6.37
in general I'm not willing to give up the little debug info I get.


We're almost using this recipe too. We just appended AUFS integration
and custom package management installer scripts for the kernel. I'll
look into -mno-unaligned-access w/ gcc-4.7 as Gary suggested as soon
as I am finished moving gcc-4.5 into HidaV so we can actually build
firmware again :)

Regards,
Thilo

Re: [oe] [toolchain-layer][pull-request] Remove old toolchainrecipes

Thilo Fromm — 2012-05-16T12:30:39

Hello Martin,


Thanks a lot for the hint, it's greatly appreciated. I'll revisit 4.7
to check whether this fixes our issue after I restored 4.5 for us. I
prefer small steps :) I guess I'll move the whole gcc-4.5... stuff
into our own layer for now.

Regards,
Thilo

Re: [oe] [toolchain-layer][pull-request] Remove old toolchainrecipes

Gary Thomas — 2012-05-16T11:38:57

The only real differences (modulo the hardware/peripherals in use)
are some of the kernel debugging settings.  Perhaps they are causing
some problems with the newer compiler.  The diffs between our configurations
are attached.

As Martin points out, the newer compilers can have problems with unaligned
access.  I've also [sometimes] had better success if I disable OPTIMIZE_FOR_SIZE

The only other thing I see is the kernel version & recipe used.  I am using
the stock one from meta-ti + some platform patches.  Perhaps there's something
else to look at.
   meta-ti/recipes-kernel/linux/linux-ti81xx-psp_2.6.37.bb

Re: [oe] [toolchain-layer][pull-request] Remove old toolchainrecipes

Martin Jansa — 2012-05-16T11:24:58

if gcc-4.6 was from meta-toolchain (including linaro patch
toolchain-layer/recipes-devtools/gcc/gcc-4.6/linaro/gcc-4.6-linaro-r106827.patch)
then you need to pass -mno-unaligned-access in your kernel Makefile
like this commit does:
http://git.freesmartphone.org/?p=linux-2.6.git;a=commit;h=78ffc81db8911acdabd026ad3fdefa20b4e34e52

be aware that without this patch -mno-unaligned-access is not valid
option for gcc (older than 4.7).

Cheers.

_______________________________________________
Openembedded-devel mailing list
Openembedded-devel< at >lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: [oe] [toolchain-layer][pull-request] Remove old toolchainrecipes

Thilo Fromm — 2012-05-16T11:07:50

Hello Gary,


Sure! Our project is on github, and so is our defconfig:
<https://github.com/DFE/HidaV/blob/master/meta-hidav/recipes-kernel-bootloader/linux/files/defconfig>

We added aufs (Another Union File system) and the blockrom MTD FTL to
the kernel, so there are additional options in our configuration.

Thanks for your effort, Gary,
regards,
Thilo