Patchwork [U-Boot,v2,7/8] FAT: Simplify get_contents

login
register
mail settings
Submitter Benoît Thébaudeau
Date July 20, 2012, 1:21 p.m.
Message ID <1663419836.332713.1342790497668.JavaMail.root@advansee.com>
Download mbox | patch
Permalink /patch/172268/
State Superseded
Delegated to: Tom Rini
Headers show

Comments

Benoît Thébaudeau - July 20, 2012, 1:21 p.m.
One call to get_cluster can be factorized with another, so avoid duplicating
code.

Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
Cc: Wolfgang Denk <wd@denx.de>
---
Changes for v2:
 - Patch renumbering because of the new v2 1/8.
 - Possible code style changes due to the new v2 1/8.

 .../fs/fat/fat.c                                   |   14 +-------------
 1 file changed, 1 insertion(+), 13 deletions(-)
Wolfgang Denk - Sept. 2, 2012, 3:25 p.m.
Dear Benoît Thébaudeau,

In message <1663419836.332713.1342790497668.JavaMail.root@advansee.com> you wrote:
> One call to get_cluster can be factorized with another, so avoid duplicatin> g
> code.
>
> Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
> Cc: Wolfgang Denk <wd@denx.de>
> ---
> Changes for v2:
>  - Patch renumbering because of the new v2 1/8.
>  - Possible code style changes due to the new v2 1/8.
>
>  .../fs/fat/fat.c                                   |   14 +-------------
>  1 file changed, 1 insertion(+), 13 deletions(-)

Applied, thanks.

Best regards,

Wolfgang Denk
Tom Rini - Sept. 4, 2012, 8:50 p.m.
On Sun, Sep 02, 2012 at 05:25:20PM +0200, Wolfgang Denk wrote:
> Dear Beno??t Th??baudeau,
> 
> In message <1663419836.332713.1342790497668.JavaMail.root@advansee.com> you wrote:
> > One call to get_cluster can be factorized with another, so avoid duplicatin> g
> > code.
> >
> > Signed-off-by: Beno??t Th??baudeau <benoit.thebaudeau@advansee.com>
> > Cc: Wolfgang Denk <wd@denx.de>
> > ---
> > Changes for v2:
> >  - Patch renumbering because of the new v2 1/8.
> >  - Possible code style changes due to the new v2 1/8.
> >
> >  .../fs/fat/fat.c                                   |   14 +-------------
> >  1 file changed, 1 insertion(+), 13 deletions(-)
> 
> Applied, thanks.

OK, this change is NOT equivalent code.  My platforms now hang thusly
(with DEBUG set):
reading u-boot.img
VFAT Support enabled
FAT16, fat_sect: 4, fatlength: 144
Rootdir begins at cluster: 0, sector: 292, offset: 24800
Data begins at: 316
Sector size: 512, cluster size: 4
FAT read sect=292, clust_size=4, DIRENTSPERBLOCK=16
Rootvfatname: |u-boot.ais|
RootMismatch: |u-boot.ais|u-boot.ais|
RootMismatch: |u-boot.ais||
RootMismatch: |mlo||
Rootvfatname: |u-boot.img|
RootName: u-boot.img, start: 0xc2, size:  0x337d0 
Filesize: 210896 bytes
64 bytes
gc - clustnum: 194, startsect: 1092
Size: 210896, got: 64

This is all fine in full U-Boot.
Benoît Thébaudeau - Sept. 4, 2012, 10:07 p.m.
Hi Tom,

