Re: [OE-core] [PATCH] arch-arm64.inc: Do not append aarch64 in MACHINEOVERRIDES

[Herve Jourdain]

Hi,

Just my 2 cents about this.
armv8-a is the architecture of the arm core, while aarch64/aarch32 is the
execution mode on said architecture.
So I believe that we should have overrides for BOTH the architecture and the
execution mode, as you can have armv8-a executing in 32 bits mode - and btw,
the instruction set in 32 bits mode is not exactly the same as armv7-ve, so
in terms of optimization it does help to know you're running on an armv8-a
architecture, even if it's in 32 bits mode.
There was no such problem before armv8-a architecture, since all previous
architectures were running in 32 bits mode only. Armv8-a changes that as
it's a "hybrid", with support for both aarch64 and aarch32.
I expect later arch to support only aarch64.

There is also an additional thing to consider, there is not just one armv8-a
profiles, there already are several, and they shall all be taken into
account.
I believe that at this time, the valid ones are armv8.0-a, armv8.1-a,
armv8.2-a, armv8.3-a  and armv8.4-a.

And let me answer before someone asks, yes the gcc compiler DOES provide
compiler options for all those architectures, with those exact names -
except armv8.0-a is just named armv8-a (-march=armv8-a or
-march=armv8.[1,2,3,4]-a).
So it just makes sense to support them all.

So overall, I believe we should support all those arm v8 architectures, and
add the corresponding override to the cpu definition files (for instance, as
Peter mentioned, cortex-a53 is an armv8.0-a. But a cortex-a55 or cortex-a75
would be an armv8.2-a).

Finally, the arm architecture is slightly more complex than just armv8.x-a,
since the support for "features" is optional. So at least "crc" and "crypto"
features should be added, in order to have a "comprehensive" view of the
armv8 architecture. And yes, the "features" are also supported by the gcc
compiler.
So the arm architecture would really be fully defined by
armv8.x-a+[no]crc+[no]crypto, depending on the underlying SoC and what they
implemented or not as optional features. And this is probably what should
end up going into the tune-cortexa53.inc and others (and should be
override-able, since again not all cortexa53 are created the same).

Cheers,
Herve

-Original Message-
From: openembedded-core-boun...@lists.openembedded.org
 On Behalf Of Peter
Kjellerstedt
Sent: 03 March 2020 13:00
To: Junling Zheng ; Khem Raj ;
openembedded-core@lists.openembedded.org
Cc: wangn...@huawei.com
Subject: Re: [OE-core] [PATCH] arch-arm64.inc: Do not append aarch64 in
MACHINEOVERRIDES

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org 
>  On Behalf Of 
> Junling Zheng
> Sent: den 3 mars 2020 04:11
> To: Khem Raj ; openembedded- 
> c...@lists.openembedded.org
> Cc: wangn...@huawei.com
> Subject: Re: [OE-core] [PATCH] arch-arm64.inc: Do not append aarch64 
> in MACHINEOVERRIDES
> 
> On 2020/3/3 2:29, Khem Raj wrote:
> >
> >
> > On 3/2/20 9:11 AM, Junling Zheng wrote:
> >> Currently, for arch-arm64, poky will append the MACHINEOVERRIDES 
> >> with "aarch64:", which has the higher priority than
TRANSLATED_TARGET_ARCH.
> >> So, for aarch64 big endian, the variable '_aarch64' will 
> >> override not only '', but also '_aarch64-be', thus we 
> >> will get an incorrect variable.
> >>
> >> Signed-off-by: Junling Zheng 
> >> ---
> >>   meta/conf/machine/include/arm/arch-arm64.inc | 2 --
> >>   1 file changed, 2 deletions(-)
> >>
> >> diff --git a/meta/conf/machine/include/arm/arch-arm64.inc
> b/meta/conf/machine/include/arm/arch-arm64.inc
> >> index 53f4566815..32294bd218 100644
> >> --- a/meta/conf/machine/include/arm/arch-arm64.inc
> >> +++ b/meta/conf/machine/include/arm/arch-arm64.inc
> >> @@ -4,8 +4,6 @@ require conf/machine/include/arm/arch-armv7ve.inc
> >> TUNEVALID[aarch64] = "Enable instructions for aarch64"
> >>   -MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES',
'aarch64', 'aarch64:', '' ,d)}"
> >> -
> >
> > if its removed here, where is it being added for other machines,
> question is, should we treat aarch64 as LE equivalent of aarch64_be
> > or should be treated as common aarch64 and a new define like 
> > aarch64_le
> defined.
> >
> 
> Currently, for arm64, we have aarch64_be to represent big endian, but 
> no overrides to represent little endian only.
> 
> So, IMO, we should treat aarch64 as little enaian only, like arm and 
> armeb.
> 
> >>   # Little Endian base configs
> >>   AVAILTUNES += "aarch64 aarch64_be"
> >>   ARMPKGARCH_tune-aarch64 ?= "aarch64"

Please, before removing "aarch64" from MACHINEOVERRIDES, add "armv8a" or
similar. This is how it is done for the armv7* based chips. E.g., I would
expect to see tune-cortexa53.inc have:

MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'cortexa53',
'armv8a:', '' ,d)}"

Which corresponds to how it is done for armv7*.

At least we currently rely on being able to do, e.g.:

COMPATIBLE_MACHINE = "aarch64|armv7a|armv7ve"

and if you remove "aarch64" from MACHINEOVERRIDES, we need a suitable

Re: [OE-core] [PATCH 1/1] db: disable the ARM assembler mutex code

[Herve Jourdain]

Hi,

Actually, I meant "works" in the sense of "does compile" - as opposed to armv8 
where it does not compile, which is why we're having this discussion in the 
first place.
So I was merely suggesting to not modify previous oe behavior for the db 
package for previous architectures, and just add the removal of 'swp' for 
armv8, where it matters most.

If we want to look at it in details, based on the "ARM Architecture Reference 
Manual ARMv7-A and ARMv7-R edition":
1. SWP is the way to go before ARMv6.
2. SWP has been deprecated in ARMv6.
3. SWP has been deprecated AND made optional in ARMv7ve.
4. "The SWP and SWPB instructions rely on the properties of the system beyond 
the processor to ensure that no stores from other observers can occur between 
the load access and the store access, and this might not be implemented for all 
regions of memory on some system implementations. In all cases, SWP and SWPB do 
ensure that no stores from the processor that executed the SWP or SWPB 
instruction can occur between the load access and the store access of the SWP 
or SWPB."

This latest part means that it may or may not work in SMP environments, it 
depends on how the system is architecture around the cores - most likely how 
the bus system is designed I believe. So it may actually be working fine if the 
system/bus designer has taken that into account.

This said, I believe that from point #3 above, it might make sense to disable 
SWP for armv7ve as well, since being optional means that it might be compiled 
correctly, but still fail at runtime, depending on the choices of the SoC 
manufacturer.
So my recommendation would be to add:
MUTEX_armv7ve = ""
MUTEX_armv8 = ""

To disable 'swp' by default only for those 2 archs, while keeping things like 
they are for previous architectures.

Cheers,
Herve

-Original Message-
From: Andre McCurdy [mailto:armccu...@gmail.com] 
Sent: vendredi 15 juin 2018 09:39
To: Herve Jourdain 
Cc: Khem Raj ; Ovidiu Panait ; 
Patches and discussions about the oe-core layer 

Subject: Re: [OE-core] [PATCH 1/1] db: disable the ARM assembler mutex code

On Fri, Jun 15, 2018 at 12:10 AM, Herve Jourdain  wrote:
> Hi,
>
> So the issue is whether we want to change the behaviour of previous 
> architectures, or if we try to fix the issue only for the architectures that 
> don't work.
> Until now, the db recipe was enabling the 'swp' optimization, and that 
> behavior could be disabled on .bbappend if needed.
> While that works fine until armv7ve, it does not work for armv8, which has 
> removed support for those instructions.

I don't know if "works fine until armv7ve" is correct. Although the swp 
instruction exists for armv7, according to the link I posted yesterday, it is 
not guaranteed to work.

  
https://community.arm.com/processors/b/blog/posts/locks-swps-and-two-smoking-barriers

Or do you have other evidence to suggest that swp is safe to use for armv7?

