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. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