On Tuesday, September 4, 2012 10:50:34 PM, Tom Rini wrote:
> On Sun, Sep 02, 2012 at 05:25:20PM +0200, Wolfgang Denk wrote:
> > Dear Beno??t Th??baudeau,
> > 
> > In message
> > <1663419836.332713.1342790497668.JavaMail.root@advansee.com> you
> > wrote:
> > > One call to get_cluster can be factorized with another, so avoid
> > > duplicatin> g
> > > code.
> > >
> > > Signed-off-by: Beno??t Th??baudeau
> > > <benoit.thebaudeau@advansee.com>
> > > Cc: Wolfgang Denk <wd@denx.de>
> > > ---
> > > Changes for v2:
> > >  - Patch renumbering because of the new v2 1/8.
> > >  - Possible code style changes due to the new v2 1/8.
> > >
> > >  .../fs/fat/fat.c                                   |   14
> > >  +-------------
> > >  1 file changed, 1 insertion(+), 13 deletions(-)
> > 
> > Applied, thanks.
> 
> OK, this change is NOT equivalent code.  My platforms now hang thusly
> (with DEBUG set):
> reading u-boot.img
> VFAT Support enabled
> FAT16, fat_sect: 4, fatlength: 144
> Rootdir begins at cluster: 0, sector: 292, offset: 24800
> Data begins at: 316
> Sector size: 512, cluster size: 4
> FAT read sect=292, clust_size=4, DIRENTSPERBLOCK=16
> Rootvfatname: |u-boot.ais|
> RootMismatch: |u-boot.ais|u-boot.ais|
> RootMismatch: |u-boot.ais||
> RootMismatch: |mlo||
> Rootvfatname: |u-boot.img|
> RootName: u-boot.img, start: 0xc2, size:  0x337d0
> Filesize: 210896 bytes
> 64 bytes
> gc - clustnum: 194, startsect: 1092
> Size: 210896, got: 64
> 
> This is all fine in full U-Boot.

OK. I'm looking into it.

Can you give more details, like the type of storage (usb, mmc, etc.)? Do you
have a command line and a disk image that could be used to duplicate the issue?

Best regards,
Benoît
Wolfgang Denk - Sept. 4, 2012, 10:08 p.m.
Dear Tom,

In message <20120904205034.GC23991@bill-the-cat> you wrote:
>
> OK, this change is NOT equivalent code.  My platforms now hang thusly

