On Thu, Jun 16, 2005 at 08:55:49PM -0700, YhLu wrote:
It hang somewhere before ending "reading resources",
what could cause that?
Allocating resources... Reading resources... PCI: 01:1d.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 2 prefmem PCI: 01:1f.0 1c <- [0x000000f000 - 0x000000efff] bus 3 io PCI: 01:1f.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 3 prefmem PCI: 01:1f.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 3 mem PCI: 00:02.0 24 <- [0x00fff00000 - 0x00ffefffff] bus 1 prefmem PCI: 00:1e.0 24 <- [0x00fff00000 - 0x00ffefffff] bus 4 prefmem
I've seen this with the EPIA-M work (which is still ongoing; Adam's been testing bits and I've been trying to understand the chip and waiting impatiently for my programmer to turn up).
We solved it by changing pci_moving_config32.
The current in-tree version reads the value, sets the reg to all 1s, reads the value, sets the reg to all 0s, reads the value, restores the regs to the original value and works out the mask by XORing the bits.
However from my reading of the PCI spec (v2.2) it just says to set the BAR to all 1s, read the value and work out the bits at the bottom you can ignore from whether it's an IO or MEM resource. I don't know if the writing all 0s is the problem or not though; presumably it works everywhere else or the tree wouldn't currently do that.
J.