Re: [U-Boot-Users] FW: USB SUPPORT & get_vfatname

25 Apr 2008

Thanks for reporting similar problems with U-Boot's FAT32
support.
Adrian Filipi wrote:
...
It seems to be a FAT32 problem with media 256MB and smaller.
Thanks for this observation, but this may not be entirely true.
With larger FAT32 filesystems it seems to require more files
in the root directory, before a failure is observed.  For
example, my 1GB pen drive passed my 36 file test, so I created
a test with more files ...
Here's a script to put 1000 files 0.txt through 999.txt
onto the current directory:
#!/bin/bash
for (( number=0 ; number < 1000 ; number++ )) ; do
        echo "${number}" > ${number}.txt
done
--- Here's the output (using my 1GB pen drive) ---
Hit any key to stop autoboot: 58 0
U-Boot> usb reset
usb reset
(Re)start USB...
USB:   scanning bus for devices...
      USB device not responding, giving up (status=20)
3 USB Device(s) found
       scanning bus for storage devices... 1 Storage Device(s) found
U-Boot> fatls usb 0:1 /
fatls usb 0:1 /
        3   92.txt
        3   93.txt
        3   94.txt
        3   95.txt
        3   96.txt
        3   97.txt
        3   98.txt
        3   99.txt
        4   100.txt
        4   101.txt
        4   102.txt
        4   103.txt
        4   104.txt
        4   105.txt
        4   106.txt
        4   107.txt
        4   108.txt
        4   109.txt
        4   110.txt
        4   111.txt
        4   112.txt
        4   113.txt
        4   114.txt
        4   115.txt
        4   116.txt
        4   117.txt
        4   118.txt
        4   119.txt
        4   120.txt
        4   121.txt
        4   122.txt
        4   123.txt
        4   124.txt
        4   125.txt
        4   126.txt
        4   127.txt
        2   0.txt
        2   1.txt
        2   2.txt
        2   3.txt
        2   4.txt
        2   5.txt
        2   6.txt
        2   7.txt
        2   8.txt
        2   9.txt
        3   10.txt
        3   11.txt
        3   12.txt
        3   13.txt
        3   14.txt
        3   15.txt
        3   16.txt
        3   17.txt
        3   18.txt
        3   19.txt
        3   20.txt
        3   21.txt
        3   22.txt
        3   23.txt
        3   24.txt
        3   25.txt
        3   26.txt
        3   27.txt
        3   28.txt
        3   29.txt
        3   30.txt
        3   31.txt
        3   32.txt
        3   33.txt
        3   34.txt
        3   35.txt
        3   36.txt
        3   37.txt
        3   38.txt
        3   39.txt
        3   40.txt
        3   41.txt
        3   42.txt
        3   43.txt
        3   44.txt
        3   45.txt
        3   46.txt
        3   47.txt
        3   48.txt
        3   49.txt
        3   50.txt
        3   51.txt
        3   52.txt
        3   53.txt
        3   54.txt
        3   55.txt
        3   56.txt
        3   57.txt
        3   58.txt
        3   59.txt
        3   60.txt
        3   61.txt
        3   62.txt
        3   63.txt
        3   64.txt
        3   65.txt
        3   66.txt
        3   67.txt
        3   68.txt
        3   69.txt
        3   70.txt
        3   71.txt
        3   72.txt
        3   73.txt
        3   74.txt
        3   75.txt
        3   76.txt
        3   77.txt
        3   78.txt
        3   79.txt
        3   80.txt
        3   81.txt
        3   82.txt
        3   83.txt
        3   84.txt
        3   85.txt
        3   86.txt
        3   87.txt
        3   88.txt
        3   89.txt
        3   90.txt
        3   91.txt
        0   0
