There is a Filter to stop booting when the CPUID is not in a list of supported CPUs. This filter does not make sense in the real world usage. For example socket 775: When you enter a working cpu, then it boots. In some cases the coreboot code didnt work with a CPU where it should. For example some Pentium-4 CPUs. Then it crashes even before raminit. But when you add a CPU that "would" work but is not listed in the CPUID lists from coreboot, the machine didnt boot. If you simply add the CPUID to the list everything works fine.
In short: The only thing this CPUID list is doing is blocking functionality and adding work (a list that have to be maintained). Nothing else. If a CPU is not supported, it crashes after 4-5 lines of logfile - even before the raminit. Thats before this CPUID list is been checked.
Please remove those CPUID lists.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/22/2017 05:07 PM, i1w5d7gf38keg@tutanota.com wrote:
There is a Filter to stop booting when the CPUID is not in a list of supported CPUs. This filter does not make sense in the real world usage. For example socket 775: When you enter a working cpu, then it boots. In some cases the coreboot code didnt work with a CPU where it should. For example some Pentium-4 CPUs. Then it crashes even before raminit. But when you add a CPU that "would" work but is not listed in the CPUID lists from coreboot, the machine didnt boot. If you simply add the CPUID to the list everything works fine.
In short: The only thing this CPUID list is doing is blocking functionality and adding work (a list that have to be maintained). Nothing else. If a CPU is not supported, it crashes after 4-5 lines of logfile - even before the raminit. Thats before this CPUID list is been checked.
Please remove those CPUID lists.
I would recommend the lists be retained. Presumably the individual(s) that wrote the CPU / northbridge support code are aware of the CPUs that the code is designed to work with, and using CPUs that were never intended with that code does entail a certain amount of risk. Individuals capable of mitigating this risk / verifying processor functionality are also capable of modifying the CPUID list.
- -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 (direct line) +1 (512) 690-0200 (switchboard) https://www.raptorengineering.com
What is the benefit of such a list? I cant see any benefit. Its only additional work that is useless.
A example for CPUID-List blocking functionality is commit I63d308477a22a9e55ceed1b6b36e63a3044c2354
22. Feb 2017 23:15 by tpearson@raptorengineering.com:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/22/2017 05:07 PM, > i1w5d7gf38keg@tutanota.com> wrote:
There is a Filter to stop booting when the CPUID is not in a list of supported CPUs. This filter does not make sense in the real world usage. For example socket 775: When you enter a working cpu, then it boots. In some cases the coreboot code didnt work with a CPU where it should. For example some Pentium-4 CPUs. Then it crashes even before raminit. But when you add a CPU that "would" work but is not listed in the CPUID lists from coreboot, the machine didnt boot. If you simply add the CPUID to the list everything works fine.
In short: The only thing this CPUID list is doing is blocking functionality and adding work (a list that have to be maintained). Nothing else. If a CPU is not supported, it crashes after 4-5 lines of logfile - even before the raminit. Thats before this CPUID list is been checked.
Please remove those CPUID lists.
I would recommend the lists be retained. Presumably the individual(s) that wrote the CPU / northbridge support code are aware of the CPUs that the code is designed to work with, and using CPUs that were never intended with that code does entail a certain amount of risk. Individuals capable of mitigating this risk / verifying processor functionality are also capable of modifying the CPUID list.
Timothy Pearson Raptor Engineering +1 (415) 727-8645 (direct line) +1 (512) 690-0200 (switchboard) https://www.raptorengineering.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Mozilla - > http://enigmail.mozdev.org
iQEcBAEBAgAGBQJYrht0AAoJEK+E3vEXDOFb/S0H/17w88+kNxBcPm+V+hPkpMDE r6FcyfSO4tm96b/lPgkhK78jxqighQHD7sR2keFWAO+5hwRQfuZwHYVsPa1WmrUN u3J08Mgl5r/xTyoBEp/CRxAGD5FaN+NOYQgBVFh8J6IGLBeYJxcmv/PdQmctvi+J lXuqepsei5TLDIn+9hE3U2Dbh0H/6m8+YFFRbeYbcoNfyuRFE5APks3s+QOjqa4w wBR30fafSBkj4DyGMSzD5yZbOLl/SJDhT1FjvWlx5H4YwKv/vltAPYhq1enaJkRf 61cpl2Prfin4DvpWGU/geTi94bskBo8D8sE1SHumoGXIQ+maICPh/ndtIRNUJIQ= =UsCc -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/22/2017 05:31 PM, i1w5d7gf38keg@tutanota.com wrote:
What is the benefit of such a list? I cant see any benefit. Its only additional work that is useless.
Example: Certain CPUs require special cache handling / setup to avoid unusual faults or security vulnerabilities at runtime. The original setup code properly configures model 1 stepping 1 CPUs, but stepping 2 CPUs require special setup. User installs coreboot and uses it with a stepping 2 CPU without adding in the new setup code -- it seems to run, but crashes every once in a while. User (possibly) figures out coreboot is the problem and is very unhappy.
Again, this is very low level stuff; mistakes do not always show up as "failure to boot". If you want to verify your CPUs and add them to the list please do so!
- -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 (direct line) +1 (512) 690-0200 (switchboard) https://www.raptorengineering.com
On 23.02.2017 00:07, i1w5d7gf38keg@tutanota.com wrote:
There is a Filter to stop booting when the CPUID is not in a list of supported CPUs. This filter does not make sense in the real world usage.
It's not a filter. It's a measure to know which code to run for which CPU. Please dig a little deeper before making such useless complaints.
Nico
On Thu, Feb 23, 2017 at 2:39 AM, Nico Huber nico.h@gmx.de wrote:
On 23.02.2017 00:07, i1w5d7gf38keg@tutanota.com wrote:
There is a Filter to stop booting when the CPUID is not in a list of supported CPUs. This filter does not make sense in the real world usage.
It's not a filter. It's a measure to know which code to run for which CPU. Please dig a little deeper before making such useless complaints.
To add to Nico's point: the cpuid list is a way to bind code code to run for certain devices -- including CPUs. If the cpuid is not listed then the match on device->code to run is not met. Therefore, the code necessary to make that CPU work won't ever be ran. src/arch/x86/cpu.c has the cpu driver binding. And there already is message printed. See the callers of set_cpu_ops() in that file. The issue is that we die() when no match is found. We could attempt to boot further, but there's no guarantee it'd actually succeed.
Nico
-- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
-
Aaron Durbin -
i1w5d7gf38keg＠tutanota.com -
Nico Huber -
Timothy Pearson