On Mon, Mar 18, 2019 at 10:42:31AM +0900, Akashi, Takahiro wrote:
Hi Faiz,
On Tue, Mar 12, 2019 at 02:11:08PM +0530, Faiz Abbas wrote:
Hi Akashi,
On 11/09/18 12:29 PM, Akashi, Takahiro wrote:
From: AKASHI Takahiro takahiro.akashi@linaro.org
The current write implementation is quite simple: remove existing clusters and then allocating new ones and filling them with data. This, inevitably, enforces always writing from the beginning of a file.
As the first step to lift this restriction, fat_file_write() and set_contents() are modified to accept an additional parameter, file offset and further re-factored so that, in the next patch, all the necessary code will be put into set_contents().
Signed-off-by: AKASHI Takahiro takahiro.akashi@linaro.org
My fatwrite, fatload and compare tests are failing in MMC with this commit. This is what I see:
=> fatwrite mmc 0 ${loadaddr} test 0x2000000 33554432 bytes written => fatload mmc 0 84000000 test 33554432 bytes read in 2149 ms (14.9 MiB/s) => cmp.b 82000000 84000000 0x2000000 byte at 0x820c5000 (0x85) != byte at 0x840c5000 (0x9d) Total of 806912 byte(s) were the same =>
I tried, but could not reproduce this issue. (v2019.04-rc2)
What I did was:
On host, create a vfat file system and a random data file. dd of=vfat128M.img bs=1M count=128 mkfs -t vfat vfat128M.img ; mount ... head -c 32m /dev/urandom > 32m.data
On qemu, try fatwrite (try 1) => fatload scsi 0:0 50000000 /32m.data 2000000 33554432 bytes read in 539 ms (59.4 MiB/s) => fatwrite scsi 0:0 50000000 /32m_w.data 2000000 33554432 bytes written => fatls scsi 0:0 / 33554432 32m.data 33554432 32m_w.data
2 file(s), 0 dir(s)
=> fatload scsi 0:0 52000000 /32m_w.data 33554432 bytes read in 537 ms (59.6 MiB/s) => cmp.b 50000000 52000000 2000000 Total of 33554432 byte(s) were the same
(try 2) => fatwrite scsi 0:0 54000000 /32m_w2.data 2000000 33554432 bytes written => fatload scsi 0:0 56000000 /32m_w2.data 33554432 bytes read in 537 ms (59.6 MiB/s) => cmp.b 54000000 56000000 2000000 Total of 33554432 byte(s) were the same
I also confirmed that 32m.data and 32m_w.data are the same on the host.
Reverting this commit fixes this issue for me.
So, first let me ask some questions:
- What is the size of your mmc memory?
- How did you format it?
- How many files are already there in the root directory?
Since I think there's some timezone mismatches here, can you please try your test in a loop? And this is likely showing up on something like am335x_evm or dra7xx_evm. Thanks!