> Therefore, there is a need to fix it for armv8 - and armv8 only - whereas it 
> can be safely used on previous architectures.
> If we remove the use for all ARM architectures, that might create some 
> regression/issues.
> If we just remove the use of 'swp' only for armv8, we ensure it doesn't break 
> anything that's running on previous ARM architectures.
>
> Cheers,
> Herve
>
> -Original Message-
> From: Andre McCurdy [mailto:armccu...@gmail.com]
> Sent: vendredi 15 juin 2018 00:03
> To: Khem Raj 
> Cc: Herve Jourdain ; Ovidiu Panait 
> ; Patches and discussions about the 
> oe-core layer 
> Subject: Re: [OE-core] [PATCH 1/1] db: disable the ARM assembler mutex 
> code
>
> On Thu, Jun 14, 2018 at 2:48 PM, Khem Raj  wrote:
>> On Thu, Jun 14, 2018 at 1:01 PM Andre McCurdy  wrote:
>>> On Thu, Jun 14, 2018 at 12:24 PM, Khem Raj  wrote:
>>> > On Thu, Jun 14, 2018 at 12:12 PM Andre McCurdy 
>>> > 
>>> > wrote:
>>> >>
>>> >> On Thu, Jun 14, 2018 at 9:40 AM, Khem Raj  wrote:
>>> >> > On 6/14/18 5:10 AM, Herve Jourdain wrote:
>>> >> >> Hi,
>>> >> >>
>>> >> >> I believe I solved that same problem by just adding, in the 
>>> >> >> case of
>>> >> >> armv8
>>> >> >> (which I believe may be the new architecture you're referring to):
>>> >> >> MUTEX_armv8 = ""
>>> >> >> This way, it allows previous versions to work just like they 
>>> >> >> did before, without having to disable ARM assembler mutex code 
>>> >> >> for architectures that support it correctly - up to armv7ve I 
>>> >> >> believe.
>>> >> >> Of course,

Re: [OE-core] [PATCH 1/1] db: disable the ARM assembler mutex code

[Herve Jourdain]

Hi,

So the issue is whether we want to change the behaviour of previous 
architectures, or if we try to fix the issue only for the architectures that 
don't work.
Until now, the db recipe was enabling the 'swp' optimization, and that behavior 
could be disabled on .bbappend if needed.
While that works fine until armv7ve, it does not work for armv8, which has 
removed support for those instructions.
Therefore, there is a need to fix it for armv8 - and armv8 only - whereas it 
can be safely used on previous architectures.
If we remove the use for all ARM architectures, that might create some 
regression/issues.
If we just remove the use of 'swp' only for armv8, we ensure it doesn't break 
anything that's running on previous ARM architectures.

Cheers,
Herve

-Original Message-
From: Andre McCurdy [mailto:armccu...@gmail.com] 
Sent: vendredi 15 juin 2018 00:03
To: Khem Raj 
Cc: Herve Jourdain ; Ovidiu Panait 
; Patches and discussions about the oe-core layer 

Subject: Re: [OE-core] [PATCH 1/1] db: disable the ARM assembler mutex code

On Thu, Jun 14, 2018 at 2:48 PM, Khem Raj  wrote:
> On Thu, Jun 14, 2018 at 1:01 PM Andre McCurdy  wrote:
>> On Thu, Jun 14, 2018 at 12:24 PM, Khem Raj  wrote:
>> > On Thu, Jun 14, 2018 at 12:12 PM Andre McCurdy 
>> > 
>> > wrote:
>> >>
>> >> On Thu, Jun 14, 2018 at 9:40 AM, Khem Raj  wrote:
>> >> > On 6/14/18 5:10 AM, Herve Jourdain wrote:
>> >> >> Hi,
>> >> >>
>> >> >> I believe I solved that same problem by just adding, in the 
>> >> >> case of
>> >> >> armv8
>> >> >> (which I believe may be the new architecture you're referring to):
>> >> >> MUTEX_armv8 = ""
>> >> >> This way, it allows previous versions to work just like they 
>> >> >> did before, without having to disable ARM assembler mutex code 
>> >> >> for architectures that support it correctly - up to armv7ve I 
>> >> >> believe.
>> >> >> Of course, we might need to also have a good definition for 
>> >> >> armv8, which is the object of another thread.
>> >> >
>> >> > right thats a better approach.
>> >>
>> >> SWP is not guaranteed to work on SMP systems... and even if it 
>> >> does, performance is likely to be worse than the pthreads version 
>> >> (which can take advantage of the newer instructions).
>> >>
>> >>
>> >> https://community.arm.com/processors/b/blog/posts/locks-swps-and-t
>> >> wo-smoking-barriers
>> >>
>> >> In general, use of hand optimised assembler mutex implementations 
>> >> in user space isn't something to be encouraged - use pthreads (or 
>> >> maybe a gcc intrinsic) instead.
>> >>
>> >
>> > question is about disabling it on old arm machines, do we have data 
>> > where we know that other sync methods without swp works better on 
>> > armv5 and lower ?
>>
>> On armv5 and below a hand optimised implementation using SWP is 
>> likely to be faster than pthreads. No one is suggesting otherwise.
>>
>> On SMP (highly likely nowadays for armv7 and above), SWP simply might 
>> not work (aside from the fact that if it does work, it's likely to be 
>> slower than pthreads). It's not really a question of performance 
>> there, so the proposal to only disable SWP for armv8 doesn't seem 
>> like a safe solution.
>
> Suggestion is not to just do it for armv8 but To keep it there where 
> its beneficial

You can always argue that micro optimisations are beneficial. The question is 
whether they make a big enough difference in some real world use case to be 
worth the maintenance effort.

>> Using pthreads unconditionally is safe and easy. Unless you can prove 
>> that hand optimised SWP is really a big win for armv5 (is anyone 
>> really running a performance critical database on an armv5 system?) 
>> why not keep the recipe simple and use pthreads everywhere?
>>
>> >> I think the original patch is good.
>> >>
>> >> >> Cheers,
>> >> >> Herve
>> >> >>
>> >> >> -Original Message-
>> >> >> From: openembedded-core-boun...@lists.openembedded.org
>> >> >> [mailto:openembedded-core-boun...@lists.openembedded.org] On 
>> >> >> Behalf Of Ovidiu Panait
>> >> >> Sent: jeudi 14 juin 2018 13:55
>> >> >> To: openembedded-core@lists.openembedded.org
>> >> >> Subject: [OE-core] [PATCH

Re: [OE-core] [PATCH 1/1] db: disable the ARM assembler mutex code

[Herve Jourdain]

Hi,

I believe I solved that same problem by just adding, in the case of armv8
(which I believe may be the new architecture you're referring to):
MUTEX_armv8 = ""
This way, it allows previous versions to work just like they did before,
without having to disable ARM assembler mutex code for architectures that
support it correctly - up to armv7ve I believe.
Of course, we might need to also have a good definition for armv8, which is
the object of another thread.

Cheers,
Herve

-Original Message-
From: openembedded-core-boun...@lists.openembedded.org
[mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
Ovidiu Panait
Sent: jeudi 14 juin 2018 13:55
To: openembedded-core@lists.openembedded.org
Subject: [OE-core] [PATCH 1/1] db: disable the ARM assembler mutex code

The swpb in macro MUTEX_SET will cause "undefined instruction" error on the
new arm arches which don't support this assembly instruction any more. If
use ldrex/strex to replace swpb, the old arm arches don't support them. So
to avoid this issue, just disable the ARM assembler mutex code, and use the
default pthreads mutex.

Signed-off-by: Li Zhou 
Signed-off-by: Catalin Enache 
Signed-off-by: Ovidiu Panait 
---
 meta/recipes-support/db/db_5.3.28.bb | 13 +
 1 file changed, 1 insertion(+), 12 deletions(-)

diff --git a/meta/recipes-support/db/db_5.3.28.bb
b/meta/recipes-support/db/db_5.3.28.bb
index 093ee44909..15b4155a29 100644
--- a/meta/recipes-support/db/db_5.3.28.bb
+++ b/meta/recipes-support/db/db_5.3.28.bb
@@ -59,18 +59,7 @@ FILES_SOLIBSDEV = "${libdir}/libdb.so
${libdir}/libdb_cxx.so"
 # All the --disable-* options replace --enable-smallbuild, which breaks a
bunch of stuff (eg. postfix)  DB5_CONFIG ?= "--enable-o_direct
--disable-cryptography --disable-queue --disable-replication
--disable-verify --disable-compat185 --disable-sql"
 
-EXTRA_OECONF = "${DB5_CONFIG} --enable-shared --enable-cxx --with-sysroot"
-
-# Override the MUTEX setting here, the POSIX library is -# the default -
"POSIX/pthreads/library".
-# Don't ignore the nice SWP instruction on the ARM:
-# These enable the ARM assembler mutex code, this won't -# work with thumb
compilation...
-ARM_MUTEX = "--with-mutex=ARM/gcc-assembly"
-MUTEX = ""
-MUTEX_arm = "${ARM_MUTEX}"
-MUTEX_armeb = "${ARM_MUTEX}"
-EXTRA_OECONF += "${MUTEX} STRIP=true"
+EXTRA_OECONF = "${DB5_CONFIG} --enable-shared --enable-cxx --with-sysroot
STRIP=true"
 EXTRA_OEMAKE += "LIBTOOL='./${HOST_SYS}-libtool'"
 
 EXTRA_AUTORECONF += "--exclude=autoheader  -I ${S}/dist/aclocal
-I${S}/dist/aclocal_java"
--
2.17.1

--
___
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 v2 0/4] Add tune for ARMv8 and some cortex processors

[Herve Jourdain]

Hi Andre,

I believe I did say always present on armv8 and armv7, I did not mean before 
that.
Having separate tunes for thumb support was necessary on previous architectures 
where it was optional, but it persisted for architectures which made thumb 
mandatory.
I’m not even advocating removing the tune option for previous architectures 
that would normally not require it, but I believe we should get rid of it for 
new ARM architectures.

Cheers,
Herve

> On 13 Jun 2018, at 04:39, Andre McCurdy  wrote:
> 
>> On Tue, Jun 12, 2018 at 1:00 PM, Mark Hatle  wrote:
>>> On 6/12/18 10:49 AM, Herve Jourdain wrote:
>>> Hi,
>>> 
>>> So I agree with you about restricting to what gcc can support, that's 
>>> actually my proposal (actually, probably a subset of what gcc can support).
>>> So for armv8, gcc supports, as architectures: armv8-a, armv8.1-a, 
>>> armv8.2-a, armv8.3-a, armv8.4-a.
>>> Then, you can add the supported options with a "+" after the architecture.
>>> Options supported for armv8-a are: '+crc', '+simd', '+crypto', '+nocrypto', 
>>> '+nofp'
>>> Options supported for armv8.1-a are: '+simd', '+crypto', '+nocrypto', 
>>> '+nofp'
>>> Options supported for armv8.2-a and armv8.3-a are: '+fp16', '+fp16fml', 
>>> '+simd', '+crypto', '+dotprod', '+nocrypto', '+nofp'
>>> Options supported for armv8.4-a are: '+fp16', '+simd', '+crypto', 
>>> '+dotprod', '+nocrypto', '+nofp'
>>> 
>>> As you can see, proposals for armv8-a, whether my previous one, the new one 
>>> here, or even the one I have updated and used in production, just capture 
>>> the existing complexity, and not add to it.
>>> and support for armv8.1-a, armv8.2-a, armv8.3-a, armv8.4a will only add 
>>> more options down the line.
>> 
>> Sounds a lot like the above would be TUNE_FEATURES to me..  (even if we don't
>> necessarily define a tune that uses them -- if it's standard another layer
>> certainly could.)
>> 
>>> Regarding fpu, gcc supports the following for armv8: fp-armv8, 
>>> neon-fp-armv8, and crypto-neon-fp-armv8.
>>> 
>>> Regarding cpu, I believe that the armv8 supported ones are: ‘cortex-a32’, 
>>> ‘cortex-a35’, ‘cortex-a53’, ‘cortex-a55’, ‘cortex-a57’, ‘cortex-a72’, 
>>> ‘cortex-a73’, ‘cortex-a75’.
>>> 
>>> I personally would like to keep tuning for a specific CPU as much as 
>>> possible (again I'm working closely with various ARM-based SoCs, so my 
>>> opinion might be tainted).
>> 
>> Thats a lot of options, but if we focus on TUNE_FEATURES, I think it's a bit
>> more reasonable to support all of this.. (maybe that is what needs to be 
>> done in
>> the future as well for other architectures.. focus on the 'gcc' behavior and
>> generate TUNE_FEATURES matching the compiler.)
>> 
>> I'd like Khem's opinion on how crazy of an idea that is.
>> 
>>> One thing that could be done to simplify things would be to just use the 
>>> cpu, and add the options to it. Gcc supports adding options to the cpu.
>>> '+nofp' for ‘cortex-a32’, ‘cortex-a35’, ‘cortex-a53’ and ‘cortex-a55’
>>> '+crypto' for ‘cortex-a32’, ‘cortex-a35’, ‘cortex-a53’, ‘cortex-a55’, 
>>> ‘cortex-a57’, ‘cortex-a72’, ‘cortex-a73’, ‘cortex-a75’
>>> 
>>> That could simplify the tune settings, but would give less control than 
>>> what we currently have.
>>> As you might have guessed, I do put a specific emphasis on the crypto 
>>> option, and on the neon option, which are the most interesting for armv8 in 
>>> my opinion.
>> 
>> In the past 'crypto' options have only been assembly.. if that's changed it 
>> has
>> definitely opened up a new facet in all of this work.
>> 
>>> Regarding thumb, always adding it to the tune without creating specific 
>>> variants with or without thumb makes sense, since the tune is normally 
>>> about the SoC capabilities, and arv7 and armv8 both support it.
>>> You can always select whether you want thumb or not by setting 
>>> ARM_INSTRUCTION_SET appropriately at the distro level.
>> 
>> Yes, that might be needed now that thumb is theoretically always supposed to 
>> be
>> present.
> 
> It's not _always_ present - it's missing for armv4 CPUs such as StrongARM.
> 
> However the option has been unnecessarily propagated into tuning files
> for higher architecture levels where support for Thumb _is_ always
> present.

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2 0/4] Add tune for ARMv8 and some cortex processors

[Herve Jourdain]

Hi,

So I agree with you about restricting to what gcc can support, that's actually 
my proposal (actually, probably a subset of what gcc can support).
So for armv8, gcc supports, as architectures: armv8-a, armv8.1-a, armv8.2-a, 
armv8.3-a, armv8.4-a.
Then, you can add the supported options with a "+" after the architecture.
Options supported for armv8-a are: '+crc', '+simd', '+crypto', '+nocrypto', 
'+nofp'
Options supported for armv8.1-a are: '+simd', '+crypto', '+nocrypto', '+nofp'
Options supported for armv8.2-a and armv8.3-a are: '+fp16', '+fp16fml', 
'+simd', '+crypto', '+dotprod', '+nocrypto', '+nofp'
Options supported for armv8.4-a are: '+fp16', '+simd', '+crypto', '+dotprod', 
'+nocrypto', '+nofp'

As you can see, proposals for armv8-a, whether my previous one, the new one 
here, or even the one I have updated and used in production, just capture the 
existing complexity, and not add to it.
and support for armv8.1-a, armv8.2-a, armv8.3-a, armv8.4a will only add more 
options down the line.

Regarding fpu, gcc supports the following for armv8: fp-armv8, neon-fp-armv8, 
and crypto-neon-fp-armv8.

Regarding cpu, I believe that the armv8 supported ones are: ‘cortex-a32’, 
‘cortex-a35’, ‘cortex-a53’, ‘cortex-a55’, ‘cortex-a57’, ‘cortex-a72’, 
‘cortex-a73’, ‘cortex-a75’.

I personally would like to keep tuning for a specific CPU as much as possible 
(again I'm working closely with various ARM-based SoCs, so my opinion might be 
tainted).

One thing that could be done to simplify things would be to just use the cpu, 
and add the options to it. Gcc supports adding options to the cpu.
'+nofp' for ‘cortex-a32’, ‘cortex-a35’, ‘cortex-a53’ and ‘cortex-a55’
'+crypto' for ‘cortex-a32’, ‘cortex-a35’, ‘cortex-a53’, ‘cortex-a55’, 
‘cortex-a57’, ‘cortex-a72’, ‘cortex-a73’, ‘cortex-a75’

That could simplify the tune settings, but would give less control than what we 
currently have.
As you might have guessed, I do put a specific emphasis on the crypto option, 
and on the neon option, which are the most interesting for armv8 in my opinion.

Regarding thumb, always adding it to the tune without creating specific 
variants with or without thumb makes sense, since the tune is normally about 
the SoC capabilities, and arv7 and armv8 both support it.
You can always select whether you want thumb or not by setting 
ARM_INSTRUCTION_SET appropriately at the distro level.

Cheers,
Herve

-Original Message-
From: Mark Hatle [mailto:mark.ha...@windriver.com] 
Sent: mardi 12 juin 2018 16:32
To: Herve Jourdain ; 'Koen Kooi' 
; 'Randy Li' 
Cc: 'OE-core' 
Subject: Re: [OE-core] [PATCH v2 0/4] Add tune for ARMv8 and some cortex 
processors

On 6/12/18 4:30 AM, Herve Jourdain wrote:
> Hi,
> 
> I believe I'm the "original author" of some patch attempt at tackling this 
> problem, more than a year ago, as referenced in this series.
> And I understand why everyone, Khem being the first and not the only one, 
> would like some "simpler" things for ARM.
> But the problem is that ARM-based SoCs are very diverse, and ARM does have a 
> number of optional IP blocks (such as crypto, but neon is another one, and 
> there are others), defined for each architecture. Then ARM defines some 
> "standard" SoCs (like cortex-A53, cortex-A57, ...) which may set some of 
> those optional IPs as required for that SoC, and the rest still as optional.
> And SoC vendors decide what optional IPs they will implement or not...

Simplification is a goal in this, but as you said, not always reasonable with a 
processor designed to be customized.

Typically true customization (vendor specific) doesn't belong in the oe-core 
tune files, but stuff that is architecturally defined may.

> So when we're talking "cortex-A53", it's not necessarily the same cortex-A53 
> for all SoC vendors.
> 
> GCC does support all that complexity. So the main question is, do we want to 
> be able to generate code that could take advantage of the optional IPs 
> present on a SoC? Or do we prefer to settle for the least common denominator?

I think this is the key.  What combinations does GCC support (actually generate
code for?)   If GCC can't generate code for that combination, then I don't
believe it belongs as a tune in OE-Core, unless there is a compelling argument 
that assembly level functions will be common enough to justify it.

> As someone who is close to the SoC, I definitely would prefer to be able to 
> take advantage of the optional IPs present on an ARM SoC, and I'd rather have 
> a system that can at least support that even if it's slightly more complex. 
> This said, once it's done, most people won't look under the hood but just use 
> it, so the complexity would end up being hidden - much like now with armv7.

And this is why my GCC statement is being made.  Most developers will define a 
tune, but will never go into the assembly realm.  Th

Re: [OE-core] [PATCH v2 0/4] Add tune for ARMv8 and some cortex processors

[Herve Jourdain]

Hi,

I believe I'm the "original author" of some patch attempt at tackling this 
problem, more than a year ago, as referenced in this series.
And I understand why everyone, Khem being the first and not the only one, would 
like some "simpler" things for ARM.
But the problem is that ARM-based SoCs are very diverse, and ARM does have a 
number of optional IP blocks (such as crypto, but neon is another one, and 
there are others), defined for each architecture. Then ARM defines some 
"standard" SoCs (like cortex-A53, cortex-A57, ...) which may set some of those 
optional IPs as required for that SoC, and the rest still as optional.
And SoC vendors decide what optional IPs they will implement or not...

So when we're talking "cortex-A53", it's not necessarily the same cortex-A53 
for all SoC vendors.

GCC does support all that complexity. So the main question is, do we want to be 
able to generate code that could take advantage of the optional IPs present on 
a SoC? Or do we prefer to settle for the least common denominator?
As someone who is close to the SoC, I definitely would prefer to be able to 
take advantage of the optional IPs present on an ARM SoC, and I'd rather have a 
system that can at least support that even if it's slightly more complex. This 
said, once it's done, most people won't look under the hood but just use it, so 
the complexity would end up being hidden - much like now with armv7.

I've personally followed up on my patches from last year, and I now have a 
slightly modified/simplified version of them, which I've used to build some 
production-ready environments using cortex-a53/armv8 tunes, that trigger the 
optimization for cortex-a53 + neon. And if the SoC I'm working with had the 
crypto extension, I would be very happy to build for it, by just switching the 
tune I use for my cortex-a53 to the armv8 tune supporting crypto.

So I believe now may be a good time to talk this over again, because we're 
basically building for cortex-a53 with cortexa7/armv7ve, and that is not the 
most optimal thing to do in my opinion (like, some instructions that were 
native in armv7ve are simulated in armv8).

One thing that I did come up as a simplification was the handling of thumb, I 
don't think it needs to be an option anymore, since its support is mandatory in 
armv8 (but I think it was also the case in armv7). That simplifies things a 
bit, but nothing fundamental, you still need to carry the support for the 
optional IPs around...
And in addition to what I proposed to support last year, we indeed now have to 
add armv8.1a, armv8.2a, armv8.3a, armv8.4a (so far...), which each have their 
own specificities/differences that make it unlikely to be supported within a 
single file.

Thoughts? Can we talk this over, so we can have a chance to have a good support 
for armv8-32 in oe, instead of everyone doing its own?

Cheers,
Herve

-Original Message-
From: openembedded-core-boun...@lists.openembedded.org 
[mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of Koen Kooi
Sent: mardi 12 juin 2018 11:01
To: Randy Li 
Cc: OE-core 
Subject: Re: [OE-core] [PATCH v2 0/4] Add tune for ARMv8 and some cortex 
processors



> Op 9 jun. 2018, om 08:26 heeft Randy Li  het volgende 
> geschreven:
> 
> I read the ARMv8 manual again, it looks the hardware float is 
> mandatory in Linux Distributions and toolchain libraries. Even some 
> cortex processors can be configured without FPU/NEON hardware, but I 
> don't think they would be used in openembeded core.
> 
> So I can assume the NEON(SIMD) would exist all the time. Leaving only 
> the crc and crypto instructions are optional here.
> 
> 
> Randy Li (4):
>  arch-armv8a.inc: add tune include for armv8
>  tune-cortexa35: add tunes for ARM Cortex-A35
>  tune-cortexa32: add tunes for ARM Cortex-A32
>  tune-cortexa72: add tunes for ARM Cortex-A72

Having been forced to deal with the mess that’s 32-bit arm tunes: Let’s only 
add an implementation specific tunes *after* having seem conclusive, repeatable 
benchmark results. 90% of the 32 bit tune files are placebo effect and just 
explode number of package archs in your distro feed. The goal of aarch64 was to 
stop being different for the sake of being different, let’s not make a mess 
because we are used to messes.

regards,

Koen
--
___
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] [smartpm][PATCH 1/1] smartpm: if RPM transaction fails with an empty list of problems in attempt mode, ignore it!

[Herve Jourdain]

 is already
installed
error: package systemd-compat-units-dbg-1.0-r29.cortexa7hf_neon_vfpv4 is
already installed
error: package util-linux-dbg-2.29-r0.cortexa7hf_neon_vfpv4 is already
installed
error: package libfreetype-dbg-2.7-r0.cortexa7hf_neon_vfpv4 is already
installed
error: package libsoup-2.4-dbg-2.56.0-r0.cortexa7hf_neon_vfpv4 is already
installed
error: package libexpat-dbg-2.2.0-r0.cortexa7hf_neon_vfpv4 is already
installed
error: package libgcrypt-dbg-1.7.3-r0.cortexa7hf_neon_vfpv4 is already
installed
error: package libmms-dbg-0.6.4-r0.cortexa7hf_neon_vfpv4 is already
installed
error: package libdrm-dbg-2.4.74-r0.cortexa7hf_neon_vfpv4 is already
installed
error: package base-files-dbg-3.0.14-r89.raspberrypi2 is already installed
error: package libffi-dbg-3.2.1-r0.cortexa7hf_neon_vfpv4 is already
installed
error: package libpng16-dbg-1.6.26-r0.cortexa7hf_neon_vfpv4 is already
installed
error: package libreadline-dbg-7.0-r0.cortexa7hf_neon_vfpv4 is already
installed
error: package libneon-dbg-0.30.2-r0.cortexa7hf_neon_vfpv4 is already
installed
error: package tcf-agent-dbg-1.4.0+git0+25f440-r0.cortexa7hf_neon_vfpv4
is already installed
error: package libwebp-dbg-0.5.1-r0.cortexa7hf_neon_vfpv4 is already
installed
error: package packagegroup-core-eclipse-debug-dbg-1.0-r0.all is already
installed
error: package libsndfile-dbg-1.0.27-r0.cortexa7hf_neon_vfpv4 is already
installed
error: package glib-networking-dbg-2.50.0-r0.cortexa7hf_neon_vfpv4 is
already installed
error: package iptables-dbg-1.6.0-r0.cortexa7hf_neon_vfpv4 is already
installed
error: package file-dbg-5.29-r0.cortexa7hf_neon_vfpv4 is already installed
error: package orc-dbg-0.4.26-r0.cortexa7hf_neon_vfpv4 is already installed
error: package flac-dbg-1.3.1-r0.cortexa7hf_neon_vfpv4 is already installed
error: package ofono-dbg-1.19-r0.cortexa7hf_neon_vfpv4 is already installed
error: package bzip2-dbg-1.0.6-r5.cortexa7hf_neon_vfpv4 is already installed
error: package dbus-dbg-1.10.10-r0.cortexa7hf_neon_vfpv4 is already
installed
error: package python-dbg-2.7.12-r1.cortexa7hf_neon_vfpv4 is already
installed
error: package libcroco-dbg-0.6.11-r0.cortexa7hf_neon_vfpv4 is already
installed
error: package libcairo-dbg-1.14.8-r0.cortexa7hf_neon_vfpv4 is already
installed
error: package kmod-dbg-23+git0+65a885df5f-r0.cortexa7hf_neon_vfpv4 is
already installed
error: package libgudev-1.0-dbg-230-r0.cortexa7hf_neon_vfpv4 is already
installed
error: package libical-dbg-2.0.0-r0.cortexa7hf_neon_vfpv4 is already
installed
error: package nss-dbg-3.27.1-r0.cortexa7hf_neon_vfpv4 is already installed
error: package libunistring-dbg-0.9.7-r0.cortexa7hf_neon_vfpv4 is already
installed
error: package faad2-dbg-2.7-r1.cortexa7hf_neon_vfpv4 is already installed
error: package libjson-c-dbg-0.12-r0.cortexa7hf_neon_vfpv4 is already
installed
error: package run-postinsts-dbg-1.0-r9.all is already installed
error: package libgcc-s-dbg-5.4.0-r0.cortexa7hf_neon_vfpv4 is already
installed
.0-dbg  shadow-securetty-dbg   
  libglib-2.0-dbgsqlite3-dbg

  libgmp-dbg systemd-compat-units-dbg

  libgnutls-dbg  systemd-dbg

  libgpg-error-dbg   systemd-serialgetty-dbg

  libgudev-1.0-dbg   tcf-agent-dbg

  libharfbuzz-dbgupdate-rc.d-dbg

  libical-dbgutil-linux-dbg

  libidn-dbg volatile-binds-dbg

  libjpeg-dbgwayland-dbg

  libjson-c-dbg  wireless-regdb-dbg

  libmms-dbg wpa-supplicant-dbg

  libneon-dbgxz-dbg

  libnl-3-dbg

1874.2MB of package files are needed. 4819.5MB will be used.


Saving cache...

-Original Message-
From: Herve Jourdain [mailto:herve.jourd...@neuf.fr] 
Sent: jeudi 9 juin 2016 09:42
To: openembedded-core@lists.openembedded.org
Cc: Herve Jourdain <herve.jourd...@neuf.fr>
Subject: [OE-core][smartpm][PATCH 1/1] smartpm: if RPM transaction fails
with an empty list of problems in attempt mode, ignore it!

Since commit be0cabf816a84c59e0e951b92a570121ed843822 on 2016/05/17, smartpm
will retry the transaction if ts.run() returns with an empty list of
problems, and we're in attempt mode.
But then, since all the packages are already installed, the transaction will
fail with "package already installed" error.

In attempt mode, it's fine to not retry nor generate an error when the
transaction fails for no reason linked to files/packages conflicts, so this
patch fixes this behaviour.

Signed-off-by: Herve Jourdain <herve.jourd...@neuf.fr>
---
 .../python/python-smartpm/smart-attempt.patch  | 14
+++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-devtools/python/python-smartpm/smart-attempt.patch
b/meta/recipes-devtools

Re: [OE-core] [oe-core][PATCH v3 2/3] arch-armv8.inc: add support for 32bits armv8 options

[Herve Jourdain]

Hi Fathi,

I do agree with both of your statements, which is why I did it that way.
But if some people want less tunes, that's the only way I can think of - 
because crc and crypto are not going away in armv8.
I can re-write the file in a nicer way, but the amount of tunes, if we want to 
give something similar in possibilities for armv8 aarch32 to what we had with 
armv7ve, can hardly be smaller I believe.
So at the end of the day, it's a choice between completeness and convenience, I 
guess.

Herve

-Original Message-
From: Fathi Boudra [mailto:fathi.bou...@linaro.org] 
Sent: lundi 21 novembre 2016 10:15
To: Herve Jourdain <herve.jourd...@neuf.fr>
Cc: Khem Raj <raj.k...@gmail.com>; Patches and discussions about the oe-core 
layer <openembedded-core@lists.openembedded.org>
Subject: Re: [OE-core] [oe-core][PATCH v3 2/3] arch-armv8.inc: add support for 
32bits armv8 options

Hi,

On 21 November 2016 at 07:02, Herve Jourdain <herve.jourd...@neuf.fr> wrote:
> Hi Khem,
>
> It does cover all the possibilities in armv8 (3 possible FPU and 2 possible 
> options - crc and crypto).
> So if we want to be exhaustive, we probably need something similar.
> If we just want to support cortex-a53, then we can trim a bit.
>
> I was not aware of the Axxia work, it could also be used in oe-core instead 
> of my patch, actually.
> But if you check what they did, they do define nearly as many - with the 
> exception of the softfloat option, in their case aarch32 is always hf. That's 
> a possibility that could be considered, but I initially tried to provide as 
> much "features" for aarch32 as there was for armv7ve - including the option 
> to do softfloat...

There is a clear statement that _currently_ there is no soft / softfp ABI for 
AArch64.
For armv8-a compliant hardware it must have NEON.
But, still, one _can_ compile for aarch32-mode on armv8-a in soft or softp 
float-abi, and it will run.
There is no statement that armv8-a can't use soft or soft-fp ABI from armv7-a.

> Please let me know what you'd like me to do, amend my patch to remove 
> softfloat cases, or just get the axxia patches into oe-core, or something 
> else?
>
> Herve
>
> -Original Message-
> From: Khem Raj [mailto:raj.k...@gmail.com]
> Sent: dimanche 20 novembre 2016 20:37
> To: Herve Jourdain <herve.jourd...@neuf.fr>
> Cc: Patches and discussions about the oe-core layer 
> <openembedded-core@lists.openembedded.org>
> Subject: Re: [OE-core] [oe-core][PATCH v3 2/3] arch-armv8.inc: add 
> support for 32bits armv8 options
>
> I dont think we need these many variats for v8, axxia has been carrying such 
> patches locally.
> see
> https://github.com/axxia/meta-axxia/tree/master/conf/machine/include
>
> On Sun, Nov 20, 2016 at 4:10 AM, Herve Jourdain <herve.jourd...@neuf.fr> 
> wrote:
>> Signed-off-by: Herve Jourdain <herve.jourd...@neuf.fr>
>> ---
>>  meta/conf/machine/include/arm/arch-armv8.inc | 60
>> 
>>  1 file changed, 60 insertions(+)
>>
>> diff --git a/meta/conf/machine/include/arm/arch-armv8.inc
>> b/meta/conf/machine/include/arm/arch-armv8.inc
>> index 5e832fa..8c96efc 100644
>> --- a/meta/conf/machine/include/arm/arch-armv8.inc
>> +++ b/meta/conf/machine/include/arm/arch-armv8.inc
>> @@ -1 +1,61 @@
>>  require conf/machine/include/arm/arch-arm64.inc
>> +
>> +TUNEVALID[armv8] = "Enable instructions for ARMv8"
>> +TUNECONFLICTS[armv8] = "armv4 armv5 armv6 armv7 armv7a armv7ve"
>> +
>> +TUNE_CCARGS .= \
>> +"${@' -march=armv8-a+crypto+crc' if
>> +bb.utils.contains('TUNE_FEATURES', [ 'armv8', 'cryptov8', 'crcv8' ], 
>> +True, False, d) else\ ' -march=armv8-a+crypto' if 
>> +bb.utils.contains('TUNE_FEATURES', [ 'armv8', 'cryptov8' ], True, False, d) 
>> else\ ' -march=armv8-a+crc' if bb.utils.contains('TUNE_FEATURES', [ 'armv8', 
>> 'crcv8' ], True, False, d) else \ bb.utils.contains('TUNE_FEATURES', 
>> 'armv8', ' -march=armv8-a', '', d)}"
>> +
>> +TUNE_CCARGS_MFPU .= \
>> +"${@' crypto-neon-fp-armv8' if bb.utils.contains('TUNE_FEATURES', [ 
>> +'armv8', 'neon', 'cryptov8' ], True, False, d) else \ '
>> +neon-fp-armv8' if bb.utils.contains('TUNE_FEATURES', [ 'armv8', 'neon' ], 
>> True, False, d) else \ bb.utils.contains('TUNE_FEATURES', [ 'armv8' ], ' 
>> fp-armv8', '', d)}"
>> +
>> +MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'armv8', 
>> 'armv8:', '' ,d)}"
>> +
>> +AVAILTUNES += "armv8 armv8-crypto armv8-crc armv8-crypto-crc"
>> +TUNE_FEATURES_tune-armv8 = "armv8"
>> +TUNE_FEATURES_tune-armv8-crypto = "${T

