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

[Michal Simek]

On 28.4.2016 15:07, Tom Rini wrote:
> 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 at 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.

Ah ok. Will look.

> 
>> 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.
> 

How do you identify platform you are running at?

Thanks,
Michal