On 27.09.2011, at 21:19, Blue Swirl wrote:
> On Tue, Sep 27, 2011 at 4:44 PM, Avi Kivity <a...@redhat.com> wrote:
>> On 09/27/2011 07:39 PM, Blue Swirl wrote:
>>>
>>>>
>>>> Well, it's not that easy. As the other mapping is part of an ordinary
>>>> BAR,
>>>> you need to setup the device (at least PCI_COMMAND and
>>>> PCI_BASE_ADDRESS_0)
>>>> so it responds to memory requests, and also enable the bridge.
>>>>
>>>> We could hack it by having a low-priority mapping at 0x80013000, but it
>>>> seems wrong. Maybe the firmware should configure that BAR first? What
>>>> happens on real hardware?
>>>
>>> In this message I seem to confess that the address is arbitrary and in
>>> the subsequent messages the overlap with PCI region is also discussed.
>>> http://lists.nongnu.org/archive/html/qemu-devel/2009-01/msg00542.html
>>>
>>> Maybe the address of macio should be fixed as Laurent suggested.
>>
>> I'll leave it up to you - I'm out of my depth here.
>>
>> Meanwhile I suggest applying the pci alias patch - the bug is independent of
>> the vga issue.
>
> OK, pushed.
>
Ah, after digging into the issue for a while myself I stumbled over this
thread, explaining what I figured would be the culprit. Please CC qemu-ppc for
these discussions :).
Either way, I'm seeing 2 issues here. I enhanced the "info mtree" command to
also display the region we're currently looking at, so the first tuple shows
the region we're in, the second tuple the region we're trying to map into the
first region (addresses aligned on each other). I also print out alias
information directly:
[ 00000000-7ffffffffffffffe ] 00000000-7ffffffffffffffe : system
[ 80013000-8001303f ] 80013000-8001303f : escc
[ fee00000-fee00fff ] fee00000-fee00fff : pci-data-idx
[ fec00000-fec00fff ] fec00000-fec00fff : pci-conf-idx
[ 80000000-fdffffff ] 80000000-fdffffff : pci-hole
-> alias (0000000080000000, 0000000000000000)
[ 80000000-fdffffff ] 00000000-ffffffff : pci-mmio
[ 80880000-808fffff ] 80880000-808fffff : macio
[ 808e0000-808fffff ] 808e0000-808fffff : macio-nvram
[ 808a0000-808a0fff ] 808a0000-808a0fff : pmac-ide
[ 80896000-80897fff ] 80896000-80897fff : cuda
[ 80893000-8089303f ] 80893000-8089303f : escc-bar
-> alias (0000000000000000, 0000000080013000)
[ 80893000-8089303f ] 80893000-8089303f : escc
[ 80888000-80888fff ] 80888000-80888fff : dbdma
[ 80880000-80880fff ] 80880000-80880fff : heathrow-pic
[ 80800000-8080ffff ] 80800000-8080ffff : vga.rom
[ 80000000-807fffff ] 80000000-807fffff : vga.vram
[ fe000000-fe1fffff ] fe000000-fe1fffff : isa-mmio
I/O
[ 00000000-0000ffff ] 00000000-0000ffff : io
[ 00000700-0000070f ] 00000700-0000070f : cmd646-bmdma
[ 0000070c-0000070f ] 0000070c-0000070f : cmd646-bmdma-ioport
[ 00000708-0000070b ] 00000708-0000070b : cmd646-bmdma-bus
[ 00000704-00000707 ] 00000704-00000707 : cmd646-bmdma-ioport
[ 00000700-00000703 ] 00000700-00000703 : cmd646-bmdma-bus
[ 00000680-00000683 ] 00000680-00000683 : cmd646-cmd
[ 00000600-00000607 ] 00000600-00000607 : cmd646-data
[ 00000580-00000583 ] 00000580-00000583 : cmd646-cmd
[ 00000500-00000507 ] 00000500-00000507 : cmd646-data
[ 00000400-000004ff ] 00000400-000004ff : ne2000
I did another small hack to display the flat memory view:
ranges[0] = { 80000000, 13000 } vga.vram
ranges[1] = { 80013000, 40 } escc
ranges[2] = { 80013040, 7ecfc0 } vga.vram
ranges[3] = { 80800000, 10000 } vga.rom
ranges[4] = { 80880000, 1000 } heathrow-pic
ranges[5] = { 80888000, 1000 } dbdma
ranges[6] = { 80893000, 40 } escc
ranges[7] = { 80896000, 2000 } cuda
ranges[8] = { 808a0000, 1000 } pmac-ide
ranges[9] = { 808e0000, 20000 } macio-nvram
ranges[10] = { fe000000, 200000 } isa-mmio
ranges[11] = { fec00000, 1000 } pci-conf-idx
ranges[12] = { fee00000, 1000 } pci-data-idx
Now to the issues:
1)
ESCC is mapped inside the VGA region. That's what you discussed in this thread.
It's wrong. Please check this bug for a dump of a real G3 Beige's memory layout:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=555651
I don't think we really need to have serial available before PCI enum, so let's
just ditch the first map.
2)
vga.vram continues to be mapped, but apparently isn't accessible. I would
expect the hole of 40 bytes to be non-accessible / broken, but what ends up
happening is that the whole second region apparently is unusable. What exactly
is going on there? Sounds like a memory API bug to me.
Alex
