[U-Boot-Users] Question on do_bootm in cmd_bootm.c

[Nick Barendt]

	Can someone, maybe Wolfgang, comment on the maximum 4MB uncompressed size 
of gunzip (and, possibly, bzip2) images?
	I've been working on a Coldfire 5272 system for quite some time with 
u-boot and uClinux.  Both have been remarkably stable.  We use the uClinux 
default build wherein the root filesystem (romfs) is appended to the end of 
the kernel image, starting where the bss would normally be.  The kernel 
startup code relocates the romfs image to just beyond the bss, then, and 
everything runs smoothly.  I know that many folks in the PPC world use 
separate kernel and root filesystem images, for many good reasons, but many 
(most?) of the uClinux platforms use this concatenated kernel+romfs image.
	Recently, we've been adding more content to the root filesystem.  As our 
root filesystem grew larger (say about 3MB), however, we started seeing 
boot problems where the kernel would boot fine but the root filesystem was 
clearly corrupt.  I've spent the better part of two days trying to track 
down where things go wrong, from the kernel to u-boot.  Of course, I used a 
hardware debugger, looked at u-boot's memory assignments, image load 
addresses, entry points, malloc areas, etc.
	I just located the source of my trouble, a hard-coded 4MB maximum 
uncompressed size in do_bootm:

int do_bootm (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
{
	ulong	iflag;
	ulong	addr;
	ulong	data, len, checksum;
	ulong  *len_ptr;
	uint	unc_len = 0x400000;
                          ^^^^^^^^^
	int	i, verify;

SNIP

	case IH_COMP_GZIP:
		printf ("   Uncompressing %s ... ", name);
		if (gunzip ((void *)ntohl(hdr->ih_load), unc_len,
							^^^^^^^^
			    (uchar *)data, (int *)&len) != 0) {
			printf ("GUNZIP ERROR - must RESET board to recover\n");
			SHOW_BOOT_PROGRESS (-6);
			do_reset (cmdtp, flag, argc, argv);
		}
		break;

SNIP

	Increasing unc_len to larger values (like 6MB) seems to solve my problem.
	With an uncompressed image larger than 4MB, gunzip doesn't seem to 
generate any errors (granted, I haven't stepped through gunzip and zlib), 
but merrily runs along, although the data beyond the 4MB boundary seems to 
be missing or corrupt.  It looks like there's a truncation (about line 1875 
in zlib.c) to z.avail_out in zlib that prevents data from being copied 
beyond unc_len - maybe that should be an error instead of silently 
truncating data?  Just a thought.  I'll into submitting a patch for that.
	I was wondering if there was some reason for the 0x400000 magic number for 
unc_len.  Is that just a magic number?  Is that larger than anyone uses for 
images?  I guess I'm a little surprised that this hasn't bitten anyone else 
so far (nothing I could see on the mailing list archive, at least).  Our 
1MB kernel and 3MB romfs root filesystem might be exceptionally large, I 
don't know.
	Would there be any issues with making unc_len a CFG_ macro, if I submitted 
a patch?

Nick Barendt