All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ira W. Snyder" <iws@ovro.caltech.edu>
To: Timur Tabi <timur@freescale.com>
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 13:31:42 -0700	[thread overview]
Message-ID: <20100909203142.GF3496@ovro.caltech.edu> (raw)
In-Reply-To: <4C893FDD.1000507@freescale.com>

On Thu, Sep 09, 2010 at 03:13:17PM -0500, Timur Tabi wrote:
> 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.
> 

That did it!

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.

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'm using your always-relocate-fdt patch. Your patch made no difference
to the FDT location. U-Boot with and without your patch both work fine,
as soon as I boosted CONFIG_SYS_BOOTMAPSZ to 16MB.

With your patch:
   Booting using the fdt blob at 0x226a278
   Uncompressing Kernel Image ... OK
   Loading Ramdisk to 0fe9f000, end 0ff75699 ... OK
   Loading Device Tree to 00ff8000, end 00fff78f ... OK

Without your patch:
   Booting using the fdt blob at 0x226a278
   Uncompressing Kernel Image ... OK
   Loading Ramdisk to 0fe9f000, end 0ff75699 ... OK
   Loading Device Tree to 00ff8000, end 00fff78f ... OK


Thanks,
Ira

  reply	other threads:[~2010-09-09 20:31 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 [this message]
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=20100909203142.GF3496@ovro.caltech.edu \
    --to=iws@ovro.caltech.edu \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=timur@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.