b9fe01c881
Background: The PCI spec (3.0-3.2.2.3.4) requires that PCI devices implement function 0. The Linux Kernel therefore will not enumerate a PCI device if it does not present a valid config space at function 0. If a board does not have anything connected to root port 0 and it is desired to disable the unused ports in order to save power then this will cause the other downstream PCIe devices to go missing as they will not be enumerated. Intel chipsets provide a way to map root port numbers to different PCI function numbers, thereby avoiding this issue and allowing root port 0 to be turned off. This change adds a new chip config option 'pcie_port_coalesce' that will collapse the enabled root ports into a linear map starting at zero. This option defaults to disabled as it can have a confusing effect on the system as the declared static devicetree may not match what is seen at runtime. This option is also forced on if the static devicetree disables port 0. When each root port is processed in the early enable stage it looks for a lower numbered root port that has been disabled and then swaps the two assigned function numbers. However the mapping register is write-once so it has to keep track of the proposed mapping changes until all ports have been processed before writing out the final map value. At this point it also updates the function numbers in the static device tree so they are consistent with the new layout. There are a few other closely related fixes in this change: 1) There is a power savings opportunity if an entire bank of ports (0-3 or 4-7) are disabled. This was checking the chipset revision to look for CougarPoint B1+ stepping and that was not passing on PantherPoint where this should always be applied. To fix this I added a function to determine the chipset type based on comparing the upper byte of the device ID. 2) Apply the same chipset type check fix to the IOBP programming. 3) There is another power savings opportunity to enable dynamic clock gating on shared PCIe resources which only applies to ports 0 and 4. However if 0 or 4 is disabled then the later check to enable this would fail as that device is already hidden. LUMPY current: 00:1c.0 PCI bridge: Intel Corporation Device 1c10 (rev b5) 00:1c.3 PCI bridge: Intel Corporation Device 1c16 (rev b5) 01:00.0 Network controller: Atheros Communications Inc. Device 0030 (rev 01) 02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B LUMPY with PCIe port coalesce enabled: 00:1c.0 PCI bridge: Intel Corporation Device 1c10 (rev b5) 00:1c.1 PCI bridge: Intel Corporation Device 1c16 (rev b5) 01:00.0 Network controller: Atheros Communications Inc. Device 0030 (rev 01) 02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B Change-Id: I828aa407fdc9c156c1c42eda8e2d893c0aa66eef Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/979 Tested-by: build bot (Jenkins) |
||
|---|---|---|
| 3rdparty@1925339dfb | ||
| documentation | ||
| payloads | ||
| src | ||
| util | ||
| .gitignore | ||
| .gitmodules | ||
| COPYING | ||
| Makefile | ||
| Makefile.inc | ||
| README | ||
README
------------------------------------------------------------------------------- coreboot README ------------------------------------------------------------------------------- coreboot is a Free Software project aimed at replacing the proprietary BIOS (firmware) found in most computers. coreboot performs a little bit of hardware initialization and then executes additional boot logic, called a payload. With the separation of hardware initialization and later boot logic, coreboot can scale from specialized applications that run directly firmware, run operating systems in flash, load custom bootloaders, or implement firmware standards, like PC BIOS services or UEFI. This allows for systems to only include the features necessary in the target application, reducing the amount of code and flash space required. coreboot was formerly known as LinuxBIOS. Payloads -------- After the basic initialization of the hardware has been performed, any desired "payload" can be started by coreboot. See http://www.coreboot.org/Payloads for a list of supported payloads. Supported Hardware ------------------ coreboot supports a wide range of chipsets, devices, and mainboards. For details please consult: * http://www.coreboot.org/Supported_Motherboards * http://www.coreboot.org/Supported_Chipsets_and_Devices Build Requirements ------------------ * gcc / g++ * make Optional: * doxygen (for generating/viewing documentation) * iasl (for targets with ACPI support) * gdb (for better debugging facilities on some targets) * ncurses (for 'make menuconfig') * flex and bison (for regenerating parsers) Building coreboot ----------------- Please consult http://www.coreboot.org/Build_HOWTO for details. Testing coreboot Without Modifying Your Hardware ------------------------------------------------ If you want to test coreboot without any risks before you really decide to use it on your hardware, you can use the QEMU system emulator to run coreboot virtually in QEMU. Please see http://www.coreboot.org/QEMU for details. Website and Mailing List ------------------------ Further details on the project, a FAQ, many HOWTOs, news, development guidelines and more can be found on the coreboot website: http://www.coreboot.org You can contact us directly on the coreboot mailing list: http://www.coreboot.org/Mailinglist Copyright and License --------------------- The copyright on coreboot is owned by quite a large number of individual developers and companies. Please check the individual source files for details. coreboot is licensed under the terms of the GNU General Public License (GPL). Some files are licensed under the "GPL (version 2, or any later version)", and some files are licensed under the "GPL, version 2". For some parts, which were derived from other projects, other (GPL-compatible) licenses may apply. Please check the individual source files for details. This makes the resulting coreboot images licensed under the GPL, version 2.