Submitter | Marc Jones |
---|---|
Date | 2009-09-14 00:46:38 |
Message ID | <534e5dc20909131746s27fdac9bube60b3fec2535d8@mail.gmail.com> |
Download | mbox | patch |
Permalink | /patch/252/ |
State | Accepted |
Headers | show |
Comments
On Sun, Sep 13, 2009 at 06:46:38PM -0600, Marc Jones wrote: > Here is a patch that fixes the cf8 config access. Not complicated like > I initially recalled. Thanks to Ralf for pointing out the bug. > > This needs testing. Anyone? We've got a couple H8DME/fam10 boxes coming this week, so I should be able to test this in a couple days. Will do as soon as we get the hardware. Thanks, Ward.
I am not sure what I was thinking last night. This is really simple... There is no address manipulation to be done before calling the coreboot pci functions. Thanks Patrick.... Marc
On Mon, Sep 14, 2009 at 10:45 AM, Marc Jones <marcj303@gmail.com> wrote: > I am not sure what I was thinking last night. This is really simple... > There is no address manipulation to be done before calling the > coreboot pci functions. Thanks Patrick.... > It looks like GetNB and SetNB should die. Is there a purpose for having the extra indirection? Thanks, Myles
Am Montag, den 14.09.2009, 10:45 -0600 schrieb Marc Jones: > I am not sure what I was thinking last night. This is really simple... > There is no address manipulation to be done before calling the > coreboot pci functions. Thanks Patrick.... The board boots much more reliable now, thank you! Acked-by: Patrick Georgi <patrick.georgi@coresystems.de>
Myles Watson wrote:
> It looks like GetNB and SetNB should die.
+1
//Peter
On Mon, Sep 14, 2009 at 10:52 AM, Peter Stuge <peter@stuge.se> wrote: > Myles Watson wrote: >> It looks like GetNB and SetNB should die. > > +1 I guess it should. The only reason to keep it is for easily diffing against the AMD AGESA reference code, but I am not certain if or when that will happen again. Marc
On Mon, Sep 14, 2009 at 10:50 AM, Patrick Georgi <patrick@georgi-clan.de> wrote: > Am Montag, den 14.09.2009, 10:45 -0600 schrieb Marc Jones: >> I am not sure what I was thinking last night. This is really simple... >> There is no address manipulation to be done before calling the >> coreboot pci functions. Thanks Patrick.... > The board boots much more reliable now, thank you! > > > Acked-by: Patrick Georgi <patrick.georgi@coresystems.de> > > Thanks Patrick. r4633
Are you sure the pci functions will cover the case that the address is
more than 0x100?
Zheng
-----Original Message-----
From: coreboot-bounces@coreboot.org
[mailto:coreboot-bounces@coreboot.org] On Behalf Of Marc Jones
Sent: Tuesday, September 15, 2009 12:45 AM
To: ron minnich
Cc: coreboot@coreboot.org
Subject: Re: [coreboot] unstable AMD Fam10h boot
I am not sure what I was thinking last night. This is really simple...
There is no address manipulation to be done before calling the
coreboot pci functions. Thanks Patrick....
Marc
On Mon, Sep 14, 2009 at 7:51 PM, Bao, Zheng <Zheng.Bao@amd.com> wrote: > Are you sure the pci functions will cover the case that the address is > more than 0x100? It should, unless you know something I don't (bug?). Using the MMIO config access is the preferred method since it enforces the ordering. See 2.11 Configuration Space in the BKDG. Marc
Patch
Use the coreboot pci config read/write functions instead of direct cf8/cfc access. The fam10 pci functions will use mmio and not have SMP pci access issues. Signed-off-by: Marc Jones <marcj303@gmail.com↔ Index: coreboot-v2/src/northbridge/amd/amdmct/mct/mct_d.c =================================================================== --- coreboot-v2.orig/src/northbridge/amd/amdmct/mct/mct_d.c 2009-09-13 18:01:54.000000000 -0600 +++ coreboot-v2/src/northbridge/amd/amdmct/mct/mct_d.c 2009-09-13 18:09:08.000000000 -0600 @@ -2474,10 +2474,8 @@ { u32 addr; - addr = (dev>>4) | (reg & 0xFF) | ((reg & 0xf00)<<16); - outl((1<<31) | (addr & ~3), 0xcf8); - - return inl(0xcfc); + addr = ((dev>>4) | (reg & 0xFF) | ((reg & 0xf00)<<16)) & ~3; + return pci_read_config32(addr); } @@ -2485,9 +2483,8 @@ { u32 addr; - addr = (dev>>4) | (reg & 0xFF) | ((reg & 0xf00)<<16); - outl((1<<31) | (addr & ~3), 0xcf8); - outl(val, 0xcfc); + addr = ((dev>>4) | (reg & 0xFF) | ((reg & 0xf00)<<16)) & ~3; + pci_write_config32(addr); }