mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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
___________________________________________________________

  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®