u-boot updates to make it more bbappend friendly

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 <[email protected]>

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 +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

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 <[email protected]>

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

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.

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.

Signed-off-by Darren Hart <[email protected]>

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

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.

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 10 lines

Signed-off-by Darren Hart <[email protected]> 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%)

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 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?

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.

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.

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

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.

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.

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

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.