On Tue, 2015-05-19 at 17:38 -0500, Scott Wood wrote:
On Tue, 2015-05-19 at 15:29 -0700, Andrei Yakimov wrote:
I did not compiling latest, I still in 2011.9 and 2.6.38. I have go over latest kernel and can see they using NAND_CMD_PARAM with sub command 0x40 - to get JEDEC information, it is 3 mandatory copy by 512 bytes.
3x512 or 3x256?
ONFI - 3x256 sub command 0x0 JEDEC - 3x512 sub command 0x40
Going over kernel divers, figure out some read whole page some 256 bytes. Reading whole page (set fcbr = 0) have some sense - you do not need to know anything about flash, but what to put in to read_bytes ?
You don't want fbcr = 0 here because that will enable ECC which isn't there.
Is it correcting or just generating syndrome? It is working on my board, I would say it only generate or ignored for this command (8313). It should corrupt data if it correcting but it does not.
It looks like for universal patch 2K should be read.
Again, if we're going to do anything beyond s/256/768/ it should be a higher level function where the caller says how much it wants.
It is not normal nand flow: READ_ID and PARAM assuming it know the size.
I have also check other vendor controllers like tegra, there continuous data read trigger additional data transfer from chip.
Can we do (NOP CWO UA RWB RS RS RS RS) wait ltesr (cc) and after that next read_buffer ( RB or RS) all command have to start with NOP, this will effectively terminate previous command. And we do not care about locks in u-boot. kernel will be different store, but again this code executed only during start up - so who care holding CS to long.
there is only 4 places for PARAM: drivers/mtd/nand/mxs_nand_spl.c chip->cmdfunc(mtd, NAND_CMD_PARAM, 0, -1); drivers/mtd/nand/nand_base.c: chip->cmdfunc(mtd, NAND_CMD_PARAM, 0, -1); drivers/mtd/nand/nand_base.c: chip->cmdfunc(mtd, NAND_CMD_PARAM, 0, -1); drivers/mtd/nand/nand_base.c: chip->cmdfunc(mtd, NAND_CMD_PARAM, 0x40, -1);
latest kernel read it like this: chip->cmdfunc(mtd, NAND_CMD_PARAM, 0, -1); for (i = 0; i < 3; i++) { for (j = 0; j < sizeof(*p); j++) ((uint8_t *)p)[j] = chip->read_byte(mtd); if (onfi_crc16(ONFI_CRC_BASE, (uint8_t *)p, 254) == le16_to_cpu(p->crc)) { break; } }
Yes, that's how the hardware works, but controllers like eLBC don't directly expose that interface. We need to get all of the command's output at once.
This kind of implementation better, but I did not see how it could be done for this controller.
I wouldn't say it's "better" so much as a closer fit to what the Linux NAND code is expecting.
I am not sure how is small page (512 byte) flash should operate also.
Is there any small-page ONFI flash?
I do not know. ONFI parameter page will tell you page size: 80-83 M Number of data bytes per page 84-85 M Number of spare bytes per page if we drop it, lets set to 2k and forget.
Why did you take this e-mail off-list?
Sorry just forgot.
-Scott