[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]

Hello

Post by Roman Mashak
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? :-)

[Stefan Roese]

Post by Roman Mashak

Post by Roman Mashak
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.

Post by Roman Mashak
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.

Post by Roman Mashak
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: [phone] Fax: [phone] Email: office at denx.de
=====================================================================

[Roman Mashak]

Hello

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

[skip]

Post by Stefan Roese

Post by Roman Mashak
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 :)

[Wolfgang Denk]

Dear Roman,

Post by Roman Mashak
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).

Post by Roman Mashak
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.

Post by Roman Mashak
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.

Post by Roman Mashak
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.

Post by Roman Mashak
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

[Roman Mashak]

Hello

Post by Wolfgang Denk
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?

Post by Wolfgang Denk
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

Post by Wolfgang Denk
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 ?

[Scott Wood]

Post by Roman Mashak
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

[Roman Mashak]

Hello

Post by Scott Wood

Post by Roman Mashak
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 :-)

Post by Scott Wood

Post by Roman Mashak
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.

[Scott Wood]

Post by Stefan Roese
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