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@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@2"` or `"#config@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