129 file(s), 0 dir(s)
U-Boot>
Organization of the 1GB pen drive:
# fdisk -l /dev/sda
Disk /dev/sda: 1037 MB, 1037615104 bytes
256 heads, 32 sectors/track, 247 cylinders
Units = cylinders of 8192 * 512 = 4194304 bytes
Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1         247     1011696    b  W95 FAT32
#
------
...
both the 1.3.2 and the 1.2.0 releases.
It is good to know that v1.3.2 has this FAT32 bug.
I can confirm that the bug is present in 1.1.5 as well.
...
The 64MB, 128MB and 256MB fails under *ALL* cases when 
using FAT32. 
All the other sizes work with FAT32 and *all* of the media 
works fine with FAT16.
I agree with this statement, except failures do occur on media
larger than 256MB.  It just takes more files on the root directory
before a failure is observed.
...
FYI, I use "mkfs.vfat -F 32" under linux to make the 
filesystems.
Since it makes scripts more readable I'll use mkfs.vfat in the
future.  Thanks.  BTW, mkfs.vfat and mkdosfs are the same file.
...
All fingers are pointing to the FAT32 code and not hardware 
dependent code.  It looks like a media size related problem.
I agree, since no failures have been observed on FAT16 and you
tested several targets.
Be sure to include the most recent vfat patch at the very end
(deeply quoted part) of this message.
--- FAT16 benchmark test with 1GB pen drive (512 files) ---
U-Boot> fatls usb 0:1 /
fatls usb 0:1 /
2   0.txt
        2   1.txt
        2   2.txt
        2   3.txt
        2   4.txt
        2   5.txt
        2   6.txt
        2   7.txt
        2   8.txt
        2   9.txt
        3   10.txt
        3   11.txt
        3   12.txt
        3   13.txt
        3   14.txt
        3   15.txt
3   16.txt
        3   17.txt
        3   18.txt
        3   19.txt
        3   20.txt
        3   21.txt
        3   22.txt
        3   23.txt
        3   24.txt
        3   25.txt
        3   26.txt
        3   27.txt
        3   28.txt
        3   29.txt
        3   30.txt
        3   31.txt
...
4   480.txt
        4   481.txt
        4   482.txt
        4   483.txt
        4   484.txt
        4   485.txt
        4   486.txt
        4   487.txt
        4   488.txt
        4   489.txt
        4   490.txt
        4   491.txt
        4   492.txt
        4   493.txt
        4   494.txt
        4   495.txt
4   496.txt
        4   497.txt
        4   498.txt
        4   499.txt
        4   500.txt
        4   501.txt
        4   502.txt
        4   503.txt
        4   504.txt
        4   505.txt
        4   506.txt
        4   507.txt
        4   508.txt
        4   509.txt
        4   510.txt
        4   511.txt
