From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Sun, 17 Mar 2019 21:44:20 -0400 Subject: [U-Boot] [BUG] cb8af8af5ba0 "fs: fat: support write with non-zero offset" fatwrite followed by fatload and then cmp fails In-Reply-To: <20190318014230.GA9937@linaro.org> References: <20180911065922.19141-1-takahiro.akashi@linaro.org> <20180911065922.19141-10-takahiro.akashi@linaro.org> <961133c7-0d01-d227-3119-61d2875ceb3e@ti.com> <20190318014230.GA9937@linaro.org> Message-ID: <20190318014420.GS8732@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 > > > > > > 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 > > > --- > > > > 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! -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: