On Wed, Nov 28, 2018 at 04:31:21PM -0500, Tom Rini 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. So, I think you're saying it's option (1) here - available memory while actively manipulating the tree, yes? -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
Attachment:
signature.asc
Description: PGP signature