This change updates the log level for prints in resource allocator v4
to BIOS_DEBUG instead of BIOS_SPEW. These are critical in debugging
issues and should be enabled at log level BIOS_DEBUG.
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: Ib863619f5e1214e4fe6f05c52be6fa2de36e6c3b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41477
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change adds back CB:39487 which was reverted as part of
CB:41412. Now that the resource allocator is split into old(v3) and
new(v4), this change adds support for allocating resources above 4G
boundary with the new allocator v4.
Original commit message:
This change adds support for allocating resources above the 4G
boundary by making use of memranges for resource windows enabled in
the previous CL.
It adds a new resource flag IORESOURCE_ABOVE_4G which is used in the
following ways:
a) Downstream device resources can set this flag to indicate that they
would like to have their resource allocation above the 4G
boundary. These semantics will have to be enabled in the drivers
managing the devices. It can also be extended to be enabled via
devicetree. This flag is automatically propagated by the resource
allocator from downstream devices to the upstream bridges in pass
1. It is done to ensure that the resource allocator has a global view
of downstream requirements during pass 2 at domain level.
b) Bridges have a single resource window for each of mem and prefmem
resource types. Thus, if any downstream resource of the bridge
requests allocation above 4G boundary, all the other downstream
resources of the same type under the bridge will be allocated above 4G
boundary.
c) During pass 2, resource allocator at domain level splits
IORESOURCE_MEM into two different memory ranges -- one for the window
below 4G and other above 4G. Resource allocation happens separately
for each of these windows.
d) At the bridge level, there is no extra logic required since the
resource will live entirely above or below the 4G boundary. Hence, all
downstream devices of any bridge will fall within the window allocated
to the bridge resource. To handle this case separately from that of
domain, initializing of memranges for a bridge is done differently
than the domain.
Limitation:
Resources of a given type at the bridge or downstream devices
cannot live both above and below 4G boundary. Thus, if a bridge has
some downstream resources requesting allocation for a given type above
4G boundary and other resources of the same type requesting allocation
below 4G boundary, then all these resources of the same type get
allocated above 4G boundary.
Change-Id: I92a5cf7cd1457f2f713e1ffd8ea31796ce3d0cce
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41466
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Addressing comment from CB:41443 that was received after the change
landed. memranges_create_hole() takes size as the last parameter. So,
the I/O hole created at 0x3b0 needs to set size as 0x3df - 0x3b0 + 1
as 0x3df is the upper limit of that hole.
Change-Id: I08fca283436924427e12c6c69edced7e51db42a9
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41737
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
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>
Furquan Shaikh