public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: llandre <r&d2@dave-tech.it>
To: Ram <vshrirama@gmail.com>
Cc: linux-mtd@lists.infradead.org
Subject: Re: Micron NAND support in linux MTD
Date: Mon, 21 Jan 2008 10:51:38 +0100	[thread overview]
Message-ID: <47946B2A.1030400@dave-tech.it> (raw)
In-Reply-To: <8bf247760801180745k6f8337d5p751d91b21bd3728d@mail.gmail.com>

Sriram,

IIUC the bad block position is set in function nand_get_flash_type:

	/* Set the bad block position */
	chip->badblockpos = mtd->writesize > 512 ?
		NAND_LARGE_BADBLOCK_POS : NAND_SMALL_BADBLOCK_POS;


/*
* Constants for oob configuration
*/
#define NAND_SMALL_BADBLOCK_POS		5
#define NAND_LARGE_BADBLOCK_POS		0

That is two values are defined:
a) 5 for small block devices (6th location)
b) 0 for large block devices (1st location)

So the position is correct with respect to the Micron MT29F1GxxABB 
datasheet.
However I still have a doubt about which page is checked. I'n not sure 
if JFFS2/MTD check first page only. Datasheet says:

"The factory identifies
invalid blocks before shipping by programming data other than FFh (x8) 
or FFFFh (x16) into the first spare location (column address 2,048 for 
x8 devices, or 1,024 for x16 devices) *of the first or second page of 
each bad block*."

so both first and second page should be checked. Do you know what 
JFFS2/MTD do?


-- 
llandre



> Hi,
>    The location of the "bad block indicator" within the spare area
> depends on the
>     manufacturer. It could vary from chip to chip.
> 
>    it could also depend on the page size as well.
> 
>    Usually, for a large page size nand, It could be located at the
> first byte of the OOB.
>    For a small it could be at 6th byte.
> 
>   The way you send some commands to the large page size nand device is
> somewhat different
>   from the small page size nand device. I think you may not be using
> the driver for a large page  nand device.
> 
>   Most of the stuff (driver) for the large page nand devices is
> generic. The way you wait for nand busy changes.
> 
>   Check the way your reading the flash information from the chip id
> and additional infomation.
>   The way youre mtd_info structure is getting initialised. You could
> be missing something here.
> 
> Hope this helps.
> 
> Regards,
> sriram
> 
> 
> 
> 
> On Jan 18, 2008 3:48 PM, llandre <r&d2@dave-tech.it> wrote:
>> Hi,
>>
>> I found on MTD mailing list your patch that adds Micron manufacturer ID:
>> http://article.gmane.org/gmane.linux.drivers.mtd/17694
>>
>> I'm going to use NAND Micron devices for a new project however I still
>> have a doubt about how MTD/JFFS2 handle bad blocks. To detect blocks
>> marked as bad it checks the 6th location of OOB area of first page, thus
>> it seems it is not able to handle Micron devices properly. In fact these
>> devices stores bad block marker in the first location of OOB of first or
>> second page (for example see page 50 of MT29F1GxxABB data sheet). Am I
>> misreading the datasheet? Could you help me to clear this point?
>>
>>
>> Thanks in advance,
>> llandre
>>
>> DAVE Electronics System House - R&D Department
>> web:   http://www.dave-tech.it
>> email: r&d2@dave-tech.it
>>
>> ______________________________________________________
>> Linux MTD discussion mailing list
>> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>>
> 
> 

  reply	other threads:[~2008-01-21  9:52 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-18 10:18 Micron NAND support in linux MTD llandre
2008-01-18 15:45 ` Ram
2008-01-21  9:51   ` llandre [this message]
2008-01-21 10:06     ` Ricard Wanderlof
2008-01-21 11:21       ` llandre
2008-01-21 11:45         ` Ricard Wanderlof

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=47946B2A.1030400@dave-tech.it \
    --to=r&d2@dave-tech.it \
    --cc=linux-mtd@lists.infradead.org \
    --cc=vshrirama@gmail.com \
    /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