From: Marek Vasut <marek.vasut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org>
Cc: Frank Rowand
<frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Devicetree Compiler
<devicetree-compiler-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"devicetree-spec-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<devicetree-spec-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Jon Loeliger <jdl-CYoMK+44s/E@public.gmane.org>,
"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Pantelis Antoniou
<pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>,
"Pantelis
Antomarek.vasut-Re5JQEeQqe/2sr8fMPgRzw@public.gmane.org"
<panto-wVdstyuyKrO8r51toPun2/C9HSW9iNxf@public.gmane.org>,
Grant Likely
<grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>,
Tom Rini <trini-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>,
Kyle Evans <kevans-h+KGxgPPiopAfugRpC6u6w@public.gmane.org>,
Geert Uytterhoeven
<geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org>,
Alan Tull <atull-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Michael Ellerman <mpe-Gsx/Oe8HsFggBc27wqDAHg@public.gmane.org>
Subject: Re: [RFC] devicetree: new FDT format version
Date: Sat, 27 Jan 2018 21:30:11 +0100 [thread overview]
Message-ID: <5a943937-3b59-514b-3939-df25daea5470@gmail.com> (raw)
In-Reply-To: <20180125123734.GC2099@umbus>
On 01/25/2018 01:37 PM, David Gibson wrote:
> On Thu, Jan 25, 2018 at 10:14:38AM +0100, Marek Vasut wrote:
>> On 01/23/2018 10:17 PM, Frank Rowand wrote:
>> [...]
>>> My knowledge of bootloader use of the FDT is nearly non-existent, so
>>> I'm on thin ice here. But I am guessing that a lot of bootloader
>>> processing of FDT data could be removed if the kernel would unflatten
>>> a chained FDT and overlay FDT(s).
>>>
>>> Comments from the bootloader folks on this topic would be much
>>> appreciated.
>>
>> U-Boot, when using DT as a hardware-description (rather than just
>> passing it to Linux) usually operates on the FDT, unless explicitly
>> configured to unflatten the tree. That later option is not enabled by
>> default.
>>
>> The reason for that is so that the DT can be accessed very early on, at
>> which point there may not be any other memory available than a very
>> limited stack and the FDT blob can still be located in some read-only
>> memory.
>
> Right, this is exactly the reason that the fdt format is designed so
> you can read thing from it directly. If you're doing more than very
> minor modifications, however, it does become worth unflattening.
Right
> Note that while unflatenning requires an allocator of sorts, it can be
> a trivial one. A bump allocator in a fixed buffer of reasonable size
> would do fine. You don't realy need a free(), since the bootloader
> has limited lifetime you can just leak nodes until you throw the lot
> away.
There's a regular mallocator in later stages of u-boot and a small
allocator for the early stages if needed. It's only the early one that
doesn't implement free() and it's only used for a very short time when
the system is still running from flash.
Thus far, I don't see a usecase for unflattening the tree that early,
but maybe one will come in the future.In the later stages, the design is
that you do unflatten only if you have a system which benefits from it
and has the resources to do that. Modern systems usually do, but there
are systems with weird limitations.
Since you can do a lot more than just booting with u-boot, leaking any
memory is a really bad idea.
> You can also use pointers into the flattened tree blob to avoid
> allocating space for the actual property values (except for ones you
> add later, obviously). And if you make extensive enough changes that
> leaked pieces really do become a problem, you could do a
> flatten/unflatten pass to recompact everything.
--
Best regards,
Marek Vasut
next prev parent reply other threads:[~2018-01-27 20:30 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-22 8:09 [RFC] devicetree: new FDT format version Frank Rowand
[not found] ` <b96829f9-2e8b-fdc5-5090-58591e2260cf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2018-01-22 8:14 ` Frank Rowand
[not found] ` <ec68cfb3-4702-ba00-e926-3ad63b20b199-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2018-01-22 20:08 ` Frank Rowand
2018-01-22 20:08 ` Frank Rowand
[not found] ` <bc44f051-835d-1c8d-a928-be0fd4ef80b5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2018-01-25 0:27 ` Frank Rowand
[not found] ` <b5a72db1-45b2-f21f-9afd-0991b288840e-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2018-01-27 8:48 ` David Gibson
2018-01-29 8:08 ` Frank Rowand
[not found] ` <2c352396-154e-ea75-c50b-0f2bfafd19da-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2018-01-29 10:56 ` David Gibson
2018-01-30 1:29 ` Frank Rowand
2018-01-22 21:01 ` Rob Herring
[not found] ` <CAL_JsqJR2y7bMw_-9TBAGWZ_kf7_sZo5qvqvRowJ8jiy=4G0Bg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-01-23 12:42 ` David Gibson
2018-01-23 21:17 ` Frank Rowand
[not found] ` <20328477-e511-e875-7dc4-253640f2219e-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2018-01-24 15:47 ` Rob Herring
[not found] ` <CAL_Jsq+fvFrGhqO0zbEUE_i23FkU=G4Z1-e0vnXHi4KbS2oK0A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-01-24 21:16 ` Frank Rowand
[not found] ` <e1bec77d-4dac-200b-34be-23573bf738f0-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2018-01-24 22:27 ` Alan Tull
2018-01-25 0:22 ` Frank Rowand
[not found] ` <e986435b-481b-2629-7600-10d9e21ac58e-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2018-01-25 12:29 ` David Gibson
2018-01-25 20:01 ` Frank Rowand
[not found] ` <72d30756-a963-92c9-1838-3e3f80c57e39-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2018-01-29 18:32 ` Grant Likely
[not found] ` <CACxGe6tUB3NhNhOtqzoJfThx=RE1_=TSDQz+wQUm=sdE5JirZQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-01-29 23:15 ` David Gibson
2018-01-26 8:56 ` Geert Uytterhoeven
[not found] ` <CAMuHMdV0jdj90uzqMx_wtvz=-KaagJG2_UQTm1DW3gzt6cNG6A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-01-26 8:59 ` Geert Uytterhoeven
2018-01-26 22:08 ` Frank Rowand
[not found] ` <83008da0-7383-ba2d-a239-e11ad7d1327d-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2018-01-27 9:00 ` David Gibson
2018-01-27 8:56 ` David Gibson
2018-01-25 23:11 ` Frank Rowand
2018-01-25 12:22 ` David Gibson
2018-01-25 9:14 ` Marek Vasut
[not found] ` <90983180-ae3b-5a31-9dc0-b62b978a0fba-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2018-01-25 12:37 ` David Gibson
2018-01-27 20:30 ` Marek Vasut [this message]
[not found] ` <5a943937-3b59-514b-3939-df25daea5470-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2018-01-29 0:53 ` David Gibson
2018-01-23 12:05 ` David Gibson
2018-01-23 21:28 ` Frank Rowand
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5a943937-3b59-514b-3939-df25daea5470@gmail.com \
--to=marek.vasut-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
--cc=atull-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org \
--cc=devicetree-compiler-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=devicetree-spec-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org \
--cc=grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org \
--cc=jdl-CYoMK+44s/E@public.gmane.org \
--cc=kevans-h+KGxgPPiopAfugRpC6u6w@public.gmane.org \
--cc=mpe-Gsx/Oe8HsFggBc27wqDAHg@public.gmane.org \
--cc=pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w@public.gmane.org \
--cc=panto-wVdstyuyKrO8r51toPun2/C9HSW9iNxf@public.gmane.org \
--cc=robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=trini-OWPKS81ov/FWk0Htik3J/w@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).