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 -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
