How Does Yocto Fill In UBOOT_MACHINE?

How Does Yocto Fill In UBOOT_MACHINE?

[Leo Schwab]

Two months ago I never heard of Yocto -- now I are one.  I'm
attempting to create a layer and pile of recipes that will allow us to
adapt Freescale's i.MX support to our custom board.  Right now we're
starting out with one of their evaluation boards, but will eventually
transition to our own.  In anticipation of arriving hardware, I
created a new config for u-boot by copying an existing config and
renaming it.  The new config builds properly, but I don't know why.
Grepping through the Yocto sources hasn't been very enlightening, and
I was hoping I could get some insights into what's going on.

I will try to be as succinct as I can (some of the names have been
changed to protect the innocent).  We initially started by using the
Freescale-furnished build targets directly.  I created a new layer
(we'll call it meta-belis3), and in it created this
conf/machine/ourboard.conf (apologies in advance for inappropriate
line wrapping; GMail offers no control over this):

----
#@TYPE: Machine
#@NAME: ourboard
#@DESCRIPTION: Based on machine configuration for Freescale i.MX6DL SABRE SD

include conf/machine/include/imx-base.inc
include conf/machine/include/tune-cortexa9.inc

SOC_FAMILY = "mx6:mx6dl"

PREFERRED_PROVIDER_u-boot = "u-boot-imx"

UBOOT_MACHINE = "mx6dl_sabresd_config"
UBOOT_SUFFIX = "bin"
UBOOT_PADDING = "2"

SERIAL_CONSOLE = "115200 ttymxc0"

MACHINE_FEATURES += " pci wifi"
----

This is basically a copy of Freescale's
meta-fsl-arm/conf/machine/imx6dlsabresd.conf file, with trivial
changes.  Inside the build directory's conf/local.conf, I set MACHINE
to 'ourboard'.  This has worked for several weeks now.

Yesterday, following Freescale's docs, I started making mods to u-boot
to create a separate build target for our board.  The result is that I
now have a working u-boot build target named 'mx6_ourboard_config".
With that done, I created a .bbappend file to make the target
available (in a file named
meta-belis3/recipes-bsp/u-boot/u-boot-imx_2009.08.bbappend):

----
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"

SRC_URI_append_ourboard = "file://u-boot-ourboard.patch"

UBOOT_MACHINE_ourboard = "mx6_ourboard_config"
----

I then ran 'bitbake u-boot', and was rewarded with a u-boot image
built for 'ourboard' -- the logs confirm it was built using the target
mx6_ourboard_config.

...Except I never told it to build 'ourboard'; I haven't modified
conf/machine/ourboard.conf yet.  It should still be building
mx6dl_sabresd_config.  So UBOOT_MACHINE is magically picking up a
different value.  If I remove my .bbappend file, then it resumes using
the target mx6dl_sabresd_config.

So:  What are the rules governing how UBOOT_MACHINE acquires its final
value?  What did I neglect to consider?  Is my .bbappend bogus?  Is
there some magic setting buried somewhere else I need to be aware of?
Thank you in advance for all suggestions.

Schwab

Re: How Does Yocto Fill In UBOOT_MACHINE?

[Saul Wold]

On 08/15/2013 11:15 AM, Leo Schwab wrote:
> Two months ago I never heard of Yocto -- now I are one.  I'm
> attempting to create a layer and pile of recipes that will allow us to
> adapt Freescale's i.MX support to our custom board.  Right now we're
> starting out with one of their evaluation boards, but will eventually
> transition to our own.  In anticipation of arriving hardware, I
> created a new config for u-boot by copying an existing config and
> renaming it.  The new config builds properly, but I don't know why.
> Grepping through the Yocto sources hasn't been very enlightening, and
> I was hoping I could get some insights into what's going on.
>
> I will try to be as succinct as I can (some of the names have been
> changed to protect the innocent).  We initially started by using the
> Freescale-furnished build targets directly.  I created a new layer
> (we'll call it meta-belis3), and in it created this
> conf/machine/ourboard.conf (apologies in advance for inappropriate
> line wrapping; GMail offers no control over this):
>
> ----
> #@TYPE: Machine
> #@NAME: ourboard
> #@DESCRIPTION: Based on machine configuration for Freescale i.MX6DL SABRE SD
>
> include conf/machine/include/imx-base.inc
> include conf/machine/include/tune-cortexa9.inc
>
> SOC_FAMILY = "mx6:mx6dl"
>
> PREFERRED_PROVIDER_u-boot = "u-boot-imx"
>
> UBOOT_MACHINE = "mx6dl_sabresd_config"
> UBOOT_SUFFIX = "bin"
> UBOOT_PADDING = "2"
>
> SERIAL_CONSOLE = "115200 ttymxc0"
>
> MACHINE_FEATURES += " pci wifi"
> ----
>
> This is basically a copy of Freescale's
> meta-fsl-arm/conf/machine/imx6dlsabresd.conf file, with trivial
> changes.  Inside the build directory's conf/local.conf, I set MACHINE
> to 'ourboard'.  This has worked for several weeks now.
>
> Yesterday, following Freescale's docs, I started making mods to u-boot
> to create a separate build target for our board.  The result is that I
> now have a working u-boot build target named 'mx6_ourboard_config".
> With that done, I created a .bbappend file to make the target
> available (in a file named
> meta-belis3/recipes-bsp/u-boot/u-boot-imx_2009.08.bbappend):
>
> ----
> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>
> SRC_URI_append_ourboard = "file://u-boot-ourboard.patch"
>
> UBOOT_MACHINE_ourboard = "mx6_ourboard_config"
> ----
>
> I then ran 'bitbake u-boot', and was rewarded with a u-boot image
> built for 'ourboard' -- the logs confirm it was built using the target
> mx6_ourboard_config.
>
> ...Except I never told it to build 'ourboard'; I haven't modified
> conf/machine/ourboard.conf yet.  It should still be building
> mx6dl_sabresd_config.  So UBOOT_MACHINE is magically picking up a
> different value.  If I remove my .bbappend file, then it resumes using
> the target mx6dl_sabresd_config.
>
But you did indirectly, I have to assume that your default MACHINE is 
set for "ourboard" and what's happened here is when the bbappend was 
added, your setting of UBOOT_MACHINE_ourboard is an override so it built 
using that setting.

> So:  What are the rules governing how UBOOT_MACHINE acquires its final
> value?  What did I neglect to consider?  Is my .bbappend bogus?  Is
> there some magic setting buried somewhere else I need to be aware of?
> Thank you in advance for all suggestions.
>
The magic is the OVERRIDES mechanism in base.bbclass, so the _ourboard 
is a machine override and takes presence over the default setting, in 
this case of the UBOOT_MACHINE.

You can see this in action by running a bitbake -e (prints the variable 
contents and how they were determined).

Sau!

> Schwab
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>

Re: How Does Yocto Fill In UBOOT_MACHINE?

[Leo Schwab]

Thank you for replying:

On Thu, Aug 15, 2013 at 11:39 AM, Saul Wold <sgw@linux.intel.com> wrote:
> On 08/15/2013 11:15 AM, Leo Schwab wrote:
>> ...Except I never told it to build 'ourboard'; I haven't modified
>> conf/machine/ourboard.conf yet.  It should still be building
>> mx6dl_sabresd_config.  So UBOOT_MACHINE is magically picking up a
>> different value.  If I remove my .bbappend file, then it resumes using
>> the target mx6dl_sabresd_config.
>>
> But you did indirectly, I have to assume that your default MACHINE is set
> for "ourboard"

Correct.

> and what's happened here is when the bbappend was added, your
> setting of UBOOT_MACHINE_ourboard is an override so it built using that
> setting.
> [ ... ]
> You can see this in action by running a bitbake -e (prints the variable
> contents and how they were determined).
>
Umm...  Actually, no I dont:

---
$ bitbake -e
[ ...blah, blah, blah...]
# $UBOOT_MACHINE
#   set /home/ewhac/devel/iMX6/fsl-community-bsp/sources/meta-belis3/conf/machine/ourboard.conf:12
#     "mx6dl_sabresd_config"
UBOOT_MACHINE="mx6dl_sabresd_config"
[ ... ]

Which is what I expected.

Meanwhile, in the build log
tmp/work/..../u-boot-imx/2009.08-r16/temp/run.do_compile.29091:

----
do_compile() {
	if [ "" = "ld-is-gold" ] ; then
		sed -i 's/$(CROSS_COMPILE)ld/$(CROSS_COMPILE)ld.bfd/g' config.mk
	fi
	if [ "" = "ld-is-gold" ] ; then
		sed -i 's/$(CROSS_COMPILE)ld$/$(CROSS_COMPILE)ld.bfd/g' config.mk
	fi

	unset LDFLAGS
	unset CFLAGS
	unset CPPFLAGS
	oe_runmake mx6_ournode_config   # <---- ?!?!?!
	oe_runmake u-boot.bin

}
----

In the process of reproducing this output, some stuff happened that
makes me think that bitbake's cache is mildly confused.  I'll try
scrubbing it and see if things become more consistent.  I will also
look into the OVERRIDES mechanism.

Schwab

Re: How Does Yocto Fill In UBOOT_MACHINE?

[Saul Wold]

On 08/15/2013 12:02 PM, Leo Schwab wrote:
> Thank you for replying:
>
> On Thu, Aug 15, 2013 at 11:39 AM, Saul Wold <sgw@linux.intel.com> wrote:
>> On 08/15/2013 11:15 AM, Leo Schwab wrote:
>>> ...Except I never told it to build 'ourboard'; I haven't modified
>>> conf/machine/ourboard.conf yet.  It should still be building
>>> mx6dl_sabresd_config.  So UBOOT_MACHINE is magically picking up a
>>> different value.  If I remove my .bbappend file, then it resumes using
>>> the target mx6dl_sabresd_config.
>>>
>> But you did indirectly, I have to assume that your default MACHINE is set
>> for "ourboard"
>
> Correct.
>
>> and what's happened here is when the bbappend was added, your
>> setting of UBOOT_MACHINE_ourboard is an override so it built using that
>> setting.
>> [ ... ]
>> You can see this in action by running a bitbake -e (prints the variable
>> contents and how they were determined).
>>
> Umm...  Actually, no I dont:
>
> ---
> $ bitbake -e
> [ ...blah, blah, blah...]
> # $UBOOT_MACHINE
> #   set /home/ewhac/devel/iMX6/fsl-community-bsp/sources/meta-belis3/conf/machine/ourboard.conf:12
> #     "mx6dl_sabresd_config"
> UBOOT_MACHINE="mx6dl_sabresd_config"
> [ ... ]
>
> Which is what I expected.
>
Not what I would expect, if you bbappend was in play correctly, here is 
my example:

# $UBOOT_MACHINE [4 operations]
#   set /srv/hdd/poky/meta/conf/machine/include/tune-ppce300c3.inc:13
#     "bogus"
#   finalize ast.py:328 [finalize]
#     "was: bogus"
#   override[mpc8315e-rdb]:set 
/srv/hdd/poky/meta-yocto-bsp/conf/machine/mpc8315e-rdb.conf:11
#     "MPC8315ERDB_config"
#   finalize override[mpc8315e-rdb]:
#     "MPC8315ERDB_config"
# computed:
#   "MPC8315ERDB_config"
UBOOT_MACHINE="MPC8315ERDB_config"

And the do_compile / oe_runmake is correct with the mpc...config


> Meanwhile, in the build log
> tmp/work/..../u-boot-imx/2009.08-r16/temp/run.do_compile.29091:
>
> ----
> do_compile() {
> 	if [ "" = "ld-is-gold" ] ; then
> 		sed -i 's/$(CROSS_COMPILE)ld/$(CROSS_COMPILE)ld.bfd/g' config.mk
> 	fi
> 	if [ "" = "ld-is-gold" ] ; then
> 		sed -i 's/$(CROSS_COMPILE)ld$/$(CROSS_COMPILE)ld.bfd/g' config.mk
> 	fi
>
> 	unset LDFLAGS
> 	unset CFLAGS
> 	unset CPPFLAGS
> 	oe_runmake mx6_ournode_config   # <---- ?!?!?!
> 	oe_runmake u-boot.bin
>
> }
> ----
>
> In the process of reproducing this output, some stuff happened that
> makes me think that bitbake's cache is mildly confused.  I'll try
> scrubbing it and see if things become more consistent.  I will also
> look into the OVERRIDES mechanism.
>

Might be a cache issue, but it should recompute the hashes when you add 
or remove the .bbappend.

What version of oe-core / bitbake are you working with?

Sound likeyou are trying a clean build, you could just try "bitbake -e 
u-boot" without doing a full build and check those two items, the -e 
will also give you the do_compile() task.

Sau!
> Schwab
>
>

Re: How Does Yocto Fill In UBOOT_MACHINE?

[Leo Schwab]

On Thu, Aug 15, 2013 at 12:41 PM, Saul Wold <sgw@linux.intel.com> wrote:
> What version of oe-core / bitbake are you working with?
>
Umm...  Is 'dylan' a meaningful answer?

> Sound likeyou are trying a clean build, you could just try "bitbake -e
> u-boot" without doing a full build and check those two items, the -e will
> also give you the do_compile() task.
>
Ooo, interesting.  'bitbake -e' all by itself gives me this:

----
# $UBOOT_MACHINE
#   set /home/ewhac/devel/iMX6/fsl-community-bsp/sources/meta-belis3/conf/machine/ourboard.conf:12
#     "mx6dl_sabresd_config"
UBOOT_MACHINE="mx6dl_sabresd_config"
----

But 'bitbake -e u-boot' gives me this:

----
# $UBOOT_MACHINE [4 operations]
#   set /home/ewhac/devel/iMX6/fsl-community-bsp/sources/meta-belis3/conf/machine/ourboard.conf:12
#     "mx6dl_sabresd_config"
#   finalize ast.py:331 [finalize]
#     "was: mx6dl_sabresd_config"
#   override[ourboard]:set
/home/ewhac/devel/iMX6/fsl-community-bsp/sources/meta-belis3/recipes-bsp/u-boot/u-boot-imx_2009.08.bbappend:5
#     "mx6_ourboard_config"
#   finalize override[ourboard]:
#     "mx6_ourboard_config"
# computed:
#   "mx6_ourboard_config"
UBOOT_MACHINE="mx6_ourboard_config"
----

And the generated do_compile() script reflects this.  Still not
entirely clear why the results differ.

Thank you for all the suggestions so far.

Schwab

Re: How Does Yocto Fill In UBOOT_MACHINE?

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 1299 bytes --]

On Thu, Aug 15, 2013 at 11:15 AM, Leo Schwab <lschwab@sensity.com> wrote:

> meta-belis3/recipes-bsp/u-boot/u-boot-imx_2009.08.bbappend):
>
> ----
> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>
> SRC_URI_append_ourboard = "file://u-boot-ourboard.patch"
>
> UBOOT_MACHINE_ourboard = "mx6_ourboard_config"
>


