All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heiko Schocher <hs@denx.de>
To: Scott Wood <scottwood@freescale.com>
Cc: Wolfgang Denk <wd@denx.de>,
	linuxppc-dev@ozlabs.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] [PowerPC] MPC8272ADS: fix device tree for 8 MB flash, size
Date: Fri, 15 May 2009 07:54:51 +0200	[thread overview]
Message-ID: <4A0D03AB.2040602@denx.de> (raw)
In-Reply-To: <20090514214819.GA15549@b07421-ec1.am.freescale.net>

Hello Scott,

Scott Wood wrote:
> On Wed, May 13, 2009 at 08:27:07AM +0200, Heiko Schocher wrote:
>> Hello Wolfgang,
>>
>>> The current device tree for the MPC8272ADS assumes a mapping of 32 MB
>>> of NOR flash at 0xFE00.0000, while there are actually only 8 MB on
>>> the boards, mapped at 0xFF80.0000. When booting an uImage with such a
>>> device tree, the kernel crashes because 0xFE00.0000 is not mapped.
>> Wouldn;t it be better, if u-boot fixes the device tree entries?
> 
> We should proabbly leave out the ranges altogether, and have u-boot
> populate it from the mappings it establishes.

No, I vote for manipulating just the entries, which u-boot dynamically
detect, and let the other entries untouched. It is possible that
there is a device which u-boot didn;t use/know, and there is in the DTS
an ranges entry for it (Maybe not on the MPC8727ADS, but we should
define a rule, how a bootloader has to manipulate entries). So if
u-boot build the complete ranges entry, it maybe miss something.

>> I think, u-boot should know, where the flash begins and ends, and
>> because this is maybe a dynamic variable for this board, it should
>> be better, if u-boot fixes this, so no need for adding a device tree
>> for every board variant.
> 
> Flash is on a SIMM on this board, and the board manual says it's
> expandable to 32 MiB.  However, I suspect that the current DTS was just
> an error as I based it on a board that had not had its flash SIMM
> modified.  That specific flash SIMM is no longer working (or perhaps just
> got its contents corrupted -- one of these days I may hook up a BDI and
> try to reflash), so I can't go back and check.
> 
> I don't see how current u-boot would accomodate more than 8MiB flash on
> this board (there's some detection in board/freescale/mpc8260ads/flash.c,

Didn;t this board uses the CFI driver? :-(

> but I don't see any setting of BR0 besides the preliminary value at
> 0xff800000).

OK, then the patch from Wolfgang should be sufficient.

bye
Heiko
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

WARNING: multiple messages have this Message-ID (diff)
From: Heiko Schocher <hs@denx.de>
To: Scott Wood <scottwood@freescale.com>
Cc: linuxppc-dev@ozlabs.org, Wolfgang Denk <wd@denx.de>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] [PowerPC] MPC8272ADS: fix device tree for 8 MB flash, size
Date: Fri, 15 May 2009 07:54:51 +0200	[thread overview]
Message-ID: <4A0D03AB.2040602@denx.de> (raw)
In-Reply-To: <20090514214819.GA15549@b07421-ec1.am.freescale.net>

Hello Scott,

Scott Wood wrote:
> On Wed, May 13, 2009 at 08:27:07AM +0200, Heiko Schocher wrote:
>> Hello Wolfgang,
>>
>>> The current device tree for the MPC8272ADS assumes a mapping of 32 MB
>>> of NOR flash at 0xFE00.0000, while there are actually only 8 MB on
>>> the boards, mapped at 0xFF80.0000. When booting an uImage with such a
>>> device tree, the kernel crashes because 0xFE00.0000 is not mapped.
>> Wouldn;t it be better, if u-boot fixes the device tree entries?
> 
> We should proabbly leave out the ranges altogether, and have u-boot
> populate it from the mappings it establishes.

No, I vote for manipulating just the entries, which u-boot dynamically
detect, and let the other entries untouched. It is possible that
there is a device which u-boot didn;t use/know, and there is in the DTS
an ranges entry for it (Maybe not on the MPC8727ADS, but we should
define a rule, how a bootloader has to manipulate entries). So if
u-boot build the complete ranges entry, it maybe miss something.

>> I think, u-boot should know, where the flash begins and ends, and
>> because this is maybe a dynamic variable for this board, it should
>> be better, if u-boot fixes this, so no need for adding a device tree
>> for every board variant.
> 
> Flash is on a SIMM on this board, and the board manual says it's
> expandable to 32 MiB.  However, I suspect that the current DTS was just
> an error as I based it on a board that had not had its flash SIMM
> modified.  That specific flash SIMM is no longer working (or perhaps just
> got its contents corrupted -- one of these days I may hook up a BDI and
> try to reflash), so I can't go back and check.
> 
> I don't see how current u-boot would accomodate more than 8MiB flash on
> this board (there's some detection in board/freescale/mpc8260ads/flash.c,

Didn;t this board uses the CFI driver? :-(

> but I don't see any setting of BR0 besides the preliminary value at
> 0xff800000).

OK, then the patch from Wolfgang should be sufficient.

bye
Heiko
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

  reply	other threads:[~2009-05-15  6:09 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.7754.1242158509.26545.linuxppc-dev@ozlabs.org>
2009-05-13  6:27 ` [PATCH] [PowerPC] MPC8272ADS: fix device tree for 8 MB flash, size Heiko Schocher
2009-05-13  6:27   ` Heiko Schocher
2009-05-14 21:48   ` Scott Wood
2009-05-14 21:48     ` Scott Wood
2009-05-15  5:54     ` Heiko Schocher [this message]
2009-05-15  5:54       ` Heiko Schocher
2009-05-15 15:36       ` Scott Wood
2009-05-12 19:06 [PATCH] [PowerPC] MPC8272ADS: fix device tree for 8 MB flash size Wolfgang Denk
2009-05-12 19:06 ` Wolfgang Denk
2009-05-13 10:28 ` Li Yang
2009-05-13 10:28   ` Li Yang
2009-05-13 19:42   ` Wolfgang Denk
2009-05-13 19:42     ` Wolfgang Denk
2009-05-20 13:29     ` Kumar Gala
2009-05-20 13:29       ` Kumar Gala
2009-05-20 14:47       ` Scott Wood
2009-05-20 14:47         ` Scott Wood
2009-06-11  1:51 ` Kumar Gala
2009-06-11  1:51   ` Kumar Gala

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=4A0D03AB.2040602@denx.de \
    --to=hs@denx.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=scottwood@freescale.com \
    --cc=wd@denx.de \
    /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.