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