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

[Jean-Jacques Hiblot <jjhiblot@ti.com>]

On 12/07/2017 14:58, Jean-Jacques Hiblot 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@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 made a short experiment and it turns out that the compression ratio is 
better when compressing the whole FIT image:
15468  spl/u-boot-spl.multidtb.fit      -- baseline: 4 dtbs, no compression
2389  spl/u-boot-spl.multidtb.fit.lzo  -- compressed as a whole
7120  spl/u-boot-spl.multidtb.itb  -- FIT containing individually 
compressed dtbs

Since the DTB for the SPL should be quite small and kind of similar to 
each other in the case of board variants, I think it's better to keep 
the compression stage at the level of the FIT image.

> 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()
>
> 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
>