[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