[U-Boot] [PATCH] ext2load: increase read speed

[U-Boot] [PATCH] ext2load: increase read speed

[Jason Cooper]

This patch dramatically drops the amount of time u-boot needs to read a
file from an ext2 partition.  On a typical 2 to 5 MB file (kernels and
initrds) it goes from tens of seconds to a couple seconds.

All we are doing here is grouping contiguous blocks into one read.

Boot tested on Globalscale Technologies Dreamplug (Kirkwood ARM SoC)
with three different files.  sha1sums were calculated in Linux
userspace, and then confirmed after ext2load.

Signed-off-by: Jason Cooper <u-boot@lakedaemon.net>
---
 fs/ext2/ext2fs.c |   26 ++++++++++++++++++++++++--
 1 files changed, 24 insertions(+), 2 deletions(-)

diff --git a/fs/ext2/ext2fs.c b/fs/ext2/ext2fs.c
index e119e13..8531db5 100644
--- a/fs/ext2/ext2fs.c
+++ b/fs/ext2/ext2fs.c
@@ -414,7 +414,6 @@ int ext2fs_read_file
 		if (blknr < 0) {
 			return (-1);
 		}
-		blknr = blknr << log2blocksize;
 
 		/* Last block.  */
 		if (i == blockcnt - 1) {
@@ -432,6 +431,29 @@ int ext2fs_read_file
 			blockend -= skipfirst;
 		}
 
+		/* grab middle blocks in one go */
+		if (i != pos / blocksize && i != blockcnt - 1 && blockcnt > 3) {
+			int oldblk = blknr;
+			int blocknxt;
+			while (i < blockcnt - 1) {
+				blocknxt = ext2fs_read_block(node, i + 1);
+				if (blocknxt == (oldblk + 1)) {
+					oldblk = blocknxt;
+					i++;
+				} else {
+					blocknxt = ext2fs_read_block(node, i);
+					break;
+				}
+			}
+
+			if (oldblk == blknr)
+				blockend = blocksize;
+			else
+				blockend = (1 + blocknxt - blknr) * blocksize;
+		}
+
+		blknr = blknr << log2blocksize;
+
 		/* If the block number is 0 this block is not stored on disk but
 		   is zero filled instead.  */
 		if (blknr) {
@@ -444,7 +466,7 @@ int ext2fs_read_file
 		} else {
 			memset (buf, 0, blocksize - skipfirst);
 		}
-		buf += blocksize - skipfirst;
+		buf += blockend - skipfirst;
 	}
 	return (len);
 }
-- 
1.7.3.4

[U-Boot] [PATCH] ext2load: increase read speed

[Eric Nelson]

On 03/28/2012 07:37 AM, Jason Cooper wrote:
> This patch dramatically drops the amount of time u-boot needs to read a
> file from an ext2 partition.  On a typical 2 to 5 MB file (kernels and
> initrds) it goes from tens of seconds to a couple seconds.
>
> All we are doing here is grouping contiguous blocks into one read.
>
> Boot tested on Globalscale Technologies Dreamplug (Kirkwood ARM SoC)
> with three different files.  sha1sums were calculated in Linux
> userspace, and then confirmed after ext2load.
>
> Signed-off-by: Jason Cooper<u-boot@lakedaemon.net>

Tested-by: Eric Nelson <eric.nelson@boundarydevices.com>

Tested on i.MX6 Sabre Lite board loading a file of ~900k:

Without patch:

	MX6QSABRELITE U-Boot > time ext2load sata 0:1 12000000 
/usr/lib/libperl.so.5.12.4 && crc32 12000000 $filesize
	Loading file "/usr/lib/libperl.so.5.12.4" from sata device 0:1 (hda1)
	958032 bytes read
	
	time: 0.414 seconds, 414 ticks
	CRC32 for 12000000 ... 120e9e4f ==> 550deec9
	
With patch:
	MX6QSABRELITE U-Boot > time ext2load sata 0:1 12000000 
/usr/lib/libperl.so.5.12.4 && crc32 12000000 $filesize
	Loading file "/usr/lib/libperl.so.5.12.4" from sata device 0:1 (hda1)
	958032 bytes read

	time: 0.205 seconds, 205 ticks
	CRC32 for 12000000 ... 120e9e4f ==> 550deec9

[U-Boot] [PATCH] ext2load: increase read speed

[Jason Cooper]

