[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