[LinuxBIOS] S2735 tree is totall broken

Jonathan McDowell noodles at earth.li
Fri Jun 17 18:42:17 CEST 2005

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.


I am Pentium of Borg.  Division is Futile.  You will be approximated.
This .sig brought to you by the letter F and the number 30
Product of the Republic of HuggieTag

More information about the coreboot mailing list