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