Strange CFI flash problem

U-Boot Matthias Weißer 3 participants 8 messages Apr 11, 2014 – Apr 15, 2014

Share & tools

Matthias Weißer

author

2014-04-11 09:54 UTC #0 lore raw

we are currently trying to get an out-of-tree board based on 2013.01 back in sync with current master and observing a strange behavior which we think is located in the CFI flash system. If we load an image via tftp, copy it to flash and then try to run the image via bootm we see an error while decomressing:

zmx25> tftpboot 0x81000000 zmx25-gfx.lzo.img;
Using FEC device
TFTP from server 192.168.1.60; our IP address is 192.168.1.107 Filename 'zmx25-gfx.lzo.img'.
Load address: 0x81000000
Loading:
#################################################################
#################################################################
#########################################
2.8 MiB/s
done
Bytes transferred = 2508249 (2645d9 hex)
zmx25> erase 0xA0080000 +${filesize}; .................... done
Erased 20 sectors
zmx25> cp.b 0x81000000 0xA0080000 ${filesize};
Copy to Flash... done
zmx25> bootm 0xA0080000;
## Booting kernel from Legacy Image at a0080000 ...

    Image Name:   zmx25-gfx ifs
    Image Type:   ARM QNX Kernel Image (lzo compressed)
    Data Size:    2508185 Bytes = 2.4 MiB

Load Address: 80000000
Entry Point: 80000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... LZO: uncompress or overwrite error -5
- must RESET board to recover
resetting ...

After the board is up and running again everything is fine when directly booting the image:

zmx25> bootm 0xa0080000
## Booting kernel from Legacy Image at a0080000 ...

    Image Name:   zmx25-gfx ifs
    Image Type:   ARM QNX Kernel Image (lzo compressed)
    Data Size:    2508185 Bytes = 2.4 MiB

Load Address: 80000000
Entry Point: 80000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Starting application at 0x80001cc0 ...

Doing an iminfo after the copy from RAM to flash (following the TFTP step) also fixes the problem. Or hides it. We tried with and without caches which didn't show any difference.

zmx25> flinfo

Bank # 1: CFI conformant flash (16 x 16) Size: 32 MB in 256 Sectors
AMD Standard command set, Manufacturer ID: 0x1C, Device ID: 0x227E2201 Erase timeout: 8192 ms, write timeout: 1 ms
Buffer write timeout: 1 ms, buffer size: 64 bytes

zmx25> bdinfo
arch_number = 0x00000C29
boot_params = 0x80000100

DRAM bank   = 0x00000000
-> start    = 0x80000000
-> size     = 0x03C00000
eth0name    = FEC
ethaddr     = 66:15:00:87:02:00
current eth = FEC
ip_addr     = 192.168.1.107
baudrate    = 115200 bps
TLB addr    = 0x83BF0000
relocaddr   = 0x83B6F000
reloc off   = 0xE3B6F000
irq_sp      = 0x83756F38
sp start    = 0x83756F28
FB base     = 0x00000000

Any ideas?

Matthias

Wolfgang Denk

2014-04-11 10:43 UTC #1 lore raw

Dear Matthias,

Quoted 6 lines · In message <[email protected]> you wrote:

we are currently trying to get an out-of-tree board based on 2013.01 back in sync with current master and observing a strange behavior which we think is located in the CFI flash system. If we load an image via tftp, copy it to flash and then try to run the image via bootm we see an error while decomressing:

...

Quoted 1 line

Uncompressing Kernel Image ... LZO: uncompress or overwrite error -5

Are you sure your malloc arena is big enough for LZO? Try if increasing it helps...

Best regards,

Wolfgang Denk

Signature · 7 lines

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
That Microsoft, the Trabant of the operating  system  world,  may  be
glancing  over the Berlin Wall at the Audis and BMWs and Mercedes. In
their own universe Trabants and Ladas were mainstream too...
                                                   -- Evan Leibovitch

Matthias Weißer

author

2014-04-14 06:09 UTC #2 lore raw

Hi Wolfgang

Am 11.04.2014 12:43, schrieb Wolfgang Denk:

Quoted 9 lines

Dear Matthias,
Quoted 6 lines · In message <[email protected]> you wrote:
we are currently trying to get an out-of-tree board based on 2013.01 back in sync with current master and observing a strange behavior which we think is located in the CFI flash system. If we load an image via tftp, copy it to flash and then try to run the image via bootm we see an error while decomressing:

