aboutsummaryrefslogtreecommitdiff
path: root/src/northbridge/intel/haswell/northbridge.c
AgeCommit message (Collapse)Author
2020-04-10Replace DEVICE_NOOP with noop_(set|read)_resourcesNico Huber
`.read_resources` and `.set_resources` are the only two device operations that are considered mandatory. Other function pointers can be left NULL. Having dedicated no-op implementations for the two mandatory fields should stop the leaking of no-op pointers to other fields. Change-Id: I6469a7568dc24317c95e238749d878e798b0a362 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/40207 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Reviewed-by: Edward O'Callaghan <quasisec@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-04-10Drop unnecessary DEVICE_NOOP entriesNico Huber
Providing an explicit no-op function pointer is only necessary for `.read_resources` and `.set_resources`. All other device-operation pointers are optional and can be NULL. Change-Id: I3d139f7be86180558cabec04b8566873062e33be Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/40206 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Edward O'Callaghan <quasisec@chromium.org> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-04-05src/northbridge: Use SPDX for GPL-2.0-only filesAngel Pons
Done with sed and God Lines. Only done for C-like code for now. Change-Id: Id2cb642baa764fd69543460ba869cd822ab5acad Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/40056 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
2020-04-05Drop explicit NULL initializations from `device_operations`Elyes HAOUAS
Unmentioned fields are initialized with 0 (or NULL) implicitly. Beside that, the struct has grown over the years. There are too many optional fields to list them all. Change-Id: Icb9e14c58153d7c14817bcde148e86e977666e4b Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/40126 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-04-02Trim `.acpi_fill_ssdt_generator` and `.acpi_inject_dsdt_generator`Nico Huber
These two identifiers were always very confusing. We're not filling and injecting generators. We are filling SSDTs and injecting into the DSDT. So drop the `_generator` suffix. Hopefully, this also makes ACPI look a little less scary. Change-Id: I6f0e79632c9c855f38fe24c0186388a25990c44d Signed-off-by: Nico Huber <nico.huber@secunet.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/39977 Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-by: David Guckian Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-03-17src (minus soc and mainboard): Remove copyright noticesPatrick Georgi
They're listed in AUTHORS and often incorrect anyway, for example: - What's a "Copyright $year-present"? - Which incarnation of Google (Inc, LLC, ...) is the current copyright holder? - People sometimes have their editor auto-add themselves to files even though they only deleted stuff - Or they let the editor automatically update the copyright year, because why not? - Who is the copyright holder "The coreboot project Authors"? - Or "Generated Code"? Sidestep all these issues by simply not putting these notices in individual files, let's list all copyright holders in AUTHORS instead and use the git history to deal with the rest. Change-Id: I89b10076e0f4a4b3acd59160fb7abe349b228321 Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/39611 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: David Hendricks <david.hendricks@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-03-15nb/intel/haswell: Tidy up code and commentsAngel Pons
- Reformat some lines of code - Put names to all used MCHBAR registers - Move MCHBAR registers into a separate file, for future expansion - Rewrite several comments - Use C-style comments for consistency - Rewrite some hex constants - Use HOST_BRIDGE instead of PCI_DEV(0, 0, 0) Tested, it does not change the binary of Asrock B85M Pro4. Change-Id: I926289304acb834f9b13cd7902801798f8ee478a Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/38434 Reviewed-by: David Hendricks <david.hendricks@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-12-19src/northbridge: Remove unused <stdlib.h>Elyes HAOUAS
Change-Id: I7a214196b05d3af06c8cd742a6154b0627a0d82f Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/33685 Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-12-12nb/{haswell,i945,sandybridge}: Drop outdated commentElyes HAOUAS
'e7525/northbridge.c' does not exist anymore. Change-Id: I5520760f59a3c6f89afb1360b12bd9763fba562a Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/37653 Reviewed-by: Frans Hendriks <fhendriks@eltan.com> Reviewed-by: Patrick Rudolph <siro@das-labor.org> Reviewed-by: Mimoja <coreboot@mimoja.de> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-08-15cpu/intel: Replace bsp_init_and_start_aps()Kyösti Mälkki
Change-Id: I7176efdd1000789a093a1b4e243b4b150e6bb06f Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/34864 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-03-21{northbridge, soc, southbridge}/intel: Make use of pci_dev_set_subsystem()Subrata Banik
This patch removes local definitions of sub_system function and make use of common function pci_dev_set_subsystem(). Change-Id: I91982597fdf586ab514bec3d8e4d09f2565fe56d Signed-off-by: Subrata Banik <subrata.banik@intel.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/31982 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-by: David Guckian Reviewed-by: Furquan Shaikh <furquan@google.com>
2019-03-20src: Use 'include <string.h>' when appropriateElyes HAOUAS
Drop 'include <string.h>' when it is not used and add it when it is missing. Also extra lines removed, or added just before local includes. Change-Id: Iccac4dbaa2dd4144fc347af36ecfc9747da3de20 Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/31966 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Werner Zeh <werner.zeh@siemens.com> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2019-03-08coreboot: Replace all IS_ENABLED(CONFIG_XXX) with CONFIG(XXX)Julius Werner
This patch is a raw application of find src/ -type f | xargs sed -i -e 's/IS_ENABLED\s*(CONFIG_/CONFIG(/g' Change-Id: I6262d6d5c23cabe23c242b4f38d446b74fe16b88 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/31774 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2019-03-04arch/io.h: Drop unnecessary includeKyösti Mälkki
Change-Id: I91158452680586ac676ea11c8589062880a31f91 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/31692 Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-01-06device: Use pcidev_path_on_root()Kyösti Mälkki
Change-Id: I2e28b9f4ecaf258bff8a062b5a54cb3d8e2bb9b0 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/30400 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2019-01-06device: Use pcidev_on_root()Kyösti Mälkki
Change-Id: Icf34b39d80f6e46d32a39b68f38fb2752c0bcebc Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/26484 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Piotr Król <piotr.krol@3mdeb.com> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2018-12-29nb/intel/haswell: Handle boards that do not support IGDTristan Corrick
Processor graphics is disabled on, for example, the C222 and C224 chipsets. The change to resource assignment in northbridge.c prevents the following warning that occurs when the IGD is disabled: > skipping PCI: 00:00.0@3 fixed resource, size=0! Tested on a Supermicro X10SLM+-F, which has the IGD disabled by the chipset. The graphics memory is reclaimed and no issues were observed. Also tested on an ASRock H81M-HDS. This board has an IGD, but no regressions were observed. Change-Id: I86d4aef50b6588f08b86c9758a4b95ccd65e9a96 Signed-off-by: Tristan Corrick <tristan@corrick.kiwi> Reviewed-on: https://review.coreboot.org/c/30271 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2018-12-29nb/intel/haswell: Use DEVEN to disable devicesTristan Corrick
This allows devices to be properly disabled when they are set to `off` in the devicetree, or when a device has its `enabled` property set to false. A message is printed stating that a device is being disabled, even if it was already disabled via DEVEN. However, it could be useful to have this information, so such messages are kept. The device 00:04.0 is a thermal sensor on the Acer C720, but it has not been named as such in this patch. This is because the public datasheets never formally acknowledge what the device is, and how it might differ across platforms. Tested on a Supermicro X10SLM+-F. The Mini-HD audio is disabled now, silencing a warning from Linux. Also tested on an Acer C720 (Google Peppy). Disabling "device 4" from devicetree.cb works. Also tested on an ASRock H81M-HDS. For this device, and all other test devices, there were no regressions observed. Change-Id: If1504e620967449a09f113a7c771a1ec30380644 Signed-off-by: Tristan Corrick <tristan@corrick.kiwi> Reviewed-on: https://review.coreboot.org/c/30270 Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Patrick Rudolph <siro@das-labor.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2018-12-18nb/intel/haswell: Add server processor host bridge device IDIru Cai
The device ID is documented in "Intel Xeon Processor E3-1200 v3 Product Family Datasheet volume 2" section 2.2. Tested with ASRock H81M-HDS with Xeon E3-1271 v3. SeaBIOS payload can find the boot devices, and GRUB payload can boot Debian GNU/Linux on the SATA disk. Change-Id: I999391c9bbc6b39526ad7aec8a6d8fe1a9b5f921 Signed-off-by: Iru Cai <mytbk920423@gmail.com> Reviewed-on: https://review.coreboot.org/c/30266 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Tristan Corrick <tristan@corrick.kiwi> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2018-11-16src: Remove unneeded include <cbmem.h>Elyes HAOUAS
Change-Id: I89e03b6def5c78415bf73baba55941953a70d8de Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/29302 Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2018-11-12src: Remove unneeded include "{arch,cpu}/cpu.h"Elyes HAOUAS
Change-Id: I17c4fc4e3e2eeef7c720c6a020b37d8f7a0f57a4 Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/29300 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2018-11-02nb/intel/haswell: Consolidate memory controller PCI driver structsTristan Corrick
Since the `PCI_DEVICE_ID_HSW_*` constants are no longer used, remove them. Change-Id: I84f1f069faa6a4165cf289f2e6c40889a49cad1d Signed-off-by: Tristan Corrick <tristan@corrick.kiwi> Reviewed-on: https://review.coreboot.org/29396 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2018-11-01sb/intel/lynxpoint: Automatically generate the ACPI PCI routing tableTristan Corrick
This patch is based on a8a9f34e9b7b ("sb/intel/i82801{g,j}x: Automatically generate ACPI PIRQ tables") Tested on an ASRock H81M-HDS. The generated _PRT object looks correct, and the system doesn't show any issue when running. The following assignments occur: ACPI_PIRQ_GEN: PCI: 00:02.0: pin=0 pirq=0 ACPI_PIRQ_GEN: PCI: 00:03.0: pin=0 pirq=0 ACPI_PIRQ_GEN: PCI: 00:14.0: pin=0 pirq=0 ACPI_PIRQ_GEN: PCI: 00:16.0: pin=0 pirq=0 ACPI_PIRQ_GEN: PCI: 00:1a.0: pin=0 pirq=0 ACPI_PIRQ_GEN: PCI: 00:1b.0: pin=0 pirq=6 ACPI_PIRQ_GEN: PCI: 00:1c.0: pin=0 pirq=0 ACPI_PIRQ_GEN: PCI: 00:1c.1: pin=1 pirq=1 ACPI_PIRQ_GEN: PCI: 00:1c.2: pin=2 pirq=2 ACPI_PIRQ_GEN: PCI: 00:1c.3: pin=3 pirq=3 ACPI_PIRQ_GEN: PCI: 00:1d.0: pin=0 pirq=7 ACPI_PIRQ_GEN: PCI: 00:1f.2: pin=1 pirq=3 ACPI_PIRQ_GEN: PCI: 00:1f.3: pin=2 pirq=2 Also tested on a Google Peppy board. The following assignments occur: ACPI_PIRQ_GEN: PCI: 00:02.0: pin=0 pirq=0 ACPI_PIRQ_GEN: PCI: 00:03.0: pin=0 pirq=0 ACPI_PIRQ_GEN: PCI: 00:14.0: pin=0 pirq=2 ACPI_PIRQ_GEN: PCI: 00:1b.0: pin=0 pirq=6 ACPI_PIRQ_GEN: PCI: 00:1c.0: pin=0 pirq=0 ACPI_PIRQ_GEN: PCI: 00:1d.0: pin=0 pirq=3 ACPI_PIRQ_GEN: PCI: 00:1f.2: pin=0 pirq=6 ACPI_PIRQ_GEN: PCI: 00:1f.3: pin=1 pirq=2 ACPI_PIRQ_GEN: PCI: 00:1f.6: pin=2 pirq=1 A diff of the _PRT object for the Google Peppy board is below. The code used in the diff has been modified for clarity, but the semantics remain the same. To summarise the diff: * The disabled PCIe root ports are no longer included. * The LPC controller is no longer included, as it has no interrupt pin. The pins for the remaining LPC devices are each one less. Perhaps the original _PRT object was incorrect? * The SDIO device is no longer included, as it is disabled. * The Serial IO devices are no longer included, but that is due to a separate issue I am having with this system (the devices don't show up under Linux regardless of this patch). In short: their omission is not a fault of this patch. --- pre/_PRT +++ post/_PRT @@ -1,301 +1,157 @@ Method (_PRT, 0, NotSerialized) // _PRT: PCI Routing Table { If (PICM) { - Return (Package (0x12) + Return (Package (0x09) { Package (0x04) { 0x0002FFFF, Zero, Zero, 0x10 }, Package (0x04) { 0x0003FFFF, Zero, Zero, 0x10 }, Package (0x04) { 0x0014FFFF, Zero, Zero, 0x12 }, Package (0x04) { 0x001BFFFF, Zero, Zero, 0x16 }, Package (0x04) { 0x001CFFFF, Zero, Zero, 0x10 }, - Package (0x04) - { - 0x001CFFFF, - One, - Zero, - 0x11 - }, - - Package (0x04) - { - 0x001CFFFF, - 0x02, - Zero, - 0x12 - }, - - Package (0x04) - { - 0x001CFFFF, - 0x03, - Zero, - 0x13 - }, - Package (0x04) { 0x001DFFFF, Zero, Zero, 0x13 }, Package (0x04) { 0x001FFFFF, Zero, Zero, 0x16 }, Package (0x04) { 0x001FFFFF, One, Zero, 0x12 }, Package (0x04) { 0x001FFFFF, 0x02, Zero, 0x11 - }, - - Package (0x04) - { - 0x001FFFFF, - 0x03, - Zero, - 0x10 - }, - - Package (0x04) - { - 0x0015FFFF, - Zero, - Zero, - 0x14 - }, - - Package (0x04) - { - 0x0015FFFF, - One, - Zero, - 0x15 - }, - - Package (0x04) - { - 0x0015FFFF, - 0x02, - Zero, - 0x15 - }, - - Package (0x04) - { - 0x0015FFFF, - 0x03, - Zero, - 0x15 - }, - - Package (0x04) - { - 0x0017FFFF, - Zero, - Zero, - 0x17 } }) } Else { - Return (Package (0x12) + Return (Package (0x09) { Package (0x04) { 0x0002FFFF, Zero, ^LPCB.LNKA, Zero }, Package (0x04) { 0x0003FFFF, Zero, ^LPCB.LNKA, Zero }, Package (0x04) { 0x0014FFFF, Zero, ^LPCB.LNKC, Zero }, Package (0x04) { 0x001BFFFF, Zero, ^LPCB.LNKG, Zero }, Package (0x04) { 0x001CFFFF, Zero, ^LPCB.LNKA, Zero }, - Package (0x04) - { - 0x001CFFFF, - One, - ^LPCB.LNKB, - Zero - }, - - Package (0x04) - { - 0x001CFFFF, - 0x02, - ^LPCB.LNKC, - Zero - }, - - Package (0x04) - { - 0x001CFFFF, - 0x03, - ^LPCB.LNKD, - Zero - }, - Package (0x04) { 0x001DFFFF, Zero, ^LPCB.LNKD, Zero }, Package (0x04) { 0x001FFFFF, Zero, ^LPCB.LNKG, Zero }, Package (0x04) { 0x001FFFFF, One, ^LPCB.LNKC, Zero }, Package (0x04) { 0x001FFFFF, 0x02, ^LPCB.LNKB, Zero - }, - - Package (0x04) - { - 0x001FFFFF, - 0x03, - ^LPCB.LNKA, - Zero - }, - - Package (0x04) - { - 0x0015FFFF, - Zero, - ^LPCB.LNKE, - Zero - }, - - Package (0x04) - { - 0x0015FFFF, - One, - ^LPCB.LNKF, - Zero - }, - - Package (0x04) - { - 0x0015FFFF, - 0x02, - ^LPCB.LNKF, - Zero - }, - - Package (0x04) - { - 0x0015FFFF, - 0x03, - ^LPCB.LNKF, - Zero - }, - - Package (0x04) - { - 0x0017FFFF, - Zero, - ^LPCB.LNKH, - Zero } }) } } Change-Id: Id3f067cbf7c7d649fbbf774648d8ff928cb752a4 Signed-off-by: Tristan Corrick <tristan@corrick.kiwi> Reviewed-on: https://review.coreboot.org/29381 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2018-11-01nb/intel/haswell: Add a PCI ID for a desktop memory controllerTristan Corrick
The PCI ID was taken from the output of `lspci` on an ASRock H81M-HDS. Change-Id: Ie162cb7a27e313ffe612659e8444657a3772d3c9 Signed-off-by: Tristan Corrick <tristan@corrick.kiwi> Reviewed-on: https://review.coreboot.org/29378 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2018-09-25northbridge: Use 'unsigned int' to bare use of 'unsigned'Elyes HAOUAS
Change-Id: Ib70eb33fac654a773ea39a5fd4206435dffdabb7 Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/28702 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martinroth@google.com>
2018-06-04northbridge/intel: Remove unneeded includesElyes HAOUAS
Change-Id: Id299295784d6fcb04234b085566995bbd8a03d01 Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/26734 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2018-05-18nb/intel/haswell: Get rid of device_tElyes HAOUAS
Use of device_t has been abandoned in ramstage. Change-Id: I10fb736a7406a6571dffce883fb82c2711526762 Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/26196 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Rudolph <siro@das-labor.org>
2018-05-08{mb,nb,soc}: Remove references to pci_bus_default_ops()Nico Huber
pci_bus_default_ops() is the default anyway. Change-Id: I5306d3feea3fc583171d8c865abbe0864b6d9cc6 Signed-off-by: Nico Huber <nico.huber@secunet.com> Reviewed-on: https://review.coreboot.org/26055 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2018-03-08nb/intel/haswell;sb/intel/lynxpoint: Enable VT-d and X2APICMatt DeVillier
We use the usual static addresses 0xfed90000/0xfed91000 for the GFX IOMMU and the general IOMMU respectively. These addresses have to be configured in MCHBAR registers and reserved from the OS. GFXVTBAR/VTVC0BAR policy registers set to be consistent with proprietary vendor firmwares on hardware of same platform (2 different vendor firmwares compared, found to be identical). Change-Id: Ib8f2fed9ae08491779e76f7d1ddc1bd3eed45ac7 Signed-off-by: Matt DeVillier <matt.devillier@gmail.com> Reviewed-on: https://review.coreboot.org/24983 Reviewed-by: Youness Alaoui <snifikino@gmail.com> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2018-03-08nb/intel/haswell: Generate ACPI DMAR tableMatt DeVillier
If the SoC is VT-d capable, write an ACPI DMAR table. The entry for the GFXVTBAR is only generated if the IGD is enabled. Change-Id: Ib354337d47b27d18c3b79b5de3b4fa100b59c8fc Signed-off-by: Matt DeVillier <matt.devillier@gmail.com> Reviewed-on: https://review.coreboot.org/24984 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Youness Alaoui <snifikino@gmail.com>
2017-07-03northbridge/intel/haswell: Fix undefined behaviorRyan Salsamendi
Fix reports found by undefined behavior sanitizer. Left shifting an int where the right operand is >= the width of the type is undefined. Add UL suffix since it's safe for unsigned types. Change-Id: If2d34e4f05494c17bf9b9dec113b8f6863214e56 Signed-off-by: Ryan Salsamendi <rsalsamendi@hotmail.com> Reviewed-on: https://review.coreboot.org/20447 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2017-06-27nb/intel: add IS_ENABLED() around Kconfig symbol referencesMartin Roth
Some of these can be changed from #if to if(), but that will happen in a follow-on commmit. Change-Id: Id5bc8b75b1fa372f31982b8636f1efa4975b61a5 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/20346 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2017-01-06nb/intel/*/northbridge.c: Remove #include <device/hypertransport.h>Arthur Heymans
Nothing from that header is used or even declared since CONFIG_HYPERTRANSPORT_PLUGIN_SUPPORT is not selected on Intel hardware. Change-Id: I9101eb6ffa6664a2ab45bc0b247279c916266537 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/18044 Tested-by: build bot (Jenkins) Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-by: Idwer Vollering <vidwer@gmail.com>
2016-09-12src/northbridge: Improve code formattingElyes HAOUAS
Change-Id: Iffa058d9eb1e96a4d1587dc3f8a1740907ffbb32 Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/16414 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2015-10-31tree: drop last paragraph of GPL copyright headerPatrick Georgi
It encourages users from writing to the FSF without giving an address. Linux also prefers to drop that and their checkpatch.pl (that we imported) looks out for that. This is the result of util/scripts/no-fsf-addresses.sh with no further editing. Change-Id: Ie96faea295fe001911d77dbc51e9a6789558fbd6 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/11888 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2015-05-21Remove address from GPLv2 headersPatrick Georgi
As per discussion with lawyers[tm], it's not a good idea to shorten the license header too much - not for legal reasons but because there are tools that look for them, and giving them a standard pattern simplifies things. However, we got confirmation that we don't have to update every file ever added to coreboot whenever the FSF gets a new lease, but can drop the address instead. util/kconfig is excluded because that's imported code that we may want to synchronize every now and then. $ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, *MA[, ]*02110-1301[, ]*USA:Foundation, Inc.:" {} + $ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin Street, Suite 500, Boston, MA 02110-1335, USA:Foundation, Inc.:" {} + $ find * -type f -exec sed -i "s:Foundation, Inc., 59 Temple Place[-, ]*Suite 330, Boston, MA *02111-1307[, ]*USA:Foundation, Inc.:" {} + $ find * -type f -exec sed -i "s:Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.:Foundation, Inc.:" {} + $ find * -type f -a \! -name \*.patch \ -a \! -name \*_shipped \ -a \! -name LICENSE_GPL \ -a \! -name LGPL.txt \ -a \! -name COPYING \ -a \! -name DISCLAIMER \ -exec sed -i "/Foundation, Inc./ N;s:Foundation, Inc.* USA\.* *:Foundation, Inc. :;s:Foundation, Inc. $:Foundation, Inc.:" {} + Change-Id: Icc968a5a5f3a5df8d32b940f9cdb35350654bef9 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/9233 Tested-by: build bot (Jenkins) Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
2015-03-10ACPI: Get S3 resume state from romstage_handoffKyösti Mälkki
There is nothing platform specific in retrieving S3 resume state from romstage_handoff structure. Boards without EARLY_CBMEM_INIT update acpi_slp_type from ACPI power-management block or scratchpad registers. Change-Id: Ifc3755f891a0810473b3216c1fec8e45908fc1ab Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/8188 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>
2014-11-01northbridge/intel: Use DEVICE_NOOP macro over dummy symbolEdward O'Callaghan
Change-Id: I9aeed70f72d4df260312df6e53379f1741415b65 Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-on: http://review.coreboot.org/7287 Tested-by: build bot (Jenkins) Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
2014-10-11acpi: Remove explicit pointer tracking in per-device ssdt.Vladimir Serbinenko
It's useless and error-prone. Change-Id: Ie385e147d42b05290ab8c3ca193c5c871306f4ac Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com> Reviewed-on: http://review.coreboot.org/7018 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>
2014-09-22haswell: Move to per-device ACPIVladimir Serbinenko
Change-Id: Ic724dcf516d9cb78e89698da603151a32d24e978 Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com> Reviewed-on: http://review.coreboot.org/6814 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>
2014-02-16haswell: backup the default SMM region on resumeAaron Durbin
Haswell CPUs need to use the default SMM region for relocating to the desired SMM location. Back up that memory on resume instead of reserving the default region. This makes the haswell support more forgiving to software which expects PC-compatible memory layouts. Change-Id: I9ae74f1f14fe07ba9a0027260d6e65faa6ea2aed Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/5217 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>
2014-01-15CBMEM intel: Define get_top_of_ram() once per chipsetKyösti Mälkki
Only have one definition of get_top_of_ram() function and compile it using __SIMPLE_DEVICE__ for both romstage and ramstage. Implemented like this on intel/northbridge/gm45 already. This also adds get_top_of_ram() to i945 ramstage. Change-Id: Ia82cf6e47a4c929223ea3d8f233d606e6f5bf2f1 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/3993 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>
2013-12-12haswell: Export functions for CPU family+model and steppingDuncan Laurie
These are needed to enable workarounds/features on specific CPU types and stepping. The older northbridge function and defines from sandybridge/ivybridge are removed. Change-Id: I80370f53590a5caa914ec8cf0095c3177a8b5c89 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/61333 Commit-Queue: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/4355 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-12-07haswell: Misc power management setup and fixesDuncan Laurie
1) fix enable of power aware interrupt routing 2) set BIOS_RESET_CPL to 3 instead of 1 3) mirror PKG power limit values from MSR to MMIO on all SKUs 4) mirror DDR power limit values from MMIO to MSR 5) remove DMI settings that were from snb/ivb as they do not apply to haswell 1) verify power aware interrupt routing is working by looking in /proc/interrupts to see interrupts routed to both cores instead of always to core0 BEFORE: 58: 4943 0 PCI-MSI-edge ahci AFTER: 58: 4766 334 PCI-MSI-edge ahci 2) read back BIOS_RESET_CPL to verify it is == 3 localhost ~ # iotools mmio_read32 0xfed15da8 0x00000003 3) read PKG power limit from MMIO and verify it is the same as the MSR value localhost ~ # rdmsr 0 0x610 0x0000809600dc8078 localhost ~ # iotools mmio_read32 0xfed159a0 0x00dc8078 localhost ~ # iotools mmio_read32 0xfed159a4 0x00008096 4) read DDR power limit from MSR and verify it is the same as the MMIO value (note this is zero based on current MRC input) localhost ~ # rdmsr 0 0x618 0x0000000000000000 localhost ~ # iotools mmio_read32 0xfed158e0 0x00000000 localhost ~ # iotools mmio_read32 0xfed158e4 0x00000000 Change-Id: I6cc4c5b2a81304e9deaad8cffcaf604ebad60b29 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/60544 Reviewed-on: http://review.coreboot.org/4333 Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Tested-by: build bot (Jenkins)
2013-10-15CBMEM: Define cbmem_top() just once for x86Kyösti Mälkki
It is expected this will always be a casted get_top_of_ram() call on x86, no reason to do that under chipset. Change-Id: I3a49abe13ca44bf4ca1e26d1b3baf954bc5a29b7 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/3972 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>
2013-07-10Fix MMCONF_SUPPORT_DEFAULT for ramstageKyösti Mälkki
Define at one place whether to use IO 0xcf8/0xcfc or MMIO via MMCONF_BASE_ADDRESS for PCI configuration access funtions in ramstage. The implementation of pci_default_config() always returned with pci_cf8_conf1. This means any PCI configuration access that did not target bus 0 used PCI IO config operations, if PCI MMIO config was not explicitly requested. Change-Id: I3b04f570fe88d022cd60dde8bb98e76bd00fe612 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/3606 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com> Reviewed-by: Aaron Durbin <adurbin@google.com>
2013-06-03haswell: fix overflow handling TOUUDAaron Durbin
It's possible that the TOUUD can be set to less than 4GiB. When that is the case the size_k variable is an extremely large value. Instead ensure TOUUD is greater than 4GiB before adding said resources. Change-Id: I456633d6210824e60665281538300fd15656b86d Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3352 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-05-01boot: remove cbmem_post_handling()Aaron Durbin
The cbmem_post_handling() function was implemented by 2 chipsets in order to save memory configuration in flash. Convert both of these chipsets to use the boot state machine callbacks to perform the saving of the memory configuration. Change-Id: I697e5c946281b85a71d8533437802d7913135af3 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3137 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-23resources: introduce reserved_ram_resource()Aaron Durbin
mmio_resource() was previously being used for reserving RAM from the OS by using IORESOURCE_IGNORE_MTRR atrribute. Instead, be more explicit for those uses with reserved_ram_resource(). bad_ram_resource() now calls reserved_ram_resource(). Those resources are marked as cacheable but reserved. The sandybridge and haswell code were relying on the implementation fo the MTRR algorithm's interaction for reserved regions. Instead be explicit about what ranges are MMIO reserved and what are RAM reserved. Change-Id: I1e47026970fb37c0305e4d49a12c98b0cdd1abe5 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2886 Tested-by: build bot (Jenkins) Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-22haswell: use dynamic cbmemAaron Durbin
Convert the existing haswell code to support reloctable ramstage to use dynamic cbmem. This patch always selects DYNAMIC_CBMEM as this option is a hard requirement for relocatable ramstage. Aside from converting a few new API calls, a cbmem_top() implementation is added which is defined to be at the begining of the TSEG region. Also, use the dynamic cbmem library for allocating a stack in ram for romstage after CAR is torn down. Utilizing dynamic cbmem does mean that the cmem field in the gnvs chromeos acpi table is now 0. Also, the memconsole driver in the kernel won't be able to find the memconsole because the cbmem structure changed. Change-Id: I7cf98d15b97ad82abacfb36ec37b004ce4605c38 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2850 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-22coreboot: dynamic cbmem requirementAaron Durbin
Dynamic cbmem is now a requirement for relocatable ramstage. This patch replaces the reserve_* fields in the romstage_handoff structure by using the dynamic cbmem library. The haswell code is not moved over in this commit, but it should be safe because there is a hard requirement for DYNAMIC_CBMEM when using a reloctable ramstage. Change-Id: I59ab4552c3ae8c2c3982df458cd81a4a9b712cc2 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2849 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-21haswell: use s3_resume field in romstage_handoffAaron Durbin
Now that there is a way to disseminate the presence of s3 wake more formally use that instead of hard coded pointers in memory and stashing magic values in device registers. The northbridge code picks up the field's presence in the romstage_handoff structure and sets up the acpi_slp_type variable accordingly. Change-Id: Ida786728ce2950bd64610a99b7ad4f1ca6917a99 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2799 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-21haswell: cbmem_get_table_location() implementationAaron Durbin
Provide the implemenation of cbmem_get_table_location() so that cbmem can be initialized early in ramstage when CONFIG_EARLY_CBMEM_INIT is enabled. The cbmem tables are located just below the TSEG region. Change-Id: Ia160ac6aff583fc52bf403d047529aaa07088085 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2798 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-18haswell: fix ACPI MCFG tableAaron Durbin
The acpi_fill_mcfg() was still using ivy/sandy PCI device ids which Hawell obviously doesn't have. This resulted in an empty MCFG table. Instead of relying on PCI device ids use dev/fn 0/0 since that is where the host bridge always resides. Additionally remove the defines for the IB and SB pci device ids. Replace them with mobile and ult Haswel device ids and use those in the pci driver tables for the northbridge code. Booted to Linux and noted that MCFG was properly parsed. Change-Id: Ieaab2dfef0e9daf3edbd8a27efe0825d2beb9443 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2748 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-18haswell: enable caching before SMM initializationAaron Durbin
The SMM handler resides in the TSEG region which is far above CONFIG_RAM_TOP (which is the highest cacheable address) before MTRRs are setup. This means that calling initialize_cpus() before performing MTRR setup on the BSP means the SMM handler is copied using uncacheable accesses. Improve the SMM handler setup path by enabling performing MTRR setup on for the BSP before the call to initialize_cpus(). In order to do this the haswell_init() function was split into 2 paths: BSP & AP paths. There is a cpu_common_init() that both call to perform similar functionality. The BSP path in haswell_init() then starts the APs using intel_cores_init(). The AP path in haswell_init() loads microcode and sets up MTRRs. This split will be leveraged for future support of bringing up APs in parallel as well as adhering to the Haswell MP initialization requirements. Change-Id: Id8e17af149e68d708f3d4765e38b1c61f7ebb470 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2746 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-17haswell: include TSEG region in cacheable memoryAaron Durbin
The SMRR takes precedence over the MTRR entries. Therefore, if the TSEG region is setup as cacheable through the MTTRs, accesses to the TSEG region before SMM relocation are cached. This allows for the setup of SMM relocation to be faster by caching accesses to the future TSEG (SMRAM) memory. MC MAP: TOM: 0x140000000 MC MAP: TOUUD: 0x18f600000 MC MAP: MESEG_BASE: 0x13f000000 MC MAP: MESEG_LIMIT: 0x7fff0fffff MC MAP: REMAP_BASE: 0x13f000000 MC MAP: REMAP_LIMIT: 0x18f5fffff MC MAP: TOLUD: 0xafa00000 MC MAP: BGSM: 0xad800000 MC MAP: BDSM: 0xada00000 MC MAP: TESGMB: 0xad000000 MC MAP: GGC: 0x209 TSEG->BGSM: PCI: 00:00.0 resource base ad000000 size 800000 align 0 gran 0 limit 0 flags f0004200 index 4 BGSM->TOLUD: PCI: 00:00.0 resource base ad800000 size 2200000 align 0 gran 0 limit 0 flags f0000200 index 5 Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB Setting variable MTRR 1, base: 2048MB, range: 512MB, type WB Setting variable MTRR 2, base: 2560MB, range: 256MB, type WB Adding hole at 2776MB-2816MB Setting variable MTRR 3, base: 2776MB, range: 8MB, type UC Setting variable MTRR 4, base: 2784MB, range: 32MB, type UC Zero-sized MTRR range @0KB Allocate an msr - basek = 00400000, sizek = 0023d800, Setting variable MTRR 5, base: 4096MB, range: 2048MB, type WB Setting variable MTRR 6, base: 6144MB, range: 256MB, type WB Adding hole at 6390MB-6400MB Setting variable MTRR 7, base: 6390MB, range: 2MB, type UC MTRR translation from MB to addresses: MTRR 0: 0x00000000 -> 0x80000000 WB MTRR 1: 0x80000000 -> 0xa0000000 WB MTRR 2: 0xa0000000 -> 0xb0000000 WB MTRR 3: 0xad800000 -> 0xae000000 UC MTRR 4: 0xae000000 -> 0xb0000000 UC I'm not a fan of the marking physical address space with MTRRs as being UC which is PCI space, but it is technically correct. Lastly, drop a comment describing AP startup flow through coreboot. Change-Id: Ic63c0377b9c20102fcd3f190052fb32bc5f89182 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2690 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-16haswell: don't add a 0-sized memory range resourceAaron Durbin
It's possible that TOUUD can be 4GiB in a small physical memory configuration. Therefore, don't add a 0-size memory range resouce in that case. Change-Id: I016616a9d9d615417038e9c847c354db7d872819 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2691 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-15haswell: Fix BDSM and BGSM indicies in memory mapAaron Durbin
This wasn't previously spotted because the printk's were correct. However if one needed to get the value of the BDSM or BGSM register the value would reflect the other register's value. Change-Id: Ieec7360a74a65292773b61e14da39fc7d8bfad46 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2689 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-15haswell: reserve default SMRAM spaceAaron Durbin
Currently the OS is free to use the memory located at the default SMRAM space because it is not marked reserved in the e820. This can lead to memory corruption on S3 resume because SMM setup doesn't save this range before using it to relocate SMRAM. Resulting tables: coreboot memory table: 0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES 1. 0000000000001000-000000000002ffff: RAM 2. 0000000000030000-000000000003ffff: RESERVED 3. 0000000000040000-000000000009ffff: RAM 4. 00000000000a0000-00000000000fffff: RESERVED 5. 0000000000100000-0000000000efffff: RAM 6. 0000000000f00000-0000000000ffffff: RESERVED 7. 0000000001000000-00000000acebffff: RAM 8. 00000000acec0000-00000000acffffff: CONFIGURATION TABLES 9. 00000000ad000000-00000000af9fffff: RESERVED 10. 00000000f0000000-00000000f3ffffff: RESERVED 11. 00000000fed10000-00000000fed19fff: RESERVED 12. 00000000fed84000-00000000fed84fff: RESERVED 13. 0000000100000000-000000018f5fffff: RAM e820 map has 13 items: 0: 0000000000000000 - 0000000000030000 = 1 RAM 1: 0000000000030000 - 0000000000040000 = 2 RESERVED 2: 0000000000040000 - 000000000009f400 = 1 RAM 3: 000000000009f400 - 00000000000a0000 = 2 RESERVED 4: 00000000000f0000 - 0000000000100000 = 2 RESERVED 5: 0000000000100000 - 0000000000f00000 = 1 RAM 6: 0000000000f00000 - 0000000001000000 = 2 RESERVED 7: 0000000001000000 - 00000000acec0000 = 1 RAM 8: 00000000acec0000 - 00000000afa00000 = 2 RESERVED 9: 00000000f0000000 - 00000000f4000000 = 2 RESERVED 10: 00000000fed10000 - 00000000fed1a000 = 2 RESERVED 11: 00000000fed84000 - 00000000fed85000 = 2 RESERVED 12: 0000000100000000 - 000000018f600000 = 1 RAM Booted and checked e820 as well as coreboot table information. Change-Id: Ie4985c748b591bf8c0d6a2b59549b698c9ad6cfe Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2688 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-15haswell: resource allocationAaron Durbin
The previous code w.r.t. resource allocation was getting lucky based on the way fixed mmio resources on the system were being chosen. Namely, PCIEXBAR was the lowest mmio space and the other fixed non-standar BARs were above it. The resource allocator would then start allocating standard BARs below that. On top of that other resources were being added when dev_ops->set_resources() was being called on the PCI domain. At that point the PCI range limit were already picked for where to start allocating from. To ensure we no longer get lucky during resource allocation add the fixed resources in the host bridge and add the memory controller cacheable memory areas. With those resources added the range limit for standard PCI BARs is chosen properly. Depending on haswell board configurations we may need to adjust and pass in the size of physical address space needed for PCI resources to the reference code. For the time being the CRBs appear to be OK. Lastly, remove the SNB workaround for reserving 2MiB at 1GiB and 512MiB. Output from 6GiB memory configuration: MC MAP: TOM: 0x140000000 MC MAP: TOUUD: 0x18f600000 MC MAP: MESEG_BASE: 0x13f000000 MC MAP: MESEG_LIMIT: 0x7fff0fffff MC MAP: REMAP_BASE: 0x13f000000 MC MAP: REMAP_LIMIT: 0x18f5fffff MC MAP: TOLUD: 0xafa00000 MC MAP: BDSM: 0xada00000 MC MAP: BGSM: 0xad800000 MC MAP: TESGMB: 0xad000000 MC MAP: GGC: 0x209 coreboot memory table: 0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES 1. 0000000000001000-000000000009ffff: RAM 2. 00000000000a0000-00000000000fffff: RESERVED 3. 0000000000100000-0000000000efffff: RAM 4. 0000000000f00000-0000000000ffffff: RESERVED 5. 0000000001000000-00000000acebffff: RAM 6. 00000000acec0000-00000000acffffff: CONFIGURATION TABLES 7. 00000000ad000000-00000000af9fffff: RESERVED 8. 00000000f0000000-00000000f3ffffff: RESERVED 9. 00000000fed10000-00000000fed17fff: RESERVED 10. 00000000fed18000-00000000fed18fff: RESERVED 11. 00000000fed19000-00000000fed19fff: RESERVED 12. 00000000fed84000-00000000fed84fff: RESERVED 13. 0000000100000000-000000018f5fffff: RAM e820 map has 11 items: 0: 0000000000000000 - 000000000009fc00 = 1 RAM 1: 000000000009fc00 - 00000000000a0000 = 2 RESERVED 2: 00000000000f0000 - 0000000000100000 = 2 RESERVED 3: 0000000000100000 - 0000000000f00000 = 1 RAM 4: 0000000000f00000 - 0000000001000000 = 2 RESERVED 5: 0000000001000000 - 00000000acec0000 = 1 RAM 6: 00000000acec0000 - 00000000afa00000 = 2 RESERVED 7: 00000000f0000000 - 00000000f4000000 = 2 RESERVED 8: 00000000fed10000 - 00000000fed1a000 = 2 RESERVED 9: 00000000fed84000 - 00000000fed85000 = 2 RESERVED 10: 0000000100000000 - 000000018f600000 = 1 RAM Output from 4GiB memory configuration: MC MAP: TOM: 0x100000000 MC MAP: TOUUD: 0x14f600000 MC MAP: MESEG_BASE: 0xff000000 MC MAP: MESEG_LIMIT: 0x7fff0fffff MC MAP: REMAP_BASE: 0x100000000 MC MAP: REMAP_LIMIT: 0x14f5fffff MC MAP: TOLUD: 0xafa00000 MC MAP: BDSM: 0xada00000 MC MAP: BGSM: 0xad800000 MC MAP: TESGMB: 0xad000000 MC MAP: GGC: 0x209 coreboot memory table: 0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES 1. 0000000000001000-000000000009ffff: RAM 2. 00000000000a0000-00000000000fffff: RESERVED 3. 0000000000100000-0000000000efffff: RAM 4. 0000000000f00000-0000000000ffffff: RESERVED 5. 0000000001000000-00000000acebffff: RAM 6. 00000000acec0000-00000000acffffff: CONFIGURATION TABLES 7. 00000000ad000000-00000000af9fffff: RESERVED 8. 00000000f0000000-00000000f3ffffff: RESERVED 9. 00000000fed10000-00000000fed17fff: RESERVED 10. 00000000fed18000-00000000fed18fff: RESERVED 11. 00000000fed19000-00000000fed19fff: RESERVED 12. 00000000fed84000-00000000fed84fff: RESERVED 13. 0000000100000000-000000014f5fffff: RAM e820 map has 11 items: 0: 0000000000000000 - 000000000009fc00 = 1 RAM 1: 000000000009fc00 - 00000000000a0000 = 2 RESERVED 2: 00000000000f0000 - 0000000000100000 = 2 RESERVED 3: 0000000000100000 - 0000000000f00000 = 1 RAM 4: 0000000000f00000 - 0000000001000000 = 2 RESERVED 5: 0000000001000000 - 00000000acec0000 = 1 RAM 6: 00000000acec0000 - 00000000afa00000 = 2 RESERVED 7: 00000000f0000000 - 00000000f4000000 = 2 RESERVED 8: 00000000fed10000 - 00000000fed1a000 = 2 RESERVED 9: 00000000fed84000 - 00000000fed85000 = 2 RESERVED 10: 0000000100000000 - 000000014f600000 = 1 RAM Output from 2GiB memory configuration: MC MAP: TOM: 0x40000000 MC MAP: TOUUD: 0x100600000 MC MAP: MESEG_BASE: 0x3f000000 MC MAP: MESEG_LIMIT: 0x7fff0fffff MC MAP: REMAP_BASE: 0x100000000 MC MAP: REMAP_LIMIT: 0x1005fffff MC MAP: TOLUD: 0x3ea00000 MC MAP: BDSM: 0x3ca00000 MC MAP: BGSM: 0x3c800000 MC MAP: TESGMB: 0x3c000000 MC MAP: GGC: 0x209 coreboot memory table: 0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES 1. 0000000000001000-000000000009ffff: RAM 2. 00000000000a0000-00000000000fffff: RESERVED 3. 0000000000100000-0000000000efffff: RAM 4. 0000000000f00000-0000000000ffffff: RESERVED 5. 0000000001000000-000000003bebffff: RAM 6. 000000003bec0000-000000003bffffff: CONFIGURATION TABLES 7. 000000003c000000-000000003e9fffff: RESERVED 8. 00000000f0000000-00000000f3ffffff: RESERVED 9. 00000000fed10000-00000000fed17fff: RESERVED 10. 00000000fed18000-00000000fed18fff: RESERVED 11. 00000000fed19000-00000000fed19fff: RESERVED 12. 00000000fed84000-00000000fed84fff: RESERVED 13. 0000000100000000-00000001005fffff: RAM e820 map has 11 items: 0: 0000000000000000 - 000000000009fc00 = 1 RAM 1: 000000000009fc00 - 00000000000a0000 = 2 RESERVED 2: 00000000000f0000 - 0000000000100000 = 2 RESERVED 3: 0000000000100000 - 0000000000f00000 = 1 RAM 4: 0000000000f00000 - 0000000001000000 = 2 RESERVED 5: 0000000001000000 - 000000003bec0000 = 1 RAM 6: 000000003bec0000 - 000000003ea00000 = 2 RESERVED 7: 00000000f0000000 - 00000000f4000000 = 2 RESERVED 8: 00000000fed10000 - 00000000fed1a000 = 2 RESERVED 9: 00000000fed84000 - 00000000fed85000 = 2 RESERVED 10: 0000000100000000 - 0000000100600000 = 1 RAM Verified through debug messages that range limits as well as resources were being properly honored. Change-Id: I2faa7d8a2a34a6a411a2885afb3b5c3fa1ad9c23 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2687 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins)
2013-03-14haswell: Add ULT device IDsDuncan Laurie
Device IDs for northbridge and GPU. Also mask off the lock bit in the memory map registers. Change-Id: I9a4955d4541b938285712e82dd0b1696fa272b63 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/2646 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2013-03-14haswell: add PCI id supportAaron Durbin
In order for coreboot to assign resources properly the pci drivers need to have th proper device ids. Add the host controller and the LPC device ids for Lynx Point. Resource assignment works correctly now w/o odd behavior because of conflicts. Change-Id: Id33b3676616fb0c428d84e5fe5c6b8a7cc5fbb62 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2638 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martin.roth@se-eng.com>
2013-03-14haswell: Add initial support for Haswell platformsAaron Durbin
The Haswell parts use a PCH code named Lynx Point (Series 8). Therefore, the southbridge support is included as well. The basis for this code is the Sandybridge code. Management Engine, IRQ routing, and ACPI still requires more attention, but this is a good starting point. This code partially gets up through the romstage just before training memory on a Haswell reference board. Change-Id: If572d6c21ca051b486b82a924ca0ffe05c4d0ad4 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2616 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-17 07:57:52 +0000