Hi, On 12 July 2017 at 06:58, Jean-Jacques Hiblot <[email protected]> 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 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. > > 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