Quoted 5 lines

...
Quoted 1 line
Uncompressing Kernel Image ... LZO: uncompress or overwrite error -5
Are you sure your malloc arena is big enough for LZO? Try if increasing it helps...

We increaded it from 4MB to 8MB and the behavior is still the same.

We also observed a different behavior when tftping the image to RAM and then directly executing it without copying it to flash. It seems that the flash device (EN29GL256H) is then in some a mode (maybe auto-select) which prevents it from normal read operations which doesn't allow the flash driver of the OS come up. We never saw this with our old u-boot. If there are no ideas left we will have to bisect the problem.

Regards
Matthias

Matthias Weißer

author Acked-by Simon Glass

2014-04-14 08:51 UTC #3 lore raw

Am 14.04.2014 08:09, schrieb Matthias Wei?er:

Quoted 18 lines

Hi Wolfgang
Am 11.04.2014 12:43, schrieb Wolfgang Denk:
Quoted 9 lines
Dear Matthias,
Quoted 6 lines · In message <[email protected]> you wrote:
we are currently trying to get an out-of-tree board based on 2013.01 back in sync with current master and observing a strange behavior which we think is located in the CFI flash system. If we load an image via tftp, copy it to flash and then try to run the image via bootm we see an error while decomressing:
Quoted 5 lines
...
Quoted 1 line
Uncompressing Kernel Image ... LZO: uncompress or overwrite error -5
Are you sure your malloc arena is big enough for LZO? Try if increasing it helps...

Quoted 8 lines

We increaded it from 4MB to 8MB and the behavior is still the same.
We also observed a different behavior when tftping the image to RAM and then directly executing it without copying it to flash. It seems that the flash device (EN29GL256H) is then in some a mode (maybe auto-select) which prevents it from normal read operations which doesn't allow the flash driver of the OS come up. We never saw this with our old u-boot. If there are no ideas left we will have to bisect the problem.

Bisecting was successfull. The commit introducing the problem is

commit ff9d2efdbf1b3b5263f81e843c6724b8bead7f1f

Author: Kees Cook <[email protected]>
Date:   Fri Aug 16 07:59:15 2013 -0700

lzo: correctly bounds-check output buffer

This checks the size of the output buffer and fails if it was going to overflow the buffer during lzo decompression.

Signed-off-by Kees Cook <[email protected]>

Acked-by Simon Glass <[email protected]>

