From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:57619) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Scd34-0003Fq-SC for qemu-devel@nongnu.org; Thu, 07 Jun 2012 09:46:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Scd32-00055x-W2 for qemu-devel@nongnu.org; Thu, 07 Jun 2012 09:46:50 -0400 Received: from mx1.redhat.com ([209.132.183.28]:5050) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Scd32-00055Z-O3 for qemu-devel@nongnu.org; Thu, 07 Jun 2012 09:46:48 -0400 Date: Thu, 7 Jun 2012 09:46:43 -0400 From: Jason Baron Message-ID: <20120607134643.GA12564@redhat.com> References: <201206051609.q55G9ImZ019474@int-mx09.intmail.prod.int.phx2.redhat.com> <20120606000921.GA32725@morn.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120606000921.GA32725@morn.localdomain> Subject: Re: [Qemu-devel] [PATCH] seabios: correct setting of datalow_base for large rom images List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin O'Connor Cc: seabios@seabios.org, qemu-devel@nongnu.org, mst@redhat.com On Tue, Jun 05, 2012 at 08:09:21PM -0400, Kevin O'Connor wrote: > On Tue, Jun 05, 2012 at 12:09:18PM -0400, Jason Baron wrote: > > I've been creating 256kb rom images with larger acpi tables for second level > > buses. After a recent re-base, my rom images no longer built. Bisected to: > > > > commit 46b82624c95b951e8825fab117d9352faeae0ec8 > > Author: Kevin O'Connor > > Date: Sun May 13 12:10:30 2012 -0400 > > > > Add mechanism to declare variables as "low mem" and use for extra stack. > > > > > > Where sec32low_top is greater than datalow_base. Currently, datalow_base is > > calculated by subtracting a 64kb offset. Updating it to 128kb, resolved this > > issue for me, while still continuing to create smaller rom images as expected. > > Thanks. The problem causing the build to fail is that negative > numbers aren't encoded properly. That's easy to fix, but it quickly > uncovers a problem with relocations. Some of the 16bit code has 16bit > relocations and those wont be handled right if the integer wraps. I > put together a fix (see below) but it's a bit ugly. > ok, yes I can confirm that the patch fixes this issue for me. Thanks, -Jason