Re: Linux Plumbers v18 DT-format followup

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



On Wed, Dec 05, 2018 at 05:55:21AM -0700, Simon Glass wrote:
> Hi David,
> 
> On Mon, 3 Dec 2018 at 22:23, David Gibson <david@xxxxxxxxxxxxxxxxxxxxx> wrote:
> >
> > On Mon, Dec 03, 2018 at 11:20:17AM -0700, Simon Glass wrote:
> > > 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?
> >
> > I guess.  My first thought would be that such a tool would be more
> > closely linked to the specific bootloader than the DT as such, but if
> > it's widely useful enough then I'm happy to consider including it with
> > dtc.
> 
> OK. I think perhaps we could work with Zephyr to come up with a common solution.
> 
> The current tool is Python. Is that acceptable or should it be C?

As a build time tool, Python is fine.

-- 
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


[Index of Archives]     [Device Tree]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux