On Tue, 27 Jul 2010, Peter Stuge wrote: > Hi Matthew, > > I very much appreciate the quick and good replies! > > Matthew Dharm wrote: > > In that category of "quick things to try", try mounting with -o sync > > and see if that makes a difference. > > Same problem, both with mount -o sync -t vfat and mount -o sync -t msdos. > As expected, the ~one second delay is then on cp instead of umount. > > > > Also, when you say "prepended", do you mean the file is 1024 bytes > > larger, exactly, then what you wrote? And that the data read back > > is 1024 bytes of 0x00 followed exactly by the exact data pattern > > you wrote? > > The file is always 32kb. A complication is that the filesystem is not > really a plain filesystem.. It looks like one, but it's just an "API" > to programming the internal flash memory. > > When mounting the filesystem and reading the file, it always > contains the flash memory contents. I'm not sure exactly how flash > erase and flash write works internally (what happens when I rm, and > what when I cp) - but if mounted async then sync after cp and umount > both take a seconds or so to complete. In any case, the User Manual > is clear that the flash memory is rewritten by copying a new file to > the filesystem. In Windows, the drive can not be ejected, so when the > copy command returns on Windows I simply unplug the device, which > works. Maybe the trick is to overwrite the existing file instead of removing it and then writing a new file. Or maybe the trick is to copy the file directly to the device without mounting it first; i.e., "cp file /dev/sdb". > The incorrect data read back is 1kb 0x00 followed by the first 31kb > of the 32kb file that I wrote. Same result also if I write a smaller > file; I then get 1kb 0x00 + full contents of my file + previous flash > memory contents. Always 32kb. > > > > What happens if you mount, write, umount, walk away for 5 min, mount, > > readback, and compare -- all without actually detaching the device and > > re-booting it > > I usually reset the device without detaching it. There's a proper > reset switch on the microcontroller RESET# signal. I just tried this, > and the file read back has correct contents. If I reset and remount, > I get the bad contents. Now it's 1024 0xff (erased flash) instead of > 0x00. > > > > (which triggers the upgrade process)? > > I believe that the flash is rewritten when I run cp/umount. After the > next reset, the flash needs to already be written. > > I think that the file contents exposed by the device is cached in the > ISP bootloader. It fills the cache with flash contents when starting > up, and after that all read operations read from the cache. And > writing goes into the flash memory. > > > > > > It would seem very improbable that this was caused by a USB storage > > > > issue. > > > > > > I'm starting at the bottom of the driver stack. :) Maybe you can help > > > me debug it in any case? Since this is a very small amount of data, > > > might it be informative to add a debug print e.g. for every sector > > > write? > > > > If you turn on CONFIG_USB_STORAGE_DEBUG you will get some pretty > > useful but still reasonably high-level data. > > 1483 lines of debug output is at http://stuge.se/lpc1343_isp.txt > (Is it OK to send the 115kb log to the list?) Ideally, we would compare this (or a usbmon log, which might be more informative) with a comparable log showing what Windows does under the same conditions. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
