On Wed, 2015-05-20 at 18:55 -0700, Andrei Yakimov wrote:
On Wed, 2015-05-20 at 20:37 -0500, Scott Wood wrote:
On Wed, 2015-05-20 at 18:27 -0700, Andrei Yakimov wrote:
For elbc and imx due to we reading all at once, it can not be stateless, we need to read more and more each time
Why do we need to? Why can't we read all three copies at once?
reissuing command or relay on different way to ID chip - and this make it pointless if it can not be done universally.
Or, we can reissue the command. I don't see any big problem either way. This is not performance critical.
lets say 1 time you read 256 ( or 512) it go bad, next time you read 512 (or 1024) next time you read 768 ( or 1536).
I was thinking read_param() would take the offset as a parameter and use NAND_CMD_RNDOUT to skip ahead -- but that would change the default flow which I'd rather avoid. Another option is that read_param() just sets up the read for the specified number of bytes, but the caller still uses read_byte() to extract the data. This way the code could specify sizeof(struct)*3 as the size up front without needing three separate buffers.
Note that whatever gets done should first be accepted in Linux, rather than being a local U-Boot change. If you want a short-term fix, just stick 1536 in the eLBC driver.
Upper layer can maintain it. Roughly like this:
Was: chip->cmdfunc(mtd, NAND_CMD_PARAM, 0, -1); for (i = 0; i < 3; i++) { chip->read_buf(mtd, (uint8_t *)p, sizeof(*p));
You're looking at old code. It uses read_byte() now.
if (onfi_crc16(ONFI_CRC_BASE, (uint8_t *)p, 254) == le16_to_cpu(p->crc)) { break; }} if (i == 3) return 0;
new: int read_size, offset; read_size = 256; offset =0; if(!chip->read_param) chip->cmdfunc(mtd, NAND_CMD_PARAM, 0, -1);
I don't want "if (chip->read_param)" all over the place; there should be a default read_param() that does what the existing code does.
for (i = 0; i < 3; i++) { if(chip->read_param) chip->read_param( 0, read_size); chip->read_buf(mtd, (uint8_t *)p + offest, sizeof(*p));
This isn't going to read the second or third copy; it's going to read the first copy and write beyond the end of your buffer.
-Scott