[U-Boot] [PATCH v2 27/27] RFC: sunxi: Enable SPL FIT support

Tom Rini
2016-04-28T13:07:39Z

On Thu, Apr 28, 2016 at 11:44:50AM +0200, Michal Simek wrote:
> Hi Simon and Tom,
>
> On 23.2.2016 06:55, Simon Glass wrote:
> > Enable SPL FIT support for the Linksprite pcDuino3 as an example of how this
> > feature is used.
> >
> > This is only for demonstration purposes and is not to be applied.
> > Signed-off-by: Simon Glass <sjg@chromium.org>
> > ---
> >
> > Changes in v2: None
> >
> > arch/arm/cpu/armv7/sunxi/board.c | 5 +++++
> > configs/Linksprite_pcDuino3_defconfig | 4 ++++
> > 2 files changed, 9 insertions(+)
>
> I have played with SPL_FIT support and find some things
> First of all
> "mkimage: Support placing data outside the FIT"
> (722ebc8f84d5bccd2e70fad1079a0dd40cceddec)
> is missing description in usage function to see what -E options does.
>
> Then I have found a problem with fit address calculation because it has
> to be aligned.
> I have sent an RFC for it
> "SPL: FIT: Align loading address for header"
>
> I have also added support for ram load for FIT - please review.
> "SPL: FIT: Enable SPL_FIT_LOAD in RAM based boot mode"

I think these are reasonable.

> And also for SD fat based images.
> "SPL: FIT: Enable SPL_FIT_LOAD for sd bootmode for fat partions"

Ug, sorry. You missed the series from Lokesh that added a bunch more
features along those lines. I didn't pull them in since it was past the
merge window but will for the next release.

> Is there any plan to support falcon mode?
> Also I see kind of interesting to have one fit image with ATF, Secure
> OS, bitstreams and U-Boot and Linux kernel + dtbs
> Currently spl_load_simple_fit() seems to me expecting to blindly read
> the first fit partition and say this is u-boot and then based
> configuration description choose dtb.
>
> Do you have any plan to get even u-boot image from configurations instead?
> The we should get a support for loadables.

Well, the first itch I needed scratched was supporting many similar
platforms in DM+DT from a single binary, and that's what's there today.
So long as we can do things in a clean way, all of these other use cases
sound interesting and clearly useful to some people, so I don't object.

--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160428/e08abff4/attachment.sig>