On Mon, Sep 26, 2011 at 5:24 PM, Avi Kivity <a...@redhat.com> wrote: > On 09/26/2011 08:20 PM, Blue Swirl wrote: >> >> On Mon, Sep 26, 2011 at 5:18 PM, Avi Kivity<a...@redhat.com> wrote: >> > On 09/26/2011 08:15 PM, Blue Swirl wrote: >> >> >> >> On Mon, Sep 26, 2011 at 10:08 AM, Avi Kivity<a...@redhat.com> 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.
That should work. > The whole dual mapping thing is wierd and set up some hoops for me to jump > through, it's probably completely bogus. Yes.