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.