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
