[meta-freescale] Best way (good way?) to make different U-boot for different machine images

[Stephen Munnings]

-----Original Message-----
From: otavio.salvador at gmail.com [mailto:otavio.salvador at gmail.com] On Behalf Of Otavio Salvador
Sent: Wednesday, June 25, 2014 2:35 PM
To: Stephen Munnings
Cc: meta-freescale at yoctoproject.org
Subject: Re: [meta-freescale] Best way (good way?) to make different U-boot for different machine images

On Wed, Jun 25, 2014 at 2:47 PM, Stephen Munnings <Stephen.Munnings at nuvation.com> wrote:
> Basically, my problem is two-fold:
>
> 1.        Setting different preprocessor variables or patches to source code
> for each different image
>
> 2.       Getting the u-boot binary to be re-built once one of the images has
> built it.
>
> Any hints, clues, or ideas on how to manage this?

Easiest solution is to use two different machine files. You can see how we did for Wandboard to easy share patches among boards.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

-----End  Original Message-----

Hi Otavio,

I did look at that (different machine files).
However, we are not looking at two different machines here, simply two different images.
Both run on exactly the same board, only one is intended to be put into the (on-board) NAND Flash and run from there, while the other image is intended to be written to an SD Card and run from there.
In these two different use cases, we have (very) different file systems, and we would like the u-boot to be (slightly) different also.

Somehow, it just doesn't "feel right" to call this two different machines.

Is there some (reasonable) way to do it within the framework of two different image names.
I have tried to put a MACHINEOVERRIDES into one of the image recipes, and having u-boot bbappend file have a conditional addition to the patches it applies, but something is not "connecting together" using this method.
Like this:
In image file:  MACHINEOVERRIDES =. "new-board-version2:"

In the u-boot-fslc_2013.10.bbappend file I have tried a selection of methods (none of which seem to work)

PR="r3"
PR_new_board-version2="r4"

SRC_URI_append_new-board = " \
	file://basic.patch \
	file://disable_watchdog.patch \
"

SRC_URI_append_new_board-version2 = " \
	file://extra.patch \
"

PACKAGE_ARCH_append_new-board-version2 = "-provision"


The PR stuff was to try and generate two different separate versions of u-boot
The SRC_URI stuff was to try and get an additional patch applied if the second image was selected
The PACKAGE_ARCH stuff was another attempt to get two different separate versions of u-boot

A bitbake with the -e parameter and grepping the output with ^OVERRIDES shows that the "new-board-version2" is getting into the OVERRIDES environment variable.
However, I suspect either that the variables I am attempting to override are not one that it can be done with, or more likely, the timing of the parsing and execution are preventing this from working.

Ideally, the difference would be one that is specified in the IMAGE_INSTALL += "....." line of the image recipe, but I can't think of any way to make the connection from there.
I don't think I can give a recipe a brand new name, and yet use it to override the u-boot-fslc recipe when it is built.


Regards,

-- 
Stephen Munnings 
Sr. Design Engineer | 519.594.0976 
www.nuvation.com