On Wed, Apr 25, 2012 at 06:17:48PM -0700, Eric Nelson wrote:
> On 03/28/2012 07:37 AM, Jason Cooper wrote:
> >This patch dramatically drops the amount of time u-boot needs to read a
> >file from an ext2 partition.  On a typical 2 to 5 MB file (kernels and
> >initrds) it goes from tens of seconds to a couple seconds.
> >
> >All we are doing here is grouping contiguous blocks into one read.
> >
> >Boot tested on Globalscale Technologies Dreamplug (Kirkwood ARM SoC)
> >with three different files.  sha1sums were calculated in Linux
> >userspace, and then confirmed after ext2load.
> >
> >Signed-off-by: Jason Cooper<u-boot@lakedaemon.net>
> 
> Tested-by: Eric Nelson <eric.nelson@boundarydevices.com>

Thanks for testing!  I've copied your results into the commit and will
be doing a pull request shortly.

thx,

Jason.

> 
> Tested on i.MX6 Sabre Lite board loading a file of ~900k:
> 
> Without patch:
> 
> 	MX6QSABRELITE U-Boot > time ext2load sata 0:1 12000000
> /usr/lib/libperl.so.5.12.4 && crc32 12000000 $filesize
> 	Loading file "/usr/lib/libperl.so.5.12.4" from sata device 0:1 (hda1)
> 	958032 bytes read
> 	
> 	time: 0.414 seconds, 414 ticks
> 	CRC32 for 12000000 ... 120e9e4f ==> 550deec9
> 	
> With patch:
> 	MX6QSABRELITE U-Boot > time ext2load sata 0:1 12000000
> /usr/lib/libperl.so.5.12.4 && crc32 12000000 $filesize
> 	Loading file "/usr/lib/libperl.so.5.12.4" from sata device 0:1 (hda1)
> 	958032 bytes read
> 
> 	time: 0.205 seconds, 205 ticks
> 	CRC32 for 12000000 ... 120e9e4f ==> 550deec9

[U-Boot] [PATCH] ext2load: increase read speed

[Eric Nelson]

Hi Jason,

On 05/08/2012 08:43 AM, Jason Cooper wrote:
> On Wed, Apr 25, 2012 at 06:17:48PM -0700, Eric Nelson wrote:
>> On 03/28/2012 07:37 AM, Jason Cooper wrote:
>>> This patch dramatically drops the amount of time u-boot needs to read a
>>> file from an ext2 partition.  On a typical 2 to 5 MB file (kernels and
>>> initrds) it goes from tens of seconds to a couple seconds.
>>>
>>> All we are doing here is grouping contiguous blocks into one read.
>>>
>>> Boot tested on Globalscale Technologies Dreamplug (Kirkwood ARM SoC)
>>> with three different files.  sha1sums were calculated in Linux
>>> userspace, and then confirmed after ext2load.
>>>
>>> Signed-off-by: Jason Cooper<u-boot@lakedaemon.net>
>>
>> Tested-by: Eric Nelson<eric.nelson@boundarydevices.com>
>
> Thanks for testing!  I've copied your results into the commit and will
> be doing a pull request shortly.
>

No problem.

Ironically, I'm working with an image this morning that loads the
kernel from ext2 and I keep thinking my board is locked up because
reads take so long.

Regards,


Eric

[U-Boot] [PATCH] ext2load: increase read speed

[Thierry Reding]

* Jason Cooper wrote:
> This patch dramatically drops the amount of time u-boot needs to read a
> file from an ext2 partition.  On a typical 2 to 5 MB file (kernels and
> initrds) it goes from tens of seconds to a couple seconds.
> 
> All we are doing here is grouping contiguous blocks into one read.
> 
> Boot tested on Globalscale Technologies Dreamplug (Kirkwood ARM SoC)
> with three different files.  sha1sums were calculated in Linux
> userspace, and then confirmed after ext2load.
> 
> Signed-off-by: Jason Cooper <u-boot@lakedaemon.net>

Before:

	Tegra2 (Medcom) # time ext2load mmc 0 0x17000000 /boot/uImage
	Loading file "/boot/uImage" from mmc device 0:1 (xxa1)
	5609104 bytes read

	time: 4.638 seconds, 4638 ticks
	Tegra2 (Medcom) # crc32 0x17000000 559690
	CRC32 for 17000000 ... 1755968f ==> 158788be

