See patch.
Uwe.
Uwe Hermann wrote:
Convert all Intel i810 boards to CAR.
Drop "select ROMCC" from the boards, as well as early_mtrr stuff.
Add "select CACHE_AS_RAM" to socket_PGA370/Kconfig, as well as the usual DCACHE_RAM_BASE and DCACHE_RAM_SIZE variables.
In socket_PGA370/Makefile.inc add: cpu_incs += $(src)/cpu/intel/car/cache_as_ram.inc
Other smaller related fixes.
Abuild-tested and boot-tested on MSI MS-6178.
Signed-off-by: Uwe Hermann uwe@hermann-uwe.de
Acked-by: Peter Stuge peter@stuge.se
Nack for the time being. I think this needs a little discussion.
Is the FC_PGA370 socket different than the PGA370 socket?
If they are different, do they take the same processors? I ask because the DCACHE_* config options in your patch are different than the options in the FC_PGA370 socket.
Thanks, wt
On Tuesday 12 October 2010 15:08:22 Uwe Hermann wrote:
See patch.
Uwe.
On 10/12/2010 09:51 PM, Warren Turkal wrote:
Nack for the time being. I think this needs a little discussion.
Is the FC_PGA370 socket different than the PGA370 socket?
If they are different, do they take the same processors? I ask because the DCACHE_* config options in your patch are different than the options in the FC_PGA370 socket.
Thanks, wt
On Tuesday 12 October 2010 15:08:22 Uwe Hermann wrote:
See patch.
Uwe.
FC-PGA's support SSE2 while the PGA's do not. that is the difference. I created FC_PGA370 to make the CAR coversion simpler. Hope that helps.
On Tuesday 12 October 2010 19:22:43 Joseph Smith wrote:
FC-PGA's support SSE2 while the PGA's do not. that is the difference. I created FC_PGA370 to make the CAR coversion simpler. Hope that helps.
I must be misunderstanding this entirely.
First, you say there is a difference in that the FC version support SSE2. Then, you say that the FC_PGA370 socket is simply a mechanism to make conversion to CAR easier.
Does that mean that FC_PGA370 is simply PGA370 + CAR, or do PGA370 sockets really not support SSE2 chips?
Researching it a little bit, I see that FC-PGA370 is a mechanically compatible socket, so I guess that the FC-PGA370 supports chips that the PGA370 does not. Is that correct? So FC-PGA is more than just an upgrade CAR?
So I guess I would be satisfied if I knew that the minimum size l2 cache for a chip that fits in the PGA370 was 4K since that's what the patch says and since that's really what matters for the DCACHE_RAM_SIZE.
Also, are we sure that the DCACHE_RAM_BASE used will work? I.e. has it been tested on real hardware?
Also, if we have real hardware running that works with this. Would if be possible to get a the register output for a cpuid 0x80000006 call? I'd just like to know if it would work on that processor since that call can be used to dynamically determine the amount of l2 cache. I've been thinking about adding that to the intel/amd/via CAR implementations so that DCACHE_RAM_SIZE doesn't need to be set.
Thanks, wt
On 10/13/2010 01:24 AM, Warren Turkal wrote:
On Tuesday 12 October 2010 19:22:43 Joseph Smith wrote:
FC-PGA's support SSE2 while the PGA's do not. that is the difference. I created FC_PGA370 to make the CAR coversion simpler. Hope that helps.
I must be misunderstanding this entirely.
First, you say there is a difference in that the FC version support SSE2. Then, you say that the FC_PGA370 socket is simply a mechanism to make conversion to CAR easier.
Does that mean that FC_PGA370 is simply PGA370 + CAR, or do PGA370 sockets really not support SSE2 chips?
Researching it a little bit, I see that FC-PGA370 is a mechanically compatible socket, so I guess that the FC-PGA370 supports chips that the PGA370 does not. Is that correct? So FC-PGA is more than just an upgrade CAR?
Yes, socket wise they are backwars compatable in 99% of boards. The PGA's were 66MHz FSB Celerons with 128k L2 cache.
So I guess I would be satisfied if I knew that the minimum size l2 cache for a chip that fits in the PGA370 was 4K since that's what the patch says and since that's really what matters for the DCACHE_RAM_SIZE.
Also, are we sure that the DCACHE_RAM_BASE used will work? I.e. has it been tested on real hardware?
Also, if we have real hardware running that works with this. Would if be possible to get a the register output for a cpuid 0x80000006 call? I'd just like to know if it would work on that processor since that call can be used to dynamically determine the amount of l2 cache. I've been thinking about adding that to the intel/amd/via CAR implementations so that DCACHE_RAM_SIZE doesn't need to be set.
I'm sure CAR will work on the PGA's, although they may need Keith's L2 patch. More or less it was decided a while ago to split the model_6xx romcc clump-o-crap out into their own CAR model directories (starting with model_68x). I have a bunch of Socket 370 processors (FC-PGA and PGA) I plan on testing on my i810 board... I just have alot on my plate at this time.
Den 13-10-2010 15:50, Joseph Smith skrev:
On 10/13/2010 01:24 AM, Warren Turkal wrote:
On Tuesday 12 October 2010 19:22:43 Joseph Smith wrote:
FC-PGA's support SSE2 while the PGA's do not. that is the difference. I created FC_PGA370 to make the CAR coversion simpler. Hope that helps.
I must be misunderstanding this entirely.
First, you say there is a difference in that the FC version support SSE2. Then, you say that the FC_PGA370 socket is simply a mechanism to make conversion to CAR easier.
Does that mean that FC_PGA370 is simply PGA370 + CAR, or do PGA370 sockets really not support SSE2 chips?
Researching it a little bit, I see that FC-PGA370 is a mechanically compatible socket, so I guess that the FC-PGA370 supports chips that the PGA370 does not. Is that correct? So FC-PGA is more than just an upgrade CAR?
Yes, socket wise they are backwars compatable in 99% of boards. The PGA's were 66MHz FSB Celerons with 128k L2 cache.
So I guess I would be satisfied if I knew that the minimum size l2 cache for a chip that fits in the PGA370 was 4K since that's what the patch says and since that's really what matters for the DCACHE_RAM_SIZE.
Also, are we sure that the DCACHE_RAM_BASE used will work? I.e. has it been tested on real hardware?
Also, if we have real hardware running that works with this. Would if be possible to get a the register output for a cpuid 0x80000006 call? I'd just like to know if it would work on that processor since that call can be used to dynamically determine the amount of l2 cache. I've been thinking about adding that to the intel/amd/via CAR implementations so that DCACHE_RAM_SIZE doesn't need to be set.
I'm sure CAR will work on the PGA's, although they may need Keith's L2 patch. More or less it was decided a while ago to split the model_6xx romcc clump-o-crap out into their own CAR model directories (starting with model_68x). I have a bunch of Socket 370 processors (FC-PGA and PGA) I plan on testing on my i810 board... I just have alot on my plate at this time.
I will probably test P6IWP-Fe with the 370 cpus i have. Thanks for converting this, this brings me closer to understanding how car works :)
-Anders Jenbo
Hi,
patch is committed with Peter's ack in r5949 as it's not really directly related to this discussion and also boot-tested by me on MSI MS-6178 as mentioned in the patch description.
On Wed, Oct 13, 2010 at 09:50:52AM -0400, Joseph Smith wrote:
On 10/13/2010 01:24 AM, Warren Turkal wrote:
On Tuesday 12 October 2010 19:22:43 Joseph Smith wrote:
FC-PGA's support SSE2 while the PGA's do not. that is the difference. I created FC_PGA370 to make the CAR coversion simpler. Hope that helps.
I must be misunderstanding this entirely.
First, you say there is a difference in that the FC version support SSE2. Then, you say that the FC_PGA370 socket is simply a mechanism to make conversion to CAR easier.
Hm, this stuff may need some clarification and/or fixing in coreboot indeed.
As far as I can see, e.g. from http://www.cpu-world.com/Sockets/Socket%20370%20%28PGA370%29.html there were 3 different sockets named socket370, all of which were physically compatible, but not electrically.
I'm not so sure about the naming, but these seem to be the different packages / form factors of the sockets:
- Plastic pin grid array (PPGA) - Flip-chip pin grid array (FC-PGA) - Flip-chip pin grid array (FC-PGA2)
(http://en.wikipedia.org/wiki/Socket_370)
Now, whether or not we need or want different socket_* directories for these I'm not sure yet, probably needs some investigation.
However, as we're switchting all CPUs/boards to CAR sooner or later, having an extra dir just for the CAR (vs. ROMCC) version of the socket will not be required.
As for SSE/SSE2, that seems to be a mess in coreboot too right now. The socket_PGA370 does "select MMX" and explictly disables SSE2 (and doesn't select or disable "SSE" explicitly). The socket_FC_PGA370 does "select MMX" and "select SSE" (but not SSE2!)
There is no default for MMX and SSE in src/cpu/Kconfig, but SSE2 defaults of off there.
This is all a bit inconsistent I think, need to look into it a bit more.
Does that mean that FC_PGA370 is simply PGA370 + CAR, or do PGA370 sockets really not support SSE2 chips?
Not sure if the socket is the correct place to "select" either of MMX/SSE/SSE2 anyway, that's a CPU-property and should probably be selected in model_* (even if for newer CPUs all of those are always "y").
So I guess I would be satisfied if I knew that the minimum size l2 cache for a chip that fits in the PGA370 was 4K since that's what the patch says and since that's really what matters for the DCACHE_RAM_SIZE.
I don't think so. The DCACHE_RAM_SIZE specifies the amount of L1 data-cache to use for CAR as far as I know (not L2 cache). Unless I'm mistaken, it also doesn't specify the actual size of the L1 cache, just the size we want to use for CAR (but please someone correct me if I'm wrong).
Actually L2 cache is completely disabled for the 6xx CPUs at the moment, and intel/car/cache_as_ram.inc doesn't use L2 at all (unless I'm very mistaken). Other CAR implementations may or may not use L2 though, not sure.
Also, are we sure that the DCACHE_RAM_BASE used will work? I.e. has it been tested on real hardware?
Yes, I mentioned that in the patch description, I boot-tested it on MSI MS-6178.
But you're right, the CACHE_BASE variables differ, but I guess they both work (0xc0000 works, I can test the other later just to make sure). We should probably use the same base address for all users of intel/car/cache_as_ram.inc for less confusion.
I'm sure CAR will work on the PGA's,
Yep.
although they may need Keith's L2 patch.
No, don't think it's needed for CAR.
More or less it was decided a while ago to split the model_6xx romcc clump-o-crap out into their own CAR model directories (starting with model_68x).
Yep, we'll move out more CPUs from 6xx into their own directories.
Uwe.
Does that mean that FC_PGA370 is simply PGA370 + CAR, or do PGA370 sockets really not support SSE2 chips?
Not sure if the socket is the correct place to "select" either of MMX/SSE/SSE2 anyway, that's a CPU-property and should probably be selected in model_* (even if for newer CPUs all of those are always "y").
Here's a quote from Stefan:
http://www.coreboot.org/pipermail/coreboot/2010-March/056586.html
"I think we should be careful as this easily breaks the code in very nasty places (especially SSE chooses the registers for ROMCC, so this definitely breaks some boards)
"The settings have to be the most conservative, not the best possible. That means if there is a single CPU for a socket that does not have SSE, SSE has to be off for that socket. Choosing SSE to be on because there is a single CPU for that socket that has SSE will break other systems."
Thanks, Myles
On Wed, Oct 13, 2010 at 09:00:00PM +0200, Uwe Hermann wrote:
But you're right, the CACHE_BASE variables differ, but I guess they both work (0xc0000 works, I can test the other later just to make sure).
Actually, scratch that. It seems intel/car/cache_as_ram.inc hardcodes the base to:
#define CacheBase (0xd0000 - CacheSize)
I.e. the DCACHE_RAM_BASE option is never used for this CAR implementation. We have multiple possibilities to fix this:
- Drop DCACHE_RAM_BASE for these CPUs/sockets, and leave in the hardcoded CacheBase, which means all of them will use the same base.
- Or, actually use DCACHE_RAM_BASE in the cache_as_ram.inc file, which allows us to use different bases per-CPU or per-socket.
No idea if it makes sense to be able to select the base for these CPUs at all (?)
Uwe.
Uwe Hermann wrote:
Actually, scratch that. It seems intel/car/cache_as_ram.inc hardcodes the base to:
#define CacheBase (0xd0000 - CacheSize)
I.e. the DCACHE_RAM_BASE option is never used for this CAR implementation. We have multiple possibilities to fix this:
- Drop DCACHE_RAM_BASE for these CPUs/sockets, and leave in the hardcoded CacheBase, which means all of them will use the same base.
I think this is the right thing to do, at least for now. Maybe hardcode cache size too.
And by "for now" I mean "until someone investigates the CAR situation on all affected CPUs".
//Peter
On 10/13/2010 03:00 PM, Uwe Hermann wrote:
Hi,
patch is committed with Peter's ack in r5949 as it's not really directly related to this discussion and also boot-tested by me on MSI MS-6178 as mentioned in the patch description.
On Wed, Oct 13, 2010 at 09:50:52AM -0400, Joseph Smith wrote:
On 10/13/2010 01:24 AM, Warren Turkal wrote:
On Tuesday 12 October 2010 19:22:43 Joseph Smith wrote:
FC-PGA's support SSE2 while the PGA's do not. that is the difference. I created FC_PGA370 to make the CAR coversion simpler. Hope that helps.
I must be misunderstanding this entirely.
First, you say there is a difference in that the FC version support SSE2. Then, you say that the FC_PGA370 socket is simply a mechanism to make conversion to CAR easier.
Hm, this stuff may need some clarification and/or fixing in coreboot indeed.
As far as I can see, e.g. from http://www.cpu-world.com/Sockets/Socket%20370%20%28PGA370%29.html there were 3 different sockets named socket370, all of which were physically compatible, but not electrically.
I'm not so sure about the naming, but these seem to be the different packages / form factors of the sockets:
- Plastic pin grid array (PPGA)
- Flip-chip pin grid array (FC-PGA)
- Flip-chip pin grid array (FC-PGA2)
(http://en.wikipedia.org/wiki/Socket_370)
Now, whether or not we need or want different socket_* directories for these I'm not sure yet, probably needs some investigation.
However, as we're switchting all CPUs/boards to CAR sooner or later, having an extra dir just for the CAR (vs. ROMCC) version of the socket will not be required.
As for SSE/SSE2, that seems to be a mess in coreboot too right now.
Yes. I would like to see a common socket for all three maybe just socket_370 (Socket 370 is all that is in most mainboard vendor descriptions)?. There must be some way to probe and detect what features the cpu has and include the features based in that? Maybe a simple table with the model numbers?
On 10/14/2010 08:35 AM, Joseph Smith wrote:
On 10/13/2010 03:00 PM, Uwe Hermann wrote:
Hi,
patch is committed with Peter's ack in r5949 as it's not really directly related to this discussion and also boot-tested by me on MSI MS-6178 as mentioned in the patch description.
On Wed, Oct 13, 2010 at 09:50:52AM -0400, Joseph Smith wrote:
On 10/13/2010 01:24 AM, Warren Turkal wrote:
On Tuesday 12 October 2010 19:22:43 Joseph Smith wrote:
FC-PGA's support SSE2 while the PGA's do not. that is the difference. I created FC_PGA370 to make the CAR coversion simpler. Hope that helps.
I must be misunderstanding this entirely.
First, you say there is a difference in that the FC version support SSE2. Then, you say that the FC_PGA370 socket is simply a mechanism to make conversion to CAR easier.
Hm, this stuff may need some clarification and/or fixing in coreboot indeed.
As far as I can see, e.g. from http://www.cpu-world.com/Sockets/Socket%20370%20%28PGA370%29.html there were 3 different sockets named socket370, all of which were physically compatible, but not electrically.
I'm not so sure about the naming, but these seem to be the different packages / form factors of the sockets:
- Plastic pin grid array (PPGA)
- Flip-chip pin grid array (FC-PGA)
- Flip-chip pin grid array (FC-PGA2)
(http://en.wikipedia.org/wiki/Socket_370)
Now, whether or not we need or want different socket_* directories for these I'm not sure yet, probably needs some investigation.
However, as we're switchting all CPUs/boards to CAR sooner or later, having an extra dir just for the CAR (vs. ROMCC) version of the socket will not be required.
As for SSE/SSE2, that seems to be a mess in coreboot too right now.
Yes. I would like to see a common socket for all three maybe just socket_370 (Socket 370 is all that is in most mainboard vendor descriptions)?. There must be some way to probe and detect what features the cpu has and include the features based in that? Maybe a simple table with the model numbers?
Anyways why can't cpu specific features be implemented at the model level and not at the socket level???
On 14.10.2010, at 05:38, Joseph Smith joe@settoplinux.org wrote:
Anyways why can't cpu specific features be implemented at the model level and not at the socket level???
Because SSE, SSE2 and MMX are not CPU specific features in this context. SSE and MMX determine how many registrers are available for romcc. It describes the lowest common denominator between all CPUs in a socket. If one model selects SSE and another one does not, it will still be enabled, thus breaking every other CPU you can put in that socket.
Maybe we should drop those flags from Kconfig completely and just set the right ROMCCFLAGS in the socket's makefile to remove any confusion about the meaning of thos flags.
SSE2 is similar. However it triggers the use of optimized assembler instructions in ram testing. This one is less critical al most boards don't test the ram. Still we can not put the setting in the model.
The reason models and sockets behave this way is that a mainboard selects a socket and the socket selects all models that fit into that socket. There is no other use for sockets than to gather models.
Stefan
-- Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Am 14.10.2010 17:58, schrieb Stefan Reinauer:
Maybe we should drop those flags from Kconfig completely and just set the right ROMCCFLAGS in the socket's makefile to remove any confusion about the meaning of thos flags.
Making the CPUs define what they _don't_ support and derive the remaining feature from there is probably overkill ;-)
The reason models and sockets behave this way is that a mainboard selects a socket and the socket selects all models that fit into that socket. There is no other use for sockets than to gather models.
I wonder how to communicate that more clearly in the code/build system.
Patrick
On Thu, 2010-10-14 at 18:02 +0200, Patrick Georgi wrote: Am 14.10.2010 17:58, schrieb Stefan Reinauer:
... The reason models and sockets behave this way is that a mainboard
selects a socket and the socket selects all models that fit into that socket. There is no other use for sockets than to gather models.
I wonder how to communicate that more clearly in the code/build system.
Sorry to chime in here, but does this cover slotkets popular a few years ago?
I have two computers with a socket 370 to slot 1 slotkets installed in a slot 1 motherboard. Thereby being able to run 1.4 GHz Tualatin Celeron II processors compared to max 400 MHz Mendocino Celeron I processors. (Have also successfully used VIA C3 Nehemiah processors)
http://en.wikipedia.org/wiki/Celeron http://en.wikipedia.org/wiki/Slotket http://en.wikipedia.org/wiki/VIA_C3
On Thu, Oct 14, 2010 at 08:58:35AM -0700, Stefan Reinauer wrote:
On 14.10.2010, at 05:38, Joseph Smith joe@settoplinux.org wrote:
Anyways why can't cpu specific features be implemented at the model level and not at the socket level???
Because SSE, SSE2 and MMX are not CPU specific features in this context. SSE and MMX determine how many registrers are available for romcc. It describes the lowest common denominator between all CPUs in a socket. If one model selects SSE and another one does not, it will still be enabled, thus breaking every other CPU you can put in that socket.
Yep.
Maybe we should drop those flags from Kconfig completely and just set the right ROMCCFLAGS in the socket's makefile to remove any confusion about the meaning of thos flags.
It's worth considering IMHO, yes. Or, actually, since sooner or later many chipsets will convert to TINYBOOTBLOCK and CAR (at least that's the plan I think), romcc will only ever be used for the bootblock, right?
And that's pretty tiny hopefully and should work just fine with 386 as romcc option? Do we actually really have any measurable advantages from using romcc options other than 386 in that case?
Same for RAM test -- it's not a memtest86 replacement, just a quick "Did I screw up RAM init" test, which doesn't get run very often after the RAM init code is finished / working. Does the RAM test speed really matter much here? Shall we just use 386 for ROMCC everywhere (and not use SSE2 for ramtest) and get rid of the MMX/SSE/SSE2 config options?
Uwe.
On 10/14/2010 06:27 PM, Uwe Hermann wrote:
On Thu, Oct 14, 2010 at 08:58:35AM -0700, Stefan Reinauer wrote:
On 14.10.2010, at 05:38, Joseph Smithjoe@settoplinux.org wrote:
Anyways why can't cpu specific features be implemented at the model level and not at the socket level???
Because SSE, SSE2 and MMX are not CPU specific features in this context. SSE and MMX determine how many registrers are available for romcc. It describes the lowest common denominator between all CPUs in a socket. If one model selects SSE and another one does not, it will still be enabled, thus breaking every other CPU you can put in that socket.
Yep.
Maybe we should drop those flags from Kconfig completely and just set the right ROMCCFLAGS in the socket's makefile to remove any confusion about the meaning of thos flags.
It's worth considering IMHO, yes. Or, actually, since sooner or later many chipsets will convert to TINYBOOTBLOCK and CAR (at least that's the plan I think), romcc will only ever be used for the bootblock, right?
And that's pretty tiny hopefully and should work just fine with 386 as romcc option? Do we actually really have any measurable advantages from using romcc options other than 386 in that case?
Same for RAM test -- it's not a memtest86 replacement, just a quick "Did I screw up RAM init" test, which doesn't get run very often after the RAM init code is finished / working. Does the RAM test speed really matter much here? Shall we just use 386 for ROMCC everywhere (and not use SSE2 for ramtest) and get rid of the MMX/SSE/SSE2 config options?
Good point Uwe, I like how you think :-)
On 10/14/10 3:27 PM, Uwe Hermann wrote:
Maybe we should drop those flags from Kconfig completely and just set the right ROMCCFLAGS in the socket's makefile to remove any confusion about the meaning of thos flags.
It's worth considering IMHO, yes. Or, actually, since sooner or later many chipsets will convert to TINYBOOTBLOCK and CAR (at least that's the plan I think), romcc will only ever be used for the bootblock, right?
Yes.
And that's pretty tiny hopefully and should work just fine with 386 as romcc option? Do we actually really have any measurable advantages from using romcc options other than 386 in that case?
Yes. Since newer systems (might) require considerably more initialization in the tiny bootblock stage (enabling ROM for example, possibly more to come, like watchdogs, ECs, HT enumeration..) there is value in having more registers available on those platforms. So we shouldn't cut off the path to having them available. They definitely have not much value in Kconfig though. If something doesn't have to be an option, we should try to wipe it from Kconfig to keep that simple.
Same for RAM test -- it's not a memtest86 replacement, just a quick "Did I screw up RAM init" test, which doesn't get run very often after the RAM init code is finished / working. Does the RAM test speed really matter much here? Shall we just use 386 for ROMCC everywhere (and not use SSE2 for ramtest) and get rid of the MMX/SSE/SSE2 config options?
Since the code is already there and tested I would strongly suggest to not wipe it. We're also using a simplified version of the ram test on some platforms to determine whether ram initialization was successful (as opposed to actually testing for ram integrity errors). Since this code is running on every boot (checking a considerably smaller amount of RAM, obviously) we should not deliberately slow it down.
Stefan
On Thu, Oct 14, 2010 at 5:38 AM, Joseph Smith joe@settoplinux.org wrote:
Anyways why can't cpu specific features be implemented at the model level and not at the socket level???
As a meta-comment, it's not always obvious, but many of these things are done for a reason.
I'm glad you asked as Stefan gave a clear reason. I think it makes sense to put this good question in a "hackers FAQ".
ron
-
Anders Jenbo -
Joseph Smith -
Myles Watson -
Patrick Georgi -
Peter Stuge -
ron minnich -
Stefan Reinauer -
Svante Signell -
Uwe Hermann -
Warren Turkal