[U-Boot-Users] Usb support

[U-Boot-Users] Usb support

[swamy]

Hi,

I am interested in knowing any development on bootloader (Uboot) to download
kernel using usb
port( PXA255) instead of serial or Ethernet?

Thanks
swamy

[U-Boot-Users] USB Support

[Ajay Jain]

Hello,

We support U-Boot on our proprietary board based on ARM core. I wanted
to take up a design discussion with you guys. We want to support a
kernel upgradation on our phone (board). This means  that the end user
can upgrade his kernel and ramdisk on his phone during his lifetime. I
was thinking on how to accomplish this.

1. I feel that passing the upgradation control to the boot loader is
the most viable option. Any comments?
2. The other idea could be to upgrade the kernel while boot up by
keeping a redundant kernel and doing a ping pong.
3. Assuming 1), how well is USB supported in U-Boot. Since the most
elegant solution is to expose the phone as a Mass Storage device, is
the mass storage gadget driver available on U-Boot?
4. I see host controller support in U-Boot, what is the application?

Thanks & Regards.
Ajay

[U-Boot-Users] USB SUPPORT

[Aneesh]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080421/460828b4/attachment.htm 

[U-Boot-Users] USB SUPPORT

[Markus Klotzbücher]

Hi Aneesh,

Aneesh <aneesh_g@cms.com> writes:

>        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

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 at denx.de

[U-Boot-Users] USB SUPPORT

[Ken.Fuchs at bench.com]

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

[U-Boot-Users] USB SUPPORT

[michael]

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

[U-Boot-Users] USB SUPPORT

[Ken.Fuchs at bench.com]

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

[U-Boot-Users] USB SUPPORT

[michael]

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

[U-Boot-Users] USB SUPPORT

[Ken.Fuchs at bench.com]

--- 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mkpen
Type: application/octet-stream
Size: 228 bytes
Desc: mkpen
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080422/698e53c2/attachment.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: u-boot-usb-bug.img.bz2
Type: application/octet-stream
Size: 1630 bytes
Desc: u-boot-usb-bug.img.bz2
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080422/698e53c2/attachment-0001.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mklpen
Type: application/octet-stream
Size: 485 bytes
Desc: mklpen
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080422/698e53c2/attachment-0002.obj 

[U-Boot-Users] USB SUPPORT

[michael]

Hi,
Ken.Fuchs at 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

[U-Boot-Users] USB SUPPORT

[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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: vfat-check-name.patch
Type: text/x-patch
Size: 1059 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080423/dfcaf019/attachment.bin 

[U-Boot-Users] USB SUPPORT & get_vfatname

[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

[U-Boot-Users] USB SUPPORT & get_vfatname

[Ken.Fuchs at bench.com]

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@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
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fat.c
Type: application/octet-stream
Size: 24738 bytes
Desc: fat.c
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080423/2a4bffdc/attachment.obj 

[U-Boot-Users] USB SUPPORT & get_vfatname

[michael]

Ken.Fuchs at 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 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@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
>>
>>
>>     

[U-Boot-Users] USB SUPPORT & get_vfatname

[Ken.Fuchs at bench.com]

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 at gandalf.sssup.it] 
> Sent: Thursday, April 24, 2008 03:00
> To: Fuchs, Ken
> Cc: u-boot-users at lists.sourceforge.net
> Subject: Re: [U-Boot-Users] USB SUPPORT & get_vfatname
> 
> 
> Ken.Fuchs at 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 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@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
> >>
> >>
> >>     
> 
> 

[U-Boot-Users] USB SUPPORT & get_vfatname

[michael]

Hi,
Ken.Fuchs at 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

[U-Boot-Users] USB SUPPORT & get_vfatname

[Ken.Fuchs at bench.com]

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 at gandalf.sssup.it] 
> Sent: Thursday, April 24, 2008 12:01
> To: Fuchs, Ken
> Cc: u-boot-users at lists.sourceforge.net
> Subject: Re: [U-Boot-Users] USB SUPPORT & get_vfatname
> 
> 
> Hi,
> Ken.Fuchs at 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
> 
>