Skip to contentSkip to conversation

u-boot updates to make it more bbappend friendly

PATCH Superseded Darren Hart 5 participants 15 messages May 26, 2011 – May 27, 2011

v1 of 2 Superseded Latest is v2 →

lore
Share & tools
lore
#0 lore raw

cover u-boot updates to make it more bbappend friendly

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%)
#1 lore raw

PATCH 1/2 u-boot: remove UBOOT_MACHINE and COMPATIBLE_MACHINES

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.

Cc Richard Purdie <[email protected]>
Cc Koen Kooi <[email protected]>
Cc Jason Kridner <[email protected]>
---
 meta/recipes-bsp/uboot/u-boot.inc    |    8 +++++++-
 meta/recipes-bsp/uboot/u-boot_git.bb |   11 ++++++-----
 2 files changed, 13 insertions(+), 6 deletions(-)
meta/recipes-bsp/uboot/u-boot.inc +7 -1
index 058e3ba..a54cf24 100644
@@ -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"
meta/recipes-bsp/uboot/u-boot_git.bb +6 -5
index 4c8f5df..0fbb9ba 100644
@@ -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)"
Signature · 1 line
1.7.1
#2 lore raw

PATCH 2/2 u-boot: rename u-boot_git.bb to u-boot_${PV}.bb

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.

Cc Richard Purdie <[email protected]>
Cc Koen Kooi <[email protected]>
Cc Jason Kridner <[email protected]>
---
 .../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%)
meta/recipes-bsp/uboot/u-boot_2011.03.bb renamed from meta/recipes-bsp/uboot/u-boot_git.bb +0 -0
similarity index 100%
rename from meta/recipes-bsp/uboot/u-boot_git.bb
rename to meta/recipes-bsp/uboot/u-boot_2011.03.bb
Signature · 1 line
1.7.1
#3 lore raw

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

Quoted 10 lines · 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.

Quoted 5 lines

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.

Quoted 17 lines
Cc Richard Purdie <[email protected]>
Cc Koen Kooi <[email protected]>
Cc Jason Kridner <[email protected]>

---
.../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%)

meta/recipes-bsp/uboot/u-boot_2011.03.bb renamed from meta/recipes-bsp/uboot/u-boot_git.bb +0 -0
similarity index 100%
rename from meta/recipes-bsp/uboot/u-boot_git.bb
rename to meta/recipes-bsp/uboot/u-boot_2011.03.bb
Signature · 1 line
1.7.1
#4 lore raw

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

Quoted 20 lines · Jason Kridner
Quoted 10 lines · 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.

Quoted 6 lines

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.

Quoted 3 lines

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

Quoted 10 lines
Quoted 10 lines

Purdie <[email protected]> Cc: Koen Kooi <[email protected]> Cc: Jason Kridner <[email protected]> --- .../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%)

