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.przyw...@arm.com> wrote:
>>> On 27/01/17 21:29, Simon Glass wrote:
>>>
>>> Hi Simon,
>>>
>>>> On 19 January 2017 at 18:53, Andre Przywara <andre.przyw...@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@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@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@1 {
description = "U-Boot (64-bit)";
data = /incbin/("u-boot-nodtb.bin");
type = "standalone";
arch = "arm64";
compression = "none";
load = <0x4a000000>;
};
atf@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@1";
__CONF_HEADER_EOF
cnt=1
for dtname in $*
do
cat << __CONF_SECTION_EOF
config@$cnt {
description = "$dtname";
firmware = "uboot@1";
loadables = "atf@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.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
