[U-Boot] Problems around fatwrite command from uboot

[Jean Louis]

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.Karrman at 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-bounces at lists.denx.de [u-boot-bounces at lists.denx.de] on
> behalf of Jean Louis [1978.jl at gmail.com]
> Sent: Thursday, February 21, 2013 12:33 PM
> To: u-boot at 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)
>