From: Timur Tabi <timur@freescale.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] libfdt: make fdt_increase_size() available to everyone
Date: Wed, 26 May 2010 12:56:27 -0500 [thread overview]
Message-ID: <4BFD60CB.5000806@freescale.com> (raw)
In-Reply-To: <20100526172312.GA4057@schlenkerla.am.freescale.net>
Scott Wood wrote:
> On Wed, May 26, 2010 at 11:38:27AM -0500, Timur Tabi wrote:
>> I believe we should have a board-specific function that figures out how much
>> extra space is needed, and just returns a single integer that the
>> boot_relocate_fdt() uses to pad the FDT when it relocates it.
>
> Why don't we just grow the FDT on demand, after we make sure that it always
> lives someplace that is safely growable?
We use lmb regions to allocate space for the fdt in the bootmap, so we need
to know how big the lmb region should be before we allocate it. Resizing an
lmb region will probably require moving it, and that might confuse the
upper-level functions that expect the fdt pointer to remain constant.
> Or if we absolutely must resize it all at once, have a variable that
> contains the size required, which gets increased by whatever init code
> determines a reason for it (whether it be QE firmware in this environment
> variable, some other firmware in that environment variable, just a bunch of
> nodes that u-boot creates on this platform, etc).
The issue is that how those functions will look. Kumar and I are advocating
a board-specific weak function that figures it all out at once and returns a
single number.
--
Timur Tabi
Linux kernel developer at Freescale
next prev parent reply other threads:[~2010-05-26 17:56 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-10 21:26 [U-Boot] [PATCH 2/3] libfdt: make fdt_increase_size() available to everyone Timur Tabi
2010-05-10 21:30 ` Timur Tabi
2010-05-13 17:46 ` Kumar Gala
2010-05-16 2:11 ` [U-Boot] " Gerald Van Baren
2010-05-16 4:13 ` Timur Tabi
2010-05-17 11:24 ` Jerry Van Baren
2010-05-17 13:16 ` Wolfgang Denk
2010-05-17 14:16 ` Timur Tabi
2010-05-17 20:33 ` Wolfgang Denk
2010-05-18 14:10 ` Timur Tabi
2010-05-18 15:18 ` Wolfgang Denk
2010-05-18 15:32 ` Timur Tabi
2010-05-18 22:20 ` Wolfgang Denk
2010-05-19 0:51 ` Timur Tabi
2010-05-19 6:54 ` Wolfgang Denk
2010-05-19 14:57 ` Timur Tabi
2010-05-19 15:14 ` Wolfgang Denk
2010-05-19 15:34 ` Timur Tabi
2010-05-19 15:44 ` Wolfgang Denk
2010-05-19 21:46 ` Kumar Gala
2010-05-19 22:06 ` Wolfgang Denk
2010-05-19 22:12 ` Timur Tabi
2010-05-20 8:28 ` Wolfgang Denk
2010-05-20 11:44 ` Timur Tabi
2010-05-25 16:07 ` Timur Tabi
2010-05-25 17:50 ` Wolfgang Denk
2010-05-25 18:01 ` Timur Tabi
2010-05-25 19:15 ` Wolfgang Denk
2010-05-25 19:28 ` Timur Tabi
2010-05-25 22:11 ` Wolfgang Denk
2010-05-26 15:11 ` Timur Tabi
2010-05-26 16:11 ` Wolfgang Denk
2010-05-26 16:38 ` Timur Tabi
2010-05-26 17:23 ` Scott Wood
2010-05-26 17:56 ` Timur Tabi [this message]
2010-05-26 18:06 ` Scott Wood
2010-05-26 18:23 ` Timur Tabi
2010-05-26 19:14 ` Wolfgang Denk
2010-05-26 19:08 ` Wolfgang Denk
2010-05-20 13:34 ` Kumar Gala
2010-05-20 12:58 ` Timur Tabi
2010-05-17 11:25 ` [U-Boot] [PATCH 2/3] " Jerry Van Baren
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=4BFD60CB.5000806@freescale.com \
--to=timur@freescale.com \
--cc=u-boot@lists.denx.de \
/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