After:

	Tegra2 (Medcom) # time ext2load mmc 0 0x17000000 /boot/uImage
	Loading file "/boot/uImage" from mmc device 0:1 (xxa1)
	5609104 bytes read

	time: 0.317 seconds, 317 ticks
	Tegra2 (Medcom) # crc32 0x17000000 559690
	CRC32 for 17000000 ... 1755968f ==> 158788be

I can also successfully load the loaded uImage to a prompt, so:

Tested-by: Thierry Reding <thierry.reding@avionic-design.de>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120426/7e136327/attachment.pgp>

[U-Boot] [PATCH] ext2load: increase read speed

[Jason Cooper]

On Thu, Apr 26, 2012 at 02:54:51PM +0200, Thierry Reding wrote:
> * Jason Cooper wrote:
> > This patch dramatically drops the amount of time u-boot needs to read a
> > file from an ext2 partition.  On a typical 2 to 5 MB file (kernels and
> > initrds) it goes from tens of seconds to a couple seconds.
> > 
> > All we are doing here is grouping contiguous blocks into one read.
> > 
> > Boot tested on Globalscale Technologies Dreamplug (Kirkwood ARM SoC)
> > with three different files.  sha1sums were calculated in Linux
> > userspace, and then confirmed after ext2load.
> > 
> > Signed-off-by: Jason Cooper <u-boot@lakedaemon.net>
> 
> Before:
> 
> 	Tegra2 (Medcom) # time ext2load mmc 0 0x17000000 /boot/uImage
> 	Loading file "/boot/uImage" from mmc device 0:1 (xxa1)
> 	5609104 bytes read
> 
> 	time: 4.638 seconds, 4638 ticks
> 	Tegra2 (Medcom) # crc32 0x17000000 559690
> 	CRC32 for 17000000 ... 1755968f ==> 158788be
> 
> After:
> 
> 	Tegra2 (Medcom) # time ext2load mmc 0 0x17000000 /boot/uImage
> 	Loading file "/boot/uImage" from mmc device 0:1 (xxa1)
> 	5609104 bytes read
> 
> 	time: 0.317 seconds, 317 ticks
> 	Tegra2 (Medcom) # crc32 0x17000000 559690
> 	CRC32 for 17000000 ... 1755968f ==> 158788be
> 
> I can also successfully load the loaded uImage to a prompt, so:
> 
> Tested-by: Thierry Reding <thierry.reding@avionic-design.de>

Thanks for testing!  I've added your results to the commit message and
will be doing a pull request shortly.

thx,

Jason.

[U-Boot] [GIT PULL] ext2load speedup

[Jason Cooper]

The following changes since commit 415d386877df49eb051b85ef74fa59a16dc17c7d:

  Prepare v2012.04.01 (2012-04-25 15:22:50 +0200)

are available in the git repository at:
  git://git.infradead.org/users/jcooper/u-boot.git ext2load_speedup

Jason Cooper (1):
      ext2load: increase read speed

 fs/ext2/ext2fs.c |   26 ++++++++++++++++++++++++--
 1 files changed, 24 insertions(+), 2 deletions(-)

[U-Boot] [GIT PULL RESEND] ext2load speedup

[Jason Cooper]

Wolfgang,

I saw you were handling some pull requests and thought this might have
slipped through the cracks.  This patch sat on the list for quite a
while and has two independent testers reporting substantial success
(included in the commit).

To my knowledge, there is no fs maintainer...

thx,

Jason.

The following changes since commit 415d386877df49eb051b85ef74fa59a16dc17c7d:

  Prepare v2012.04.01 (2012-04-25 15:22:50 +0200)

are available in the git repository at:
  git://git.infradead.org/users/jcooper/u-boot.git ext2load_speedup

Jason Cooper (1):
      ext2load: increase read speed

 fs/ext2/ext2fs.c |   26 ++++++++++++++++++++++++--
 1 files changed, 24 insertions(+), 2 deletions(-)

[U-Boot] [GIT PULL RESEND] ext2load speedup

[Wolfgang Denk]

Dear Jason Cooper,

In message <20120521013540.GM24238@titan.lakedaemon.net> you wrote:
> 
> I saw you were handling some pull requests and thought this might have
> slipped through the cracks.  This patch sat on the list for quite a
> while and has two independent testers reporting substantial success
> (included in the commit).

I accept only pull requests from the U-Boot custodians, who in turn
accept only patches posted on the mailing list.

