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

[Franklin S Cooper Jr <fcooper@ti.com>]

On 03/21/2017 07:25 PM, Tom Rini wrote:
> 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?

If the concern is space atleast for TI evms I don't see the difference
between carving out separate space just for dtbs vs having 1 large space
for both U-boot and dtbs. Without the right dtb U-boot may not properly
boot or have enough to boot a kernel. So if dtbs out grow their space we
will need to increase it anyway.

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

So my thought would be that we will compress the dtbs individually and
not the entire FIT image. This way U-boot can then read the FIT header
uncompressed and then select and uncompress only the dtb it needs.
> 
>>
>> 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.
> 

I think prebuilt overlays that are loaded and applied in U-boot is the
right way to go. Atleast then its not entwined within source code and is
edited in a very human readable manner.