Hi David, On Sun, 2 Dec 2018 at 18:11, David Gibson <david@xxxxxxxxxxxxxxxxxxxxx> wrote: > > On Wed, Nov 28, 2018 at 07:31:37PM -0700, Simon Glass wrote: > > Hi Rob, > > > > On Wed, 28 Nov 2018 at 14:51, Tom Rini <trini@xxxxxxxxxxxx> wrote: > > > > > > On Wed, Nov 28, 2018 at 03:47:22PM -0600, Rob Herring wrote: > > > > 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? > > > > > > Yes. > > So, I gather this SPL is essentially a first-stage bootloader? I'm Yes. > wondering if fdt is actually the right tool for the job here. Could > you instead make just a hardcoded structure with the minimal known > values that the first stage loader needs to find the second stage, > which would include the full DT. I'm envisaging that you'd have some > tool for building that first-stage structure from the fdt, but that > would be done at build time, not runtime. This is the goal of the 'dtoc' tool in U-Boot. It creates header files and structs to hold data from the DT. Would you be open to upstreaming this? > > > > > 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. > > > > > > No, we're already stripping stuff out and while we have the sunxi case > > > functional today it's one of the cases that keeps hitting the ceiling. > > > So both the dtb itself and being able to parse it in very constrained > > > environments are important to us. I'll let Simon chime in more now :) > > > > Yes we are doing all of that and more. See slides at [5] for details. > > For example firefly-rk3288 reduces from ~40KB to ~3KB. > > > > The fdtgrep tool allows dropping of nodes and properties based on > > various search terms. It has not been upstreamed so far. Well, it was > > attempted but did not get far and I have not tried again. > > > > Regards, > > Simon > > > > [5] https://www.elinux.org/images/1/15/Device_tree_in_U-Boot_SPL.pdf > > > > -- > 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 - Simon
