Hi Karl, On 23 April 2015 at 15:39, Karl Apsite <[email protected]> wrote: > > > On 04/23/2015 01:06 PM, Simon Glass wrote: >> Hi Karl, >> >> On 23 April 2015 at 07:15, Karl Apsite <[email protected]> wrote: >>> >>> On 04/22/2015 09:55 PM, Simon Glass wrote: >>>> +Tom >>>> >>>> Hi Karl, >>>> >>>> On 22 April 2015 at 13:05, Karl Apsite <[email protected]> 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 _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
