Re: [coreboot] Dont filter supported CPUs on a mainboard by the CPUID

[ron minnich]

For those of us working on boards that don't ship in a product, the die()
is probably not appropriate. But  if you intend to ship a real product then
you definitely want to die() if someone tries to use a CPU that's not
tested on the board.

Or at least that's the way it seems to me.

On Fri, Feb 24, 2017 at 7:42 AM Aaron Durbin via coreboot <
[e-mail]> wrote:
> On Fri, Feb 24, 2017 at 5:04 AM,   wrote:
> > Yes, this die() is what i mean. Try to get maybe some functionality is i
> > think better then just stopping there and providing zero functionality.
> >
> > I also know, that there is a message when the CPUID is not known. Its
>
> about
> > the die() afterwards.
>
> Patches always welcome. Did you try removing the die() and seeing if
> things actually booted?
> > Feb 2017 14:31 by [e-mail]:
> >
> > On Thu, Feb 23, 2017 at 2:39 AM, Nico Huber  wrote:
> >
> > On 23.02.2017 00:07, [e-mail] 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