u-boot updates to make it more bbappend friendly
v2 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.
V2: Fixup the message printed if u-boot is skipped so it:
1) appears on the console
2) prints the name of the including u-boot recipe for reference (instead of a hard coded name)
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 | 10 +++++++++-
.../uboot/{u-boot_git.bb => u-boot_2011.03.bb} | 11 ++++++-----
2 files changed, 15 insertions(+), 6 deletions(-)
rename meta/recipes-bsp/uboot/{u-boot_git.bb => u-boot_2011.03.bb} (64%)PATCH v2 2/2 u-boot: rename u-boot_git.bb to u-boot_${PV}.bb
In reply to Darren HartIn 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.
---
.../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
Signature · 1 line
1.7.1
PATCH v2 1/2 u-boot: remove UBOOT_MACHINE and COMPATIBLE_MACHINES
In reply to Darren Hartoe-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.
Note: I used bb.note() instead of bb.debug() to ensure the message at least
makes it to the console. From what I could gather, bb.debug() doesn't go anywhere during recipe parsing.
--- meta/recipes-bsp/uboot/u-boot.inc | 10 +++++++++- meta/recipes-bsp/uboot/u-boot_git.bb | 11 ++++++----- 2 files changed, 15 insertions(+), 6 deletions(-)
meta/recipes-bsp/uboot/u-boot.inc +9 -1
@@ -11,7 +11,15 @@ 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 d.getVar("UBOOT_MACHINE", True): + PN = d.getVar("PN", True) + FILE = os.path.basename(d.getVar("FILE", True)) + bb.note("To build %s, see %s for instructions on setting up \ + your machine config" % (PN, FILE)) + 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
@@ -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
Re: [PATCH 1/2] u-boot: remove UBOOT_MACHINE and COMPATIBLE_MACHINES
Quoted 3 lines · Darren Hart
Note: I used
bb.note()instead ofbb.debug()to ensure the message at least
makes it to the console. From what I could gather,bb.debug()doesn't go anywhere during recipe parsing.
Why?
We exclude about 30 different recipes when parsing and would you really want to see a usability message from each one when you likely don't care about it?
A bb.debug is fine and the user can see it if they run with -D to get more info. A bb.note is just irritating.
Cheers,
Richard
Re: [PATCH 1/2] u-boot: remove UBOOT_MACHINE and COMPATIBLE_MACHINES
Quoted 5 lines · Richard Purdie
Quoted 3 lines · Darren Hart
Note: I used
bb.note()instead ofbb.debug()to ensure the message at least makes it to the console. From what I could gather,bb.debug()doesn't go anywhere during recipe parsing.
Quoted 8 lines
Why?
We exclude about 30 different recipes when parsing and would you really want to see a usability message from each one when you likely don't care about it?
A bb.debug is fine and the user can see it if they run with -D to get more info. A bb.note is just irritating.
As alternative, *If* there's a need for a one time message when building, which is questionable, and assuming the variable is configuration, not recipe bound, one could always install a ConfigParsed event handler and warn if e.g. UBOOT_ENTRYPOINT or UBOOT_LOADADDRESS are set and UBOOT_MACHINE is not.
Signature · 5 lines
Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics
Re: [PATCH 1/2] u-boot: remove UBOOT_MACHINE and COMPATIBLE_MACHINES
In reply to Richard PurdieQuoted 7 lines · Richard Purdie
Quoted 3 lines · Darren Hart
Note: I used
bb.note()instead ofbb.debug()to ensure the message at least
makes it to the console. From what I could gather,bb.debug()doesn't go anywhere during recipe parsing.Why?
My thinking was that the only time you would legitimately try and build this package when you can't is during a "world" build, which is likely an unattended sort of build anyway. The rest of the time you might hit this error would be when you intended to build u-boot but are missing the requisite configuration bits in your machine config.
Since the debug lines don't get logged anywhere, and you have to clear tmp/cache in order to retrigger the SkipPackage event with a new bitbake command (even with -D), I thought it the most user friendly to ensure the message made it out somewhere where it wouldn't get lost.
Quoted 1 line
We exclude about 30 different recipes
I didn't realize it was so many, it's difficult to tell just grepping for SkipPackage.
Quoted 3 lines
when parsing and would you really
want to see a usability message from each one when you likely don't care about it?
See above for my rationale on when you "care about it".
Quoted 3 lines
A bb.debug is fine and the user can see it if they run with -D to get more info.
The user won't see it unless they clear tmp/cache, which isn't very intuitive (or at least it wasn't to me).
Quoted 1 line
A bb.note is just irritating.
I can resend with bb.debug() if you feel strongly about it, as apparently you do. I've answered your "why" question, but I don't feel strongly about it. If you want to use bb.debug() I can resend as such (or just repush with that single change).
Thanks,
Signature · 3 lines
Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel
Re: [PATCH 1/2] u-boot: remove UBOOT_MACHINE and COMPATIBLE_MACHINES
Quoted 6 lines · Darren Hart
Quoted 5 lines · Richard Purdie
Quoted 3 lines · Darren Hart
Note: I used
bb.note()instead ofbb.debug()to ensure the message at least
makes it to the console. From what I could gather,bb.debug()doesn't go anywhere during recipe parsing.
Quoted 8 lines
Quoted 2 lines
Why?
My thinking was that the only time you would legitimately try and build this package when you can't is during a "world" build, which is likely an unattended sort of build anyway. The rest of the time you might hit this error would be when you intended to build u-boot but are missing the requisite configuration bits in your machine config.
You've inserted the note at parsing time though so every time anyone builds anything this will show up.
In case you wonder why bitbake does this its because it has no idea what the recipe provides until it attempts to parse it. Yes, you can make guesses from filenames but those are just a convenience and BBCLASSEXTEND can make one recipe provide multiple things for example.
foo_git.bb
containing:
PN = "bar"
or
PROVIDES += "something-else"
are both valid things to do too if potentially misleading.
Quoted 9 lines
Since the debug lines don't get logged anywhere, and you have to clear tmp/cache in order to retrigger the SkipPackage event with a new bitbake command (even with -D), I thought it the most user friendly to ensure the message made it out somewhere where it wouldn't get lost.
Quoted 1 line
We exclude about 30 different recipes
I didn't realize it was so many, it's difficult to tell just grepping for SkipPackage.
COMPATIBLE_MACHINE and COMPATIBLE_HOST will show more.
Quoted 13 lines
Quoted 3 lines
when parsing and would you really
want to see a usability message from each one when you likely don't care about it?See above for my rationale on when you "care about it".
Quoted 3 lines
A bb.debug is fine and the user can see it if they run with -D to get more info.
The user won't see it unless they clear tmp/cache, which isn't very intuitive (or at least it wasn't to me).
Quoted 6 lines
Quoted 1 line
A bb.note is just irritating.
I can resend with
bb.debug()if you feel strongly about it, as apparently you do. I've answered your "why" question, but I don't feel strongly about it. If you want to usebb.debug()I can resend as such (or just repush with that single change).
Given my comment above (the note appears all the time, not just for world), I do feel strongly about this.
Yes, we could do with a better way of showing up which packages were skipped if the user needs to know but this isn't the way to do it and it won't scale.
Cheers,
Richard
Re: [PATCH 1/2] u-boot: remove UBOOT_MACHINE and COMPATIBLE_MACHINES
Quoted 10 lines · Richard Purdie
Quoted 9 lines · Darren Hart
Quoted 7 lines · Richard Purdie
Quoted 3 lines · Darren Hart
Note: I used
bb.note()instead ofbb.debug()to ensure the message at least
makes it to the console. From what I could gather,bb.debug()doesn't go anywhere during recipe parsing.Why?
Quoted 8 lines
Quoted 5 lines
My thinking was that the only time you would legitimately try and build this package when you can't is during a "world" build, which is likely an unattended sort of build anyway. The rest of the time you might hit this error would be when you intended to build u-boot but are missing the requisite configuration bits in your machine config.
You've inserted the note at parsing time though so every time anyone builds anything this will show up.
Aha! Got it. I changed it and ran a test:
bb.note("DEBUG TO FOLLOW")
bb.debug(1, "To build %s, see %s for instructions on setting \
up your machine config" % (PN, FILE))
$ rm -rf tmp/cache; bitbake -DDDD u-boot | tee log Pseudo is not present but is required, building this first before the main build Loading cache...done. Loaded 998 entries from dependency cache. Parsing recipes...NOTE: DEBUG TO FOLLOW done. Parsing of 783 .bb files complete (780 cached, 3 parsed). 1000 targets, 11 skipped, 0 masked, 0 errors.
As you can see, even with -DDDD, the message never makes it to the console. So I agree that bb.note() is inappropriate, unfortunately, bb.debug doesn't appear to be working. I believe it was yesterday...
I pushed the bb.debug version to the same contrib branch in case I'm just running on too little sleep and I did something stupid in the above command which I'm not seeing.
--
Darren
Quoted 62 lines
In case you wonder why bitbake does this its because it has no idea what the recipe provides until it attempts to parse it. Yes, you can make guesses from filenames but those are just a convenience and BBCLASSEXTEND can make one recipe provide multiple things for example.
foo_git.bb
containing:
PN = "bar"
or
PROVIDES += "something-else"
are both valid things to do too if potentially misleading.
Quoted 9 lines
Since the debug lines don't get logged anywhere, and you have to clear tmp/cache in order to retrigger the SkipPackage event with a new bitbake command (even with -D), I thought it the most user friendly to ensure the message made it out somewhere where it wouldn't get lost.
Quoted 1 line
We exclude about 30 different recipes
I didn't realize it was so many, it's difficult to tell just grepping for SkipPackage.
COMPATIBLE_MACHINEandCOMPATIBLE_HOSTwill show more.Quoted 13 lines
Quoted 3 lines
when parsing and would you really
want to see a usability message from each one when you likely don't care about it?See above for my rationale on when you "care about it".
Quoted 3 lines
A bb.debug is fine and the user can see it if they run with -D to get more info.
The user won't see it unless they clear tmp/cache, which isn't very intuitive (or at least it wasn't to me).
Quoted 6 lines
Quoted 1 line
A bb.note is just irritating.
I can resend with
bb.debug()if you feel strongly about it, as apparently you do. I've answered your "why" question, but I don't feel strongly about it. If you want to usebb.debug()I can resend as such (or just repush with that single change).Given my comment above (the note appears all the time, not just for world), I do feel strongly about this.
Yes, we could do with a better way of showing up which packages were skipped if the user needs to know but this isn't the way to do it and it won't scale.
Cheers,
Richard
Signature · 3 lines
Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel
Re: [PATCH 1/2] u-boot: remove UBOOT_MACHINE and COMPATIBLE_MACHINES
Quoted 38 lines · Darren Hart
Quoted 10 lines · Richard Purdie
Quoted 9 lines · Darren Hart
Quoted 7 lines · Richard Purdie
Quoted 3 lines · Darren Hart
Note: I used
bb.note()instead ofbb.debug()to ensure the message at least
makes it to the console. From what I could gather,bb.debug()doesn't go anywhere during recipe parsing.Why?
Quoted 8 lines
Quoted 5 lines
My thinking was that the only time you would legitimately try and build this package when you can't is during a "world" build, which is likely an unattended sort of build anyway. The rest of the time you might hit this error would be when you intended to build u-boot but are missing the requisite configuration bits in your machine config.
You've inserted the note at parsing time though so every time anyone builds anything this will show up.
Aha! Got it. I changed it and ran a test:
bb.note("DEBUG TO FOLLOW")
bb.debug(1, "To build %s, see %s for instructions on setting \
up your machine config" % (PN, FILE))$ rm -rf tmp/cache; bitbake -DDDD u-boot | tee log Pseudo is not present but is required, building this first before the main build Loading cache...done. Loaded 998 entries from dependency cache. Parsing recipes...NOTE: DEBUG TO FOLLOW done. Parsing of 783 .bb files complete (780 cached, 3 parsed). 1000 targets, 11 skipped, 0 masked, 0 errors.
Quoted 3 lines
As you can see, even with -DDDD, the message never makes it to the console. So I agree that
bb.note()is inappropriate, unfortunately, bb.debug doesn't appear to be working. I believe it was yesterday...
The result was cached (780 cached). Try that command after "touch conf/local.conf" and it will be in there.
Cheers,
Richard
Re: [PATCH 1/2] u-boot: remove UBOOT_MACHINE and COMPATIBLE_MACHINES
Quoted 39 lines · Richard Purdie
Quoted 38 lines · Darren Hart
Quoted 10 lines · Richard Purdie
Quoted 9 lines · Darren Hart
Quoted 7 lines · Richard Purdie
Quoted 3 lines · Darren Hart
Note: I used
bb.note()instead ofbb.debug()to ensure the message at least
makes it to the console. From what I could gather,bb.debug()doesn't go anywhere during recipe parsing.Why?
Quoted 8 lines
Quoted 5 lines
My thinking was that the only time you would legitimately try and build this package when you can't is during a "world" build, which is likely an unattended sort of build anyway. The rest of the time you might hit this error would be when you intended to build u-boot but are missing the requisite configuration bits in your machine config.
You've inserted the note at parsing time though so every time anyone builds anything this will show up.
Aha! Got it. I changed it and ran a test:
bb.note("DEBUG TO FOLLOW")
bb.debug(1, "To build %s, see %s for instructions on setting \
up your machine config" % (PN, FILE))$ rm -rf tmp/cache; bitbake -DDDD u-boot | tee log Pseudo is not present but is required, building this first before the main build Loading cache...done. Loaded 998 entries from dependency cache. Parsing recipes...NOTE: DEBUG TO FOLLOW done. Parsing of 783 .bb files complete (780 cached, 3 parsed). 1000 targets, 11 skipped, 0 masked, 0 errors.
Quoted 6 lines
Quoted 3 lines
As you can see, even with -DDDD, the message never makes it to the console. So I agree that
bb.note()is inappropriate, unfortunately, bb.debug doesn't appear to be working. I believe it was yesterday...The result was cached (780 cached). Try that command after "touch
conf/local.conf" and it will be in there.
Sorry, the note did appear though.
That needs looking into and is possibly a logging problem. Needs fixing as a separate issue though and use of bb.note there isn't the right approach.
Cheers,
Richard
Re: [PATCH 1/2] u-boot: remove UBOOT_MACHINE and COMPATIBLE_MACHINES
Quoted 44 lines · Richard Purdie
Quoted 43 lines · Richard Purdie
Quoted 41 lines · Darren Hart
Quoted 10 lines · Richard Purdie
Quoted 9 lines · Darren Hart
Quoted 7 lines · Richard Purdie
Quoted 3 lines · Darren Hart
Note: I used
bb.note()instead ofbb.debug()to ensure the message at least
makes it to the console. From what I could gather,bb.debug()doesn't go anywhere during recipe parsing.Why?
Quoted 8 lines
Quoted 5 lines
My thinking was that the only time you would legitimately try and build this package when you can't is during a "world" build, which is likely an unattended sort of build anyway. The rest of the time you might hit this error would be when you intended to build u-boot but are missing the requisite configuration bits in your machine config.
You've inserted the note at parsing time though so every time anyone builds anything this will show up.
Aha! Got it. I changed it and ran a test:
bb.note("DEBUG TO FOLLOW")
bb.debug(1, "To build %s, see %s for instructions on setting \
up your machine config" % (PN, FILE))$ rm -rf tmp/cache; bitbake -DDDD u-boot | tee log Pseudo is not present but is required, building this first before the main build Loading cache...done. Loaded 998 entries from dependency cache. Parsing recipes...NOTE: DEBUG TO FOLLOW done. Parsing of 783 .bb files complete (780 cached, 3 parsed). 1000 targets, 11 skipped, 0 masked, 0 errors.As you can see, even with -DDDD, the message never makes it to the console. So I agree that
bb.note()is inappropriate, unfortunately, bb.debug doesn't appear to be working. I believe it was yesterday...
Quoted 8 lines
Quoted 2 lines
The result was cached (780 cached). Try that command after "touch
conf/local.conf" and it will be in there.Sorry, the note did appear though.
That needs looking into and is possibly a logging problem. Needs fixing as a separate issue though and use of bb.note there isn't the right approach.
OK, I haven't completely lost it then :-) In that case, are you looking for any additional changes/dialog/acks here? If not, the version with bb.debug() is now in the contrib branch:
git://git.pokylinux.org/poky-contrib dvhart/oe/u-boot
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=dvhart/oe/u-boot
I can resend as V3 if more discussion is desirable.
Signature · 3 lines
Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel
Re: [PATCH 1/2] u-boot: remove UBOOT_MACHINE and COMPATIBLE_MACHINES
Quoted 8 lines · Darren Hart
OK, I haven't completely lost it then :-) In that case, are you looking for any additional changes/dialog/acks here? If not, the version with
bb.debug()is now in the contrib branch:
git://git.pokylinux.org/poky-contribdvhart/oe/u-boot
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=dvhart/oe/u-bootI can resend as V3 if more discussion is desirable.
No, we're good.
Both patches merged to master.
Cheers,
Richard