[U-Boot] [RFC PATCH 00/11] extend FIT loading support (plus Pine64/ATF support)

Andrew F. Davis afd at ti.com
Mon Feb 6 16:37:54 UTC 2017


On 02/06/2017 10:32 AM, Andre Przywara wrote:
> Hi Andrew,
> 
> On 06/02/17 16:17, Andrew F. Davis wrote:
>> On 02/06/2017 09:33 AM, Simon Glass wrote:
>>> Hi Andre,
>>>
>>> On 27 January 2017 at 17:47, André Przywara <andre.przywara at arm.com> wrote:
>>>> On 27/01/17 21:29, Simon Glass wrote:
>>>>
>>>> Hi Simon,
>>>>
>>>>> On 19 January 2017 at 18:53, Andre Przywara <andre.przywara at arm.com> wrote:
>>>>>> Currently the FIT format is not used to its full potential in the SPL:
>>>>>> It only loads the first image from the /images node and appends the
>>>>>> proper FDT.
>>>>>> Some boards and platforms would benefit from loading more images before
>>>>>> starting U-Boot proper, notably Allwinner A64 and ARMv8 Rockchip boards,
>>>>>> which use an ARM Trusted Firmware (ATF) image to be executed before U-Boot.
>>>>>>
>>>>>> This series tries to solve this in a board agnostic and generic way:
>>>>>> We extend the SPL FIT loading scheme to allow loading multiple images.
>>>>>> So apart from loading the image which is referenced by the "firmware"
>>>>>> property in the respective configuration node and placing the DTB right
>>>>>> behind it, we iterate over all strings in the "loadable" property.
>>>>>> Each image referenced there will be loaded to its specified load address.
>>>>>> The entry point U-Boot eventually branches to will be taken from the
>>>>>> first image to explicitly provide the "entry" property, or, if none
>>>>>> of them does so, from the load address of the "firmware" image.
>>>>>> This keeps the scheme compatible with the FIT images our Makefile creates
>>>>>> automatically at the moment.
>>>>>>
>>>>>> Apart from the already mentioned ATF scenario this opens up more usage
>>>>>> scenarios, of which the commit message of patch 04/11 lists some.
>>>>>>
>>>>>> The first three patches rework the SPL FIT support to be more flexible
>>>>>> and to allow easier usage in the fourth patch, which introduces the
>>>>>> multiple-image loading facility.
>>>>>> The remaining patches enable that support for the Pine64 board to make
>>>>>> its SPL support finally useful and to demonstrate usage of this scheme:
>>>>>> patches 5-7 extend the usable SPL size by about 4 KB to allow AArch64
>>>>>> compilation of the SPL with FIT support enabled. Patch 8 implements the
>>>>>> board selector routine, which selects either the Pine64 or Pine64+ DTB
>>>>>> depending on the detected DRAM size. Patch 9 enables SPL FIT support in
>>>>>> the Pine64 defconfig.
>>>>>> To demonstrate the usage, patch 10 provides a FIT source file, which
>>>>>> loads and executes ATF before the U-Boot proper. Users are expected to
>>>>>> compile this with "mkimage -f boards/sunxi/pine64_atf.its -E pine64.itb",
>>>>>> then write the resulting file behind the SPL on an SD card (or any other
>>>>>> U-Boot supported boot media, for that matter).
>>>>>> Patch 11 then adds FIT support to the sunxi SPL SPI loading routine,
>>>>>> which allows to load ATF on boards with SPI flash as well.
>>>>>>
>>>>>> Questions:
>>>>>> 1) Is this scheme the right one (usage of "firmware" and "loadables",
>>>>>>    determination of entry point)? Shall we make use of the "setup"
>>>>>>    property?
>>>>>
>>>>> Seems reasonable to me.
>>>>>
>>>>>> 2) Shall we extend mkimage to allow supplying "loadable" files on the
>>>>>>    command line, which would allow to build the .itb file automatically?
>>>>>
>>>>> Yes.
>>>>
>>>> I was thinking about this a bit more, as Andrew pointed out before it
>>>> may become hairy to add tons of options to mkimage.
>>>> I came up with a simple shell script, mostly using here documents
>>>> (cat << _EOF) to generate the .its file on the fly, adding all DTs given
>>>> on the command line. It's pretty easy, yet readable and adaptable. So
>>>> each platform could provide one, if needed, and could hard code things
>>>> like ATF in here.
>>>
>>> That sounds reasonable. But I do think it is valuable to support the
>>> basic case without needing a script, so long as you can do it with
>>> only a few mkimage options?
>>>
>>
>> We already have a few mkimage option for auto-generating FIT for basic
>> cases (Executable and DTBs). I've seen internally confusion caused by
>> having mkimage accept dtb's on the command-line while we work to add
>> more complex FIT schemes. I think our time is best spent working on
>> simplifying generating custom .its files during build, and less on
>> patching mkimage to support increasingly complex build configurations.
>>
>> How about we have template .its files for platforms and for simple build
>> cases, then simply define a way to fill in these using mkimage:
>>
>>> / {
>>>         description = "U-Boot fitImage for PlatformX";
>>>         #address-cells = <1>;
>>>
>>>         images {
>>>                 u-boot at 1 {
>>>                         description = "U-Boot";
>>>                         data = /incbin/("u-boot.bin");
>>>                         arch = "arm";
>>>                         load = <[u_boot_load]>;
>>>                 };
>>>                 [dtb_name] {
>>>                         description = "Flattened Device Tree blob";
>>>                         data = /incbin/("arch/arm/boot/dts/[dtb_name].dtb");
>>>                         type = "flat_dt";
>>>                         arch = "arm";
>>>                 };
>>>                 firmware at 1 {
>>>                         data = /incbin/("[firmware_name]");
>>>                         arch = "arm";
>>>                         compression = "none";
>>>                 };
>>>         };
>>> };
>>
>> Then:
>>
>>> $ mkimage --template "default.dtb" -x "u_boot_load=0x800000,dtb_name=dra7xx_evm.dtb,firmware_name=atf.bin"
>>
>> Or better yet, use an existing template engine as a pre-processing step
>> in the Makefile to generate the needed .its files.
> 
> Short of using some fancy templating, would that script cover that?
> 
> ==================================================
> #!/bin/sh
> #
> # script to generate FIT image source for 64-bit sunxi boards with
> # ARM Trusted Firmware and multiple device trees (given on the command #
> line)
> #
> # usage: $0 <dt_name> [<dt_name> [<dt_name] ...]
> 
> cat << __HEADER_EOF
> /dts-v1/;
> 
> / {
>         description = "Configuration to load ATF before U-Boot";
>         #address-cells = <1>;
> 
>         images {
>                 uboot at 1 {
>                         description = "U-Boot (64-bit)";
>                         data = /incbin/("u-boot-nodtb.bin");
>                         type = "standalone";
>                         arch = "arm64";
>                         compression = "none";
>                         load = <0x4a000000>;
>                 };
>                 atf at 1 {
>                         description = "ARM Trusted Firmware";
>                         data = /incbin/("bl31.bin");
>                         type = "firmware";
>                         arch = "arm64";
>                         compression = "none";
>                         load = <0x44000>;
>                         entry = <0x44000>;
>                 };
> __HEADER_EOF
> 
> cnt=1
> for dtname in $*
> do
>         cat << __FDT_IMAGE_EOF
>                 fdt@$cnt {
>                         description = "$dtname";
>                         data = /incbin/("arch/arm/dts/$dtname.dtb");
>                         type = "flat_dt";
>                         compression = "none";
>                 };
> __FDT_IMAGE_EOF
>         cnt=$((cnt+1))
> done
> 
> cat << __CONF_HEADER_EOF
>         };
>         configurations {
>                 default = "config at 1";
> 
> __CONF_HEADER_EOF
> 
> cnt=1
> for dtname in $*
> do
>         cat << __CONF_SECTION_EOF
>                 config@$cnt {
>                         description = "$dtname";
>                         firmware = "uboot at 1";
>                         loadables = "atf at 1";
>                         fdt = "fdt@$cnt";
>                 };
> __CONF_SECTION_EOF
>         cnt=$((cnt+1))
> done
> 
> cat << __ITS_EOF
>         };
> };
> __ITS_EOF
> ==================================================
> 
> This would be passed $CONFIG_OF_LIST.
> The resulting .its file can the be transformed by a generic:
> mkimage -f u-boot.its -E u-boot.img
> 
> This script would be platform specific and referenced by boards in need
> for it.
> 
> Andrew, does that cover the use cases you were thinking of?
> 

I just saw your other reply after I had sent mine here, I like the idea
of having a CONFIG_FIT_GENERATOR symbol, or some other way to point to
platform specific generators, then you can use your style, and I can
make a more complex fancy templating one if I needed.

To answer your question, yes, for now it looks like that script could be
make to handle our current use-cases.

Thanks for posting that by the way, +Franklin who was looking for
something similar.

Andrew

> Cheers,
> Andre.
> 


More information about the U-Boot mailing list