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
next prev parent 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: linkBe 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.