v2 and v3 pci differences

[Myles Watson]

Here are the major differences between v2 and v3 initializing serengeti
cheetah.  The biggest problem is that the memory-mapped I/O ends up in the
wrong place (see the Display controller's ROM address)

I'll look at it more later, but if someone beats me to it I won't complain
:)

Thanks,
Myles

0    6    0     AMD-8111 PCI
v3 sets parity error response, v2 doesn't
v2 has FD00FC00 for IO Base/LIM v3 has 01000000

1    4    0    Display Controller
v3 sets parity error response, v2 doesn't
v3 sets SERR# Enable, v2 doesn't

v2 has FC000000 and FD053000 for base and lim
v3 has 00000000 and 01055000
v2 has FD040001 v3 has 01040001 for ROM address

0    24    0     K8 [Athlon64/Opteron] HyperTransport Technology
Configuration

v2 thinks nodeID is 1 in 0x60
v3 doesn't enable the second processor in 0x68
v2 sets a reserved bit in 0x6c

0    24    1     K8 [Athlon64/Opteron] Address Map

base and limits messed up in v3 using 0x012000 instead of 0x0fc000

in v2 base smaller than limit! 0xb8 & 0xbc

in v3 limit 0xdc is 0x02020 v2 has 0x000.

0    24    2     K8 [Athlon64/Opteron] DRAM Controller

reserved bits differ in 0x88
v2 sets reserved bit 12 in 0x94

0    24    3     K8 [Athlon64/Opteron] Miscellaneous Control

0x44 v2 sets bits 6, 25,27 27 is NB MCA to CPU 0 enable

0x80 & 0x84 power management totally different

0x90 & 0x94 v2 sets up the GART aperture, v3 doesn't

0xd4 & 0xd8 clock power & timing registers different.

[ron minnich]

On Thu, Oct 9, 2008 at 1:58 PM, Myles Watson  wrote:
> Here are the major differences between v2 and v3 initializing serengeti
> cheetah.  The biggest problem is that the memory-mapped I/O ends up in the
> wrong place (see the Display controller's ROM address)

This one is easy:

if ((dev->on_mainboard) && (dev->rom_address == 0)) {
                // Skip it if rom_address is not set in MB Config.lb.
                // TODO: No more Config.lb in coreboot-v3.
                return;
        }

we have not done it yet.

If anybody wants to get to this before I do, the help is appreciated.
I think it needs a dtc fix.

i.e. in a dts for a part,
rom_address = "fff00000";
and the dtc needs to know this is one of the special properties in the
device struct.

ron

[Myles Watson]

> -----Original Message-----
> From: ron minnich [mailto:[e-mail]]
> Sent: Thursday, October 09, 2008 4:54 PM
> To: Myles Watson
> Cc: Coreboot
> Subject: Re: v2 and v3 pci differences
>
> On Thu, Oct 9, 2008 at 1:58 PM, Myles Watson  wrote:
> > Here are the major differences between v2 and v3 initializing serengeti
> > cheetah.  The biggest problem is that the memory-mapped I/O ends up in
>
> the
> > wrong place (see the Display controller's ROM address)
>
> This one is easy:
>   if ((dev->on_mainboard) && (dev->rom_address == 0)) {
>             // Skip it if rom_address is not set in MB Config.lb.
>             // TODO: No more Config.lb in coreboot-v3.
>             return;
>     }
>
>
>
> we have not done it yet.
>
> If anybody wants to get to this before I do, the help is appreciated.
> I think it needs a dtc fix.
>
> i.e. in a dts for a part,
> rom_address = "fff00000";
> and the dtc needs to know this is one of the special properties in the
> device struct.

I agree that needs to be done, but in this case the VGA card is not onboard.
I think the I/O mapping is wrong, which makes it so that when the signature
gets read it comes back 0xffff instead of 0xa5a5.

Thanks,
Myles

[ron minnich]

On Thu, Oct 9, 2008 at 5:01 PM, Myles Watson  wrote:
> >   if ((dev->on_mainboard) && (dev->rom_address == 0)) {
> >             // Skip it if rom_address is not set in MB Config.lb.
> >             // TODO: No more Config.lb in coreboot-v3.
> >             return;
> >     }
> I agree that needs to be done, but in this case the VGA card is not onboard.
> I think the I/O mapping is wrong, which makes it so that when the signature
> gets read it comes back 0xffff instead of 0xa5a5.

I think you are right, I will look again.

ron