[U-Boot] SPL load ARM Trusted Firmware BL31?

[Michal Simek]

Hi Masahiro,

2016-10-05 19:34 GMT-07:00 Masahiro Yamada <yamada.masahiro at socionext.com>:

> Hi Michal,
>
>
> 2016-10-05 23:39 GMT+09:00 Michal Simek <monstr at monstr.eu>:
> > Hi Masahiro,
> >
> > 2016-10-04 20:19 GMT-07:00 Masahiro Yamada <
> yamada.masahiro at socionext.com>:
> >
> >> Hi.
> >>
> >> Recently I implemented ARM Trusted Firmware BL31 for my SoCs.
> >>
> >> But, I am wondering how the boot-flow should be.
> >>
> >>
> >>
> >> Here is my situation.
> >>
> >>
> >> [1]
> >> When my company developed its first ARMv8 SoC,
> >> I had to bring up the system very quickly.
> >>
> >> I was familiar with U-Boot and Linux to some extent, but not with ATF
> >> at that time.
> >> Also I was too pressed, so I decided to build up the system without ATF.
> >>
> >> The boot-flow was like this:
> >>
> >>   BootROM  ->  U-Boot SPL  -> U-Boot proper -> Linux
> >>
> >> In this flow, the secure runtime firmware is missing,
> >> so I used Spin-Table for the enable-method.
> >>
> >>
> >> [2]
> >> Now I finished porting ATF BL31.
> >> The low-level init code (basic SoC init + DRAM initialization)
> >> already exists in U-Boot SPL.
> >> So, I am currently re-using SPL, like follows:
> >>
> >>  BootROM ->  U-Boot SPL  -> ATF BL31 -> U-Boot proper (=BL33) -> Linux
> >>
> >>
> >> As far as I know, SPL can not load multiple images such as BL31, BL32,
> BL33
> >> (here BL32 is optional).
> >> So, I hacked my SPL to load multi images
> >> and jump to BL31.
> >>
> >
> > this is not entirely truth. If you look at zynqmp you will find out that
> if
> > you
> > work with atf as kernel and full u-boot as dtb then u-boot SPL can load
> two
> > images.
> > This is what I use. It is a trick but I am not using any changes to get
> it
> > work.
>
>
> Ah, now I see.
>
> The idea I came up with was
> to put every ATF stuff into spl_board_prepare_for_boot().
>


In our ATF implementation we are using structure for passing information
from
fsbl (which loads all images) to ATF to tell ATF what to do.
It means I could use this function to prepare the same in SPL.



>
>
>
> >
> > We are using only BL31 and nothing else.
>
>
> But, prior to commit f3d1cc2ff387ffe22ccd1bdcb2a998ec46149c6d
> (ARM64: zynqmp: Enable SPL for all zynqmp boards),
>
> BootROM -> fsbl -> ATF BL31 -> U-Boot -> Linux
>
> was the only supported solution, yes?
>

yes correct.



>
>
>
> >>
> >>
> >> Recently I saw Simon's binman patches.
> >> It provides a fancy way to pack multiple firmware components into a
> >> single image,
> >> but I did not see the systematic way to load every entry in the image.
> >>   (under way?)
> >>
> >>
> >> I was wondering if I should move my low-level init code
> >> from SPL to ATF BL2 or somewhere.
> >>
> >> Comments are welcome.
> >>
> >
> > I use bootrom -> SPL -> ATF -> full u-boot.
> >
> > I want to use SPL because we have all device drivers in u-boot and
> > in ATF we have only serial driver. If you want to use BL2 just for low
> > level init stuff
> > you can but it is the question if this brings you any value.
>
>
> Yes.  This is one big advantage of using SPL over BL2.
>

right. It is not only about drivers. Also fdt support and high level
functions.
ZynqMP for example has USB dfu boot mode which would be a little bit painful
to do in bl2 but it is almost for free with current SPL.

Thanks,
Michal


-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform