Christian Ehrhardt wrote:
I tried to use a radeon r200 based graphic card on a sequoia ppc
(440epx) board. I wondered about the initialization of radeonfb that
failed with
__ioremap(): phys addr 0x0 is RAM lr c029cf80
radeonfb (0000:00:0a.0): cannot map MMIO
radeonfb: probe of 0000:00:0a.0 failed with error -5
I trigger a check in ioremap, because the address it wants to remap is
0x0 which can never work. The reason of that is that the pci ressource
of that graphic card is not properly detected.
There might be another reason. This driver seems to be another subject to
the 440-specific PCI memory space issue beacuse it uses 'unsigned long' to
store the PCI memory physical addresses and those are 64-bit in the 440
arch/powerpc/ kernels.
With some help I found two kernels - one that work and one that has this
issue.
Unfortunately they are very different:
good => 2.6.24.2 from the linux-2.6-denx - built for arch=ppc
bad => we have 2.6.25-rc9 (used in our kvm ppc project atm) - build
for arch=powerpc
I tried building the 2.6.25-rc9 with arch=ppc, but that one does not
boot so far. Because of that I can't surely tell you if it is only that
difference that breaks the pci detection.
We need arch=powerpc for our kvm code anyway, so I hope there is another
solution than to switch to arch=ppc ;-)
Yes, the driver needs fixing -- at least that.
I just started to debug into that, but I wanted to ask here if there
might be some known issues causing that and/or to get some hints where
to look at.
Now you know of at least one.
The issue is much better visible when I boot with these two kernels and
use "lspci -vvv"
Good kernel:
00:0a.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon
9200 PRO] (rev 01) (prog-if 00 [VGA])
Subsystem: PC Partner Limited Unknown device 0250
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 128 (2000ns min)
Interrupt: pin A routed to IRQ 67
Region 0: Memory at 88000000 (32-bit, prefetchable) [size=128M]
Region 1: I/O ports at ff00 [size=256]
Region 2: Memory at 87ff0000 (32-bit, non-prefetchable) [size=64K]
Expansion ROM at 80020000 [disabled] [size=128K]
Here, the PCI resources have been re-assigned by arch/ppc/ kernel, and are
confined to 4 GB due to fixup_bigphys_addr() trick used for 440...
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Bad kernel:
00:0a.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon
9200 PRO] (rev 01) (prog-if 00 [VGA])
Subsystem: PC Partner Limited Unknown device 0250
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 128 (2000ns min)
Interrupt: pin A routed to IRQ 16
Region 0: Memory at 180000000 (32-bit, prefetchable) [size=128M]
That's beyond 4 GB, seems correct. That should be the address assigned by
bootloader? BTW, what's your bootloader, U-Boot?
Region 1: I/O ports at 1000 [size=256]
Region 2: Memory at <ignored> (32-bit, non-prefetchable)
Hm... what could this mean? Could you post the result of 'lspci -x'?
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
=> Region 2 is not detected with our kernel, this later break things
like radeonfb initialization.
Well, not only this...
WBR, Sergei
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
