On 5.10.2016 09:50, Simon Glass wrote: > Hi, > > On 5 October 2016 at 08:39, Michal Simek <mon...@monstr.eu> wrote: >> 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. >> >> >> >> >>> >>> >>> >>> >>> [3] >>> I am guessing most vendors use vendor-specific firmware for low-level init >>> because I see many of ARMv8 SoCs disabling CONFIG_SPL. Correct? >>> >> >> I do use SPL exactly how as used without ATF. It means low level init is >> done in SPL in EL3. >> >> >>> >>> Boot ROM -> Vendor proprietary firmware -> ATF BL31 -> U-Boot or >>> UEFI (=BL33) -> Linux >>> >>> >>> >>> >>> [4] >>> Is it a good idea to implement everything in ATF like Juno/FVP? >>> >>> BL1 -> BL2 -> BL31 -> U-Boot or UEFI (BL33) -> Linux >>> >> >> We are using only BL31 and nothing else. >> >> >>> >>> >>> >>> >>> >>> 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. >> >> Anyway check zynqmp. It is not perfect solution but it is at least temporary >> solution for just this case. >> FIT image has an option to add more images with load address and I think >> this is a support >> we should support in SPL. (doc/uImage.FIT/multi-with-loadables.its) >> Also there will be probably need to mark images with EL level this targets. > > I have not got into this yet. But I'm really keen on SPL being the > first thing that runs, and it calling into ATF bits as needed. This > allows verified boot to work correctly, since we can add signatures to > the images, etc. It also is easier to follow IMO.
Isn't this already supported if I pretend that ATF is Linux kernel and dtb is full U-Boot. > > Long term, I am wondering if ATF could be a library instead of a > separate binary? Or perhaps it could be build so that it can be linked > against. > > Binman aims to make it easier to create these images with 4-5 separate > binaries. At some point I'm going to look at ATF in a bit more detail. I should look at it when you send it because for boot.bin generation could be useful. Thanks. Michal -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Xilinx Microblaze Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP SoCs
signature.asc
Description: OpenPGP digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot