[U-Boot-Users] FW: USB SUPPORT & get_vfatname
Ken.Fuchs at bench.com
Ken.Fuchs at bench.com
Fri Apr 25 01:32:26 CEST 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 at pmy.adscville [mailto:afilipi at pmy.adscville] On
> Behalf Of Adrian Filipi
> Sent: Thursday, April 24, 2008 13:38
> To: Fuchs, Ken
> Cc: trimarchi at gandalf.sssup.it; u-boot-users at 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 at 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 at lists.sourceforge.net
> [mailto:u-boot-users-bounces at lists.sourceforge.net] On Behalf
> Of Ken.Fuchs at bench.com
> > Sent: Wednesday, April 23, 2008 13:01
> > To: trimarchi at gandalf.sssup.it
> > Cc: u-boot-users at 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 at gandalf.sssup.it]
> >> Sent: Wednesday, April 23, 2008 06:16
> >> To: michael
> >> Cc: Fuchs, Ken; u-boot-users at 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 at 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
>
More information about the U-Boot
mailing list