From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Date: Wed, 29 Feb 2012 16:37:32 -0600 Subject: [U-Boot] Nand dump and nand bad block disagree In-Reply-To: <201202291734.39594.vapier@gentoo.org> References: <201202291406.29073.vapier@gentoo.org> <4F4E77F8.2030908@freescale.com> <201202291734.39594.vapier@gentoo.org> Message-ID: <4F4EA8AC.6040602@freescale.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 02/29/2012 04:34 PM, Mike Frysinger wrote: > On Wednesday 29 February 2012 14:09:44 Scott Wood wrote: >> On 02/29/2012 01:06 PM, Mike Frysinger wrote: >>> On Wednesday 29 February 2012 04:02:39 jean-philippe francois wrote: >>>> Le 29 f?vrier 2012 00:40, Scott Wood a ?crit : >>>>> Is this a 16-bit NAND? If so, the first two bytes have to be 0xffff, >>>>> unless the controller driver defines the bad block pattern differently. >>>> >>>> It is an 8 bit nand. The badblock patern can be redefined by the >>>> controller driver to be different from the one in nand_base.c ? Do you >>>> have an example of this ? >>> >>> look at the Blackfin nand driver (in u-boot and linux). we have to >>> override the badblock layout because our on-chip boot rom expects >>> something other than what linux uses. >> >> But be careful when doing this -- it really should match what >> manufacturers will write. > > yep > > on the Blackfin side, nothing to be done now. the rom team didn't consult with > the linux team before implementing things, and these roms are fixed in the > processor, and they can't change now without breaking backwards compat. Do you migrate the bad block markers to the new location prior to using a chip? -Scott