Re: [OE-core] [oe-core][PATCH v3 1/3] arch-arm64.inc: include arch-armv7ve instead of arch-armv7a

[Herve Jourdain]

Hi Khem,

Do you want me to resubmit the patch with a better commit message?
Or do you want to submit yours instead?
I'm fine either way.

Herve

-Original Message-
From: Khem Raj [mailto:raj.k...@gmail.com] 
Sent: dimanche 20 novembre 2016 20:35
To: Herve Jourdain <herve.jourd...@neuf.fr>
Cc: Patches and discussions about the oe-core layer 
<openembedded-core@lists.openembedded.org>
Subject: Re: [OE-core] [oe-core][PATCH v3 1/3] arch-arm64.inc: include 
arch-armv7ve instead of arch-armv7a

On Sun, Nov 20, 2016 at 4:10 AM, Herve Jourdain <herve.jourd...@neuf.fr> wrote:
> Signed-off-by: Herve Jourdain <herve.jourd...@neuf.fr>
> ---
>  meta/conf/machine/include/arm/arch-arm64.inc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/conf/machine/include/arm/arch-arm64.inc 
> b/meta/conf/machine/include/arm/arch-arm64.inc
> index 9440698..9eeffac 100644
> --- a/meta/conf/machine/include/arm/arch-arm64.inc
> +++ b/meta/conf/machine/include/arm/arch-arm64.inc
> @@ -1,6 +1,6 @@
>  DEFAULTTUNE ?= "aarch64"
>
> -require conf/machine/include/arm/arch-armv7a.inc
> +require conf/machine/include/arm/arch-armv7ve.inc

This is ok. However a better commit message would be justified.
I have similar patch see

https://github.com/kraj/openembedded-core/commit/8ece89ac164062601d3418576d51434c69654e28

>
>  TUNEVALID[aarch64] = "Enable instructions for aarch64"
>
> --
> 2.7.4
>
> --
> ___
> 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] [oe-core][PATCH v3 2/3] arch-armv8.inc: add support for 32bits armv8 options

[Herve Jourdain]

Hi Khem,

It does cover all the possibilities in armv8 (3 possible FPU and 2 possible 
options - crc and crypto).
So if we want to be exhaustive, we probably need something similar.
If we just want to support cortex-a53, then we can trim a bit.

I was not aware of the Axxia work, it could also be used in oe-core instead of 
my patch, actually.
But if you check what they did, they do define nearly as many - with the 
exception of the softfloat option, in their case aarch32 is always hf. That's a 
possibility that could be considered, but I initially tried to provide as much 
"features" for aarch32 as there was for armv7ve - including the option to do 
softfloat...

Please let me know what you'd like me to do, amend my patch to remove softfloat 
cases, or just get the axxia patches into oe-core, or something else?

Herve

-Original Message-
From: Khem Raj [mailto:raj.k...@gmail.com] 
Sent: dimanche 20 novembre 2016 20:37
To: Herve Jourdain <herve.jourd...@neuf.fr>
Cc: Patches and discussions about the oe-core layer 
<openembedded-core@lists.openembedded.org>
Subject: Re: [OE-core] [oe-core][PATCH v3 2/3] arch-armv8.inc: add support for 
32bits armv8 options

I dont think we need these many variats for v8, axxia has been carrying such 
patches locally.
see
https://github.com/axxia/meta-axxia/tree/master/conf/machine/include

On Sun, Nov 20, 2016 at 4:10 AM, Herve Jourdain <herve.jourd...@neuf.fr> wrote:
> Signed-off-by: Herve Jourdain <herve.jourd...@neuf.fr>
> ---
>  meta/conf/machine/include/arm/arch-armv8.inc | 60 
> 
>  1 file changed, 60 insertions(+)
>
> diff --git a/meta/conf/machine/include/arm/arch-armv8.inc 
> b/meta/conf/machine/include/arm/arch-armv8.inc
> index 5e832fa..8c96efc 100644
> --- a/meta/conf/machine/include/arm/arch-armv8.inc
> +++ b/meta/conf/machine/include/arm/arch-armv8.inc
> @@ -1 +1,61 @@
>  require conf/machine/include/arm/arch-arm64.inc
> +
> +TUNEVALID[armv8] = "Enable instructions for ARMv8"
> +TUNECONFLICTS[armv8] = "armv4 armv5 armv6 armv7 armv7a armv7ve"
> +
> +TUNE_CCARGS .= \
> +"${@' -march=armv8-a+crypto+crc' if 
> +bb.utils.contains('TUNE_FEATURES', [ 'armv8', 'cryptov8', 'crcv8' ], 
> +True, False, d) else\ ' -march=armv8-a+crypto' if 
> +bb.utils.contains('TUNE_FEATURES', [ 'armv8', 'cryptov8' ], True, False, d) 
> else\ ' -march=armv8-a+crc' if bb.utils.contains('TUNE_FEATURES', [ 'armv8', 
> 'crcv8' ], True, False, d) else \ bb.utils.contains('TUNE_FEATURES', 'armv8', 
> ' -march=armv8-a', '', d)}"
> +
> +TUNE_CCARGS_MFPU .= \
> +"${@' crypto-neon-fp-armv8' if bb.utils.contains('TUNE_FEATURES', [ 
> +'armv8', 'neon', 'cryptov8' ], True, False, d) else \ ' 
> +neon-fp-armv8' if bb.utils.contains('TUNE_FEATURES', [ 'armv8', 'neon' ], 
> True, False, d) else \ bb.utils.contains('TUNE_FEATURES', [ 'armv8' ], ' 
> fp-armv8', '', d)}"
> +
> +MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'armv8', 
> 'armv8:', '' ,d)}"
> +
> +AVAILTUNES += "armv8 armv8-crypto armv8-crc armv8-crypto-crc"
> +TUNE_FEATURES_tune-armv8 = "armv8"
> +TUNE_FEATURES_tune-armv8-crypto = "${TUNE_FEATURES_tune-armv8} cryptov8"
> +TUNE_FEATURES_tune-armv8-crc = "${TUNE_FEATURES_tune-armv8} crcv8"
> +TUNE_FEATURES_tune-armv8-crypto-crc = "${TUNE_FEATURES_tune-armv8} cryptov8 
> crcv8"
> +PACKAGE_EXTRA_ARCHS_tune-armv8 = "armv8"
> +PACKAGE_EXTRA_ARCHS_tune-armv8-crypto = "${PACKAGE_EXTRA_ARCHS_tune-armv8} 
> armv8-crypto"
> +PACKAGE_EXTRA_ARCHS_tune-armv8-crc = "${PACKAGE_EXTRA_ARCHS_tune-armv8} 
> armv8-crc"
> +PACKAGE_EXTRA_ARCHS_tune-armv8-crypto-crc = 
> "${PACKAGE_EXTRA_ARCHS_tune-armv8} armv8-crypto-crc"
> +
> +AVAILTUNES += "armv8-neon armv8-neon-crypto armv8-neon-crc 
> armv8-neon-crypto-crc"
> +TUNE_FEATURES_tune-armv8-neon = "${TUNE_FEATURES_tune-armv8} neon"
> +TUNE_FEATURES_tune-armv8-neon-crypto = "${TUNE_FEATURES_tune-armv8-crypto} 
> neon"
> +TUNE_FEATURES_tune-armv8-neon-crc = "${TUNE_FEATURES_tune-armv8-crc} neon"
> +TUNE_FEATURES_tune-armv8-neon-crypto-crc = 
> "${TUNE_FEATURES_tune-armv8-crypto-crc} neon"
> +PACKAGE_EXTRA_ARCHS_tune-armv8-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv8} 
> armv8-neon"
> +PACKAGE_EXTRA_ARCHS_tune-armv8-neon-crypto = 
> "${PACKAGE_EXTRA_ARCHS_tune-armv8-crypto} armv8-neon-crypto"
> +PACKAGE_EXTRA_ARCHS_tune-armv8-neon-crc = 
> "${PACKAGE_EXTRA_ARCHS_tune-armv8-crc} armv8-neon-crc"
> +PACKAGE_EXTRA_ARCHS_tune-armv8-neon-crypto-crc = 
> "${PACKAGE_EXTRA_ARCHS_tune-armv8-crypto-crc} armv8-neon-crypto-crc"
> +
> +AVAILTUNES += "armv8hf armv

[OE-core] [oe-core][PATCH v3 0/3] Add a tune file for cortexa53, valid for 32 bits and 64 bits

[Herve Jourdain]

Add a tune file for cortexa53, valid for 32 bits and 64 bits
It requires adding options in arch-armv8.inc to support 32 bits options

Herve Jourdain (3):
  arch-arm64.inc: include arch-armv7ve instead of arch-armv7a
  arch-armv8.inc: add support for 32bits armv8 options
  Add a tune file for cortexa53, valid for 32 bits and 64 bits

 meta/conf/machine/include/arm/arch-arm64.inc |  2 +-
 meta/conf/machine/include/arm/arch-armv8.inc | 60 
 meta/conf/machine/include/tune-cortexa53.inc | 43 
 3 files changed, 104 insertions(+), 1 deletion(-)
 create mode 100644 meta/conf/machine/include/tune-cortexa53.inc

-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [oe-core][PATCH v3 1/3] arch-arm64.inc: include arch-armv7ve instead of arch-armv7a

[Herve Jourdain]

Signed-off-by: Herve Jourdain <herve.jourd...@neuf.fr>
---
 meta/conf/machine/include/arm/arch-arm64.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/conf/machine/include/arm/arch-arm64.inc 
b/meta/conf/machine/include/arm/arch-arm64.inc
index 9440698..9eeffac 100644
--- a/meta/conf/machine/include/arm/arch-arm64.inc
+++ b/meta/conf/machine/include/arm/arch-arm64.inc
@@ -1,6 +1,6 @@
 DEFAULTTUNE ?= "aarch64"
 
-require conf/machine/include/arm/arch-armv7a.inc
+require conf/machine/include/arm/arch-armv7ve.inc
 
 TUNEVALID[aarch64] = "Enable instructions for aarch64"
 
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [oe-core][PATCH v3 2/3] arch-armv8.inc: add support for 32bits armv8 options

[Herve Jourdain]

Signed-off-by: Herve Jourdain <herve.jourd...@neuf.fr>
---
 meta/conf/machine/include/arm/arch-armv8.inc | 60 
 1 file changed, 60 insertions(+)

diff --git a/meta/conf/machine/include/arm/arch-armv8.inc 
b/meta/conf/machine/include/arm/arch-armv8.inc
index 5e832fa..8c96efc 100644
--- a/meta/conf/machine/include/arm/arch-armv8.inc
+++ b/meta/conf/machine/include/arm/arch-armv8.inc
@@ -1 +1,61 @@
 require conf/machine/include/arm/arch-arm64.inc
+
+TUNEVALID[armv8] = "Enable instructions for ARMv8"
+TUNECONFLICTS[armv8] = "armv4 armv5 armv6 armv7 armv7a armv7ve"
+
+TUNE_CCARGS .= \
+"${@' -march=armv8-a+crypto+crc' if bb.utils.contains('TUNE_FEATURES', [ 
'armv8', 'cryptov8', 'crcv8' ], True, False, d) else\
+' -march=armv8-a+crypto' if bb.utils.contains('TUNE_FEATURES', [ 'armv8', 
'cryptov8' ], True, False, d) else\
+' -march=armv8-a+crc' if bb.utils.contains('TUNE_FEATURES', [ 'armv8', 'crcv8' 
], True, False, d) else \
+bb.utils.contains('TUNE_FEATURES', 'armv8', ' -march=armv8-a', '', d)}"
+
+TUNE_CCARGS_MFPU .= \
+"${@' crypto-neon-fp-armv8' if bb.utils.contains('TUNE_FEATURES', [ 'armv8', 
'neon', 'cryptov8' ], True, False, d) else \
+' neon-fp-armv8' if bb.utils.contains('TUNE_FEATURES', [ 'armv8', 'neon' ], 
True, False, d) else \
+bb.utils.contains('TUNE_FEATURES', [ 'armv8' ], ' fp-armv8', '', d)}"
+
+MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'armv8', 'armv8:', 
'' ,d)}"
+
+AVAILTUNES += "armv8 armv8-crypto armv8-crc armv8-crypto-crc"
+TUNE_FEATURES_tune-armv8 = "armv8"
+TUNE_FEATURES_tune-armv8-crypto = "${TUNE_FEATURES_tune-armv8} cryptov8"
+TUNE_FEATURES_tune-armv8-crc = "${TUNE_FEATURES_tune-armv8} crcv8"
+TUNE_FEATURES_tune-armv8-crypto-crc = "${TUNE_FEATURES_tune-armv8} cryptov8 
crcv8"
+PACKAGE_EXTRA_ARCHS_tune-armv8 = "armv8"
+PACKAGE_EXTRA_ARCHS_tune-armv8-crypto = "${PACKAGE_EXTRA_ARCHS_tune-armv8} 
armv8-crypto"
+PACKAGE_EXTRA_ARCHS_tune-armv8-crc = "${PACKAGE_EXTRA_ARCHS_tune-armv8} 
armv8-crc"
+PACKAGE_EXTRA_ARCHS_tune-armv8-crypto-crc = "${PACKAGE_EXTRA_ARCHS_tune-armv8} 
armv8-crypto-crc"
+
+AVAILTUNES += "armv8-neon armv8-neon-crypto armv8-neon-crc 
armv8-neon-crypto-crc"
+TUNE_FEATURES_tune-armv8-neon = "${TUNE_FEATURES_tune-armv8} neon"
+TUNE_FEATURES_tune-armv8-neon-crypto = "${TUNE_FEATURES_tune-armv8-crypto} 
neon"
+TUNE_FEATURES_tune-armv8-neon-crc = "${TUNE_FEATURES_tune-armv8-crc} neon"
+TUNE_FEATURES_tune-armv8-neon-crypto-crc = 
"${TUNE_FEATURES_tune-armv8-crypto-crc} neon"
+PACKAGE_EXTRA_ARCHS_tune-armv8-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv8} 
armv8-neon"
+PACKAGE_EXTRA_ARCHS_tune-armv8-neon-crypto = 
"${PACKAGE_EXTRA_ARCHS_tune-armv8-crypto} armv8-neon-crypto"
+PACKAGE_EXTRA_ARCHS_tune-armv8-neon-crc = 
"${PACKAGE_EXTRA_ARCHS_tune-armv8-crc} armv8-neon-crc"
+PACKAGE_EXTRA_ARCHS_tune-armv8-neon-crypto-crc = 
"${PACKAGE_EXTRA_ARCHS_tune-armv8-crypto-crc} armv8-neon-crypto-crc"
+
+AVAILTUNES += "armv8hf armv8hf-crypto armv8hf-crc armv8hf-crypto-crc"
+TUNE_FEATURES_tune-armv8hf = "${TUNE_FEATURES_tune-armv8} callconvention-hard"
+TUNE_FEATURES_tune-armv8hf-crypto = "${TUNE_FEATURES_tune-armv8-crypto} 
callconvention-hard"
+TUNE_FEATURES_tune-armv8hf-crc = "${TUNE_FEATURES_tune-armv8-crc} 
callconvention-hard"
+TUNE_FEATURES_tune-armv8hf-crypto-crc = 
"${TUNE_FEATURES_tune-armv8-crypto-crc} callconvention-hard"
+PACKAGE_EXTRA_ARCHS_tune-armv8hf = "armv8hf"
+PACKAGE_EXTRA_ARCHS_tune-armv8hf-crypto = "${PACKAGE_EXTRA_ARCHS_tune-armv8hf} 
armv8hf-crypto"
+PACKAGE_EXTRA_ARCHS_tune-armv8hf-crc = "${PACKAGE_EXTRA_ARCHS_tune-armv8hf} 
armv8hf-crc"
+PACKAGE_EXTRA_ARCHS_tune-armv8hf-crypto-crc = 
"${PACKAGE_EXTRA_ARCHS_tune-armv8hf} armv8hf-crypto-crc"
+
+AVAILTUNES += "armv8hf-neon armv8hf-neon-crypto armv8hf-neon-crc 
armv8hf-neon-crypto-crc"
+TUNE_FEATURES_tune-armv8hf-neon = "${TUNE_FEATURES_tune-armv8hf} neon"
+TUNE_FEATURES_tune-armv8hf-neon-crypto = "${TUNE_FEATURES_tune-armv8hf-crypto} 
neon"
+TUNE_FEATURES_tune-armv8hf-neon-crc = "${TUNE_FEATURES_tune-armv8hf-crc} neon"
+TUNE_FEATURES_tune-armv8hf-neon-crypto-crc = 
"${TUNE_FEATURES_tune-armv8hf-crypto-crc} neon"
+PACKAGE_EXTRA_ARCHS_tune-armv8hf-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv8hf} 
armv8hf-neon"
+PACKAGE_EXTRA_ARCHS_tune-armv8hf-neon-crypto = 
"${PACKAGE_EXTRA_ARCHS_tune-armv8hf-crypto} armv8hf-neon-crypto"
+PACKAGE_EXTRA_ARCHS_tune-armv8hf-neon-crc = 
"${PACKAGE_EXTRA_ARCHS_tune-armv8hf-crc} armv8hf-neon-crc"
+PACKAGE_EXTRA_ARCHS_tune-armv8hf-neon-crypto-crc = 
"${PACKAGE_EXTRA_ARCHS_tune-armv8hf-crypto-crc} armv8hf-neon-crypto-crc"
+
+TUNEVALID[cryptov8] = "Enable armv8 crypto extensions"
+TUNEVALID[crcv8] = "Enable armv8 crc extensions"
+
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [oe-core][PATCH v3 3/3] Add a tune file for cortexa53, valid for 32 bits and 64 bits

