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