On 03.05.2017 09:28, Zoran Stojsavljevic wrote:
The reason we want to prioritize the ME vs. the FSP, is because a lot
more people were interested in getting rid of the ME,
so it is a higher priority, *but the FSP is also going to be reversed
eventually and coreboot deblobbed entirely*.
This is very serious claim, Youness. In FSP you do have much more than ONLY MRC (actually, several MRC algorithms, a bunch tied/bundled together, depending upon what the initial DRAM SPD discovery mechanism is, my best guess). You do have BSP CPU init, then APP CPU(s) init(s), and then PCH init as well, on the system registry level. There is also platform init phase in there, the very minimal one. Also I throw-in PCIe discovery algorithm. Serious stuff.
Serious stuff, sure. But it has been done before (without anyone being payed for it, FWIW). And compared to the ME firmware we know what it has to do _and_ don't have to hack into anything to get our code run- ning.
If you ask me, I would keep up with disabling ME on application level (since ME FW booting is A MUST, as my best understanding of ME FW stands for now). In other words, if I guessed correctly, to make newest ME 11.x engine, based on x86 HW (quark most likely), to run idler process all the time, if Dmitry is correct, and we have MINIX3 micro-kernel running on the top of quark there.
Divide and Conquer, the evergreen idiom: first to take ME, FSP should come after (they can be well divided)... ;-)
Why ME first? What is a free ME good for if you don't control the main (um, how to call it if both are x86?) processor?
Nico
Serious stuff, sure. But it has been done before (without anyone being payed for it, FWIW). And compared to the ME firmware we know what it has to do _and_ don't have to hack into anything to get our code running.
I would not say so. I know about the history, and I know a bit about IVB and BYT GOOGLE orthogonal connections to CCG. Well... INTEL cut these ties, and now, again, Coreboot is back these days to FSP binary blobs (even more complex as before, but, seems, there is a better chance to reverse engineer some parts of it), and similar "venues".
Why ME first? What is a free ME good for if you don't control the main (um, how to call it if both are x86?) processor?
On another hand, I should/will agree with you that this, what you have presented/proposed here, sounds like a plan. Yes, it will be nice to have all FSP as (open) source code. But I would not run away from/postpone disabling/neutralising ME after ME is up and running, just to have it excluded from the up and running system equation.
The complete exclusion, I am afraid, at this point in time, is not possible (since ME plays core part in bringing up the whole system, especially in early boot, before even BIOS/FSP starts running). To be more specific, up to establishing HECI interface.
Anyway, I am learning more, diving deeper in, as we speak. In both directions: [1] BIOS PEI phase, [2] ME boot up. Long way to go. As I estimate now the effort. I guess! :-)
Zoran
On Wed, May 3, 2017 at 9:56 PM, Nico Huber nico.h@gmx.de wrote:
On 03.05.2017 09:28, Zoran Stojsavljevic wrote:
The reason we want to prioritize the ME vs. the FSP, is because a lot
more people were interested in getting rid of the ME,
so it is a higher priority, *but the FSP is also going to be reversed
eventually and coreboot deblobbed entirely*.
This is very serious claim, Youness. In FSP you do have much more than
ONLY
MRC (actually, several MRC algorithms, a bunch tied/bundled together, depending upon what the initial DRAM SPD discovery mechanism is, my best guess). You do have BSP CPU init, then APP CPU(s) init(s), and then PCH init as well, on the system registry level. There is also platform init phase in there, the very minimal one. Also I throw-in PCIe discovery algorithm. Serious stuff.
Serious stuff, sure. But it has been done before (without anyone being payed for it, FWIW). And compared to the ME firmware we know what it has to do _and_ don't have to hack into anything to get our code run- ning.
If you ask me, I would keep up with disabling ME on application level (since ME FW booting is A MUST, as my best understanding of ME FW stands for now). In other words, if I guessed correctly, to make newest ME 11.x engine, based on x86 HW (quark most likely), to run idler process all the time, if Dmitry is correct, and we have MINIX3 micro-kernel running on
the
top of quark there.
Divide and Conquer, the evergreen idiom: first to take ME, FSP should
come
after (they can be well divided)... ;-)
Why ME first? What is a free ME good for if you don't control the main (um, how to call it if both are x86?) processor?
Nico
-
Nico Huber -
Zoran Stojsavljevic