Re: [coreboot] [v2] r4745 - in trunk/coreboot-v2/src/cpu/intel: socket_PGA370 socket_mPGA479M socket_mPGA604

[Stefan Reinauer]

[e-mail] wrote:
> Author: rminnich
> Date: 2009-10-08 18:06:09 +0200 (Thu, 08 Oct 2009)
> New Revision: 4745
>
> Modified:
>    trunk/coreboot-v2/src/cpu/intel/socket_PGA370/Kconfig
>    trunk/coreboot-v2/src/cpu/intel/socket_mPGA479M/Kconfig
>    trunk/coreboot-v2/src/cpu/intel/socket_mPGA604/Kconfig
> Log:
> Set MMX and SSE where needed. Note that many boards don't even bother
> with this as many boards (AMD in particular) use CAR.
>
> This list determined by a series of greps etc. on mainboards, no humans
> were harmed in the making of this list.
>
> Signed-off-by: Ronald G. Minnich
>
> Acked-by: Peter Stuge

Isn't MMX or SSE something attached to a given CPU rather than a socket?

I see the correctness of our CPU model being compromised here..
> Modified: trunk/coreboot-v2/src/cpu/intel/socket_PGA370/Kconfig
>
> --- trunk/coreboot-v2/src/cpu/intel/socket_PGA370/Kconfig	2009-10-08 15:12:31 UTC (rev 4744)
> +++ trunk/coreboot-v2/src/cpu/intel/socket_PGA370/Kconfig	2009-10-08 16:06:09 UTC (rev 4745)
> @@ -21,3 +21,4 @@
>  config CPU_INTEL_SOCKET_PGA370
>    bool
>    default n
> select MMX
> Modified: trunk/coreboot-v2/src/cpu/intel/socket_mPGA479M/Kconfig
>
> --- trunk/coreboot-v2/src/cpu/intel/socket_mPGA479M/Kconfig	2009-10-08 15:12:31 UTC (rev 4744)
> +++ trunk/coreboot-v2/src/cpu/intel/socket_mPGA479M/Kconfig	2009-10-08 16:06:09 UTC (rev 4745)
> @@ -3,3 +3,5 @@
>    default n
>    select CPU_INTEL_MODEL_69X
>    select CPU_INTEL_MODEL_6DX
> select MMX
> select SSE
> Modified: trunk/coreboot-v2/src/cpu/intel/socket_mPGA604/Kconfig
>
> --- trunk/coreboot-v2/src/cpu/intel/socket_mPGA604/Kconfig	2009-10-08 15:12:31 UTC (rev 4744)
> +++ trunk/coreboot-v2/src/cpu/intel/socket_mPGA604/Kconfig	2009-10-08 16:06:09 UTC (rev 4745)
> @@ -4,3 +4,5 @@
>    select CPU_INTEL_MODEL_F2X
>    select CPU_INTEL_MODEL_F3X
>    select CPU_INTEL_MODEL_F4X
> select MMX
> select SSE

[v2] r4745 - in trunk/coreboot-v2/src/cpu/intel: socket_PGA370 socket_mPGA479M socket_mPGA604

[Peter Stuge]

Stefan Reinauer wrote:
> > Modified:
> >    trunk/coreboot-v2/src/cpu/intel/socket_PGA370/Kconfig
> >    trunk/coreboot-v2/src/cpu/intel/socket_mPGA479M/Kconfig
> >    trunk/coreboot-v2/src/cpu/intel/socket_mPGA604/Kconfig
> > Log:
> > Set MMX and SSE where needed.
>
> Isn't MMX or SSE something attached to a given CPU rather than a
> socket?

That makes sense.
> I see the correctness of our CPU model being compromised here..

Please write a little about sockets vs. CPUs?

Why is there a socket?

