21.01.2017, 01:47, "Andre Przywara" andre.przywara@arm.com:
Hi,
On 20/01/17 17:35, Andrew F. Davis wrote:
On 01/20/2017 11:17 AM, Andre Przywara wrote:
Hi Andrew,
thanks for the comments.
On 20/01/17 17:02, Andrew F. Davis wrote:
On 01/19/2017 07:53 PM, Andre Przywara 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.
I have been thinking about a similar problem we are facing regarding OP-TEE loading when doing SPL-only boots. I think extending SPL FIT loader is a good approach, I've just been concerned about SPL bloat. On our High Security enabled AM335x SoC we only have 41KB of SRAM to load SPL (last I checked we only have 100 bytes of overhead left), and we need FIT support as we use it for image authentication (it's what we use the board_fit_image_post_process() hook for), so any changes to SPL FIT need to be carefully made.
Understood. Have you actually included FIT support as it exists already in your build? My observation is that even without these changes proposed here SPL FIT adds quite a bit to the SPL size (hence my patches to extend SPL size for AArch64 sunxi). This is mostly due to some libfdt bits being included, so I guess there is not much you can do about it. I will later check how much the code size changes with my patches. And btw.: Allwinner has either 24KB or 32KB of SRAM, so the situation is even more dire here.
Yes, we include FIT support in our build, and we make a lot of sacrifices in functionality for it (reducing the types of media we can load from, tiny malloc, tiny printf, etc..).
When new features come out we need to decide which old ones to disable, so the benefits of FIT and other features have to be worth more than the size in code it takes to implement them. (I think this change is worth it and am willing to sacrifice other things to keep our boards booting and have this addition, but we need to try to keep this in size issue in mind).
OK, got it. I have some easy patches to cut off 250 Bytes or so from an AArch64 build, maybe there is something similar possible for ARM? For instance I converted the ctype() implementation from table based to using simple comparisons and could cover all cases needed by the SPL and save 200 Bytes. After a quick look at am335x_shc_sdboot_defconfig it seems you have the 256 Byte ctype() table in there, so I can send this patch to give you more back than this FIT extension takes ;-)
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? 2) Shall we extend mkimage to allow supplying "loadable" files on the command line, which would allow to build the .itb file automatically?
Where does this end, we may also need to add the load address for images, etc... eventually we are passing a full .its on the command line. I'm not against this, as it would help our build process also (we generate an .its file with all our build artifacts during our distro build and feed it to mkimage), so if we think this is better than option 3 below, we should think through all the things we may need before cluttering up the mkimage command line arguments.
I agree, I was wondering about that as well. It's just tempting to add one or two options and piggy-back on the existing Makefile support.
Maybe some generic infrastructure of storing platform or board specific .its files can be included into the build system? Similarly to .dts files we could reference them in the (def)config and use mkimage -f during build to generate an image? That sounds more flexible than adding command line options to cover specific scenarios. We may use something like mergeconfig to make changes to the .its when needed.
I'm okay with that, as these .its files are .dts based anyway it shouldn't be too hard to have #includes to get other image specific nodes and overrides. One thing I'm not sure about is having the .its files stored in U-Boot tree, as most of the stuff we add to our .itb loadable section is external (ATF, OP-TEE, IPU/IVA firmware, etc..), but I'm all for adding the support to mkimage for such a thing anyway.
Yeah, that's an interesting point. Allwinner also needs the ATF bl31.bin to be provided somehow. In the "demo" .its I put it into U-Boot root, maybe we should create a directory "externals" or the like with just a README in it, and people are supposed to copy or link in the binary images there? In the .its it would read "../../externals/...", for instance, to make it more clear that those components are external to and not provided by U-Boot.
Maybe you can take doc/README.x86 as a reference?
X86 platform nearly all needs external blob (except QEMU :-) ) to build a ROM image.
Cheers, Andre.
Cheers, Andre.
3) Is providing the .its source file for a (family of) boards the right way? 4) Does this break any boards which already use SPL FIT loading?
And for the Pine64 part: 5) Is extending the usable SPL size like in patch 5-7 acceptable?
I have a more generic solution for the .dtb selection in mind: Based on some patch from Siarhei we store the .dtb filename in the SPL header and select the .dtb from the FIT image by simply matching the name. This would allow _one_ build supporting multiple boards. The actual board name would need to written into the SPL header or could be copied from there when updating the image. I can provide the patches once we agreed upon this series.
Please let me know what you think!
Cheers, Andre.
Andre Przywara (11): SPL: FIT: refactor FDT loading SPL: FIT: rework U-Boot image loading SPL: FIT: factor out spl_load_fit_image() SPL: FIT: allow loading multiple images tools: mksunxiboot: allow larger SPL binaries sunxi: A64: SPL: allow large SPL binary sunxi: A64: move SPL stack to end of SRAM A2 sunxi: SPL: add FIT config selector for Pine64 boards sunxi: Pine64: defconfig: enable SPL FIT support sunxi: Pine64: add FIT image source SPL: SPI: sunxi: add SPL FIT image support
board/sunxi/board.c | 13 +++ board/sunxi/pine64_atf.its | 54 +++++++++ common/spl/spl_fit.c | 241 +++++++++++++++++++++++----------------- configs/pine64_plus_defconfig | 5 + drivers/mtd/spi/sunxi_spi_spl.c | 39 +++++-- include/configs/sunxi-common.h | 6 +- scripts/Makefile.spl | 7 +- tools/mksunxiboot.c | 51 ++++++--- 8 files changed, 290 insertions(+), 126 deletions(-) create mode 100644 board/sunxi/pine64_atf.its
-- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout.