From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:52677) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R8Eue-0007of-D8 for qemu-devel@nongnu.org; Mon, 26 Sep 2011 13:24:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R8Eud-0002n4-E2 for qemu-devel@nongnu.org; Mon, 26 Sep 2011 13:24:16 -0400 Received: from mx1.redhat.com ([209.132.183.28]:35053) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R8Eud-0002my-6w for qemu-devel@nongnu.org; Mon, 26 Sep 2011 13:24:15 -0400 Message-ID: <4E80B535.1030804@redhat.com> Date: Mon, 26 Sep 2011 20:24:05 +0300 From: Avi Kivity MIME-Version: 1.0 References: <4E7A828A.3030404@codemonkey.ws> <4E7F366F.9060501@redhat.com> <4E7F5B62.1090307@redhat.com> <4E804F20.2090007@redhat.com> <4E80B3EF.3070202@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [FYI] Soft feature freeze for 1.0 is 10/15 (three weeks away) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: qemu-devel On 09/26/2011 08:20 PM, Blue Swirl wrote: > On Mon, Sep 26, 2011 at 5:18 PM, Avi Kivity wrote: > > On 09/26/2011 08:15 PM, Blue Swirl wrote: > >> > >> On Mon, Sep 26, 2011 at 10:08 AM, Avi Kivity wrote: > >> > On 09/25/2011 08:31 PM, Blue Swirl wrote: > >> >> > >> >> > > >> >> > Please point out a test case and I'll try to fix it. > >> >> > >> >> Run qemu-system-ppc without any arguments. There is a black bar > >> >> (because of vga.chain4), it shouldn't be there. > >> > > >> > With your pci hole patch, it's fixed, except for: > >> > > >> > escc_mem = escc_init(0x80013000, pic[0x25], pic[0x24], > >> > serial_hds[0], serial_hds[1], ESCC_CLOCK, 4) > >> > > >> > This puts escc bang into the framebuffer. Changing it to 0x90013000 > >> > makes > >> > the black bar go away. > >> > > >> > Before the memory API, this worked, likely because the framebuffer > >> > overlays > >> > escc. > >> > > >> > The correct fix depends on what the hardware does. Is escc really > >> > registered into the pci area, and again as a BAR? > >> > >> I think the previous code assumed that there is a single BAR with > >> default address of 0x80013000, but it can move as controlled by macio > >> mapping. > > > > So the fix would be to just drop this extraneous mapping? > > The default address is used for early serial printk in OpenBIOS, so it > should still work. Ok, so drop the extra mapping, but init the dynamic mapping to 0x80013000. The whole dual mapping thing is wierd and set up some hoops for me to jump through, it's probably completely bogus. -- error compiling committee.c: too many arguments to function