Patchwork [meta-fsl-arm,01/23] fsl-dynamic-packagearch.bbclass: Dynamically set package architecture

login
register
mail settings
Submitter Otavio Salvador
Date Sept. 23, 2013, 7:55 p.m.
Message ID <1379966158-18179-2-git-send-email-otavio@ossystems.com.br>
Download mbox | patch
Permalink /patch/58575/
State Changes Requested
Delegated to: Otavio Salvador
Headers show

Comments

Otavio Salvador - Sept. 23, 2013, 7:55 p.m.
This allow to easy reuse of binary packages among similar SoCs. The
usual use for this is to share SoC specific packages among different
boards. The class can be used to share GPU packages for i.MX53 boards
(as all them share the AMD GPU) and i.MX6 based boards (as all them
share Vivante GPU).

It inspects the database and identify if the package provides or
depends on one of subarch provided values and if it does, it sets the
PACKAGE_ARCH for MACHINE_SUBARCH value otherwise if it matches in the
machine specific filter, it sets it to MACHINE_ARCH.

Change-Id: Icb0a8060e862c8eeb166c45d1b39c40de07b01d8
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
---
 classes/fsl-dynamic-packagearch.bbclass | 37 +++++++++++++++++++++++++++++++++
 1 file changed, 37 insertions(+)
 create mode 100644 classes/fsl-dynamic-packagearch.bbclass
Eric BENARD - Sept. 23, 2013, 11:04 p.m.
H Otavio,

Le Mon, 23 Sep 2013 16:55:36 -0300,
Otavio Salvador <otavio@ossystems.com.br> a écrit :

> This allow to easy reuse of binary packages among similar SoCs. The
> usual use for this is to share SoC specific packages among different
> boards. The class can be used to share GPU packages for i.MX53 boards
> (as all them share the AMD GPU) and i.MX6 based boards (as all them
> share Vivante GPU).
> 
> It inspects the database and identify if the package provides or
> depends on one of subarch provided values and if it does, it sets the
> PACKAGE_ARCH for MACHINE_SUBARCH value otherwise if it matches in the
> machine specific filter, it sets it to MACHINE_ARCH.
> 
> Change-Id: Icb0a8060e862c8eeb166c45d1b39c40de07b01d8
> Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
> ---
>  classes/fsl-dynamic-packagearch.bbclass | 37 +++++++++++++++++++++++++++++++++
>  1 file changed, 37 insertions(+)
>  create mode 100644 classes/fsl-dynamic-packagearch.bbclass
> 
> diff --git a/classes/fsl-dynamic-packagearch.bbclass b/classes/fsl-dynamic-packagearch.bbclass
> new file mode 100644
> index 0000000..2778885
> --- /dev/null
> +++ b/classes/fsl-dynamic-packagearch.bbclass
> @@ -0,0 +1,37 @@
> +# Automatically set PACKAGE_ARCH for MACHINE_SUBARCH
> +#
> +# This allow to easy reuse of binary packages among similar SoCs. The
> +# usual use for this is to share SoC specific packages among different
> +# boards.
> +#
> +# For example, in meta-fsl-arm, this is used to share GPU packages for
> +# i.MX53 boards (as all them share the AMD GPU) and i.MX6 based boards
> +# (as all them share Vivante GPU).
> +#
> +# To use the class, specify:
> +#
> +# SUBARCH_FILTER = "foo"
> +# MACHINE_ARCH_FILTER = "bar"
> +#
> +# Copyright 2013 (C) O.S. Systems Software LTDA.
> +
> +python __anonymous () {
> +    machine_arch_filter = set((d.getVar("MACHINE_ARCH_FILTER", True) or "").split())
> +    subarch_filter = set((d.getVar("SUBARCH_FILTER", True) or "").split())
> +    if subarch_filter or machine_arch_filter:
> +        provides = set((d.getVar("PROVIDES", True) or "").split())
> +        depends = set((d.getVar("DEPENDS", True) or "").split())
> +        PN = d.getVar("PN", True)
> +
> +        package_arch = None
> +        if list(machine_arch_filter & (provides | depends)):
> +            package_arch = d.getVar("MACHINE_ARCH", True)
> +        elif list(subarch_filter & (provides | depends)):
> +            package_arch = d.getVar("MACHINE_SUBARCH", True)
> +            if not package_arch:
> +                bb.parse.SkipPackage("You must set MACHINE_SUBARCH as SUBARCH_FILTER is set for this SoC.")
> +
> +        if package_arch:
> +            bb.debug(1, "Use '%s' as package archictecture for '%s'" % (package_arch, PN))
> +            d.setVar("PACKAGE_ARCH", package_arch)
> +}

