[coreboot] [patch 16/16] Ranges unavailable for PCI BARs shouldbemarked as reserved in the E820 memory map, in case the OS wants to change the BARs.

[Scott Duplichan]

-----Original Message-----
From: coreboot-bounces at coreboot.org [mailto:coreboot-bounces at coreboot.org] On Behalf Of Tobias Diedrich
Sent: Sunday, November 07, 2010 02:33 PM
To: Scott Duplichan
Cc: 'Rudolf Marek'; coreboot at coreboot.org
Subject: Re: [coreboot] [patch 16/16] Ranges unavailable for PCI BARs shouldbemarked as reserved in the E820 memory map,in case the
OS wants to change the BARs.

]Scott Duplichan wrote:
]> From: Tobias Diedrich
]> ]Linux also needs the MMCONF area to be reserved either in E820 or
]> ]as an ACPI motherboard resource or it will not enable MMCONFIG
]> ]and the extended pcie configuration area will be unaccessible:
]> ]
]> ]This patch adds the IORESOURCE_RESERVE flag to the APIC and MMCONF
]> ]resource flags to do this.
]> ]I also added a new resource for the mapped bios rom area just below 4GB.
]> ]I'm not sure if the choice for the index parameter of new_resource()
]> ]is correct though.
]> ]Note that the bios rom decode is enabled in
]> ]src/southbridge/via/vt8237r/vt8237r_early_smbus.c
]> ]for the whole 4MB area (even though the comment says 1MB).
]> 
]> Thank you Tobias. To be even more conservative, the upper 5 MB of the
]> first 4GB can be reserved for flash memory. This is because many LPC
]> flash chips place the jedec ID register of the boot device at address
]> ffbc0000.
]
]I think that probably doesn't apply here, since the LPC flash
]shouldn't get chip-select outside the selected area.
]However src/southbridge/via/vt8237r/bootblock.c (which I had missed
]because I got my board to work without touching this file)
]says its actually 8MB big for VT8237A and VT8237S.

Hello Tobias,

Here is my concern,
1) Coreboot reserves only 4MB (ffc00000-ffffffff).
2) The OS then assigns a PCI memory range that ends at ffbfffff.
3) A bios flash update program is run from the OS. It expands the
   flash decode range if needed then tries to read the flash jedec
   ID at ffbc0000. Both the flash chip and PCI device are set to
   decode ffbc0000. I do not know which device wins. If the flash
   wins and overrides the PCI device, things will be OK unless the
   OS needs to access the PCI device before flashing is complete.
   If the PCI device wins and overrides the flash, then the flash
   update utility will not be able to read the jedec ID.

Thanks,
Scott

]-- 
]Tobias						PGP: http://8ef7ddba.uguu.de