On Wed, Nov 28, 2018 at 3:31 PM Tom Rini <trini@xxxxxxxxxxxx> wrote: > > On Sat, Nov 24, 2018 at 08:42:19PM +1100, David Gibson wrote: > > On Wed, Nov 14, 2018 at 04:29:23PM -0800, Simon Glass wrote: > > > Hi David, > > > > > > We had a discussion today about a possible new v18 DT format[1] > > > > > > You have seen Frank Rowand's design from January[2]. Frank presented > > > material at the conference[3] and I wrote up something up too [4]. > > > > Yes, I didn't like the original proposal very much - overly > > complicated, but the revised one I suggested back looks reasonably > > do-able. > > > > Your proposal seems to have a rather different focus from Frank's - > > his is mostly about cleaner handling of overlays and similar > > extensions. Yours is mostly about size. > > > > Can I ask what's the concern here? I mean, first of all, I'm finding > > it a bit hard to believe that a few kiB of device tree really mean > > much in the context of a vaguely modern system. But more specifically > > is the concern in-memory size? Or size on persistent storage, disk or > > flash? Those two would be amenable to different approaches to > > mitigate. > > So, with respect to size, yes, for one example, modern 32bit Allwinner > SoCs are limited to either 32KiB or 24KiB and 64bit SoCs are limited to > 32KiB and that's our space for residing and executing from and holding > the device tree we're working from. You are referring to limits of what the bootROM can load for u-boot SPL cases, right? Probably just removing any nodes with 'status = "disabled"' and the delete if not referenced support would save more size impact than Simon's proposal. Changing the format will be painful and size improvements are the least compelling reasons to go thru that. While not ideal, another loader stage can deal with crappy SoC limitations and only those platforms have to have that added pain. Rob
