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

[Tom Rini <trini@konsulko.com>]

On Tue, Mar 21, 2017 at 01:52:07PM -0500, Franklin S Cooper Jr wrote:
> 
> 
> On 03/20/2017 11:57 PM, Vignesh R wrote:
> > 
> > 
> > On Saturday 18 March 2017 08:04 PM, Tom Rini wrote:
> >>>> 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?
> >>
> > 
> > I will leave Franklin to comment here. I dont think he has plans to do
> > changes for all K2 platforms (I guess his plans are mostly limited to K2G)
> 
> I'm not sure if there is any real solution other than providing a
> generous amount of storage for U-boot in the flash memory. I don't think
> atleast within our TI SDK use cases we even use the misc partition. So I
> don't see a reason why we couldn't give U-boot's partition 3 or 4 MB of
> space.

OK.  But what about a dedicated place where the right (base) board DTB
could reside?

> Also has there been any thoughts of compressing dtbs? These dtbs are
> relatively massive and compressed they are around 1/5 the size.

There has not yet been.  My first thought is about decompression time,
but maybe that won't matter.

> 
> Personally I'm not a fan of U-boot performing all these fix ups before
> passing things to the kernel. It forces so much coupling between
> bootloader versions and kernel. And things become more painful when
> changes in the kernel causes U-boot fix ups to break.

To the final point, I cannot find the video from the device tree BoF at
ELC, but as we talked about there, to some degree overlays/fixups will
have to be done in Linux.  But by the same token, a lot of overlay
applications will be done prior to the kernel as well.  When in doubt,
this shouldn't be done in C, but in user replaceable/updatable scripts.

-- 
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/20170321/aae9dc6b/attachment.sig>