argh... :-(

> This is all fine in full U-Boot.

What shall we do?  Revert?  Fix?

Best regards,

Wolfgang Denk
Tom Rini - Sept. 4, 2012, 10:10 p.m.
On 09/04/2012 03:07 PM, Benoît Thébaudeau wrote:
> Hi Tom,
> 
> On Tuesday, September 4, 2012 10:50:34 PM, Tom Rini wrote:
>> On Sun, Sep 02, 2012 at 05:25:20PM +0200, Wolfgang Denk wrote:
>>> Dear Beno??t Th??baudeau,
>>>
>>> In message
>>> <1663419836.332713.1342790497668.JavaMail.root@advansee.com> you
>>> wrote:
>>>> One call to get_cluster can be factorized with another, so avoid
>>>> duplicatin> g
>>>> code.
>>>>
>>>> Signed-off-by: Beno??t Th??baudeau
>>>> <benoit.thebaudeau@advansee.com>
>>>> Cc: Wolfgang Denk <wd@denx.de>
>>>> ---
>>>> Changes for v2:
>>>>  - Patch renumbering because of the new v2 1/8.
>>>>  - Possible code style changes due to the new v2 1/8.
>>>>
>>>>  .../fs/fat/fat.c                                   |   14
>>>>  +-------------
>>>>  1 file changed, 1 insertion(+), 13 deletions(-)
>>>
>>> Applied, thanks.
>>
>> OK, this change is NOT equivalent code.  My platforms now hang thusly
>> (with DEBUG set):
>> reading u-boot.img
>> VFAT Support enabled
>> FAT16, fat_sect: 4, fatlength: 144
>> Rootdir begins at cluster: 0, sector: 292, offset: 24800
>> Data begins at: 316
>> Sector size: 512, cluster size: 4
>> FAT read sect=292, clust_size=4, DIRENTSPERBLOCK=16
>> Rootvfatname: |u-boot.ais|
>> RootMismatch: |u-boot.ais|u-boot.ais|
>> RootMismatch: |u-boot.ais||
>> RootMismatch: |mlo||
>> Rootvfatname: |u-boot.img|
>> RootName: u-boot.img, start: 0xc2, size:  0x337d0
>> Filesize: 210896 bytes
>> 64 bytes
>> gc - clustnum: 194, startsect: 1092
>> Size: 210896, got: 64
>>
>> This is all fine in full U-Boot.
> 
> OK. I'm looking into it.
> 
> Can you give more details, like the type of storage (usb, mmc, etc.)? Do you
> have a command line and a disk image that could be used to duplicate the issue?

It's an SD card.  If you have any "OMAP" platform (beagleboard,
beaglebone, pandaboard) or am35x/am37x or similar platforms SPL should
hang like that.  72MB partition (or so) on either a 2 or 4GB card.
Getting all the way up into U-Boot clears the problem away until power
cycle.  That last part makes me worried...
Tom Rini - Sept. 4, 2012, 10:41 p.m.
On 09/04/2012 03:10 PM, Tom Rini wrote:
> On 09/04/2012 03:07 PM, Benoît Thébaudeau wrote:
>> Hi Tom,
>>
>> On Tuesday, September 4, 2012 10:50:34 PM, Tom Rini wrote:
>>> On Sun, Sep 02, 2012 at 05:25:20PM +0200, Wolfgang Denk wrote:
>>>> Dear Beno??t Th??baudeau,
>>>>
>>>> In message
>>>> <1663419836.332713.1342790497668.JavaMail.root@advansee.com> you
>>>> wrote:
>>>>> One call to get_cluster can be factorized with another, so avoid
>>>>> duplicatin> g
>>>>> code.
>>>>>
>>>>> Signed-off-by: Beno??t Th??baudeau
>>>>> <benoit.thebaudeau@advansee.com>
>>>>> Cc: Wolfgang Denk <wd@denx.de>
>>>>> ---
>>>>> Changes for v2:
>>>>>  - Patch renumbering because of the new v2 1/8.
>>>>>  - Possible code style changes due to the new v2 1/8.
>>>>>
>>>>>  .../fs/fat/fat.c                                   |   14
>>>>>  +-------------
>>>>>  1 file changed, 1 insertion(+), 13 deletions(-)
>>>>
>>>> Applied, thanks.
>>>
>>> OK, this change is NOT equivalent code.  My platforms now hang thusly
>>> (with DEBUG set):
>>> reading u-boot.img
>>> VFAT Support enabled
>>> FAT16, fat_sect: 4, fatlength: 144
>>> Rootdir begins at cluster: 0, sector: 292, offset: 24800
>>> Data begins at: 316
>>> Sector size: 512, cluster size: 4
>>> FAT read sect=292, clust_size=4, DIRENTSPERBLOCK=16
>>> Rootvfatname: |u-boot.ais|
>>> RootMismatch: |u-boot.ais|u-boot.ais|
>>> RootMismatch: |u-boot.ais||
>>> RootMismatch: |mlo||
>>> Rootvfatname: |u-boot.img|
>>> RootName: u-boot.img, start: 0xc2, size:  0x337d0
>>> Filesize: 210896 bytes
>>> 64 bytes
>>> gc - clustnum: 194, startsect: 1092
>>> Size: 210896, got: 64
>>>
>>> This is all fine in full U-Boot.
>>
>> OK. I'm looking into it.
>>
>> Can you give more details, like the type of storage (usb, mmc, etc.)? Do you
>> have a command line and a disk image that could be used to duplicate the issue?
> 
> It's an SD card.  If you have any "OMAP" platform (beagleboard,
> beaglebone, pandaboard) or am35x/am37x or similar platforms SPL should
> hang like that.  72MB partition (or so) on either a 2 or 4GB card.
> Getting all the way up into U-Boot clears the problem away until power
> cycle.  That last part makes me worried...

