From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?B?TWF0dGhpYXMgV2Vpw59lcg==?= Date: Tue, 15 Apr 2014 07:48:15 +0200 Subject: [U-Boot] Strange CFI flash problem In-Reply-To: References: <5347BBBC.9000806@arcor.de> <20140411104350.BA22938042D@gemini.denx.de> <534B7BA4.8070100@arcor.de> <534BA18B.5050509@arcor.de> Message-ID: <534CC81F.5030606@arcor.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Am 14.04.2014 17:38, schrieb Kees Cook: > On Mon, Apr 14, 2014 at 1:51 AM, Matthias Wei?er 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 >> 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 >> Acked-by: Simon Glass >> >> 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 > Subject: [PATCH] bootm: set max output for LZO > > The LZO decompressor wasn't initializing the maximum output size. > > Reported-by: Matthias Wei?er > Signed-off-by: Kees Cook > --- > 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 Regards Matthias