Hi Jean,

Accidentally I'm also currently debugging fat_write. I have a problem with USB EHCI time-outs while writing but so far I have not found a cure.

What I have found is this rather strange code in fat_write.c:

~line 659: if (fat_val == 0xfffffff || fat_val == 0xffff) break; ~line 904: if ((curclust >= 0xffffff8) || (curclust >= 0xfff8)) { empty_dentptr = dentptr; return NULL; }

Both these conditions seem to be plain wrong. They should probably take mydata->fatsize into account and select either of the conditions. I suspect that they could cause errors in the FAT chains by triggering on the FAT16 condition when actually running on FAT32.

Good luck! BR // Mats ________________________________________ From: u-boot-bounces@lists.denx.de [u-boot-bounces@lists.denx.de] on behalf of Jean Louis [1978.jl@gmail.com] Sent: Thursday, February 21, 2013 12:33 PM To: u-boot@lists.denx.de Subject: [U-Boot] Problems around fatwrite command from uboot

Hi,

I use the last uboot from your git and boot with it on AM3517 EVM from SD card without NAND.

I use this option in uboot config : #define CONFIG_FAT_WRITE 1

I use intensively fatload / fatwrite commands at the boot before kernel loading.

Sometimes, in about 2% of cases of boot, the FAT becomes inconsistent and I have systematically these messages at boot when I use fatwrite command :

U-Boot 2013.01-gd3b9a66-dirty (Feb 21 2013 - 11:02:33) ... writing MODIFYME.001 mmc_send_cmd: timedout waiting on cmd inhibit to clear mmc_send_cmd: timedout waiting on cmd inhibit to clear mmc_send_cmd: timedout waiting on cmd inhibit to clear mmc_send_cmd: timedout waiting on cmd inhibit to clear mmc_send_cmd: timedout waiting on cmd inhibit to clear mmc_send_cmd: timedout waiting on cmd inhibit to clear mmc_send_cmd: timedout waiting on cmd inhibit to clear mmc_send_cmd: timedout waiting on cmd inhibit to clear mmc_send_cmd: timedout waiting on cmd inhibit to clear mmc_send_cmd: timedout waiting on cmd inhibit to clear mmc_send_cmd: timedout waiting on cmd inhibit to clear 42428 bytes written ...

unlike that is said at the last line, the file is not written.

If I run a 'fatls' command before this fatwrite, I see the same file 'modifyme.001' twice :

AM3517_EVM # fatls mmc 0:1 42428 mlo 261332 u-boot.bin 2 modifyme.001 2 modifyme.001 2644996 uimage ...

After the board boot on linux, I run this command to repair FAT part:

umount /dev/mmcblk0p1 ; fsck.vfat -a -w -v /dev/mmcblk0p1 dosfsck 2.11 (12 Mar 2005) dosfsck 2.11, 12 Mar 2005, FAT32, LFN Checking we can access the last sector of the filesystem Boot sector contents: System ID "MSDOS5.0" Media byte 0xf8 (hard disk) 512 bytes per logical sector 4096 bytes per cluster 34 reserved sectors First FAT starts at byte 17408 (sector 34) 2 FATs, 32 bit entries 321024 bytes per FAT (= 627 sectors) Root directory start at cluster 2 (arbitrary size) Data area starts at byte 659456 (sector 1288) 80156 data clusters (328318976 bytes) 63 sectors/track, 255 heads 63 hidden sectors 642537 sectors total

Wrong checksum for long file name "modifyme.001". (Short name MODIFYME.001 may have changed without updating the long name) Not auto-correcting this. /modifyme.001 Contains a free cluster (3081). Assuming EOF. /modifyme.001 File size is 2 bytes, cluster chain length is 0 bytes. Truncating file to 0 bytes.

Reclaiming unconnected clusters. Checking free cluster summary. Performing changes. /dev/mmcblk0p1: 24 files, 3487/80156 clusters

As you can see in this return, the error 'Wrong checksum for long file name "modifyme.001"' often appears after use of fatwrite command at the boot.

After the part is repaired, I reboot the board and uboot run as infinite loop after the fatwrite command :

writing MODIFYME.001 error: overflow occurs error: overflow occurs error: overflow occurs error: overflow occurs error: overflow occurs ...

( seems to be error in source code at disk_write() /* Write FAT buf */ in flush_fat_buffer() )

I do an electrical off / on of my board during this infinite loop and the next boot seems okay but the file is once again corrupted, we can see that the count is incorrect (4096 and not 42428) :

... 42428 bytes read in 6 ms (6.7 MiB/s) writing MODIFYME.001 4096 bytes written ...

A fatload at the next boot says 'Invalid FAT Entry' :

... reading MODIFYME.001 Invalid FAT entry ...

If I try to fatwrite an another file in this situation, I fall in the first case ( mmc_send_cmd: timedout waiting on cmd inhibit to clear )

I think that the fatwrite command is potentially incomplete maybe around :

- free cluster summary - second FAT entry - short/long filenames - deleted files entries

any help appreciated

Best regards, Jean Louis. (France)