Hi Masahiro, 2016-10-05 19:34 GMT-07:00 Masahiro Yamada <yamada.masah...@socionext.com>:
> Hi Michal, > > > 2016-10-05 23:39 GMT+09:00 Michal Simek <mon...@monstr.eu>: > > Hi Masahiro, > > > > 2016-10-04 20:19 GMT-07:00 Masahiro Yamada < > yamada.masah...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot