[U-Boot] [PATCH] cmd_bmp: fix very long uncompressing time of gzipped bitmaps

Mike Frysinger vapier at gentoo.org
Wed Jul 20 05:36:32 CEST 2011


On Tuesday, July 19, 2011 08:12:43 Anatolij Gustschin wrote:
> If a compressed bitmap is located in sectors at the end of the
> flash and it's offset + CONFIG_SYS_VIDEO_LOGO_MAX_SIZE > 0xFFFFFFFF,
> the uncompressing time is very long, since processing the
> stream is done bytewise (and not blockwise) due to overflow
> in inflate_fast() while calculation and checking for enough
> input available.
> 
> Fix available bitmap data input size for gunzip() to match
> the actually available data size to prevent the observed
> misbehaviour.

this doesnt sound right.  the flash region should have no relevance at all to 
the bmp funcs (and the current ones dont check it at all).  also, i'm not sure 
your code currently handles multiple flashes as bi_flashstart really is only 
good for flash_info[0].

if there's an overflow happening, then the overflow should be detected 
generically and handled without any knowledge at all of flashes.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20110719/42f0fd67/attachment.pgp 


More information about the U-Boot mailing list