On Mon, Dec 3, 2018 at 12:20 PM Simon Glass <sjg@xxxxxxxxxxxx> 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? Are you aware Zephyr is doing something similar[1]? I'd think we'd only want something in dtc if we can align with them. Even there's different needs on the output, there's probably still some parts that could be shared. I'm thinking things like address translation. Rob [1] https://docs.zephyrproject.org/latest/devices/dts/device_tree.html