Quoted 9 lines
Quoted 5 lines
(quoted diff) +0 -0

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 [email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

--

Quoted 1 line

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

#5 lore raw

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

In reply to Darren Hart

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

Quoted 47 lines · 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.

Cc Richard Purdie <[email protected]>
Cc Koen Kooi <[email protected]>
Cc Jason Kridner <[email protected]>

---
meta/recipes-bsp/uboot/u-boot.inc | 8 +++++++-
meta/recipes-bsp/uboot/u-boot_git.bb | 11 ++++++-----

2 files changed, 13 insertions(+), 6 deletions(-)
meta/recipes-bsp/uboot/u-boot.inc +0 -0
index 058e3ba..a54cf24 100644
@@ -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'"

meta/recipes-bsp/uboot/u-boot.inc PARALLEL_MAKE="" · line 16

Quoted 4 lines
meta/recipes-bsp/uboot/u-boot.inc +3 -1
-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?

Quoted 38 lines
meta/recipes-bsp/uboot/u-boot.inc +4 -0
+              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"

meta/recipes-bsp/uboot/u-boot_git.bb +0 -0
index 4c8f5df..0fbb9ba 100644
@@ -1,5 +1,11 @@

require u-boot.inc

meta/recipes-bsp/uboot/u-boot_git.bb +6 -0
+# 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"
meta/recipes-bsp/uboot/u-boot_git.bb +0 -0
@@ -12,11 +18,6 @@ PR="r3"
 

SRC_URI = "git://git.denx.de/u-boot.git;branch=master;protocol=git"

meta/recipes-bsp/uboot/u-boot_git.bb +0 -3
-UBOOT_MACHINE_beagleboard = "omap3_beagle_config"
-UBOOT_MACHINE_overo = "omap3_overo_config"
-

S = "${WORKDIR}/git"

PACKAGE_ARCH = "${MACHINE_ARCH}"

meta/recipes-bsp/uboot/u-boot_git.bb +0 -2
-
-COMPATIBLE_MACHINE = "(beagleboard|overo)"
Signature · 1 line
1.7.1
#6 lore raw

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

Quoted 51 lines · Jason Kridner

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

Quoted 47 lines · 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.

Cc Richard Purdie <[email protected]>
Cc Koen Kooi <[email protected]>
Cc Jason Kridner <[email protected]>

---
meta/recipes-bsp/uboot/u-boot.inc | 8 +++++++-
meta/recipes-bsp/uboot/u-boot_git.bb | 11 ++++++-----

2 files changed, 13 insertions(+), 6 deletions(-)
meta/recipes-bsp/uboot/u-boot.inc +0 -0
index 058e3ba..a54cf24 100644
@@ -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'"

Quoted 6 lines

meta/recipes-bsp/uboot/u-boot.inc PARALLEL_MAKE="" · line 16

Quoted 4 lines
meta/recipes-bsp/uboot/u-boot.inc +3 -1
-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

Quoted 39 lines
Quoted 39 lines
meta/recipes-bsp/uboot/u-boot.inc +4 -0
+              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"

meta/recipes-bsp/uboot/u-boot_git.bb +0 -0
index 4c8f5df..0fbb9ba 100644
@@ -1,5 +1,11 @@

require u-boot.inc

meta/recipes-bsp/uboot/u-boot_git.bb +6 -0
+# 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"
meta/recipes-bsp/uboot/u-boot_git.bb +0 -0
@@ -12,11 +18,6 @@ PR="r3"
 

SRC_URI = "git://git.denx.de/u-boot.git;branch=master;protocol=git"

meta/recipes-bsp/uboot/u-boot_git.bb +0 -3
-UBOOT_MACHINE_beagleboard = "omap3_beagle_config"
-UBOOT_MACHINE_overo = "omap3_overo_config"
-

S = "${WORKDIR}/git"

PACKAGE_ARCH = "${MACHINE_ARCH}"

meta/recipes-bsp/uboot/u-boot_git.bb +0 -2
-
-COMPATIBLE_MACHINE = "(beagleboard|overo)"
Signature · 1 line
1.7.1
Signature · 3 lines
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
#7 lore raw

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

Quoted 7 lines · Darren Hart
Quoted 6 lines

meta/recipes-bsp/uboot/u-boot.inc PARALLEL_MAKE="" · line 16

Quoted 4 lines
meta/recipes-bsp/uboot/u-boot.inc +3 -1
-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?

Quoted 6 lines

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 :)

Signature · 5 lines
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
#8 lore raw

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

In reply to Darren Hart
Quoted 3 lines · Darren Hart

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.

#9 lore raw

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

Quoted 5 lines · Phil Blundell
Quoted 3 lines · Darren Hart

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.

Quoted 8 lines

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

#10 lore raw

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

Quoted 2 lines · Richard Purdie

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.

Quoted 5 lines

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.

#11 lore raw

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

Quoted 20 lines · Phil Blundell
Quoted 2 lines · Richard Purdie

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.

Quoted 2 lines

Its usually seem to work out easier to just do:

Quoted 7 lines
Quoted 3 lines

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.

Quoted 3 lines

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.

Signature · 3 lines
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
#12 lore raw

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

Quoted 4 lines · Darren Hart

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.

#13 lore raw

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

Quoted 15 lines · Phil Blundell
Quoted 4 lines · Darren Hart

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$)"

Quoted 6 lines

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).

Quoted 9 lines

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.

Signature · 3 lines
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
#14 lore raw

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

Quoted 1 line · Darren Hart

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.

Quoted 3 lines

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.