All of lore.kernel.org
 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 4/4] Kill flatdevtree.c David Gibson
2007-11-08 14:27   ` Jon Loeliger
2007-11-08  3:36 ` [PATCH 2/4] Use embedded dtc in kernel builds David Gibson
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.