From: Scott Wood <scottwood@freescale.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] NOR NAND Interference question
Date: Mon, 7 Jan 2013 18:37:20 -0600 [thread overview]
Message-ID: <1357605440.1113.15@snotra> (raw)
In-Reply-To: <1357343226.16096.101.camel@andrei.linux> (from ayakimov@iptec-inc.com on Fri Jan 4 17:47:06 2013)
On 01/04/2013 05:47:06 PM, Andrei wrote:
> Hi,
> Recently I am start getting strange problem
> with u-boot-2011.09. MPC8313ERDB like
> configuration ( main change - I am using
> different NAND flash - 256MBib - need change
> page size)
Please always try with the latest U-Boot when you have a problem -- or
even when you don't have a problem. :-)
> If I am access NAND flash before nor
> u-boot not always read NOR correctly.
>
> >mtdparts
>
> device nor0 <phys_mapped_flash>, # parts = 3
> #: name size offset mask_flags
> 0: u-boot 0x000e0000 0x00000000 0
> 1: env 0x00020000 0x000e0000 0
> 2: jffs2 0x01f00000 0x00100000 0
>
> device nand0 <e2800000.flash>, # parts = 1
> #: name size offset mask_flags
> 0: ubifs 0x10000000 0x00000000 0
>
> If I do:
> ubi part ubifs;ubifsmount iptec_nand
>
> and read something from NAND before I read NOR
How much time passes between the NAND access and the NOR access? If
it's all part of a script, maybe the NAND access isn't quite finished
when the command returns.
We used to have problems on Linux with NAND and NOR interfering, though
I wouldn't think that it would be possible in U-Boot even with the old
broken code because of its single-tasking nature.
One thing you might want to try is applying Linux commit
476459a6cf46d20ec73d9b211f3894ced5f9871e ("mtd: eLBC NAND: use
recommended command sequences") to U-Boot.
> I found most stable configuration:
> mount NAND, read NAND,
> chaprt nor0,2
> boot
>
> and most unstable
> chaprt nor0,2
> mount NAND, read NAND,
> boot
I don't see "chaprt" in the U-Boot sources. Where did you get U-Boot
from?
I thought your problem was doing NAND before NOR, not the other way
around.
> And I did increase malloc size to 1M.( ubifs does not like 128K).
MPC8313ERDB has always had a malloc size of 512K -- where did 128K come
from?
> There is no option for stack size - it is PPC,
> so it should grow down as needed.
It grows down within the area that has been designated for the stack.
This area is not very large. Do you have any reason to believe you're
seeing stack issues?
-Scott
next prev parent reply other threads:[~2013-01-08 0:37 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-04 23:47 [U-Boot] NOR NAND Interference question Andrei
2013-01-08 0:37 ` Scott Wood [this message]
2013-01-09 0:44 ` Andrei
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=1357605440.1113.15@snotra \
--to=scottwood@freescale.com \
--cc=u-boot@lists.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox