Kumar Gala wrote:

quoted

quoted

quoted

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:

quoted

quoted

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
------------------------------------------------------------