​the above would mean when MACHINE is ourboard then value for UBOOT_MACHINE
will be mx6_ourboard_config​



> ----
>
> I then ran 'bitbake u-boot', and was rewarded with a u-boot image
> built for 'ourboard' -- the logs confirm it was built using the target
> mx6_ourboard_config.
>
> ...Except I never told it to build 'ourboard';
>


​I doubt that. Whats your default MACHINE may be in your local.conf ?​



> I haven't modified
> conf/machine/ourboard.conf yet.  It should still be building
> mx6dl_sabresd_config.  So UBOOT_MACHINE is magically picking up a
> different value.  If I remove my .bbappend file, then it resumes using
> the target mx6dl_sabresd_config.
>
> So:  What are the rules governing how UBOOT_MACHINE acquires its final
> value?  What did I neglect to consider?  Is my .bbappend bogus?  Is
> there some magic setting buried somewhere else I need to be aware of?
> Thank you in advance for all suggestions.
>
>

[-- Attachment #2: Type: text/html, Size: 2375 bytes --]

Re: How Does Yocto Fill In UBOOT_MACHINE?

[Leo Schwab]

On Thu, Aug 15, 2013 at 1:21 PM, Leo Schwab <lschwab@sensity.com> wrote:
> Still not entirely clear why the results differ.
>
I still haven't figured out why those two runs are different, but I
think I see what I might have done wrong with the .bbappend file.  Put
briefly: I copy-pasted Freescale's work.

Again, my u-boot-imx_2009.08.bbappend file:

----
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"

SRC_URI_append_ourboard = "file://u-boot-ourboard.patch"

UBOOT_MACHINE_ourboard = "mx6_ourboard_config"
----

The reason I put a UBOOT_MACHINE_ourboard assignment in there at all
is because Freescale does something similar in their
meta-fsl-arm/recipes-bsp/u-boot/u-boot-imx_2009.08.bb file for all
their development boards:

----
[ ...blah, blah, blah... ]
UBOOT_MACHINE_imx53qsb = "mx53_loco_config"
UBOOT_MACHINE_imx53ard = "mx53_ard_ddr3_config"
UBOOT_MACHINE_imx51evk = "mx51_bbg_config"
UBOOT_MACHINE_imx6qsabrelite = "mx6q_sabrelite_config"
UBOOT_MACHINE_imx6qsabreauto = "mx6q_sabreauto_config"
UBOOT_MACHINE_imx6qsabresd = "mx6q_sabresd_config"
UBOOT_MACHINE_imx6dlsabresd = "mx6dl_sabresd_config"
UBOOT_MACHINE_imx6slevk = "mx6sl_evk_config"
UBOOT_MACHINE_imx28evk = "mx28_evk_config"
[ ... ]
----

Near as I can tell, however, these override assignments are redundant,
as they have machine definitions located at
meta-fsl-arm/conf/machine/*.conf, each of which assigns a value to
UBOOT_MACHINE.  Indeed, if I'm reading the bitbake docs correctly, the
above assignments will override any UBOOT_MACHINE assignment in any
other machine/*.conf file (this potential gotcha is currently obscured
by the fact that the same value is assigned in both places).

From this, I conclude that I should remove the UBOOT_MACHINE_ourboard
assignment from my .bbappend file entirely, since the OVERRIDES
facility doesn't really buy me anything in this instance, and
(manifestly) leads to confusion.  Does that seem reasonable?

Schwab