[U-Boot] [PATCH] ARM: keystone: Pass SPI MTD partition table via kernel command line

[Tom Rini]

On Sat, Mar 18, 2017 at 05:44:05PM +0530, Vignesh R wrote:
> 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

Yes, this is more in line with what I was seeing.

> Still at least for k2 platforms DTBs alone are not to be blamed for
> image size increase.

Yes, features add size.  And the desire to add more and more DTBs also
increases the size.

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

The next question is, given that Franklin is talking about being able to
load the right DTB for any K2 platform basically, is the layout in
https://patchwork.ozlabs.org/patch/736498/ really looking like it will
be enough?

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

Yes, setting the initial size limit to 64KiB was a bad initial choice
especially since we want to have more and more features in SPL too.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170318/e701c13c/attachment.sig>