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

[Otavio Salvador]

Hello Stephen,

On Thu, Jun 26, 2014 at 11:29 AM, Stephen Munnings
<Stephen.Munnings at nuvation.com> wrote:
...
> Both of these images are intended to run on the same board.
> I fear that my explanation has not been clear or detailed enough.
> The SPL U-boot would not do much good, because both versions run on the same instance of the board.
> (What would U-Boot use to differentiate between which version should be used?)
>
> The intent is this:
>
>    Image A (production image):
>     Designed to be run from NAND Flash.
>     This is  the image that the board will normally run, in its intended use in the field.
>
>   Image B (provisioning image):
>    Designed to be run from SD Card (on this same board).
>    The intent of this image is to have (as part of its file system) all the archives and a script to allow the installation of Image A onto the NAND Flash on the board.
>    Image B will (primarily) be run in manufacturing to put the production image (Image A) onto the (empty NAND Flash) boards in question.
>
> As such, the only real differences between the U-Boots is that one gets its image from the NAND Flash, and its Linux Kernel, and its file system, and has the watchdog enabled.
> The provisioning version disables the watchdog, gets it U-Boot, Linux Kernel, and file system from the SD card, and ultimately creates the production image on the NAND Flash.
> (Image A is packaged and included in the file system of Image B, but not in bootable form - the installation script(s) manage putting these on the NAND Flash)

So you don't need two images but a environment setting to change the
behavior; this can be a value read from the NAND for example.

> The "two different machines" approach also has the issue of a considerable amount of data redundancy - and extra time spent on building the images.
>
> If I correctly read what Lauren has done, it is not really much of a "trick", but more a management of what steps are run to achieve the desired results:
>   a.  Clean out the previous u-boot.
>   b.  (re)Configure the recipes as appropriate
>   c.  Force a complete re-build of u-boot
>   d.  Save the result
>
>   Then repeat steps a through d with differences in the recipes and saved names/locations
>
> Works just fine for me.
> Part of my difficulties were in figuring out what steps to run to force a complete re-build of u-boot.

This works but as I am always concerned about trackability,
predictability and other long term thing I would not do that. There is
no right or wrong here but best practices and learning from previous
experience.

Best Regards,

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