[U-Boot] NAND flash driver for Samsung K9F1G08

[U-Boot] NAND flash driver for Samsung K9F1G08

[Roman Mashak]

Hello

I'm using 128Mb Samsung NAND flash K9F1G08 on our custom ARM-based
board. Flash ID is in $(UBOOT)/include/linux/mtd/nand_ids.h
Seems this chip is not CFI compliant (at least datasheet says nothing
of it), so the use of CFI driver falls away.

The problem I faced is how to calculate max number of sectors on a
flash chip, i.e. CFG_MAX_FLASH_SECT parameter. Does CFG_MAX_FLASH_SECT
mean total max number of sectors on the device, or max number of
sectors on a page? If I divide total flash size on bytes by sector
size I get weird numbers, obviously I'm on a wrong way.

Will appreciate any comments.
Thanks.

-- 
Roman Mashak

[U-Boot] NAND flash driver for Samsung K9F1G08

[Roman Mashak]

Hello

2008/9/30 Roman Mashak <romez777@gmail.com>:
> Flash ID is in $(UBOOT)/include/linux/mtd/nand_ids.h
> Seems this chip is not CFI compliant (at least datasheet says nothing
> of it), so the use of CFI driver falls away.

After some investigations I see that $(uboot)/drivers/mtd/nand/nand.c
is compiled in with CONFIG_CMD_NAND defined and CFG_NAND_LEGACY
undefined -- these two macros are mutually exclusive. Why do then some
platforms define both of them, for instance
$(uboot)/include/configs/at91rm9200dk.h  and what is the proper use of
these macros?

To make things more clear: NAND flash Samsung K9F1G08U is defined in
both $(uboot)/drivers/mtd/nand/nand_ids.c and
$(uboot)/include/linux/mtd/nand_ids.h, latter is included with
CFG_NAND_LEGACY defined. It confuses me, I don't understand is my
flash legacy device or rather new one? :-)

-- 
Roman Mashak

[U-Boot] NAND flash driver for Samsung K9F1G08

[Stefan Roese]

On Wednesday 01 October 2008, Roman Mashak wrote:
> > Flash ID is in $(UBOOT)/include/linux/mtd/nand_ids.h
> > Seems this chip is not CFI compliant (at least datasheet says nothing
> > of it), so the use of CFI driver falls away.
>
> After some investigations I see that $(uboot)/drivers/mtd/nand/nand.c
> is compiled in with CONFIG_CMD_NAND defined and CFG_NAND_LEGACY
> undefined -- these two macros are mutually exclusive.

Correct. The legacy NAND support is, as the name implies, outdated and should 
*not* be used anymore.

> Why do then some 
> platforms define both of them, for instance
> $(uboot)/include/configs/at91rm9200dk.h  and what is the proper use of
> these macros?

Defining both is definitely broken and should be fixed. I think now its really 
time to completely remove the legacy NAND support. It has been dragged along 
for quite some time.

> To make things more clear: NAND flash Samsung K9F1G08U is defined in
> both $(uboot)/drivers/mtd/nand/nand_ids.c and
> $(uboot)/include/linux/mtd/nand_ids.h, latter is included with
> CFG_NAND_LEGACY defined. It confuses me, I don't understand is my
> flash legacy device or rather new one? :-)

IIRC then your NAND chips should be supported in the U-Boot NAND driver 
without any changes.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================

[U-Boot] NAND flash driver for Samsung K9F1G08

[Roman Mashak]

Hello

2008/9/30 Stefan Roese <sr@denx.de>:

[skip]
>> To make things more clear: NAND flash Samsung K9F1G08U is defined in
>> both $(uboot)/drivers/mtd/nand/nand_ids.c and
>> $(uboot)/include/linux/mtd/nand_ids.h, latter is included with
>> CFG_NAND_LEGACY defined. It confuses me, I don't understand is my
>> flash legacy device or rather new one? :-)
>
> IIRC then your NAND chips should be supported in the U-Boot NAND driver
> without any changes.

Okay. There is another thing confusing me is - almost all ports
implement board specific support of flash in
$(uboot)/board/board_name/flash.c or $(uboot)/board/board_name/nand.c
(NAND specific).

What is the rationale to separate them in such a way -- flash.c is for
NOR, boot flash etc. only and all NAND stuff apart? Does 'flinfo'
print information about ANY available flash -- but on the other hand,
do_flinfo() in $(uboot)/common/cmd_flash.c uses 'flash_print_info()'
defined in target's flash.c

Hmm.. completely confused.

Hopefully somebody can bring me out in the light :)

-- 
Roman Mashak

[U-Boot] NAND flash driver for Samsung K9F1G08

[Wolfgang Denk]

Dear Roman,

In message <40a670230810010111u2c4992f0g51c6e486e8c150bc@mail.gmail.com> you wrote:
> 
> Okay. There is another thing confusing me is - almost all ports
> implement board specific support of flash in
> $(uboot)/board/board_name/flash.c or $(uboot)/board/board_name/nand.c
> (NAND specific).

Not almost all boards to that. Only some 200 out of more than 500 do,
i. e. less than 40%, and these are mostly old boards  that  have  not
been  adapted  to  use  the  CFI driver yet (with very few exceptions
where some specific issue prevents us from using the CFI driver).

> What is the rationale to separate them in such a way -- flash.c is for

flash.c is the old, obsolete way to implement a NOR flash driver.

> NOR, boot flash etc. only and all NAND stuff apart? Does 'flinfo'
> print information about ANY available flash -- but on the other hand,

flinfo is part of the NOR flash interface.

> do_flinfo() in $(uboot)/common/cmd_flash.c uses 'flash_print_info()'
> defined in target's flash.c

cmd_flash.c is part of the NOR flash interface.

> Hmm.. completely confused.

Part of your confisuion probably results from the fact that NAND flash
is *not* memory, but a storage device instead.

NOR flash is memory - you have byte addresses, and it is mapped  into
the processors address space. It is supported by memory commands like
"md", "cp" etc.

NAND flash is a storage device. You cannot address a certain byte  by
the  CPU - instead you have to runa specific command sequence to load
some amount of data from the storage device into RAM, before you  wan
work on it. The "nand" command is used to do this.


I am aware that many people  use  sloppy  terms  and  call  NAND  and
OneNAND  etc.  as "flash memory", while in fact all these devices are
storage devices - the reemble much more the behaviour of a disk drive
than of memroy.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
When a program is being  tested,  it  is  too  late  to  make  design
changes.                  -- Geoffrey James, "The Tao of Programming"

[U-Boot] NAND legacy flash removal

[Scott Wood]

On Wed, Oct 01, 2008 at 08:07:04AM +0200, Stefan Roese wrote:
> Defining both is definitely broken and should be fixed. I think now its really 
> time to completely remove the legacy NAND support. It has been dragged along 
> for quite some time.

I'd love to see that as well.

To anyone who's maintaining a board that still uses legacy NAND, please
update soon.

-Scott

[U-Boot] NAND flash driver for Samsung K9F1G08

[Roman Mashak]

Hello

2008/10/1 Wolfgang Denk <wd@denx.de>:
> Not almost all boards to that. Only some 200 out of more than 500 do,
> i. e. less than 40%, and these are mostly old boards  that  have  not
> been  adapted  to  use  the  CFI driver yet (with very few exceptions
> where some specific issue prevents us from using the CFI driver).

As far as I understand not all manufacturers adhere to CFI standards,
so this is flash chip's problem rather then board itself.
CFI is for both NAND and NOR flash devices (even though CFI stands for
Common _Flash memory_ Interface)? So if a device CFI compliant, only
one driver 'cfi_flash.c' can be used to control it, and it's
guaranteed it will support whole set of operations on a chip?

> flash.c is the old, obsolete way to implement a NOR flash driver.
> flinfo is part of the NOR flash interface.
> cmd_flash.c is part of the NOR flash interface.
[skip]

So the settings as follows mainly refer to NOR:
CFG_MAX_FLASH_BANKS
CFG_NO_FLASH
CFG_MAX_FLASH_BANKS_DETECT
CFG_FLASH_BASE
CFG_FLASH_ERASE_TOUT
CFG_FLASH_WRITE_TOUT
CFG_FLASH_LOCK_TOUT
CFG_FLASH_UNLOCK_TOUT

while
CFG_MAX_NAND_DEVICE
CFG_NAND_SELECT_DEVICE

are NAND-related

> Part of your confisuion probably results from the fact that NAND flash
> is *not* memory, but a storage device instead.

Indeed. In U-Boot you've logically separated 'flash memory' from
'flash storage'. Then what about dataflash? It's obviously a 'flash
storage' device, but is supported in NOR memory interface in
cmd_flash.c ?

-- 
Roman Mashak

[U-Boot] NAND flash driver for Samsung K9F1G08

[Scott Wood]

On Wed, Oct 01, 2008 at 06:04:02PM -0700, Roman Mashak wrote:
> As far as I understand not all manufacturers adhere to CFI standards,
> so this is flash chip's problem rather then board itself.
> CFI is for both NAND and NOR flash devices (even though CFI stands for
> Common _Flash memory_ Interface)?

No, CFI is just for NOR.

-Scott

[U-Boot] NAND flash driver for Samsung K9F1G08

[Roman Mashak]

Hello

2008/10/2 Scott Wood <scottwood@freescale.com>:
> On Wed, Oct 01, 2008 at 06:04:02PM -0700, Roman Mashak wrote:
>> As far as I understand not all manufacturers adhere to CFI standards,
>> so this is flash chip's problem rather then board itself.
>> CFI is for both NAND and NOR flash devices (even though CFI stands for
>> Common _Flash memory_ Interface)?
>
> No, CFI is just for NOR.
Thanks, now it's a bit easier to find my way around the deep jungles
of U-Boot :-)

Would you please elaborate on my previous statement:

>> So the settings as follows mainly refer to NOR:
>> CFG_MAX_FLASH_BANKS
>> CFG_NO_FLASH
>> CFG_MAX_FLASH_BANKS_DETECT
>> CFG_FLASH_BASE
>> CFG_FLASH_ERASE_TOUT
>> CFG_FLASH_WRITE_TOUT
>> CFG_FLASH_LOCK_TOUT
>> CFG_FLASH_UNLOCK_TOUT

>> while
>> CFG_MAX_NAND_DEVICE
>> CFG_NAND_SELECT_DEVICE

>> are NAND-related

Is my understanding correct, if not - why?
Thanks again.

-- 
Roman Mashak