On 07/12/2017 10:20 AM, Jean-Jacques Hiblot wrote: > > > 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 <[email protected]> >>>>>> --- >>>>>> >>>>>> 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
Just to clarify is the last one also using lzo? > > 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. Ok > >> 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 >> > _______________________________________________ U-Boot mailing list [email protected] https://lists.denx.de/listinfo/u-boot
