[U-Boot] [PATCH] spl: dm: Make it possible for the SPL to pick its own DTB from a FIT

[Simon Glass]

Hi Jean-Jacques,

On 12 July 2017 at 15:32, Simon Glass <sjg at chromium.org> wrote:
> Hi,
>
> On 12 July 2017 at 06:58, Jean-Jacques Hiblot <jjhiblot at ti.com> wrote:
>>
>>
>> On 10/07/2017 18:34, Franklin S Cooper Jr wrote:
>>>
>>>
>>> On 07/07/2017 10:00 AM, Jean-Jacques Hiblot wrote:
>>>>
>>>>
>>>> On 07/07/2017 16:30, Tom Rini wrote:
>>>>>
>>>>> On Fri, Jul 07, 2017 at 01:44:39PM +0200, Jean-Jacques Hiblot wrote:
>>>>>
>>>>>> u-boot can be embedded within a FIT image with multiple DTBs. It then
>>>>>> selects at run-time  which one is best suited for the platform.
>>>>>> Use the same principle here for the SPL: put the DTBs in a FIT image,
>>>>>> compress it (LZO, GZIP, or no compression) and append it at the end
>>>>>> of the
>>>>>> SPL.
>>>>>>
>>>>>> Signed-off-by: Jean-Jacques Hiblot <jjhiblot at ti.com>
>>>>>> ---
>>>>>>
>>>>>> The impact in terms of boot time is not high when using LZO but I
>>>>>> gues it can vary
>>>>>> from platform to platform.
>>>>>> The size of the SPL binary is increased (1.5kB more code on ARM), but
>>>>>> the compression
>>>>>> really flattens the DTBS. so at the end of the day, enabling this
>>>>>> option doesn't add much.
>>>>>>
>>>>>> Here are some sumbers with a DRA7 platform (numbers in bytes):
>>>>>>                             size  delta with ref
>>>>>>     MLO.reference         123450
>>>>>>     MLO.lzo_1_DTB         123715    +265
>>>>>>     MLO.lzo_4_DTB         124237    +787
>>>>>>     MLO.gzip_4_DTB        132006    +8556
>>>>>>     MLO.no_comp_4_DTB     134184    +10734
>>>
>>> It would great if you can show the difference in time between todays,
>>> approach, your FIT approach gzipped and your FIT approach using lzo in
>>> terms of time between power on to SPL handling things off to U-boot.
>>
>> I'll add the measurements in the next version.
>>>
>>> Also would it make sense to sacrifice saving some space by not
>>> compressing the entire FIT but instead compressing dtbs individually and
>>> storing it in an uncompressed FIT? This way any additional boot time is
>>> limited to uncompressing the DTB you need. It would be especially
>>> helpful in the case of a large amount of dtbs being stored, slower
>>> devices, or using compression algorithms that save more space but its
>>> decompression is slower.
>>
>> It makes sense. I'll look into it.
>> I wasn't aware of your work in this area (CONFIG_FIT_EMBED). Now that is in
>> mainline u-boot, I'll leverage on it as it mostly does the same thing.
>> At the end, I may just end up removing the restriction that prevents using
>> CONFIG_FIT_EMBED in the SPL and move the decompression stage at the very end
>> of fdtdec_setup()
>
> I am not too keen on CONFIG_FIT_EMBED as a name since it is similar to
> CONFIG_OF_EMBED.  Can we perhaps rename it, e.g. to
> CONFIG_OF_INSIDE_FIT? That's not a great name, maybe you can think of
> something better.

Also on the patch itself a few comments:

- can you split out the lb/Makefile changes into a separate patch?
- Would it be better to use fit_image_load() to reduce code duplication?
- blablablabla needs more detail :-)

Regards,
Simon

>
>>
>> JJ
>>
>>>
>>>>> Bearing in mind that you said in a follow up this is RFC, I'm ignoring
>>>>> all of the stuff that I believe you would fix in a v1.  At the heart of
>>>>> it, are you able to tell different boards before you have a DTB loaded?
>>>>
>>>> In my case (DRA7) the board can be identified before the dtb is loaded.
>>>> The identification
>>>> is done by reading an eeprom on I2c. It just can't be using DM I2C in
>>>> the SPL.
>>>>>
>>>>> I keep coming back to the problem that for SPL it seems like we should
>>>>> be able to do what Franklin did for keystone
>>>>> (https://patchwork.ozlabs.org/patch/777242/) and have a 'fake' dts file
>>>>> that represents the SoC such that any real boards can get U-Boot loaded
>>>>> and from there have the real board dtb be used.  Or am I forgetting
>>>>> something?  Thanks!
>>>>
>>>> That's more or less the situation now with DRA7. This idea comes from
>>>> the need to accelerate the fastboot path by using the HS200 mode of the
>>>> eMMC. There we need to configure the lines of the eMMC and this
>>>> information is typically found in the DTB and differs from SOC to SOC.
>>>> At the moment in the ti tree this is done by duplicating this
>>>> information in C structures protected with #ifdef CONFIG_SPL_BUILD.
>>>> While this works, it would be nicer to get it from the dtb as done in
>>>> u-boot.
>>>
>>> Yeah I think thats the toughest thing with my approach. It only works in
>>> situations where loading the "next stage" is consistent between boards.
>>> In my case Keystone doesn't use SPL so I benefited from the ROM handling
>>> any board specific logic to load U-boot. Not sure if it will work well
>>> in SPL since loading U-boot can vary quite a bit.
>>>>
>>>> Jean-Jacques
>>
>>