[U-Boot-Users] max gunzip output buffer size in do_bootm()

Hi,
I ran into trouble when booting huge compressed images via bootm. do_bootm uses a fixed maximum size for the uncompressed data of 0x400000 bytes. That's not enough for our images (about uncompressed 9MB VxWorks image).
Is there any reason for the 4MB limiting? I'd like to post a patch that fixes this issue:
a) just increase the unc_len variable to e.g. 16MB b) add a define with default to board config file (CONFIG_MAX_BOOTM_UNC_LEN). When not defined in config file, 0x400000 is used c) set unc_len to mem size :-) So user must know what he is doing.
What do you like best?
BTW: When the uncompressed data is more than the unc_len limit no error is reported. The uncompressed data is just truncated leading to corrupted uncompressed data. Should that be fixed, too?
Regards Matthias

In message 43D655B2.6070204@esd-electronics.com you wrote:
I ran into trouble when booting huge compressed images via bootm. do_bootm uses a fixed maximum size for the uncompressed data of 0x400000 bytes. That's not enough for our images (about uncompressed 9MB VxWorks image).
That's a built-in reminder that the time has come to port your applications to Linux :-)
Is there any reason for the 4MB limiting? I'd like to post a patch that
As usual: hysteric reasons. There was a time when nobody imagined that a Linux kernel image would exceed that size (and at this time Linux was all what we were concerned about). Given the size explosion with 2.6 I fear that the 4 MB might not be enough for Linux any more soon, too :-(
a) just increase the unc_len variable to e.g. 16MB b) add a define with default to board config file (CONFIG_MAX_BOOTM_UNC_LEN). When not defined in config file, 0x400000 is used c) set unc_len to mem size :-) So user must know what he is doing.
What do you like best?
Looking at the gunzip() code I'm not sure we need this at all.
BTW: When the uncompressed data is more than the unc_len limit no error is reported. The uncompressed data is just truncated leading to corrupted uncompressed data. Should that be fixed, too?
Maybe we should just get rid of this and assume that there is sufficient space to uncompress the image.
Best regards,
Wolfgang Denk
participants (2)
-
Matthias Fuchs
-
Wolfgang Denk