0   0
513 file(s), 0 dir(s)
U-Boot>
------
All 512 files are listed OK, but a blank line was added
every 16 files and there is a 513th file "0" that doesn't
exist.  All files on FAT16 are accessible, but there
may be a trivial non-existent file bug in FAT16 as well.
Just to be clear, my script that should put 1000 files
in /, could only put 512 of them on, since FAT16 has some
limitation of the number of files in a directory.
Sincerely,
Ken Fuchs
...
-----Original Message-----
From: afilipi@pmy.adscville [mailto:afilipi@pmy.adscville] On 
Behalf Of Adrian Filipi
Sent: Thursday, April 24, 2008 13:38
To: Fuchs, Ken
Cc: trimarchi@gandalf.sssup.it; u-boot-users@lists.sourceforge.net
Subject: Re: [U-Boot-Users] FW: USB SUPPORT & get_vfatname
FYI, I too have been seeing this problem.  It is 100% 
reproducible. 
It seems to be a FAT32 problem with media 256MB and smaller.
I have tried various media sizes between 64MB and 2GB, 
MMC/SD, USB 
and CF media types, different boards (PXA270, EP93xx and 
IMX31), and lastly 
both the 1.3.2 and the 1.2.0 releases.
The 64MB, 128MB and 256MB fails under *ALL* cases when 
using FAT32. 
All the other sises work with FAT32 and *all* of the media 
works fine with 
FAT16.
FYI, I use "mkfs.vfat -F 32" under linux to make the 
filesystems.
All fingers are pointing to the FAT32 code and not hardware 
dependent code.  It looks like a media size related problem.  
This is also 
an old bug given that it's in the 1.2.0 sources.
Adrian
Linux Software Engineer | EuroTech, Inc. | www.eurotech-inc.com
On Wed, 23 Apr 2008, Ken.Fuchs@bench.com wrote:
...
Michael,
I copied all files in fs/fat from git repository
u-boot-at91.  Made trivial changes to compile it with my code 
base.  Added your latest get_vfatname patch, but it had no 
effect on the issue.  fatls still
...
doesn't list filenames in some FAT32 filesystems, including the one
built via the Linux script I provided earlier in this thread.
Thus, there's no point in looking at the fat.c file I sent earlier
today.  The problem remains in the git fat.c code or possibly in
the USB stack code.  However, FAT16 has never failed, so the issue
is more likely to be with the FAT32 or vfat code.
Sincerely,
Ken Fuchs
-----Original Message-----
From: u-boot-users-bounces@lists.sourceforge.net
[mailto:u-boot-users-bounces@lists.sourceforge.net] On Behalf 
Of Ken.Fuchs@bench.com
...
Sent: Wednesday, April 23, 2008 13:01
To: trimarchi@gandalf.sssup.it
Cc: u-boot-users@lists.sourceforge.net
Subject: Re: [U-Boot-Users] USB SUPPORT & get_vfatname
Michael,
Sorry, your latest get_vfatname patch doesn't work either.
FAT16 works perfectly, so the USB code is probably _not_ at
fault.  I see only problems with FAT32, but only for _some_ 
long collections of files.
...
Thus, there may still be a problem with fs/fat/fat.c.
Maybe there is something wrong with my copy of fat.c  I 
attached it;  Perhaps you can see a problem with it.
...
Sincerely,
Ken Fuchs
...
-----Original Message-----
From: michael [mailto:trimarchi@gandalf.sssup.it]
Sent: Wednesday, April 23, 2008 06:16
To: michael
Cc: Fuchs, Ken; u-boot-users@lists.sourceforge.net; Wolfgang Denk
Subject: Re: [U-Boot-Users] USB SUPPORT & get_vfatname
Hi,
michael wrote:
...
Hi,
Can you try this one?
Revert my last one patch?
It change the test code, before the while. I use your script on a
Compact Flash and it looks fine for me (under linux).
Regards Michael


...
Check if the entry is a valid dir_slot entry, otherwise it
is a dentry and the
...
name has to be taken by the get_name function
Signed-off-by: michael trimarchi trimarchi@gandalf.sssup.it

fs/fat/fat.c |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/fs/fat/fat.c b/fs/fat/fat.c
index 49c78ed..bc37cec 100644
--- a/fs/fat/fat.c
+++ b/fs/fat/fat.c
@@ -473,8 +473,14 @@ get_vfatname(fsdata *mydata, int
curclust, __u8 *cluster,
...
while (slotptr2->id > 0x01) {
	slotptr2++;
}


/* Save the real directory entry */
  realdent = (dir_entry*)slotptr2 + 1;
if (slotptr2->attr != ATTR_VFAT) {


	get_name ((dir_entry *)realdent, l_name);


	goto out;


}


while ((__u8*)slotptr2 >= get_vfatname_block) {
  	slot2str(slotptr2, l_name, &idx);
  	slotptr2--;

@@ -494,6 +500,7 @@ get_vfatname(fsdata *mydata, int
curclust, __u8 *cluster,
...
else if (*l_name == aRING) *l_name = '?';
   downcase(l_name);
+out:
   /* Return the real directory entry */
   memcpy(retdent, realdent, sizeof(dir_entry));
The scripts in this thread can be used to test the fat32
filesystem. I
do some tests using Compact Flash
device and this patchs work for me. I would like to know
if is a fat
...
...
layer problem or usb layer problem.
Michael


...
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time
to save $100.
...
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java
.sun.com/javaone
...

U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

    

Re: [U-Boot-Users] FW: USB SUPPORT & get_vfatname

Ken.Fuchs＠bench.com

Adrian