From: "Lothar Waßmann" <LW@KARO-electronics.de>
To: Huang Shijie <b32955@freescale.com>
Cc: Fabio Estevam <fabio.estevam@freescale.com>,
Mark Rutland <mark.rutland@arm.com>,
Shawn Guo <shawn.guo@linaro.org>,
Russell King <linux@arm.linux.org.uk>,
Pawel Moll <pawel.moll@arm.com>, Arnd Bergmann <arnd@arndb.de>,
Ian Campbell <ijc+devicetree@hellion.org.uk>,
Artem Bityutskiy <artem.bityutskiy@linux.intel.com>,
<linux-doc@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<devicetree@vger.kernel.org>, Rob Herring <robh+dt@kernel.org>,
<linux-mtd@lists.infradead.org>,
<linux-arm-kernel@lists.infradead.org>,
Rob Landley <rob@landley.net>, Kumar Gala <galak@codeaurora.org>,
Brian Norris <computersforpeace@gmail.com>,
David Woodhouse <dwmw2@infradead.org>,
Sascha Hauer <kernel@pengutronix.de>,
Shawn Guo <shawn.guo@freescale.com>
Subject: Re: [PATCHv2 1/1] mtd: gpmi: make blockmark swapping optional
Date: Thu, 27 Mar 2014 13:21:09 +0100 [thread overview]
Message-ID: <20140327132109.06258526@ipc1.ka-ro> (raw)
In-Reply-To: <20140327095956.GA29623@localhost>
Hi,
Huang Shijie wrote:
> > > Please see "Figure 12-13" in the 12.12.1.12:
> > > "In order to preserve the BI (bad block information), flash updater
> > > or gang programmer
> > > applications need to swap Bad Block Information (BI) data to byte 0 of
> > > metadata area for
> > > every page before programming NAND Flash. ROM when loading firmware,
> > > copies back
> > > the value at metadata[0] to BI offset in page data. The following figure
> > > shows how the
> > > factory bad block marker is preserved."
> > >
> > The inspection of the BB markers is only a fallback for the case that
> > there is no DBBT. From the same chapter that you quoted above:
> > | ROM uses DBBT to skip any bad block that falls within firmware data
> > | on NAND Flash device.
> > | If the address of DBBT Search Area in FCB is 0, ROM will rely on
> > | factory marked bad block markers to find out if a block is good or bad.
> >
> > Thus, even the boot ROM of i.MX28 can well live without blockmark
> > swapping.
>
> Assume that there is a NAND block "A", and the A consist of 256 pages.
> the uboot is burned to the "A", can occupy 6 pages:
>
> -----------------------------------------------------------------------------
> | page 0 | page 1 | page 2 | page 3 | page 4 | page 5 | ... | ... | page 255 |
> -----------------------------------------------------------------------------
>
> \-------------------------------------- ------------------------------------/
> V
> "A"
>
> The DBBT is used to track if "A" is bad or not.
> Assume we know that "A" is a good block, ROM then need to read out the uboot.
> When the ROM needs to read out the 6 pages one by one. And each time the ROM read
> the page, it should do the swapping for this page.
>
> In this case, the ROM will do the swapping six times.
>
> Please read the sector again, you will see the "every page" in it:
> --------------------------------------------------------------------
> "In order to preserve the BI (bad block information), flash updater
> or gang programmer applications need to swap Bad Block Information (BI) data to byte 0 of
> metadata area for every page before programming NAND Flash. ROM when loading firmware,
> copies back
> --------------------------------------------------------------------
>
I can assure you that the >100.000 i.MX28 based modules, that we sold
up to now boot from NAND just fine without any block mark swapping in
the U-Boot pages.
Lothar Waßmann
--
___________________________________________________________
Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Geschäftsführer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996
www.karo-electronics.de | info@karo-electronics.de
___________________________________________________________
next prev parent reply other threads:[~2014-03-27 12:22 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-19 13:23 [PATCH] " y
2014-03-20 8:33 ` Juergen Beisert
2014-03-20 9:20 ` Lothar Waßmann
2014-03-20 9:15 ` Huang Shijie
2014-03-20 9:21 ` Lothar Waßmann
2014-03-20 9:47 ` Huang Shijie
2014-03-20 10:09 ` Lothar Waßmann
2014-03-20 10:56 ` Huang Shijie
2014-03-21 5:36 ` Huang Shijie
2014-03-21 10:50 ` [PATCHv2 1/1] " Lothar Waßmann
2014-03-24 9:59 ` Huang Shijie
2014-03-26 8:51 ` Lothar Waßmann
2014-03-26 10:41 ` Huang Shijie
2014-03-26 11:55 ` Lothar Waßmann
2014-03-27 9:59 ` Huang Shijie
2014-03-27 12:21 ` Lothar Waßmann [this message]
2014-03-28 2:09 ` Huang Shijie
2014-03-28 8:16 ` Lothar Waßmann
2014-03-28 8:39 ` Huang Shijie
2014-03-28 9:00 ` Sascha Hauer
2014-03-28 9:26 ` Huang Shijie
2014-03-28 9:31 ` Lothar Waßmann
2014-03-28 10:09 ` Huang Shijie
2014-03-28 10:18 ` Lothar Waßmann
2014-03-28 9:01 ` Lothar Waßmann
2014-03-28 9:33 ` Huang Shijie
2014-03-28 9:38 ` Huang Shijie
2014-03-28 10:13 ` Lothar Waßmann
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=20140327132109.06258526@ipc1.ka-ro \
--to=lw@karo-electronics.de \
--cc=arnd@arndb.de \
--cc=artem.bityutskiy@linux.intel.com \
--cc=b32955@freescale.com \
--cc=computersforpeace@gmail.com \
--cc=devicetree@vger.kernel.org \
--cc=dwmw2@infradead.org \
--cc=fabio.estevam@freescale.com \
--cc=galak@codeaurora.org \
--cc=ijc+devicetree@hellion.org.uk \
--cc=kernel@pengutronix.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=linux@arm.linux.org.uk \
--cc=mark.rutland@arm.com \
--cc=pawel.moll@arm.com \
--cc=rob@landley.net \
--cc=robh+dt@kernel.org \
--cc=shawn.guo@freescale.com \
--cc=shawn.guo@linaro.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
all inboxes | Powered by JetHome®