From: Timur Tabi <timur@freescale.com>
To: "Ira W. Snyder" <iws@ovro.caltech.edu>
Cc: peterz@infradead.org, mingo@redhat.com, linuxppc-dev@lists.ozlabs.org
Subject: Re: CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?)
Date: Thu, 9 Sep 2010 15:13:17 -0500 [thread overview]
Message-ID: <4C893FDD.1000507@freescale.com> (raw)
In-Reply-To: <20100909200606.GE3496@ovro.caltech.edu>
Ira W. Snyder wrote:
> That easily overruns the location where U-Boot puts the FDT. Is this a
> U-Boot bug, meaning I should post this information on the U-Boot
> mailing list?
Possibly.
I am under the impression that the memory in the boot block that contains
the FDT is marked as "reserved" in the device tree, so that the kernel
doesn't overwrite it. However, that obviously isn't helpful if we haven't
parsed the device tree yet.
What concerns me is this in U-Boot:
/*
* For booting Linux, the board info and command line data
* have to be in the first 16 MB of memory, since this is
* the maximum mapped by the Linux kernel during initialization.
*/
#define CONFIG_SYS_BOOTMAPSZ (16 << 20) /* Initial Memory map for Linux*/
If the 16MB mapping limit is true, then does this mean that the Linux's BSS
is larger than the memory that is mapped? If so, that means that Linux
can't even access all of its BSS at this point. Somehow, I doubt that.
Can you try increasing the size of CONFIG_SYS_BOOTMAPSZ? Combined with my
always-relocate-fdt, I think this will force the FDT to be placed higher in
memory.
--
Timur Tabi
Linux kernel developer at Freescale
next prev parent reply other threads:[~2010-09-09 20:13 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 [this message]
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
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=4C893FDD.1000507@freescale.com \
--to=timur@freescale.com \
--cc=iws@ovro.caltech.edu \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
/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).