[PATCH 0/2] u-boot updates to make it more bbappend friendly

[PATCH 0/2] u-boot updates to make it more bbappend friendly

[Darren Hart]

Tested via build/install/boot of core-image-minimal with the meta-yocto
beagleboard machine config.

The following changes since commit 1607d7b6809eb3f0aa8d09713a4e467a1f4585a2:

  IMAGE_ROOTFS_SIZE: Cleanup machine conf files (2011-05-25 14:07:37 -0700)

are available in the git repository at:
  git://git.pokylinux.org/poky-contrib dvhart/oe/u-boot
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=dvhart/oe/u-boot

Darren Hart (2):
  u-boot: remove UBOOT_MACHINE and COMPATIBLE_MACHINES
  u-boot: rename u-boot_git.bb to u-boot_${PV}.bb

 meta/recipes-bsp/uboot/u-boot.inc                  |    8 +++++++-
 .../uboot/{u-boot_git.bb => u-boot_2011.03.bb}     |   11 ++++++-----
 2 files changed, 13 insertions(+), 6 deletions(-)
 rename meta/recipes-bsp/uboot/{u-boot_git.bb => u-boot_2011.03.bb} (64%)

[pull-oe-uboot 1/2] u-boot: remove UBOOT_MACHINE and COMPATIBLE_MACHINES

[Darren Hart]

oe-core does not define any machines, so it does not make sense to
add machine specific information in the oe-core u-boot recipe and
infrastructure. Also note that COMPATIBLE_MACHINES is not easily extended due to
its regex syntax: "(machine_a|machine_b)", making it difficult to extend the
u-boot recipe in bbappend files without resorting to machine specific overrides.