OK, this is somehow a 'me' problem it seems.  I don't see it on a
beagleboard and rebuilding things gives me a different failure now, so
something is up.  Digging more  now, sorry for the noise.
Benoît Thébaudeau - Sept. 4, 2012, 10:53 p.m.
On Wednesday, September 5, 2012 12:10:41 AM, Tom Rini wrote:
> On 09/04/2012 03:07 PM, Benoît Thébaudeau wrote:
> > On Tuesday, September 4, 2012 10:50:34 PM, Tom Rini wrote:
> >> On Sun, Sep 02, 2012 at 05:25:20PM +0200, Wolfgang Denk wrote:
> >>> Dear Beno??t Th??baudeau,
> >>>
> >>> In message
> >>> <1663419836.332713.1342790497668.JavaMail.root@advansee.com> you
> >>> wrote:
> >>>> One call to get_cluster can be factorized with another, so avoid
> >>>> duplicatin> g
> >>>> code.
> >>>>
> >>>> Signed-off-by: Beno??t Th??baudeau
> >>>> <benoit.thebaudeau@advansee.com>
> >>>> Cc: Wolfgang Denk <wd@denx.de>
> >>>> ---
> >>>> Changes for v2:
> >>>>  - Patch renumbering because of the new v2 1/8.
> >>>>  - Possible code style changes due to the new v2 1/8.
> >>>>
> >>>>  .../fs/fat/fat.c                                   |   14
> >>>>  +-------------
> >>>>  1 file changed, 1 insertion(+), 13 deletions(-)
> >>>
> >>> Applied, thanks.
> >>
> >> OK, this change is NOT equivalent code.  My platforms now hang
> >> thusly
> >> (with DEBUG set):
> >> reading u-boot.img
> >> VFAT Support enabled
> >> FAT16, fat_sect: 4, fatlength: 144
> >> Rootdir begins at cluster: 0, sector: 292, offset: 24800
> >> Data begins at: 316
> >> Sector size: 512, cluster size: 4
> >> FAT read sect=292, clust_size=4, DIRENTSPERBLOCK=16
> >> Rootvfatname: |u-boot.ais|
> >> RootMismatch: |u-boot.ais|u-boot.ais|
> >> RootMismatch: |u-boot.ais||
> >> RootMismatch: |mlo||
> >> Rootvfatname: |u-boot.img|
> >> RootName: u-boot.img, start: 0xc2, size:  0x337d0
> >> Filesize: 210896 bytes
> >> 64 bytes
> >> gc - clustnum: 194, startsect: 1092
> >> Size: 210896, got: 64
> >>
> >> This is all fine in full U-Boot.
> > 
> > OK. I'm looking into it.
> > 
> > Can you give more details, like the type of storage (usb, mmc,
> > etc.)? Do you
> > have a command line and a disk image that could be used to
> > duplicate the issue?
> 
> It's an SD card.  If you have any "OMAP" platform (beagleboard,
> beaglebone, pandaboard) or am35x/am37x or similar platforms SPL
> should
> hang like that.

Unfortunately, I don't have these platforms.

>  72MB partition (or so) on either a 2 or 4GB card.
> Getting all the way up into U-Boot clears the problem away until
> power
> cycle.  That last part makes me worried...

What do you mean by "Getting all the way up into U-Boot"? Is it that your SPL
can be aborted and give a command prompt?

The only difference that this specific patch (7/8) introduces in your use case
(i.e. a request to read the first 64 bytes of a file of 210896 bytes) is that it
removes a spurious call to get_cluster() with a size of 0, which should be
transparent.

Can you confirm that your tests bisect to this patch and not to another one in
this series?

Can you try to apply locally 5/8 and 8/8 to see if it makes a difference, just
in case there would be some dependencies?

Is it OK to send e-mails with attachments on the ML? If so, I can post the full
fat.c that I currently use so that you can test with it. I have used it for a
couple of years without any issue.

Also, why do you read only 64 bytes from this file? According to your debug
trace, this read was successful, and then no error is shown. So, if it hangs, it
might be that the read data is corrupted, or that the image is not fully read
because of this 64-byte limit.

