On 12.10.2016 13:18, Mike Looijmans wrote:
> On 11-10-16 13:00, Dan Handley wrote:
> Kind regards,
> Mike Looijmans
> System Expert
> TOPIC Products
> Materiaalweg 4, NL-5681 RJ Best
> Postbus 440, NL-5680 AK Best
> Telefoon: +31 (0) 499 33 69 79
> E-mail: mike.looijm...@topicproducts.com
> Website: www.topicproducts.com
> Please consider the environment before printing this e-mail
> -----Original Message-----
>>> From: Masahiro Yamada [mailto:yamada.masah...@socionext.com]
>>> Sent: 05 October 2016 04:19
>>> Recently I implemented ARM Trusted Firmware BL31 for my SoCs.
>>> But, I am wondering how the boot-flow should be.
>> I'm no U-Boot expert but as ARM Trusted Firmware (TF) maintainer, I
>> feel I should say something here.
>> In general we expect partners to take the bits of TF that work best
>> for them. So all the bootflows discussed in this thread are valid as
>> far as I'm concerned:
>> Proprietary Boot ROM -> Proprietary firmware -> TF BL31 -> U-Boot ->
>> Proprietary Boot ROM -> U-Boot SPL -> TF BL31 -> Full U-Boot -> Linux
>> TF BL1 -> TF BL2 -> TF BL31 -> U-Boot or UEFI (BL33) -> Linux
> Regardless of choice here, it would be nice if all those blobs could be
> combined into a single image. Currently the system spends most of its
> boot time looking up binaries, and copying them around from device into
> memory and then relocate them to a final destination.
> The current situation is that I need to create a bunch of tiny flash
> partitions: SPL, BL31, U-boot, devicetree, ...
> What I WANT to have is just one "boot" partition that holds SPL, BL31
> and u-boot, and then have big u-boot access a filesystem (UBI, FAT or
> EXT) to continue from there.
I haven't had a time but Simon sent binman which can solve at least the
part of this.
U-Boot mailing list