UBI - NAND Flash Programming

UBI - NAND Flash Programming

[Musch, Edwin]

Hello

I am from Data I/O. We produce mass production Flash programming equipment.
We received a request from Keymile/Germany to support the UBI.

As you will know we need to program the raw NAND Flash the same way than the application is handling the NAND Flash ( bad blocks )

Could you please give me further information regarding the Bad Block Handling? Since we are programming the NAND Flash only once we are not worried about wear levelling.

1) If we detect a bad block where should we move the Data
   a. SKIP: go on with the next good block - or
   b. Put the Data into a reserved area
      c. Please let me know where this area is defined
2) Do I need to update the Main area if I move a block? - Is there a header?
3) Could you explain the info within the spare area? 
   a. Do I need to update anything if I move a block to different location?
   b. ECC - In case I need to update the main area - How is it done?
4) Are there any dynamic table somewhere that needs to be updated - Bad block table?

Thank you for your help - Let me know if you need further information to answer any of my questions.

Mit freundlichen Grüßen / Best Regards
Edwin Musch

Re: UBI - NAND Flash Programming

[Artem Bityutskiy]

On Mon, 2009-05-04 at 08:39 -0700, Musch, Edwin wrote:
> 
> Hello
> 
> I am from Data I/O. We produce mass production Flash programming equipment.
> We received a request from Keymile/Germany to support the UBI.
> 
> As you will know we need to program the raw NAND Flash the same way than the application is handling the NAND Flash ( bad blocks )
> 
> Could you please give me further information regarding the Bad Block Handling? Since we are programming the NAND Flash only once we are not worried about wear levelling.
> 

You have an UBI image, and you need to flash it to your device,
right?

> 1) If we detect a bad block where should we move the Data
>    a. SKIP: go on with the next good block - or
>    b. Put the Data into a reserved area
>       c. Please let me know where this area is defined

a).

> 2) Do I need to update the Main area if I move a block? - Is there a header?
> 3) Could you explain the info within the spare area? 
>    a. Do I need to update anything if I move a block to different location?
>    b. ECC - In case I need to update the main area - How is it done?

I do not really understand these questions, sorry.

> 4) Are there any dynamic table somewhere that needs to be updated - Bad block table?

There might be. It depends what you MTD driver chooses. See the
NAND_USE_FLASH_BBT option in the linux kernel. I personally never
used on-flash BBT.

Please, take a look here:
http://www.linux-mtd.infradead.org/doc/ubi.html#L_format

The flashing algorithm is described there.

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)

AW: UBI - NAND Flash Programming

[Musch, Edwin]

Hello Artem Bityutskiy

Thank you so far for your info.

I'm working on the device level of the chip, but I'm not using the Linux kernel. Only our customer does but we have to follow the UBI convention.

We are programming blank chips in production so there is nothing in the NAND flash. This means I do not have to change anything from the Image, right?
So I don't have to make any updates within the main and the spare area, right?

With question 2 & 3 I try to say. Do I need to update a dependency if a block will be moved? Is there something in the main / spare area of the NAND flash that needs to be updated if a block will be moved into the next good block.

Could you provide me the structure of the table if "NAND_USE_FLASH_BBT" is enabled?

Mit freundlichen Grüßen / Best Regards
Edwin Musch
Dipl. - Ing.
FAE - Support Team
6464 185th Avenue NE - Suite 101
Redmond, WA, USA, 98052
Fon:          +1 425 867 6268
@:             musche@data.io.com
web:          www.data-io.com

-----Ursprüngliche Nachricht-----
Von: Artem Bityutskiy [mailto:dedekind@infradead.org] 
Gesendet: Dienstag, 5. Mai 2009 07:18
An: Musch, Edwin
Cc: linux-mtd@lists.infradead.org
Betreff: Re: UBI - NAND Flash Programming

On Mon, 2009-05-04 at 08:39 -0700, Musch, Edwin wrote:
> 
> Hello
> 
> I am from Data I/O. We produce mass production Flash programming equipment.
> We received a request from Keymile/Germany to support the UBI.
> 
> As you will know we need to program the raw NAND Flash the same way than the application is handling the NAND Flash ( bad blocks )
> 
> Could you please give me further information regarding the Bad Block Handling? Since we are programming the NAND Flash only once we are not worried about wear levelling.
> 

You have an UBI image, and you need to flash it to your device,
right?

> 1) If we detect a bad block where should we move the Data
>    a. SKIP: go on with the next good block - or
>    b. Put the Data into a reserved area
>       c. Please let me know where this area is defined

a).

> 2) Do I need to update the Main area if I move a block? - Is there a header?
> 3) Could you explain the info within the spare area? 
>    a. Do I need to update anything if I move a block to different location?
>    b. ECC - In case I need to update the main area - How is it done?

I do not really understand these questions, sorry.

> 4) Are there any dynamic table somewhere that needs to be updated - Bad block table?

There might be. It depends what you MTD driver chooses. See the
NAND_USE_FLASH_BBT option in the linux kernel. I personally never
used on-flash BBT.

Please, take a look here:
http://www.linux-mtd.infradead.org/doc/ubi.html#L_format

The flashing algorithm is described there.

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)

Re: AW: UBI - NAND Flash Programming

[Artem Bityutskiy]

Hi, no offence, just a kind suggestion: we do not appreciate
top-posting here. Well, any technical mailing list does not
appreciate that.

A: Because we read from top to bottom, left to right.
Q: Why should I start my reply below the quoted text?

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?   

A: The lost context.
Q: What makes top-posted replies harder to read than bottom-posted?

A: Yes.
Q: Should I trim down the quoted part of an email to which I'm replying?

Please, read http://david.woodhou.se/email.html

On Tue, 2009-05-05 at 14:41 -0700, Musch, Edwin wrote:
> I'm working on the device level of the chip, but I'm not using the Linux kernel. Only our customer does but we have to follow the UBI convention.

And we do not appreciate looooooooong lines, just like any technical
mailing.

> We are programming blank chips in production so there is nothing in the NAND flash. This means I do not have to change anything from the Image, right?

Right. The link I posted you last time does have the algorithm
description. It is more generic than you need, but you may easily
simplify it. In your case - you do not have to preserve erase
counters. Just skip bad blocks, that's all.

> So I don't have to make any updates within the main and the spare area, right?

UBI does not touch the spare area. Never.

> With question 2 & 3 I try to say. Do I need to update a dependency if a block will be moved?

No. In UBI all eraseblocks are independent.

>  Is there something in the main / spare area of the NAND flash that needs to be updated if a block will be moved into the next good block.

No. You may even randomly re-arrange all eraseblocks, this
should not matter.

> Could you provide me the structure of the table if "NAND_USE_FLASH_BBT" is enabled?

No, sorry. Never used BBT. You should download kernel sources
and dig them, unfortunately.

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)