Hi
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
Dear Matthias,
In message 5347BBBC.9000806@arcor.de 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:
...
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
Hi Wolfgang
Am 11.04.2014 12:43, schrieb Wolfgang Denk:
Dear Matthias,
In message 5347BBBC.9000806@arcor.de 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:
...
Uncompressing Kernel Image ... LZO: uncompress or overwrite error -5Are 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
Am 14.04.2014 08:09, schrieb Matthias Weißer:
Hi Wolfgang
Am 11.04.2014 12:43, schrieb Wolfgang Denk:
Dear Matthias,
In message 5347BBBC.9000806@arcor.de 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:
...
Uncompressing Kernel Image ... LZO: uncompress or overwrite error -5Are 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.
Bisecting was successfull. The commit introducing the problem is
commit ff9d2efdbf1b3b5263f81e843c6724b8bead7f1f Author: Kees Cook keescook@chromium.org 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 keescook@chromium.org Acked-by: Simon Glass sjg@chromium.org
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
On Mon, Apr 14, 2014 at 1:51 AM, Matthias Weißer weisserm@arcor.de wrote:
Am 14.04.2014 08:09, schrieb Matthias Weißer:
Hi Wolfgang
Am 11.04.2014 12:43, schrieb Wolfgang Denk:
Dear Matthias,
In message 5347BBBC.9000806@arcor.de 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:
...
Uncompressing Kernel Image ... LZO: uncompress or overwrite error -5Are 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.
Bisecting was successfull. The commit introducing the problem is
commit ff9d2efdbf1b3b5263f81e843c6724b8bead7f1f Author: Kees Cook keescook@chromium.org 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 <keescook@chromium.org> Acked-by: Simon Glass <sjg@chromium.org>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.
Does this work?
--- From: Kees Cook keescook@chromium.org Subject: [PATCH] bootm: set max output for LZO
The LZO decompressor wasn't initializing the maximum output size.
Reported-by: Matthias Weißer weisserm@arcor.de Signed-off-by: Kees Cook keescook@chromium.org --- common/cmd_bootm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c index 9751edc..c243a5b 100644 --- a/common/cmd_bootm.c +++ b/common/cmd_bootm.c @@ -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);
Am 14.04.2014 17:38, schrieb Kees Cook:
On Mon, Apr 14, 2014 at 1:51 AM, Matthias Weißer weisserm@arcor.de wrote:
Am 14.04.2014 08:09, schrieb Matthias Weißer:
Hi Wolfgang
Am 11.04.2014 12:43, schrieb Wolfgang Denk:
Dear Matthias,
In message 5347BBBC.9000806@arcor.de 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:
...
Uncompressing Kernel Image ... LZO: uncompress or overwrite error -5Are 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.
Bisecting was successfull. The commit introducing the problem is
commit ff9d2efdbf1b3b5263f81e843c6724b8bead7f1f Author: Kees Cook keescook@chromium.org 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 <keescook@chromium.org> Acked-by: Simon Glass <sjg@chromium.org>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.
Does this work?
Yes. Didn't saw that configuration option. Thanks.
From: Kees Cook keescook@chromium.org Subject: [PATCH] bootm: set max output for LZO
The LZO decompressor wasn't initializing the maximum output size.
Reported-by: Matthias Weißer weisserm@arcor.de Signed-off-by: Kees Cook keescook@chromium.org
common/cmd_bootm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c index 9751edc..c243a5b 100644 --- a/common/cmd_bootm.c +++ b/common/cmd_bootm.c @@ -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 weisserm@arcor.de
Regards Matthias
On Mon, Apr 14, 2014 at 10:48 PM, Matthias Weißer weisserm@arcor.de wrote:
Am 14.04.2014 17:38, schrieb Kees Cook:
On Mon, Apr 14, 2014 at 1:51 AM, Matthias Weißer weisserm@arcor.de wrote:
Am 14.04.2014 08:09, schrieb Matthias Weißer:
Hi Wolfgang
Am 11.04.2014 12:43, schrieb Wolfgang Denk:
Dear Matthias,
In message 5347BBBC.9000806@arcor.de 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:
...
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.
Bisecting was successfull. The commit introducing the problem is
commit ff9d2efdbf1b3b5263f81e843c6724b8bead7f1f Author: Kees Cook keescook@chromium.org 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 goingto overflow the buffer during lzo decompression.
Signed-off-by: Kees Cook <keescook@chromium.org> Acked-by: Simon Glass <sjg@chromium.org>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.
Does this work?
Yes. Didn't saw that configuration option. Thanks.
From: Kees Cook keescook@chromium.org Subject: [PATCH] bootm: set max output for LZO
The LZO decompressor wasn't initializing the maximum output size.
Reported-by: Matthias Weißer weisserm@arcor.de Signed-off-by: Kees Cook keescook@chromium.org
common/cmd_bootm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c index 9751edc..c243a5b 100644 --- a/common/cmd_bootm.c +++ b/common/cmd_bootm.c @@ -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 weisserm@arcor.de
Great! Thanks for testing.
Who can commit this patch? LZO is pretty busted at the moment without it. :)
-Kees
On Tue, Apr 15, 2014 at 10:27 AM, Kees Cook keescook@chromium.org wrote:
On Mon, Apr 14, 2014 at 10:48 PM, Matthias Weißer weisserm@arcor.de wrote:
Am 14.04.2014 17:38, schrieb Kees Cook:
On Mon, Apr 14, 2014 at 1:51 AM, Matthias Weißer weisserm@arcor.de wrote:
Am 14.04.2014 08:09, schrieb Matthias Weißer:
Hi Wolfgang
Am 11.04.2014 12:43, schrieb Wolfgang Denk:
Dear Matthias,
In message 5347BBBC.9000806@arcor.de 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:
... > > > 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.
Bisecting was successfull. The commit introducing the problem is
commit ff9d2efdbf1b3b5263f81e843c6724b8bead7f1f Author: Kees Cook keescook@chromium.org 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 goingto overflow the buffer during lzo decompression.
Signed-off-by: Kees Cook <keescook@chromium.org> Acked-by: Simon Glass <sjg@chromium.org>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.
Does this work?
Yes. Didn't saw that configuration option. Thanks.
From: Kees Cook keescook@chromium.org Subject: [PATCH] bootm: set max output for LZO
The LZO decompressor wasn't initializing the maximum output size.
Reported-by: Matthias Weißer weisserm@arcor.de Signed-off-by: Kees Cook keescook@chromium.org
common/cmd_bootm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c index 9751edc..c243a5b 100644 --- a/common/cmd_bootm.c +++ b/common/cmd_bootm.c @@ -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 weisserm@arcor.de
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
participants (3)
-
Kees Cook -
Matthias Weißer -
Wolfgang Denk