* PCI changes 2.6.26 => 2.6.28
@ 2009-04-21 16:24 Gary Thomas
2009-04-21 20:30 ` Gary Thomas
0 siblings, 1 reply; 16+ messages in thread
From: Gary Thomas @ 2009-04-21 16:24 UTC (permalink / raw)
To: linuxppc-dev
I had a stable port of 2.6.26 for my 834x hardware, with a
frame buffer on a PCI device. After I upgraded to 2.6.28,
this isn't working any more. The frame buffer code is happily
writing to a mapped [memory] space on the PCI card, but nothing
is happening.
Did something [subtle] change in how the PCI is handled in
this timeframe? Perhaps with how PCI devices are mapped or
enabled? I've looked at the changes between the two versions,
but nothing leaps out at me.
n.b. I have other devices on the PCI bus, such as a SATA
controller, which work the same in both versions.
Thanks for any ideas
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: PCI changes 2.6.26 => 2.6.28
2009-04-21 16:24 PCI changes 2.6.26 => 2.6.28 Gary Thomas
@ 2009-04-21 20:30 ` Gary Thomas
2009-04-21 20:32 ` Gary Thomas
2009-04-21 20:33 ` Kumar Gala
0 siblings, 2 replies; 16+ messages in thread
From: Gary Thomas @ 2009-04-21 20:30 UTC (permalink / raw)
To: linuxppc-dev
Gary Thomas wrote:
> I had a stable port of 2.6.26 for my 834x hardware, with a
> frame buffer on a PCI device. After I upgraded to 2.6.28,
> this isn't working any more. The frame buffer code is happily
> writing to a mapped [memory] space on the PCI card, but nothing
> is happening.
>
> Did something [subtle] change in how the PCI is handled in
> this timeframe? Perhaps with how PCI devices are mapped or
> enabled? I've looked at the changes between the two versions,
> but nothing leaps out at me.
>
> n.b. I have other devices on the PCI bus, such as a SATA
> controller, which work the same in both versions.
>
> Thanks for any ideas
>
The difference seems to be in how the PCI bus gets mapped.
In the working, 2.6.26 based kernel, 'lspci -v' shows this:
00:00.0 Bridge: Unknown device 1957:0084 (rev 11)
Flags: bus master, 66MHz, fast devsel, latency 0
Memory at cc000000 (32-bit, non-prefetchable) [size=1M]
Memory at c0000000 (64-bit, prefetchable) [size=128M]
Memory at cc143100 (64-bit, non-prefetchable) [size=1]
Capabilities: [48] #06 [0000]
00:0a.0 Network controller: Unknown device 001c:0001 (rev 02)
Subsystem: Unknown device 001c:0004
Flags: medium devsel, IRQ 22
Memory at cc120000 (32-bit, non-prefetchable) [size=64K]
Memory at cc130000 (32-bit, non-prefetchable) [size=64K]
00:0b.0 Mass storage controller: Promise Technology, Inc. PDC40775 (SATA 300 TX2plus) (rev 02)
Subsystem: Promise Technology, Inc. Unknown device 3573
Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 23
I/O ports at 1000 [size=128]
I/O ports at 1100 [size=256]
Memory at cc140000 (32-bit, non-prefetchable) [size=4K]
Memory at cc100000 (32-bit, non-prefetchable) [size=128K]
Capabilities: [60] Power Management version 2
00:0c.0 Display controller: Fujitsu Limited. Unknown device 2019 (rev 01)
Flags: bus master, medium devsel, latency 0, IRQ 24
Memory at c8000000 (32-bit, non-prefetchable) [size=64M]
00:0d.0 USB Controller: Philips Semiconductors USB 1.1 Host Controller (rev 11) (prog-if 10 [OHCI])
Subsystem: Philips Semiconductors USB 1.1 Host Controller
Flags: bus master, medium devsel, latency 0, IRQ 25
Memory at cc141000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [dc] Power Management version 2
00:0d.1 USB Controller: Philips Semiconductors USB 1.1 Host Controller (rev 11) (prog-if 10 [OHCI])
Subsystem: Philips Semiconductors USB 1.1 Host Controller
Flags: bus master, medium devsel, latency 0, IRQ 25
Memory at cc142000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [dc] Power Management version 2
00:0d.2 USB Controller: Philips Semiconductors USB 2.0 Host Controller (rev 11) (prog-if 20 [EHCI])
Subsystem: Philips Semiconductors USB 2.0 Host Controller
Flags: bus master, medium devsel, latency 0, IRQ 25
Memory at cc143000 (32-bit, non-prefetchable) [size=256]
Capabilities: [dc] Power Management version 2
This is what 2.6.28 shows:
00:00.0 Bridge: Unknown device 1957:0084 (rev 11)
Flags: bus master, 66MHz, fast devsel, latency 0
Memory at <unassigned> (64-bit, prefetchable)
Memory at <unassigned> (64-bit, non-prefetchable)
Capabilities: [48] #06 [0000]
00:0a.0 Network controller: Unknown device 001c:0001 (rev 02)
Subsystem: Unknown device 001c:0004
Flags: medium devsel, IRQ 16
Memory at c4020000 (32-bit, non-prefetchable) [size=64K]
Memory at c4030000 (32-bit, non-prefetchable) [size=64K]
00:0b.0 Mass storage controller: Promise Technology, Inc. PDC40775 (SATA 300 TX2plus) (rev 02)
Subsystem: Promise Technology, Inc. Unknown device 3573
Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 21
I/O ports at 1000 [size=128]
I/O ports at 1100 [size=256]
Memory at c4040000 (32-bit, non-prefetchable) [size=4K]
Memory at c4000000 (32-bit, non-prefetchable) [size=128K]
Capabilities: [60] Power Management version 2
00:0c.0 Display controller: Fujitsu Limited. Unknown device 2019 (rev 01)
Flags: bus master, medium devsel, latency 0, IRQ 22
[virtual] Memory at c0000000 (32-bit, non-prefetchable) [size=64M]
00:0d.0 USB Controller: Philips Semiconductors USB 1.1 Host Controller (rev 11) (prog-if 10 [OHCI])
Subsystem: Philips Semiconductors USB 1.1 Host Controller
Flags: bus master, medium devsel, latency 0, IRQ 23
Memory at c4041000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [dc] Power Management version 2
00:0d.1 USB Controller: Philips Semiconductors USB 1.1 Host Controller (rev 11) (prog-if 10 [OHCI])
Subsystem: Philips Semiconductors USB 1.1 Host Controller
Flags: bus master, medium devsel, latency 0, IRQ 23
Memory at c4042000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [dc] Power Management version 2
00:0d.2 USB Controller: Philips Semiconductors USB 2.0 Host Controller (rev 11) (prog-if 20 [EHCI])
Subsystem: Philips Semiconductors USB 2.0 Host Controller
Flags: bus master, medium devsel, latency 0, IRQ 23
Memory at c4043000 (32-bit, non-prefetchable) [size=256]
Capabilities: [dc] Power Management version 2
The [two] big differences I see are that the video card (00:0d.0)
is being assigned 0xC0000000, which lspci marks as "virtual".
I think I've had trouble in the past with memory regions which
started at 0 relative to the PCI space. Also "virtual" concerns me.
Does this spark any ideas from anyone?
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: PCI changes 2.6.26 => 2.6.28
2009-04-21 20:30 ` Gary Thomas
@ 2009-04-21 20:32 ` Gary Thomas
2009-04-21 20:33 ` Kumar Gala
1 sibling, 0 replies; 16+ messages in thread
From: Gary Thomas @ 2009-04-21 20:32 UTC (permalink / raw)
To: linuxppc-dev
Gary Thomas wrote:
> Gary Thomas wrote:
>> I had a stable port of 2.6.26 for my 834x hardware, with a
>> frame buffer on a PCI device. After I upgraded to 2.6.28,
>> this isn't working any more. The frame buffer code is happily
>> writing to a mapped [memory] space on the PCI card, but nothing
>> is happening.
>>
>> Did something [subtle] change in how the PCI is handled in
>> this timeframe? Perhaps with how PCI devices are mapped or
>> enabled? I've looked at the changes between the two versions,
>> but nothing leaps out at me.
>>
>> n.b. I have other devices on the PCI bus, such as a SATA
>> controller, which work the same in both versions.
>>
>> Thanks for any ideas
>>
>
> The difference seems to be in how the PCI bus gets mapped.
>
> In the working, 2.6.26 based kernel, 'lspci -v' shows this:
>
> 00:00.0 Bridge: Unknown device 1957:0084 (rev 11)
> Flags: bus master, 66MHz, fast devsel, latency 0
> Memory at cc000000 (32-bit, non-prefetchable) [size=1M]
> Memory at c0000000 (64-bit, prefetchable) [size=128M]
> Memory at cc143100 (64-bit, non-prefetchable) [size=1]
> Capabilities: [48] #06 [0000]
>
> 00:0a.0 Network controller: Unknown device 001c:0001 (rev 02)
> Subsystem: Unknown device 001c:0004
> Flags: medium devsel, IRQ 22
> Memory at cc120000 (32-bit, non-prefetchable) [size=64K]
> Memory at cc130000 (32-bit, non-prefetchable) [size=64K]
>
> 00:0b.0 Mass storage controller: Promise Technology, Inc. PDC40775 (SATA 300 TX2plus) (rev 02)
> Subsystem: Promise Technology, Inc. Unknown device 3573
> Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 23
> I/O ports at 1000 [size=128]
> I/O ports at 1100 [size=256]
> Memory at cc140000 (32-bit, non-prefetchable) [size=4K]
> Memory at cc100000 (32-bit, non-prefetchable) [size=128K]
> Capabilities: [60] Power Management version 2
>
> 00:0c.0 Display controller: Fujitsu Limited. Unknown device 2019 (rev 01)
> Flags: bus master, medium devsel, latency 0, IRQ 24
> Memory at c8000000 (32-bit, non-prefetchable) [size=64M]
>
> 00:0d.0 USB Controller: Philips Semiconductors USB 1.1 Host Controller (rev 11) (prog-if 10 [OHCI])
> Subsystem: Philips Semiconductors USB 1.1 Host Controller
> Flags: bus master, medium devsel, latency 0, IRQ 25
> Memory at cc141000 (32-bit, non-prefetchable) [size=4K]
> Capabilities: [dc] Power Management version 2
>
> 00:0d.1 USB Controller: Philips Semiconductors USB 1.1 Host Controller (rev 11) (prog-if 10 [OHCI])
> Subsystem: Philips Semiconductors USB 1.1 Host Controller
> Flags: bus master, medium devsel, latency 0, IRQ 25
> Memory at cc142000 (32-bit, non-prefetchable) [size=4K]
> Capabilities: [dc] Power Management version 2
>
> 00:0d.2 USB Controller: Philips Semiconductors USB 2.0 Host Controller (rev 11) (prog-if 20 [EHCI])
> Subsystem: Philips Semiconductors USB 2.0 Host Controller
> Flags: bus master, medium devsel, latency 0, IRQ 25
> Memory at cc143000 (32-bit, non-prefetchable) [size=256]
> Capabilities: [dc] Power Management version 2
>
> This is what 2.6.28 shows:
>
> 00:00.0 Bridge: Unknown device 1957:0084 (rev 11)
> Flags: bus master, 66MHz, fast devsel, latency 0
> Memory at <unassigned> (64-bit, prefetchable)
> Memory at <unassigned> (64-bit, non-prefetchable)
> Capabilities: [48] #06 [0000]
>
> 00:0a.0 Network controller: Unknown device 001c:0001 (rev 02)
> Subsystem: Unknown device 001c:0004
> Flags: medium devsel, IRQ 16
> Memory at c4020000 (32-bit, non-prefetchable) [size=64K]
> Memory at c4030000 (32-bit, non-prefetchable) [size=64K]
>
> 00:0b.0 Mass storage controller: Promise Technology, Inc. PDC40775 (SATA 300 TX2plus) (rev 02)
> Subsystem: Promise Technology, Inc. Unknown device 3573
> Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 21
> I/O ports at 1000 [size=128]
> I/O ports at 1100 [size=256]
> Memory at c4040000 (32-bit, non-prefetchable) [size=4K]
> Memory at c4000000 (32-bit, non-prefetchable) [size=128K]
> Capabilities: [60] Power Management version 2
>
> 00:0c.0 Display controller: Fujitsu Limited. Unknown device 2019 (rev 01)
> Flags: bus master, medium devsel, latency 0, IRQ 22
> [virtual] Memory at c0000000 (32-bit, non-prefetchable) [size=64M]
>
> 00:0d.0 USB Controller: Philips Semiconductors USB 1.1 Host Controller (rev 11) (prog-if 10 [OHCI])
> Subsystem: Philips Semiconductors USB 1.1 Host Controller
> Flags: bus master, medium devsel, latency 0, IRQ 23
> Memory at c4041000 (32-bit, non-prefetchable) [size=4K]
> Capabilities: [dc] Power Management version 2
>
> 00:0d.1 USB Controller: Philips Semiconductors USB 1.1 Host Controller (rev 11) (prog-if 10 [OHCI])
> Subsystem: Philips Semiconductors USB 1.1 Host Controller
> Flags: bus master, medium devsel, latency 0, IRQ 23
> Memory at c4042000 (32-bit, non-prefetchable) [size=4K]
> Capabilities: [dc] Power Management version 2
>
> 00:0d.2 USB Controller: Philips Semiconductors USB 2.0 Host Controller (rev 11) (prog-if 20 [EHCI])
> Subsystem: Philips Semiconductors USB 2.0 Host Controller
> Flags: bus master, medium devsel, latency 0, IRQ 23
> Memory at c4043000 (32-bit, non-prefetchable) [size=256]
> Capabilities: [dc] Power Management version 2
>
> The [two] big differences I see are that the video card (00:0d.0)
> is being assigned 0xC0000000, which lspci marks as "virtual".
> I think I've had trouble in the past with memory regions which
> started at 0 relative to the PCI space. Also "virtual" concerns me.
>
> Does this spark any ideas from anyone?
>
n.b. "virtual" means that Linux reports that the device has
been mapped to 0xC0000000, but the device address register
is still unset :-( How can this happen?
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: PCI changes 2.6.26 => 2.6.28
2009-04-21 20:30 ` Gary Thomas
2009-04-21 20:32 ` Gary Thomas
@ 2009-04-21 20:33 ` Kumar Gala
2009-04-21 20:45 ` Gary Thomas
1 sibling, 1 reply; 16+ messages in thread
From: Kumar Gala @ 2009-04-21 20:33 UTC (permalink / raw)
To: Gary Thomas; +Cc: linuxppc-dev
On Apr 21, 2009, at 3:30 PM, Gary Thomas wrote:
> The [two] big differences I see are that the video card (00:0d.0)
> is being assigned 0xC0000000, which lspci marks as "virtual".
> I think I've had trouble in the past with memory regions which
> started at 0 relative to the PCI space. Also "virtual" concerns me.
>
> Does this spark any ideas from anyone?
Doesn't ring any bells. What does cat /proc/iomem look like between
the two kernels.
- k
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: PCI changes 2.6.26 => 2.6.28
2009-04-21 20:33 ` Kumar Gala
@ 2009-04-21 20:45 ` Gary Thomas
2009-04-21 22:22 ` Gary Thomas
0 siblings, 1 reply; 16+ messages in thread
From: Gary Thomas @ 2009-04-21 20:45 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
Kumar Gala wrote:
>
> On Apr 21, 2009, at 3:30 PM, Gary Thomas wrote:
>
>> The [two] big differences I see are that the video card (00:0d.0)
>> is being assigned 0xC0000000, which lspci marks as "virtual".
>> I think I've had trouble in the past with memory regions which
>> started at 0 relative to the PCI space. Also "virtual" concerns me.
>>
>> Does this spark any ideas from anyone?
>
> Doesn't ring any bells. What does cat /proc/iomem look like between the
> two kernels.
About what I gleaned from lspci. The working 2.6.26 kernel has
space mapped in the controller (exposed memory window, I think)
and the video card got moved down accordingly.
---------------------------------- 2.6.26
c0000000-cfffffff : /pci@ff008500
c0000000-c7ffffff : 0000:00:00.0
c8000000-cbffffff : 0000:00:0c.0
c8000000-cbffffff : CoralP_fb
cc000000-cc0fffff : 0000:00:00.0
cc100000-cc11ffff : 0000:00:0b.0
cc120000-cc12ffff : 0000:00:0a.0
cc130000-cc13ffff : 0000:00:0a.0
cc140000-cc140fff : 0000:00:0b.0
cc140000-cc140fff : sata_promise
cc141000-cc141fff : 0000:00:0d.0
cc141000-cc141fff : ohci_hcd
cc142000-cc142fff : 0000:00:0d.1
cc142000-cc142fff : ohci_hcd
cc143000-cc1430ff : 0000:00:0d.2
cc143000-cc1430ff : ehci_hcd
cc143100-cc143100 : 0000:00:00.0
f0000000-f1ffffff : f0000000.flash
ff000200-ff0002ff : wdt
ff003000-ff0030ff : i2c
ff003100-ff0031ff : i2c
ff004500-ff004507 : serial
ff004600-ff004607 : serial
ff022000-ff022fff : usb
ff022000-ff022fff : ehci_hcd
ff023000-ff023fff : usb
ff023000-ff023fff : usb
ff023000-ff023fff : ehci_hcd
ff024000-ff024fff : ethernet
ff024520-ff02453f : mdio
ff025000-ff025fff : ethernet
---------------------------------- 2.6.28
c0000000-cfffffff : /pci@ff008500
c0000000-c3ffffff : 0000:00:0c.0
c0000000-c3ffffff : CoralP_fb
c4000000-c401ffff : 0000:00:0b.0
c4020000-c402ffff : 0000:00:0a.0
c4030000-c403ffff : 0000:00:0a.0
c4040000-c4040fff : 0000:00:0b.0
c4040000-c4040fff : sata_promise
c4041000-c4041fff : 0000:00:0d.0
c4041000-c4041fff : ohci_hcd
c4042000-c4042fff : 0000:00:0d.1
c4042000-c4042fff : ohci_hcd
c4043000-c40430ff : 0000:00:0d.2
c4043000-c40430ff : ehci_hcd
f0000000-f1ffffff : f0000000.flash
ff004500-ff004507 : serial
ff004600-ff004607 : serial
ff022000-ff022fff : usb
ff022000-ff022fff : ehci_hcd
ff023000-ff023fff : usb
ff023000-ff023fff : usb
ff023000-ff023fff : ehci_hcd
ff024000-ff024fff : ethernet
ff024520-ff02453f : mdio
ff025000-ff025fff : ethernet
I'm still looking into how the PCI address register for the video
card did not get written, even though the system obviously thinks
it did (hence "virtual")
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: PCI changes 2.6.26 => 2.6.28
2009-04-21 20:45 ` Gary Thomas
@ 2009-04-21 22:22 ` Gary Thomas
2009-04-21 22:38 ` Kumar Gala
0 siblings, 1 reply; 16+ messages in thread
From: Gary Thomas @ 2009-04-21 22:22 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
Gary Thomas wrote:
> Kumar Gala wrote:
>> On Apr 21, 2009, at 3:30 PM, Gary Thomas wrote:
>>
>>> The [two] big differences I see are that the video card (00:0d.0)
>>> is being assigned 0xC0000000, which lspci marks as "virtual".
>>> I think I've had trouble in the past with memory regions which
>>> started at 0 relative to the PCI space. Also "virtual" concerns me.
>>>
>>> Does this spark any ideas from anyone?
>> Doesn't ring any bells. What does cat /proc/iomem look like between the
>> two kernels.
>
> About what I gleaned from lspci. The working 2.6.26 kernel has
> space mapped in the controller (exposed memory window, I think)
> and the video card got moved down accordingly.
>
> ---------------------------------- 2.6.26
> c0000000-cfffffff : /pci@ff008500
> c0000000-c7ffffff : 0000:00:00.0
> c8000000-cbffffff : 0000:00:0c.0
> c8000000-cbffffff : CoralP_fb
> cc000000-cc0fffff : 0000:00:00.0
> cc100000-cc11ffff : 0000:00:0b.0
> cc120000-cc12ffff : 0000:00:0a.0
> cc130000-cc13ffff : 0000:00:0a.0
> cc140000-cc140fff : 0000:00:0b.0
> cc140000-cc140fff : sata_promise
> cc141000-cc141fff : 0000:00:0d.0
> cc141000-cc141fff : ohci_hcd
> cc142000-cc142fff : 0000:00:0d.1
> cc142000-cc142fff : ohci_hcd
> cc143000-cc1430ff : 0000:00:0d.2
> cc143000-cc1430ff : ehci_hcd
> cc143100-cc143100 : 0000:00:00.0
> f0000000-f1ffffff : f0000000.flash
> ff000200-ff0002ff : wdt
> ff003000-ff0030ff : i2c
> ff003100-ff0031ff : i2c
> ff004500-ff004507 : serial
> ff004600-ff004607 : serial
> ff022000-ff022fff : usb
> ff022000-ff022fff : ehci_hcd
> ff023000-ff023fff : usb
> ff023000-ff023fff : usb
> ff023000-ff023fff : ehci_hcd
> ff024000-ff024fff : ethernet
> ff024520-ff02453f : mdio
> ff025000-ff025fff : ethernet
>
> ---------------------------------- 2.6.28
> c0000000-cfffffff : /pci@ff008500
> c0000000-c3ffffff : 0000:00:0c.0
> c0000000-c3ffffff : CoralP_fb
> c4000000-c401ffff : 0000:00:0b.0
> c4020000-c402ffff : 0000:00:0a.0
> c4030000-c403ffff : 0000:00:0a.0
> c4040000-c4040fff : 0000:00:0b.0
> c4040000-c4040fff : sata_promise
> c4041000-c4041fff : 0000:00:0d.0
> c4041000-c4041fff : ohci_hcd
> c4042000-c4042fff : 0000:00:0d.1
> c4042000-c4042fff : ohci_hcd
> c4043000-c40430ff : 0000:00:0d.2
> c4043000-c40430ff : ehci_hcd
> f0000000-f1ffffff : f0000000.flash
> ff004500-ff004507 : serial
> ff004600-ff004607 : serial
> ff022000-ff022fff : usb
> ff022000-ff022fff : ehci_hcd
> ff023000-ff023fff : usb
> ff023000-ff023fff : usb
> ff023000-ff023fff : ehci_hcd
> ff024000-ff024fff : ethernet
> ff024520-ff02453f : mdio
> ff025000-ff025fff : ethernet
>
> I'm still looking into how the PCI address register for the video
> card did not get written, even though the system obviously thinks
> it did (hence "virtual")
>
It most definitely has something to do with 0xC0000000 being
assigned to the video card. I changed my DTS to move everything
up (started the whole space at 0xC4000000) and the video card
came to life! Of course, I'm not interested in this hack,
so the simplest thing would be to figure out why 2.6.26 allocated
that outgoing window and 2.6.28 doesn't
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: PCI changes 2.6.26 => 2.6.28
2009-04-21 22:22 ` Gary Thomas
@ 2009-04-21 22:38 ` Kumar Gala
2009-04-21 22:50 ` Kumar Gala
0 siblings, 1 reply; 16+ messages in thread
From: Kumar Gala @ 2009-04-21 22:38 UTC (permalink / raw)
To: Gary Thomas; +Cc: linuxppc-dev
On Apr 21, 2009, at 5:22 PM, Gary Thomas wrote:
> Gary Thomas wrote:
>> Kumar Gala wrote:
>>> On Apr 21, 2009, at 3:30 PM, Gary Thomas wrote:
>>>
>>>> The [two] big differences I see are that the video card (00:0d.0)
>>>> is being assigned 0xC0000000, which lspci marks as "virtual".
>>>> I think I've had trouble in the past with memory regions which
>>>> started at 0 relative to the PCI space. Also "virtual" concerns
>>>> me.
>>>>
>>>> Does this spark any ideas from anyone?
>>> Doesn't ring any bells. What does cat /proc/iomem look like
>>> between the
>>> two kernels.
>>
>> About what I gleaned from lspci. The working 2.6.26 kernel has
>> space mapped in the controller (exposed memory window, I think)
>> and the video card got moved down accordingly.
>>
>> ---------------------------------- 2.6.26
>> c0000000-cfffffff : /pci@ff008500
>> c0000000-c7ffffff : 0000:00:00.0
>> c8000000-cbffffff : 0000:00:0c.0
>> c8000000-cbffffff : CoralP_fb
>> cc000000-cc0fffff : 0000:00:00.0
>> cc100000-cc11ffff : 0000:00:0b.0
>> cc120000-cc12ffff : 0000:00:0a.0
>> cc130000-cc13ffff : 0000:00:0a.0
>> cc140000-cc140fff : 0000:00:0b.0
>> cc140000-cc140fff : sata_promise
>> cc141000-cc141fff : 0000:00:0d.0
>> cc141000-cc141fff : ohci_hcd
>> cc142000-cc142fff : 0000:00:0d.1
>> cc142000-cc142fff : ohci_hcd
>> cc143000-cc1430ff : 0000:00:0d.2
>> cc143000-cc1430ff : ehci_hcd
>> cc143100-cc143100 : 0000:00:00.0
>> f0000000-f1ffffff : f0000000.flash
>> ff000200-ff0002ff : wdt
>> ff003000-ff0030ff : i2c
>> ff003100-ff0031ff : i2c
>> ff004500-ff004507 : serial
>> ff004600-ff004607 : serial
>> ff022000-ff022fff : usb
>> ff022000-ff022fff : ehci_hcd
>> ff023000-ff023fff : usb
>> ff023000-ff023fff : usb
>> ff023000-ff023fff : ehci_hcd
>> ff024000-ff024fff : ethernet
>> ff024520-ff02453f : mdio
>> ff025000-ff025fff : ethernet
>>
>> ---------------------------------- 2.6.28
>> c0000000-cfffffff : /pci@ff008500
>> c0000000-c3ffffff : 0000:00:0c.0
>> c0000000-c3ffffff : CoralP_fb
>> c4000000-c401ffff : 0000:00:0b.0
>> c4020000-c402ffff : 0000:00:0a.0
>> c4030000-c403ffff : 0000:00:0a.0
>> c4040000-c4040fff : 0000:00:0b.0
>> c4040000-c4040fff : sata_promise
>> c4041000-c4041fff : 0000:00:0d.0
>> c4041000-c4041fff : ohci_hcd
>> c4042000-c4042fff : 0000:00:0d.1
>> c4042000-c4042fff : ohci_hcd
>> c4043000-c40430ff : 0000:00:0d.2
>> c4043000-c40430ff : ehci_hcd
>> f0000000-f1ffffff : f0000000.flash
>> ff004500-ff004507 : serial
>> ff004600-ff004607 : serial
>> ff022000-ff022fff : usb
>> ff022000-ff022fff : ehci_hcd
>> ff023000-ff023fff : usb
>> ff023000-ff023fff : usb
>> ff023000-ff023fff : ehci_hcd
>> ff024000-ff024fff : ethernet
>> ff024520-ff02453f : mdio
>> ff025000-ff025fff : ethernet
>>
>> I'm still looking into how the PCI address register for the video
>> card did not get written, even though the system obviously thinks
>> it did (hence "virtual")
>>
>
> It most definitely has something to do with 0xC0000000 being
> assigned to the video card. I changed my DTS to move everything
> up (started the whole space at 0xC4000000) and the video card
> came to life! Of course, I'm not interested in this hack,
> so the simplest thing would be to figure out why 2.6.26 allocated
> that outgoing window and 2.6.28 doesn't
So I think the difference is due to the change in PCI code between
2.6.26 and .28 for 83xx. If you notice we exclude the FSL device in .
26 you have:
>> c0000000-c7ffffff : 0000:00:00.0
and in .28 its gone. This accounts for the allocation differences.
What I don't get is why the behavior would vary based on address.
Can you dump out the PCI inbound/outbound registers. I have a theory
as to what's going on and want to confirm it.
- k
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: PCI changes 2.6.26 => 2.6.28
2009-04-21 22:38 ` Kumar Gala
@ 2009-04-21 22:50 ` Kumar Gala
2009-04-21 23:00 ` Gary Thomas
0 siblings, 1 reply; 16+ messages in thread
From: Kumar Gala @ 2009-04-21 22:50 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Gary Thomas
>>> I'm still looking into how the PCI address register for the video
>>> card did not get written, even though the system obviously thinks
>>> it did (hence "virtual")
>>>
>>
>> It most definitely has something to do with 0xC0000000 being
>> assigned to the video card. I changed my DTS to move everything
>> up (started the whole space at 0xC4000000) and the video card
>> came to life! Of course, I'm not interested in this hack,
>> so the simplest thing would be to figure out why 2.6.26 allocated
>> that outgoing window and 2.6.28 doesn't
>
> So I think the difference is due to the change in PCI code between
> 2.6.26 and .28 for 83xx. If you notice we exclude the FSL device
> in .26 you have:
>
>>> c0000000-c7ffffff : 0000:00:00.0
>
> and in .28 its gone. This accounts for the allocation differences.
> What I don't get is why the behavior would vary based on address.
>
> Can you dump out the PCI inbound/outbound registers. I have a
> theory as to what's going on and want to confirm it.
Also, what's your .dts look like for the PCI node.
- k
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: PCI changes 2.6.26 => 2.6.28
2009-04-21 22:50 ` Kumar Gala
@ 2009-04-21 23:00 ` Gary Thomas
2009-04-21 23:41 ` Kumar Gala
0 siblings, 1 reply; 16+ messages in thread
From: Gary Thomas @ 2009-04-21 23:00 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
Kumar Gala wrote:
>>>> I'm still looking into how the PCI address register for the video
>>>> card did not get written, even though the system obviously thinks
>>>> it did (hence "virtual")
>>>>
>>>
>>> It most definitely has something to do with 0xC0000000 being
>>> assigned to the video card. I changed my DTS to move everything
>>> up (started the whole space at 0xC4000000) and the video card
>>> came to life! Of course, I'm not interested in this hack,
>>> so the simplest thing would be to figure out why 2.6.26 allocated
>>> that outgoing window and 2.6.28 doesn't
>>
>> So I think the difference is due to the change in PCI code between
>> 2.6.26 and .28 for 83xx. If you notice we exclude the FSL device in
>> .26 you have:
>>
>>>> c0000000-c7ffffff : 0000:00:00.0
>>
>> and in .28 its gone. This accounts for the allocation differences.
>> What I don't get is why the behavior would vary based on address.
>>
>> Can you dump out the PCI inbound/outbound registers. I have a theory
>> as to what's going on and want to confirm it.
I found the difference - in 2.6.28 the inbound/outbound windows
don't seem to be set up at all. In 2.6.26, the function 'fsl_add_bridge'
was common among architectures and ended up calling 'setup_pci_atmu'
which created those mappings. In 2.6.28, the 83xx PCI setup code
has been refactored. It uses 'mpc83xx_add_bridge' instead of
'fsl_add_bridge' and 'setup_pci_atmu' is not called at all :-(
I'm sure this is the problem.
> Also, what's your .dts look like for the PCI node.
For the record:
bus-range = <0 0>;
ranges = <0x02000000 0x0 0xC0000000 0xC0000000 0x0 0x10000000
0x01000000 0x0 0x00000000 0xB8000000 0x0 0x00100000>;
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: PCI changes 2.6.26 => 2.6.28
2009-04-21 23:00 ` Gary Thomas
@ 2009-04-21 23:41 ` Kumar Gala
2009-04-21 23:45 ` Gary Thomas
0 siblings, 1 reply; 16+ messages in thread
From: Kumar Gala @ 2009-04-21 23:41 UTC (permalink / raw)
To: Gary Thomas; +Cc: linuxppc-dev
On Apr 21, 2009, at 6:00 PM, Gary Thomas wrote:
>
> I found the difference - in 2.6.28 the inbound/outbound windows
> don't seem to be set up at all. In 2.6.26, the function
> 'fsl_add_bridge'
> was common among architectures and ended up calling 'setup_pci_atmu'
> which created those mappings. In 2.6.28, the 83xx PCI setup code
> has been refactored. It uses 'mpc83xx_add_bridge' instead of
> 'fsl_add_bridge' and 'setup_pci_atmu' is not called at all :-(
>
> I'm sure this is the problem.
Looking at a diff between 2.6.26 and .28 I don't see the 83xx pci code
calling setup_pci_atmu().
- k
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: PCI changes 2.6.26 => 2.6.28
2009-04-21 23:41 ` Kumar Gala
@ 2009-04-21 23:45 ` Gary Thomas
2009-04-22 3:51 ` Kumar Gala
0 siblings, 1 reply; 16+ messages in thread
From: Gary Thomas @ 2009-04-21 23:45 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
Kumar Gala wrote:
>
> On Apr 21, 2009, at 6:00 PM, Gary Thomas wrote:
>
>>
>> I found the difference - in 2.6.28 the inbound/outbound windows
>> don't seem to be set up at all. In 2.6.26, the function 'fsl_add_bridge'
>> was common among architectures and ended up calling 'setup_pci_atmu'
>> which created those mappings. In 2.6.28, the 83xx PCI setup code
>> has been refactored. It uses 'mpc83xx_add_bridge' instead of
>> 'fsl_add_bridge' and 'setup_pci_atmu' is not called at all :-(
>>
>> I'm sure this is the problem.
>
> Looking at a diff between 2.6.26 and .28 I don't see the 83xx pci code
> calling setup_pci_atmu().
It did not directly; it called 'fsl_add_bridge' which in turn called
'setup_pci_atmu'
I modified the 2.6.28 driver to also call this function. Now the
inbound/outbound windows are set up, but the bridge still has
no allocations, so the problem remains.
I need to move on; I may just live with sliding the PCI space
up for now (doesn't really hurt anything, just seems like a hack)
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: PCI changes 2.6.26 => 2.6.28
2009-04-21 23:45 ` Gary Thomas
@ 2009-04-22 3:51 ` Kumar Gala
2009-04-23 14:24 ` Gary Thomas
0 siblings, 1 reply; 16+ messages in thread
From: Kumar Gala @ 2009-04-22 3:51 UTC (permalink / raw)
To: Gary Thomas; +Cc: linuxppc-dev
On Apr 21, 2009, at 6:45 PM, Gary Thomas wrote:
> Kumar Gala wrote:
>>
>> On Apr 21, 2009, at 6:00 PM, Gary Thomas wrote:
>>
>>>
>>> I found the difference - in 2.6.28 the inbound/outbound windows
>>> don't seem to be set up at all. In 2.6.26, the function
>>> 'fsl_add_bridge'
>>> was common among architectures and ended up calling 'setup_pci_atmu'
>>> which created those mappings. In 2.6.28, the 83xx PCI setup code
>>> has been refactored. It uses 'mpc83xx_add_bridge' instead of
>>> 'fsl_add_bridge' and 'setup_pci_atmu' is not called at all :-(
>>>
>>> I'm sure this is the problem.
>>
>> Looking at a diff between 2.6.26 and .28 I don't see the 83xx pci
>> code
>> calling setup_pci_atmu().
>
> It did not directly; it called 'fsl_add_bridge' which in turn called
> 'setup_pci_atmu'
Don't ever see 83xx boards calling fsl_add_bridge -- that is 85xx/86xx
only in 83xx.
> I modified the 2.6.28 driver to also call this function. Now the
> inbound/outbound windows are set up, but the bridge still has
> no allocations, so the problem remains.
>
> I need to move on; I may just live with sliding the PCI space
> up for now (doesn't really hurt anything, just seems like a hack)
It is and you are glossing over a real bug.
Are you using u-boot to boot? If so is the board port public?
- k
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: PCI changes 2.6.26 => 2.6.28
2009-04-22 3:51 ` Kumar Gala
@ 2009-04-23 14:24 ` Gary Thomas
2009-04-23 18:47 ` Kumar Gala
0 siblings, 1 reply; 16+ messages in thread
From: Gary Thomas @ 2009-04-23 14:24 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 2847 bytes --]
Kumar Gala wrote:
>
> On Apr 21, 2009, at 6:45 PM, Gary Thomas wrote:
>
>> Kumar Gala wrote:
>>>
>>> On Apr 21, 2009, at 6:00 PM, Gary Thomas wrote:
>>>
>>>>
>>>> I found the difference - in 2.6.28 the inbound/outbound windows
>>>> don't seem to be set up at all. In 2.6.26, the function
>>>> 'fsl_add_bridge'
>>>> was common among architectures and ended up calling 'setup_pci_atmu'
>>>> which created those mappings. In 2.6.28, the 83xx PCI setup code
>>>> has been refactored. It uses 'mpc83xx_add_bridge' instead of
>>>> 'fsl_add_bridge' and 'setup_pci_atmu' is not called at all :-(
>>>>
>>>> I'm sure this is the problem.
>>>
>>> Looking at a diff between 2.6.26 and .28 I don't see the 83xx pci code
>>> calling setup_pci_atmu().
>>
>> It did not directly; it called 'fsl_add_bridge' which in turn called
>> 'setup_pci_atmu'
>
> Don't ever see 83xx boards calling fsl_add_bridge -- that is 85xx/86xx
> only in 83xx.
Sorry, you're correct. I got lost looking through the code :-(
No matter, none of that code seems to be relevant to the change
in behaviour.
>> I modified the 2.6.28 driver to also call this function. Now the
>> inbound/outbound windows are set up, but the bridge still has
>> no allocations, so the problem remains.
>>
>> I need to move on; I may just live with sliding the PCI space
>> up for now (doesn't really hurt anything, just seems like a hack)
>
> It is and you are glossing over a real bug.
I have found the culprit - in arch/powerpc/kernel/pci_32.c
static void
fixup_hide_host_resource_fsl(struct pci_dev *dev)
{
int i, class = dev->class >> 8;
#if 0
if ((class == PCI_CLASS_PROCESSOR_POWERPC ||
class == PCI_CLASS_BRIDGE_OTHER) &&
#else
if ((class == PCI_CLASS_PROCESSOR_POWERPC) &&
#endif
(dev->hdr_type == PCI_HEADER_TYPE_NORMAL) &&
(dev->bus->parent == NULL)) {
for (i = 0; i < DEVICE_COUNT_RESOURCE; i++) {
dev->resource[i].start = 0;
dev->resource[i].end = 0;
dev->resource[i].flags = 0;
}
}
}
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_MOTOROLA, PCI_ANY_ID, fixup_hide_host_resource_fsl);
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_FREESCALE, PCI_ANY_ID, fixup_hide_host_resource_fsl);
This function is now (the #if 0 case is in 2.6.28) tossing out
the memory resources used by the PCI bridge itself. This makes
everything fall over, at least on my 834x platform.
This change was applied 2008-10-08, but it seems incorrect on the 834x.
> Are you using u-boot to boot? If so is the board port public?
My systems use RedBoot (I'm the original author of RedBoot, so one would
expect that). At this moment, the code isn't public, sorry.
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
[-- Attachment #2: Attached Message --]
[-- Type: message/rfc822, Size: 4387 bytes --]
From: John Rigby <jrigby@freescale.com>
To: linuxppc-dev@ozlabs.org
Cc: John Rigby <jrigby@freescale.com>
Subject: [PATCH 3/3] powerpc: pci: 5121: Hide pci bridge.
Date: Tue, 7 Oct 2008 13:00:20 -0600
Message-ID: <1223406020-12278-4-git-send-email-jrigby@freescale.com>
The class of the MPC5121 pci host bridge is PCI_CLASS_BRIDGE_OTHER
while other freescale host bridges have class set to
PCI_CLASS_PROCESSOR_POWERPC.
This patch makes fixup_hide_host_resource_fsl match
PCI_CLASS_BRIDGE_OTHER in addition to PCI_CLASS_PROCESSOR_POWERPC.
Signed-off-by: John Rigby <jrigby@freescale.com>
---
arch/powerpc/kernel/pci_32.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/pci_32.c b/arch/powerpc/kernel/pci_32.c
index 174b77e..a848c63 100644
--- a/arch/powerpc/kernel/pci_32.c
+++ b/arch/powerpc/kernel/pci_32.c
@@ -54,11 +54,12 @@ LIST_HEAD(hose_list);
static int pci_bus_count;
static void
-fixup_hide_host_resource_fsl(struct pci_dev* dev)
+fixup_hide_host_resource_fsl(struct pci_dev *dev)
{
int i, class = dev->class >> 8;
- if ((class == PCI_CLASS_PROCESSOR_POWERPC) &&
+ if ((class == PCI_CLASS_PROCESSOR_POWERPC ||
+ class == PCI_CLASS_BRIDGE_OTHER) &&
(dev->hdr_type == PCI_HEADER_TYPE_NORMAL) &&
(dev->bus->parent == NULL)) {
for (i = 0; i < DEVICE_COUNT_RESOURCE; i++) {
--
1.5.6.2.255.gbed62
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply related [flat|nested] 16+ messages in thread
* Re: PCI changes 2.6.26 => 2.6.28
2009-04-23 14:24 ` Gary Thomas
@ 2009-04-23 18:47 ` Kumar Gala
2009-04-23 22:27 ` Gary Thomas
0 siblings, 1 reply; 16+ messages in thread
From: Kumar Gala @ 2009-04-23 18:47 UTC (permalink / raw)
To: Gary Thomas; +Cc: linuxppc-dev
On Apr 23, 2009, at 9:24 AM, Gary Thomas wrote:
> I have found the culprit - in arch/powerpc/kernel/pci_32.c
>
> static void
> fixup_hide_host_resource_fsl(struct pci_dev *dev)
> {
> int i, class = dev->class >> 8;
>
> #if 0
> if ((class == PCI_CLASS_PROCESSOR_POWERPC ||
> class == PCI_CLASS_BRIDGE_OTHER) &&
> #else
> if ((class == PCI_CLASS_PROCESSOR_POWERPC) &&
> #endif
> (dev->hdr_type == PCI_HEADER_TYPE_NORMAL) &&
> (dev->bus->parent == NULL)) {
> for (i = 0; i < DEVICE_COUNT_RESOURCE; i++) {
> dev->resource[i].start = 0;
> dev->resource[i].end = 0;
> dev->resource[i].flags = 0;
> }
> }
> }
> DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_MOTOROLA, PCI_ANY_ID,
> fixup_hide_host_resource_fsl);
> DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_FREESCALE, PCI_ANY_ID,
> fixup_hide_host_resource_fsl);
>
> This function is now (the #if 0 case is in 2.6.28) tossing out
> the memory resources used by the PCI bridge itself. This makes
> everything fall over, at least on my 834x platform.
>
> This change was applied 2008-10-08, but it seems incorrect on the
> 834x.
Its not. The PCI subsystem shouldn't be allocating or seeing the PHBs
resources.
>> Are you using u-boot to boot? If so is the board port public?
>
> My systems use RedBoot (I'm the original author of RedBoot, so one
> would
> expect that). At this moment, the code isn't public, sorry.
Ok. Not sure if RedBoot has a simple memory dump command, but if you
can dump the IMMR registers for PCI (0x8400 - IOS and 0x8500 - PCI1).
(I'm assuming PCI1 is the one you are using). From IOS I wanted the
outbound registers, for PCI1 the inbound ATU registers.
- k
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: PCI changes 2.6.26 => 2.6.28
2009-04-23 18:47 ` Kumar Gala
@ 2009-04-23 22:27 ` Gary Thomas
2009-04-27 13:17 ` Benjamin Herrenschmidt
0 siblings, 1 reply; 16+ messages in thread
From: Gary Thomas @ 2009-04-23 22:27 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
Kumar Gala wrote:
>
> On Apr 23, 2009, at 9:24 AM, Gary Thomas wrote:
>
>> I have found the culprit - in arch/powerpc/kernel/pci_32.c
>>
>> static void
>> fixup_hide_host_resource_fsl(struct pci_dev *dev)
>> {
>> int i, class = dev->class >> 8;
>>
>> #if 0
>> if ((class == PCI_CLASS_PROCESSOR_POWERPC ||
>> class == PCI_CLASS_BRIDGE_OTHER) &&
>> #else
>> if ((class == PCI_CLASS_PROCESSOR_POWERPC) &&
>> #endif
>> (dev->hdr_type == PCI_HEADER_TYPE_NORMAL) &&
>> (dev->bus->parent == NULL)) {
>> for (i = 0; i < DEVICE_COUNT_RESOURCE; i++) {
>> dev->resource[i].start = 0;
>> dev->resource[i].end = 0;
>> dev->resource[i].flags = 0;
>> }
>> }
>> }
>> DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_MOTOROLA, PCI_ANY_ID,
>> fixup_hide_host_resource_fsl);
>> DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_FREESCALE, PCI_ANY_ID,
>> fixup_hide_host_resource_fsl);
>>
>> This function is now (the #if 0 case is in 2.6.28) tossing out
>> the memory resources used by the PCI bridge itself. This makes
>> everything fall over, at least on my 834x platform.
>>
>> This change was applied 2008-10-08, but it seems incorrect on the 834x.
>
> Its not. The PCI subsystem shouldn't be allocating or seeing the PHBs
> resources.
>
>>> Are you using u-boot to boot? If so is the board port public?
>>
>> My systems use RedBoot (I'm the original author of RedBoot, so one would
>> expect that). At this moment, the code isn't public, sorry.
>
> Ok. Not sure if RedBoot has a simple memory dump command, but if you
> can dump the IMMR registers for PCI (0x8400 - IOS and 0x8500 - PCI1).
> (I'm assuming PCI1 is the one you are using). From IOS I wanted the
I don't think any of this matters. It turns out that even
the 2.6.26 kernel fails on an identical board with a newer
revision of the 8347 chip. I'm sure that the problem is
that the Coral-P fails when mapped to 0 (PCI relative).
I couldn't find another reliable way to get the Coral-P assigned
an address other than 0, so I'm happy accepting the work around
of allowing the kernel to map those windows, even if it's not
necessary.
For completeness, here are the values you asked for:
pcilawbar0 : 0xc0000000 -1073741824
pcilawar : 0x8000001b -2147483621
pcilawbar1 : 0xb8000000 -1207959552
pcilawar1 : 0x80000013 -2147483629
8347>md 0xff008400
ff008400 : 00000000 00000000 000c0000 00000000 ................
ff008410 : 800f0000 00000000 00000000 00000000 ................
ff008420 : 000b8000 00000000 c00fff00 00000000 ................
ff008430 : 00000000 00000000 00000000 00000000 ................
ff008440 : 00000000 00000000 00000000 00000000 ................
ff008450 : 00000000 00000000 00000000 00000000 ................
ff008460 : 00000000 00000000 00000000 00000000 ................
ff008470 : 00000000 00000000 00000000 00000000 ................
ff008480 : 00000000 00000000 00000000 00000000 ................
ff008490 : 00000000 00000000 00000000 00000000 ................
ff0084a0 : 00000000 00000000 00000000 00000000 ................
ff0084b0 : 00000000 00000000 00000000 00000000 ................
ff0084c0 : 00000000 00000000 00000000 00000000 ................
ff0084d0 : 00000000 00000000 00000000 00000000 ................
ff0084e0 : 00000000 00000000 00000000 00000000 ................
ff0084f0 : 00000001 00010006 00000000 00000000 ................
8347>md 0xff008500
ff008500 : 00000000 00000000 00000000 00000000 ................
ff008510 : 00000000 00000000 00000000 00000000 ................
ff008520 : 00000001 00000000 00000001 00000000 ................
ff008530 : 00000000 00000000 00000000 00000000 ................
ff008540 : 00000000 00000000 00000000 00000000 ................
ff008550 : 00000000 00000000 00000000 00000000 ................
ff008560 : a005501a 00000000 00000000 00000000 ..P.............
ff008570 : 00000000 00000000 00000000 00000000 ................
ff008580 : 00000000 00000000 00000000 00000000 ................
ff008590 : 00000000 00000000 00000000 00000000 ................
ff0085a0 : 00000000 00000000 00000000 00000000 ................
ff0085b0 : 00000000 00000000 00000000 00000000 ................
ff0085c0 : 00000000 00000000 00000000 00000000 ................
ff0085d0 : 00000000 00000000 00000000 00000000 ................
ff0085e0 : 00000000 00000000 00000000 00000000 ................
ff0085f0 : 00000000 00000000 00000000 00000000 ................
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: PCI changes 2.6.26 => 2.6.28
2009-04-23 22:27 ` Gary Thomas
@ 2009-04-27 13:17 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 16+ messages in thread
From: Benjamin Herrenschmidt @ 2009-04-27 13:17 UTC (permalink / raw)
To: Gary Thomas; +Cc: linuxppc-dev
On Thu, 2009-04-23 at 16:27 -0600, Gary Thomas wrote:
> I don't think any of this matters. It turns out that even
> the 2.6.26 kernel fails on an identical board with a newer
> revision of the 8347 chip. I'm sure that the problem is
> that the Coral-P fails when mapped to 0 (PCI relative).
There are macro that the PCI code uses to define the min address to
assign to devices but it's broken for us as it doesn't account
for the kind of remapping we do... I've been wanting to fix those
for some time but didn't get a chance yet, that would sort this out.
Ben.
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2009-04-27 13:17 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-04-21 16:24 PCI changes 2.6.26 => 2.6.28 Gary Thomas
2009-04-21 20:30 ` Gary Thomas
2009-04-21 20:32 ` Gary Thomas
2009-04-21 20:33 ` Kumar Gala
2009-04-21 20:45 ` Gary Thomas
2009-04-21 22:22 ` Gary Thomas
2009-04-21 22:38 ` Kumar Gala
2009-04-21 22:50 ` Kumar Gala
2009-04-21 23:00 ` Gary Thomas
2009-04-21 23:41 ` Kumar Gala
2009-04-21 23:45 ` Gary Thomas
2009-04-22 3:51 ` Kumar Gala
2009-04-23 14:24 ` Gary Thomas
2009-04-23 18:47 ` Kumar Gala
2009-04-23 22:27 ` Gary Thomas
2009-04-27 13:17 ` Benjamin Herrenschmidt
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).