lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 27 Mar 2014 17:59:58 +0800
From:	Huang Shijie <b32955@...escale.com>
To:	Lothar Waßmann <LW@...O-electronics.de>
CC:	Fabio Estevam <fabio.estevam@...escale.com>,
	Mark Rutland <mark.rutland@....com>,
	Shawn Guo <shawn.guo@...aro.org>,
	Russell King <linux@....linux.org.uk>,
	Pawel Moll <pawel.moll@....com>, Arnd Bergmann <arnd@...db.de>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Artem Bityutskiy <artem.bityutskiy@...ux.intel.com>,
	<linux-doc@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	<devicetree@...r.kernel.org>, Rob Herring <robh+dt@...nel.org>,
	<linux-mtd@...ts.infradead.org>,
	<linux-arm-kernel@...ts.infradead.org>,
	Rob Landley <rob@...dley.net>,
	Kumar Gala <galak@...eaurora.org>,
	Brian Norris <computersforpeace@...il.com>,
	David Woodhouse <dwmw2@...radead.org>,
	Sascha Hauer <kernel@...gutronix.de>,
	Shawn Guo <shawn.guo@...escale.com>
Subject: Re: [PATCHv2 1/1] mtd: gpmi: make blockmark swapping optional

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