[U-Boot] [RFC] Booting Xen from a FIT - Additional discussion about a refactor

[Simon Glass]

Hi Karl,

On 23 April 2015 at 15:39, Karl Apsite <Karl.Apsite at 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 at 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 at 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 at 1 {
>>>>>     description = "Xen 4.6.0-unstable configuration";
>>>>>     kernel = "xen_kernel at 1";
>>>>>     fdt = "fdt at 1";
>>>>>     gen_bin0 = "linux_kernel at 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