What are sockets used for?
(Grouping CPUs is not the answer I'm hoping for.)

//Peter

[v2] r4745 - in trunk/coreboot-v2/src/cpu/intel: socket_PGA370 socket_mPGA479M socket_mPGA604

[Joseph Smith]

On 10/08/2009 09:54 PM, Peter Stuge wrote:
> Stefan Reinauer wrote:
> > > Modified:
> > >     trunk/coreboot-v2/src/cpu/intel/socket_PGA370/Kconfig
> > >     trunk/coreboot-v2/src/cpu/intel/socket_mPGA479M/Kconfig
> > >     trunk/coreboot-v2/src/cpu/intel/socket_mPGA604/Kconfig
> > > Log:
> > > Set MMX and SSE where needed.
> >
> > Isn't MMX or SSE something attached to a given CPU rather than a
> > socket?
>
> That makes sense.
> > I see the correctness of our CPU model being compromised here..
>
> Please write a little about sockets vs. CPUs?
>
> Why is there a socket?
>
> What are sockets used for?
> (Grouping CPUs is not the answer I'm hoping for.)

Right, like in my particular case the CPU's are physically socket 479's 
but are mobile celeron and mobile PIII so I use socket_PGA370.

[v2] r4745 - in trunk/coreboot-v2/src/cpu/intel: socket_PGA370 socket_mPGA479M socket_mPGA604

[Stefan Reinauer]

Peter Stuge wrote:
> > I see the correctness of our CPU model being compromised here..
>
> Please write a little about sockets vs. CPUs?
>
> Why is there a socket?
>
> What are sockets used for?
> (Grouping CPUs is not the answer I'm hoping for.)

When you describe a mainboard (think devicetree.lb), you usually don't
have a CPU on there, but a socket.

There is a certain choice of CPUs you can put into that socket. The
socket decides which CPU drivers to
include in the coreboot image. These drivers include
 - MSR setup
 - microcode updates
 - power management setup
 - cache setup

Especially due to microcode it's not possible to make this completely
generic: All microcode for all Intel CPUs alone is more than 500kb

It's less about grouping CPUs but more about a clean device model. If we
want coreboot to be easily understandable, we need to make it reflect
what hardware looks like, logically. I think Ron has brought up some
pretty good reasons for moving the CPU capabilities into the sockets
(Which is a hack we need because of romcc - Enabling MMX and SSE per
socket is only needed because romcc needs to work without cache or
memory. We might want to add that as a comment to the socket Kconfig)

Stefan

[v2] r4745 - in trunk/coreboot-v2/src/cpu/intel: socket_PGA370 socket_mPGA479M socket_mPGA604

[Peter Stuge]

Stefan Reinauer wrote:
> > > I see the correctness of our CPU model being compromised here..
> >
> > Please write a little about sockets vs. CPUs?
> >
> > Why is there a socket?
> >
> > What are sockets used for?
> > (Grouping CPUs is not the answer I'm hoping for.)
>
> When you describe a mainboard (think devicetree.lb), you usually
> don't have a CPU on there, but a socket.

Check.
> There is a certain choice of CPUs you can put into that socket. The
> socket decides which CPU drivers to include in the coreboot image.
> These drivers include
> MSR setup
> microcode updates
> power management setup
> cache setup

The socket determines appropriate code for the CPUs that fit. Ok!
> Especially due to microcode it's not possible to make this completely
> generic: All microcode for all Intel CPUs alone is more than 500kb

And there's no good reason to do so. All those CPUs are not really
interchangeable anyway, so it's fine to "only" support the CPUs that
actually fit on the board. (With or without adapters, like 370/Slot1)
> It's less about grouping CPUs but more about a clean device model.
> If we want coreboot to be easily understandable, we need to make it
> reflect what hardware looks like, logically. I think Ron has
> brought up some pretty good reasons for moving the CPU capabilities
> into the sockets (Which is a hack we need because of romcc -

Hm. You just explained how the socket already controls which CPU code
is included - so basically CPU capabilities are already determined by
sockets. I don't think anything is principally wrong with letting the
socket also control the code produced by romcc?
> Enabling MMX and SSE per socket is only needed because romcc needs
> to work without cache or memory.

So far that's the only use, but that can change of course. Anyway, is
the problem that these hardware features are described in Kconfig, or
that Kconfig bools are like wired-or, so that any one means true,
when it should instead be wired-and, so that all must be true.

Is the Kconfig mod worth it?

//Peter

[v2] r4745 - in trunk/coreboot-v2/src/cpu/intel: socket_PGA370 socket_mPGA479M socket_mPGA604

[Stefan Reinauer]

Peter Stuge wrote:
> > Especially due to microcode it's not possible to make this completely
> > generic: All microcode for all Intel CPUs alone is more than 500kb
>
> And there's no good reason to do so. All those CPUs are not really
> interchangeable anyway, so it's fine to "only" support the CPUs that
> actually fit on the board. (With or without adapters, like 370/Slot1)

I think for the adapter case it's ok if people have to change the source
code to change the socket of their mainboard manually.
Maybe these adapters are not so common.
> > It's less about grouping CPUs but more about a clean device model.
> > If we want coreboot to be easily understandable, we need to make it
> > reflect what hardware looks like, logically. I think Ron has
> > brought up some pretty good reasons for moving the CPU capabilities
> > into the sockets (Which is a hack we need because of romcc -
>
> Hm. You just explained how the socket already controls which CPU code
> is included - so basically CPU capabilities are already determined by
> sockets. I don't think anything is principally wrong with letting the
> socket also control the code produced by romcc?

Yes, if the socket decided whether to enable MMX or SSE for romcc, it
should also set CFLAGS for the romcc calls accordingly, so we keep stuff
logically together.
> > Enabling MMX and SSE per socket is only needed because romcc ne
> > to work without cache or memory.
>
> So far that's the only use, but that can change of course.

I don't think it can. Nor should it. Any other use of SSE or MMX in the
firmware would be a very bad move.
> Anyway, is
> the problem that these hardware features are described in Kconfig, or
> that Kconfig bools are like wired-or, so that any one means true,
> when it should instead be wired-and, so that all must be true.

Yes. That keeps us from moving stuff to the CPUs
> Is the Kconfig mod worth it?

Changing Kconfig because of romcc? I don't think so.

Stefan

[v2] r4745 - in trunk/coreboot-v2/src/cpu/intel: socket_PGA370 socket_mPGA479M socket_mPGA604

[Peter Stuge]

Stefan Reinauer wrote:
> > interchangeable anyway, so it's fine to "only" support the CPUs
> > that actually fit on the board. (With or without adapters, like
> > 370/Slot1)
>
> I think for the adapter case it's ok if people have to change the
> source code to change the socket of their mainboard manually.
> Maybe these adapters are not so common.

Not anymore in any case. I guess where an adapter can be used the
sockets are similar enough to be pretty compatible. Not a big deal
either way.
> > > I think Ron has brought up some pretty good reasons for moving
> > > the CPU capabilities into the sockets (Which is a hack we need
> > > because of romcc -
> >
> > I don't think anything is principally wrong with letting the
> > socket also control the code produced by romcc?
>
> Yes, if the socket decided whether to enable MMX or SSE for romcc,
> it should also set CFLAGS for the romcc calls accordingly, so we
> keep stuff logically together.

Even if not directly, isn't this actually the end result now?
> > > Enabling MMX and SSE per socket is only needed because romcc ne
> > > to work without cache or memory.
> >
> > So far that's the only use, but that can change of course.
>
> I don't think it can. Nor should it. Any other use of SSE or MMX in
> the firmware would be a very bad move.

Hm, why is that? If some code for a component which is known to have
SSE - why not? It would basically mean -msse for gcc.

Oh, just saw something at Apple.
http://developer.apple.com/hardwaredrivers/ve/sse.html#ISA_Overview
in the SSE section:

"SSE is enabled by default on gcc-4.0."

Don't know if that applies also to upstream gcc. Probably not.
> > Is the Kconfig mod worth it?
>
> Changing Kconfig because of romcc? I don't think so.

Nod.

//Peter

[v2] r4745 - in trunk/coreboot-v2/src/cpu/intel: socket_PGA370 socket_mPGA479M socket_mPGA604

[Carl-Daniel Hailfinger]

On 10.10.2009 17:31, Peter Stuge wrote:
> Stefan Reinauer wrote:
> > > > Enabling MMX and SSE per socket is only needed because romcc ne
> > > > to work without cache or memory.
> > >
> > > So far that's the only use, but that can change of course.
> >
> > I don't think it can. Nor should it. Any other use of SSE or MMX in
> > the firmware would be a very bad move.
>
> Hm, why is that? If some code for a component which is known to have
> SSE - why not? It would basically mean -msse for gcc.

MOVNTQ and family, MMX memory ops and SSE memory ops are not allowed in
CAR unless you deliberately want to access RAM instead of CAR. The AMD
BKDG has the details.
> Oh, just saw something at Apple.
> http://developer.apple.com/hardwaredrivers/ve/sse.html#ISA_Overview
> in the SSE section:
>
> "SSE is enabled by default on gcc-4.0."
>
> Don't know if that applies also to upstream gcc. Probably not.

Does that mean we have to disable SSE explicitly if we compile the CAR
stage of coreboot on such GCC versions?

Regards,
Carl-Daniel

[v2] r4745 - in trunk/coreboot-v2/src/cpu/intel: socket_PGA370 socket_mPGA479M socket_mPGA604

[ron minnich]

On Thu, Oct 8, 2009 at 5:26 PM, Stefan Reinauer  wrote:
> Isn't MMX or SSE something attached to a given CPU rather than a socket?

The current design sets the choice of mmx/sse in the *mainboard* by
the inclusion of .inc files.

Moving it to the socket is a bit better than that.

If a socket includes multiple CPU types, is there ever a case where
different CPUs for that socket have different
settings for MMX and SSE? If so, then every mainboard in v2 has been
wrong until now. If not, then it is ok to set MMX/SSE in the socket.

It gets worse! For a given socket, you have to use the *least* set of
capabilities. CPUs with less capabilities have "veto power" over CPUs
with more capabilities, because you have to generate romcc code that
will work on the least-capable CPU for that socket. So, if ANY cpu in
a given socket doesn't have SSE, you're going to have to disable ALL
SSE code in ROMCC for that socket, because you are allowing people to
plug in CPUs with or without SSE, and you can't "un-use" the SSE usage
in the ROMCC code. Which means that the socket has to determine
whether MMX and SSE are set.

I hope this makes sense, I'm tired.

Bottom line, however: the socket determines usage of SSE and MMX, not
the CPU, because at the socket level you know which CPU types to
support, but at the CPU level you don't.

ron

[v2] r4745 - in trunk/coreboot-v2/src/cpu/intel: socket_PGA370 socket_mPGA479M socket_mPGA604

[Peter Stuge]

ron minnich wrote:
> > Isn't MMX or SSE something attached to a given CPU rather than a
> > socket?
>
> The current design sets the choice of mmx/sse in the *mainboard* by
> the inclusion of .inc files.
>
> Moving it to the socket is a bit better than that.

Very much!
> If a socket includes multiple CPU types, is there ever a case where
> different CPUs for that socket have different settings for MMX and
> SSE?

Yes. It's true for all Pentium {,II,III} sockets.
> It gets worse! For a given socket, you have to use the *least* set
> of capabilities.

..
> I hope this makes sense, I'm tired.

It does. I acked specifically because of this situation with sockets
that can have CPUs with differing features. You added the selects
only to the sockets one notch "above", so that the feature is
guaranteed to be available. That's the good way.
> Bottom line, however: the socket determines usage of SSE and MMX,
> not the CPU, because at the socket level you know which CPU types
> to support, but at the CPU level you don't.

At the CPU level there is just one CPU to support. But unless
mainboards specify a CPU rather than a socket that doesn't matter.

However, if boards usually specify sockets (makes more sense, right)
then the register option really must be controlled by sockets.

Stefan got me thinking that maybe a particular board would be limited
to a single CPU - but that's not how it works, right?

//Peter

[v2] r4745 - in trunk/coreboot-v2/src/cpu/intel: socket_PGA370 socket_mPGA479M socket_mPGA604

[Myles Watson]

On Thu, Oct 8, 2009 at 9:44 PM, ron minnich  wrote:
> to generate romcc code that
> will work on the least-capable CPU for that socket.

...
> the socket has to determine
> whether MMX and SSE are set.

Maybe since these options are romcc-specific they should be ROMCC_MMX
& ROMCC_SSE.  I just noticed that on my K8 boards SSE=0, which is
confusing.

Thanks,
Myles

[v2] r4745 - in trunk/coreboot-v2/src/cpu/intel: socket_PGA370 socket_mPGA479M socket_mPGA604

[ron minnich]

On Fri, Oct 9, 2009 at 8:47 AM, Myles Watson  wrote:
> Maybe since these options are romcc-specific they should be ROMCC_MMX
> & ROMCC_SSE.  I just noticed that on my K8 boards SSE=0, which is
> confusing.

Why not set SSE to 1 then? They have it.

I think we leave it as MMX and SSE because, at some future time,
people might want to use MMX and/or SSE config variables in some other
way, not related to romcc.

SSE and MMX are described what capabilities can be used for a given
socket. Those capabilities, if available, can be used by romcc, but
might also be usable by other bits of software too. We might even find
ourselves using them in gcc someday.

Just my $.02

ron

[v2] r4745 - in trunk/coreboot-v2/src/cpu/intel: socket_PGA370 socket_mPGA479M socket_mPGA604

[Myles Watson]

On Fri, Oct 9, 2009 at 12:04 PM, ron minnich  wrote:
> On Fri, Oct 9, 2009 at 8:47 AM, Myles Watson  wrote:
> > Maybe since these options are romcc-specific they should be ROMCC_MMX
> > & ROMCC_SSE.  I just noticed that on my K8 boards SSE=0, which is
> > confusing.
>
> Why not set SSE to 1 then? They have it.

Because it doesn't do anything and I think that having extra values
goes against KISS.
> I think we leave it as MMX and SSE because, at some future time,
> people might want to use MMX and/or SSE config variables in some other
> way, not related to romcc.

I agree with that.

Thanks,
Myles

[v2] r4745 - in trunk/coreboot-v2/src/cpu/intel: socket_PGA370 socket_mPGA479M socket_mPGA604

[Peter Stuge]

Myles Watson wrote:
> > > Maybe since these options are romcc-specific they should be
> > > ROMCC_MMX & ROMCC_SSE.

They are only used by romcc, but they are really hardware specific.
We could rename them now, but the first time they are used for
something other than romcc they would have be to changed back. I
prefer keeping them.
> > > I just noticed that on my K8 boards SSE=0, which is confusing.
> >
> > Why not set SSE to 1 then? They have it.
>
> Because it doesn't do anything and I think that having extra values
> goes against KISS.
> From the board port perspective it shouldn't matter if they do

anything. They should be set when appropriate. I don't think they
should be set by boards. There can certainly be exceptions, but for
K8 I say just remove them from the board.

//Peter

[v2] r4745 - in trunk/coreboot-v2/src/cpu/intel: socket_PGA370 socket_mPGA479M socket_mPGA604

[Myles Watson]

> They should be set when appropriate. I don't think they
> should be set by boards.

I agree.

Thanks,
Myles