I think this is just me being stupid. I looked up the nand probe function and it appears to have the correct detection mechanism in place. In fact, I rebuilt after the daily pull from the repo and it seems to be working fine. I must have just mistyped something somewhere along the line.
// Dean Glazeski On Thu, Nov 19, 2009 at 2:40 AM, David Brownell <[email protected]> wrote: > On Wednesday 18 November 2009, Dean Glazeski wrote: > > The thing is that the first time I tried to do this: > > > > nand erase 0 0 2048 > > > > I got presented with command usage and had no idea why it was failing. I > > looked into it a bit more and found out what the block size was. For my > > NAND chip it is 128KB. Now, when I tried again with > > > > nand erase 0 0 0x20000 > > > > It failed in the same way. Looking at how the NAND struct was used, the > > erase block size is defined as 0. There is a check in the nand erase > > command handler that checks for length % nand->erase_size != 0 and this > > fails for my chip when I specify length. > > I thought that was filled in via "nand probe". Did you probe? > Or did probing not collect that data? I certainly see code in > the probe routine to fill in erase_size... > > You're not allowed to acess any kind of flash chip before it's > been probed. Normally, a "reset-init" event handler probes. > > > > The issue is that the erase block size is wrong and this could be > retrieved > > from the Samsung NAND chip. I'm wondering if it would be good to parse > this > > field out when probed or to just set the value in the device_id array as > > opposed to leaving it as 0. > > > > Long story short, nand probe works. I'm just not sure if specifying 128k > > erase blocks for all 512MiB, 8-bit NAND chips is correct. > > I'm still not following. If it works, what's the issue?? > > > > This leads me to another question. Should there be more descriptive > error > > output? It's sort of confusing to get presented with the command syntax > > when the syntax is correct, but the underlying command handler errors > over > > an invalid parameter value. > > Sounds like some bad diagnostics, on the order of "you didn't > probe this yet". > > - Dave > > > > // Dean Glazeski > > > > > > On Thu, Nov 19, 2009 at 1:04 AM, David Brownell <[email protected]> > wrote: > > > > > On Wednesday 18 November 2009, Dean Glazeski wrote: > > > > Hi all, > > > > > > > > Is there a good way for me to determine the erase block size for a > NAND > > > > chip? Right now, the device ID array in nand.c has 0 as the erase > block > > > > size for my NAND device. I believe this should be 128k. Is this not > > > always > > > > the case for 512MiB, 8-bit NAND devices? Is this just a case of no > one > > > has > > > > filled in the table? I know my Samsung chip gives out additional > data > > > bytes > > > > in addition to manufacturer and device ID that specify block and page > > > > sizes. Can this be leveraged to dynamically populate the NAND > devices? > > > > > > I'm not following. Not that I've done this with very many NAND chips > ... > > > but "nand probe <bank#>" has so far been good at finding out block > sizes. > > > Including 1GiB parts filled out like the 512Mib ones... > > > > > > Are you saying that "nand probe" fails for your chip? > > > > > > Or just wondering if the table should be filled in differently? > > > > > > > > > > >
_______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
