[U-Boot-Users] USB SUPPORT
Hi, I am using an at91rm9200dk custom board.I want to boot kernel and ram disk from the usb stick.for that i tried to enable the usb support in the uboot.but now i am getting a message like no storage devices found . i gave the configurations in include/configs/at91rm9200dk.h like follows
#define CONFIG_DOS_PARTITION 1 #define CONFIG_USB_OHCI 1 #define CONFIG_USB_STORAGE 1
#define CONFIG_COMMANDS \ ((CONFIG_CMD_DFL | CFG_CMD_MII | CFG_CMD_NET | CFG_CMD_USB | \ CFG_CMD_DHCP ) & \ ~(CFG_CMD_BDI | \ CFG_CMD_IMI | \ CFG_CMD_AUTOSCRIPT | \ CFG_CMD_FPGA | \ CFG_CMD_MISC | \ CFG_CMD_LOADS))
Is this configuration is right? i am not able to acess the USB stick using Storage USB Commands. My U-boot version is 1.1.5. Any one can help? regards Aneesh
Hi Aneesh,
Aneesh aneesh_g@cms.com writes:
I am using an at91rm9200dk custom board.I want to boot kernel andram disk from the usb stick.for that i tried to enable the usb support in the uboot.but now i am getting a message like no storage devices found . i gave the configurations in include/configs/at91rm9200dk.h like follows #define CONFIG_DOS_PARTITION 1 #define CONFIG_USB_OHCI 1
You should use the new ohci driver and define CONFIG_USB_OHCI_NEW. But that alone is not enough, please checkout doc/README.generic_usb_ohci.
#define CONFIG_USB_STORAGE 1 #define CONFIG_COMMANDS \ ((CONFIG_CMD_DFL | CFG_CMD_MII | CFG_CMD_NET | CFG_CMD_USB | \ CFG_CMD_DHCP ) & \ ~(CFG_CMD_BDI | \ CFG_CMD_IMI | \ CFG_CMD_AUTOSCRIPT | \ CFG_CMD_FPGA | \ CFG_CMD_MISC | \ CFG_CMD_LOADS)) Is this configuration is right? i am not able to acess the USB stick using Storage USB Commands. My U-boot version is 1.1.5.
Oh, and please update your U-Boot version to top of git before anything else.
Best regards
Markus Klotzbuecher
-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
Aneesh wrote:
I am using an at91rm9200dk custom board.I want to boot kernel and ram disk from the usb stick.for that i tried to enable the usb support in the uboot. but now i am getting a message like no storage devices found .
Someone else has already suggested using a current U-Boot version via git rather than v1.1.5, so I will restrict my comments to the old 1.1.5 version.
i gave the configurations in include/configs/at91rm9200dk.h like follows
#define CONFIG_DOS_PARTITION 1 #define CONFIG_USB_OHCI 1 #define CONFIG_USB_STORAGE 1
I have a AT91SAM9261-EK (v1.1.5) with working USB Storage that also includes ...
#define LITTLEENDIAN 1
as part of the USB configuration.
#define CONFIG_COMMANDS \ ((CONFIG_CMD_DFL | CFG_CMD_MII | CFG_CMD_NET | CFG_CMD_USB | \ CFG_CMD_DHCP ) & \ ~(CFG_CMD_BDI | \ CFG_CMD_IMI | \ CFG_CMD_AUTOSCRIPT | \ CFG_CMD_FPGA | \ CFG_CMD_MISC | \ CFG_CMD_LOADS))
Is this configuration is right? i am not able to acess the USB stick using Storage USB Commands. My U-boot version is 1.1.5. Any one can help?
--- When you get USB Storage working - either v1.1.5 or git ---
You will probably need (at least want)
#define CFG_CMD_FAT
or
#define CFG_CMD_EXT2
to access the FAT or ext2 directories and files on the USB Storage device.
This may be useful if your kernel and ramdisk are files on a FAT/ext2 filesystem (rather than at a fixed locations on the raw USB device).
u-boot> setenv bootcmd ... u-boot> saveenv
--- VFAT ---
You may want to include the following for long filename support (for FAT filesystems):
#define CONFIG_SUPPORT_VFAT
--- FAT16 vs. FAT32 - Atmel U-Boot v1.1.5 issue? ---
I have found that the USB support is better when the USB Storage device is FAT16 formatted rather than FAT32 formatted. For some reason not all files were accessible on FAT32 formatted media, but I never had any problem with FAT16 formatted media.
Sincerely,
Ken Fuchs
Hi,
#define CONFIG_SUPPORT_VFAT
--- FAT16 vs. FAT32 - Atmel U-Boot v1.1.5 issue? ---
I have found that the USB support is better when the USB Storage device is FAT16 formatted rather than FAT32 formatted. For some reason not all files were accessible on FAT32 formatted media, but I never had any problem with FAT16 formatted media.
Sincerely,
Ken Fuchs
Can you try this patch? In the git log there is another patch for vfat to be applied. 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..ddee823 100644 --- a/fs/fat/fat.c +++ b/fs/fat/fat.c @@ -470,6 +470,12 @@ get_vfatname(fsdata *mydata, int curclust, __u8 *cluster, return -1; } slotptr2 = (dir_slot*) get_vfatname_block; + if (slotptr2->attr != ATTR_VFAT) { + realdent = (dir_entry *)get_vfatname_block; + get_name ((dir_entry *)get_vfatname_block, l_name); + goto out; + } + while (slotptr2->id > 0x01) { 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));
-- 1.5.2.1.174.gcd03-dirty
micheal wrote:
Ken Fuchs wrote:
#define CONFIG_SUPPORT_VFAT
--- FAT16 vs. FAT32 - Atmel U-Boot v1.1.5 issue? ---
I have found that the USB support is better when the USB Storage device is FAT16 formatted rather than FAT32 formatted. For some reason not all files were accessible on FAT32 formatted media, but I never had any problem with FAT16 formatted media.
Can you try this patch? In the git log there is another patch for vfat to be applied.
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
I tried it, but it did not work.
I also tried the earlier patch where Michael Trimarchi added the CHECK_CLUST() macro, but it still doesn't work.
Next, I compared my fs/fat/fat.c with what was in git a few hours ago. The only significant differences were in the fat_register_device(), but after making my fs/fat/fat.c match what's in git (except for trivial whitespace differences and recent CONFIG_* & CFG_* handling differences, it still fails to work properly.
Test pen drive content:
$ ls -lU total 6354 -rw-r--r-- 1 fuchsk mkpasswd 1298 Apr 18 12:57 xy010.ubs -rw-r--r-- 1 fuchsk mkpasswd 1298 Apr 18 12:57 xy011.ubs -rw-r--r-- 1 fuchsk mkpasswd 1298 Apr 18 12:57 xy100.ubs -rw-r--r-- 1 fuchsk mkpasswd 1298 Apr 18 12:57 xy101.ubs drwxr-xr-x 2 fuchsk mkpasswd 0 Apr 21 17:31 admin -rw-r--r-- 1 fuchsk mkpasswd 1298 Apr 18 12:57 xy110.ubs -rw-r--r-- 1 fuchsk mkpasswd 1298 Apr 18 12:58 xy111.ubs drwxr-xr-x 3 fuchsk mkpasswd 0 Apr 21 17:31 Linux_demo drwxr-xr-x 2 fuchsk mkpasswd 0 Apr 21 17:31 photos drwxr-xr-x 2 fuchsk mkpasswd 0 Apr 21 17:31 videos -rw-r--r-- 1 fuchsk mkpasswd 32 Apr 18 12:56 ab000.txt -rw-r--r-- 1 fuchsk mkpasswd 32 Apr 18 12:56 ab001.txt -rw-r--r-- 1 fuchsk mkpasswd 32 Apr 18 12:57 ab010.txt -rw-r--r-- 1 fuchsk mkpasswd 32 Apr 18 12:57 ab011.txt -rw-r--r-- 1 fuchsk mkpasswd 32 Apr 18 12:57 ab100.txt -rw-r--r-- 1 fuchsk mkpasswd 32 Apr 18 12:57 ab101.txt -rw-r--r-- 1 fuchsk mkpasswd 32 Apr 18 12:57 ab110.txt -rw-r--r-- 1 fuchsk mkpasswd 32 Apr 18 12:57 ab111.txt -rw-r--r-- 1 fuchsk mkpasswd 308326 Dec 18 2006 coffee.bmp -rw-r--r-- 1 fuchsk mkpasswd 24116 Dec 18 2006 debian.bmp -rw-r--r-- 1 fuchsk mkpasswd 153720 Dec 18 2006 debianlilo.bmp -rw-r--r-- 1 fuchsk mkpasswd 65 Mar 31 13:01 index.txt -rw-r--r-- 1 fuchsk mkpasswd 179 Apr 15 11:52 locvar.ubs -rw-r--r-- 1 fuchsk mkpasswd 95 Apr 15 12:17 locvar1.ubs -rw-r--r-- 1 fuchsk mkpasswd 101 Apr 15 12:28 locvar2.ubs -rw-r--r-- 1 fuchsk mkpasswd 23662 Dec 18 2006 sarge.bmp -rw-r--r-- 1 fuchsk mkpasswd 24116 Dec 18 2006 sid.bmp -rw-r--r-- 1 fuchsk mkpasswd 6719 Apr 18 12:57 test000.ugz -rw-r--r-- 1 fuchsk mkpasswd 6719 Apr 18 12:57 test001.ugz -rw-r--r-- 1 fuchsk mkpasswd 6722 Apr 18 12:57 test010.ugz -rw-r--r-- 1 fuchsk mkpasswd 6721 Apr 18 12:57 test011.ugz -rw-r--r-- 1 fuchsk mkpasswd 6720 Apr 18 12:57 test100.ugz -rw-r--r-- 1 fuchsk mkpasswd 6720 Apr 18 12:57 test101.ugz -rw-r--r-- 1 fuchsk mkpasswd 6715 Apr 18 12:57 test110.ugz -rw-r--r-- 1 fuchsk mkpasswd 6717 Apr 18 12:58 test111.ugz -rw-r--r-- 1 fuchsk mkpasswd 92160 Oct 11 2007 U-Boot-xload.bin -rw-r--r-- 1 fuchsk mkpasswd 5706338 Apr 18 12:46 xxx1.ugz.dis -rw-r--r-- 1 fuchsk mkpasswd 41007 Apr 18 12:52 xxx2.ugz.dis -rw-r--r-- 1 fuchsk mkpasswd 41007 Apr 18 12:56 xxx3.ugz.dis -rw-r--r-- 1 fuchsk mkpasswd 1298 Apr 18 12:57 xy000.ubs -rw-r--r-- 1 fuchsk mkpasswd 1298 Apr 18 12:57 xy001.ubs $ ls -lU | wc 42 371 2504 $
Here's fatls output on an XP FAT32 formatted pen drive:
U-Boot> fatls usb 0:1 / fatls usb 0:1 / 1298 xy010.ubs 1298 xy011.ubs 1298 xy100.ubs 1298 xy101.ubs admin/ 1298 xy110.ubs 1298 xy111.ubs linux_demo/ photos/ videos/ 32 ab000.txt 32 ab001.txt 32 ab010.txt 32 ab011.txt 32 ab100.txt 32 ab101.txt 32 ab110.txt 32 ab111.txt 308326 coffee.bmp 24116 debian.bmp 153720 debianlilo.bmp 65 index.txt 179 locvar.ubs 95 locvar1.ubs 101 locvar2.ubs 23662 sarge.bmp 24116 sid.bmp 6719 test000.ugz 6719 test001.ugz \365+3.\341 write.sk4/ 1718159906 .000 otm.800/ / 2016419888 .mmc 808464432 20000000."
0.0x2/ if.ad/ :1.000/ 808464432 ." 1948269360 ; 1920409699 hen
ite.0/ .wri/ .280/ 540028976 " if.loa 1763713056 /part3.u.gz; f.0x2/ .280/ 808465457 ho 0.000/ 544172131 28000.000 1667566090 ".
0.10./ 2016419949 ; 808464432 .ite 538976266 0x200000.00
40 file(s), 17 dir(s)
U-Boot>
Here's fatls output on an Linux mkdosfs -F 32 formatted pen drive:
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 / 32 ab001.txt 32 ab101.txt 1298 xy001.ubs 1298 xy101.ubs 6719 test001.ugz 6720 test101.ugz admin/ linux_demo/ photos/ videos/ 308326 coffee.bmp 24116 debian.bmp 168636477 version=.3
9 file(s), 4 dir(s)
U-Boot>
---
Sincerely,
Ken Fuchs
Hi,
$ ls -lU | wc 42 371 2504 $
Here's fatls output on an XP FAT32 formatted pen drive:
U-Boot> fatls usb 0:1 / fatls usb 0:1 / 1298 xy010.ubs 1298 xy011.ubs 1298 xy100.ubs 1298 xy101.ubs admin/ 1298 xy110.ubs 1298 xy111.ubs linux_demo/ photos/ videos/ 32 ab000.txt 32 ab001.txt 32 ab010.txt 32 ab011.txt 32 ab100.txt 32 ab101.txt 32 ab110.txt 32 ab111.txt 308326 coffee.bmp 24116 debian.bmp 153720 debianlilo.bmp 65 index.txt 179 locvar.ubs 95 locvar1.ubs 101 locvar2.ubs 23662 sarge.bmp 24116 sid.bmp 6719 test000.ugz 6719 test001.ugz \365+3.\341 write.sk4/ 1718159906 .000 otm.800/ / 2016419888 .mmc 808464432 20000000."
0.0x2/ if.ad/ :1.000/808464432 ." 1948269360 ; 1920409699 hen
ite.0/ .wri/ .280/540028976 " if.loa 1763713056 /part3.u.gz; f.0x2/ .280/ 808465457 ho 0.000/ 544172131 28000.000 1667566090 ".
0.10./2016419949 ; 808464432 .ite 538976266 0x200000.00
40 file(s), 17 dir(s)
U-Boot>
Can you give an image of it?
Regards Michael
--- Introduction ---
This thread concerns possible problems with fs/fat/fat.c (incorrect fatls output and inaccessible files via fatload) even when recent "git" patches have been applied to fat.c. VFAT is enabled.
Michael Trimarchi wrote:
Can you give an image of it?
(He is referring to the FAT32 image where "fatls usb 0:1 /" resulted in a clearly garbled/incorrect directory listing.)
Rather than that particular image, I decided to write two scripts that do most of the work building two other FAT32 images that trigger problems with "fatls usb 0:1 /". Note that one FAT32 image is made on XP/Cygwin (mkpen) and the other on FLOSS/Linux ..err.. GNU/Linux (mklpen). Note that two FAT32 images they make do have exactly the same files and file content, built in exactly the same order, but since the filesystem code is different, the metadata will probably also be different ... different inodes ... etc.
The attached mkpen is the XP/Cygwin build script and u-boot-usb-bug.img.bz2 is a bzip2 compression of the XP FAT32 image that demonstrates the problems (shown below) when accessed by U-Boot's fatls.
The attached mklpen automates the whole process on a Linux host, except you still need to enter the command ./mklpen and move the pen drive from host to target when done... It makes a slightly a different FAT32 image that reveals the same issues with fat.c a bit faster. The part where it wipes out /dev/sda1 is commented out, so uncomment at your risk and modify as needed for a SCSI host.
The middle of this message describes how the XP FAT32 image was made. The latter part of this message shows the list of files via XP/Cygwin and a different list shown via U-Boot's fatls.
--- Pen drive used ---
A 128MB USB pen drive with the following partition table is being used (only one pen drive was used in testing):
# fdisk -l /dev/sda
Disk /dev/sda: 131 MB, 131072512 bytes 8 heads, 32 sectors/track, 1000 cylinders Units = cylinders of 256 * 512 = 131072 bytes
Device Boot Start End Blocks Id System /dev/sda1 1 1000 127984 b W95 FAT32 #
--- XP/Cygwin FAT32 image build procedure ---
(For FLOSS/Linux host, just use the attached mklpen script.)
1) On Linux do:
# dd if=/dev/zero of=/dev/sda1 bs=`echo "32 * 512" | bc`
This is an attempt to reduce the effect of a bad "link" to unallocated space. There is _no_ proof that this happens. (Only null strings and null pointers can now be found here.)
2) On MS Windows XP or similar OS, format (mkfs) partition 1 with a FAT32 filesystem.
Alternative) On Linux: # mkdosfs -F 32 /dev/sda1
Warning: Linux mkdosfs and XP make different FAT32 images.
3) In a Cygwin bash shell, run the mkpen script with cd set to /cygdrive/d (or e, f, g, etc. as appropriate):
#!/bin/bash for char in 0 1 2 3 4 5 6 7 8 9 a b c d e f g h \ i j k l m n o p q r s t u v w x y z ; do file=; for (( index=0 ; index < 8 ; index++ )) ; do file=${file}${char}; done; echo "${file}" > ${file}.txt done
Alternative) On Linux, run the same script.
Warning: Linux vfat fs and XP FAT32 fs code may produce different FAT32 images when running this script.
--- Note about building the FAT32 image with FLOSS ---
I also tested the FAT32 image that is built exclusively via FLOSS tools (using the Linux alternatives in steps 2 & 3 or mklpen). The result is shown at the end of this message.
--- ls -lU output of USB pen drive root directory ---
$ cd /pen1 $ ls -lU total 36 -rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 00000000.txt -rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 11111111.txt -rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 22222222.txt -rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 33333333.txt -rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 44444444.txt -rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 55555555.txt -rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 66666666.txt -rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 77777777.txt -rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 88888888.txt -rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 99999999.txt -rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 aaaaaaaa.txt -rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 bbbbbbbb.txt -rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 cccccccc.txt -rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 dddddddd.txt -rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 eeeeeeee.txt -rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 ffffffff.txt -rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 gggggggg.txt -rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 hhhhhhhh.txt -rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 iiiiiiii.txt -rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 jjjjjjjj.txt -rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 kkkkkkkk.txt -rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 llllllll.txt -rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 mmmmmmmm.txt -rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 nnnnnnnn.txt -rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 oooooooo.txt -rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 pppppppp.txt -rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 qqqqqqqq.txt -rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 rrrrrrrr.txt -rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 ssssssss.txt -rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 tttttttt.txt -rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 uuuuuuuu.txt -rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 vvvvvvvv.txt -rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 wwwwwwww.txt -rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 xxxxxxxx.txt -rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 yyyyyyyy.txt -rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 zzzzzzzz.txt $
--- U-Boot fatls output of the same directory ---
Hit any key to stop autoboot: 59 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 / 9 00000000.txt 9 11111111.txt 9 22222222.txt 9 33333333.txt 9 44444444.txt 9 55555555.txt 9 66666666.txt 9 77777777.txt 9 88888888.txt 9 99999999.txt 9 aaaaaaaa.txt 9 bbbbbbbb.txt 9 cccccccc.txt 9 dddddddd.txt 9 eeeeeeee.txt 9 ffffffff.txt 9 gggggggg.txt 9 hhhhhhhh.txt 9 iiiiiiii.txt 9 jjjjjjjj.txt 9 kkkkkkkk.txt 9 llllllll.txt 9 mmmmmmmm.txt 9 nnnnnnnn.txt 9 oooooooo.txt 9 pppppppp.txt 9 qqqqqqqq.txt 9 rrrrrrrr.txt 9 ssssssss.txt 9 tttttttt.txt 9 uuuuuuuu.txt 9 vvvvvvvv.txt 0 00000000.
33 file(s), 0 dir(s)
U-Boot>
--- Comments ---
Notice that the last four files are not listed and "00000000." is a non-existent file that is listed. (There should be 36 files.)
--- U-Boot fatls output of FAT32 image built entirely on Linux ---
Hit any key to stop autoboot: 48 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 / 9 00000000.txt 9 11111111.txt 9 22222222.txt 9 33333333.txt 9 44444444.txt 9 55555555.txt 9 66666666.txt 9 77777777.txt 0 00000000.
9 file(s), 0 dir(s)
U-Boot>
---
Sincerely,
Ken Fuchs
Hi, Ken.Fuchs@bench.com wrote:
--- Introduction ---
This thread concerns possible problems with fs/fat/fat.c (incorrect fatls output and inaccessible files via fatload) even when recent "git" patches have been applied to fat.c. VFAT is enabled.
Michael Trimarchi wrote:
Can you give an image of it?
Notice that the last four files are not listed and "00000000." is a non-existent file that is listed. (There should be 36 files.)
--- U-Boot fatls output of FAT32 image built entirely on Linux ---
Hit any key to stop autoboot: 48 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 / 9 00000000.txt 9 11111111.txt 9 22222222.txt 9 33333333.txt 9 44444444.txt 9 55555555.txt 9 66666666.txt 9 77777777.txt 0 00000000.
9 file(s), 0 dir(s)
U-Boot>
Sincerely,
Ken Fuchs
Thank's...
Regards Michael
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
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
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
Ken.Fuchs@bench.com wrote: Ok,
check your fat.h and your fsdata
typedef struct { __u8 fatbuf[FATBUFSIZE]; /* Current FAT buffer */ int fatsize; /* Size of FAT in bits */ __u16 fatlength; /* Length of FAT in sectors */ __u16 fat_sect; /* Starting sector of the FAT */ __u16 rootdir_sect; /* Start sector of root directory */ __u16 clust_size; /* Size of clusters in sectors */ short data_begin; /* The sector of the first cluster, can be negative */ int fatbufnum; /* Used by get_fatent, init to -1 */ } fsdata;
The fatbuf is on the top?
Regards Michael
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
My include/fat.h is identical to the fat.h in both git repository u-boot and git repository u-boot-at91, except that I put the CHECKCLUST() macro in fat.c rather than fat.h.
Ken
-----Original Message----- From: michael [mailto:trimarchi@gandalf.sssup.it] Sent: Thursday, April 24, 2008 03:00 To: Fuchs, Ken Cc: u-boot-users@lists.sourceforge.net Subject: Re: [U-Boot-Users] USB SUPPORT & get_vfatname
Ken.Fuchs@bench.com wrote: Ok,
check your fat.h and your fsdata
typedef struct { __u8 fatbuf[FATBUFSIZE]; /* Current FAT buffer */ int fatsize; /* Size of FAT in bits */ __u16 fatlength; /* Length of FAT in sectors */ __u16 fat_sect; /* Starting sector of the FAT */ __u16 rootdir_sect; /* Start sector of root directory */ __u16 clust_size; /* Size of clusters in sectors */ short data_begin; /* The sector of the first cluster, can be negative */ int fatbufnum; /* Used by get_fatent, init to -1 */ } fsdata;
The fatbuf is on the top?
Regards Michael
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
Hi, Ken.Fuchs@bench.com wrote:
My include/fat.h is identical to the fat.h in both git repository u-boot and git repository u-boot-at91, except that I put the CHECKCLUST() macro in fat.c rather than fat.h.
Ken
Can you put in debug the fat.c file? Try to align the temp buffer in fat.c to 32 bit and send to the list a log file during the fatls command.
To do the align just put the attribute keyword.
fat/fat.c: __u8 tmpbuf[FS_BLOCK_SIZE] __attribute__((aligned(4))); fat/fat.c:__u8 get_vfatname_block[MAX_CLUSTSIZE] __attribute__((aligned(4))); fat/fat.c:__u8 get_dentfromdir_block[MAX_CLUSTSIZE] __attribute__((aligned(4))); fat/fat.c:__u8 do_fat_read_block[MAX_CLUSTSIZE] __attribute__((aligned(4)));
Your test in my CF card works without problem.
Regards Michael
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>
-----Original Message----- From: michael [mailto:trimarchi@gandalf.sssup.it] Sent: Thursday, April 24, 2008 12:01 To: Fuchs, Ken Cc: u-boot-users@lists.sourceforge.net Subject: Re: [U-Boot-Users] USB SUPPORT & get_vfatname
Hi, Ken.Fuchs@bench.com wrote:
My include/fat.h is identical to the fat.h in both git repository u-boot and git repository u-boot-at91, except that I put the CHECKCLUST() macro in fat.c rather than fat.h.
Ken
Can you put in debug the fat.c file? Try to align the temp buffer in fat.c to 32 bit and send to the list a log file during the fatls command.
To do the align just put the attribute keyword.
fat/fat.c: __u8 tmpbuf[FS_BLOCK_SIZE] __attribute__((aligned(4))); fat/fat.c:__u8 get_vfatname_block[MAX_CLUSTSIZE] __attribute__((aligned(4))); fat/fat.c:__u8 get_dentfromdir_block[MAX_CLUSTSIZE] __attribute__((aligned(4))); fat/fat.c:__u8 do_fat_read_block[MAX_CLUSTSIZE] __attribute__((aligned(4)));
Your test in my CF card works without problem.
Regards Michael
participants (4)
-
Aneesh -
Ken.Fuchs＠bench.com -
Markus Klotzbücher -
michael