blkdev/dosfs/emmc issues.

[Tasslehoff Kjappfot]

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
3. Unmount
4. Mount
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>
wrote:

> 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
> this.
>
> 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,
> Tasslehoff
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20170313/e8ae99fc/attachment.html>