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, [EMAIL PROTECTED] 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL
> PROTECTED]
> Sent: Wednesday, April 23, 2008 13:01
> To: [EMAIL PROTECTED]
> 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:[EMAIL PROTECTED]
>> 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 <[EMAIL PROTECTED]>
>>>
>>> ---
>>> 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
>
-------------------------------------------------------------------------
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
