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:36:31 -0500 [thread overview]
Message-ID: <4C89454F.8070701@freescale.com> (raw)
In-Reply-To: <20100909203142.GF3496@ovro.caltech.edu>
Ira W. Snyder wrote:
> That did it!
Yea!
> I'm using include/configs/MPC8349EMDS.h. On that board,
> CONFIG_SYS_BOOTMAPSZ is 8MB. Boosting it to 16MB fixed the problem and
> the kernel now boots.
Ah, yes. I believe the reason that is the case is because some of those
boards were shipped with only 8MB of RAM.
> I'll make a post to the U-Boot list asking if this should be boosted for
> MPC8349EMDS (and others?). It is easy to build a kernel that overruns
> this limit. Other than debugging options, my kernel is fairly minimal,
> only a few drivers are built in.
I think we should first determine if the kernel boot map limit really is
16MB. If it's more than that, then we should consider making it match.
Assuming, of course, that the U-Boot code can handle a situation where
CONFIG_SYS_BOOTMAPSZ is larger than the actual amount of RAM.
> I'm using your always-relocate-fdt patch. Your patch made no difference
> to the FDT location. U-Boot with and without your patch bo
My patch only does something if the FDT is already located inside the boot
map. Since you were expanding the size of the boot map, there's a chance
that the FDT was located between 8MB and 16MB, and if so, my patch would
have made a difference.
--
Timur Tabi
Linux kernel developer at Freescale
next prev parent reply other threads:[~2010-09-09 20:36 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 [this message]
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=4C89454F.8070701@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).