This commit introduced the usage of the dst_len output parameter as additional input parameter containing the maximum output buffer size. This parameter isn't initialized in cmd_bootm.c:

  454 #ifdef CONFIG_LZO
  455     case IH_COMP_LZO: {
  456         size_t size;
  457
  458         printf("   Uncompressing %s ... ", type_name);
  459
  460         ret = lzop_decompress(image_buf, image_len, load_buf, &size);

Setting size to some big value (SZE_MAX is not avialable) fixed the behavior but I am unsure if this is the correct solution. I think its hard to get the max output buffer size at this point in cmd_bootm.c.

Regards
Matthias

Kees Cook

2014-04-14 15:38 UTC #4 lore raw

Quoted 62 lines · Matthias Wei?er

Am 14.04.2014 08:09, schrieb Matthias Wei?er:
Quoted 24 lines
Hi Wolfgang
Am 11.04.2014 12:43, schrieb Wolfgang Denk:
Quoted 12 lines
Dear Matthias,
Quoted 7 lines · In message <[email protected]> you wrote:
we are currently trying to get an out-of-tree board based on 2013.01 back in sync with current master and observing a strange behavior which we think is located in the CFI flash system. If we load an image via tftp, copy it to flash and then try to run the image via bootm we see an error while decomressing:
Quoted 7 lines
...
Quoted 2 lines
Uncompressing Kernel Image ... LZO: uncompress or overwrite error -5
Are you sure your malloc arena is big enough for LZO? Try if increasing it helps...
Quoted 8 lines
We increaded it from 4MB to 8MB and the behavior is still the same.
We also observed a different behavior when tftping the image to RAM and then directly executing it without copying it to flash. It seems that the flash device (EN29GL256H) is then in some a mode (maybe auto-select) which prevents it from normal read operations which doesn't allow the flash driver of the OS come up. We never saw this with our old u-boot. If there are no ideas left we will have to bisect the problem.
Bisecting was successfull. The commit introducing the problem is
commit ff9d2efdbf1b3b5263f81e843c6724b8bead7f1f
Author: Kees Cook <[email protected]>
Date:   Fri Aug 16 07:59:15 2013 -0700
lzo: correctly bounds-check output buffer
This checks the size of the output buffer and fails if it was going to overflow the buffer during lzo decompression.
Signed-off-by Kees Cook <[email protected]>
Acked-by Simon Glass <[email protected]>
This commit introduced the usage of the dst_len output parameter as additional input parameter containing the maximum output buffer size. This parameter isn't initialized in cmd_bootm.c:
454 #ifdef CONFIG_LZO
455 case IH_COMP_LZO: {
456 size_t size;
457
458 printf(" Uncompressing %s ... ", type_name);
459
460 ret = lzop_decompress(image_buf, image_len, load_buf, &size);

Quoted 3 lines

Setting size to some big value (SZE_MAX is not avialable) fixed the behavior but I am unsure if this is the correct solution. I think its hard to get the max output buffer size at this point in cmd_bootm.c.

Does this work?

---
From: Kees Cook <[email protected]>
Subject: [PATCH] bootm: set max output for LZO

The LZO decompressor wasn't initializing the maximum output size.

Reported-by Matthias Wei?er <[email protected]>

Signed-off-by Kees Cook <[email protected]>

---
 common/cmd_bootm.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

common/cmd_bootm.c +0 -0

index 9751edc..c243a5b 100644
@@ -453,7 +453,7 @@ static int bootm_load_os(bootm_headers_t *images,

unsigned long *load_end,
#endif /* CONFIG_LZMA */

 #ifdef CONFIG_LZO
        case IH_COMP_LZO: {

- size_t size;
+ size_t size = unc_len;

                printf("   Uncompressing %s ... ", type_name);

Signature · 7 lines

1.7.9.5



-- 
Kees Cook
Chrome OS Security

Matthias Weißer

author Tested-by

2014-04-15 05:48 UTC #5 lore raw

Am 14.04.2014 17:38, schrieb Kees Cook:

Quoted 63 lines · Matthias Wei?er

Quoted 62 lines
Am 14.04.2014 08:09, schrieb Matthias Wei?er:
Quoted 24 lines
Hi Wolfgang
Am 11.04.2014 12:43, schrieb Wolfgang Denk:
Quoted 12 lines
Dear Matthias,
Quoted 7 lines · In message <[email protected]> you wrote:
we are currently trying to get an out-of-tree board based on 2013.01 back in sync with current master and observing a strange behavior which we think is located in the CFI flash system. If we load an image via tftp, copy it to flash and then try to run the image via bootm we see an error while decomressing:
Quoted 7 lines
...
Quoted 2 lines
Uncompressing Kernel Image ... LZO: uncompress or overwrite error -5
Are you sure your malloc arena is big enough for LZO? Try if increasing it helps...
Quoted 8 lines
We increaded it from 4MB to 8MB and the behavior is still the same.
We also observed a different behavior when tftping the image to RAM and then directly executing it without copying it to flash. It seems that the flash device (EN29GL256H) is then in some a mode (maybe auto-select) which prevents it from normal read operations which doesn't allow the flash driver of the OS come up. We never saw this with our old u-boot. If there are no ideas left we will have to bisect the problem.
Bisecting was successfull. The commit introducing the problem is
commit ff9d2efdbf1b3b5263f81e843c6724b8bead7f1f
Author: Kees Cook <[email protected]>
Date:   Fri Aug 16 07:59:15 2013 -0700
lzo: correctly bounds-check output buffer
This checks the size of the output buffer and fails if it was going to overflow the buffer during lzo decompression.
Signed-off-by Kees Cook <[email protected]>
Acked-by Simon Glass <[email protected]>
This commit introduced the usage of the dst_len output parameter as additional input parameter containing the maximum output buffer size. This parameter isn't initialized in cmd_bootm.c:
454 #ifdef CONFIG_LZO
455 case IH_COMP_LZO: {
456 size_t size;
457
458 printf(" Uncompressing %s ... ", type_name);
459
460 ret = lzop_decompress(image_buf, image_len, load_buf, &size);

Quoted 5 lines

Quoted 3 lines
Setting size to some big value (SZE_MAX is not avialable) fixed the behavior but I am unsure if this is the correct solution. I think its hard to get the max output buffer size at this point in cmd_bootm.c.
Does this work?

Yes. Didn't saw that configuration option. Thanks.

Quoted 18 lines

---
From: Kees Cook <[email protected]>
Subject: [PATCH] bootm: set max output for LZO
The LZO decompressor wasn't initializing the maximum output size.
Reported-by Matthias Wei?er <[email protected]>
Signed-off-by Kees Cook <[email protected]>
---
  common/cmd_bootm.c |    2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
common/cmd_bootm.c +0 -0
index 9751edc..c243a5b 100644

common/cmd_bootm.c static int bootm_load_os(bootm_headers_t *images, · line 459

Quoted 8 lines

common/cmd_bootm.c +1 -1

@@ -453,7 +453,7 @@ static int bootm_load_os(bootm_headers_t *images,
 unsigned long *load_end,
  #endif /* CONFIG_LZMA */
  #ifdef CONFIG_LZO
         case IH_COMP_LZO: {
-               size_t size;
+               size_t size = unc_len;
 
                 printf("   Uncompressing %s ... ", type_name);

Tested-by Matthias Wei?er <[email protected]>

Regards
Matthias

Kees Cook

2014-04-15 17:27 UTC #6 lore raw

Quoted 117 lines · Matthias Wei?er

Am 14.04.2014 17:38, schrieb Kees Cook:
Quoted 78 lines
Quoted 76 lines · Matthias Wei?er
Am 14.04.2014 08:09, schrieb Matthias Wei?er:
Quoted 33 lines
Hi Wolfgang
Am 11.04.2014 12:43, schrieb Wolfgang Denk:
Quoted 20 lines
Dear Matthias,
Quoted 10 lines · In message <[email protected]> you wrote:
we are currently trying to get an out-of-tree board based on 2013.01 back in sync with current master and observing a strange behavior which
we think is located in the CFI flash system. If we load an image via tftp, copy it to flash and then try to run the image via bootm we see an
error while decomressing:
...
Quoted 2 lines
Quoted 7 lines
Quoted 2 lines
Uncompressing Kernel Image ... LZO: uncompress or overwrite error
-5
Are you sure your malloc arena is big enough for LZO? Try if increasing it helps...
Quoted 8 lines
We increaded it from 4MB to 8MB and the behavior is still the same.
We also observed a different behavior when tftping the image to RAM and then directly executing it without copying it to flash. It seems that the flash device (EN29GL256H) is then in some a mode (maybe auto-select) which prevents it from normal read operations which doesn't allow the flash driver of the OS come up. We never saw this with our old u-boot. If there are no ideas left we will have to bisect the problem.
Bisecting was successfull. The commit introducing the problem is
commit ff9d2efdbf1b3b5263f81e843c6724b8bead7f1f
Author: Kees Cook <[email protected]>
Date:   Fri Aug 16 07:59:15 2013 -0700
lzo: correctly bounds-check output buffer
This checks the size of the output buffer and fails if it was going
to
overflow the buffer during lzo decompression.
Signed-off-by Kees Cook <[email protected]>
Acked-by Simon Glass <[email protected]>
This commit introduced the usage of the dst_len output parameter as additional input parameter containing the maximum output buffer size. This
parameter isn't initialized in cmd_bootm.c:
454 #ifdef CONFIG_LZO
455 case IH_COMP_LZO: {
456 size_t size;
457
458 printf(" Uncompressing %s ... ", type_name);
459
460 ret = lzop_decompress(image_buf, image_len, load_buf,
&size);
Quoted 8 lines
Quoted 5 lines
Setting size to some big value (SZE_MAX is not avialable) fixed the behavior
but I am unsure if this is the correct solution. I think its hard to get the
max output buffer size at this point in cmd_bootm.c.
Does this work?
Yes. Didn't saw that configuration option. Thanks.
Quoted 24 lines
---
From: Kees Cook <[email protected]>
Subject: [PATCH] bootm: set max output for LZO
The LZO decompressor wasn't initializing the maximum output size.
Reported-by Matthias Wei?er <[email protected]>
Signed-off-by Kees Cook <[email protected]>
---
  common/cmd_bootm.c |    2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
common/cmd_bootm.c +1 -1
index 9751edc..c243a5b 100644
@@ -453,7 +453,7 @@ static int bootm_load_os(bootm_headers_t *images,
 unsigned long *load_end,
  #endif /* CONFIG_LZMA */
  #ifdef CONFIG_LZO
         case IH_COMP_LZO: {
-               size_t size;
+               size_t size = unc_len;
 

Quoted 4 lines

common/cmd_bootm.c static int bootm_load_os(bootm_headers_t *images, · line 459
Quoted 2 lines
common/cmd_bootm.c +0 -0
                 printf("   Uncompressing %s ... ", type_name);
Tested-by Matthias Wei?er <[email protected]>

Great! Thanks for testing.

Who can commit this patch? LZO is pretty busted at the moment without it. :)

-Kees

Signature · 2 lines

Kees Cook
Chrome OS Security

Kees Cook

2014-04-15 17:29 UTC #7 lore raw

Quoted 118 lines · Kees Cook

Quoted 117 lines · Matthias Wei?er
Am 14.04.2014 17:38, schrieb Kees Cook:
Quoted 78 lines
Quoted 76 lines · Matthias Wei?er
Am 14.04.2014 08:09, schrieb Matthias Wei?er:
Quoted 33 lines
Hi Wolfgang
Am 11.04.2014 12:43, schrieb Wolfgang Denk:
Quoted 20 lines
Dear Matthias,
Quoted 10 lines · In message <[email protected]> you wrote:
we are currently trying to get an out-of-tree board based on 2013.01 back in sync with current master and observing a strange behavior which
we think is located in the CFI flash system. If we load an image via tftp, copy it to flash and then try to run the image via bootm we see an
error while decomressing:
...
Quoted 2 lines
Quoted 7 lines
Quoted 2 lines
Uncompressing Kernel Image ... LZO: uncompress or overwrite error
-5
Are you sure your malloc arena is big enough for LZO? Try if increasing it helps...
Quoted 8 lines
We increaded it from 4MB to 8MB and the behavior is still the same.
We also observed a different behavior when tftping the image to RAM and then directly executing it without copying it to flash. It seems that the flash device (EN29GL256H) is then in some a mode (maybe auto-select) which prevents it from normal read operations which doesn't allow the flash driver of the OS come up. We never saw this with our old u-boot. If there are no ideas left we will have to bisect the problem.
Bisecting was successfull. The commit introducing the problem is
commit ff9d2efdbf1b3b5263f81e843c6724b8bead7f1f
Author: Kees Cook <[email protected]>
Date:   Fri Aug 16 07:59:15 2013 -0700
lzo: correctly bounds-check output buffer
This checks the size of the output buffer and fails if it was going
to
overflow the buffer during lzo decompression.
Signed-off-by Kees Cook <[email protected]>
Acked-by Simon Glass <[email protected]>
This commit introduced the usage of the dst_len output parameter as additional input parameter containing the maximum output buffer size. This
parameter isn't initialized in cmd_bootm.c:
454 #ifdef CONFIG_LZO
455 case IH_COMP_LZO: {
456 size_t size;
457
458 printf(" Uncompressing %s ... ", type_name);
459
460 ret = lzop_decompress(image_buf, image_len, load_buf,
&size);
Quoted 8 lines
Quoted 5 lines
Setting size to some big value (SZE_MAX is not avialable) fixed the behavior
but I am unsure if this is the correct solution. I think its hard to get the
max output buffer size at this point in cmd_bootm.c.
Does this work?
Yes. Didn't saw that configuration option. Thanks.
Quoted 24 lines
---
From: Kees Cook <[email protected]>
Subject: [PATCH] bootm: set max output for LZO
The LZO decompressor wasn't initializing the maximum output size.
Reported-by Matthias Wei?er <[email protected]>
Signed-off-by Kees Cook <[email protected]>
---
  common/cmd_bootm.c |    2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
common/cmd_bootm.c +1 -1
index 9751edc..c243a5b 100644
@@ -453,7 +453,7 @@ static int bootm_load_os(bootm_headers_t *images,
 unsigned long *load_end,
  #endif /* CONFIG_LZMA */
  #ifdef CONFIG_LZO
         case IH_COMP_LZO: {
-               size_t size;
+               size_t size = unc_len;
 

Quoted 8 lines

Quoted 4 lines
common/cmd_bootm.c static int bootm_load_os(bootm_headers_t *images, · line 459
Quoted 2 lines
common/cmd_bootm.c +0 -0
                 printf("   Uncompressing %s ... ", type_name);
Tested-by Matthias Wei?er <[email protected]>
Great! Thanks for testing.
Who can commit this patch? LZO is pretty busted at the moment without it. :)

Actually, since this is on -users, I'll resend the patch to the devel list...

Thanks!

-Kees

Signature · 2 lines

Kees Cook
Chrome OS Security