linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Timur Tabi <timur@freescale.com>
To: "Ira W. Snyder" <iws@ovro.caltech.edu>
Cc: Kumar Gala <kumar.gala@freescale.com>, linuxppc-dev@lists.ozlabs.org
Subject: Re: CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?)
Date: Thu, 9 Sep 2010 16:19:45 -0500	[thread overview]
Message-ID: <4C894F71.4050408@freescale.com> (raw)
In-Reply-To: <20100909205507.GG3496@ovro.caltech.edu>

Ira W. Snyder wrote:
> I have no idea how to determine this.
> 
> The code that caused the problem runs so early in boot that the MMU is
> not running yet. Looking through the tiny bit of code, it appears that
> it just uses whatever the bootloader set up for it. It hasn't gotten to
> the initial_bats function yet.

I just spoke to Kumar, and he said that the 8MB is just historical.  We ran
into the same exact problem that you ran into, except it was with a normal
kernel, so we changed 8MB to 16MB on our 85xx boards, but we never went back
and made the same change to 83xx boards.

So it should be safe to change CONFIG_SYS_BOOTMAPSZ from 8MB to 16MB on all
83xx systems.  However, U-Boot does not verify that CONFIG_SYS_BOOTMAPSZ <=
the actual amount of RAM in the system, so we need to make sure that
CONFIG_SYS_BOOTMAPSZ isn't increased on any board that actually did ship
with only 8MB of RAM.  My guess is that no such board exists, but I will get
confirmation.

However, this comment for CONFIG_SYS_BOOTMAPSZ still bothers me:

/*
 * For booting Linux, the board info and command line data
 * have to be in the first 8 MB of memory, since this is
 * the maximum mapped by the Linux kernel during initialization.
 */

This same comment says 16MB on 85xx systems, so I don't think the statement
about "maximum mapped by the Linux kernel" is really true.  Maybe someone
else can shed some light on this.

> I think the MPC8349EA would be a 603 CPU, meaning that we could increase
> CONFIG_SYS_BOOTMAPSZ up to 256MB (if the board had that much RAM).

Except that I'm still not sure what CONFIG_SYS_BOOTMAPSZ really means.  I
was under the impression that CONFIG_MAX_MEM_MAPPED is the actual value of
the size of the mapping that U-Boot creates for the kernel.  When the kernel
initializes the MMU for its own purposes, does it limit anything to 16MB?  I
seriously doubt it.

> You'll see that your patch now relocated the FDT. It didn't cause any
> problems. I'll post to the thread on the U-Boot ML.

Yes, please.  I need someone to confirm that he tested my patch.

-- 
Timur Tabi
Linux kernel developer at Freescale

  reply	other threads:[~2010-09-09 21:20 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 [this message]
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=4C894F71.4050408@freescale.com \
    --to=timur@freescale.com \
    --cc=iws@ovro.caltech.edu \
    --cc=kumar.gala@freescale.com \
    --cc=linuxppc-dev@lists.ozlabs.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).