From: Wolfgang Denk <wd@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] libfdt: make fdt_increase_size() available to everyone
Date: Thu, 20 May 2010 00:06:28 +0200 [thread overview]
Message-ID: <20100519220628.6CBC2E5C89E@gemini.denx.de> (raw)
In-Reply-To: <52E9D06A-E721-4907-9024-11BDC8D006E0@kernel.crashing.org>
Dear Kumar Gala,
In message <52E9D06A-E721-4907-9024-11BDC8D006E0@kernel.crashing.org> you wrote:
> So I tried to read this whole thread and got lost in the discussion.
> I'm wondering of something along the following lines would address your
> concerns:
My concerns are simple: if we need to increase the size of the FDT
because we pull in some random amountof data, we should make sure to
have enough room for this, or fail with a clear error message.
And we should not try to use fixed sized buffers, but instead adapt
to the actual amount required by the end user.
Timur assumes that all such code and it's sizess will be known in
advance, and I disagree - other users will have other ideas what they
can do with this, and his assumptions will break.
> #define CONFIG_SYS_FDT_PAD 0x3000
Where exactly is this 0x3000 coming from?
> /* Allow for arch specific config before we boot */
> int __fdt_board_size(void)
> {
> return CONFIG_SYS_FDT_PAD;
> }
> int fdt_board_size(void) __attribute__((weak, alias("__
> fdt_board_size")));
>
>
> int boot_relocate_fdt (struct lmb *lmb, ulong bootmap_base,
> char **of_flat_tree, ulong *of_size)
> {
> ...
>
> if ((fdt_blob + *of_size + fdt_board_size()) >=
> ((char *)CONFIG_SYS_BOOTMAPSZ + bootmap_base))
> relocate = 1;
>
> ...
> }
>
> Than board specific code knows what fix ups might happen and can
> implement dynamic behavior and do something like:
If any board specific code can determine the needed sizes, then how
would such code differ from one board to another?
Why would this in any way be a board specific implementation? This
makes no sense to me. The feature to include some binary data into the
DTB is IMO in no way dependent on or specific to a certain board.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
To program is to be.
next prev parent reply other threads:[~2010-05-19 22:06 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 [this message]
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
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=20100519220628.6CBC2E5C89E@gemini.denx.de \
--to=wd@denx.de \
--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