On 3/16/2017 2:18 AM, Tom Rini wrote: > On Tue, Mar 14, 2017 at 05:11:06PM +0530, Vignesh R wrote: >> [...] >> >> On Friday 10 March 2017 11:32 PM, Tom Rini wrote: >>>> Yes, I agree that initial DT layout of 512K may not have been good >>>> design, but it would be good to have an agreeable way of fixing up MTD >>>> partitions when there is overflow. So, is fdt_fixup_mtdparts() preferred >>>> approach? >>> You make a good point about fdt_fixup_mtdparts() being non-trivial to >>> have happen correctly in all cases above, so OK, lets put that aside. >>> I'll also accept that previous best wisdom of not shoving tons of stuff >>> into the cmdline, rather than passing it in the device tree, isn't >>> correct anymore. >>> >>> But the big, un-tackled problem is that the old DT layout is failing >>> because we're constantly increasing the number of full linux DTB files >>> we're including in an image and thus increasing the size of our blob >>> every time. We need to stop and think and maybe design things >>> differently. Perhaps it's time for more platforms to have a spot on >>> their storage where the DT is supposed to be, and we only use a fall >>> back one that's included in U-Boot if it's not found? Franklin already >>> posted a patch to have something kind-of similar be able to happen >>> (which is to say, go from a generic DTB to the correct-for-the-HW one). >> I agree that DTB files are making u-boot image bulky. But it does not >> seem to be problem due to addition of DT alone. For example SPI boot >> image on K2 platform is two stage SPL+U-Boot combined into one single >> image u-boot-spi.gph which is about 555K. General boot image u-boot.bin >> is about 491K and u-boot-nodtb.bin is 432K. So even w/o dtbs SPI image >> may overflow and its because of new code/framework changes. > Which platform exactly? I don't see anything today that's quite that > large. Sorry, I had few debug prints enabled when I collected the stats. On vanila u-boot for k2hk here are the stats: u-boot-spi.gph 512K u-boot.bin 448K u-boot-nodtb.bin 420K
Still at least for k2 platforms DTBs alone are not to be blamed for image size increase. > And can we not move towards the "normal" method of SPL loading > the u-boot.img (or FIT) from? I guess the current architecture here is > confusing me. This has been same for all k2 platforms. I guess we have single image so that user don't have to bother flashing multiple images for spi boot given the fact that all other boot modes have single image. > Regardless, I still see the DT problem as the bigger one long term, and > dra7xx shows that. And I agree we need to re-size how the flash is > partitioned. True. >> There is similar issue with dra7xx where flash partition for SPL is >> running out due to addition of new code. > The DRA flash partition is, and should be fine because we have the > ROM-mandated limits and don't need to include U-Boot with the SPL image. > The main U-Boot image however is growing and that is a DTB problem. The > difference here between -nodtb and the .img (FIT) with all of the DTBs > is over 300KiB. And that's mostly linear growth when compared with the > single-DTB case. I agree DTBs are adding to image size on DRA. But even SPL is growing and is bound to exceed its 64K limit[1]. [1] https://patchwork.kernel.org/patch/9515551/ _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