[Herve Jourdain]

Signed-off-by: Herve Jourdain <herve.jourd...@neuf.fr>
---
 meta/conf/machine/include/tune-cortexa53.inc | 43 
 1 file changed, 43 insertions(+)
 create mode 100644 meta/conf/machine/include/tune-cortexa53.inc

diff --git a/meta/conf/machine/include/tune-cortexa53.inc 
b/meta/conf/machine/include/tune-cortexa53.inc
new file mode 100644
index 000..1d2947f
--- /dev/null
+++ b/meta/conf/machine/include/tune-cortexa53.inc
@@ -0,0 +1,43 @@
+DEFAULTTUNE ?= "cortexa53-32"
+
+require conf/machine/include/arm/arch-armv8.inc
+
+TUNEVALID[cortexa53] = "Enable Cortex-A53 specific processor optimizations"
+TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa53', ' 
-mcpu=cortex-a53 ', '',d)}"
+
+# Extra tune selections
+AVAILTUNES += "cortexa53-32"
+ARMPKGARCH_tune-cortexa53-32 ?= "cortexa53"
+TUNE_FEATURES_tune-cortexa53-32 = "${TUNE_FEATURES_tune-armv8-neon-crc} 
cortexa53"
+BASE_LIB_tune-cortexa53-32 = "lib"
+TUNE_PKGARCH_tune-cortexa53-32 = "cortexa53-32"
+PACKAGE_EXTRA_ARCHS_tune-cortexa53-32 = 
"${PACKAGE_EXTRA_ARCHS_tune-armv8-neon-crc} cortexa53-32 
cortexa53-neon-fp-armv8"
+
+AVAILTUNES += "cortexa53crypto-32"
+ARMPKGARCH_tune-cortexa53crypto-32 ?= "cortexa53"
+TUNE_FEATURES_tune-cortexa53crypto-32 = 
"${TUNE_FEATURES_tune-armv8-neon-crypto-crc} cortexa53"
+BASE_LIB_tune-cortexa53crypto-32 = "lib"
+TUNE_PKGARCH_tune-cortexa53crypto-32 = "cortexa53crypto-32"
+PACKAGE_EXTRA_ARCHS_tune-cortexa53crypto-32 = 
"${PACKAGE_EXTRA_ARCHS_tune-armv8-neon-crypto-crc} cortexa53-32 
cortexa53-crypto-neon-fp-armv8"
+
+AVAILTUNES += "cortexa53hf-32"
+ARMPKGARCH_tune-cortexa53hf-32 ?= "cortexa53"
+TUNE_FEATURES_tune-cortexa53hf-32 = "${TUNE_FEATURES_tune-armv8hf-neon-crc} 
cortexa53"
+BASE_LIB_tune-cortexa53hf-32 = "lib"
+TUNE_PKGARCH_tune-cortexa53hf-32 = "cortexa53hf-32"
+PACKAGE_EXTRA_ARCHS_tune-cortexa53hf-32 = 
"${PACKAGE_EXTRA_ARCHS_tune-armv8hf-neon-crc} cortexa53hf-32 
cortexa53hf-neon-fp-armv8"
+
+AVAILTUNES += "cortexa53hfcrypto-32"
+ARMPKGARCH_tune-cortexa53hfcrypto-32 ?= "cortexa53"
+TUNE_FEATURES_tune-cortexa53hfcrypto-32 = 
"${TUNE_FEATURES_tune-armv8hf-neon-crypto-crc} cortexa53"
+BASE_LIB_tune-cortexa53hfcrypto-32 = "lib"
+TUNE_PKGARCH_tune-cortexa53hfcrypto-32 = "cortexa53hfcrypto-32"
+PACKAGE_EXTRA_ARCHS_tune-cortexa53hfcrypto-32 = 
"${PACKAGE_EXTRA_ARCHS_tune-armv8hf-neon-crypto-crc} cortexa53hf-32 
cortexa53hf-crypto-neon-fp-armv8"
+
+AVAILTUNES += "cortexa53-64"
+ARMPKGARCH_tune-cortexa53-64 ?= "cortexa53"
+TUNE_FEATURES_tune-cortexa53-64 = "${TUNE_FEATURES_tune-aarch64} cortexa53"
+BASE_LIB_tune-cortexa53-64 = "lib64"
+TUNE_PKGARCH_tune-cortexa53-64 = "cortexa53-64"
+PACKAGE_EXTRA_ARCHS_tune-cortexa53-64 = "${PACKAGE_EXTRA_ARCHS_tune-aarch64} 
cortexa53-64"
+
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe-core][PATCH v2 0/1] Add a tune file for cortexa53, valid for 32 bits and 64 bits

[Herve Jourdain]

Please disregard this patch, it's not working fine for 32bits (cortex-a53
must have armv8+crc as arch), v3 coming soon.

Sorry for that.

Herve

-Original Message-
From: Herve Jourdain [mailto:herve.jourd...@neuf.fr] 
Sent: samedi 19 novembre 2016 13:51
To: openembedded-core@lists.openembedded.org
Cc: Herve Jourdain <herve.jourd...@neuf.fr>
Subject: [oe-core][PATCH v2 0/1] Add a tune file for cortexa53, valid for 32
bits and 64 bits

Tune file for ARM Cortex-A53, supporting 32 bits and 64 bits configuration

Herve Jourdain (1):
  Add a tune file for cortexa53, valid for 32 bits and 64 bits

 meta/conf/machine/include/tune-cortexa53.inc | 22 ++
 1 file changed, 22 insertions(+)
 create mode 100644 meta/conf/machine/include/tune-cortexa53.inc

-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe-core][PATCH v2 1/1] Add a tune file for cortexa53, valid for 32 bits and 64 bits

[Herve Jourdain]

Hi Khem,

Unfortunately, it has a few issues in 32bits mode...
Basically, cortex-a53 is an armv8+crc...
I'm sending an updated version - v3 - soon.
But I'll run the tune checker first. At least, the new version I'm coming up 
with and plan to send soon seems to work fine now with 32bits - and I shouldn't 
have broken the 64bits support in the process, but I will also compile it.

Herve

-Original Message-
From: Khem Raj [mailto:raj.k...@gmail.com] 
Sent: samedi 19 novembre 2016 18:51
To: Herve Jourdain <herve.jourd...@neuf.fr>
Cc: Patches and discussions about the oe-core layer 
<openembedded-core@lists.openembedded.org>
Subject: Re: [OE-core] [oe-core][PATCH v2 1/1] Add a tune file for cortexa53, 
valid for 32 bits and 64 bits

This seems fine to me. There is a tune checker that Martin has, it would be 
good to run that and see if this new tune is tested.

http://git.openembedded.org/openembedded-core-contrib/log/?h=jansa/tune2-test


On Sat, Nov 19, 2016 at 4:50 AM, Herve Jourdain <herve.jourd...@neuf.fr> wrote:
> Signed-off-by: Herve Jourdain <herve.jourd...@neuf.fr>
> ---
>  meta/conf/machine/include/tune-cortexa53.inc | 22 
> ++
>  1 file changed, 22 insertions(+)
>  create mode 100644 meta/conf/machine/include/tune-cortexa53.inc
>
> diff --git a/meta/conf/machine/include/tune-cortexa53.inc 
> b/meta/conf/machine/include/tune-cortexa53.inc
> new file mode 100644
> index 000..ff5edb6
> --- /dev/null
> +++ b/meta/conf/machine/include/tune-cortexa53.inc
> @@ -0,0 +1,22 @@
> +DEFAULTTUNE ?= "cortexa53-32"
> +
> +require conf/machine/include/arm/arch-armv8.inc
> +
> +TUNEVALID[cortexa53] = "Enable Cortex-A53 specific processor optimizations"
> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa53', ' 
> -mcpu=cortex-a53 ', '',d)}"
> +
> +# Extra tune selections
> +AVAILTUNES += "cortexa53-32"
> +ARMPKGARCH_tune-cortexa53-32 ?= "cortexa53"
> +TUNE_FEATURES_tune-cortexa53-32 = "${TUNE_FEATURES_tune-armv7ve-neon-vfpv4} 
> cortexa53"
> +BASE_LIB_tune-cortexa53-32 = "lib"
> +TUNE_PKGARCH_tune-cortexa53-32 = "cortexa53-32"
> +PACKAGE_EXTRA_ARCHS_tune-cortexa53-32 = 
> "${PACKAGE_EXTRA_ARCHS_tune-armv7ve-neon-vfpv4} cortexa53-32 
> cortexa53-neon-vfpv4"
> +
> +AVAILTUNES += "cortexa53-64"
> +ARMPKGARCH_tune-cortexa53-64 ?= "cortexa53"
> +TUNE_FEATURES_tune-cortexa53-64 = "${TUNE_FEATURES_tune-aarch64} cortexa53"
> +BASE_LIB_tune-cortexa53-64 = "lib64"
> +TUNE_PKGARCH_tune-cortexa53-64 = "cortexa53-64"
> +PACKAGE_EXTRA_ARCHS_tune-cortexa53-64 = "${PACKAGE_EXTRA_ARCHS_tune-aarch64} 
> cortexa53-64"
> +
> --
> 2.7.4
>
> --
> ___
> 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] [oe-core][PATCH v2 0/1] Add a tune file for cortexa53, valid for 32 bits and 64 bits

[Herve Jourdain]

Tune file for ARM Cortex-A53, supporting 32 bits and 64 bits configuration

Herve Jourdain (1):
  Add a tune file for cortexa53, valid for 32 bits and 64 bits

 meta/conf/machine/include/tune-cortexa53.inc | 22 ++
 1 file changed, 22 insertions(+)
 create mode 100644 meta/conf/machine/include/tune-cortexa53.inc

-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [oe-core][PATCH v2 1/1] Add a tune file for cortexa53, valid for 32 bits and 64 bits

[Herve Jourdain]

Signed-off-by: Herve Jourdain <herve.jourd...@neuf.fr>
---
 meta/conf/machine/include/tune-cortexa53.inc | 22 ++
 1 file changed, 22 insertions(+)
 create mode 100644 meta/conf/machine/include/tune-cortexa53.inc

diff --git a/meta/conf/machine/include/tune-cortexa53.inc 
b/meta/conf/machine/include/tune-cortexa53.inc
new file mode 100644
index 000..ff5edb6
--- /dev/null
+++ b/meta/conf/machine/include/tune-cortexa53.inc
@@ -0,0 +1,22 @@
+DEFAULTTUNE ?= "cortexa53-32"
+
+require conf/machine/include/arm/arch-armv8.inc
+
+TUNEVALID[cortexa53] = "Enable Cortex-A53 specific processor optimizations"
+TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa53', ' 
-mcpu=cortex-a53 ', '',d)}"
+
+# Extra tune selections
+AVAILTUNES += "cortexa53-32"
+ARMPKGARCH_tune-cortexa53-32 ?= "cortexa53"
+TUNE_FEATURES_tune-cortexa53-32 = "${TUNE_FEATURES_tune-armv7ve-neon-vfpv4} 
cortexa53"
+BASE_LIB_tune-cortexa53-32 = "lib"
+TUNE_PKGARCH_tune-cortexa53-32 = "cortexa53-32"
+PACKAGE_EXTRA_ARCHS_tune-cortexa53-32 = 
"${PACKAGE_EXTRA_ARCHS_tune-armv7ve-neon-vfpv4} cortexa53-32 
cortexa53-neon-vfpv4"
+
+AVAILTUNES += "cortexa53-64"
+ARMPKGARCH_tune-cortexa53-64 ?= "cortexa53"
+TUNE_FEATURES_tune-cortexa53-64 = "${TUNE_FEATURES_tune-aarch64} cortexa53"
+BASE_LIB_tune-cortexa53-64 = "lib64"
+TUNE_PKGARCH_tune-cortexa53-64 = "cortexa53-64"
+PACKAGE_EXTRA_ARCHS_tune-cortexa53-64 = "${PACKAGE_EXTRA_ARCHS_tune-aarch64} 
cortexa53-64"
+
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe-core][PATCH 0/1] Add a tune file for cortexa53, valid for 32 bits and 64 bits

[Herve Jourdain]

Please disregard this patch, v2 coming...

-Original Message-
From: Herve Jourdain [mailto:herve.jourd...@neuf.fr] 
Sent: samedi 19 novembre 2016 11:51
To: openembedded-core@lists.openembedded.org
Cc: Herve Jourdain <herve.jourd...@neuf.fr>
Subject: [oe-core][PATCH 0/1] Add a tune file for cortexa53, valid for 32
bits and 64 bits

Tune file for ARM Cortex-A53, supporting 32 bits and 64 bits configuration

Herve Jourdain (1):
  Add a tune file for cortexa53, valid for 32 bits and 64 bits

 meta/conf/machine/include/tune-cortexa53.inc | 22 ++
 1 file changed, 22 insertions(+)
 create mode 100644 meta/conf/machine/include/tune-cortexa53.inc

-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [oe-core][PATCH 1/1] Add a tune file for cortexa53, valid for 32 bits and 64 bits

[Herve Jourdain]

Signed-off-by: Herve Jourdain <herve.jourd...@neuf.fr>
---
 meta/conf/machine/include/tune-cortexa53.inc | 22 ++
 1 file changed, 22 insertions(+)
 create mode 100644 meta/conf/machine/include/tune-cortexa53.inc

diff --git a/meta/conf/machine/include/tune-cortexa53.inc 
b/meta/conf/machine/include/tune-cortexa53.inc
new file mode 100644
index 000..d2e2d53
--- /dev/null
+++ b/meta/conf/machine/include/tune-cortexa53.inc
@@ -0,0 +1,22 @@
+DEFAULTTUNE ?= "cortexa53-32"
+
+require conf/machine/include/arm/arch-armv8.inc
+
+TUNEVALID[cortexa53] = "Enable Cortex-A53 specific processor optimizations"
+TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa53', ' 
-mcpu=cortex-a53 ', '',d)}"
+
+# Extra tune selections
+AVAILTUNES += "cortexa53-32"
+ARMPKGARCH_tune-cortexa53-32 ?= "cortexa53"
+TUNE_FEATURES_tune-cortexa53-32 = "${TUNE_FEATURES_tune-armv7ve-neon-vfpv4} 
cortexa53"
+BASE_LIB_tune-cortexa53-32 = "lib"
+TUNE_PKGARCH_tune-cortexa53-32 = "cortexa53-32"
+PACKAGE_EXTRA_ARCHS_tune-cortexa53-32 = 
"${PACKAGE_EXTRA_ARCHS_tune-armv7ve-neon-vfpv4} cortexa53-32"
+
+AVAILTUNES += "cortexa53-64"
+ARMPKGARCH_tune-cortexa53-64 ?= "cortexa53"
+TUNE_FEATURES_tune-cortexa53-64 = "${TUNE_FEATURES_tune-aarch64} cortexa53"
+BASE_LIB_tune-cortexa53-64 = "lib64"
+TUNE_PKGARCH_tune-cortexa53-64 = "cortexa53-64"
+PACKAGE_EXTRA_ARCHS_tune-cortexa53-64 = "${PACKAGE_EXTRA_ARCHS_tune-aarch64} 
cortexa53-64"
+
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [oe-core][PATCH 0/1] Add a tune file for cortexa53, valid for 32 bits and 64 bits

[Herve Jourdain]

Tune file for ARM Cortex-A53, supporting 32 bits and 64 bits configuration

Herve Jourdain (1):
  Add a tune file for cortexa53, valid for 32 bits and 64 bits

 meta/conf/machine/include/tune-cortexa53.inc | 22 ++
 1 file changed, 22 insertions(+)
 create mode 100644 meta/conf/machine/include/tune-cortexa53.inc

-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v3] linux-dtb.inc: Support for .dtbo files for dtb overlays

[Herve Jourdain]

Ping...
This is needed for support of "dynamic" device tree overlays, with
extensions .dtbo (instead of xxx-overlay.dtb), which are used in RaspberryPi
kernel since 4.4.6.

-Original Message-----
From: Herve Jourdain [mailto:herve.jourd...@neuf.fr] 
Sent: mardi 31 mai 2016 09:55
To: openembedded-core@lists.openembedded.org
Cc: Herve Jourdain <herve.jourd...@neuf.fr>
Subject: [OE-core][PATCH v3] linux-dtb.inc: Support for .dtbo files for dtb
overlays

Signed-off-by: Herve Jourdain <herve.jourd...@neuf.fr>
---
 meta/recipes-kernel/linux/linux-dtb.inc | 18 +++---
 1 file changed, 11 insertions(+), 7 deletions(-)