You wrote before that you had updated the commit message, so I am
still waiting for you to re-post your patch.  A pull request from some
external repository is not sufficient - we cannot easily review and
comment the code then, and it does not get logged in patchwork.

> To my knowledge, there is no fs maintainer...

True.  Stuff like this has to be handled by me, unless some other
maintainer picks it up through the staging tree.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
It is impractical for  the  standard  to  attempt  to  constrain  the
behavior  of code that does not obey the constraints of the standard.
                                                          - Doug Gwyn

[U-Boot] [GIT PULL RESEND] ext2load speedup

[Jason Cooper]

Wolfgang,

My apologies.  I pulled up the patchwork and saw that you had responded
to this email.  However, I never received it.  Time to go review my
procmailrc.  At any rate, I'll post v2 shortly as requested.

thx,

Jason.

On Sun, May 20, 2012 at 09:35:40PM -0400, Jason Cooper wrote:
> Wolfgang,
> 
> I saw you were handling some pull requests and thought this might have
> slipped through the cracks.  This patch sat on the list for quite a
> while and has two independent testers reporting substantial success
> (included in the commit).
> 
> To my knowledge, there is no fs maintainer...
> 
> thx,
> 
> Jason.
> 
> The following changes since commit 415d386877df49eb051b85ef74fa59a16dc17c7d:
> 
>   Prepare v2012.04.01 (2012-04-25 15:22:50 +0200)
> 
> are available in the git repository at:
>   git://git.infradead.org/users/jcooper/u-boot.git ext2load_speedup
> 
> Jason Cooper (1):
>       ext2load: increase read speed
> 
>  fs/ext2/ext2fs.c |   26 ++++++++++++++++++++++++--
>  1 files changed, 24 insertions(+), 2 deletions(-)
> 
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2] ext2load: increase read speed

[Jason Cooper]

This patch dramatically drops the amount of time u-boot needs to read a
file from an ext2 partition.  On a typical 2 to 5 MB file (kernels and
initrds) it goes from tens of seconds to a couple seconds.

All we are doing here is grouping contiguous blocks into one read.

Boot tested on Globalscale Technologies Dreamplug (Kirkwood ARM SoC)
with three different files.  sha1sums were calculated in Linux
userspace, and then confirmed after ext2load.

The following test results were provided by Eric Nelson:

Tested on i.MX6 Sabre Lite board loading a file of ~900k:

Without patch:

      MX6QSABRELITE U-Boot > time ext2load sata 0:1 12000000
/usr/lib/libperl.so.5.12.4 && crc32 12000000 $filesize
      Loading file "/usr/lib/libperl.so.5.12.4" from sata device 0:1
      (hda1)
      958032 bytes read

      time: 0.414 seconds, 414 ticks
      CRC32 for 12000000 ... 120e9e4f ==> 550deec9

With patch:
      MX6QSABRELITE U-Boot > time ext2load sata 0:1 12000000
/usr/lib/libperl.so.5.12.4 && crc32 12000000 $filesize
      Loading file "/usr/lib/libperl.so.5.12.4" from sata device 0:1
      (hda1)
      958032 bytes read

      time: 0.205 seconds, 205 ticks
      CRC32 for 12000000 ... 120e9e4f ==> 550deec9

And, the following results were reported by Thierry Reding:

Before:

      Tegra2 (Medcom) # time ext2load mmc 0 0x17000000 /boot/uImage
      Loading file "/boot/uImage" from mmc device 0:1 (xxa1)
      5609104 bytes read

      time: 4.638 seconds, 4638 ticks
      Tegra2 (Medcom) # crc32 0x17000000 559690
      CRC32 for 17000000 ... 1755968f ==> 158788be

After:

      Tegra2 (Medcom) # time ext2load mmc 0 0x17000000 /boot/uImage
      Loading file "/boot/uImage" from mmc device 0:1 (xxa1)
      5609104 bytes read

      time: 0.317 seconds, 317 ticks
      Tegra2 (Medcom) # crc32 0x17000000 559690
      CRC32 for 17000000 ... 1755968f ==> 158788be

I can also successfully load the loaded uImage to a prompt

End results.

Signed-off-by: Jason Cooper <u-boot@lakedaemon.net>
Tested-by: Eric Nelson <eric.nelson@boundarydevices.com>
Tested-by: Thierry Reding <thierry.reding@avionic-design.de>
---
Changes since v1:
  - updated commit entry to include test results from Eric Nelson and Thierry
    Reding

