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.

Reply via email to