linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
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

  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).