>
> cp -p ../../gcc-11.2.0/gcc/ada/sinfo.ads
> ../../gcc-11.2.0/gcc/ada/sinfo.adb ../../gcc-11.2.0/gcc/ada/xsinfo.adb
> ../../gcc-11.2.0/gcc/ada/csinfo.adb ada/bldtools/sinfo
> make[2]: cp: Permission denied
> make[2]: *** [../../gcc-11.2.0/gcc/ada/Make-generated.in:44:
> ada/sinfo.h] Error 127
>
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
Le 2022-03-14 21:40, Karl Semich a écrit :
Hi I'm new to coreboot and visiting briefly, I'm replying to this
error because it looks like a systems error rather than a coreboot
error, at first glance.
"permission denied" during any build of anything is usually from
accidentally running part of
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.
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
Hi
I've recently tried to improve the soc/intel/xeon_sp codebase.
I want to make it use more native coreboot structures and codeflows instead
of parsing the FSP HOB again and again to do things. Ideally the HOB is
parsed only once in ramstage, parsed into adequate native coreboot
structures
6 matches
Mail list logo
