linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: b32955@freescale.com (Huang Shijie)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCHv2 1/1] mtd: gpmi: make blockmark swapping optional
Date: Thu, 27 Mar 2014 17:59:58 +0800	[thread overview]
Message-ID: <20140327095956.GA29623@localhost> (raw)
In-Reply-To: <20140326125502.0e8d0657@ipc1.ka-ro>

On Wed, Mar 26, 2014 at 12:55:02PM +0100, Lothar Wa?mann wrote:
> Hi,
> 
> Huang Shijie wrote:
> > ? 2014?03?26? 16:51, Lothar Wa?mann ??:
> > > I don't see why this should not be supported on i.MX28 (i.MX23 doesn't
> > > do byteswapping anyway, so this wouldn't change anything for i.MX23).
> > > The partitions used by Linux need not necessarily be accessible for the
> > > Boot ROM code (and vice versa).
> > But the first partition used to store the u-boot is accessible for the ROM.
> > 
> Whether this partition is available to Linux depends on the partition table
> passed in the DT.
yes, i agree.

But it is strange if we do not export this partition to Linux.

> 
> > 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
--------------------------------------------------------------------

thanks
Huang Shijie

  reply	other threads:[~2014-03-27  9:59 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-19 13:23 [PATCH] mtd: gpmi: make blockmark swapping optional y at karo-electronics.de
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 [this message]
2014-03-27 12:21               ` Lothar Waßmann
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
2014-03-28 10:35 ` [PATCHv3 0/2] " Lothar Waßmann
2014-03-28 10:35   ` [PATCHv3 1/2] " Lothar Waßmann
2014-03-31  2:06     ` Huang Shijie
2014-03-28 10:35   ` [PATCHv3 2/2] of/mtd/nand: add generic binding and helper for NAND_BBT_NO_OOB_BBM 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=20140327095956.GA29623@localhost \
    --to=b32955@freescale.com \
    --cc=linux-arm-kernel@lists.infradead.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;
as well as URLs for NNTP newsgroup(s).