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