On Tue, 2015-05-19 at 16:42 -0700, Andrei Yakimov wrote:
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
So then we want 1536 bytes, not 768 (or 786) if we go with the simple fix?
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.
Correcting. Perhaps it's working because it's reporting an uncorrectable error (thus not correcting anything) and you're ignoring it?
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'm not sure what you're trying to say here.
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.
You won't be holding CS that long. It will drop as soon as the current operation completes. And I'm not interested in a solution that only works in U-Boot's single-tasking environment, given that this code is more or less shared with Linux.
I don't see what the objection is to adding a replaceable read_param() method that is not so hostile to high-level controllers.
-Scott