5 comments:
File Documentation/Intel/MultiProcessorInit/MultiProcessorInit.md:
Patch Set #3, Line 7: for Intel 9th Gen (Cannon Lake) and beyond CPUs
This is why you are doing it, but it seems to me that the result […]
i have made this clear why we need to create this API interface in this section.
Although i agree this is very generic implementation and dependent on mp_init.c so going forward we might feel a feed to make it generic, today we can't do because it has some EDK2 header dependencies which is only available for intel UDK2017 platform (CNL onwards).
btw, why you might need to have 2 document, i'm not going to explain how mp_init works on x86 platform, those are already in SDM, this document is to only talk about why we are creating EDK2 interface in coreboot and how intel thinks this can help our partners design.
Patch Set #3, Line 25: closed source in nature
It might be just me, but to me "closed source in nature" sounds like […]
i don;t understand what you mean by can't be trusted ?
Patch Set #3, Line 29: get-rid of such close source
If I understand it correctly (please correct me if not), it only […]
Yes, you are right
It’s also possible for coreboot to extend its own
support model and create a sets of APIs which later can be used by FSP to run CPU feature
programming using coreboot published APIs
I don't understand. coreboot already has such an API […]
i guess you have missed problem statement, you are referring to proposal and try to understand why i have made this proposal.
its clearly mentioned in problem statement why we even need this proposal
Patch Set #3, Line 68: 1. coreboot was using SkipMpInit=1 which will skip entire FSP CPU feature programming.
This is decided per board and not for coreboot in general, AFAICS.
not sure what you mean by coreboot? this is a UPD which is intel fsp specific. not sure how this can be in general ?
To view, visit change 25921. To unsubscribe, or for help writing mail filters, visit settings.