GNUBoot
/
coreboot-kgpe-d16
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
34,351 Commits 1 Branch 29 Tags 224 MiB
C 90.7%
ASL 5.1%
Makefile 1.1%
Assembly 0.9%
Pawn 0.6%
Other 1.5%
Go to file
Furquan Shaikh f4bc9eb2e6 device: Add support for resource allocator v4 
This change adds back support for the resource allocator using
multiple ranges as originally landed in CB:39486(commit hash 3b02006)
and reverted in CB:41413(commit hash 6186cbc). The new resource
allocator can be selected by Kconfig option RESOURCE_ALLOCATOR_V4. It
was identified that there are some AMD chipsets in the tree that do
not really work well with the dynamic resource allocation. Until these
chipsets are fixed, old (v3) and new (v4) of the resource allocator
need to live side-by-side in the tree. There were some other chipsets
in the tree which originally demonstrated problems with the new
resource allocator, but have been since fixed in the tree.

This change picks up the same additions as performed in CB:39486 along
with the following changes:
1. Changes to avoid fixed resources in the entire tree. Use of
search_bus_resources() is replaced with a walk of the entire tree
in avoid_fixed_resources(). This is required to ensure that all fixed
resources added to any device (including domain) are taken into
consideration to avoid overlap during dynamic resource allocation.
2. Changes to set up alignment for memranges when initializing
them. This is done to ensure that the right granularity is used for
IORESOURCE_IO(no special alignment) and IORESOURCE_MEM(4KiB) resource
requests.
3. mark_resource_invalid() is dropped as the resource no longer needs
to be marked in any special way if allocation is not being
done. Instead setting of IORESOURCE_ASSIGNED flag is skipped in this
case.
4. initialize_memranges() is updated to check IORESOURCE_ASSIGNED
instead of base == limit.

Original commit message:
This change updates the resource allocator in coreboot to allow using
multiple ranges for resource allocation rather than restricting
available window to a single base/limit pair. This is done in
preparation to allow 64-bit resource allocation.

Following changes are made as part of this:
a) Resource allocator still makes 2 passes at the entire tree. The
first pass is to gather the resource requirements of each device
under each domain. It walks recursively in DFS fashion to gather the
requirements of the leaf devices and propagates this back up to the
downstream bridges of the domain. Domain is special in the sense that
it has fixed resource ranges. Hence, the resource requirements from
the downstream devices have no effect on the domain resource
windows. This results in domain resource limits being unmodified after
the first pass.

b) Once the requirements for all the devices under the domain are
gathered, resource allocator walks a second time to allocate resources
to downstream devices as per the requirements. Here, instead of
maintaining a single window for allocating resources, it creates a
list of memranges starting with the resource window at domain and then
applying constraints to create holes for any fixed resources. This
ensures that there is no overlap with fixed resources under the
domain.

c) Domain does not differentiate between mem and prefmem. Since they
are allocated space from the same resource window at the domain level,
it considers all resource requests from downstream devices of the
domain independent of the prefetch type.

d) Once resource allocation is done at the domain level, resource
allocator walks down the downstream bridges and continues the same
process until it reaches the leaves. Bridges have separate windows for
mem and prefmem. Hence, unlike domain, the resource allocator at
bridge level ensures that downstream requirements are satisfied by
taking prefetch type into consideration.

e) This whole 2-pass process is performed for every domain in the
system under the assumption that domains do not have overlapping
address spaces.

Noticeable differences from previous resource allocator:
a) Changes in print logs observed due to flows being slightly
different.
b) Base, limit and size of domain resources are no longer updated
based on downstream requirements.
c) Memranges are used instead of a single base/limit pair for
determining resource allocation.
d) Previously, if a resource request did not fit in the available
base/limit window, then the resource would be allocated over DRAM or
any other address space defeating the principle of "no overlap". With
this change, any time a resource cannot fit in the available ranges,
it complains and ensures that the resource is effectively disabled by
setting base same as the limit.
e) Resource allocator no longer looks at multiple links to determine
the right bus for a resource. None of the current boards have multiple
buses under any downstream device of the domain. The only device with
multiple links seems to be the cpu cluster device for some AMD
platforms.

Change-Id: Ide4d98528197bb03850a8fb4d73c41cd2c0195aa
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41443
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
 		2020-05-26 15:17:29 +00:00
3rdparty Update vboot submodule to upstream master (commit hash c531000) 2020-05-26 15:07:52 +00:00
Documentation Documentation/acpi: Fix the path to variants/hatch/overridetree.cb 2020-05-26 14:58:35 +00:00
LICENSES drivers: Use SPDX identifiers 2020-05-25 22:19:21 +00:00
configs mb/dell/optiplex_9010: Add Dell OptiPlex 9010 SFF support 2020-05-16 17:38:46 +00:00
payloads libpayload/cbgfx: Remove gap between adjacent boxes 2020-05-26 15:03:59 +00:00
src device: Add support for resource allocator v4 2020-05-26 15:17:29 +00:00
tests tests: Add region-test for rdev API 2020-05-19 03:22:04 +00:00
util drivers: Use SPDX identifiers 2020-05-25 22:19:21 +00:00
.checkpatch.conf
…
.clang-format
…
.editorconfig Add .editorconfig file 2019-09-10 12:52:18 +00:00
.gitignore cbfstool: Build vboot library 2020-03-23 08:34:23 +00:00
.gitmodules submodules: Add 3rdparty/amd_blobs 2019-10-31 12:28:38 +00:00
.gitreview
…
AUTHORS AUTHORS, util/: Drop individual copyright notices 2020-05-09 21:21:32 +00:00
COPYING
…
MAINTAINERS MAINTAINERS: Add entry for mb/ocp/tiogapass 2020-05-11 08:34:49 +00:00
Makefile Makefile: Use SPDX identifier 2020-05-23 21:03:17 +00:00
Makefile.inc make: Add a target and dependency to parse the devicetree with sconfig 2020-05-22 01:50:11 +00:00
README.md README.md: Remove link to deprecated wiki 2019-11-16 20:39:55 +00:00
gnat.adc treewide: Remove "this file is part of" lines 2020-05-11 17:11:40 +00:00
toolchain.inc Remove MAYBE_STATIC_BSS and ENV_STAGE_HAS_BSS_SECTION 2020-05-26 15:04:08 +00:00

README.md

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 https://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:

Build Requirements

  • make
  • gcc / g++ Because Linux distribution compilers tend to use lots of patches. coreboot does lots of "unusual" things in its build system, some of which break due to those patches, sometimes by gcc aborting, sometimes - and that's worse - by generating broken object code. Two options: use our toolchain (eg. make crosstools-i386) or enable the ANY_TOOLCHAIN Kconfig option if you're feeling lucky (no support in this case).
  • iasl (for targets with ACPI support)
  • pkg-config
  • libssl-dev (openssl)

Optional:

  • doxygen (for generating/viewing documentation)
  • gdb (for better debugging facilities on some targets)
  • ncurses (for make menuconfig and make nconfig)
  • flex and bison (for regenerating parsers)

Building coreboot

Please consult https://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 https://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:

https://www.coreboot.org

You can contact us directly on the coreboot mailing list:

https://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.