linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Scott Wood <scottwood@freescale.com>
Cc: peterz@infradead.org, mingo@redhat.com,
	linuxppc-dev@lists.ozlabs.org,
	"Ira W. Snyder" <iws@ovro.caltech.edu>
Subject: Re: CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?)
Date: Fri, 10 Sep 2010 08:16:18 +1000	[thread overview]
Message-ID: <1284070578.6515.41.camel@pasglop> (raw)
In-Reply-To: <1284070433.6515.39.camel@pasglop>

On Fri, 2010-09-10 at 08:13 +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2010-09-09 at 17:11 -0500, Scott Wood wrote:
> > > I would have expected uboot to warn (the kernel ELF header contains
> > the
> > > BSS size) but apparently that isn't the case.
> > 
> > U-Boot doesn't use ELF files with Linux, so it has no idea where the
> > BSS is.  uImage is just a wrapper around a flat binary.
> 
> Oh, right, I forgot about that... -1 for uboot there. Seriously, it's
> time it grows the ability to load ELF or to at least stick an ELF in a
> uImage... I've never understood the reasoning for that uImage wrapper
> thingy. Definitely causes more problems than it solves in my experience.

Note that with ePAPR we know the top of mapped memory on entry, so
in theory, if the bootloader is fully ePAPR compliant we -could- detect
that case and move the FDT up to after the .dts before we clear the
bss... do we care enough tho ?

Even if we aren't totally ePAPR compliant, we could still try to move
it, if we hit the end of memory well... we won't do more damage than we
already did by by overwriting the dts in the first place.

Cheers,
Ben.

  reply	other threads:[~2010-09-09 22:16 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-08 23:21 CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?) Ira W. Snyder
2010-09-09  1:02 ` Benjamin Herrenschmidt
2010-09-09  2:52   ` Ira W. Snyder
2010-09-09  2:58     ` Benjamin Herrenschmidt
2010-09-09 16:23       ` Ira W. Snyder
2010-09-09 18:44         ` Ira W. Snyder
2010-09-09 19:10           ` Timur Tabi
2010-09-09 19:36             ` Ira W. Snyder
2010-09-09 19:40               ` Timur Tabi
2010-09-09 20:06                 ` Ira W. Snyder
2010-09-09 20:13                   ` Timur Tabi
2010-09-09 20:31                     ` Ira W. Snyder
2010-09-09 20:36                       ` Timur Tabi
2010-09-09 20:55                         ` Ira W. Snyder
2010-09-09 21:19                           ` Timur Tabi
2010-09-09 22:01               ` Benjamin Herrenschmidt
2010-09-09 19:33           ` Ira W. Snyder
2010-09-09 21:58         ` Benjamin Herrenschmidt
2010-09-09 22:11           ` Scott Wood
2010-09-09 22:13             ` Benjamin Herrenschmidt
2010-09-09 22:16               ` Benjamin Herrenschmidt [this message]
2010-09-09 22:37               ` Scott Wood
2010-09-09 22:49                 ` Benjamin Herrenschmidt
2010-09-10 11:29                 ` Wolfgang Denk

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=1284070578.6515.41.camel@pasglop \
    --to=benh@kernel.crashing.org \
    --cc=iws@ovro.caltech.edu \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.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).