OneNAND: Always print error messages

OneNAND: Always print error messages

[Kyungmin Park]

Hi,


> > Yes, simple solution is separate read oob from normal and scanning.
> > I think is is easy because we can use state variable, FL_SCANNING instead of FL_READING in bbt.

> Also there are the issues of a load error or ECC error when scanning for bad blocks:

> Is it possible to get an ECC error when scanning a bad block?

Theoretical it's possible but I never see it.

> If a load error occurs when scanning a bad block, does that mean the dataRAM
> has been updated or not?

scanning a bad block means read oob so we don't update dataRAM. In onenand implementation. we always invalid dataRAM in oob case.

Thank you,
Kyungmin Park

Re: OneNAND: Always print error messages

[Adrian Hunter]

ext Kyungmin Park wrote:
>> Is it possible to get an ECC error when scanning a bad block?
> 
> Theoretical it's possible but I never see it.

I like to program all the corner cases.

>> If a load error occurs when scanning a bad block, does that mean the dataRAM
>> has been updated or not?
> 
> scanning a bad block means read oob so we don't update dataRAM. In onenand implementation. we always invalid dataRAM in oob case.

I meant the dataRAM spare area: 8010h - 804fh in the bufferRAM address map.

After a load error, will this:

		this->read_bufferram(mtd, ONENAND_SPARERAM, buf, column, thislen);

read the what was meant to be loaded, or will it still contain the data from a previous load?

OneNAND: Always print error messages

[Kyungmin Park]

------- Original Message -------
Sender : Adrian Hunter<ext-adrian.hunter@nokia.com> 
Date   : Jan 19, 2007 17:02
Title  : Re: OneNAND: Always print error messages

ext Kyungmin Park wrote:
>> Is it possible to get an ECC error when scanning a bad block?
> 
> Theoretical it's possible but I never see it.

I like to program all the corner cases.

>> If a load error occurs when scanning a bad block, does that mean the dataRAM
>> has been updated or not?
> 
> scanning a bad block means read oob so we don't update dataRAM. In onenand implementation. we always invalid dataRAM in oob case.

I meant the dataRAM spare area: 8010h - 804fh in the bufferRAM address map.

After a load error, will this:

		this->read_bufferram(mtd, ONENAND_SPARERAM, buf, column, thislen);

read the what was meant to be loaded, or will it still contain the data from a previous load?

=> It depends on load error timings. but we think it is always invalid.
load error means that there's error during load from nand core to bufferram.

Thank you,
Kyungmin Park

Re: OneNAND: Always print error messages

[Adrian Hunter]

ext Kyungmin Park wrote:
>>>> If a load error occurs when scanning a bad block, does that mean the dataRAM
>>>> has been updated or not?
>>> scanning a bad block means read oob so we don't update dataRAM. In onenand implementation. we always invalid dataRAM in oob case.
>> 
>> I meant the dataRAM spare area: 8010h - 804fh in the bufferRAM address map.
>> 
>> After a load error, will this:
>> 
>> 		this->read_bufferram(mtd, ONENAND_SPARERAM, buf, column, thislen);
>> 
>> read the what was meant to be loaded, or will it still contain the data from a previous load?
> 
> => It depends on load error timings. but we think it is always invalid.
> load error means that there's error during load from nand core to bufferram.

So, when scanning for bad blocks, after a load error or ECC (2 bit) error, we have to
assume that the block is bad without reading the spare area?

In that case, should we attempt to mark the block as bad,
perhaps writing the spare area in the second page?

OneNAND: Always print error messages

[Kyungmin Park]

Hi Artem,

> Yeah, it indeed makes few sense to print out error message if we meet a
> bad block. But being silent when errors occur is bad as well.

I agree

> > I'm not sure how to handle error message, especillay at onenand_wait().
> > controller error is very important but it's too verbose at boot time.

> We can avoid doing this if (1) we cannot read OOB (1) and we are
> scanning (2). In other cases we print the error message. Comments?

Yes, simple solution is separate read oob from normal and scanning.
I think is is easy because we can use state variable, FL_SCANNING instead of FL_READING in bbt.
I will try it.

Thank you,
Kyungmin Park

Re: OneNAND: Always print error messages

[Artem Bityutskiy]

Hi Kyungmin,

On Wed, 2007-01-17 at 23:57 +0000, Kyungmin Park wrote:
Yes, simple solution is separate read oob from normal and scanning.
> I think is is easy because we can use state variable, FL_SCANNING 
instead of FL_READING in bbt.
> I will try it.
>
I meant something like this:

if (error occured
     if (!(we are scanning the flash && this is a read OOB error))
         printk("error message");

I guess Adrian could just tweak his patch and re-submit.

-- 
Best regards,
Artem Bityutskiy

Re: OneNAND: Always print error messages

[Adrian Hunter]

ext Kyungmin Park wrote:
> Yes, simple solution is separate read oob from normal and scanning.
> I think is is easy because we can use state variable, FL_SCANNING instead of FL_READING in bbt.

Also there are the issues of a load error or ECC error when scanning for bad blocks:

Is it possible to get an ECC error when scanning a bad block?

If a load error occurs when scanning a bad block, does that mean the dataRAM
has been updated or not?

OneNAND: Always print error messages

[Kyungmin Park]

Hi Adrian,

I think it's too verbose.

As you know, nand flash has several initial bad blocks.
Maybe many uses don't like to see the some error message at boot time.

At least, onenand_wait(), onenand_do_read_oob() have to change from KERN_ERR to KERN_DEBUG
I'm not sure how to handle error message, especillay at onenand_wait().
controller error is very important but it's too verbose at boot time.

Thank you,
Kyungmin Park

Re: OneNAND: Always print error messages

[Artem Bityutskiy]

On Fri, 2007-01-12 at 06:48 +0000, Kyungmin Park wrote:
> As you know, nand flash has several initial bad blocks.
> Maybe many uses don't like to see the some error message at boot time.

Yeah, it indeed makes few sense to print out error message if we meet a
bad block. But being silent when errors occur is bad as well.

> At least, onenand_wait(), onenand_do_read_oob() have to change from 
KERN_ERR to KERN_DEBUG

KERN_ERR and KERN_DEBUG are just printk priorities. I would better say
"printk to DEBUG()".

> I'm not sure how to handle error message, especillay at onenand_wait().
> controller error is very important but it's too verbose at boot time.

We can avoid doing this if (1) we cannot read OOB (1) and we are
scanning (2). In other cases we print the error message. Comments?

-- 
Best regards,
Artem Bityutskiy