From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jean-Jacques Hiblot Date: Wed, 12 Jul 2017 14:58:26 +0200 Subject: [U-Boot] [PATCH] spl: dm: Make it possible for the SPL to pick its own DTB from a FIT In-Reply-To: <6f6ab04d-fcc8-1686-574c-dac1ec1cdfc4@ti.com> References: <1499427879-9045-1-git-send-email-jjhiblot@ti.com> <20170707143028.GF22707@bill-the-cat> <6f6ab04d-fcc8-1686-574c-dac1ec1cdfc4@ti.com> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 >>>> --- >>>> >>>> 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() 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