tasskjapp at gmail.com
Mon Mar 13 13:42:28 UTC 2017
A little update on this. I found out that if I do the following, the md5sum
is wrong the second time I check it.
1. Write upgrade files
2. Check MD5
5. Check MD5
If I do not unmount/mount, the MD5 is ok, even after a reboot.
With JTAG I discovered that after I have initiated an unmount, the
bdbuf_swapout_task tries to do 3 writes into blocks inside the file where
the MD5 check fails. If I just ignore those writes, it also works.
On Fri, Mar 10, 2017 at 4:49 PM, Tasslehoff Kjappfot <tasskjapp at gmail.com>
> I have some issues with rtems(4.11)/dosfs/emmc that I hope you can help me
> with. The problem is corrupted files after a software upgrade. It goes like
> 1. Format the eMMC. Doesn't matter if I use msdos_format, gparted or
> something else.
> 2. Boot the system and let the bootloader receive a ~10 file upgrade which
> it writes to eMMC
> 3. Compute md5sum of all the received files (open/read/compute/close). All
> the md5sums are ok.
> 4. "Disconnect" the eMMC with rtems_bdbuf_syncdev followed by umount.
> (I've also tried turning off the eMMC after this.)
> 5. Reboot the system. When I mount the eMMC again, the md5sum of the
> biggest file has changed. It's ~4MB, and typically 10-12 bytes are wrong.
> I do not understand how the md5sum can be correct when read from the eMMC
> before I boot, and then have changed after a reboot. Is there a chance that
> I get data from some cache when I do open/read/close right after writing
> the file? A lot of times the bad bytes have been at an offset of 0x50000
> into the file.
> I've tried playing with the different BDBUF and SWAPOUT defines, but it
> doesn't affect the outcome.
> Any help or ideas on things to try appreciated.
> Best regards,
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the users