Remove COMPATIBLE_MACHINES and the default UBOOT_MACHINE from the recipe and
insert some anonymous python into u-boot.inc to raise SkipPackage if
UBOOT_MACHINE is not set (this ensures 'world' still works for machines that
can't build u-boot).

UBOOT_MACHINE must now be specified in each machine config that requires u-boot.
This is an improvement over requiring machine specific overrides in every BSP
layer's u-boot_git.bbappend file. For example, a beagleboard machine config
currently contains:

UBOOT_ENTRYPOINT = "0x80008000"
UBOOT_LOADADDRESS = "0x80008000"

With this change, it must now contain:

UBOOT_MACHINE = "omap3_beagle_config"
UBOOT_ENTRYPOINT = "0x80008000"
UBOOT_LOADADDRESS = "0x80008000"

So long as the SRC_URI in the base recipe can build a working u-boot for a given
machine, there is no need to create a u-boot_git.bbappend file. If additional
patches are deemed necessary, a BSP layer creates a u-boot_git.bbappend file and
extends the SRC_URI to include general or machine specific backports.

Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Cc: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: Koen Kooi <koen@dominion.thruhere.net>
Cc: Jason Kridner <jkridner@beagleboard.org>
---
 meta/recipes-bsp/uboot/u-boot.inc    |    8 +++++++-
 meta/recipes-bsp/uboot/u-boot_git.bb |   11 ++++++-----
 2 files changed, 13 insertions(+), 6 deletions(-)

diff --git a/meta/recipes-bsp/uboot/u-boot.inc b/meta/recipes-bsp/uboot/u-boot.inc
index 058e3ba..a54cf24 100644
--- a/meta/recipes-bsp/uboot/u-boot.inc
+++ b/meta/recipes-bsp/uboot/u-boot.inc
@@ -11,7 +11,13 @@ PARALLEL_MAKE=""
 # GCC 4.5.1 builds unusable binaries using -Os, remove it from OPTFLAGS
 EXTRA_OEMAKE = "CROSS_COMPILE=${TARGET_PREFIX} OPTFLAGS='-O2'"
 
-UBOOT_MACHINE ?= "${MACHINE}_config"
+python () {
+	if not bb.data.getVar('UBOOT_MACHINE', d, 1):
+		bb.debug("To build %s, see u-boot_git.bb for instructions on \
+			  setting up your machine config" % pn)
+		raise bb.parse.SkipPackage("because UBOOT_MACHINE is not set")
+}
+
 UBOOT_IMAGE ?= "u-boot-${MACHINE}-${PV}-${PR}.bin"
 UBOOT_SYMLINK ?= "u-boot-${MACHINE}.bin"
 UBOOT_MAKE_TARGET ?= "all"
diff --git a/meta/recipes-bsp/uboot/u-boot_git.bb b/meta/recipes-bsp/uboot/u-boot_git.bb
index 4c8f5df..0fbb9ba 100644
--- a/meta/recipes-bsp/uboot/u-boot_git.bb
+++ b/meta/recipes-bsp/uboot/u-boot_git.bb
@@ -1,5 +1,11 @@
 require u-boot.inc
 
+# To build u-boot for your machine, provide the following lines in your machine
+# config, replacing the assignments as appropriate for your machine.
+# UBOOT_MACHINE = "omap3_beagle_config"
+# UBOOT_ENTRYPOINT = "0x80008000"
+# UBOOT_LOADADDRESS = "0x80008000"
+
 LICENSE = "GPLv2+"
 LIC_FILES_CHKSUM = "file://COPYING;md5=1707d6db1d42237583f50183a5651ecb \
                     file://README;beginline=1;endline=22;md5=3a00ef51d3fc96e9d6c1bc4708ccd3b5"
@@ -12,11 +18,6 @@ PR="r3"
 
 SRC_URI = "git://git.denx.de/u-boot.git;branch=master;protocol=git"
 
-UBOOT_MACHINE_beagleboard = "omap3_beagle_config"
-UBOOT_MACHINE_overo = "omap3_overo_config"
-
 S = "${WORKDIR}/git"
 
 PACKAGE_ARCH = "${MACHINE_ARCH}"
-
-COMPATIBLE_MACHINE = "(beagleboard|overo)"
-- 
1.7.1

[pull-oe-uboot 2/2] u-boot: rename u-boot_git.bb to u-boot_${PV}.bb

[Darren Hart]

In order to facilitate reuse of the oe-core u-boot recipe, there needs to be
some assurance that the oe-core version won't change without a clear indicator
to people extending it.

By renaming the recipe to include its version string instead of "git", BSP
layers can extend a specific base version of u-boot, ie.
u-boot_2011.03.bbappend. When 2011.06 becomes available, we can create that file
without instantly breaking all the BSPs depending on oe-core version of the
recipe.

As a matter of policy I would recommend we not carry more than 2 versioned
u-boot recipess at any given time. This will provide BSP layers time to migrate
to the newer version, without cluttering oe-core with numerous stale versions of
u-boot. We may decide later to resurrect u-boot_git.bb as an AUTOREV recipe to
faciliate upstream development on u-boot in the oe environment.

Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Cc: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: Koen Kooi <koen@dominion.thruhere.net>
Cc: Jason Kridner <jkridner@beagleboard.org>
---
 .../uboot/{u-boot_git.bb => u-boot_2011.03.bb}     |    0
 1 files changed, 0 insertions(+), 0 deletions(-)
 rename meta/recipes-bsp/uboot/{u-boot_git.bb => u-boot_2011.03.bb} (100%)

diff --git a/meta/recipes-bsp/uboot/u-boot_git.bb b/meta/recipes-bsp/uboot/u-boot_2011.03.bb
similarity index 100%
rename from meta/recipes-bsp/uboot/u-boot_git.bb
rename to meta/recipes-bsp/uboot/u-boot_2011.03.bb
-- 
1.7.1

Re: [pull-oe-uboot 1/2] u-boot: remove UBOOT_MACHINE and COMPATIBLE_MACHINES

[Jason Kridner]

I think this is a good change. One comment below...

On May 26, 2011, at 12:02 AM, Darren Hart <dvhart@linux.intel.com> wrote:

> oe-core does not define any machines, so it does not make sense to
> add machine specific information in the oe-core u-boot recipe and
> infrastructure. Also note that COMPATIBLE_MACHINES is not easily extended due to
> its regex syntax: "(machine_a|machine_b)", making it difficult to extend the
> u-boot recipe in bbappend files without resorting to machine specific overrides.
> 
> Remove COMPATIBLE_MACHINES and the default UBOOT_MACHINE from the recipe and
> insert some anonymous python into u-boot.inc to raise SkipPackage if
> UBOOT_MACHINE is not set (this ensures 'world' still works for machines that
> can't build u-boot).
> 
> UBOOT_MACHINE must now be specified in each machine config that requires u-boot.
> This is an improvement over requiring machine specific overrides in every BSP
> layer's u-boot_git.bbappend file. For example, a beagleboard machine config
> currently contains:
> 
> UBOOT_ENTRYPOINT = "0x80008000"
> UBOOT_LOADADDRESS = "0x80008000"
> 
> With this change, it must now contain:
> 
> UBOOT_MACHINE = "omap3_beagle_config"
> UBOOT_ENTRYPOINT = "0x80008000"
> UBOOT_LOADADDRESS = "0x80008000"
> 
> So long as the SRC_URI in the base recipe can build a working u-boot for a given
> machine, there is no need to create a u-boot_git.bbappend file. If additional
> patches are deemed necessary, a BSP layer creates a u-boot_git.bbappend file and
> extends the SRC_URI to include general or machine specific backports.
> 
> Signed-off-by: Darren Hart <dvhart@linux.intel.com>
> Cc: Richard Purdie <richard.purdie@linuxfoundation.org>
> Cc: Koen Kooi <koen@dominion.thruhere.net>
> Cc: Jason Kridner <jkridner@beagleboard.org>
> ---
> meta/recipes-bsp/uboot/u-boot.inc    |    8 +++++++-
> meta/recipes-bsp/uboot/u-boot_git.bb |   11 ++++++-----
> 2 files changed, 13 insertions(+), 6 deletions(-)
> 
> diff --git a/meta/recipes-bsp/uboot/u-boot.inc b/meta/recipes-bsp/uboot/u-boot.inc
> index 058e3ba..a54cf24 100644
> --- a/meta/recipes-bsp/uboot/u-boot.inc
> +++ b/meta/recipes-bsp/uboot/u-boot.inc
> @@ -11,7 +11,13 @@ PARALLEL_MAKE=""
> # GCC 4.5.1 builds unusable binaries using -Os, remove it from OPTFLAGS
> EXTRA_OEMAKE = "CROSS_COMPILE=${TARGET_PREFIX} OPTFLAGS='-O2'"
> 
> -UBOOT_MACHINE ?= "${MACHINE}_config"
> +python () {
> +    if not bb.data.getVar('UBOOT_MACHINE', d, 1):
> +        bb.debug("To build %s, see u-boot_git.bb for instructions on \

If this file was renamed, don't you also want to update this printout?

> +              setting up your machine config" % pn)
> +        raise bb.parse.SkipPackage("because UBOOT_MACHINE is not set")
> +}
> +
> UBOOT_IMAGE ?= "u-boot-${MACHINE}-${PV}-${PR}.bin"
> UBOOT_SYMLINK ?= "u-boot-${MACHINE}.bin"
> UBOOT_MAKE_TARGET ?= "all"
> diff --git a/meta/recipes-bsp/uboot/u-boot_git.bb b/meta/recipes-bsp/uboot/u-boot_git.bb
> index 4c8f5df..0fbb9ba 100644
> --- a/meta/recipes-bsp/uboot/u-boot_git.bb
> +++ b/meta/recipes-bsp/uboot/u-boot_git.bb
> @@ -1,5 +1,11 @@
> require u-boot.inc
> 
> +# To build u-boot for your machine, provide the following lines in your machine
> +# config, replacing the assignments as appropriate for your machine.
> +# UBOOT_MACHINE = "omap3_beagle_config"
> +# UBOOT_ENTRYPOINT = "0x80008000"
> +# UBOOT_LOADADDRESS = "0x80008000"
> +
> LICENSE = "GPLv2+"
> LIC_FILES_CHKSUM = "file://COPYING;md5=1707d6db1d42237583f50183a5651ecb \
>                     file://README;beginline=1;endline=22;md5=3a00ef51d3fc96e9d6c1bc4708ccd3b5"
> @@ -12,11 +18,6 @@ PR="r3"
> 
> SRC_URI = "git://git.denx.de/u-boot.git;branch=master;protocol=git"
> 
> -UBOOT_MACHINE_beagleboard = "omap3_beagle_config"
> -UBOOT_MACHINE_overo = "omap3_overo_config"
> -
> S = "${WORKDIR}/git"
> 
> PACKAGE_ARCH = "${MACHINE_ARCH}"
> -
> -COMPATIBLE_MACHINE = "(beagleboard|overo)"
> -- 
> 1.7.1
> 

Re: [pull-oe-uboot 2/2] u-boot: rename u-boot_git.bb to u-boot_${PV}.bb

[Jason Kridner]

On May 26, 2011, at 12:02 AM, Darren Hart <dvhart@linux.intel.com> wrote:

> In order to facilitate reuse of the oe-core u-boot recipe, there needs to be
> some assurance that the oe-core version won't change without a clear indicator
> to people extending it.
> 
> By renaming the recipe to include its version string instead of "git", BSP
> layers can extend a specific base version of u-boot, ie.
> u-boot_2011.03.bbappend. When 2011.06 becomes available, we can create that file
> without instantly breaking all the BSPs depending on oe-core version of the
> recipe.
> 
> As a matter of policy I would recommend we not carry more than 2 versioned
> u-boot recipess at any given time. This will provide BSP layers time to migrate
> to the newer version, without cluttering oe-core with numerous stale versions of
> u-boot. We may decide later to resurrect u-boot_git.bb as an AUTOREV recipe to
> faciliate upstream development on u-boot in the oe environment.

This sounds especially useful for automated testing of upstream. I'd be interested in setting up a public daily build and test report in such a configuration. Let me know if it would be redundant. 

> 
> Signed-off-by: Darren Hart <dvhart@linux.intel.com>
> Cc: Richard Purdie <richard.purdie@linuxfoundation.org>
> Cc: Koen Kooi <koen@dominion.thruhere.net>
> Cc: Jason Kridner <jkridner@beagleboard.org>
> ---
> .../uboot/{u-boot_git.bb => u-boot_2011.03.bb}     |    0
> 1 files changed, 0 insertions(+), 0 deletions(-)
> rename meta/recipes-bsp/uboot/{u-boot_git.bb => u-boot_2011.03.bb} (100%)
> 
> diff --git a/meta/recipes-bsp/uboot/u-boot_git.bb b/meta/recipes-bsp/uboot/u-boot_2011.03.bb
> similarity index 100%
> rename from meta/recipes-bsp/uboot/u-boot_git.bb
> rename to meta/recipes-bsp/uboot/u-boot_2011.03.bb
> -- 
> 1.7.1
> 

Re: [pull-oe-uboot 1/2] u-boot: remove UBOOT_MACHINE and COMPATIBLE_MACHINES

[Phil Blundell]

On Wed, 2011-05-25 at 22:02 -0700, Darren Hart wrote:
> COMPATIBLE_MACHINES is not easily extended due to
> its regex syntax: "(machine_a|machine_b)", making it difficult to extend the
> u-boot recipe in bbappend files without resorting to machine specific overrides.

Not that I have an objection to your patch, but I think this remark
about COMPATIBLE_MACHINE is wrong.  AFAIK, you can disregard the
parenthesis and just splice extra alternates on the end, viz:

COMPATIBLE_MACHINE_append = "|mymachine"

so there oughtn't to be any reason, in general, for .bbappends to have a
hard time extending that field.

p.

Re: [pull-oe-uboot 1/2] u-boot: remove UBOOT_MACHINE and COMPATIBLE_MACHINES

[Darren Hart]

On 05/26/2011 12:47 AM, Jason Kridner wrote:
> I think this is a good change. One comment below...
> 
> On May 26, 2011, at 12:02 AM, Darren Hart <dvhart@linux.intel.com> wrote:
> 
>> oe-core does not define any machines, so it does not make sense to
>> add machine specific information in the oe-core u-boot recipe and
>> infrastructure. Also note that COMPATIBLE_MACHINES is not easily extended due to
>> its regex syntax: "(machine_a|machine_b)", making it difficult to extend the
>> u-boot recipe in bbappend files without resorting to machine specific overrides.
>>
>> Remove COMPATIBLE_MACHINES and the default UBOOT_MACHINE from the recipe and
>> insert some anonymous python into u-boot.inc to raise SkipPackage if
>> UBOOT_MACHINE is not set (this ensures 'world' still works for machines that
>> can't build u-boot).
>>
>> UBOOT_MACHINE must now be specified in each machine config that requires u-boot.
>> This is an improvement over requiring machine specific overrides in every BSP
>> layer's u-boot_git.bbappend file. For example, a beagleboard machine config
>> currently contains:
>>
>> UBOOT_ENTRYPOINT = "0x80008000"
>> UBOOT_LOADADDRESS = "0x80008000"
>>
>> With this change, it must now contain:
>>
>> UBOOT_MACHINE = "omap3_beagle_config"
>> UBOOT_ENTRYPOINT = "0x80008000"
>> UBOOT_LOADADDRESS = "0x80008000"
>>
>> So long as the SRC_URI in the base recipe can build a working u-boot for a given
>> machine, there is no need to create a u-boot_git.bbappend file. If additional
>> patches are deemed necessary, a BSP layer creates a u-boot_git.bbappend file and
>> extends the SRC_URI to include general or machine specific backports.
>>
>> Signed-off-by: Darren Hart <dvhart@linux.intel.com>
>> Cc: Richard Purdie <richard.purdie@linuxfoundation.org>
>> Cc: Koen Kooi <koen@dominion.thruhere.net>
>> Cc: Jason Kridner <jkridner@beagleboard.org>
>> ---
>> meta/recipes-bsp/uboot/u-boot.inc    |    8 +++++++-
>> meta/recipes-bsp/uboot/u-boot_git.bb |   11 ++++++-----
>> 2 files changed, 13 insertions(+), 6 deletions(-)
>>
>> diff --git a/meta/recipes-bsp/uboot/u-boot.inc b/meta/recipes-bsp/uboot/u-boot.inc
>> index 058e3ba..a54cf24 100644
>> --- a/meta/recipes-bsp/uboot/u-boot.inc
>> +++ b/meta/recipes-bsp/uboot/u-boot.inc
>> @@ -11,7 +11,13 @@ PARALLEL_MAKE=""
>> # GCC 4.5.1 builds unusable binaries using -Os, remove it from OPTFLAGS
>> EXTRA_OEMAKE = "CROSS_COMPILE=${TARGET_PREFIX} OPTFLAGS='-O2'"
>>
>> -UBOOT_MACHINE ?= "${MACHINE}_config"
>> +python () {
>> +    if not bb.data.getVar('UBOOT_MACHINE', d, 1):
>> +        bb.debug("To build %s, see u-boot_git.bb for instructions on \
> 
> If this file was renamed, don't you also want to update this printout?

Oh, tricky. This should be addressed in the 2/2 patch.... but what to
name it too. Do I have access to the filename of the recipe that
included this one, causing this code to run? Perhaps I should move the
instructions into this .inc file since the u-boot_*.bb recipe name will
change over time if my 2/2 patch is accepted?

Thoughts?

--
Darren

> 
>> +              setting up your machine config" % pn)
>> +        raise bb.parse.SkipPackage("because UBOOT_MACHINE is not set")
>> +}
>> +
>> UBOOT_IMAGE ?= "u-boot-${MACHINE}-${PV}-${PR}.bin"
>> UBOOT_SYMLINK ?= "u-boot-${MACHINE}.bin"
>> UBOOT_MAKE_TARGET ?= "all"
>> diff --git a/meta/recipes-bsp/uboot/u-boot_git.bb b/meta/recipes-bsp/uboot/u-boot_git.bb
>> index 4c8f5df..0fbb9ba 100644
>> --- a/meta/recipes-bsp/uboot/u-boot_git.bb
>> +++ b/meta/recipes-bsp/uboot/u-boot_git.bb
>> @@ -1,5 +1,11 @@
>> require u-boot.inc
>>
>> +# To build u-boot for your machine, provide the following lines in your machine
>> +# config, replacing the assignments as appropriate for your machine.
>> +# UBOOT_MACHINE = "omap3_beagle_config"
>> +# UBOOT_ENTRYPOINT = "0x80008000"
>> +# UBOOT_LOADADDRESS = "0x80008000"
>> +
>> LICENSE = "GPLv2+"
>> LIC_FILES_CHKSUM = "file://COPYING;md5=1707d6db1d42237583f50183a5651ecb \
>>                     file://README;beginline=1;endline=22;md5=3a00ef51d3fc96e9d6c1bc4708ccd3b5"
>> @@ -12,11 +18,6 @@ PR="r3"
>>
>> SRC_URI = "git://git.denx.de/u-boot.git;branch=master;protocol=git"
>>
>> -UBOOT_MACHINE_beagleboard = "omap3_beagle_config"
>> -UBOOT_MACHINE_overo = "omap3_overo_config"
>> -
>> S = "${WORKDIR}/git"
>>
>> PACKAGE_ARCH = "${MACHINE_ARCH}"
>> -
>> -COMPATIBLE_MACHINE = "(beagleboard|overo)"
>> -- 
>> 1.7.1
>>

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel

Re: [pull-oe-uboot 2/2] u-boot: rename u-boot_git.bb to u-boot_${PV}.bb

[Darren Hart]

On 05/26/2011 12:58 AM, Jason Kridner wrote:
> On May 26, 2011, at 12:02 AM, Darren Hart <dvhart@linux.intel.com>
> wrote:
> 
>> In order to facilitate reuse of the oe-core u-boot recipe, there
>> needs to be some assurance that the oe-core version won't change
>> without a clear indicator to people extending it.
>> 
>> By renaming the recipe to include its version string instead of
>> "git", BSP layers can extend a specific base version of u-boot,
>> ie. u-boot_2011.03.bbappend. When 2011.06 becomes available, we can
>> create that file without instantly breaking all the BSPs depending
>> on oe-core version of the recipe.
>> 
>> As a matter of policy I would recommend we not carry more than 2
>> versioned u-boot recipess at any given time. This will provide BSP
>> layers time to migrate to the newer version, without cluttering
>> oe-core with numerous stale versions of u-boot. We may decide later
>> to resurrect u-boot_git.bb as an AUTOREV recipe to faciliate
>> upstream development on u-boot in the oe environment.
> 
> This sounds especially useful for automated testing of upstream. I'd
> be interested in setting up a public daily build and test report in
> such a configuration. Let me know if it would be redundant.

That is the sort of thing this caters to, yes. And no, I don't think
your testing in this way would be redundant - at least not with respect
to anything I'm doing.

--
Darren

> 
>> 
>> Signed-off-by: Darren Hart <dvhart@linux.intel.com> Cc: Richard
>> Purdie <richard.purdie@linuxfoundation.org> Cc: Koen Kooi
>> <koen@dominion.thruhere.net> Cc: Jason Kridner
>> <jkridner@beagleboard.org> --- .../uboot/{u-boot_git.bb =>
>> u-boot_2011.03.bb}     |    0 1 files changed, 0 insertions(+), 0
>> deletions(-) rename meta/recipes-bsp/uboot/{u-boot_git.bb =>
>> u-boot_2011.03.bb} (100%)
>> 
>> diff --git a/meta/recipes-bsp/uboot/u-boot_git.bb
>> b/meta/recipes-bsp/uboot/u-boot_2011.03.bb similarity index 100% 
>> rename from meta/recipes-bsp/uboot/u-boot_git.bb rename to
>> meta/recipes-bsp/uboot/u-boot_2011.03.bb -- 1.7.1
>> 
> 
> _______________________________________________ Openembedded-core
> mailing list Openembedded-core@lists.openembedded.org 
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

--
> 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel

Re: [pull-oe-uboot 1/2] u-boot: remove UBOOT_MACHINE and COMPATIBLE_MACHINES

[Chris Larson]

On Thu, May 26, 2011 at 6:50 AM, Darren Hart <dvhart@linux.intel.com> wrote:
>>> -UBOOT_MACHINE ?= "${MACHINE}_config"
>>> +python () {
>>> +    if not bb.data.getVar('UBOOT_MACHINE', d, 1):
>>> +        bb.debug("To build %s, see u-boot_git.bb for instructions on \
>>
>> If this file was renamed, don't you also want to update this printout?
>
> Oh, tricky. This should be addressed in the 2/2 patch.... but what to
> name it too. Do I have access to the filename of the recipe that
> included this one, causing this code to run? Perhaps I should move the
> instructions into this .inc file since the u-boot_*.bb recipe name will
> change over time if my 2/2 patch is accepted?
>

FILE should refer to the recipe, if it's not evaluated until the end
of the parse process, so I expect you could just use it in the
anonymous python snippet. Would definitely want to confirm that though
:)
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

Re: [pull-oe-uboot 1/2] u-boot: remove UBOOT_MACHINE and COMPATIBLE_MACHINES

[Richard Purdie]

On Thu, 2011-05-26 at 11:50 +0100, Phil Blundell wrote:
> On Wed, 2011-05-25 at 22:02 -0700, Darren Hart wrote:
> > COMPATIBLE_MACHINES is not easily extended due to
> > its regex syntax: "(machine_a|machine_b)", making it difficult to extend the
> > u-boot recipe in bbappend files without resorting to machine specific overrides.
> 
> Not that I have an objection to your patch, but I think this remark
> about COMPATIBLE_MACHINE is wrong.  AFAIK, you can disregard the
> parenthesis and just splice extra alternates on the end, viz:
> 
> COMPATIBLE_MACHINE_append = "|mymachine"
>
> so there oughtn't to be any reason, in general, for .bbappends to have a
> hard time extending that field.

u-boot in OE-Core would need something like COMPATIBLE_MACHINE = ""
which makes this harder.

Its usually seem to work out easier to just do:

COMPATIBLE_MACHINE_mymachine = "mymachine"

which avoids several potential issues.

Cheers,

Richard

Re: [pull-oe-uboot 1/2] u-boot: remove UBOOT_MACHINE and COMPATIBLE_MACHINES

[Phil Blundell]

On Thu, 2011-05-26 at 15:37 +0100, Richard Purdie wrote:
> u-boot in OE-Core would need something like COMPATIBLE_MACHINE = ""
> which makes this harder.

Yes, true.  I don't think that's a major problem, though, you just need
a regex that won't match anything.  Something like:

COMPATIBLE_MACHINE = "(?!^)"

would probably do what you want, though it does have the admitted
downside of looking rather like line noise.  

If this is going to be a common problem then it might be worth hacking
base.bbclass about a bit to provide a more convenient way to do it.  The
UBOOT_MACHINE thing is fine as a solution for u-boot since that variable
needs to exist anyway, but I wouldn't have been keen on introducing it
just to control the recipe acceptability.

> Its usually seem to work out easier to just do:
> 
> COMPATIBLE_MACHINE_mymachine = "mymachine"
> 
> which avoids several potential issues.

Yeah, that would work fine too: you could even save a bit of typing by
just using "" as the rvalue since an empty C_M will (somewhat
counterintuitively) permit everything.  I got the impression from
Darren's original phraseology of "resorting to machine-specific
overrides" that he didn't like it much, though.

p.

Re: [pull-oe-uboot 1/2] u-boot: remove UBOOT_MACHINE and COMPATIBLE_MACHINES

[Darren Hart]

On 05/26/2011 09:18 AM, Phil Blundell wrote:
> On Thu, 2011-05-26 at 15:37 +0100, Richard Purdie wrote:
>> u-boot in OE-Core would need something like COMPATIBLE_MACHINE = ""
>> which makes this harder.
> 
> Yes, true.  I don't think that's a major problem, though, you just need
> a regex that won't match anything.  Something like:
> 
> COMPATIBLE_MACHINE = "(?!^)"
> 
> would probably do what you want, though it does have the admitted
> downside of looking rather like line noise.  
> 
> If this is going to be a common problem then it might be worth hacking
> base.bbclass about a bit to provide a more convenient way to do it.  The
> UBOOT_MACHINE thing is fine as a solution for u-boot since that variable
> needs to exist anyway, but I wouldn't have been keen on introducing it
> just to control the recipe acceptability.
> 
>> Its usually seem to work out easier to just do:
>>
>> COMPATIBLE_MACHINE_mymachine = "mymachine"
>>
>> which avoids several potential issues.
> 
> Yeah, that would work fine too: you could even save a bit of typing by
> just using "" as the rvalue since an empty C_M will (somewhat
> counterintuitively) permit everything.

Really?... <looks into base.bbclass and data_smart.py> Huh, you are
correct. I wouldn't have expected that.

>  I got the impression from
> Darren's original phraseology of "resorting to machine-specific
> overrides" that he didn't like it much, though.

Right, it just starts to look rather ugly in the recipe, especially for
BSPs supporting more than just a couple of machines. I also think that
having to use machine overrides is an indicator that the mechanism is
not working for the purpose it was designed for.

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel

Re: [pull-oe-uboot 1/2] u-boot: remove UBOOT_MACHINE and COMPATIBLE_MACHINES

[Phil Blundell]

On Thu, 2011-05-26 at 10:46 -0700, Darren Hart wrote:
> Right, it just starts to look rather ugly in the recipe, especially for
> BSPs supporting more than just a couple of machines. I also think that
> having to use machine overrides is an indicator that the mechanism is
> not working for the purpose it was designed for.

Yes, agreed.  But the point I was making in my first mail is that you
don't actually need to use machine overrides at all; just appending to
COMPATIBLE_MACHINE will work fine.

So, to be clear, in the core u-boot.bb you could have:

# These machines are supported by upstream u-boot
COMPATIBLE_MACHINE = "(beagleboard$|at91sam9260ek$)"

and then, in some putative meta-dec overlay, you could have a
u_boot.bbappend which does:

# This patch adds PDP-11 support to u-boot
SRC_URI += "pdp11.patch"
COMPATIBLE_MACHINE .= "|pdp11$"

and everything ought to work out just fine.  The only bit that is
slightly non-obvious is what to do if you don't want the core version of
u-boot to admit any MACHINEs at all but, as I mentioned to Richard, you
can achieve that by setting

COMPATIBLE_MACHINE = "(?!^)"

or something similar.

p.

Re: [pull-oe-uboot 1/2] u-boot: remove UBOOT_MACHINE and COMPATIBLE_MACHINES

[Darren Hart]

On 05/27/2011 07:04 AM, Phil Blundell wrote:
> On Thu, 2011-05-26 at 10:46 -0700, Darren Hart wrote:
>> Right, it just starts to look rather ugly in the recipe, especially for
>> BSPs supporting more than just a couple of machines. I also think that
>> having to use machine overrides is an indicator that the mechanism is
>> not working for the purpose it was designed for.
> 
> Yes, agreed.  But the point I was making in my first mail is that you
> don't actually need to use machine overrides at all; just appending to
> COMPATIBLE_MACHINE will work fine.
> 
> So, to be clear, in the core u-boot.bb you could have:
> 
> # These machines are supported by upstream u-boot
> COMPATIBLE_MACHINE = "(beagleboard$|at91sam9260ek$)"
> 
> and then, in some putative meta-dec overlay, you could have a
> u_boot.bbappend which does:
> 
> # This patch adds PDP-11 support to u-boot
> SRC_URI += "pdp11.patch"
> COMPATIBLE_MACHINE .= "|pdp11$"

Ah good point, and if you have multiple machines:
COMPATIBLE_MACHINE .= "|(pdp11$|pdp11/20$)"

In fact... why are the parens used at all?

I think we would likely get a lot of bug reports on the lists if we used
this approach, using regex's here seems rather non-intuitive to me (and
I'm rather fond of regexes).

> 
> and everything ought to work out just fine.  The only bit that is
> slightly non-obvious is what to do if you don't want the core version of
> u-boot to admit any MACHINEs at all but, as I mentioned to Richard, you
> can achieve that by setting
> 
> COMPATIBLE_MACHINE = "(?!^)"
> 
> or something similar.


All this said, do you have any objection to using UBOOT_MACHINE in the
machine.conf with the anon python check for it in the inc file? I think
you said not, but I want to be sure.

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel

Re: [pull-oe-uboot 1/2] u-boot: remove UBOOT_MACHINE and COMPATIBLE_MACHINES

[Phil Blundell]

On Fri, 2011-05-27 at 08:06 -0700, Darren Hart wrote:
> In fact... why are the parens used at all?

No good reason.  I would guess that we started off with something like

COMPATIBLE_MACHINE = "pdp11/(23|34)"

in a recipe, and that got somehow generalised to wrapping all the
alternatives in parens even where not required.  I imagine most/all of
those parens can just be removed.

> All this said, do you have any objection to using UBOOT_MACHINE in the
> machine.conf with the anon python check for it in the inc file? I think
> you said not, but I want to be sure.

No objection, I'm quite happy with the UBOOT_MACHINE thing here.

p.