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

Peter Stuge peter at stuge.se
Sat Oct 10 17:31:48 CEST 2009

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.
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.



More information about the coreboot mailing list