[coreboot] [PATCH] AMD MMCONF Support

Arne Georg Gleditsch arne.gleditsch at numascale.com
Mon Sep 13 14:36:36 CEST 2010

Arne Georg Gleditsch <arne.gleditsch at numascale.com> writes:
>> -	RES_PCI_IO, PCI_ADDR(0, 1, 0, 0x78), 0xC0FFFFFF, 0x19000000,
>> +	/* The following operation hangs when performed via MMCFG:
>> +	     pci_read_config32(romcc): 00010000:0078: 20040000
>> +	     setup_resource_map_x_offset: 10000, 78: 20040000
>> +	     pci_write_config32(romcc): 00010000:0078: 19040000
>> +	     (hang)
>> +	   Response missing? */
>> +	/* RES_PCI_IO, PCI_ADDR(0, 1, 0, 0x78), 0xC0FFFFFF, 0x19000000, */
>> I forgot to ask if you'd tried setting the SyncOnWdError bit (20) in
>> function 3, register 0x44.  That could help further debug this
>> problem.  For me it caused a reboot instead of a hang when there was a
>> response missing.  Bit 21 could also be helpful.
> I can have a look.  I won't get a chance until Monday, though.

Ah, I've just stumbled across something.
src/mainboard/tyan/s2912_fam10/romstage.c:sio_setup does: 

  byte = pci_read_config8(PCI_DEV(0, MCP55_DEVN_BASE+1 , 0), 0x7b);
  byte |= 0x20;
  pci_write_config8(PCI_DEV(0, MCP55_DEVN_BASE+1 , 0), 0x7b, byte);

It appears that the offending RES_PCI_IO line is not so much hanging the
system as disabling the serial console.  Furthermore, the reason this
does not happen when using pio-based config space accesses seems to be
that several functions, for instance precisely sio_setup, are using
pci_read/write_config before init_cpus has run and thus begore the
MMCONF BAR is set up.  This means these accesses are effectively ignored
when MMCONF is enabled.  Some of these are apparently required for the
RES_PCI_IO in question to be set without affecting the serial output.

Rather than hunt around and try to change all config accesses that might
run before init_cpus to explicit pio-accesses, I've moved the BAR init
to run as early as possible, in cache_as_ram.  With this change, I can
re-insert the RES_PCI_IO wihtout ill effects.

> We could fall back to that, if we want to keep it.  FWIW, Ed Swierk had
> some input on the semantics of this register the last time this came up:
> http://thread.gmane.org/gmane.linux.bios/57708/focus=59900

(The correct link to Ed's post is


More information about the coreboot mailing list