From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?ISO-8859-1?Q?Matthias_Wei=DFer?= Date: Mon, 14 Apr 2014 10:51:23 +0200 Subject: [U-Boot] Strange CFI flash problem In-Reply-To: <534B7BA4.8070100@arcor.de> References: <5347BBBC.9000806@arcor.de> <20140411104350.BA22938042D@gemini.denx.de> <534B7BA4.8070100@arcor.de> Message-ID: <534BA18B.5050509@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 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. Regards Matthias