Hi Karl,
On 23 April 2015 at 15:39, Karl Apsite Karl.Apsite@dornerworks.com wrote:
On 04/23/2015 01:06 PM, Simon Glass wrote:
Hi Karl,
On 23 April 2015 at 07:15, Karl Apsite Karl.Apsite@dornerworks.com wrote:
On 04/22/2015 09:55 PM, Simon Glass wrote:
+Tom
Hi Karl,
On 22 April 2015 at 13:05, Karl Apsite Karl.Apsite@dornerworks.com wrote:
Hi!
I work at DornerWorks with the Xen Hypervisor. We work with a variety of embedded systems, and we wanted to facilitate Xen's boot procedure through U-boot's Flattened Image Tree (FIT) format. I've already prototyped some of the functionality we were hoping to see, so we thought it'd be prudent to begin a discussion with denx to get your opinion on the matter,
First Objective: (Summary of what was prototyped) A Flattened Image Tree is capable of holding all of the necessary binaries already, so we only need to make a quick change to allow u-boot to load an extra binary (in this case, a linux kernel) so that Xen can boot and load the kernel when it's ready. I started by simply adding a line in the configuration of my tree-source (.its) to look like:
config@1 { description = "Xen 4.6.0-unstable configuration"; kernel = "xen_kernel@1"; fdt = "fdt@1"; gen_bin0 = "linux_kernel@1"; };
I investigated what effort would be needed to load the additional binary.
Booting Xen is easy (only a kernel and fdt are required), but Xen will look at a hard-coded memory address to try a load a linux kernel. This has to be placed in memory by u-boot. The only major addition I needed, was to make u-boot care about a config option named "generic-binary" and load it, no questions asked. I chose the name "generic binary" as I simply needed u-boot to load a [thing] without any additional behavior. I'm using it to specifically load a linux kernel at a specific memory address in preparation for xen, but there could be potential future uses, hence the ambiguous name.
I wonder whether you should add a new type for the target kernel? General binary seems a bit vague. Just a thought.
I do agree, I don't really like the term "generic binary" either.
When preparing to boot Xen, u-boot needs to take a binary, and simply put it in place. Unlike the other images/objects (kernel, fdt, ramdisk, etc) u-boot's role is very simple in this regard: "Take these bits, and make sure they go over here."
In this scenario, the action taken by u-boot should be agnostic to what the image actually is. U-boot should simply move a binary, without any additional behavior. This led me to choose a name just as generic.
What is this additional behaviour you are referring to?
In each of the existing boot_get_<thing> functions, I saw that U-boot stores various addresses in the images parameter: bootm_headers_t *images. I am making an assumption that these addresses are used later for any possible "additional behaviors." That could very well be a misunderstanding, but I thought those addresses are used by u-boot later in the boot process.
There is a load and an exec address. The first tells U-Boot where to copy it (likely you will want this) and exec tells it where to start execution (which is only used for some image types).
So I would be quite comfortable with you just adding a new image for your special type of kernel.
[snip]
Regards, Simon