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 > > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot