[U-Boot-Users] FW: USB SUPPORT & get_vfatname
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
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/javao... _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Hi, I try my fix and old version of u-boot system. The only different is the align of the buffer. The hardware that I have is tested with the 32Mb, 64Mb, 128Mb, 256Mb, and it works fine. I try the scripts without any problem... but the tests doesn't cover all the possibility. Can you send me a dd of a compact flash of 64Mb that failed. I rewrite it and test and maybe post a patch.
Regards Michael
Adrian Filipi wrote:
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, USBand 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 usingFAT32. 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 hardwaredependent 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
The patch didn't improve my first few test cases. CF and USB on an EP93xx board.
I'm sending you an image off-list.
Adrian -- Linux Software Engineer | EuroTech, Inc. | www.eurotech-inc.com
On Thu, 24 Apr 2008, michael wrote:
Hi, I try my fix and old version of u-boot system. The only different is the align of the buffer. The hardware that I have is tested with the 32Mb, 64Mb, 128Mb, 256Mb, and it works fine. I try the scripts without any problem... but the tests doesn't cover all the possibility. Can you send me a dd of a compact flash of 64Mb that failed. I rewrite it and test and maybe post a patch.
Regards Michael
Adrian Filipi wrote:
FYI, I too have been seeing this problem. It is 100% reproducible. Itseems to be a FAT32 problem with media 256MB and smaller.
I have tried various media sizes between 64MB and 2GB, MMC/SD, USB andCF 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. Allthe 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 dependentcode. 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
Hi, just to know! What is the log if you define the
USB_STOR_DEBUG
in the usb_storage.c
Can you send me the log?
Regards Michael
Adrian Filipi wrote:
The patch didn't improve my first few test cases. CF and USB onan EP93xx board.
I'm sending you an image off-list. Adrian-- Linux Software Engineer | EuroTech, Inc. | www.eurotech-inc.com
On Thu, 24 Apr 2008, michael wrote:
Hi, I try my fix and old version of u-boot system. The only different is the align of the buffer. The hardware that I have is tested with the 32Mb, 64Mb, 128Mb, 256Mb, and it works fine. I try the scripts without any problem... but the tests doesn't cover all the possibility. Can you send me a dd of a compact flash of 64Mb that failed. I rewrite it and test and maybe post a patch.
Regards Michael
Adrian Filipi wrote:
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 usingFAT32. 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 hardwaredependent 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
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
Michael Trimarchi wrote:
confirm that the problem is in fat.c file and I will try to fix.
It has been confirmed that fatls does _not_ list all files on FAT32 filesystems.
There are _no_ reports of fatls failing to list all files on FAT16 filesystems. (There may be an unrelated bug caused by all 512 directory entries of FAT16 being used.)
What additional information is needed to confirm that the problem is in fat.c?
What is your response to the debug log you requested? It was sent to the ml almost 18 hours ago and is also quoted below.
Sincerely,
Ken Fuchs
------
USB_STOR_DEBUG log:
Hit any key to stop autoboot: 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... i=0 i=1
USB Mass Storage device detected Transport: Bulk/Bulk/Bulk Endpoints In 1 Out 2 Int 0 BBB_reset BBB_reset result 0: status 0 reset BBB_reset result 0: status 0 clearing IN endpoint BBB_reset result 0: status 0 clearing OUT endpoint BBB_reset done address 2 COMMAND phase DATA phase STATUS phase inquiry returns 0 ISO Vers 2, Response Data 2 COMMAND phase STATUS phase FAILED COMMAND phase DATA phase STATUS phase Request Sense returned 06 28 00 COMMAND phase STATUS phase COMMAND phase DATA phase STATUS phase Read Capacity returns: 0xe80300, 0x20000 Capacity = 0x3e801, blocksz = 0x200 address 2 partype: 0
usb_read: dev 0 COMMAND phase STATUS phase
usb_read: dev 0 startblk 0, blccnt 1 buffer 23edbbe4 read10: start 0 blocks 1 COMMAND phase DATA phase STATUS phase usb_read: end startblk 1, blccnt 1 buffer 23edbde4 partype: 2 i=2 i=3 1 Storage Device(s) found U-Boot> fatls usb 0:1 / fatls usb 0:1 /
usb_read: dev 0 COMMAND phase STATUS phase
usb_read: dev 0 startblk 0, blccnt 1 buffer 23edbbc8 read10: start 0 blocks 1 COMMAND phase DATA phase STATUS phase usb_read: end startblk 1, blccnt 1 buffer 23edbdc8
usb_read: dev 0 COMMAND phase STATUS phase
usb_read: dev 0 startblk 0, blccnt 1 buffer 23edb998 read10: start 0 blocks 1 COMMAND phase DATA phase STATUS phase usb_read: end startblk 1, blccnt 1 buffer 23edbb98
usb_read: dev 0 COMMAND phase STATUS phase
usb_read: dev 0 startblk 20, blccnt 1 buffer 23eda540 read10: start 20 blocks 1 COMMAND phase DATA phase STATUS phase usb_read: end startblk 21, blccnt 1 buffer 23eda740
usb_read: dev 0 COMMAND phase STATUS phase
usb_read: dev 0 startblk fa2, blccnt 1 buffer 23f3ad78 read10: start fa2 blocks 1 COMMAND phase DATA phase STATUS phase usb_read: end startblk fa3, blccnt 1 buffer 23f3af78 9 00000000.txt 9 11111111.txt 9 22222222.txt 9 33333333.txt 9 44444444.txt 9 55555555.txt 9 66666666.txt 9 77777777.txt
usb_read: dev 0 COMMAND phase STATUS phase
usb_read: dev 0 startblk fa3, blccnt 1 buffer 23f3ad78 read10: start fa3 blocks 1 COMMAND phase DATA phase STATUS phase usb_read: end startblk fa4, blccnt 1 buffer 23f3af78 0 00000000.
9 file(s), 0 dir(s)
U-Boot>
Hi, Ken.Fuchs@bench.com wrote:
Michael Trimarchi wrote:
confirm that the problem is in fat.c file and I will try to fix.
It has been confirmed that fatls does _not_ list all files on FAT32 filesystems.
There are _no_ reports of fatls failing to list all files on FAT16 filesystems. (There may be an unrelated bug caused by all 512 directory entries of FAT16 being used.)
What additional information is needed to confirm that the problem is in fat.c?
The problem is related to how fat.c manage the root directory. As reported by microsoft in "FAT32, the root directory can be of variable size and is a cluster chain, just like any other directory is. The first cluster of the root directory on a FAT32 volume is stored in BPB_RootClus. Unlike other directories, the root directory itself on any FAT type does not have any date or time stamps, does not have a file name (other than the implied file name “\”), and does not contain “.” and “..” files as the first two directory entries in the directory. The only other special aspect of the root directory is that it is the only directory on the FAT volume for which it is valid to have a file that has only the ATTR_VOLUME_ID attribute bit set (see below)."
What is your response to the debug log you requested? It was sent to the ml almost 18 hours ago and is also quoted below.
In my spare time a try to change the do_fat_read to support the chaining.
Regards Michael
It looks like fat.c is not handling the case where the sectors/cluster is 1, and the rood directory spans multiple clusters.
In my case I was getting garbage directoy info after the invalid fat error. The attached patch stops the code from rolling past the end of cluster.
It looks like a loop to walk the allocation chain is neccessary. I think get_contents() does all the right work, but it of course starts with a directory entry, which we don't have yet for /. A little refactoring might do the trick.
Adrian -- Linux Software Engineer | EuroTech, Inc. | www.eurotech-inc.com
On Fri, 25 Apr 2008, michael wrote:
Hi, Ken.Fuchs@bench.com wrote:
Michael Trimarchi wrote:
confirm that the problem is in fat.c file and I will try to fix.
It has been confirmed that fatls does _not_ list all files on FAT32 filesystems.
There are _no_ reports of fatls failing to list all files on FAT16 filesystems. (There may be an unrelated bug caused by all 512 directory entries of FAT16 being used.)
What additional information is needed to confirm that the problem is in fat.c?
The problem is related to how fat.c manage the root directory. As reported by microsoft in "FAT32, the root directory can be of variable size and is a cluster chain, just like any other directory is. The first cluster of the root directory on a FAT32 volume is stored in BPB_RootClus. Unlike other directories, the root directory itself on any FAT type does not have any date or time stamps, does not have a file name (other than the implied file name ??), and does not contain ?.? and ?..? files as the first two directory entries in the directory. The only other special aspect of the root directory is that it is the only directory on the FAT volume for which it is valid to have a file that has only the ATTR_VOLUME_ID attribute bit set (see below)."
What is your response to the debug log you requested? It was sent to the ml almost 18 hours ago and is also quoted below.
In my spare time a try to change the do_fat_read to support the chaining.
Regards Michael
Adrian Filipi wrote:
It looks like fat.c is not handling the case where the sectors/cluster is 1, and the rood directory spans multiple clusters.
In my case I was getting garbage directory info after the invalid fat error. The attached patch stops the code from rolling past the end of cluster.
I was also getting these garbage directory entries which appeared to be file nodes being interpreted as directory nodes.
I can confirm that Adrian's patch fixes this particular problem for FAT32. Now, on FAT32, whatever files are displayed by fatls are also readable by fatload. As Adrian mentions below, the files not displayed by fatls are completely inaccessible to the current fat.c with or without Adrian's patch.
FAT16 also suffered from this "garbage" problem when there were 512 files, but the patch also fixes this. (If there is a volume name, it should use one of the root directory entries, leaving only 511 directory entries for files; otherwise, the lack/presence of a volume name probably has no effect on FAT16.)
It looks like a loop to walk the allocation chain is necessary. I think get_contents() does all the right work, but it of course starts with a directory entry, which we don't have yet for /. A little refactoring might do the trick.
Of course this only applies to FAT32. Adrian's patch appears to have fixed the only issue with FAT16 that I'm aware of.
Time permitting, I will try to fix this remaining problem myself. Adrian, thanks for your insight into the problem and a potential solution.
Sincerely,
Ken Fuchs
Hi,
Time permitting, I will try to fix this remaining problem myself. Adrian, thanks for your insight into the problem and a potential solution.
Sincerely,
Ken Fuchs
I think that is more simple to rewrite that code. It contains duplication and errors. I start to rewrite it in my spare time and so I hope that you will fix the remain problems.
Regards Michael
Hi,
I prepare a new versione of fat support to test in user space, with some modification of the function. So before to post a patch in u-boot mailing list, we can adjust the library.
I send an archive that contains a first step in this direction
Regards Michael
Ken.Fuchs@bench.com wrote:
Adrian Filipi wrote:
It looks like fat.c is not handling the case where the sectors/cluster is 1, and the rood directory spans multiple clusters.
In my case I was getting garbage directory info after the invalid fat error. The attached patch stops the code from rolling past the end of cluster.
I was also getting these garbage directory entries which appeared to be file nodes being interpreted as directory nodes.
I can confirm that Adrian's patch fixes this particular problem for FAT32. Now, on FAT32, whatever files are displayed by fatls are also readable by fatload. As Adrian mentions below, the files not displayed by fatls are completely inaccessible to the current fat.c with or without Adrian's patch.
FAT16 also suffered from this "garbage" problem when there were 512 files, but the patch also fixes this. (If there is a volume name, it should use one of the root directory entries, leaving only 511 directory entries for files; otherwise, the lack/presence of a volume name probably has no effect on FAT16.)
It looks like a loop to walk the allocation chain is necessary. I think get_contents() does all the right work, but it of course starts with a directory entry, which we don't have yet for /. A little refactoring might do the trick.
Of course this only applies to FAT32. Adrian's patch appears to have fixed the only issue with FAT16 that I'm aware of.
Time permitting, I will try to fix this remaining problem myself. Adrian, thanks for your insight into the problem and a potential solution.
Sincerely,
Ken Fuchs
In message 481462E8.6010706@gandalf.sssup.it you wrote:
I prepare a new versione of fat support to test in user space, with some modification of the function. So before to post a patch in u-boot mailing list, we can adjust the library.
I send an archive that contains a first step in this direction
Please don;t do that.
Please ALWAYS send proper patches, inlined, and plain text.
Best regards,
Wolfgang Denk
Hi, Wolfgang Denk wrote:
Please don;t do that.
Please ALWAYS send proper patches, inlined, and plain text.
Best regards,
Wolfgang Denk
You are right. I try to fix this problem. I don't send a patch but a user space version to help who want to fix fat32 problem on u-boot. I don't send any more archive on the mailing list.
Regards Michael
On Fri, 25 Apr 2008, Adrian Filipi wrote:
It looks like fat.c is not handling the case where the sectors/cluster is 1, and the rood directory spans multiple clusters.
In my case I was getting garbage directoy info after the invalid fat error. The attached patch stops the code from rolling past the end of cluster.
It looks like a loop to walk the allocation chain is neccessary. I think get_contents() does all the right work, but it of course starts with a directory entry, which we don't have yet for /. A little refactoring might do the trick.
Adrian
Linux Software Engineer | EuroTech, Inc. | www.eurotech-inc.com
FYI, my patch may have prevented walking off the end of a cluster on FAT32, but it has its own problems with larger directories on FAT16.
As such, I don't recommend using it.
Adrian -- Linux Software Engineer | EuroTech, Inc. | www.eurotech-inc.com
Michael Trimarchi wrote:
In my spare time a try to change the do_fat_read to support the chaining.
Thank you. Please let me know of anything I can do to help.
Does this mean you are now able to duplicate the problem?
The "Microsoft Extensible Firmware Initiative FAT32 File System Specification" white paper you quoted seems like a good reference document for FAT32. Is there anything better?
BTW, in working with partitions <= 32MB, I have used FAT12, but fs/fat/fat.c clearly doesn't support FAT12 properly. FAT12 can be useful for NOR flash devices which are often small enough for all four primary partitions to be <= 32MB. Is anyone else (trying to) use FAT12 via U-Boot? My work-around for this problem has simply been force partitions <= 32MB to contain FAT16 whenever U-Boot needs to read file from them.
Sincerely,
Ken Fuchs
-----Original Message----- From: michael [mailto:trimarchi@gandalf.sssup.it] Sent: Friday, April 25, 2008 10:45 To: Fuchs, Ken Cc: afilipi@applieddata.net; u-boot-users@lists.sourceforge.net Subject: Re: [U-Boot-Users] FW: USB SUPPORT & get_vfatname
Hi, Ken.Fuchs@bench.com wrote:
Michael Trimarchi wrote:
confirm that the problem is in fat.c file and I will try to fix.
It has been confirmed that fatls does _not_ list all files on FAT32 filesystems.
There are _no_ reports of fatls failing to list all files on FAT16 filesystems. (There may be an unrelated bug caused by all 512 directory entries of FAT16 being used.)
What additional information is needed to confirm that the problem is in fat.c?
The problem is related to how fat.c manage the root directory. As reported by microsoft in "FAT32, the root directory can be of variable size and is a cluster chain, just like any other directory is. The first cluster of the root directory on a FAT32 volume is stored in BPB_RootClus. Unlike other directories, the root directory itself on any FAT type does not have any date or time stamps, does not have a file name (other than the implied file name ""), and does not contain "." and ".." files as the first two directory entries in the directory. The only other special aspect of the root directory is that it is the only directory on the FAT volume for which it is valid to have a file that has only the ATTR_VOLUME_ID attribute bit set (see below)."
What is your response to the debug log you requested? It was sent to the ml almost 18 hours ago and is also quoted below.
In my spare time a try to change the do_fat_read to support the chaining.
Regards Michael
participants (5)
-
Adrian Filipi -
Adrian Filipi -
Ken.Fuchs＠bench.com -
michael -
Wolfgang Denk