[U-Boot] [PATCH v2 0/4] New tag for Flattened Image Trees (FIT) - Booting Xen from a FIT.

[Karl Apsite]

Hi Simon,

On 05/18/2015 11:28 AM, Simon Glass wrote:
> +Tom in case he has a comment
> 
> Hi Karl,
> 
> On 15 May 2015 at 15:13, Karl Apsite <Karl.Apsite at dornerworks.com> wrote:
>>
>> The FIT config now supports a tag named "loadables:" which is a
>> comma separated list.  Users can add any number of images to the list,
>> and u-boot will move the selected binaries to their listed
>> load_addresses. This allows u-boot to boot xen from using an FIT
>> configuration.  Xen expects a kernel to be placed at a predetermined
>> location, however the "kernel" field was already filled by xen itself.
>> This change allows the user to move the required binary before xen
>> boots, all within the FIT's configuration.
>>
> 
> I think I've convinced myself that this ('loadables') is a good
> solution to the problem. I'm not 100% comfortable with the name but I
> don't have a better one, and no one else has chimed in.
> 
> Will you actually use multiple images in your application?
> 
We initially wanted to create this feature for Xen initially, and that only
required loading one "loadable", or simply another kernel binary along side the
first one.

While I was working on loading another binary in this fashion, we thought of a
few other use cases that might benefit from this feature involving a number of
the embedded systems we work with.  Many of our use cases involve other
peripheries that need to be configured or programmed with data during the boot
process.  By extending this configuration to an FIT, we can load/configure
N-number of peripherals during boot, and gain some of the benefits that an FIT
can provide:
 - Automatic checksum validation
 - Multiple configurations at the ready, all inside one "pre-baked image"
 - All while keeping the interface that a customer might use relatively simple
`> bootm "#config at 2"` or `"#config at 3"`, etc.
This is quite beneficial when we'd normally have to rely on u-boot scripts to do
everything instead.

As a final consideration (and to be clear, this is requires a lot more
investigation), one of the long-term goals that has been proposed to Xen,
involves splitting up the "master control domain" (known as dom0) into a number
of smaller domains/microkernels, each responsible for a certain task/service.
E.G. a networking domain, a file-system IO domain, etc.  So while this doesn't
solve a large number of problems that are currently blocking that complex
feature, this might help open the door to allow Xen to break components/services
into different executables/kernels, and load them simultaneously.
>>
>> Karl Apsite (4):
>>   add test for two 'loadables'
>>   mkimage will now report information about loadable
>>   add boot_get_loadables() to load listed images
>>   Combine bootm_find_<thing> functions together
>>
>>  common/bootm.c                        | 49 ++++++++++++-----------
>>  common/cmd_bootm.c                    |  4 +-
>>  common/image-fit.c                    | 25 +++++++++++-
>>  common/image.c                        | 71 ++++++++++++++++++++++++++++++++++
>>  doc/uImage.FIT/source_file_format.txt |  4 ++
>>  include/bootm.h                       |  2 +-
>>  include/bootstage.h                   |  1 +
>>  include/image.h                       | 28 +++++++++++++-
>>  test/image/test-fit.py                | 73 ++++++++++++++++++++++++++++++-----
>>  9 files changed, 221 insertions(+), 36 deletions(-)
>>
>> --
>> 2.3.7
>>
> 
> Regards,
> Simon
>