[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 7:17 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 5:58 PM, Stephen Munnings <Stephen.Munnings at nuvation.com> wrote:
...
> 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.
...

The concept of machine configuration for Yocto Project is exactly this; u-boot, kernel and recipe specific settings.

You can 'workaround' it and do tricks, as explained by Lauren, but I don't advise this approach as this has predictability, consistency and maintenance implications.

One alternative is to build upon the upcoming U-Boot 2014.07 which has SPL support for i.MX6 and use a single U-Boot binary which has detection at runtime at the board it is running on top and change it dynamically. This would be the ideal solution in my point of view.

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

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)

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.

Regards,

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