From: Jerry Van Baren <gvb.linuxppc.dev@gmail.com>
To: Scott Wood <scottwood@freescale.com>
Cc: linuxppc-dev@ozlabs.org, Paul Mackerras <paulus@samba.org>
Subject: Re: [PATCH 3/4] Use embedded libfdt in the bootwrapper
Date: Fri, 09 Nov 2007 20:14:59 -0500 [thread overview]
Message-ID: <47350613.7000606@gmail.com> (raw)
In-Reply-To: <473483DF.7060903@freescale.com>
Scott Wood wrote:
> Jerry Van Baren wrote:
>> My concern from the u-boot side is that u-boot has to know exactly
>> *where* to put the expanded blob because it has to pass it to linux
>> and keep it out of linux' way so it doesn't get "stepped on." Linux
>> has an advantage in that it "owns" all of memory and can allocate and
>> deallocate whatever and wherever and it won't step on itself (hopefully).
>
> Linux is pretty careful not to step on the device tree; it marks the
> area as reserved, and moves it if it really has to. The only scenario I
> think would be problematic is if the kernel is started somewhere other
> than zero, and has to relocate itself, and the relocation clobbers the
> device tree. That's easily avoided by making sure the device tree is at
> a higher address than the kernel -- and is really not much different
> than the old bd_t mechanism, which didn't use a user provided address
> AFAIK.
That is good to know, makes things much easier.
>> I'm assuming your boot wedge has the advantage of being able to use
>> linux's malloc() and thus don't have to worry about coordinating with
>> linux on memory allocation.
>
> No, it uses its own malloc.
>
>> With the current u-boot fdt command, you can resize the blob, and this
>> can be done in a script with all the (somewhat limited) capabilities
>> of the u-boot shell (an adaptation of hush).
>
> OK, I'm just going by the behavior of the default boot commands on (at
> least some of) our boards, which just give you an error if the blob
> isn't already enlarged.
>
> Maybe I should just poke Kim et al. about fixing our default environment
> -- though I'm guessing it'd still have to know from the script how much
> to enlarge the blob.
Currently it is a manual thing, my point was that it is potentially
scriptable (but would probably take a genius or 3 days of
experimentation to make the script work ;-). If we can settle on a safe
way to expand the blob automatically, I'm all for that.
>> In the u-boot world, we fixate on memory maps and putting things in
>> specific places.
>
> I've noticed. :-)
>
> -Scott
Yeah, I had a ruder term than "fixate" but changed it for public
consumption. ;-)
Best regards,
gvb
next prev parent reply other threads:[~2007-11-10 1:12 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-08 3:32 [0/4] Embed dtc and libfdt in the kernel David Gibson
2007-11-08 3:36 ` [PATCH 3/4] Use embedded libfdt in the bootwrapper David Gibson
2007-11-08 16:08 ` Scott Wood
2007-11-08 22:40 ` David Gibson
2007-11-08 22:50 ` Scott Wood
2007-11-08 23:29 ` David Gibson
2007-11-09 0:52 ` Jerry Van Baren
2007-11-09 15:59 ` Scott Wood
2007-11-10 1:14 ` Jerry Van Baren [this message]
2007-11-08 3:36 ` [PATCH 2/4] Use embedded dtc in kernel builds David Gibson
2007-11-08 3:36 ` [PATCH 4/4] Kill flatdevtree.c David Gibson
2007-11-08 14:27 ` Jon Loeliger
2007-11-08 3:38 ` [1/4] Merge dtc and libfdt upstream source David Gibson
-- strict thread matches above, loose matches on Subject: below --
2007-11-12 4:11 [0/4] Embed dtc and libfdt in the kernel (spin the third) David Gibson
2007-11-12 4:15 ` [PATCH 3/4] Use embedded libfdt in the bootwrapper David Gibson
2007-12-03 4:30 ` David Gibson
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=47350613.7000606@gmail.com \
--to=gvb.linuxppc.dev@gmail.com \
--cc=linuxppc-dev@ozlabs.org \
--cc=paulus@samba.org \
--cc=scottwood@freescale.com \
/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).