Best regards,
Benoît
Tom Rini - Sept. 5, 2012, 12:03 a.m.
On 09/04/2012 03:53 PM, Benoît Thébaudeau wrote:
> On Wednesday, September 5, 2012 12:10:41 AM, Tom Rini wrote:
>> On 09/04/2012 03:07 PM, Benoît Thébaudeau wrote:
>>> On Tuesday, September 4, 2012 10:50:34 PM, Tom Rini wrote:
>>>> On Sun, Sep 02, 2012 at 05:25:20PM +0200, Wolfgang Denk wrote:
>>>>> Dear Beno??t Th??baudeau,
>>>>>
>>>>> In message
>>>>> <1663419836.332713.1342790497668.JavaMail.root@advansee.com> you
>>>>> wrote:
>>>>>> One call to get_cluster can be factorized with another, so avoid
>>>>>> duplicatin> g
>>>>>> code.
>>>>>>
>>>>>> Signed-off-by: Beno??t Th??baudeau
>>>>>> <benoit.thebaudeau@advansee.com>
>>>>>> Cc: Wolfgang Denk <wd@denx.de>
>>>>>> ---
>>>>>> Changes for v2:
>>>>>>  - Patch renumbering because of the new v2 1/8.
>>>>>>  - Possible code style changes due to the new v2 1/8.
>>>>>>
>>>>>>  .../fs/fat/fat.c                                   |   14
>>>>>>  +-------------
>>>>>>  1 file changed, 1 insertion(+), 13 deletions(-)
>>>>>
>>>>> Applied, thanks.
>>>>
>>>> OK, this change is NOT equivalent code.  My platforms now hang
>>>> thusly
>>>> (with DEBUG set):
>>>> reading u-boot.img
>>>> VFAT Support enabled
>>>> FAT16, fat_sect: 4, fatlength: 144
>>>> Rootdir begins at cluster: 0, sector: 292, offset: 24800
>>>> Data begins at: 316
>>>> Sector size: 512, cluster size: 4
>>>> FAT read sect=292, clust_size=4, DIRENTSPERBLOCK=16
>>>> Rootvfatname: |u-boot.ais|
>>>> RootMismatch: |u-boot.ais|u-boot.ais|
>>>> RootMismatch: |u-boot.ais||
>>>> RootMismatch: |mlo||
>>>> Rootvfatname: |u-boot.img|
>>>> RootName: u-boot.img, start: 0xc2, size:  0x337d0
>>>> Filesize: 210896 bytes
>>>> 64 bytes
>>>> gc - clustnum: 194, startsect: 1092
>>>> Size: 210896, got: 64
>>>>
>>>> This is all fine in full U-Boot.
>>>
>>> OK. I'm looking into it.
>>>
>>> Can you give more details, like the type of storage (usb, mmc,
>>> etc.)? Do you
>>> have a command line and a disk image that could be used to
>>> duplicate the issue?
>>
>> It's an SD card.  If you have any "OMAP" platform (beagleboard,
>> beaglebone, pandaboard) or am35x/am37x or similar platforms SPL
>> should
>> hang like that.
> 
> Unfortunately, I don't have these platforms.
> 
>>  72MB partition (or so) on either a 2 or 4GB card.
>> Getting all the way up into U-Boot clears the problem away until
>> power
>> cycle.  That last part makes me worried...
> 
> What do you mean by "Getting all the way up into U-Boot"? Is it that your SPL
> can be aborted and give a command prompt?
> 
> The only difference that this specific patch (7/8) introduces in your use case
> (i.e. a request to read the first 64 bytes of a file of 210896 bytes) is that it
> removes a spurious call to get_cluster() with a size of 0, which should be
> transparent.
> 
> Can you confirm that your tests bisect to this patch and not to another one in
> this series?
> 
> Can you try to apply locally 5/8 and 8/8 to see if it makes a difference, just
> in case there would be some dependencies?
> 
> Is it OK to send e-mails with attachments on the ML? If so, I can post the full
> fat.c that I currently use so that you can test with it. I have used it for a
> couple of years without any issue.
> 
> Also, why do you read only 64 bytes from this file? According to your debug
> trace, this read was successful, and then no error is shown. So, if it hangs, it
> might be that the read data is corrupted, or that the image is not fully read
> because of this 64-byte limit.

I've bisected this twice and I've come to a conclusion.  It is this
patch that makes my problem show up, but it's not this patch at fault.
What I'm going to go with is that the "am33xx: Remove redundant timer
config" patch that I forgot in my last round of pull requests needs to
come in as with that set of patches applied locally to top of tree the
platform is fine again.

Patch

diff --git u-boot-66714b1.orig/fs/fat/fat.c u-boot-66714b1/fs/fat/fat.c
index 101eb3a..19f6a8c 100644
--- u-boot-66714b1.orig/fs/fat/fat.c
+++ u-boot-66714b1/fs/fat/fat.c
@@ -367,21 +367,9 @@  get_contents(fsdata *mydata, dir_entry *dentptr, __u8 *buffer,
 			actsize += bytesperclust;
 		}
 
-		/* actsize >= file size */
-		actsize -= bytesperclust;
-
-		/* get remaining clusters */
-		if (get_cluster(mydata, curclust, buffer, (int)actsize) != 0) {
-			printf("Error reading cluster\n");
-			return -1;
-		}
-
 		/* get remaining bytes */
-		gotsize += (int)actsize;
-		filesize -= actsize;
-		buffer += actsize;
 		actsize = filesize;
-		if (get_cluster(mydata, endclust, buffer, (int)actsize) != 0) {
+		if (get_cluster(mydata, curclust, buffer, (int)actsize) != 0) {
 			printf("Error reading cluster\n");
 			return -1;
 		}