[U-Boot] Fat write problem

[Ruud Commandeur]

Hello again,

This week I decided to do some further research and testing regarding
this problem.
With the image I had from the previous time, I could immediately
reproduce it and
by adding more and more debug prints, I tried to find the cause. Sofar,
I have not
succeeded in this yet.

However: later on I started testing with a freshly formatted drive (32
MB FAT partition)
and kept repeating the fatwrite command:

fatwrite mmc 0:1 42000000 test-x 200

where x runs from 1, 2,3 and further. And this way I could reproduce it
quite easily.
Writing always fails for the 32nd file. This is with the partition
formatted with a 512 byte
sector size and a cluster size of 4. If the cluster size is 1 (formatted
by Windows),
it already fails at the 8th file.

If I create a subdirectory (from Linux) with already 24 files in it, I
can still write 29 files
and it fails at number 30. Also, if earlier files were deleted from the
root-directory, they
still count in the total number of files here.

If I take out the card where u-boot fails to write new files, I can
still add new files from
my PC with Linux or Windows.

I tested with both long and short filenames (same result), VFAT is
enabled.

I hope this gives you all some more information about this problem and
perhaps it is even a
known problem (limited number of files in the root directory?). I know
it is voor FAT16, but
that was 512 entries if I am correct.

Regards,

Ruud


> -----Oorspronkelijk bericht-----
> Van: Ruud Commandeur 
> Verzonden: woensdag 23 oktober 2013 17:18
> Aan: U-Boot list
> Onderwerp: Fat write problem
> 
> Hi Everyone,
> 
> After about half a year without problems for fatwrite, I have 
> some new problem.
> The fatwrites for the u-boot are used to write the uimage and 
> dtb file to a 32
> MB FAT16 partition on an SD-card. Since this morning, the 
> writing of a new file
> keeps failing. I still can write files that are already present.
> But if try and write some file with a name that doe not exist 
> yet, it fails. I guess
> this just hasn't been tested for a while, since these 
> filenames don't change.
> Meanwhile some extra files have been copied to the partition 
> from the Linux
> platform. I did check the SD-card partition with fsck and 
> could not find any
> problems.
> 
> I did enable the debug for MMC and FAT to get the following output:
> 
> fatwrite mmc 0:1 42000000 test-file 200
> writing test-file
> MMC0: CMD16
> MMC0: CMD17
> MMC0: CMD16
> MMC0: CMD18
> MMC0: CMD12
> get_dentfromdir: test-file
> gc - clustnum: -6, startsect: 132
> MMC0: CMD16
> MMC0: CMD18
> MMC0: CMD12
> vfatname: |uimage|
> Mismatch: |uimage|uimage|
> vfatname: |imx28-evk.dtb|
> Mismatch: |imx28-~1.dtb|imx28-evk.dtb|
> vfatname: |linux-file1.txt|
> Mismatch: |linux-~1.txt|linux-file1.txt|
> Mismatch: |address.ini||
> vfatname: |imx28-clb.dtb|
> Mismatch: |imx28-~2.dtb|imx28-clb.dtb|
> vfatname: |img-copy|
> Mismatch: |img-copy|img-copy|
> vfatname: |tessie|
> Mismatch: |tessie|tessie|
> vfatname: |img-copy2|
> Mismatch: |img-co~1|img-copy2|
> vfatname: |imx-28-clb-37.dtb|
> Mismatch: |imx-28~1.dtb|imx-28-clb-37.dtb|
> vfatname: |hello8000.wav|
> Mismatch: |hello8~1.wav|hello8000.wav|
> vfatname: |versions.ini|
> Mismatch: |versions.ini|versions.ini|
> vfatname: |mx28-310.dtb|
> Mismatch: |mx28-310.dtb|mx28-310.dtb|
> FAT16: entry: 0xfffffffa = -6, offset: 0x03fa = 1018
> MMC: block number 0x1000806 exceeds max(0x762c00)
> FAT16: ret: 00000000, entry: fffffffa, offset: 03fa
> curclust: 0x0
> Invalid FAT entry
> name.ext : <NULL>.
> FAT16: entry: 0x0003 = 3, offset: 0x0003 = 3
> error: overflow occurs
> error: writing FAT blocks
> FAT16: entry: 0x0004 = 4, offset: 0x0004 = 4
> error: overflow occurs
> error: writing FAT blocks
> FAT16: entry: 0x0005 = 5, offset: 0x0005 = 5
> error: overflow occurs
> error: writing FAT blocks
> FAT16: entry: 0x0006 = 6, offset: 0x0006 = 6
> ... and this goes on for a long long time...
> 
> It points to get_fatent_value( ) where things go wrong. Or 
> perhaps the call of
> this function with the value 0xfffffffa (-6). I don't know if 
> that is supposed
> to be possible?
> 
> At the moment I am a bit stuck here, so if anyone would have 
> an idea what
> goes wrong here, please let me know.
> 
> Thanks,
> 
> Ruud
> 
> N.B. It might be that this can be solved by clearing the FAT 
> partition and starting
> with a clean sheet. But I prefer not to lose this error 
> situaion before I know
> what goes wrong here.