Hi Nico,
Concept of multiple host bridges was partially implemented in PoC
project for upcomming SoC when I joined this project some time ago.
There were many issues (maybe because an early, prototype
implementation/incompatibility with previous v3 resource alocator)
mainly in resource alloc
Hi Arthur,
In our multidomin based PoC in this situation (multiple root busses on
one stack) we "virtually" splitted this stack and its resource window to
two or more virtual stacks and later handled as separate stacks.
Mariusz
W dniu 17.03.2022 o 19:03, Arthur Heymans pisze:
Hi
I've recen
> -Original Message-
> From: Nico Huber
> Sent: Tuesday, March 22, 2022 7:21 AM
> To: coreb...@akumat.pl; coreboot@coreboot.org
> Subject: [coreboot] Re: Multi domain PCI resource allocation: How to deal
> with multiple root busses on one domain
>
> Caution: T
>
>
> So it can be handled as you proposed in CB:59395 or we can define weak
> function e.g. get_max_subordinate(int current) which return 0xff by
> default and can be overriden in soc code to return real allowed max
> subordinate no.
>
> int __weak get_max_subordinate(int current) { return 0xff;};
W dniu 22.03.2022 o 12:38, Arthur Heymans pisze:
sidenote: it also looks like the hardware really does not like to have
PCI bridges on a IIO stack set a subordinate
value larger than the IIO stack 'MaxBus' (basically a stack-level
subordinate bus?). So scanning PCI busses needs some care.
See h
any
MMIO resources for internal registers. When more register space is needed,
they will be in MMCFG space.
From: Lance Zhao
Sent: Friday, March 18, 2022 12:06 AM
To: Nico Huber
Cc: Arthur Heymans ; coreboot
Subject: [coreboot] Re: Multi domain PCI resource allocation: How to deal with
Hi
Hi
>
>
>> e.g. if we got from HOB info that physical stack x has preallocated PCI
>> buses 0x20..0x2f, io form 0x2000..0x2fff, mem 0xd000..0xdfff, mem
>> 0x100...0x1ff and there are 2 root buses 0x20 and 0x28
>> instead of adding one domain with "physical" stack we added
On 22.03.22 12:01, Mariusz Szafrański via coreboot wrote:
>> At some point of time I was thinking about something called
>> "subdomains" concept to cover this multiple root buses in one
>> domain case so to make something like:
>>
>> domain 0 //domain
>> domain 1 //
On 22.03.22 09:57, Mariusz Szafrański via coreboot wrote:
> e.g. if we got from HOB info that physical stack x has preallocated PCI
> buses 0x20..0x2f, io form 0x2000..0x2fff, mem 0xd000..0xdfff,
> mem 0x100...0x1ff and there are 2 root buses 0x20 and
> 0x28 instead of addin
Hi
W dniu 22.03.2022 o 10:30, Arthur Heymans pisze:
Hi
e.g. if we got from HOB info that physical stack x has
preallocated PCI buses 0x20..0x2f, io form 0x2000..0x2fff, mem
0xd000..0xdfff, mem 0x100...0x1ff and
there are 2 root buses 0x20 and 0x28 instead
On 22.03.22 10:30, Arthur Heymans wrote:
> OTOH, does it even make sense to map this in the devicetree? The way FSP
> reports stacks is generated at runtime and differs depending on the
> hardware configuration.
> So having a static structure mapping that may not be interesting?
IMO, a static devi
Hi
> e.g. if we got from HOB info that physical stack x has preallocated PCI
> buses 0x20..0x2f, io form 0x2000..0x2fff, mem 0xd000..0xdfff, mem
> 0x100...0x1ff and there are 2 root buses 0x20 and 0x28
> instead of adding one domain with "physical" stack we added two domai
Hi Artur,
Multiple PCI root bus per domain gives us more control about resource
allocation for downstream devices from poll preallocated by FSP to stack
but adds this link_list->next looping complexity (maybe not much deal to
handle that as you stated). Additional work will be needed for
stat
Hi Mariusz
I was inspired by the multi domain approach doc and got quite far already.
I decided to allocate and attach domains at runtime for the moment
instead of statically via the devicetree. In the future I think having
devicetree structures makes a lot of sense, e.g. to provide stack specific
Hi Nico,
Concept of multiple host bridges was partially implemented in PoC
project for upcomming SoC when I joined this project some time ago.
There were many issues (maybe because an early, prototype
implementation/incompatibility with previous v3 resource alocator)
mainly in resource alloc
Hi Arthur,
In our multidomain based PoC in this situation (multiple root busses on
one stack) we "virtually" splitted this stack and its resource window to
two or more virtual stacks and later handled as separate stacks.
Mariusz
W dniu 17.03.2022 o 19:03, Arthur Heymans pisze:
Hi
I've rece
https://review.coreboot.org/c/coreboot/+/51180 not exactly but similar
one ;-)
Mariusz
W dniu 21.03.2022 o 21:35, Arthur Heymans pisze:
Hi all
Thanks a lot for the input.
I looked a bit further into this and it looks like only the resource
allocation parts assumes one downstream bus under l
Hi all
Thanks a lot for the input.
I looked a bit further into this and it looks like only the resource
allocation parts assumes one downstream bus under link_list.
The rest of coreboot seems to properly account for sibling busses, so maybe
making the allocator loop over ->next in busses is
not s
Hi Lance,
On 18.03.22 05:06, Lance Zhao wrote:
> Stack idea is from
> https://www.intel.com/content/www/us/en/developer/articles/technical/utilizing-the-intel-xeon-processor-scalable-family-iio-performance-monitoring-events.html
thank you very much! The diagrams are enlightening. I always assumed
Stack idea is from
https://www.intel.com/content/www/us/en/developer/articles/technical/utilizing-the-intel-xeon-processor-scalable-family-iio-performance-monitoring-events.html
.
In linux, sometimes domain is same as "segment", I am not sure current
coreboot on xeon_sp already cover the case of m
Hi Arthur,
On 17.03.22 19:03, Arthur Heymans wrote:
> Now my question is the following:
> On some Stacks there are multiple root busses, but the resources need to be
> allocated on the same window. My initial idea was to add those root busses
> as separate struct bus in the domain->link_list. Howe
How about this option? Instead of one (coreboot) PCIe domain per (Xeon-SP) PCIe
stack, we do one (coreboot) PCIe domain per root bus assignment. Regarding
resource windows, we could adjust the remaining windows after assignment for a
PCIe domain is completed.
Jonathan
From: Arthur Heymans
Dat
22 matches
Mail list logo
