[U-Boot] [RFC PATCH 00/11] extend FIT loading support (plus Pine64/ATF support)
Andre Przywara
andre.przywara at arm.com
Mon Feb 6 16:32:47 UTC 2017
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?
Cheers,
Andre.
More information about the U-Boot
mailing list