[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: Thursday, June 26, 2014 11:38 AM
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

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
-----End Original Message-----

Hi Otavio,

We certainly considered the environment variable approach, but there are certain issues with that also - unless I have missed something.
Basically, it would introduce some potential manual steps that we would not like to add.

Our setup is intended to run with NO saved environment variables, and all normal settings are in the default environment.
They CAN be overridden with saved env values, but the intent is that a "blank" board (erased flash) will just boot and run normally in the way it is intended from an SD Card, and once the NAND has been programmed, would then just run normally from the NAND Flash with the overriding of env variables (saved in NAND Flash) being a very unusual circumstance.
The SD Card UBoot is configured to get everything from the SD Card, and run with that, while the NAND UBoot is configured to get everything from the NAND Flash and run with that.
And, I don't think (haven't looked carefully yet) that the Watchdog enablement is controllable from the Environment variables (although we could certainly modify the code to make it so).
It is currently controlled by preprocessor variables at compile time - <board>.h file.

As for best practices:  I understand, but there are often differences of opinion on what constitutes best practices.

In our environment, this appears to work well, be reasonably intuitive, and - if properly documented - pretty straight forward.

Regards,

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