[U-Boot] [BUG] cb8af8af5ba0 "fs: fat: support write with non-zero offset" fatwrite followed by fatload and then cmp fails

[Tom Rini]

On Wed, Mar 13, 2019 at 10:41:15PM +0530, Rizvi, Mohammad Faiz Abbas wrote:
> Tom,
> 
> On 3/12/2019 2:11 PM, Faiz Abbas wrote:
> > Hi Akashi,
> > 
> > On 11/09/18 12:29 PM, Akashi, Takahiro wrote:
> >> From: AKASHI Takahiro <takahiro.akashi at 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 at 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
> > =>
> > 
> > Reverting this commit fixes this issue for me.
> > 
> > Thanks,
> > Faiz
> > 
> 
> We have about 100 boards failing to boot from SD card because of fat
> filesystem corruption in our test farm (likely) because of this patch. I
> am afraid we will have to revert it until something stable can be
> figured out. Will send out reverts tomorrow. Hopefully they can be
> reviewed and merged quickly.

OK, thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190313/86e0f695/attachment.sig>