diff --git a/meta/recipes-kernel/linux/linux-dtb.inc
b/meta/recipes-kernel/linux/linux-dtb.inc
index 74f5ef8..8528d64 100644
--- a/meta/recipes-kernel/linux/linux-dtb.inc
+++ b/meta/recipes-kernel/linux/linux-dtb.inc
@@ -33,12 +33,13 @@ do_compile_append() {
 do_install_append() {
for DTB in ${KERNEL_DEVICETREE}; do
DTB=`normalize_dtb "${DTB}"`
-   DTB_BASE_NAME=`basename ${DTB} .dtb`
+   DTB_EXT=${DTB##*.}
+   DTB_BASE_NAME=`basename ${DTB} ."${DTB_EXT}"`
for type in ${KERNEL_IMAGETYPE_FOR_MAKE}; do
symlink_name=${type}"-"${KERNEL_IMAGE_SYMLINK_NAME}
DTB_SYMLINK_NAME=`echo ${symlink_name} | sed
"s/${MACHINE}/${DTB_BASE_NAME}/g"`
DTB_PATH=`get_real_dtb_path_in_kernel "${DTB}"`
-   install -m 0644 ${DTB_PATH}
${D}/${KERNEL_IMAGEDEST}/devicetree-${DTB_SYMLINK_NAME}.dtb
+   install -m 0644 ${DTB_PATH}
${D}/${KERNEL_IMAGEDEST}/devicetree-${DTB_SYMLINK_NAME}.${DTB_EXT}
done
done
 }
@@ -46,7 +47,8 @@ do_install_append() {
 do_deploy_append() {
for DTB in ${KERNEL_DEVICETREE}; do
DTB=`normalize_dtb "${DTB}"`
-   DTB_BASE_NAME=`basename ${DTB} .dtb`
+   DTB_EXT=${DTB##*.}
+   DTB_BASE_NAME=`basename ${DTB} ."${DTB_EXT}"`
for type in ${KERNEL_IMAGETYPE_FOR_MAKE}; do
base_name=${type}"-"${KERNEL_IMAGE_BASE_NAME}
symlink_name=${type}"-"${KERNEL_IMAGE_SYMLINK_NAME}
@@ -54,8 +56,8 @@ do_deploy_append() {
DTB_SYMLINK_NAME=`echo ${symlink_name} | sed
"s/${MACHINE}/${DTB_BASE_NAME}/g"`
DTB_PATH=`get_real_dtb_path_in_kernel "${DTB}"`
install -d ${DEPLOYDIR}
-   install -m 0644 ${DTB_PATH}
${DEPLOYDIR}/${DTB_NAME}.dtb
-   ln -sf ${DTB_NAME}.dtb
${DEPLOYDIR}/${DTB_SYMLINK_NAME}.dtb
+   install -m 0644 ${DTB_PATH}
${DEPLOYDIR}/${DTB_NAME}.${DTB_EXT}
+   ln -sf ${DTB_NAME}.${DTB_EXT}
${DEPLOYDIR}/${DTB_SYMLINK_NAME}.${DTB_EXT}
done
done
 }
@@ -65,9 +67,10 @@ pkg_postinst_kernel-devicetree () {
for DTB in ${KERNEL_DEVICETREE}; do
for type in ${KERNEL_IMAGETYPE_FOR_MAKE}; do
symlink_name=${type}"-"${KERNEL_IMAGE_SYMLINK_NAME}
+   DTB_EXT=${DTB##*.}
DTB_BASE_NAME=`basename ${DTB} | awk -F "." '{print
$1}'`
DTB_SYMLINK_NAME=`echo ${symlink_name} | sed
"s/${MACHINE}/${DTB_BASE_NAME}/g"`
-   update-alternatives --install
/${KERNEL_IMAGEDEST}/${DTB_BASE_NAME}.dtb ${DTB_BASE_NAME}.dtb
/boot/devicetree-${DTB_SYMLINK_NAME}.dtb ${KERNEL_PRIORITY} || true
+   update-alternatives --install
/${KERNEL_IMAGEDEST}/${DTB_BASE_NAME}.${DTB_EXT} ${DTB_BASE_NAME}.${DTB_EXT}
/boot/devicetree-${DTB_SYMLINK_NAME}.${DTB_EXT} ${KERNEL_PRIORITY} || true
done
done
 }
@@ -77,9 +80,10 @@ pkg_postrm_kernel-devicetree () {
for DTB in ${KERNEL_DEVICETREE}; do
for type in ${KERNEL_IMAGETYPE_FOR_MAKE}; do
symlink_name=${type}"-"${KERNEL_IMAGE_SYMLINK_NAME}
+   DTB_EXT=${DTB##*.}
DTB_BASE_NAME=`basename ${DTB} | awk -F "." '{print
$1}'`
DTB_SYMLINK_NAME=`echo ${symlink_name} | sed
"s/${MACHINE}/${DTB_BASE_NAME}/g"`
-   update-alternatives --remove ${DTB_BASE_NAME}.dtb
/boot/devicetree-${DTB_SYMLINK_NAME}.dtb ${KERNEL_PRIORITY} || true
+   update-alternatives --remove
${DTB_BASE_NAME}.${DTB_EXT} /boot/devicetree-${DTB_SYMLINK_NAME}.${DTB_EXT}
${KERNEL_PRIORITY} || true
done
done
 }
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v3] Support for .dtbo files for dtb overlays

[Herve Jourdain]

Ping...

-Original Message-
From: Herve Jourdain [mailto:herve.jourd...@neuf.fr] 
Sent: mardi 31 mai 2016 09:55
To: openembedded-core@lists.openembedded.org
Cc: Herve Jourdain <herve.jourd...@neuf.fr>
Subject: [OE-core][PATCH v3] Support for .dtbo files for dtb overlays

Sorry, sent to the wrong list initially, then with wrong header, so updating
header...

v3: rebased

Recent kernels tend to use .dtbo files for device tree overlays, instead of
.dtb before.
.dtb are still used, but only for the "real" device trees (not the
overlays).

On some platforms (meta-raspberrypi for instance), recent firmware only
loads .dtbo files for overlays.

This patch tries to address this issue, while not breaking support for .dtb
overlays.
It allows the installation/deployment of both .dtb and .dtbo files, for
device trees and overlays.

This is in line with the behavior of kernels 4.4.6+

Herve Jourdain (1):
  linux-dtb.inc: Support for .dtbo files for dtb overlays

 meta/recipes-kernel/linux/linux-dtb.inc | 18 +++---
 1 file changed, 11 insertions(+), 7 deletions(-)

-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] ***SPAM*** Re: [PATCH] smartpm: Don't ignore error if RPM transaction fails without problems

[Herve Jourdain]

Hi Mark,

OK, I've just sent the patch for the immediate issue to the list.

For the remaining potential issue, I believe one easy way to fix it would be
to handle the RPMPROB_PKG_INSTALLED error in addition to the existing error
types, but without generating a retry (if attempting to install a package,
and the package is already installed, then it should be just fine)...
But without a way to test the fix, I'm not sure if we want to do that...

Herve

-Original Message-
From: Mark Hatle [mailto:mark.ha...@windriver.com] 
Sent: mercredi 8 juin 2016 18:47
To: Herve Jourdain <herve.jourd...@neuf.fr>
Cc: openembedded-core@lists.openembedded.org
Subject: ***SPAM*** Re: [OE-core] [PATCH] smartpm: Don't ignore error if RPM
transaction fails without problems

On 6/8/16 11:17 AM, Herve Jourdain wrote:
> Hi Mark,
> 
> In my case, the issue was due to an empty problem list, which after
Daniel's fix did trigger a retry, which failed because the packages were
already installed.
> But the code for a non-empty problem list does also trigger a retry, and I
suppose it would run also in the same "package already installed" issue, if
it were to be triggered - not sure though, since I never had that case yet.
> Do you think we need to check and potentially fix that case? Or shall we
remove the retry feature altogether instead?

We should definitely get the fix suggested here in place and resolve the
immediate issue.

I'm not sure if we can intentionally trigger the faults or not.  If we can,
then we can add a test case to the existing harness.

The normal way to test this is inject a pre/post install script fault -- but
the cross install process protects against that already.

I can't think of any way to trigger the fault in an automated fashion (cause
a failure during install vs during transaction config)

--Mark

> Hervé
> 
>> Le 9 juin 2016 à 00:05, Mark Hatle <mark.ha...@windriver.com> a écrit :
>>
>>> On 6/8/16 10:43 AM, Klauer, Daniel wrote:
>>> Hello,
>>>
>>>> You also need to add another check just before raising the error, 
>>>> or you would end up getting an "unknown error" raised there.
>>>> I basically replaced:
>>>> -if (probs is not None) and (not retry):
>>>> +   if (probs is not None) and ((len(probs) != 0) or not
>>>> sysconf.has("attempt-install", soft=True)) and (not retry):
>>>
>>> Hmm, it sounds like the attempt mode wants to ignore installation 
>>> failures (empty problems list) like before the patch, which makes 
>>> sense to me. Afterall, attempt mode wants to try installation and 
>>> ignore failures. So it seems good to fix this regression too.
>>>
>>> However, I wonder why it never ignored a non-empty problems list, 
>>> which would also trigger an error. Maybe that case just never 
>>> happens in practice, because it's always just file conflicts. Those 
>>> trigger a retry, which prevents the error from being raised.
>>>
>>>> BUT reflecting on the whole scheme, I'm wondering how it will work 
>>>> in case of file found conflict, since the problem package gets 
>>>> removed from the list, but the list is committed again, with most 
>>>> packages already installed...
>>
>> File conflicts are discovered prior to the transaction being 
>> committed (installation time).  Problems reported during installation 
>> are 'different' (and generally do not happen).  I'm not sure if a 
>> pre/post install failure, bad package (signature or otherwise) or 
>> whatever would do here.  I'm not sure it's been tested.
>>
>> (The items above can't generally happen based on the way the system 
>> is designed..)
>>
>> --Mark
>>
>>>> I therefore wonder that there could be the same error that I got in 
>>>> the end, i.e failing with package already installed - which should 
>>>> not fail for attempt only.
>>>
>>> Indeed, I'm curious about that too...
>>>
>>> If you could put together the patch, that would be great and fine with
me.
>>>
>>> Thanks,
>>> Daniel
>>>
>>
>> --
>> ___
>> 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] [smartpm][PATCH 1/1] smartpm: if RPM transaction fails with an empty list of problems in attempt mode, ignore it!

[Herve Jourdain]

Since commit be0cabf816a84c59e0e951b92a570121ed843822 on 2016/05/17, smartpm 
will retry the transaction if ts.run() returns with an empty list of problems, 
and we're in attempt mode.
But then, since all the packages are already installed, the transaction will 
fail with "package already installed" error.

In attempt mode, it's fine to not retry nor generate an error when the 
transaction fails for no reason linked to files/packages conflicts, so this 
patch fixes this behaviour.

Signed-off-by: Herve Jourdain <herve.jourd...@neuf.fr>
---
 .../python/python-smartpm/smart-attempt.patch  | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-devtools/python/python-smartpm/smart-attempt.patch 
b/meta/recipes-devtools/python/python-smartpm/smart-attempt.patch
index 5aedc88..e118204 100644
--- a/meta/recipes-devtools/python/python-smartpm/smart-attempt.patch
+++ b/meta/recipes-devtools/python/python-smartpm/smart-attempt.patch
@@ -26,7 +26,7 @@ diff --git a/smart/backends/rpm/pm.py 
b/smart/backends/rpm/pm.py
 index 9bbd952..ba6405a 100644
 --- a/smart/backends/rpm/pm.py
 +++ b/smart/backends/rpm/pm.py
-@@ -241,15 +241,48 @@ class RPMPackageManager(PackageManager):
+@@ -241,15 +241,56 @@ class RPMPackageManager(PackageManager):
  cb = RPMCallback(prog, upgradednames)
  cb.grabOutput(True)
  probs = None
@@ -36,7 +36,12 @@ index 9bbd952..ba6405a 100644
  finally:
  del getTS.ts
  cb.grabOutput(False)
-+if (probs is not None) and sysconf.has("attempt-install", 
soft=True):
++# If there are file conflicts, and we're attempting installation,
++# remove conflicting packages from the transaction and retry
++# If there are other problems returned by ts.run(), that are not
++# linked with packages/files conflicts (the returned list is 
empty),
++# then don't retry
++if (probs is not None) and (len(probs) != 0) and 
sysconf.has("attempt-install", soft=True):
 +def remove_conflict(pkgNEVR):
 +for key in changeset.keys():
 +if pkgNEVR == str(key):
@@ -68,7 +73,10 @@ index 9bbd952..ba6405a 100644
 +
  prog.setDone()
 -if probs is not None:
-+if (probs is not None) and (not retry):
++# If there are other problems than packages/files conflicts
++# returned by ts.run(), the returned list is empty, and if
++# we're only attempting installation, then don't raise any error
++if (probs is not None) and ((len(probs) != 0) or not 
sysconf.has("attempt-install", soft=True)) and (not retry):
  raise Error, "\n".join([x[0] for x in probs])
  prog.stop()
 +if retry and len(changeset):
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [smartpm][PATCH 0/1] smartpm: if RPM transaction fails with an empty list of problems in attempt mode, ignore it!

[Herve Jourdain]

Since commit be0cabf816a84c59e0e951b92a570121ed843822 on 2016/05/17, smartpm 
will retry the transaction if ts.run() returns with an empty list of problems, 
and we're in attempt mode.
But then, since all the packages are already installed, the transaction will 
fail with "package already installed" error.

In attempt mode, it's fine to not retry nor generate an error when the 
transaction fails for no reason linked to files/packages conflicts, so this 
patch fixes this behaviour.

On a side note, it's most likely that in the case where we could get some 
packages to be returned in error by ts.run(), the current code that removes 
those packages from the list and then retry the transaction would also fail 
with "package already installed" error (unless no packages at all was 
successfully installed).
This patch does not address that case.

Herve Jourdain (1):
  smartpm: if RPM transaction fails with an empty list of problems in
attempt mode, ignore it!

 .../python/python-smartpm/smart-attempt.patch  | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] smartpm: Don't ignore error if RPM transaction fails without problems

[Herve Jourdain]

Hi Mark,

In my case, the issue was due to an empty problem list, which after Daniel's 
fix did trigger a retry, which failed because the packages were already 
installed.
But the code for a non-empty problem list does also trigger a retry, and I 
suppose it would run also in the same "package already installed" issue, if it 
were to be triggered - not sure though, since I never had that case yet.
Do you think we need to check and potentially fix that case? Or shall we remove 
the retry feature altogether instead?

Hervé

> Le 9 juin 2016 à 00:05, Mark Hatle  a écrit :
> 
>> On 6/8/16 10:43 AM, Klauer, Daniel wrote:
>> Hello,
>> 
>>> You also need to add another check just before raising the error, or you
>>> would end up getting an "unknown error" raised there.
>>> I basically replaced:
>>> -if (probs is not None) and (not retry):
>>> +   if (probs is not None) and ((len(probs) != 0) or not
>>> sysconf.has("attempt-install", soft=True)) and (not retry):
>> 
>> Hmm, it sounds like the attempt mode wants to ignore installation failures
>> (empty problems list) like before the patch, which makes sense to me. 
>> Afterall,
>> attempt mode wants to try installation and ignore failures. So it seems good 
>> to
>> fix this regression too.
>> 
>> However, I wonder why it never ignored a non-empty problems list, which would
>> also trigger an error. Maybe that case just never happens in practice, 
>> because
>> it's always just file conflicts. Those trigger a retry, which prevents the 
>> error
>> from being raised.
>> 
>>> BUT reflecting on the whole scheme, I'm wondering how it will work in case
>>> of file found conflict, since the problem package gets removed from the
>>> list, but the list is committed again, with most packages already
>>> installed...
> 
> File conflicts are discovered prior to the transaction being committed
> (installation time).  Problems reported during installation are 'different' 
> (and
> generally do not happen).  I'm not sure if a pre/post install failure, bad
> package (signature or otherwise) or whatever would do here.  I'm not sure it's
> been tested.
> 
> (The items above can't generally happen based on the way the system is 
> designed..)
> 
> --Mark
> 
>>> I therefore wonder that there could be the same error that I got in the end,
>>> i.e failing with package already installed - which should not fail for
>>> attempt only.
>> 
>> Indeed, I'm curious about that too...
>> 
>> If you could put together the patch, that would be great and fine with me.
>> 
>> Thanks,
>> Daniel
>> 
> 
> -- 
> ___
> 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] smartpm: Don't ignore error if RPM transaction fails without problems

[Herve Jourdain]

Hi Daniel,

OK, I'll send what I've done to fix this for me tomorrow - it's basically
what we have discussed here, modification of 2 lines.

Regarding the possibility that the whole scheme might fail because of
"package already installed" during a retry, I won't try anything yet,
because I'd like to understand why it was done this way to begin with -
there may be some good reasons that I just can't find, so I'd rather be on
the safe side.
This said, the way things are done would work if all packages would fail
installation, because then none would become "already installed". But since
I'm not sure what exact kind of use cases / tests are supposed to be working
or not here, I'd rather postpone "fixing" that part.

If anyone on the list knows the history on that part, though, I'd be
interested to learn the background on the design, and the rationale of the
implementation.

Herve

-Original Message-
From: Klauer, Daniel [mailto:daniel.kla...@gin.de] 
Sent: mercredi 8 juin 2016 17:43
To: Herve Jourdain <herve.jourd...@neuf.fr>;
openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH] smartpm: Don't ignore error if RPM
transaction fails without problems

Hello,

> You also need to add another check just before raising the error, or 
> you would end up getting an "unknown error" raised there.
> I basically replaced:
> -if (probs is not None) and (not retry):
> +   if (probs is not None) and ((len(probs) != 0) or not
> sysconf.has("attempt-install", soft=True)) and (not retry):

Hmm, it sounds like the attempt mode wants to ignore installation failures
(empty problems list) like before the patch, which makes sense to me.
Afterall, attempt mode wants to try installation and ignore failures. So it
seems good to fix this regression too.

However, I wonder why it never ignored a non-empty problems list, which
would also trigger an error. Maybe that case just never happens in practice,
because it's always just file conflicts. Those trigger a retry, which
prevents the error from being raised.

> BUT reflecting on the whole scheme, I'm wondering how it will work in 
> case of file found conflict, since the problem package gets removed 
> from the list, but the list is committed again, with most packages 
> already installed...
> I therefore wonder that there could be the same error that I got in 
> the end, i.e failing with package already installed - which should not 
> fail for attempt only.

Indeed, I'm curious about that too...

If you could put together the patch, that would be great and fine with me.

Thanks,
Daniel
=

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] smartpm: Don't ignore error if RPM transaction fails without problems

[Herve Jourdain]

Hi,

Yes, that's what I'm seeing... And setting the check with (len(probs)!=0) in
case of retry makes it go away (I tested that exact same thing yesterday),
provided another small modification is added.
You also need to add another check just before raising the error, or you
would end up getting an "unknown error" raised there.
I basically replaced:
-if (probs is not None) and (not retry):
+   if (probs is not None) and ((len(probs) != 0) or not
sysconf.has("attempt-install", soft=True)) and (not retry):

BUT reflecting on the whole scheme, I'm wondering how it will work in case
of file found conflict, since the problem package gets removed from the
list, but the list is committed again, with most packages already
installed...
I therefore wonder that there could be the same error that I got in the end,
i.e failing with package already installed - which should not fail for
attempt only.

Regarding the "empty" probs list issue when in attempted mode, do you want
to issue the patch, or do you prefer I do it?

Herve

-Original Message-
From: Klauer, Daniel [mailto:daniel.kla...@gin.de] 
Sent: mercredi 8 juin 2016 12:24
To: Herve Jourdain <herve.jourd...@neuf.fr>;
openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH] smartpm: Don't ignore error if RPM
transaction fails without problems

Hello,

I don't know the details of the attempt-install feature, but it looks like
my patch did change the retry behaviour, due to this change in
smart/backends/rpm/pm.py (in smart-attempt.patch):
-if probs and sysconf.has("attempt-install", soft=True):
+if (probs is not None) and sysconf.has("attempt-install",
soft=True):

Unlike before, this if block now sets retry = 1 if len(probs) == 0. It looks
to me like the attempt-install feature only wants to retry in case it found
file conflicts, and there aren't any other problems - but unfortunately
retry is only set back to 0 if it finds something other than file conflicts,
the case of len(probs) == 0 is not handled inside the if block.

Is this the problem you're seeing? I think it could be fixed by reverting
that one change, maybe like this:
-if (probs is not None) and sysconf.has("attempt-install",
soft=True):
+# If there are file conflicts, remove conflicting packages from
transaction and retry,
+# unless there are other problems too.
+if (probs is not None) and (len(probs) != 0) and
sysconf.has("attempt-install", soft=True):

Daniel


From: Herve Jourdain <herve.jourd...@neuf.fr>
Sent: Tuesday, June 7, 2016 15:17
To: Klauer, Daniel; openembedded-core@lists.openembedded.org
Subject: RE: [OE-core] [PATCH] smartpm: Don't ignore error if RPM
transaction fails without problems

Hi Daniel,

I've just met a problem linked to that patch...
Indeed, it appears that your modifications make the original patch work as
intended: check if there are problems like RPMPROB_NEW_FILE_CONFLICT or
RPMPROB_FILE_CONFLICT, then remove the packages from the list of packages to
apply (because it's attempt-install), then try the same transaction again...

The problem is: if not all the packages have problems, then the packages
that didn't have problems installing in the first place will now get an
error: "package already installed"!!!
And since it's not one of the problems that are handled in pm.py, it will
just fail...

What do you think would be the best way to solve this: add a check for all
the codes linked to package already installed in the "attempt-only" check in
pm.py?
Or try to cancel the whole previous transaction - and then keep on
committing the new one?

I can generate a new patch if you want, after your guidance, or let you fix
it, like you prefer.
I do have an environment where I can reproduce this problem easily enough.

Herve

-Original Message-
From: openembedded-core-boun...@lists.openembedded.org
[mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
Klauer, Daniel
Sent: mardi 17 mai 2016 14:58
To: openembedded-core@lists.openembedded.org
Subject: [OE-core] [PATCH] smartpm: Don't ignore error if RPM transaction
fails without problems

SmartPM could misinterpret RPM transaction error as success, if ts.run()
(RPM Python API) returns an empty problems list.

This could happen for example if the RPM database is partially corrupted
such that the transaction does not have any problems like conflicts or
missing dependencies, but still can't be committed.

The added patch fixes the problem in the upstream sources; one of the
existing patches has to be adjusted to still apply.

Signed-off-by: Daniel Klauer <daniel.kla...@gin.de>
---
 .../python/python-smartpm/smart-attempt.patch  |  6 +--
 .../smart-rpm-transaction-failure-check.patch  | 57
++
 meta/recipes-devtools/python/python-smartp

Re: [OE-core] [PATCH] smartpm: Don't ignore error if RPM transaction fails without problems

[Herve Jourdain]

Hi Daniel,

I've just met a problem linked to that patch...
Indeed, it appears that your modifications make the original patch work as
intended: check if there are problems like RPMPROB_NEW_FILE_CONFLICT or
RPMPROB_FILE_CONFLICT, then remove the packages from the list of packages to
apply (because it's attempt-install), then try the same transaction again...

The problem is: if not all the packages have problems, then the packages
that didn't have problems installing in the first place will now get an
error: "package already installed"!!!
And since it's not one of the problems that are handled in pm.py, it will
just fail...

What do you think would be the best way to solve this: add a check for all
the codes linked to package already installed in the "attempt-only" check in
pm.py?
Or try to cancel the whole previous transaction - and then keep on
committing the new one?

I can generate a new patch if you want, after your guidance, or let you fix
it, like you prefer.
I do have an environment where I can reproduce this problem easily enough.

Herve

-Original Message-
From: openembedded-core-boun...@lists.openembedded.org
[mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
Klauer, Daniel
Sent: mardi 17 mai 2016 14:58
To: openembedded-core@lists.openembedded.org
Subject: [OE-core] [PATCH] smartpm: Don't ignore error if RPM transaction
fails without problems

SmartPM could misinterpret RPM transaction error as success, if ts.run()
(RPM Python API) returns an empty problems list.

This could happen for example if the RPM database is partially corrupted
such that the transaction does not have any problems like conflicts or
missing dependencies, but still can't be committed.

The added patch fixes the problem in the upstream sources; one of the
existing patches has to be adjusted to still apply.

Signed-off-by: Daniel Klauer 
---
 .../python/python-smartpm/smart-attempt.patch  |  6 +--
 .../smart-rpm-transaction-failure-check.patch  | 57
++
 meta/recipes-devtools/python/python-smartpm_git.bb |  1 +
 3 files changed, 61 insertions(+), 3 deletions(-)  create mode 100644
meta/recipes-devtools/python/python-smartpm/smart-rpm-transaction-failure-ch
eck.patch

diff --git a/meta/recipes-devtools/python/python-smartpm/smart-attempt.patch
b/meta/recipes-devtools/python/python-smartpm/smart-attempt.patch
index ec98e03..5aedc88 100644
--- a/meta/recipes-devtools/python/python-smartpm/smart-attempt.patch
+++ b/meta/recipes-devtools/python/python-smartpm/smart-attempt.patch
@@ -36,7 +36,7 @@ index 9bbd952..ba6405a 100644
  finally:
  del getTS.ts
  cb.grabOutput(False)
-+if probs and sysconf.has("attempt-install", soft=True):
++if (probs is not None) and sysconf.has("attempt-install",
soft=True):
 +def remove_conflict(pkgNEVR):
 +for key in changeset.keys():
 +if pkgNEVR == str(key):
@@ -67,8 +67,8 @@ index 9bbd952..ba6405a 100644
 +retry = 0
 +
  prog.setDone()
--if probs:
-+if probs and (not retry):
+-if probs is not None:
++if (probs is not None) and (not retry):
  raise Error, "\n".join([x[0] for x in probs])
  prog.stop()
 +if retry and len(changeset):
diff --git
a/meta/recipes-devtools/python/python-smartpm/smart-rpm-transaction-failure-
check.patch
b/meta/recipes-devtools/python/python-smartpm/smart-rpm-transaction-failure-
check.patch
new file mode 100644
index 000..a740ddd
--- /dev/null
+++ b/meta/recipes-devtools/python/python-smartpm/smart-rpm-transaction-
+++ failure-check.patch
@@ -0,0 +1,57 @@
+From 0c55d7e18f40465e95e8e4bf22af01f5d4477d3c Mon Sep 17 00:00:00 2001
+From: Daniel Klauer 
+Date: Wed, 11 May 2016 17:22:49 +0200
+Subject: [PATCH] rpm: Don't ignore transaction error with empty 
+problems list
+
+SmartPM could misinterpret RPM transaction error as success, if 
+ts.run() (RPM Python API) returns an empty problems list, because of 
+incorrect check for None which treated empty list to be the same as 
+None when it has different meaning.
+
+ts.run() returns:
+* None in case of success
+* problems list in case of error, may be empty (look at rpmts_Run() in 
+rpm-5.4.14/python/rpmts-py.c [1])
+
+"if mylist" is not good enough to check for error here, because it will 
+treat an empty list as "false" because its len() == 0 [2].
+
+ts.check() seems to be different (it's ok for it to return an empty 
+list), but for consistency it should be made clear that it can return 
+either None, an empty list or a non-empty list.
+
+[1] http://rpm5.org/cvs/fileview?f=rpm/python/rpmts-py.c=1.111.2.3
+[2] https://docs.python.org/2/library/stdtypes.html#truth-value-testing
+
+Upstream-Status: Pending
+
+Signed-off-by: Daniel Klauer 
+---
+ smart/backends/rpm/pm.py | 

Re: [OE-core] [PATCH 1/2 v4] kernel: Add KERNEL_IMAGETYPES to build multi types kernel at one time

[Herve Jourdain]

Hi,

OK, it seems I've found a patch for meta-raspberrypi. I'll be submitting it
to the Yocto mailing list.
Sorry for the noise.

Herve

-Original Message-
From: Herve Jourdain [mailto:herve.jourd...@neuf.fr] 
Sent: mardi 31 mai 2016 13:37
To: 'zhe...@windriver.com' <zhe...@windriver.com>;
'richard.pur...@linuxfoundation.org' <richard.pur...@linuxfoundation.org>;
'openembedded-core@lists.openembedded.org'
<openembedded-core@lists.openembedded.org>
Subject: RE: [OE-core] [PATCH 1/2 v4] kernel: Add KERNEL_IMAGETYPES to build
multi types kernel at one time

Hi,

I've just found out that this breaks the kernel builds on raspberrypi,
because do_rpiboot_mkimage() uses ${KERNEL_OUTPUT}, and this patch removes
it...
(sorry to find that only now, but I only today switched to a new environment
for some tests) I'm trying to find a patch to that one, but in the meantime,
people might need to revert it if they meet that kind of problems.

Herve

-Original Message-
From: openembedded-core-boun...@lists.openembedded.org
[mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
zhe...@windriver.com
Sent: mercredi 25 mai 2016 10:47
To: richard.pur...@linuxfoundation.org;
openembedded-core@lists.openembedded.org
Subject: [OE-core] [PATCH 1/2 v4] kernel: Add KERNEL_IMAGETYPES to build
multi types kernel at one time

From: He Zhe <zhe...@windriver.com>

Add KERNEL_IMAGETYPES to support building packaging and installing multi
types of kernel images, such as zImage uImage, at one time.

KERNEL_IMAGETYPE and KERNEL_ALT_IMAGETYPE work as before.

Signed-off-by: He Zhe <zhe...@windriver.com>
---
 meta/classes/kernel-fitimage.bbclass|  20 ++--
 meta/classes/kernel-grub.bbclass|  44 +---
 meta/classes/kernel-uimage.bbclass  |  10 +-
 meta/classes/kernel.bbclass | 174
+++-
 meta/conf/documentation.conf|   1 +
 meta/recipes-kernel/linux/linux-dtb.inc |  49 +
 6 files changed, 202 insertions(+), 96 deletions(-)

diff --git a/meta/classes/kernel-fitimage.bbclass
b/meta/classes/kernel-fitimage.bbclass
index 298eda2..9a3caf5 100644
--- a/meta/classes/kernel-fitimage.bbclass
+++ b/meta/classes/kernel-fitimage.bbclass
@@ -1,8 +1,8 @@
 inherit kernel-uboot uboot-sign
 
 python __anonymous () {
-kerneltype = d.getVar('KERNEL_IMAGETYPE', True)
-if kerneltype == 'fitImage':
+kerneltypes = d.getVar('KERNEL_IMAGETYPES', True) or ""
+if 'fitImage' in kerneltypes.split():
 depends = d.getVar("DEPENDS", True)
 depends = "%s u-boot-mkimage-native dtc-native" % depends
 d.setVar("DEPENDS", depends)
@@ -10,7 +10,9 @@ python __anonymous () {
# Override KERNEL_IMAGETYPE_FOR_MAKE variable, which is internal
# to kernel.bbclass . We have to override it, since we pack zImage
# (at least for now) into the fitImage .
-d.setVar("KERNEL_IMAGETYPE_FOR_MAKE", "zImage")
+typeformake = d.getVar("KERNEL_IMAGETYPE_FOR_MAKE", True) or ""
+if 'fitImage' in typeformake.split():
+d.setVar('KERNEL_IMAGETYPE_FOR_MAKE',
+ typeformake.replace('fitImage', 'zImage'))
 
 image = d.getVar('INITRAMFS_IMAGE', True)
 if image:
@@ -187,7 +189,7 @@ EOF
 }
 
 do_assemble_fitimage() {
-   if test "x${KERNEL_IMAGETYPE}" = "xfitImage" ; then
+   if echo ${KERNEL_IMAGETYPES} | grep -wq "fitImage"; then
kernelcount=1
dtbcount=""
rm -f fit-image.its arch/${ARCH}/boot/fitImage @@ -265,14
+267,14 @@ addtask assemble_fitimage before do_install after do_compile
kernel_do_deploy[vardepsexclude] = "DATETIME"
 kernel_do_deploy_append() {
# Update deploy directory
-   if test "x${KERNEL_IMAGETYPE}" = "xfitImage" ; then
+   if echo ${KERNEL_IMAGETYPES} | grep -wq "fitImage"; then
cd ${B}
echo "Copying fit-image.its source file..."
-
its_base_name="${KERNEL_IMAGETYPE}-its-${PV}-${PR}-${MACHINE}-${DATETIME}"
-   its_symlink_name=${KERNEL_IMAGETYPE}-its-${MACHINE}
+
its_base_name="fitImage-its-${PV}-${PR}-${MACHINE}-${DATETIME}"
+   its_symlink_name=fitImage-its-${MACHINE}
install -m 0644 fit-image.its
${DEPLOYDIR}/${its_base_name}.its
-
linux_bin_base_name="${KERNEL_IMAGETYPE}-linux.bin-${PV}-${PR}-${MACHINE}-${
DATETIME}"
-
linux_bin_symlink_name=${KERNEL_IMAGETYPE}-linux.bin-${MACHINE}
+
linux_bin_base_name="fitImage-linux.bin-${PV}-${PR}-${MACHINE}-${DATETIME}"
+   linux_bin_symlink_name=fitImage-linux.bin-${MACHINE}
install -m 0644 linux.bin
${DEPLOYDIR}/${linux_bin_base_name}.bin
 
cd ${DEPLOYDIR}
diff --git a/meta/classes/kernel-grub.bbclass
b/meta/cla

Re: [OE-core] [PATCH 1/2 v4] kernel: Add KERNEL_IMAGETYPES to build multi types kernel at one time

[Herve Jourdain]

Hi,

I've just found out that this breaks the kernel builds on raspberrypi,
because do_rpiboot_mkimage() uses ${KERNEL_OUTPUT}, and this patch removes
it...
(sorry to find that only now, but I only today switched to a new environment
for some tests)
I'm trying to find a patch to that one, but in the meantime, people might
need to revert it if they meet that kind of problems.

Herve

-Original Message-
From: openembedded-core-boun...@lists.openembedded.org
[mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
zhe...@windriver.com
Sent: mercredi 25 mai 2016 10:47
To: richard.pur...@linuxfoundation.org;
openembedded-core@lists.openembedded.org
Subject: [OE-core] [PATCH 1/2 v4] kernel: Add KERNEL_IMAGETYPES to build
multi types kernel at one time

From: He Zhe 

Add KERNEL_IMAGETYPES to support building packaging and installing multi
types of kernel images, such as zImage uImage, at one time.

KERNEL_IMAGETYPE and KERNEL_ALT_IMAGETYPE work as before.

Signed-off-by: He Zhe 
---
 meta/classes/kernel-fitimage.bbclass|  20 ++--
 meta/classes/kernel-grub.bbclass|  44 +---
 meta/classes/kernel-uimage.bbclass  |  10 +-
 meta/classes/kernel.bbclass | 174
+++-
 meta/conf/documentation.conf|   1 +
 meta/recipes-kernel/linux/linux-dtb.inc |  49 +
 6 files changed, 202 insertions(+), 96 deletions(-)

diff --git a/meta/classes/kernel-fitimage.bbclass
b/meta/classes/kernel-fitimage.bbclass
index 298eda2..9a3caf5 100644
--- a/meta/classes/kernel-fitimage.bbclass
+++ b/meta/classes/kernel-fitimage.bbclass
@@ -1,8 +1,8 @@
 inherit kernel-uboot uboot-sign
 
 python __anonymous () {
-kerneltype = d.getVar('KERNEL_IMAGETYPE', True)
-if kerneltype == 'fitImage':
+kerneltypes = d.getVar('KERNEL_IMAGETYPES', True) or ""
+if 'fitImage' in kerneltypes.split():
 depends = d.getVar("DEPENDS", True)
 depends = "%s u-boot-mkimage-native dtc-native" % depends
 d.setVar("DEPENDS", depends)
@@ -10,7 +10,9 @@ python __anonymous () {
# Override KERNEL_IMAGETYPE_FOR_MAKE variable, which is internal
# to kernel.bbclass . We have to override it, since we pack zImage
# (at least for now) into the fitImage .
-d.setVar("KERNEL_IMAGETYPE_FOR_MAKE", "zImage")
+typeformake = d.getVar("KERNEL_IMAGETYPE_FOR_MAKE", True) or ""
+if 'fitImage' in typeformake.split():
+d.setVar('KERNEL_IMAGETYPE_FOR_MAKE', 
+ typeformake.replace('fitImage', 'zImage'))
 
 image = d.getVar('INITRAMFS_IMAGE', True)
 if image:
@@ -187,7 +189,7 @@ EOF
 }
 
 do_assemble_fitimage() {
-   if test "x${KERNEL_IMAGETYPE}" = "xfitImage" ; then
+   if echo ${KERNEL_IMAGETYPES} | grep -wq "fitImage"; then
kernelcount=1
dtbcount=""
rm -f fit-image.its arch/${ARCH}/boot/fitImage @@ -265,14
+267,14 @@ addtask assemble_fitimage before do_install after do_compile
kernel_do_deploy[vardepsexclude] = "DATETIME"
 kernel_do_deploy_append() {
# Update deploy directory
-   if test "x${KERNEL_IMAGETYPE}" = "xfitImage" ; then
+   if echo ${KERNEL_IMAGETYPES} | grep -wq "fitImage"; then
cd ${B}
echo "Copying fit-image.its source file..."
-
its_base_name="${KERNEL_IMAGETYPE}-its-${PV}-${PR}-${MACHINE}-${DATETIME}"
-   its_symlink_name=${KERNEL_IMAGETYPE}-its-${MACHINE}
+
its_base_name="fitImage-its-${PV}-${PR}-${MACHINE}-${DATETIME}"
+   its_symlink_name=fitImage-its-${MACHINE}
install -m 0644 fit-image.its
${DEPLOYDIR}/${its_base_name}.its
-
linux_bin_base_name="${KERNEL_IMAGETYPE}-linux.bin-${PV}-${PR}-${MACHINE}-${
DATETIME}"
-
linux_bin_symlink_name=${KERNEL_IMAGETYPE}-linux.bin-${MACHINE}
+
linux_bin_base_name="fitImage-linux.bin-${PV}-${PR}-${MACHINE}-${DATETIME}"
+   linux_bin_symlink_name=fitImage-linux.bin-${MACHINE}
install -m 0644 linux.bin
${DEPLOYDIR}/${linux_bin_base_name}.bin
 
cd ${DEPLOYDIR}
diff --git a/meta/classes/kernel-grub.bbclass
b/meta/classes/kernel-grub.bbclass
index a63f482..f7dcc07 100644
--- a/meta/classes/kernel-grub.bbclass
+++ b/meta/classes/kernel-grub.bbclass
@@ -10,41 +10,44 @@
 #   updates the new kernel as the boot priority.
 #
 
-pkg_preinst_kernel-image_append () {
+python __anonymous () {
+import re
+
+preinst = '''
# Parsing confliction
[ -f "$D/boot/grub/menu.list" ] && grubcfg="$D/boot/grub/menu.list"
[ -f "$D/boot/grub/grub.cfg" ] && grubcfg="$D/boot/grub/grub.cfg"
if [ -n "$grubcfg" ]; then
# Dereference symlink to avoid confliction with new kernel
name.
-   if grep -q "/${KERNEL_IMAGETYPE} \+root=" $grubcfg; then
-   if [ -L "$D/boot/${KERNEL_IMAGETYPE}" ]; then
-   kimage=`realpath 

[OE-core] [PATCH v3] linux-dtb.inc: Support for .dtbo files for dtb overlays

[Herve Jourdain]

Signed-off-by: Herve Jourdain <herve.jourd...@neuf.fr>
---
 meta/recipes-kernel/linux/linux-dtb.inc | 18 +++---
 1 file changed, 11 insertions(+), 7 deletions(-)

diff --git a/meta/recipes-kernel/linux/linux-dtb.inc 
b/meta/recipes-kernel/linux/linux-dtb.inc
index 74f5ef8..8528d64 100644
--- a/meta/recipes-kernel/linux/linux-dtb.inc
+++ b/meta/recipes-kernel/linux/linux-dtb.inc
@@ -33,12 +33,13 @@ do_compile_append() {
 do_install_append() {
for DTB in ${KERNEL_DEVICETREE}; do
DTB=`normalize_dtb "${DTB}"`
-   DTB_BASE_NAME=`basename ${DTB} .dtb`
+   DTB_EXT=${DTB##*.}
+   DTB_BASE_NAME=`basename ${DTB} ."${DTB_EXT}"`
for type in ${KERNEL_IMAGETYPE_FOR_MAKE}; do
symlink_name=${type}"-"${KERNEL_IMAGE_SYMLINK_NAME}
DTB_SYMLINK_NAME=`echo ${symlink_name} | sed 
"s/${MACHINE}/${DTB_BASE_NAME}/g"`
DTB_PATH=`get_real_dtb_path_in_kernel "${DTB}"`
-   install -m 0644 ${DTB_PATH} 
${D}/${KERNEL_IMAGEDEST}/devicetree-${DTB_SYMLINK_NAME}.dtb
+   install -m 0644 ${DTB_PATH} 
${D}/${KERNEL_IMAGEDEST}/devicetree-${DTB_SYMLINK_NAME}.${DTB_EXT}
done
done
 }
@@ -46,7 +47,8 @@ do_install_append() {
 do_deploy_append() {
for DTB in ${KERNEL_DEVICETREE}; do
DTB=`normalize_dtb "${DTB}"`
-   DTB_BASE_NAME=`basename ${DTB} .dtb`
+   DTB_EXT=${DTB##*.}
+   DTB_BASE_NAME=`basename ${DTB} ."${DTB_EXT}"`
for type in ${KERNEL_IMAGETYPE_FOR_MAKE}; do
base_name=${type}"-"${KERNEL_IMAGE_BASE_NAME}
symlink_name=${type}"-"${KERNEL_IMAGE_SYMLINK_NAME}
@@ -54,8 +56,8 @@ do_deploy_append() {
DTB_SYMLINK_NAME=`echo ${symlink_name} | sed 
"s/${MACHINE}/${DTB_BASE_NAME}/g"`
DTB_PATH=`get_real_dtb_path_in_kernel "${DTB}"`
install -d ${DEPLOYDIR}
-   install -m 0644 ${DTB_PATH} ${DEPLOYDIR}/${DTB_NAME}.dtb
-   ln -sf ${DTB_NAME}.dtb 
${DEPLOYDIR}/${DTB_SYMLINK_NAME}.dtb
+   install -m 0644 ${DTB_PATH} 
${DEPLOYDIR}/${DTB_NAME}.${DTB_EXT}
+   ln -sf ${DTB_NAME}.${DTB_EXT} 
${DEPLOYDIR}/${DTB_SYMLINK_NAME}.${DTB_EXT}
done
done
 }
@@ -65,9 +67,10 @@ pkg_postinst_kernel-devicetree () {
for DTB in ${KERNEL_DEVICETREE}; do
for type in ${KERNEL_IMAGETYPE_FOR_MAKE}; do
symlink_name=${type}"-"${KERNEL_IMAGE_SYMLINK_NAME}
+   DTB_EXT=${DTB##*.}
DTB_BASE_NAME=`basename ${DTB} | awk -F "." '{print 
$1}'`
DTB_SYMLINK_NAME=`echo ${symlink_name} | sed 
"s/${MACHINE}/${DTB_BASE_NAME}/g"`
-   update-alternatives --install 
/${KERNEL_IMAGEDEST}/${DTB_BASE_NAME}.dtb ${DTB_BASE_NAME}.dtb 
/boot/devicetree-${DTB_SYMLINK_NAME}.dtb ${KERNEL_PRIORITY} || true
+   update-alternatives --install 
/${KERNEL_IMAGEDEST}/${DTB_BASE_NAME}.${DTB_EXT} ${DTB_BASE_NAME}.${DTB_EXT} 
/boot/devicetree-${DTB_SYMLINK_NAME}.${DTB_EXT} ${KERNEL_PRIORITY} || true
done
done
 }
@@ -77,9 +80,10 @@ pkg_postrm_kernel-devicetree () {
for DTB in ${KERNEL_DEVICETREE}; do
for type in ${KERNEL_IMAGETYPE_FOR_MAKE}; do
symlink_name=${type}"-"${KERNEL_IMAGE_SYMLINK_NAME}
+   DTB_EXT=${DTB##*.}
DTB_BASE_NAME=`basename ${DTB} | awk -F "." '{print 
$1}'`
DTB_SYMLINK_NAME=`echo ${symlink_name} | sed 
"s/${MACHINE}/${DTB_BASE_NAME}/g"`
-   update-alternatives --remove ${DTB_BASE_NAME}.dtb 
/boot/devicetree-${DTB_SYMLINK_NAME}.dtb ${KERNEL_PRIORITY} || true
+   update-alternatives --remove 
${DTB_BASE_NAME}.${DTB_EXT} /boot/devicetree-${DTB_SYMLINK_NAME}.${DTB_EXT} 
${KERNEL_PRIORITY} || true
done
done
 }
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v3] Support for .dtbo files for dtb overlays

[Herve Jourdain]

Sorry, sent to the wrong list initially, then with wrong header, so updating 
header...

v3: rebased

Recent kernels tend to use .dtbo files for device tree overlays, instead of 
.dtb before.
.dtb are still used, but only for the "real" device trees (not the overlays).

On some platforms (meta-raspberrypi for instance), recent firmware only loads 
.dtbo files for overlays.

This patch tries to address this issue, while not breaking support for .dtb 
overlays.
It allows the installation/deployment of both .dtb and .dtbo files, for device 
trees and overlays.

This is in line with the behavior of kernels 4.4.6+

Herve Jourdain (1):
  linux-dtb.inc: Support for .dtbo files for dtb overlays

 meta/recipes-kernel/linux/linux-dtb.inc | 18 +++---
 1 file changed, 11 insertions(+), 7 deletions(-)

-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [yocto][PATCH v3] Support for .dtbo files for dtb overlays

[Herve Jourdain]

v3: rebased
Recent kernels tend to use .dtbo files for device tree overlays, instead of 
.dtb before.
.dtb are still used, but only for the "real" device trees (not the overlays).

On some platforms (meta-raspberrypi for instance), recent firmware only loads 
.dtbo files for overlays.

This patch tries to address this issue, while not breaking support for .dtb 
overlays.
It allows the installation/deployment of both .dtb and .dtbo files, for device 
trees and overlays.

This is in line with the behavior of kernels 4.4.6+

Herve Jourdain (1):
  linux-dtb.inc: Support for .dtbo files for dtb overlays

 meta/recipes-kernel/linux/linux-dtb.inc | 18 +++---
 1 file changed, 11 insertions(+), 7 deletions(-)

-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [yocto][PATCH v3] linux-dtb.inc: Support for .dtbo files for dtb overlays

[Herve Jourdain]

Signed-off-by: Herve Jourdain <herve.jourd...@neuf.fr>
---
 meta/recipes-kernel/linux/linux-dtb.inc | 18 +++---
 1 file changed, 11 insertions(+), 7 deletions(-)

diff --git a/meta/recipes-kernel/linux/linux-dtb.inc 
b/meta/recipes-kernel/linux/linux-dtb.inc
index 74f5ef8..8528d64 100644
--- a/meta/recipes-kernel/linux/linux-dtb.inc
+++ b/meta/recipes-kernel/linux/linux-dtb.inc
@@ -33,12 +33,13 @@ do_compile_append() {
 do_install_append() {
for DTB in ${KERNEL_DEVICETREE}; do
DTB=`normalize_dtb "${DTB}"`
-   DTB_BASE_NAME=`basename ${DTB} .dtb`
+   DTB_EXT=${DTB##*.}
+   DTB_BASE_NAME=`basename ${DTB} ."${DTB_EXT}"`
for type in ${KERNEL_IMAGETYPE_FOR_MAKE}; do
symlink_name=${type}"-"${KERNEL_IMAGE_SYMLINK_NAME}
DTB_SYMLINK_NAME=`echo ${symlink_name} | sed 
"s/${MACHINE}/${DTB_BASE_NAME}/g"`
DTB_PATH=`get_real_dtb_path_in_kernel "${DTB}"`
-   install -m 0644 ${DTB_PATH} 
${D}/${KERNEL_IMAGEDEST}/devicetree-${DTB_SYMLINK_NAME}.dtb
+   install -m 0644 ${DTB_PATH} 
${D}/${KERNEL_IMAGEDEST}/devicetree-${DTB_SYMLINK_NAME}.${DTB_EXT}
done
done
 }
@@ -46,7 +47,8 @@ do_install_append() {
 do_deploy_append() {
for DTB in ${KERNEL_DEVICETREE}; do
DTB=`normalize_dtb "${DTB}"`
-   DTB_BASE_NAME=`basename ${DTB} .dtb`
+   DTB_EXT=${DTB##*.}
+   DTB_BASE_NAME=`basename ${DTB} ."${DTB_EXT}"`
for type in ${KERNEL_IMAGETYPE_FOR_MAKE}; do
base_name=${type}"-"${KERNEL_IMAGE_BASE_NAME}
symlink_name=${type}"-"${KERNEL_IMAGE_SYMLINK_NAME}
@@ -54,8 +56,8 @@ do_deploy_append() {
DTB_SYMLINK_NAME=`echo ${symlink_name} | sed 
"s/${MACHINE}/${DTB_BASE_NAME}/g"`
DTB_PATH=`get_real_dtb_path_in_kernel "${DTB}"`
install -d ${DEPLOYDIR}
-   install -m 0644 ${DTB_PATH} ${DEPLOYDIR}/${DTB_NAME}.dtb
-   ln -sf ${DTB_NAME}.dtb 
${DEPLOYDIR}/${DTB_SYMLINK_NAME}.dtb
+   install -m 0644 ${DTB_PATH} 
${DEPLOYDIR}/${DTB_NAME}.${DTB_EXT}
+   ln -sf ${DTB_NAME}.${DTB_EXT} 
${DEPLOYDIR}/${DTB_SYMLINK_NAME}.${DTB_EXT}
done
done
 }
@@ -65,9 +67,10 @@ pkg_postinst_kernel-devicetree () {
for DTB in ${KERNEL_DEVICETREE}; do
for type in ${KERNEL_IMAGETYPE_FOR_MAKE}; do
symlink_name=${type}"-"${KERNEL_IMAGE_SYMLINK_NAME}
+   DTB_EXT=${DTB##*.}
DTB_BASE_NAME=`basename ${DTB} | awk -F "." '{print 
$1}'`
DTB_SYMLINK_NAME=`echo ${symlink_name} | sed 
"s/${MACHINE}/${DTB_BASE_NAME}/g"`
-   update-alternatives --install 
/${KERNEL_IMAGEDEST}/${DTB_BASE_NAME}.dtb ${DTB_BASE_NAME}.dtb 
/boot/devicetree-${DTB_SYMLINK_NAME}.dtb ${KERNEL_PRIORITY} || true
+   update-alternatives --install 
/${KERNEL_IMAGEDEST}/${DTB_BASE_NAME}.${DTB_EXT} ${DTB_BASE_NAME}.${DTB_EXT} 
/boot/devicetree-${DTB_SYMLINK_NAME}.${DTB_EXT} ${KERNEL_PRIORITY} || true
done
done
 }
@@ -77,9 +80,10 @@ pkg_postrm_kernel-devicetree () {
for DTB in ${KERNEL_DEVICETREE}; do
for type in ${KERNEL_IMAGETYPE_FOR_MAKE}; do
symlink_name=${type}"-"${KERNEL_IMAGE_SYMLINK_NAME}
+   DTB_EXT=${DTB##*.}
DTB_BASE_NAME=`basename ${DTB} | awk -F "." '{print 
$1}'`
DTB_SYMLINK_NAME=`echo ${symlink_name} | sed 
"s/${MACHINE}/${DTB_BASE_NAME}/g"`
-   update-alternatives --remove ${DTB_BASE_NAME}.dtb 
/boot/devicetree-${DTB_SYMLINK_NAME}.dtb ${KERNEL_PRIORITY} || true
+   update-alternatives --remove 
${DTB_BASE_NAME}.${DTB_EXT} /boot/devicetree-${DTB_SYMLINK_NAME}.${DTB_EXT} 
${KERNEL_PRIORITY} || true
done
done
 }
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [mesa][PATCH v2 1/1] Fix mesa_populate_packages() when dri is disabled

[Herve Jourdain]

Hi Martin,

Even though the line just below uses "+"? Or shall I modify both?

Herve

-Original Message-
From: Martin Jansa [mailto:martin.ja...@gmail.com] 
Sent: mercredi 18 mai 2016 16:15
To: Herve Jourdain <herve.jourd...@neuf.fr>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [mesa][PATCH v2 1/1] Fix mesa_populate_packages()
when dri is disabled

On Wed, May 18, 2016 at 08:33:37PM +0800, Herve Jourdain wrote:
> When compiling mesa, if dri is disabled in PACKAGECONFIG, or if the list
of DRI drivers is empty, it will cause populate_package to fail, because it
can't find - rightfully - the directory for the DRI drivers.
> This patch checks that the directory indeed exists before trying to get a
list of the files in it
> 
> Signed-off-by: Herve Jourdain <herve.jourd...@neuf.fr>
> ---
>  meta/recipes-graphics/mesa/mesa.inc | 19 ++-
>  1 file changed, 10 insertions(+), 9 deletions(-)
> 
> diff --git a/meta/recipes-graphics/mesa/mesa.inc
b/meta/recipes-graphics/mesa/mesa.inc
> index a4e5351..0e46092 100644
> --- a/meta/recipes-graphics/mesa/mesa.inc
> +++ b/meta/recipes-graphics/mesa/mesa.inc
> @@ -143,15 +143,16 @@ python mesa_populate_packages() {
>  
>  import re
>  dri_drivers_root = os.path.join(d.getVar('libdir', True), "dri")
> -dri_pkgs = os.listdir(d.getVar('PKGD', True) + dri_drivers_root)
> -lib_name = d.expand("${MLPREFIX}mesa-megadriver")
> -for p in dri_pkgs:
> -m = re.match('^(.*)_dri\.so$', p)
> -if m:
> -pkg_name = " ${MLPREFIX}mesa-driver-%s" %
legitimize_package_name(m.group(1))
> -d.appendVar("RPROVIDES_%s" % lib_name, pkg_name)
> -d.appendVar("RCONFLICTS_%s" % lib_name, pkg_name)
> -d.appendVar("RREPLACES_%s" % lib_name, pkg_name)
> +if os.path.isdir(d.getVar('PKGD', True) + dri_drivers_root):

Use os.path.join instead of +

> +dri_pkgs = os.listdir(d.getVar('PKGD', True) + dri_drivers_root)
> +lib_name = d.expand("${MLPREFIX}mesa-megadriver")
> +for p in dri_pkgs:
> +m = re.match('^(.*)_dri\.so$', p)
> +if m:
> +pkg_name = " ${MLPREFIX}mesa-driver-%s" %
legitimize_package_name(m.group(1))
> +d.appendVar("RPROVIDES_%s" % lib_name, pkg_name)
> +d.appendVar("RCONFLICTS_%s" % lib_name, pkg_name)
> +d.appendVar("RREPLACES_%s" % lib_name, pkg_name)
>  
>  pipe_drivers_root = os.path.join(d.getVar('libdir', True),
"gallium-pipe")
>  do_split_packages(d, pipe_drivers_root, '^pipe_(.*)\.so$',
'mesa-driver-pipe-%s', 'Mesa %s pipe driver', extra_depends='')
> -- 
> 2.7.4
> 
> -- 
> ___
> 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

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [mesa][PATCH v2 1/1] Fix mesa_populate_packages() when dri is disabled

[Herve Jourdain]

When compiling mesa, if dri is disabled in PACKAGECONFIG, or if the list of DRI 
drivers is empty, it will cause populate_package to fail, because it can't find 
- rightfully - the directory for the DRI drivers.
This patch checks that the directory indeed exists before trying to get a list 
of the files in it

Signed-off-by: Herve Jourdain <herve.jourd...@neuf.fr>
---
 meta/recipes-graphics/mesa/mesa.inc | 19 ++-
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/meta/recipes-graphics/mesa/mesa.inc 
b/meta/recipes-graphics/mesa/mesa.inc
index a4e5351..0e46092 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -143,15 +143,16 @@ python mesa_populate_packages() {
 
 import re
 dri_drivers_root = os.path.join(d.getVar('libdir', True), "dri")
-dri_pkgs = os.listdir(d.getVar('PKGD', True) + dri_drivers_root)
-lib_name = d.expand("${MLPREFIX}mesa-megadriver")
-for p in dri_pkgs:
-m = re.match('^(.*)_dri\.so$', p)
-if m:
-pkg_name = " ${MLPREFIX}mesa-driver-%s" % 
legitimize_package_name(m.group(1))
-d.appendVar("RPROVIDES_%s" % lib_name, pkg_name)
-d.appendVar("RCONFLICTS_%s" % lib_name, pkg_name)
-d.appendVar("RREPLACES_%s" % lib_name, pkg_name)
+if os.path.isdir(d.getVar('PKGD', True) + dri_drivers_root):
+dri_pkgs = os.listdir(d.getVar('PKGD', True) + dri_drivers_root)
+lib_name = d.expand("${MLPREFIX}mesa-megadriver")
+for p in dri_pkgs:
+m = re.match('^(.*)_dri\.so$', p)
+if m:
+pkg_name = " ${MLPREFIX}mesa-driver-%s" % 
legitimize_package_name(m.group(1))
+d.appendVar("RPROVIDES_%s" % lib_name, pkg_name)
+d.appendVar("RCONFLICTS_%s" % lib_name, pkg_name)
+d.appendVar("RREPLACES_%s" % lib_name, pkg_name)
 
 pipe_drivers_root = os.path.join(d.getVar('libdir', True), "gallium-pipe")
 do_split_packages(d, pipe_drivers_root, '^pipe_(.*)\.so$', 
'mesa-driver-pipe-%s', 'Mesa %s pipe driver', extra_depends='')
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [mesa][PATCH v2 0/1] Fix mesa_populate_packages() when dri is disabled

[Herve Jourdain]

When compiling mesa, if dri is disabled in PACKAGECONFIG, or if the list of DRI 
drivers is empty, it will cause populate_package to fail, because it can't find 
- rightfully - the directory for the DRI drivers.
This patch checks that the directory indeed exists before trying to get a list 
of the files in it

Herve Jourdain (1):
  Fix mesa_populate_packages() when dri is disabled

 meta/recipes-graphics/mesa/mesa.inc | 19 ++-
 1 file changed, 10 insertions(+), 9 deletions(-)

-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [mesa][PATCH 1/1] Fix mesa_populate_packages() when dri is disabled

[Herve Jourdain]

Hi Ross,

 

Yep, you’re right, sorry for that. V2 coming in a few.

 

Herve

 

From: Burton, Ross [mailto:ross.bur...@intel.com] 
Sent: mercredi 18 mai 2016 13:28
To: Herve Jourdain <herve.jourd...@neuf.fr>
Cc: OE-core <openembedded-core@lists.openembedded.org>
Subject: Re: [OE-core] [mesa][PATCH 1/1] Fix mesa_populate_packages() when dri 
is disabled

 

 

On 18 May 2016 at 10:45, Herve Jourdain <herve.jourd...@neuf.fr 
<mailto:herve.jourd...@neuf.fr> > wrote:

+if os.path.isdir(dri_drivers_root):


You're checking files on the host here as dri_driver_root is ${libdir}/dri and 
you failed to append PKGD (see the os.listdir call).

 

Ross

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [mesa][PATCH 1/1] Fix mesa_populate_packages() when dri is disabled

[Herve Jourdain]

When compiling mesa, if dri is disabled in PACKAGECONFIG, or if the list of DRI 
drivers is empty, it will cause populate_package to fail, because it can't find 
- rightfully - the directory for the DRI drivers.
This patch checks that the directory indeed exists before trying to get a list 
of the files in it

Signed-off-by: Herve Jourdain <herve.jourd...@neuf.fr>
---
 meta/recipes-graphics/mesa/mesa.inc | 19 ++-
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/meta/recipes-graphics/mesa/mesa.inc 
b/meta/recipes-graphics/mesa/mesa.inc
index a4e5351..0e46092 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -143,15 +143,16 @@ python mesa_populate_packages() {
 
 import re
 dri_drivers_root = os.path.join(d.getVar('libdir', True), "dri")
-dri_pkgs = os.listdir(d.getVar('PKGD', True) + dri_drivers_root)
-lib_name = d.expand("${MLPREFIX}mesa-megadriver")
-for p in dri_pkgs:
-m = re.match('^(.*)_dri\.so$', p)
-if m:
-pkg_name = " ${MLPREFIX}mesa-driver-%s" % 
legitimize_package_name(m.group(1))
-d.appendVar("RPROVIDES_%s" % lib_name, pkg_name)
-d.appendVar("RCONFLICTS_%s" % lib_name, pkg_name)
-d.appendVar("RREPLACES_%s" % lib_name, pkg_name)
+if os.path.isdir(dri_drivers_root):
+dri_pkgs = os.listdir(d.getVar('PKGD', True) + dri_drivers_root)
+lib_name = d.expand("${MLPREFIX}mesa-megadriver")
+for p in dri_pkgs:
+m = re.match('^(.*)_dri\.so$', p)
+if m:
+pkg_name = " ${MLPREFIX}mesa-driver-%s" % 
legitimize_package_name(m.group(1))
+d.appendVar("RPROVIDES_%s" % lib_name, pkg_name)
+d.appendVar("RCONFLICTS_%s" % lib_name, pkg_name)
+d.appendVar("RREPLACES_%s" % lib_name, pkg_name)
 
 pipe_drivers_root = os.path.join(d.getVar('libdir', True), "gallium-pipe")
 do_split_packages(d, pipe_drivers_root, '^pipe_(.*)\.so$', 
'mesa-driver-pipe-%s', 'Mesa %s pipe driver', extra_depends='')
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [mesa][PATCH 0/1] Fix mesa_populate_packages() when dri is disabled

[Herve Jourdain]

When compiling mesa, if dri is disabled in PACKAGECONFIG, or if the list of DRI 
drivers is empty, it will cause populate_package to fail, because it can't find 
- rightfully - the directory for the DRI drivers.
This patch checks that the directory indeed exists before trying to get a list 
of the files in it

Herve Jourdain (1):
  Fix mesa_populate_packages() when dri is disabled

 meta/recipes-graphics/mesa/mesa.inc | 19 ++-
 1 file changed, 10 insertions(+), 9 deletions(-)

-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [meta-oe][PATCH] systemd: binfmt should be added to SYSTEMD_PACKAGES only if binfmt is enabled

[Herve Jourdain]

Hi Ross,

 

Duly noted, actually I tried several times through git-send-email, but it 
didn’t go through… I’m trying to figure out how to have it working in my 
configuration, but as a last resort I turned to Oulook…

Until I fix my configuration, if I have other patches to send, I’ll follow your 
suggestion and attach the patch to the email.

 

Thanks,

 

Herve

 

From: Burton, Ross [mailto:ross.bur...@intel.com] 
Sent: lundi 7 mars 2016 17:16
To: Herve Jourdain <herve.jourd...@neuf.fr>
Cc: OE-core <openembedded-core@lists.openembedded.org>
Subject: Re: [OE-core] [meta-oe][PATCH] systemd: binfmt should be added to 
SYSTEMD_PACKAGES only if binfmt is enabled

 

Your mailer (Outlook, by the look of it) is corrupting patches (wraps lines 
when they shouldn't be wrapped), in the future please don't send patches by 
pasting them into an email but use git-send-email if you can, or attach the 
patch if you can't.  For a one-liner I could fix up the patch by hand so you 
don't need to re-send this one.

 

Ross

 

On 7 March 2016 at 15:59, Herve Jourdain <herve.jourd...@neuf.fr 
<mailto:herve.jourd...@neuf.fr> > wrote:

V2
Signed-off-by: Herve Jourdain <herve.jourd...@neuf.fr 
<mailto:herve.jourd...@neuf.fr> >
---
 meta/recipes-core/systemd/systemd_229.bb <http://systemd_229.bb>  | 2 ++--
 1 file changed, 1 insertions(+), 1 deletions(-)

diff --git a/meta/recipes-core/systemd/systemd_229.bb <http://systemd_229.bb> 
b/meta/recipes-core/systemd/systemd_229.bb <http://systemd_229.bb> 
index 16af0ac..a537dd3 100644
--- a/meta/recipes-core/systemd/systemd_229.bb <http://systemd_229.bb> 
+++ b/meta/recipes-core/systemd/systemd_229.bb <http://systemd_229.bb> 
@@ -298,7 +298,7 @@ PACKAGES =+ "\
 ${PN}-extra-utils \
 "

-SYSTEMD_PACKAGES = "${PN}-binfmt"
+SYSTEMD_PACKAGES = "${@bb.utils.contains('PACKAGECONFIG', 'binfmt', 
<mailto:$%7b@bb.utils.contains('PACKAGECONFIG',%20'binfmt',%0b'$%7bPN%7d-binfmt',%20'',%20d)%7d>
 
'${PN}-binfmt', '', d)}"
 SYSTEMD_SERVICE_${PN}-binfmt = "systemd-binfmt.service"

 USERADD_PACKAGES = "${PN}"
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org 
<mailto:Openembedded-core@lists.openembedded.org> 
http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org 
<mailto: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] [meta-oe][PATCH] systemd: binfmt should be added to SYSTEMD_PACKAGES only if binfmt is enabled

[Herve Jourdain]

V2
Signed-off-by: Herve Jourdain <herve.jourd...@neuf.fr>
---
 meta/recipes-core/systemd/systemd_229.bb | 2 ++--
 1 file changed, 1 insertions(+), 1 deletions(-)

diff --git a/meta/recipes-core/systemd/systemd_229.bb
b/meta/recipes-core/systemd/systemd_229.bb
index 16af0ac..a537dd3 100644
--- a/meta/recipes-core/systemd/systemd_229.bb
+++ b/meta/recipes-core/systemd/systemd_229.bb
@@ -298,7 +298,7 @@ PACKAGES =+ "\
 ${PN}-extra-utils \
 "
 
-SYSTEMD_PACKAGES = "${PN}-binfmt"
+SYSTEMD_PACKAGES = "${@bb.utils.contains('PACKAGECONFIG', 'binfmt',
'${PN}-binfmt', '', d)}"
 SYSTEMD_SERVICE_${PN}-binfmt = "systemd-binfmt.service"
 
 USERADD_PACKAGES = "${PN}"
--
1.9.1
--
___
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] [meta-oe][PATCH] systemd: binfmt should be added to SYSTEMD_PACKAGES

[Herve Jourdain]

Hmmm… It seems the subject line was cut… It was supposed to say "system: binfmt 
should be added to SYSTEMD_PACKAGES only if binfmt is enabled".
Yep, the second condition was overkill, I agree.
I'll send a new version of the patch.

Thanks,

Herve

From: Burton, Ross [mailto:ross.bur...@intel.com] 
Sent: lundi 7 mars 2016 15:39
To: Herve Jourdain <herve.jourd...@neuf.fr>
Cc: OE-core <openembedded-core@lists.openembedded.org>
Subject: Re: [OE-core] [meta-oe][PATCH] systemd: binfmt should be added to 
SYSTEMD_PACKAGES

First, the commit message isn't accurate (binfmt was already in 
SYSTEMD_PACKAGES).

On 7 March 2016 at 14:17, Herve Jourdain <herve.jourd...@neuf.fr> wrote:
-SYSTEMD_PACKAGES = "${PN}-binfmt"
-SYSTEMD_SERVICE_${PN}-binfmt = "systemd-binfmt.service"
+SYSTEMD_PACKAGES = "${@bb.utils.contains('PACKAGECONFIG', 'binfmt',
'${PN}-binfmt', '', d)}"
+SYSTEMD_SERVICE_${PN}-binfmt = "${@bb.utils.contains('PACKAGECONFIG',
'binfmt', 'systemd-binfmt.service', '', d)}"

You don't need to conditionalise SYSTEDM_SERVICE_${PN}-binfmt, just 
SYSTEMD_PACKAGES.

Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [meta-oe][PATCH] systemd: binfmt should be added to SYSTEMD_PACKAGES

[Herve Jourdain]

Signed-off-by: Herve Jourdain <herve.jourd...@neuf.fr>
---
 meta/recipes-core/systemd/systemd_229.bb | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-core/systemd/systemd_229.bb
b/meta/recipes-core/systemd/systemd_229.bb
index 16af0ac..a537dd3 100644
--- a/meta/recipes-core/systemd/systemd_229.bb
+++ b/meta/recipes-core/systemd/systemd_229.bb
@@ -298,8 +298,8 @@ PACKAGES =+ "\
 ${PN}-extra-utils \
 "
 
-SYSTEMD_PACKAGES = "${PN}-binfmt"
-SYSTEMD_SERVICE_${PN}-binfmt = "systemd-binfmt.service"
+SYSTEMD_PACKAGES = "${@bb.utils.contains('PACKAGECONFIG', 'binfmt',
'${PN}-binfmt', '', d)}"
+SYSTEMD_SERVICE_${PN}-binfmt = "${@bb.utils.contains('PACKAGECONFIG',
'binfmt', 'systemd-binfmt.service', '', d)}"
 
 USERADD_PACKAGES = "${PN}"
 USERADD_PARAM_${PN} += "${@bb.utils.contains('PACKAGECONFIG', 'microhttpd',
'--system -d / -M --shell /bin/nologin systemd-journal-gateway;', '', d)}"
-- 
1.9.1
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe-core][systemd][PATCH] some dependencies in systemd seem not to be taken into account in systemd_229.bb

[Herve Jourdain]

Dear Anders,

Regarding the binfmt part, you're right, it should be a second patch... I
will resend it separately.

For the gcrypt/resolved patch, I will rework it.
One thing, though, the idea was to add the --disable-gcrypt in the
EXTRA_OECONF, if neither gcrypt nor resolved are enabled.
Hence the removal of "--disable-gcrypt" in the PACKAGECONFIG[gcrypt] line...
That seemed easier at the time, but I'll try to find a different way to
achieve this.

This patch seems to build/work fine on my system, but I'll try to find a
better one.

Thanks,

Herve

-Original Message-
From: Anders Darander [mailto:and...@chargestorm.se] 
Sent: lundi 7 mars 2016 12:47
To: Herve Jourdain <herve.jourd...@neuf.fr>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [oe-core][systemd][PATCH] some dependencies in
systemd seem not to be taken into account in systemd_229.bb

(Resending as it didn't go to the list).

Thanks!

I've just ran into this myself this morning.

A few comments are inlined.

* Herve Jourdain <herve.jourd...@neuf.fr> [160307 11:51]:

> # Sign the journal for anti-tampering

> -PACKAGECONFIG[gcrypt] = "--enable-gcrypt,--disable-gcrypt,libgcrypt"

Please, keep this line as it is. If gcrypt isn't enabled, we need to pass
--disable-gcrypt. Tnus, it should be part of this line.

> +# RESOLVED depends on GCRYPT, so disable gcrypt only if resolved and 
> +gcrypt
> are NOT part of PACKAGECONFIG - done in EXTRA_OECONF

Remove the comment.

> +PACKAGECONFIG[gcrypt] = "--enable-gcrypt,,libgcrypt"

As above, keep the original line.


> -PACKAGECONFIG[resolved] = "--enable-resolved,--disable-resolved"

> +# RESOLVED depends on GCRYPT, so enable gcrypt any time resolved is 
> +in
> PACKAGECONFIG

Either keep this comment, and keep enabling gcrypt.

Though, I'd prefer to follow the precedence of importd, and just have the
comment stating what you need to enable.

> +PACKAGECONFIG[resolved] = "--enable-resolved
> --enable-gcrypt,--disable-resolved,libgcrypt"

No, don't add --enable-gcrypt to the resolved PACKAGECONFIG.


> +# RESOLVED depends on GCRYPT, so disable gcrypt only if resolved and 
> +gcrypt
> are NOT part of PACKAGECONFIG

> +EXTRA_OECONF += "${@bb.utils.contains_any('PACKAGECONFIG', 'resolved
> gcrypt', '', '--disable-gcrypt', d)}
> <mailto:$%7b@bb.utils.contains_any('PACKAGECONFIG',%20'resolved%20gcry
> pt',%2
> 0'',%20'--disable-gcrypt',%20d)%7d> "

Skip this part.


> + if [ ${@bb.utils.contains('PACKAGECONFIG
> <mailto:$%7b@bb.utils.contains('PACKAGECONFIG> ', 'resolved', 'true', 
> 'false', d)} -a \

> + ! ${@bb.utils.contains('PACKAGECONFIG
> <mailto:$%7b@bb.utils.contains('PACKAGECONFIG> ', 'gcrypt', 'true', 
> 'false', d)} ]; then

> +   PACKAGECONFIG_append = "gcrypt"

> + fi

Isn't this too late? (I've not runtime tested this).

If you go the route of modifying PACKAGECONFIG automatically, I'd prefer an
anonymous python funtion doing this at the recipe processing stage.


> -SYSTEMD_PACKAGES = "${PN}-binfmt"

> -SYSTEMD_SERVICE_${PN}-binfmt = "systemd-binfmt.service"

> +#SYSTEMD_PACKAGES = "${PN}-binfmt"

> +#SYSTEMD_SERVICE_${PN}-binfmt = "systemd-binfmt.service"

> +SYSTEMD_PACKAGES = "${@bb.utils.contains('PACKAGECONFIG', 'binfmt',
> '${PN}-binfmt', '', d)}
> <mailto:$%7b@bb.utils.contains('PACKAGECONFIG',%20'binfmt',%20'$%7bPN%
> 7d-bin
> fmt',%20'',%20d)%7d> "

> +SYSTEMD_SERVICE_${PN}-binfmt = "${@bb.utils.contains('PACKAGECONFIG',
> 'binfmt', 'systemd-binfmt.service', '', d)} 
> <mailto:$%7b@bb.utils.contains('PACKAGECONFIG',%20'binfmt',%20'systemd
> -binfm
> t.service',%20'',%20d)%7d> "

This looks good, but should probably be a separate patch.

Cheers,
Anders

--
Anders Darander, Senior System Architect ChargeStorm AB / eStorm AB
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [oe-core][systemd][PATCH] some dependencies in systemd seem not to be taken into account in systemd_229.bb

[Herve Jourdain]

Systemd: - RESOLVED depends on GCRYPT, so GCRYPT should be enabled if
RESOLVED is enabled

 - ${PN}-binfmt should be added to SYSTEMD_PACKAGES only if
binfmt is enabled

Without this patch, build fails when gcrypt is not in PACKAGECONFIG, but
resolved is, or when binfmt is not in PACKAGECONFIG.

 

Signed-off-by: Herve Jourdain <herve.jourd...@neuf.fr
<mailto:herve.jourd...@neuf.fr> >

---

diff --git a/meta/recipes-core/systemd/systemd_229.bb
b/meta/recipes-core/systemd/systemd_229.bb

index 16af0ac..6523e0a 100644

--- a/meta/recipes-core/systemd/systemd_229.bb

+++ b/meta/recipes-core/systemd/systemd_229.bb

@@ -97,11 +97,13 @@ PACKAGECONFIG_remove_libc-musl = "smack"

 

 PACKAGECONFIG[journal-upload] = "--enable-libcurl,--disable-libcurl,curl"

# Sign the journal for anti-tampering

-PACKAGECONFIG[gcrypt] = "--enable-gcrypt,--disable-gcrypt,libgcrypt"

+# RESOLVED depends on GCRYPT, so disable gcrypt only if resolved and gcrypt
are NOT part of PACKAGECONFIG - done in EXTRA_OECONF

+PACKAGECONFIG[gcrypt] = "--enable-gcrypt,,libgcrypt"

PACKAGECONFIG[cryptsetup] =
"--enable-libcryptsetup,--disable-libcryptsetup,cryptsetup"

PACKAGECONFIG[microhttpd] =
"--enable-microhttpd,--disable-microhttpd,libmicrohttpd"

PACKAGECONFIG[elfutils] = "--enable-elfutils,--disable-elfutils,elfutils"

-PACKAGECONFIG[resolved] = "--enable-resolved,--disable-resolved"

+# RESOLVED depends on GCRYPT, so enable gcrypt any time resolved is in
PACKAGECONFIG

+PACKAGECONFIG[resolved] = "--enable-resolved
--enable-gcrypt,--disable-resolved,libgcrypt"

PACKAGECONFIG[networkd] = "--enable-networkd,--disable-networkd"

PACKAGECONFIG[machined] = "--enable-machined,--disable-machined"

PACKAGECONFIG[backlight] = "--enable-backlight,--disable-backlight"

@@ -180,6 +182,9 @@ EXTRA_OECONF = " --with-rootprefix=${rootprefix} \

  --with-firmware-path=/lib/firmware \

  --with-testdir=${PTEST_PATH} \

"

+# RESOLVED depends on GCRYPT, so disable gcrypt only if resolved and gcrypt
are NOT part of PACKAGECONFIG

+EXTRA_OECONF += "${@bb.utils.contains_any('PACKAGECONFIG', 'resolved
gcrypt', '', '--disable-gcrypt', d)}
<mailto:$%7b@bb.utils.contains_any('PACKAGECONFIG',%20'resolved%20gcrypt',%2
0'',%20'--disable-gcrypt',%20d)%7d> "

+

# per the systemd README, define VALGRIND=1 to run under valgrind

CFLAGS .= "${@bb.utils.contains('PACKAGECONFIG', 'valgrind', '
-DVALGRIND=1', '', d)}
<mailto:$%7b@bb.utils.contains('PACKAGECONFIG',%20'valgrind',%20'%20-DVALGRI
ND=1',%20'',%20d)%7d> "

 

@@ -196,6 +201,10 @@ do_configure_prepend() {

  else

 cp -r ${S}/units ${S}/units.pre_sed

  fi

+ if [ ${@bb.utils.contains('PACKAGECONFIG
<mailto:$%7b@bb.utils.contains('PACKAGECONFIG> ', 'resolved', 'true',
'false', d)} -a \

+ ! ${@bb.utils.contains('PACKAGECONFIG
<mailto:$%7b@bb.utils.contains('PACKAGECONFIG> ', 'gcrypt', 'true', 'false',
d)} ]; then

+   PACKAGECONFIG_append = "gcrypt"

+ fi

}

 

 do_install() {

@@ -298,8 +307,10 @@ PACKAGES =+ "\

 ${PN}-extra-utils \

"

 

-SYSTEMD_PACKAGES = "${PN}-binfmt"

-SYSTEMD_SERVICE_${PN}-binfmt = "systemd-binfmt.service"

+#SYSTEMD_PACKAGES = "${PN}-binfmt"

+#SYSTEMD_SERVICE_${PN}-binfmt = "systemd-binfmt.service"

+SYSTEMD_PACKAGES = "${@bb.utils.contains('PACKAGECONFIG', 'binfmt',
'${PN}-binfmt', '', d)}
<mailto:$%7b@bb.utils.contains('PACKAGECONFIG',%20'binfmt',%20'$%7bPN%7d-bin
fmt',%20'',%20d)%7d> "

+SYSTEMD_SERVICE_${PN}-binfmt = "${@bb.utils.contains('PACKAGECONFIG',
'binfmt', 'systemd-binfmt.service', '', d)}
<mailto:$%7b@bb.utils.contains('PACKAGECONFIG',%20'binfmt',%20'systemd-binfm
t.service',%20'',%20d)%7d> "

 

 USERADD_PACKAGES = "${PN}"

USERADD_PARAM_${PN} += "${@bb.utils.contains('PACKAGECONFIG', 'microhttpd',
'--system -d / -M --shell /bin/nologin systemd-journal-gateway;', '', d)}
<mailto:$%7b@bb.utils.contains('PACKAGECONFIG',%20'microhttpd',%20'--system%
20-d%20/%20-M%20--shell%20/bin/nologin%20systemd-journal-gateway;',%20'',%20
d)%7d> "

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core