Hi Masahiro,
2016-10-05 19:34 GMT-07:00 Masahiro Yamada yamada.masahiro@socionext.com:
Hi Michal,
2016-10-05 23:39 GMT+09:00 Michal Simek monstr@monstr.eu:
Hi Masahiro,
2016-10-04 20:19 GMT-07:00 Masahiro Yamada <
yamada.masahiro@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