[U-Boot] NAND flash driver for Samsung K9F1G08
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.
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? :-)
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@denx.de =====================================================================
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 :)
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
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 ?
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
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.
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
participants (4)
-
Roman Mashak -
Scott Wood -
Stefan Roese -
Wolfgang Denk