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. > > 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?) The debug output is a little odd; there are no writes to sector 2 (which I would expect to contain a second FAT). Interesting things to try: Before writing the new firmware, do dd if=/dev/sdb count=7 | hexdump -C That should print the boot sector, the two FATs, the root directory, and the first 3 sectors (1536 bytes) of the firmware file. After writing the new firmware, do the same thing. Look for significant differences. Note that this will give you the information in the kernel's page cache rather than the data from the device. Then without resetting, do (as root): blockdev --flushbufs /dev/sdb and repeat the dd|hexdump. This will show the data as actually present on the device. 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