what is the time cost of this dynamic setting vs the static one ?

Eric
Otavio Salvador - Sept. 24, 2013, 1:04 a.m.
On Mon, Sep 23, 2013 at 8:04 PM, Eric Bénard <eric@eukrea.com> wrote:
> H Otavio,
>
> Le Mon, 23 Sep 2013 16:55:36 -0300,
> Otavio Salvador <otavio@ossystems.com.br> a écrit :
>
>> This allow to easy reuse of binary packages among similar SoCs. The
>> usual use for this is to share SoC specific packages among different
>> boards. The class can be used to share GPU packages for i.MX53 boards
>> (as all them share the AMD GPU) and i.MX6 based boards (as all them
>> share Vivante GPU).
>>
>> It inspects the database and identify if the package provides or
>> depends on one of subarch provided values and if it does, it sets the
>> PACKAGE_ARCH for MACHINE_SUBARCH value otherwise if it matches in the
>> machine specific filter, it sets it to MACHINE_ARCH.
>>
>> Change-Id: Icb0a8060e862c8eeb166c45d1b39c40de07b01d8
>> Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
...
> what is the time cost of this dynamic setting vs the static one ?

This reduces the amount of packages we build, for example in case of
core-image-x11 we:

$ ls -l tmp/deploy/rpm/cortexa9hf_vfp_neon_mx6/*.rpm | wc -l
75

So we reuse 75 binaries; these would be build otherwise.

Regarding it being dynamically set or statically set it has following benefits:

* correctness: it is easier to ensure the system behaves as expected
* correctness for non-tracked recipes: new recipes, if depending on
virtual/kernel or GPU has the right architecture choosen, without a
.bbappend file for them
* safeness: non-expert users get a more adequate behavior as the
complexity of choosing the right architecture is simplified for them
* easy maintenance: it is easier for me, as maintainer, to maintain a
code which decides what to do than having hundreds of bbappend files
for it

I hope it justify it enough.

Regards,
Daiane Angolini - Sept. 24, 2013, 11:21 a.m.
On 09/23/2013 10:04 PM, Otavio Salvador wrote:
> On Mon, Sep 23, 2013 at 8:04 PM, Eric Bénard <eric@eukrea.com> wrote:
>> H Otavio,
>>
>> Le Mon, 23 Sep 2013 16:55:36 -0300,
>> Otavio Salvador <otavio@ossystems.com.br> a écrit :
>>
>>> This allow to easy reuse of binary packages among similar SoCs. The
>>> usual use for this is to share SoC specific packages among different
>>> boards. The class can be used to share GPU packages for i.MX53 boards
>>> (as all them share the AMD GPU) and i.MX6 based boards (as all them
>>> share Vivante GPU).
>>>
>>> It inspects the database and identify if the package provides or
>>> depends on one of subarch provided values and if it does, it sets the
>>> PACKAGE_ARCH for MACHINE_SUBARCH value otherwise if it matches in the
>>> machine specific filter, it sets it to MACHINE_ARCH.
>>>
>>> Change-Id: Icb0a8060e862c8eeb166c45d1b39c40de07b01d8
>>> Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
> ...
>> what is the time cost of this dynamic setting vs the static one ?
>
> This reduces the amount of packages we build, for example in case of
> core-image-x11 we:
>
> $ ls -l tmp/deploy/rpm/cortexa9hf_vfp_neon_mx6/*.rpm | wc -l
> 75
>
> So we reuse 75 binaries; these would be build otherwise.
>
> Regarding it being dynamically set or statically set it has following benefits:
>
> * correctness: it is easier to ensure the system behaves as expected
> * correctness for non-tracked recipes: new recipes, if depending on
> virtual/kernel or GPU has the right architecture choosen, without a
> .bbappend file for them
> * safeness: non-expert users get a more adequate behavior as the
> complexity of choosing the right architecture is simplified for them
> * easy maintenance: it is easier for me, as maintainer, to maintain a
> code which decides what to do than having hundreds of bbappend files
> for it
>
> I hope it justify it enough.

Could you, please, explain how this is a upstream trend?
(or, in other words, how this is the same thing people are doing for 
mesa in poky)

Consider to include those justification on commit log.

>
> Regards,
>
Otavio Salvador - Sept. 24, 2013, 11:58 a.m.
On Tue, Sep 24, 2013 at 8:21 AM, Daiane Angolini
<daiane.angolini@freescale.com> wrote:
> On 09/23/2013 10:04 PM, Otavio Salvador wrote:
>>
>> On Mon, Sep 23, 2013 at 8:04 PM, Eric Bénard <eric@eukrea.com> wrote:
>>>
>>> H Otavio,
>>>
>>> Le Mon, 23 Sep 2013 16:55:36 -0300,
>>> Otavio Salvador <otavio@ossystems.com.br> a écrit :
>>>
>>>> This allow to easy reuse of binary packages among similar SoCs. The
>>>> usual use for this is to share SoC specific packages among different
>>>> boards. The class can be used to share GPU packages for i.MX53 boards
>>>> (as all them share the AMD GPU) and i.MX6 based boards (as all them
>>>> share Vivante GPU).
>>>>
>>>> It inspects the database and identify if the package provides or
>>>> depends on one of subarch provided values and if it does, it sets the
>>>> PACKAGE_ARCH for MACHINE_SUBARCH value otherwise if it matches in the
>>>> machine specific filter, it sets it to MACHINE_ARCH.
>>>>
>>>> Change-Id: Icb0a8060e862c8eeb166c45d1b39c40de07b01d8
>>>> Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
>>
>> ...
>>>
>>> what is the time cost of this dynamic setting vs the static one ?
>>
>>
>> This reduces the amount of packages we build, for example in case of
>> core-image-x11 we:
>>
>> $ ls -l tmp/deploy/rpm/cortexa9hf_vfp_neon_mx6/*.rpm | wc -l
>> 75
>>
>> So we reuse 75 binaries; these would be build otherwise.
>>
>> Regarding it being dynamically set or statically set it has following
>> benefits:
>>
>> * correctness: it is easier to ensure the system behaves as expected
>> * correctness for non-tracked recipes: new recipes, if depending on
>> virtual/kernel or GPU has the right architecture choosen, without a
>> .bbappend file for them
>> * safeness: non-expert users get a more adequate behavior as the
>> complexity of choosing the right architecture is simplified for them
>> * easy maintenance: it is easier for me, as maintainer, to maintain a
>> code which decides what to do than having hundreds of bbappend files
>> for it
>>
>> I hope it justify it enough.
>
>
> Could you, please, explain how this is a upstream trend?
> (or, in other words, how this is the same thing people are doing for mesa in
> poky)
>
> Consider to include those justification on commit log.

It is not. This is what people has done for meta-intel to handle GPU
packages better.

The mesa part is another one which has been merged in Poky; now I need
to stop and integrate this in meta-fsl-arm as well.
Eric BENARD - Sept. 24, 2013, 5:02 p.m.
Hi Otavio,

Le Mon, 23 Sep 2013 22:04:41 -0300,
Otavio Salvador <otavio@ossystems.com.br> a écrit :

> On Mon, Sep 23, 2013 at 8:04 PM, Eric Bénard <eric@eukrea.com> wrote:
> > H Otavio,
> >
> > Le Mon, 23 Sep 2013 16:55:36 -0300,
> > Otavio Salvador <otavio@ossystems.com.br> a écrit :
> >
> >> This allow to easy reuse of binary packages among similar SoCs. The
> >> usual use for this is to share SoC specific packages among different
> >> boards. The class can be used to share GPU packages for i.MX53 boards
> >> (as all them share the AMD GPU) and i.MX6 based boards (as all them
> >> share Vivante GPU).
> >>
> >> It inspects the database and identify if the package provides or
> >> depends on one of subarch provided values and if it does, it sets the
> >> PACKAGE_ARCH for MACHINE_SUBARCH value otherwise if it matches in the
> >> machine specific filter, it sets it to MACHINE_ARCH.
> >>
> >> Change-Id: Icb0a8060e862c8eeb166c45d1b39c40de07b01d8
> >> Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
> ...
> > what is the time cost of this dynamic setting vs the static one ?
> 
> This reduces the amount of packages we build, for example in case of
> core-image-x11 we:
> 
> $ ls -l tmp/deploy/rpm/cortexa9hf_vfp_neon_mx6/*.rpm | wc -l
> 75
> 
> So we reuse 75 binaries; these would be build otherwise.
> 
how many recipes are concerned by these 75 packages ?

> Regarding it being dynamically set or statically set it has following benefits:
> 
> * correctness: it is easier to ensure the system behaves as expected
> * correctness for non-tracked recipes: new recipes, if depending on
> virtual/kernel or GPU has the right architecture choosen, without a
> .bbappend file for them
> * safeness: non-expert users get a more adequate behavior as the
> complexity of choosing the right architecture is simplified for them

do you have an example ?

> * easy maintenance: it is easier for me, as maintainer, to maintain a
> code which decides what to do than having hundreds of bbappend files
> for it

but in the present patchset you don't remove any bbappend !

What is the cost on the build/parse time to have this code running
dynamicaly ?

While at it : why does qt4 depends on virtual/kernel ?
That's quite annoying as it seems qt gets rebuilt everytime we make a
change to the kernel.

Eric
Otavio Salvador - Sept. 24, 2013, 5:36 p.m.
On Tue, Sep 24, 2013 at 2:02 PM, Eric Bénard <eric@eukrea.com> wrote:
> Le Mon, 23 Sep 2013 22:04:41 -0300,
> Otavio Salvador <otavio@ossystems.com.br> a écrit :
>
>> On Mon, Sep 23, 2013 at 8:04 PM, Eric Bénard <eric@eukrea.com> wrote:
>> > H Otavio,
>> >
>> > Le Mon, 23 Sep 2013 16:55:36 -0300,
>> > Otavio Salvador <otavio@ossystems.com.br> a écrit :
>> >
>> >> This allow to easy reuse of binary packages among similar SoCs. The
>> >> usual use for this is to share SoC specific packages among different
>> >> boards. The class can be used to share GPU packages for i.MX53 boards
>> >> (as all them share the AMD GPU) and i.MX6 based boards (as all them
>> >> share Vivante GPU).
>> >>
>> >> It inspects the database and identify if the package provides or
>> >> depends on one of subarch provided values and if it does, it sets the
>> >> PACKAGE_ARCH for MACHINE_SUBARCH value otherwise if it matches in the
>> >> machine specific filter, it sets it to MACHINE_ARCH.
>> >>
>> >> Change-Id: Icb0a8060e862c8eeb166c45d1b39c40de07b01d8
>> >> Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
>> ...
>> > what is the time cost of this dynamic setting vs the static one ?
>>
>> This reduces the amount of packages we build, for example in case of
>> core-image-x11 we:
>>
>> $ ls -l tmp/deploy/rpm/cortexa9hf_vfp_neon_mx6/*.rpm | wc -l
>> 75
>>
>> So we reuse 75 binaries; these would be build otherwise.
>
> how many recipes are concerned by these 75 packages ?

gpu-viv, xserver-xorg and more ... (full list for fsl-image-gui - 235
rpm packages - attached).

>> Regarding it being dynamically set or statically set it has following benefits:
>>
>> * correctness: it is easier to ensure the system behaves as expected
>> * correctness for non-tracked recipes: new recipes, if depending on
>> virtual/kernel or GPU has the right architecture choosen, without a
>> .bbappend file for them
>> * safeness: non-expert users get a more adequate behavior as the
>> complexity of choosing the right architecture is simplified for them
>
> do you have an example ?

Sure; for example a weston package (which we don't have a bbappend)
will have the package architecture set to the mx6 subarch as it
depends on the gpu libraries. This also works for customer recipes and
other layers.

Otherwise we'd need to include bbappend files for all those recipes.

>> * easy maintenance: it is easier for me, as maintainer, to maintain a
>> code which decides what to do than having hundreds of bbappend files
>> for it
>
> but in the present patchset you don't remove any bbappend !

Yes and not all where being done right. We had most as machine
specific which where wrong.

> What is the cost on the build/parse time to have this code running
> dynamicaly ?
>
> While at it : why does qt4 depends on virtual/kernel ?
> That's quite annoying as it seems qt gets rebuilt everytime we make a
> change to the kernel.

It uses kernel headers and do syscalls for mxcfb. I am open for an
advise how to make this better.
Eric BENARD - Sept. 24, 2013, 6:16 p.m.
Le Tue, 24 Sep 2013 14:36:21 -0300,
Otavio Salvador <otavio@ossystems.com.br> a écrit :

> On Tue, Sep 24, 2013 at 2:02 PM, Eric Bénard <eric@eukrea.com> wrote:
> > Le Mon, 23 Sep 2013 22:04:41 -0300,
> > Otavio Salvador <otavio@ossystems.com.br> a écrit :
> >
> >> On Mon, Sep 23, 2013 at 8:04 PM, Eric Bénard <eric@eukrea.com> wrote:
> >> > H Otavio,
> >> >
> >> > Le Mon, 23 Sep 2013 16:55:36 -0300,
> >> > Otavio Salvador <otavio@ossystems.com.br> a écrit :
> >> >
> >> >> This allow to easy reuse of binary packages among similar SoCs. The
> >> >> usual use for this is to share SoC specific packages among different
> >> >> boards. The class can be used to share GPU packages for i.MX53 boards
> >> >> (as all them share the AMD GPU) and i.MX6 based boards (as all them
> >> >> share Vivante GPU).
> >> >>
> >> >> It inspects the database and identify if the package provides or
> >> >> depends on one of subarch provided values and if it does, it sets the
> >> >> PACKAGE_ARCH for MACHINE_SUBARCH value otherwise if it matches in the
> >> >> machine specific filter, it sets it to MACHINE_ARCH.
> >> >>
> >> >> Change-Id: Icb0a8060e862c8eeb166c45d1b39c40de07b01d8
> >> >> Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
> >> ...
> >> > what is the time cost of this dynamic setting vs the static one ?
> >>
> >> This reduces the amount of packages we build, for example in case of
> >> core-image-x11 we:
> >>
> >> $ ls -l tmp/deploy/rpm/cortexa9hf_vfp_neon_mx6/*.rpm | wc -l
> >> 75
> >>
> >> So we reuse 75 binaries; these would be build otherwise.
> >
> > how many recipes are concerned by these 75 packages ?
> 
> gpu-viv, xserver-xorg and more ... (full list for fsl-image-gui - 235
> rpm packages - attached).
> 
> >> Regarding it being dynamically set or statically set it has following benefits:
> >>
> >> * correctness: it is easier to ensure the system behaves as expected
> >> * correctness for non-tracked recipes: new recipes, if depending on
> >> virtual/kernel or GPU has the right architecture choosen, without a
> >> .bbappend file for them
> >> * safeness: non-expert users get a more adequate behavior as the
> >> complexity of choosing the right architecture is simplified for them
> >
> > do you have an example ?
> 
> Sure; for example a weston package (which we don't have a bbappend)
> will have the package architecture set to the mx6 subarch as it
> depends on the gpu libraries. This also works for customer recipes and
> other layers.
> 
> Otherwise we'd need to include bbappend files for all those recipes.
> 
> >> * easy maintenance: it is easier for me, as maintainer, to maintain a
> >> code which decides what to do than having hundreds of bbappend files
> >> for it
> >
> > but in the present patchset you don't remove any bbappend !
> 
> Yes and not all where being done right. We had most as machine
> specific which where wrong.
> 
OK that seems fine.

Do you have an idea of the cost on the build/parse time ?

> > What is the cost on the build/parse time to have this code running
> > dynamicaly ?
> >
> > While at it : why does qt4 depends on virtual/kernel ?
> > That's quite annoying as it seems qt gets rebuilt everytime we make a
> > change to the kernel.
> 
> It uses kernel headers and do syscalls for mxcfb. I am open for an
> advise how to make this better.
> 
maybe we could include the linux/mxcfb.h in the patch as these 2
ioctls and the 2 struct have little chance to change ?

Eric
Otavio Salvador - Sept. 24, 2013, 6:26 p.m.
On Tue, Sep 24, 2013 at 3:16 PM, Eric Bénard <eric@eukrea.com> wrote:
> Le Tue, 24 Sep 2013 14:36:21 -0300,
> Otavio Salvador <otavio@ossystems.com.br> a écrit :
...
>> Yes and not all where being done right. We had most as machine
>> specific which where wrong.
>>
> OK that seems fine.
>
> Do you have an idea of the cost on the build/parse time ?

It does slows the parsing a little but build in fact is faster (if you
build more than one mx6 or mx5 based board, for example).

>> > What is the cost on the build/parse time to have this code running
>> > dynamicaly ?
>> >
>> > While at it : why does qt4 depends on virtual/kernel ?
>> > That's quite annoying as it seems qt gets rebuilt everytime we make a
>> > change to the kernel.
>>
>> It uses kernel headers and do syscalls for mxcfb. I am open for an
>> advise how to make this better.
>>
> maybe we could include the linux/mxcfb.h in the patch as these 2
> ioctls and the 2 struct have little chance to change ?

The problem here is it is included in the kernel. Can you submit a bug
in bugzilla about this? So I can use this to collect the information.

We have this in more places, not just Qt, and it'd help a lot so I
will try to think on a generic solution for this.
Eric BENARD - Sept. 24, 2013, 6:40 p.m.
Le Tue, 24 Sep 2013 15:26:22 -0300,
Otavio Salvador <otavio@ossystems.com.br> a écrit :
> >> > What is the cost on the build/parse time to have this code running
> >> > dynamicaly ?
> >> >
> >> > While at it : why does qt4 depends on virtual/kernel ?
> >> > That's quite annoying as it seems qt gets rebuilt everytime we make a
> >> > change to the kernel.
> >>
> >> It uses kernel headers and do syscalls for mxcfb. I am open for an
> >> advise how to make this better.
> >>
> > maybe we could include the linux/mxcfb.h in the patch as these 2
> > ioctls and the 2 struct have little chance to change ?
> 
> The problem here is it is included in the kernel. Can you submit a bug
> in bugzilla about this? So I can use this to collect the information.
> 
> We have this in more places, not just Qt, and it'd help a lot so I
> will try to think on a generic solution for this.
> 
why not having a mxc-header package built from the generic
Freescale kernel so that the software depending on the headers are not
impacted by any kernel change ?

Eric

Patch

diff --git a/classes/fsl-dynamic-packagearch.bbclass b/classes/fsl-dynamic-packagearch.bbclass
new file mode 100644
index 0000000..2778885
--- /dev/null
+++ b/classes/fsl-dynamic-packagearch.bbclass
@@ -0,0 +1,37 @@ 
+# Automatically set PACKAGE_ARCH for MACHINE_SUBARCH
+#
+# This allow to easy reuse of binary packages among similar SoCs. The
+# usual use for this is to share SoC specific packages among different
+# boards.
+#
+# For example, in meta-fsl-arm, this is used to share GPU packages for
+# i.MX53 boards (as all them share the AMD GPU) and i.MX6 based boards
+# (as all them share Vivante GPU).
+#
+# To use the class, specify:
+#
+# SUBARCH_FILTER = "foo"
+# MACHINE_ARCH_FILTER = "bar"
+#
+# Copyright 2013 (C) O.S. Systems Software LTDA.
+
+python __anonymous () {
+    machine_arch_filter = set((d.getVar("MACHINE_ARCH_FILTER", True) or "").split())
+    subarch_filter = set((d.getVar("SUBARCH_FILTER", True) or "").split())
+    if subarch_filter or machine_arch_filter:
+        provides = set((d.getVar("PROVIDES", True) or "").split())
+        depends = set((d.getVar("DEPENDS", True) or "").split())
+        PN = d.getVar("PN", True)
+
+        package_arch = None
+        if list(machine_arch_filter & (provides | depends)):
+            package_arch = d.getVar("MACHINE_ARCH", True)
+        elif list(subarch_filter & (provides | depends)):
+            package_arch = d.getVar("MACHINE_SUBARCH", True)
+            if not package_arch:
+                bb.parse.SkipPackage("You must set MACHINE_SUBARCH as SUBARCH_FILTER is set for this SoC.")
+
+        if package_arch:
+            bb.debug(1, "Use '%s' as package archictecture for '%s'" % (package_arch, PN))
+            d.setVar("PACKAGE_ARCH", package_arch)
+}