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 >>> Hi. >>> >>> 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 -> >> Linux >> >> 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. Thanks, Michal _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot