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 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. > > > 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
Attachment:
signature.asc
Description: PGP signature
