Hi Mats,
Many thanks for your great help, I change the code as you say by :
~line 659:
if ((fat_val == 0xfffffff && mydata->fatsize == 32) ||
(fat_val == 0xffff && mydata->fatsize == 16))
break;
~line 904:
if ((curclust >= 0xffffff8 && mydata->fatsize == 32) ||
(curclust >= 0xfff8 && mydata->fatsize == 16)) {
empty_dentptr = dentptr;
return NULL;
}
I will do more tests with these changes.
Thank you
----
2013/2/21 Mats Kärrman <mats.karr...@tritech.se>
> 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-boun...@lists.denx.de [u-boot-boun...@lists.denx.de] on
> behalf of Jean Louis [1978...@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)
>
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