Based against tag 2012.04.01

 fs/ext2/ext2fs.c |   26 ++++++++++++++++++++++++--
 1 files changed, 24 insertions(+), 2 deletions(-)

diff --git a/fs/ext2/ext2fs.c b/fs/ext2/ext2fs.c
index f621741..f1fce48 100644
--- a/fs/ext2/ext2fs.c
+++ b/fs/ext2/ext2fs.c
@@ -420,7 +420,6 @@ int ext2fs_read_file
 		if (blknr < 0) {
 			return (-1);
 		}
-		blknr = blknr << log2blocksize;
 
 		/* Last block.  */
 		if (i == blockcnt - 1) {
@@ -438,6 +437,29 @@ int ext2fs_read_file
 			blockend -= skipfirst;
 		}
 
+		/* grab middle blocks in one go */
+		if (i != pos / blocksize && i != blockcnt - 1 && blockcnt > 3) {
+			int oldblk = blknr;
+			int blocknxt;
+			while (i < blockcnt - 1) {
+				blocknxt = ext2fs_read_block(node, i + 1);
+				if (blocknxt == (oldblk + 1)) {
+					oldblk = blocknxt;
+					i++;
+				} else {
+					blocknxt = ext2fs_read_block(node, i);
+					break;
+				}
+			}
+
+			if (oldblk == blknr)
+				blockend = blocksize;
+			else
+				blockend = (1 + blocknxt - blknr) * blocksize;
+		}
+
+		blknr = blknr << log2blocksize;
+
 		/* If the block number is 0 this block is not stored on disk but
 		   is zero filled instead.  */
 		if (blknr) {
@@ -450,7 +472,7 @@ int ext2fs_read_file
 		} else {
 			memset (buf, 0, blocksize - skipfirst);
 		}
-		buf += blocksize - skipfirst;
+		buf += blockend - skipfirst;
 	}
 	return (len);
 }
-- 
1.7.3.4

[U-Boot] [PATCH v2] ext2load: increase read speed

[Wolfgang Denk]

Dear Jason Cooper,

In message <1338566090-15008-1-git-send-email-u-boot@lakedaemon.net> you wrote:
> This patch dramatically drops the amount of time u-boot needs to read a
> file from an ext2 partition.  On a typical 2 to 5 MB file (kernels and
> initrds) it goes from tens of seconds to a couple seconds.
> 
> All we are doing here is grouping contiguous blocks into one read.
> 
> Boot tested on Globalscale Technologies Dreamplug (Kirkwood ARM SoC)
> with three different files.  sha1sums were calculated in Linux
> userspace, and then confirmed after ext2load.
> 
> The following test results were provided by Eric Nelson:
> 
> Tested on i.MX6 Sabre Lite board loading a file of ~900k:
> 
> Without patch:
> 
>       MX6QSABRELITE U-Boot > time ext2load sata 0:1 12000000
> /usr/lib/libperl.so.5.12.4 && crc32 12000000 $filesize
>       Loading file "/usr/lib/libperl.so.5.12.4" from sata device 0:1
>       (hda1)
>       958032 bytes read
> 
>       time: 0.414 seconds, 414 ticks
>       CRC32 for 12000000 ... 120e9e4f ==> 550deec9
> 
> With patch:
>       MX6QSABRELITE U-Boot > time ext2load sata 0:1 12000000
> /usr/lib/libperl.so.5.12.4 && crc32 12000000 $filesize
>       Loading file "/usr/lib/libperl.so.5.12.4" from sata device 0:1
>       (hda1)
>       958032 bytes read
> 
>       time: 0.205 seconds, 205 ticks
>       CRC32 for 12000000 ... 120e9e4f ==> 550deec9
> 
> And, the following results were reported by Thierry Reding:
> 
> Before:
> 
>       Tegra2 (Medcom) # time ext2load mmc 0 0x17000000 /boot/uImage
>       Loading file "/boot/uImage" from mmc device 0:1 (xxa1)
>       5609104 bytes read
> 
>       time: 4.638 seconds, 4638 ticks
>       Tegra2 (Medcom) # crc32 0x17000000 559690
>       CRC32 for 17000000 ... 1755968f ==> 158788be
> 
> After:
> 
>       Tegra2 (Medcom) # time ext2load mmc 0 0x17000000 /boot/uImage
>       Loading file "/boot/uImage" from mmc device 0:1 (xxa1)
>       5609104 bytes read
> 
>       time: 0.317 seconds, 317 ticks
>       Tegra2 (Medcom) # crc32 0x17000000 559690
>       CRC32 for 17000000 ... 1755968f ==> 158788be
> 
> I can also successfully load the loaded uImage to a prompt
> 
> End results.
> 
> Signed-off-by: Jason Cooper <u-boot@lakedaemon.net>
> Tested-by: Eric Nelson <eric.nelson@boundarydevices.com>
> Tested-by: Thierry Reding <thierry.reding@avionic-design.de>
> ---
> Changes since v1:
>   - updated commit entry to include test results from Eric Nelson and Thierry
>     Reding
> 
> Based against tag 2012.04.01
> 
>  fs/ext2/ext2fs.c |   26 ++++++++++++++++++++++++--
>  1 files changed, 24 insertions(+), 2 deletions(-)

