-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/13/2017 01:19 AM, Andrey Petrov wrote: <snip>
For [2] we have been working on prototype for Apollolake that does pre-memory MPinit. We've got to a stage where we can run C code on another core before DRAM is up (please do not try that at home, because you'd need custom experimental ucode).
In addition to the very valid points raised by others on this list, this note in particular is concerning. Whenever we start talking about microcode, we're talking about yet another magic black box that coreboot has no control over and cannot maintain. Adding global functionality that is so system specific in practice as to rely on microcode feature support is not something I ever want to see, unless perhaps the relevant portions of the microcode are open and maintainable by the coreboot project.
In a nutshell, this proposal would make it even harder for any low-level coreboot development on these systems to take place outside of Intel, and as one of the main coreboot contractors this "soft lockdown" is something we are strongly opposed to. Furthermore, I suggest looking at the AMD K8 memory init code -- some basic parallelism was introduced for memory clear, but in the end the improved boot speed was not a "killer feature" and had the side effect of making the code difficult to maintain, leaving the K8 support permanently broken as of this writing.
- -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 (direct line) +1 (512) 690-0200 (switchboard) https://www.raptorengineering.com