From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from fed1rmmtao05.cox.net (fed1rmmtao05.cox.net [68.230.241.34]) by ozlabs.org (Postfix) with ESMTP id AF2E467B53 for ; Thu, 17 Aug 2006 15:04:10 +1000 (EST) Date: Wed, 16 Aug 2006 22:04:08 -0700 From: Tom Rini To: Benjamin Heyne Subject: Re: [PATCH] Gunzip call fix for PPC kernel images >4MB Message-ID: <20060817050408.GJ3249@smtp.west.cox.net> References: <20060816113137.7a8e5608@bob.dt.e-technik.uni-dortmund.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <20060816113137.7a8e5608@bob.dt.e-technik.uni-dortmund.de> Cc: linuxppc-dev@ozlabs.org, Paul Mackerras , Milton Miller List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Wed, Aug 16, 2006 at 11:31:37AM +0200, Benjamin Heyne wrote: > If Kernel images for PPC grow >4MB inflating of the kernel fails. > Increasing the link/load address doesn't help. Problem is > solved by replacing the fixed address of the gunzip() call in > misc-embedded.c with CONFIG_BOOT_LOAD. I've thought about this a bit and I think the general concept is OK, but this works with a bit of luck I think. The arch/ppc/boot code makes some assumptions such as that 4MB-8MB (except on 40x which is end of the wrapper code to 8MB, and BOOT_LOAD defaults to 4MB here) is free to use for malloc()'ing for the inflate routine. It also assumes that the vmlinux.gz will live at BOOT_LOAD + a bit, when the wrapper is set to kick off linux. Finally, in arch/ppc/boot/ (for both OF and !OF cases) gunzip looks like: void gunzip(void *dst, int dstlen, unsigned char *src, int *lenp) So I see 2 problems here. First, there are other calls to gunzip with dstlen hard-coded to 4MB, so the problem would still exist. Second, and more complexly we want to make sure that we don't tell gunzip that the destination size grows into the area it would also be using to malloc buffers, unless someone can (and please do if possible) explain that it's really OK to uncompress into our zalloc space (there is no zfree so maybe it's going to be OK, but I don't know that the algorithm wouldn't try and reuse buffers which would be bad). Thanks! -- Tom Rini