Applied, thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
When it is incorrect, it is, at least *authoritatively* incorrect.
                                    - Hitchiker's Guide To The Galaxy

[U-Boot] [PATCH] ext2fs: fix warning: 'blocknxt' may be used uninitialized

[Kim Phillips]

ext2fs.c: In function 'ext2fs_read_file':
ext2fs.c:458:19: warning: 'blocknxt' may be used uninitialized in this function [-Wuninitialized]

Cc: Jason Cooper <u-boot@lakedaemon.net>
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
---
is this right?

 fs/ext2/ext2fs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/ext2/ext2fs.c b/fs/ext2/ext2fs.c
index f1fce48..c6c950e 100644
--- a/fs/ext2/ext2fs.c
+++ b/fs/ext2/ext2fs.c
@@ -440,7 +440,7 @@ int ext2fs_read_file
 		/* grab middle blocks in one go */
 		if (i != pos / blocksize && i != blockcnt - 1 && blockcnt > 3) {
 			int oldblk = blknr;
-			int blocknxt;
+			int blocknxt = 0;
 			while (i < blockcnt - 1) {
 				blocknxt = ext2fs_read_block(node, i + 1);
 				if (blocknxt == (oldblk + 1)) {
-- 
1.7.11.1

[U-Boot] [PATCH] ext2fs: fix warning: 'blocknxt' may be used uninitialized

[Andreas Bießmann]

Dear Kim Philips,

On 03.07.12 18:05, Kim Phillips wrote:
> ext2fs.c: In function 'ext2fs_read_file':
> ext2fs.c:458:19: warning: 'blocknxt' may be used uninitialized in this function [-Wuninitialized]
> 
> Cc: Jason Cooper <u-boot@lakedaemon.net>
> Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
> ---
> is this right?
> 
>  fs/ext2/ext2fs.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/fs/ext2/ext2fs.c b/fs/ext2/ext2fs.c
> index f1fce48..c6c950e 100644
> --- a/fs/ext2/ext2fs.c
> +++ b/fs/ext2/ext2fs.c
> @@ -440,7 +440,7 @@ int ext2fs_read_file
>  		/* grab middle blocks in one go */
>  		if (i != pos / blocksize && i != blockcnt - 1 && blockcnt > 3) {
>  			int oldblk = blknr;
> -			int blocknxt;
> +			int blocknxt = 0;
>  			while (i < blockcnt - 1) {
>  				blocknxt = ext2fs_read_block(node, i + 1);
>  				if (blocknxt == (oldblk + 1)) {
> 

there are two other solutions. I dunno which should we use but Thierry
Reding suggested another working one which I think its cleaner. Please
read http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/134043

Best regards

Andreas Bie?mann

[U-Boot] [PATCH v2] ext2fs: fix warning: 'blocknxt' may be used uninitialized

[Kim Phillips]

This warning was introduced in 436da3c "ext2load: increase read
speed":

ext2fs.c: In function 'ext2fs_read_file':
ext2fs.c:458:19: warning: 'blocknxt' may be used uninitialized in this function [-Wuninitialized]

this change makes it go away.

Cc: Eric Nelson <eric.nelson@boundarydevices.com>
Cc: Thierry Reding <thierry.reding@avionic-design.de>
Cc: Jason Cooper <u-boot@lakedaemon.net>
Cc: Andreas Bie?mann <andreas.devel@googlemail.com>
Cc: Reinhard Arlt <reinhard.arlt@esd-electronics.com>
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
---
v2: changed to Thierry's recommendation in:

http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/134043

build-tested only - please ack

 fs/ext2/ext2fs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/ext2/ext2fs.c b/fs/ext2/ext2fs.c
index f1fce48..182f0ac 100644
--- a/fs/ext2/ext2fs.c
+++ b/fs/ext2/ext2fs.c
@@ -438,7 +438,7 @@ int ext2fs_read_file
 		}
 
 		/* grab middle blocks in one go */
-		if (i != pos / blocksize && i != blockcnt - 1 && blockcnt > 3) {
+		if (i != pos / blocksize && i < blockcnt - 1 && blockcnt > 3) {
 			int oldblk = blknr;
 			int blocknxt;
 			while (i < blockcnt - 1) {
-- 
1.7.11.1

[U-Boot] [PATCH v2] ext2fs: fix warning: 'blocknxt' may be used uninitialized

[Thierry Reding]

On Tue, Jul 03, 2012 at 05:41:56PM -0500, Kim Phillips wrote:
> This warning was introduced in 436da3c "ext2load: increase read
> speed":
> 
> ext2fs.c: In function 'ext2fs_read_file':
> ext2fs.c:458:19: warning: 'blocknxt' may be used uninitialized in this function [-Wuninitialized]
> 
> this change makes it go away.
> 
> Cc: Eric Nelson <eric.nelson@boundarydevices.com>
> Cc: Thierry Reding <thierry.reding@avionic-design.de>
> Cc: Jason Cooper <u-boot@lakedaemon.net>
> Cc: Andreas Bie?mann <andreas.devel@googlemail.com>
> Cc: Reinhard Arlt <reinhard.arlt@esd-electronics.com>
> Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
> ---
> v2: changed to Thierry's recommendation in:
> 
> http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/134043
> 
> build-tested only - please ack

Tested on TEC, seems to behave the same as before:

Tested-by: Thierry Reding <thierry.reding@avionic-design.de>

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120704/8ba15969/attachment.pgp>

[U-Boot] [PATCH v2] ext2fs: fix warning: 'blocknxt' may be used uninitialized

[Jason Cooper]

On Tue, Jul 03, 2012 at 05:41:56PM -0500, Kim Phillips wrote:
> This warning was introduced in 436da3c "ext2load: increase read
> speed":
> 
> ext2fs.c: In function 'ext2fs_read_file':
> ext2fs.c:458:19: warning: 'blocknxt' may be used uninitialized in this function [-Wuninitialized]
> 
> this change makes it go away.
> 
> Cc: Eric Nelson <eric.nelson@boundarydevices.com>
> Cc: Thierry Reding <thierry.reding@avionic-design.de>
> Cc: Jason Cooper <u-boot@lakedaemon.net>
> Cc: Andreas Bie?mann <andreas.devel@googlemail.com>
> Cc: Reinhard Arlt <reinhard.arlt@esd-electronics.com>
> Signed-off-by: Kim Phillips <kim.phillips@freescale.com>

Acked-By: Jason Cooper <u-boot@lakedaemon.net>

thx,

Jason.

> ---
> v2: changed to Thierry's recommendation in:
> 
> http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/134043
> 
> build-tested only - please ack
> 
>  fs/ext2/ext2fs.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/fs/ext2/ext2fs.c b/fs/ext2/ext2fs.c
> index f1fce48..182f0ac 100644
> --- a/fs/ext2/ext2fs.c
> +++ b/fs/ext2/ext2fs.c
> @@ -438,7 +438,7 @@ int ext2fs_read_file
>  		}
>  
>  		/* grab middle blocks in one go */
> -		if (i != pos / blocksize && i != blockcnt - 1 && blockcnt > 3) {
> +		if (i != pos / blocksize && i < blockcnt - 1 && blockcnt > 3) {
>  			int oldblk = blknr;
>  			int blocknxt;
>  			while (i < blockcnt - 1) {
> -- 
> 1.7.11.1
> 
> 

[U-Boot] [PATCH v2] ext2fs: fix warning: 'blocknxt' may be used uninitialized

[Wolfgang Denk]

Dear Kim Phillips,

In message <20120703174156.a1082309c2b205216606a004@freescale.com> you wrote:
> This warning was introduced in 436da3c "ext2load: increase read
> speed":
> 
> ext2fs.c: In function 'ext2fs_read_file':
> ext2fs.c:458:19: warning: 'blocknxt' may be used uninitialized in this func=
> tion [-Wuninitialized]
> 
> this change makes it go away.
> 
> Cc: Eric Nelson <eric.nelson@boundarydevices.com>
> Cc: Thierry Reding <thierry.reding@avionic-design.de>
> Cc: Jason Cooper <u-boot@lakedaemon.net>
> Cc: Andreas Bie=DFmann <andreas.devel@googlemail.com>
> Cc: Reinhard Arlt <reinhard.arlt@esd-electronics.com>
> Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
> ---
> v2: changed to Thierry's recommendation in:
> 
> http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/134043
> 
> build-tested only - please ack
> 
>  fs/ext2/ext2fs.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Applied, thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
... not meant for the weak-at-heart: /^(?=.*one)(?=.*two)/
If you can follow that, you can use it.
          - Randal L. Schwartz in <ukpw67rhl3.fsf@julie.teleport.com>

[U-Boot] [PATCH v2] ext2fs: fix warning: 'blocknxt' may be used uninitialized

[Tom Rini]

On Sun, Jul 08, 2012 at 10:55:16PM +0200, Wolfgang Denk wrote:
> Dear Kim Phillips,
> 
> In message <20120703174156.a1082309c2b205216606a004@freescale.com> you wrote:
> > This warning was introduced in 436da3c "ext2load: increase read
> > speed":
> > 
> > ext2fs.c: In function 'ext2fs_read_file':
> > ext2fs.c:458:19: warning: 'blocknxt' may be used uninitialized in this func=
> > tion [-Wuninitialized]
> > 
> > this change makes it go away.
> > 
> > Cc: Eric Nelson <eric.nelson@boundarydevices.com>
> > Cc: Thierry Reding <thierry.reding@avionic-design.de>
> > Cc: Jason Cooper <u-boot@lakedaemon.net>
> > Cc: Andreas Bie=DFmann <andreas.devel@googlemail.com>
> > Cc: Reinhard Arlt <reinhard.arlt@esd-electronics.com>
> > Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
> > ---
> > v2: changed to Thierry's recommendation in:
> > 
> > http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/134043
> > 
> > build-tested only - please ack
> > 
> >  fs/ext2/ext2fs.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> Applied, thanks.

This doesn't fix the warning for ELDK 4.2 toolchains (gcc 4.2.2):
ext2fs.c: In function 'ext2fs_read_file':
ext2fs.c:443: warning: 'blocknxt' may be used uninitialized in this
function

-- 
Tom

[U-Boot] [PATCH v2] ext2fs: fix warning: 'blocknxt' may be used uninitialized

[Thierry Reding]

On Mon, Jul 23, 2012 at 11:56:00AM -0700, Tom Rini wrote:
> On Sun, Jul 08, 2012 at 10:55:16PM +0200, Wolfgang Denk wrote:
> > Dear Kim Phillips,
> > 
> > In message <20120703174156.a1082309c2b205216606a004@freescale.com> you wrote:
> > > This warning was introduced in 436da3c "ext2load: increase read
> > > speed":
> > > 
> > > ext2fs.c: In function 'ext2fs_read_file':
> > > ext2fs.c:458:19: warning: 'blocknxt' may be used uninitialized in this func=
> > > tion [-Wuninitialized]
> > > 
> > > this change makes it go away.
> > > 
> > > Cc: Eric Nelson <eric.nelson@boundarydevices.com>
> > > Cc: Thierry Reding <thierry.reding@avionic-design.de>
> > > Cc: Jason Cooper <u-boot@lakedaemon.net>
> > > Cc: Andreas Bie=DFmann <andreas.devel@googlemail.com>
> > > Cc: Reinhard Arlt <reinhard.arlt@esd-electronics.com>
> > > Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
> > > ---
> > > v2: changed to Thierry's recommendation in:
> > > 
> > > http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/134043
> > > 
> > > build-tested only - please ack
> > > 
> > >  fs/ext2/ext2fs.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > Applied, thanks.
> 
> This doesn't fix the warning for ELDK 4.2 toolchains (gcc 4.2.2):
> ext2fs.c: In function 'ext2fs_read_file':
> ext2fs.c:443: warning: 'blocknxt' may be used uninitialized in this
> function

I've seen older toolchains fail a lot at detecting situations like this.
I think starting with 4.5 things got a lot better.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120724/895638f5/attachment.pgp>