I've separated this into two patches, one code and one microcode, to improve readability, but they would both have to be committed at once (else things break). These patches eliminate a lot of repeated code, make porting and adding new CPUs easier, add all the latest released microcode updates, and add somewhat experimental support for the latest lga775 cpus, along with various other currently unsupported CPUs. Unfortunately, not everything works quite right yet. Here's the broken stuff:
* socket_603: includes all Xeon model f0x, f1x, and f2x cpus. This may be incorrect, but I can't see any easy way to find out. * socket_604: includes all Xeon model f2x, f3x, f4x, and f6x. Same as above, with the added bonus of being too large to fit with any current board. It should also include the socket_603 IDs, since socket 603 CPUs work on socket 604 boards. * socket_775: too large to build with most current ports, but it could probably be broken down into socket_775_pentium and socket_775_core. All fxx IDs are pentium 4/D, and 6xx IDs are Core/Core 2
For now, I've left the current model_fxx and socket_*60*, so nothing breaks, but IMO the socket_603/604 I've added should be made to work.
Both patches Signed-off-by: Corey Osgood corey.osgood@gmail.com
Quoting Corey Osgood corey.osgood@gmail.com:
I've separated this into two patches, one code and one microcode, to improve readability, but they would both have to be committed at once (else things break). These patches eliminate a lot of repeated code, make porting and adding new CPUs easier, add all the latest released microcode updates, and add somewhat experimental support for the latest lga775 cpus, along with various other currently unsupported CPUs. Unfortunately, not everything works quite right yet. Here's the broken stuff:
- socket_603: includes all Xeon model f0x, f1x, and f2x cpus. This may
be incorrect, but I can't see any easy way to find out.
- socket_604: includes all Xeon model f2x, f3x, f4x, and f6x. Same as
above, with the added bonus of being too large to fit with any current board. It should also include the socket_603 IDs, since socket 603 CPUs work on socket 604 boards.
- socket_775: too large to build with most current ports, but it could
probably be broken down into socket_775_pentium and socket_775_core. All fxx IDs are pentium 4/D, and 6xx IDs are Core/Core 2
For now, I've left the current model_fxx and socket_*60*, so nothing breaks, but IMO the socket_603/604 I've added should be made to work.
Both patches Signed-off-by: Corey Osgood corey.osgood@gmail.com
Hmm looks good. Should we add a quick note to each file to what processor it belongs too? I think that would save developers time from having to look it up when writing code for a new board? What do you think?
Thanks - Joe
joe@smittys.pointclark.net wrote:
Quoting Corey Osgood corey.osgood@gmail.com:
I've separated this into two patches, one code and one microcode, to improve readability, but they would both have to be committed at once (else things break). These patches eliminate a lot of repeated code, make porting and adding new CPUs easier, add all the latest released microcode updates, and add somewhat experimental support for the latest lga775 cpus, along with various other currently unsupported CPUs. Unfortunately, not everything works quite right yet. Here's the broken stuff:
- socket_603: includes all Xeon model f0x, f1x, and f2x cpus. This may
be incorrect, but I can't see any easy way to find out.
- socket_604: includes all Xeon model f2x, f3x, f4x, and f6x. Same as
above, with the added bonus of being too large to fit with any current board. It should also include the socket_603 IDs, since socket 603 CPUs work on socket 604 boards.
- socket_775: too large to build with most current ports, but it could
probably be broken down into socket_775_pentium and socket_775_core. All fxx IDs are pentium 4/D, and 6xx IDs are Core/Core 2
For now, I've left the current model_fxx and socket_*60*, so nothing breaks, but IMO the socket_603/604 I've added should be made to work.
Both patches Signed-off-by: Corey Osgood corey.osgood@gmail.com
Hmm looks good. Should we add a quick note to each file to what processor it belongs too? I think that would save developers time from having to look it up when writing code for a new board? What do you think?
Thanks - Joe
Do you mean the microcode files? If so, the microcode update looks like this:
Header Update Revision Date Processor Signature (CPU ID) ...
So, the 4th entry in the update is always the CPU ID, and conveniently it's always the last one on the first line. It also makes grepping for them very easy, once you have the update broken down into smaller files. This is documented *somewhere* in LB, but I can't find it at the moment. It's also in the Intel architecture manual, volume 3a, table 9-6.
In the past we labeled some CPU IDs as to what CPUs they belonged to. In truth, Intel uses the same CPU IDs for a variety of CPUs, for instance in some cases Celeron, Pentium X, and Xeons all share a common ID, since the core is still the same. So we can't really do that any more ;)
-Corey
Quoting Corey Osgood corey.osgood@gmail.com:
joe@smittys.pointclark.net wrote:
Quoting Corey Osgood corey.osgood@gmail.com:
I've separated this into two patches, one code and one microcode, to improve readability, but they would both have to be committed at once (else things break). These patches eliminate a lot of repeated code, make porting and adding new CPUs easier, add all the latest released microcode updates, and add somewhat experimental support for the latest lga775 cpus, along with various other currently unsupported CPUs. Unfortunately, not everything works quite right yet. Here's the broken stuff:
- socket_603: includes all Xeon model f0x, f1x, and f2x cpus. This may
be incorrect, but I can't see any easy way to find out.
- socket_604: includes all Xeon model f2x, f3x, f4x, and f6x. Same as
above, with the added bonus of being too large to fit with any current board. It should also include the socket_603 IDs, since socket 603 CPUs work on socket 604 boards.
- socket_775: too large to build with most current ports, but it could
probably be broken down into socket_775_pentium and socket_775_core. All fxx IDs are pentium 4/D, and 6xx IDs are Core/Core 2
For now, I've left the current model_fxx and socket_*60*, so nothing breaks, but IMO the socket_603/604 I've added should be made to work.
Both patches Signed-off-by: Corey Osgood corey.osgood@gmail.com
Hmm looks good. Should we add a quick note to each file to what processor it belongs too? I think that would save developers time from having to look it up when writing code for a new board? What do you think?
Thanks - Joe
Do you mean the microcode files? If so, the microcode update looks like this:
Header Update Revision Date Processor Signature (CPU ID) ...
So, the 4th entry in the update is always the CPU ID, and conveniently it's always the last one on the first line. It also makes grepping for them very easy, once you have the update broken down into smaller files. This is documented *somewhere* in LB, but I can't find it at the moment. It's also in the Intel architecture manual, volume 3a, table 9-6.
In the past we labeled some CPU IDs as to what CPUs they belonged to. In truth, Intel uses the same CPU IDs for a variety of CPUs, for instance in some cases Celeron, Pentium X, and Xeons all share a common ID, since the core is still the same. So we can't really do that any more ;)
-Corey
Oh ok, that makes sense.
Acked-by: Joseph Smith joe@smittys.pointclark.net
Thanks - Joe
joe@smittys.pointclark.net wrote:
Quoting Corey Osgood corey.osgood@gmail.com:
joe@smittys.pointclark.net wrote:
Quoting Corey Osgood corey.osgood@gmail.com:
I've separated this into two patches, one code and one microcode, to improve readability, but they would both have to be committed at once (else things break). These patches eliminate a lot of repeated code, make porting and adding new CPUs easier, add all the latest released microcode updates, and add somewhat experimental support for the latest lga775 cpus, along with various other currently unsupported CPUs. Unfortunately, not everything works quite right yet. Here's the broken stuff:
- socket_603: includes all Xeon model f0x, f1x, and f2x cpus. This
may be incorrect, but I can't see any easy way to find out.
- socket_604: includes all Xeon model f2x, f3x, f4x, and f6x. Same as
above, with the added bonus of being too large to fit with any current board. It should also include the socket_603 IDs, since socket 603 CPUs work on socket 604 boards.
- socket_775: too large to build with most current ports, but it
could probably be broken down into socket_775_pentium and socket_775_core. All fxx IDs are pentium 4/D, and 6xx IDs are Core/Core 2
For now, I've left the current model_fxx and socket_*60*, so nothing breaks, but IMO the socket_603/604 I've added should be made to work.
Both patches Signed-off-by: Corey Osgood corey.osgood@gmail.com
Hmm looks good. Should we add a quick note to each file to what processor it belongs too? I think that would save developers time from having to look it up when writing code for a new board? What do you think?
Thanks - Joe
Do you mean the microcode files? If so, the microcode update looks like this:
Header Update Revision Date Processor Signature (CPU ID) ...
So, the 4th entry in the update is always the CPU ID, and conveniently it's always the last one on the first line. It also makes grepping for them very easy, once you have the update broken down into smaller files. This is documented *somewhere* in LB, but I can't find it at the moment. It's also in the Intel architecture manual, volume 3a, table 9-6.
In the past we labeled some CPU IDs as to what CPUs they belonged to. In truth, Intel uses the same CPU IDs for a variety of CPUs, for instance in some cases Celeron, Pentium X, and Xeons all share a common ID, since the core is still the same. So we can't really do that any more ;)
-Corey
Oh ok, that makes sense.
Acked-by: Joseph Smith joe@smittys.pointclark.net
Thanks - Joe
Thanks, Joe. Anyone else have anything to say? Honestly expected more feedback, but if there are no objections I'll commit it tomorrow.
The other thing I forgot to mention was that all the data on CPU IDs came from the existing code and this site: http://processorfinder.intel.com. Some of them are a bit unclear on what sockets they use, but if anything comes up wrong, we can easily correct it.
-Corey
On 11.01.2008 02:33, Corey Osgood wrote:
joe@smittys.pointclark.net wrote:
Quoting Corey Osgood corey.osgood@gmail.com:
Do you mean the microcode files? If so, the microcode update looks like this:
Header Update Revision Date Processor Signature (CPU ID) ...
So, the 4th entry in the update is always the CPU ID, and conveniently it's always the last one on the first line. It also makes grepping for them very easy, once you have the update broken down into smaller files. This is documented *somewhere* in LB, but I can't find it at the moment. It's also in the Intel architecture manual, volume 3a, table 9-6.
In the past we labeled some CPU IDs as to what CPUs they belonged to. In truth, Intel uses the same CPU IDs for a variety of CPUs, for instance in some cases Celeron, Pentium X, and Xeons all share a common ID, since the core is still the same. So we can't really do that any more ;)
Oh ok, that makes sense.
Acked-by: Joseph Smith joe@smittys.pointclark.net
Thanks, Joe. Anyone else have anything to say? Honestly expected more feedback, but if there are no objections I'll commit it tomorrow.
The other thing I forgot to mention was that all the data on CPU IDs came from the existing code and this site: http://processorfinder.intel.com. Some of them are a bit unclear on what sockets they use, but if anything comes up wrong, we can easily correct it.
Do you see any way to solve the "size problem" for sockets with too many different cores? It would also be interesting to find out if your work on stripping duplicate contents gives us new opportunities to reduce size even further.
Regards, Carl-Daniel
Quoting Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net:
Do you see any way to solve the "size problem" for sockets with too many different cores?
Regards, Carl-Daniel
Not sure what you mean? How many different cores could you put in even the most popular socket, three?
Thanks - Joe
On 11.01.2008 02:53, joe@smittys.pointclark.net wrote:
Quoting Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net:
Do you see any way to solve the "size problem" for sockets with too many different cores?
Not sure what you mean? How many different cores could you put in even the most popular socket, three?
No, I was talking about the problems to keep all microcodes available for all processor types that could be plugged into a given socket. To express it another way: "no BIOS changes needed as long as the processor fits electrically and mechanically into the socket". Depending on the socket, that might be a lot of different microcode updates you have to keep in ROM.
Regards, Carl-Daniel
Carl-Daniel Hailfinger wrote:
On 11.01.2008 02:33, Corey Osgood wrote:
joe@smittys.pointclark.net wrote:
Quoting Corey Osgood corey.osgood@gmail.com:
Do you mean the microcode files? If so, the microcode update looks like this:
Header Update Revision Date Processor Signature (CPU ID) ...
So, the 4th entry in the update is always the CPU ID, and conveniently it's always the last one on the first line. It also makes grepping for them very easy, once you have the update broken down into smaller files. This is documented *somewhere* in LB, but I can't find it at the moment. It's also in the Intel architecture manual, volume 3a, table 9-6.
In the past we labeled some CPU IDs as to what CPUs they belonged to. In truth, Intel uses the same CPU IDs for a variety of CPUs, for instance in some cases Celeron, Pentium X, and Xeons all share a common ID, since the core is still the same. So we can't really do that any more ;)
Oh ok, that makes sense.
Acked-by: Joseph Smith joe@smittys.pointclark.net
Thanks, Joe. Anyone else have anything to say? Honestly expected more feedback, but if there are no objections I'll commit it tomorrow.
The other thing I forgot to mention was that all the data on CPU IDs came from the existing code and this site: http://processorfinder.intel.com. Some of them are a bit unclear on what sockets they use, but if anything comes up wrong, we can easily correct it.
Do you see any way to solve the "size problem" for sockets with too many different cores? It would also be interesting to find out if your work on stripping duplicate contents gives us new opportunities to reduce size even further.
Regards, Carl-Daniel
I'm thinking lzma compression, it knocks the files down to about 1/3 their current size or smaller. But I hate to introduce lzma as a requirement, especially just for this one task, and some distros don't have lzma prepackaged. I have already removed all the duplicate updates, so the only option is possibly eliminating more cores, for socket 604, and for lga775 it's either breaking things down into smaller subsets (pentium vs. core, as i mentioned before), or larger flash chips.
joe@smittys.pointclark.net wrote:
Not sure what you mean? How many different cores could you put in even the most popular socket, three?
Thanks - Joe
LGA775 currently has 19 (and may have more I don't know about). Using some rough math, I get a rounded-down size of 186KB (really is quite a bit more) for its updates, and that would go into both normal and fallback images.
-Corey
On Thu, Jan 10, 2008 at 09:34:28PM -0500, Corey Osgood wrote:
How many different cores could you put in even the most popular socket, three?
LGA775 currently has 19 (and may have more I don't know about). Using some rough math, I get a rounded-down size of 186KB (really is quite a bit more) for its updates, and that would go into both normal and fallback images.
I think we need to make it configurable.
//Peter
On Fri, Jan 11, 2008 at 04:34:39AM +0100, Peter Stuge wrote:
On Thu, Jan 10, 2008 at 09:34:28PM -0500, Corey Osgood wrote:
How many different cores could you put in even the most popular socket, three?
LGA775 currently has 19 (and may have more I don't know about). Using some rough math, I get a rounded-down size of 186KB (really is quite a bit more) for its updates, and that would go into both normal and fallback images.
I think we need to make it configurable.
Yep, agreed. You should be able to specify exactly which CPU you want to use and the build process should only include the updates for just that CPU (or list of CPUs if you specify more than one).
Uwe.
Peter Stuge wrote:
On Thu, Jan 10, 2008 at 09:34:28PM -0500, Corey Osgood wrote:
How many different cores could you put in even the most popular socket, three?
LGA775 currently has 19 (and may have more I don't know about). Using some rough math, I get a rounded-down size of 186KB (really is quite a bit more) for its updates, and that would go into both normal and fallback images.
I think we need to make it configurable.
//Peter
I don't like that. With a factory bios, you expect the correct microcode update for your CPU to be present, no matter what CPU you put in a socket. We should be able to do the same.
-Corey
On Fri, Jan 11, 2008 at 09:42:00AM -0500, Corey Osgood wrote:
Peter Stuge wrote:
I think we need to make it configurable.
I don't like that. With a factory bios, you expect the correct microcode update for your CPU to be present, no matter what CPU you put in a socket.
(Actually no, not always.)
We should be able to do the same.
I agree, but we should also try to be even more flexible. I think we should allow inclusion of 0<=n<=all microcode updates. Definately an advanced option, but still.
//Peter
On Fri, Jan 11, 2008 at 03:54:18PM +0100, Peter Stuge wrote:
On Fri, Jan 11, 2008 at 09:42:00AM -0500, Corey Osgood wrote:
Peter Stuge wrote:
I think we need to make it configurable.
I don't like that. With a factory bios, you expect the correct microcode update for your CPU to be present, no matter what CPU you put in a socket.
(Actually no, not always.)
We should be able to do the same.
I agree, but we should also try to be even more flexible. I think we should allow inclusion of 0<=n<=all microcode updates. Definately an advanced option, but still.
Yep, that's what I meant. It's fine if the default is "all microcode updates", but there should be an option for advanced users to only use the one(s) you really want or need in order to save time and space.
Uwe.
Quoting Uwe Hermann uwe@hermann-uwe.de:
On Fri, Jan 11, 2008 at 03:54:18PM +0100, Peter Stuge wrote:
On Fri, Jan 11, 2008 at 09:42:00AM -0500, Corey Osgood wrote:
Peter Stuge wrote:
I think we need to make it configurable.
I don't like that. With a factory bios, you expect the correct microcode update for your CPU to be present, no matter what CPU you put in a socket.
(Actually no, not always.)
We should be able to do the same.
I agree, but we should also try to be even more flexible. I think we should allow inclusion of 0<=n<=all microcode updates. Definately an advanced option, but still.
Yep, that's what I meant. It's fine if the default is "all microcode updates", but there should be an option for advanced users to only use the one(s) you really want or need in order to save time and space.
Uwe.
That makes perfect sense.....I like the advanced option idea:-)
Thanks - Joe
note that on V3, we have the neat ability to put microcode in LAR, and find it there on boot.
So we might have another top level directory: /microcode
And then you can figure out, long after the bios is built, which microcode updates you want to support.
ron
On Fri, Jan 11, 2008 at 05:27:48PM -0800, ron minnich wrote:
note that on V3, we have the neat ability to put microcode in LAR, and find it there on boot.
So we might have another top level directory: /microcode
And then you can figure out, long after the bios is built, which microcode updates you want to support.
A good deal indeed.
//Peter
ron minnich wrote:
note that on V3, we have the neat ability to put microcode in LAR, and find it there on boot.
So we might have another top level directory: /microcode
And then you can figure out, long after the bios is built, which microcode updates you want to support.
ron
This is what I'm thinking, once v3 gets going. For now, I think LGA775 is about to get split, socket 603 works (I forgot that it really does build now, ignore my previous statement), and socket 604, well, I'll try to find out more on exactly what cores were used.
Thanks, Corey
joe@smittys.pointclark.net wrote:
Quoting Uwe Hermann uwe@hermann-uwe.de:
On Fri, Jan 11, 2008 at 03:54:18PM +0100, Peter Stuge wrote:
On Fri, Jan 11, 2008 at 09:42:00AM -0500, Corey Osgood wrote:
Peter Stuge wrote:
I think we need to make it configurable.
I don't like that. With a factory bios, you expect the correct microcode update for your CPU to be present, no matter what CPU you put in a socket.
(Actually no, not always.)
We should be able to do the same.
I agree, but we should also try to be even more flexible. I think we should allow inclusion of 0<=n<=all microcode updates. Definately an advanced option, but still.
Yep, that's what I meant. It's fine if the default is "all microcode updates", but there should be an option for advanced users to only use the one(s) you really want or need in order to save time and space.
Uwe.
That makes perfect sense.....I like the advanced option idea:-)
Thanks - Joe
This seems like it would get very messy, very quickly. The only way I can come up with to do it is #if's for every single ID, perhaps in some intel_custom folder, so it doesn't make a mess of the existing stuff.
Anyways, I'll get on top of testing this weekend, I have slot 1 (440zx), socket 370 (i810), and socket 479 (i830) boards I can test with, assuming they all still work. If those work, I'll bet the farm that the rest of them do. Everything passes abuild, btw.
-Corey
Quoting Corey Osgood corey.osgood@gmail.com:
joe@smittys.pointclark.net wrote:
Quoting Uwe Hermann uwe@hermann-uwe.de:
On Fri, Jan 11, 2008 at 03:54:18PM +0100, Peter Stuge wrote:
On Fri, Jan 11, 2008 at 09:42:00AM -0500, Corey Osgood wrote:
Peter Stuge wrote:
I think we need to make it configurable.
I don't like that. With a factory bios, you expect the correct microcode update for your CPU to be present, no matter what CPU you put in a socket.
(Actually no, not always.)
We should be able to do the same.
I agree, but we should also try to be even more flexible. I think we should allow inclusion of 0<=n<=all microcode updates. Definately an advanced option, but still.
Yep, that's what I meant. It's fine if the default is "all microcode updates", but there should be an option for advanced users to only use the one(s) you really want or need in order to save time and space.
Uwe.
That makes perfect sense.....I like the advanced option idea:-)
Thanks - Joe
This seems like it would get very messy, very quickly. The only way I can come up with to do it is #if's for every single ID, perhaps in some intel_custom folder, so it doesn't make a mess of the existing stuff.
Anyways, I'll get on top of testing this weekend, I have slot 1 (440zx), socket 370 (i810), and socket 479 (i830) boards I can test with, assuming they all still work. If those work, I'll bet the farm that the rest of them do. Everything passes abuild, btw.
-Corey
Yeh, even though it is a good idea it probibly would complicate things alot. For now it may be better to just commit a piece at a time for each processor tested. I'm really interested in how the socket 479 (Pentium M) testing goes. Let us know:-)
Thanks - Joe
joe@smittys.pointclark.net wrote:
Quoting Corey Osgood corey.osgood@gmail.com:
joe@smittys.pointclark.net wrote:
Quoting Uwe Hermann uwe@hermann-uwe.de:
On Fri, Jan 11, 2008 at 03:54:18PM +0100, Peter Stuge wrote:
On Fri, Jan 11, 2008 at 09:42:00AM -0500, Corey Osgood wrote:
Peter Stuge wrote:
> I think we need to make it configurable. > I don't like that. With a factory bios, you expect the correct microcode update for your CPU to be present, no matter what CPU you put in a socket.
(Actually no, not always.)
We should be able to do the same.
I agree, but we should also try to be even more flexible. I think we should allow inclusion of 0<=n<=all microcode updates. Definately an advanced option, but still.
Yep, that's what I meant. It's fine if the default is "all microcode updates", but there should be an option for advanced users to only use the one(s) you really want or need in order to save time and space.
Uwe.
That makes perfect sense.....I like the advanced option idea:-)
Thanks - Joe
This seems like it would get very messy, very quickly. The only way I can come up with to do it is #if's for every single ID, perhaps in some intel_custom folder, so it doesn't make a mess of the existing stuff.
Anyways, I'll get on top of testing this weekend, I have slot 1 (440zx), socket 370 (i810), and socket 479 (i830) boards I can test with, assuming they all still work. If those work, I'll bet the farm that the rest of them do. Everything passes abuild, btw.
-Corey
Yeh, even though it is a good idea it probibly would complicate things alot. For now it may be better to just commit a piece at a time for each processor tested. I'm really interested in how the socket 479 (Pentium M) testing goes. Let us know:-)
Thanks - Joe
I know ;) Uwe, do you have a 440bx board you can try this on? Mine has officially bit the dust. I can say that i810/socket 370 works as expected with 3 different cores. I'll get to the socket 479 if I have time tomorrow, I've been tinkering with the i810 most of the last couple days.
Thanks, Corey
On Mon, Jan 14, 2008 at 05:46:29AM -0500, Corey Osgood wrote:
I know ;) Uwe, do you have a 440bx board you can try this on? Mine has
Yep, will do.
officially bit the dust. I can say that i810/socket 370 works as expected with 3 different cores. I'll get to the socket 479 if I have time tomorrow, I've been tinkering with the i810 most of the last couple days.
Anyone here with an E7520 or similar board?
Uwe.
Am Mon, 14 Jan 2008 15:29:51 +0100 schrieb Uwe Hermann uwe@hermann-uwe.de:
On Mon, Jan 14, 2008 at 05:46:29AM -0500, Corey Osgood wrote:
I know ;) Uwe, do you have a 440bx board you can try this on? Mine has
Yep, will do.
officially bit the dust. I can say that i810/socket 370 works as expected with 3 different cores. I'll get to the socket 479 if I have time tomorrow, I've been tinkering with the i810 most of the last couple days.
Anyone here with an E7520 or similar board?
Uwe.
Only a E7525
Markus
On Tue, Jan 15, 2008 at 06:32:02AM +0100, Markus wrote:
Am Mon, 14 Jan 2008 15:29:51 +0100 schrieb Uwe Hermann uwe@hermann-uwe.de:
On Mon, Jan 14, 2008 at 05:46:29AM -0500, Corey Osgood wrote:
I know ;) Uwe, do you have a 440bx board you can try this on? Mine has
Yep, will do.
officially bit the dust. I can say that i810/socket 370 works as expected with 3 different cores. I'll get to the socket 479 if I have time tomorrow, I've been tinkering with the i810 most of the last couple days.
Anyone here with an E7520 or similar board?
Uwe.
Only a E7525
Perfect. Does it run LinuxBIOS/coreboot? If so, does the microcode patch work on this box? Any problems or regressions?
Thanks, Uwe.
Uwe Hermann wrote:
On Tue, Jan 15, 2008 at 06:32:02AM +0100, Markus wrote:
Am Mon, 14 Jan 2008 15:29:51 +0100 schrieb Uwe Hermann uwe@hermann-uwe.de:
On Mon, Jan 14, 2008 at 05:46:29AM -0500, Corey Osgood wrote:
I know ;) Uwe, do you have a 440bx board you can try this on? Mine has
Yep, will do.
officially bit the dust. I can say that i810/socket 370 works as expected with 3 different cores. I'll get to the socket 479 if I have time tomorrow, I've been tinkering with the i810 most of the last couple days.
Anyone here with an E7520 or similar board?
Uwe.
Only a E7525
Perfect. Does it run LinuxBIOS/coreboot? If so, does the microcode patch work on this box? Any problems or regressions?
Thanks, Uwe.
e75xx are mostly for socket 603/604 xeons. although the patch does add some new socket 603/604 code, it doesn't remove the old code, nor does it point any boards to the new stuff. so this patch shouldn't affect him at all, unless he decides to change it. just from a couple peaks accross the interwebs, it seems most e7525 boards are socket 604, and that doesn't build (yet). I'm putting in a request to intel for more info, i'll update the patch if it helps.
-corey
On Mon, Jan 14, 2008 at 03:29:51PM +0100, Uwe Hermann wrote:
On Mon, Jan 14, 2008 at 05:46:29AM -0500, Corey Osgood wrote:
I know ;) Uwe, do you have a 440bx board you can try this on? Mine has
Yep, will do.
OK, here's my status report, there seem to be some issues.
I tried the current svn on my ASUS P2B-F, works fine. Then I applied the microcode patches and tried to rebuild.
First issue is that I cannot rebuild anymore, linker errors because the code became bigger.
The default in Options.lb is default ROM_IMAGE_SIZE = 64 * 1024 and I had to change the size (in targets/.../Config.lb) to '74 * 1024' in order to fit the increased size. Maybe some smaller value will also work, but '70 * 1024' didn't, so you need something between 70 KB and 74 KB. Before the patches, 64 KB was enough.
The image finally built fine with 74 KB, but didn't boot anymore. It hangs upon the 'Jumping to coreboot' message. Not sure why.
I noticed that the slot_1 directory now includes some HT stuff, in src/cpu/intel/intel_shared/Config.lb: there's now dir /cpu/intel/hyperthreading which wasn't there in the old slot_1 code (slot_2 actually), I think.
But that doesn't seem to be the (only) problem, commenting the # dir /cpu/intel/hyperthreading doesn't help. I tried setting NO_MICROCODE_UPDATES = 1 in the Options.lb and it _seems_ that helped, it's booting again. But of course it doesn't apply the microcode updates in that case.
My test CPU was CPU: family 06, model 07, stepping 03
Uwe.
Uwe Hermann wrote:
On Mon, Jan 14, 2008 at 03:29:51PM +0100, Uwe Hermann wrote:
On Mon, Jan 14, 2008 at 05:46:29AM -0500, Corey Osgood wrote:
I know ;) Uwe, do you have a 440bx board you can try this on? Mine has
Yep, will do.
OK, here's my status report, there seem to be some issues.
I tried the current svn on my ASUS P2B-F, works fine. Then I applied the microcode patches and tried to rebuild.
First issue is that I cannot rebuild anymore, linker errors because the code became bigger.
The default in Options.lb is default ROM_IMAGE_SIZE = 64 * 1024 and I had to change the size (in targets/.../Config.lb) to '74 * 1024' in order to fit the increased size. Maybe some smaller value will also work, but '70 * 1024' didn't, so you need something between 70 KB and 74 KB. Before the patches, 64 KB was enough.
Thanks for testing this out! This is to be expected, unfortunately. I don't like eating another 10K that could be used by FILO for some feature, but it seems necessary. BTW, for some reason, this works fine with abuild, so abuild must set some larger size.
The image finally built fine with 74 KB, but didn't boot anymore. It hangs upon the 'Jumping to coreboot' message. Not sure why.
This sounds like it may be related to the extra wrmsr, whereever that email went, since this sounds like the same issue. There weren't any updates for your CPU before, so it makes sense that the patch would bring the issue up. I put a message out to the list to try and fix it, but never got any response, and I can't seem to reproduce the issue.
I noticed that the slot_1 directory now includes some HT stuff, in src/cpu/intel/intel_shared/Config.lb: there's now dir /cpu/intel/hyperthreading which wasn't there in the old slot_1 code (slot_2 actually), I think.
I looked through the hyperthreading code, and it shouldn't affect CPUs that don't have hyperthreading. IIRC, there's also some sort of block in there that prevents it from doing anything if CONFIG_SMP isn't set.
But that doesn't seem to be the (only) problem, commenting the # dir /cpu/intel/hyperthreading doesn't help. I tried setting NO_MICROCODE_UPDATES = 1 in the Options.lb and it _seems_ that helped, it's booting again. But of course it doesn't apply the microcode updates in that case.
My test CPU was CPU: family 06, model 07, stepping 03
NO_MICROCODE_UPDATES cuts out everything microcode-related, so that's expected, too.
Uwe.
Thanks, Corey
Quoting Corey Osgood corey.osgood@gmail.com:
Carl-Daniel Hailfinger wrote:
On 11.01.2008 02:33, Corey Osgood wrote:
joe@smittys.pointclark.net wrote:
Quoting Corey Osgood corey.osgood@gmail.com:
Do you mean the microcode files? If so, the microcode update looks like this:
Header Update Revision Date Processor Signature (CPU ID) ...
So, the 4th entry in the update is always the CPU ID, and conveniently it's always the last one on the first line. It also makes grepping for them very easy, once you have the update broken down into smaller files. This is documented *somewhere* in LB, but I can't find it at the moment. It's also in the Intel architecture manual, volume 3a, table 9-6.
In the past we labeled some CPU IDs as to what CPUs they belonged to. In truth, Intel uses the same CPU IDs for a variety of CPUs, for instance in some cases Celeron, Pentium X, and Xeons all share a common ID, since the core is still the same. So we can't really do that any more ;)
Oh ok, that makes sense.
Acked-by: Joseph Smith joe@smittys.pointclark.net
Thanks, Joe. Anyone else have anything to say? Honestly expected more feedback, but if there are no objections I'll commit it tomorrow.
The other thing I forgot to mention was that all the data on CPU IDs came from the existing code and this site: http://processorfinder.intel.com. Some of them are a bit unclear on what sockets they use, but if anything comes up wrong, we can easily correct it.
Do you see any way to solve the "size problem" for sockets with too many different cores? It would also be interesting to find out if your work on stripping duplicate contents gives us new opportunities to reduce size even further.
Regards, Carl-Daniel
I'm thinking lzma compression, it knocks the files down to about 1/3 their current size or smaller. But I hate to introduce lzma as a requirement, especially just for this one task, and some distros don't have lzma prepackaged. I have already removed all the duplicate updates, so the only option is possibly eliminating more cores, for socket 604, and for lga775 it's either breaking things down into smaller subsets (pentium vs. core, as i mentioned before), or larger flash chips.
joe@smittys.pointclark.net wrote:
Not sure what you mean? How many different cores could you put in even the most popular socket, three?
Thanks - Joe
LGA775 currently has 19 (and may have more I don't know about). Using some rough math, I get a rounded-down size of 186KB (really is quite a bit more) for its updates, and that would go into both normal and fallback images.
-Corey
Wow I guess I didn't realize LGA775 had so many.....
Thanks - Joe
On Tue, Jan 08, 2008 at 09:36:20PM -0500, Corey Osgood wrote:
Both patches Signed-off-by: Corey Osgood corey.osgood@gmail.com
I checked that this doesn't break abuild, so far so good.
On which hardware has this been tested so far? I'm reluctant to commit this without some broader testing on actual hardware. I'd say at least some of the 440BX boards, i810, and others.
I can test some of the above soonish I hope, but someone with server-grade boards should probably also do some tests (E7520 boards and similar).
Index: src/cpu/intel/microcode/2107-m406fbB4.inc
--- src/cpu/intel/microcode/2107-m406fbB4.inc (revision 0) +++ src/cpu/intel/microcode/2107-m406fbB4.inc (revision 0) @@ -0,0 +1,266 @@ +/**
- Copyright Intel Corporation, 1995, 96, 97, 98, 99, 2000, 01, 02,
- 03, 04, 05, 06, 07.
- These microcode updates are distributed for the sole purpose of
- installation in the BIOS or Operating System of computer systems
- which include a Genuine Intel microprocessor sold or distributed
- to or by you. You are not authorized to use this material for
- any other purpose.
+**/
Where exactly do these files come from (URL on intel.com?) We should document this in either the files and/or the wiki.
I know about http://www.urbanmyth.org/microcode/ http://people.debian.org/~cate/files/microcode/ is that the source?
There's also some stuff at http://downloadcenter.intel.com/detail_desc.aspx?strstate=live&productid... for example, which has a different license header, though:
/+++ / Copyright (c) <1995-2008>, Intel Corporation. / All rights reserved. / / Redistribution. Redistribution and use in binary form, without modification, are / permitted provided that the following conditions are met: / .Redistributions must reproduce the above copyright notice and the following / disclaimer in the documentation and/or other materials provided with the / distribution. / .Neither the name of Intel Corporation nor the names of its suppliers may be used / to endorse or promote products derived from this software without specific prior / written permission. / .No reverse engineering, decompilation, or disassembly of this software is / permitted. / ."Binary form" includes any format commonly used for electronic conveyance / which is a reversible, bit-exact translation of binary representation to ASCII or / ISO text, for example, "uuencode." / / DISCLAIMER. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT / HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED / WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED / WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR / PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER / OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, / SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT / NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; / LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER / CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, / STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) / ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF / ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. / / These microcode updates are distributed for the sole purpose of / installation in the BIOS or Operating System of computer systems / which include a Genuine Intel microprocessor sold or distributed / to or by you. You are not authorized to use this material for / any other purpose. /---
+/* Note: It is impossible to tell what Xeons are Socket 603 vs 604 from the info
- on Intel's website. Also, socket 603 CPUs work in 604 systems. Hence,
- combined for good reasons. */
+struct cpu_device_id cpu_table[] = {
- { X86_VENDOR_INTEL, 0x0f0a },
- { X86_VENDOR_INTEL, 0x0f11 },
- { X86_VENDOR_INTEL, 0x0f12 },
- { X86_VENDOR_INTEL, 0x0f22 },
- { X86_VENDOR_INTEL, 0x0f24 },
- { X86_VENDOR_INTEL, 0x0f25 },
- { X86_VENDOR_INTEL, 0x0f26 },
- { X86_VENDOR_INTEL, 0x0f27 },
- { X86_VENDOR_INTEL, 0x0f29 },
- { 0, 0 },
+};
+struct chip_operations cpu_intel_socket_603_ops = {
- CHIP_NAME("Socket 603 CPU")
Shouldn't this be CHIP_NAME("Socket 603/604 CPU") then?
+/* Note: It is impossible to tell what Xeons are Socket 603 vs 604 from the info
- on Intel's website. Also, socket 603 CPUs work in 604 systems. Hence,
- combined for good reasons. */
+struct cpu_device_id cpu_table[] = {
- { X86_VENDOR_INTEL, 0x0f22 },
- { X86_VENDOR_INTEL, 0x0f24 },
- { X86_VENDOR_INTEL, 0x0f25 },
- { X86_VENDOR_INTEL, 0x0f26 },
- { X86_VENDOR_INTEL, 0x0f27 },
- { X86_VENDOR_INTEL, 0x0f29 },
- { X86_VENDOR_INTEL, 0x0f34 },
- { X86_VENDOR_INTEL, 0x0f41 },
- { X86_VENDOR_INTEL, 0x0f43 },
- { X86_VENDOR_INTEL, 0x0f48 },
- { X86_VENDOR_INTEL, 0x0f49 },
- { X86_VENDOR_INTEL, 0x0f4a },
- { 0, 0 },
+};
+struct chip_operations cpu_intel_socket_604_ops = {
- CHIP_NAME("Socket 604 CPU")
Same here?
+/* Note: Intel does not explicitly state which CPUs are Socket M vs Socket P on their website, but there was a large overlap of the ones I could identify. Hence, this includes all Socket M and P CPUs, along with onboard Core, Core 2, and (Core/Core2 based) Celeron M CPUs, for convenience's sake */
Line is too long.
+struct cpu_device_id cpu_table[] = {
- { X86_VENDOR_INTEL, 0x06e8 },
- { X86_VENDOR_INTEL, 0x06ec },
- { X86_VENDOR_INTEL, 0x06f2 },
- { X86_VENDOR_INTEL, 0x06f6 },
- { X86_VENDOR_INTEL, 0x06fa },
- { X86_VENDOR_INTEL, 0x06fb },
- { X86_VENDOR_INTEL, 0x06fd },
- /* I don't know if we'll be able to see all 5 digits, so both are included */
- { X86_VENDOR_INTEL, 0x10676 },
- { X86_VENDOR_INTEL, 0x0676 },
Add a TODO here maybe, we should find out and fix it.
+/* Slot 1 CPU IDs. Note that the same ID is sometimes used for Celeron,
- Pentium, and Xeon families, in various packages. This also includes
- Mobile Pentium II and Celeron families */
+struct cpu_device_id cpu_table[] = {
Maybe const struct cpu_device_id cpu_table[] = {
(same for most other files)
+u32 microcode_updates[] = {
These arrays can be const too, I guess.
Index: src/cpu/intel/intel_shared/intel_init.c
--- src/cpu/intel/intel_shared/intel_init.c (revision 0) +++ src/cpu/intel/intel_shared/intel_init.c (revision 0) @@ -0,0 +1,53 @@ +#include <console/console.h> +#include <device/device.h> +#include <device/pci.h> +#include <string.h> +#include <cpu/cpu.h> +#include <cpu/x86/mtrr.h> +#include <cpu/x86/msr.h> +#include <cpu/x86/lapic.h> +#include <cpu/intel/microcode.h>
+#ifdef CONFIG_SMP +#if CONFIG_SMP
Why both?
Index: src/cpu/intel/intel_generic/intel_generic.c
--- src/cpu/intel/intel_generic/intel_generic.c (revision 0) +++ src/cpu/intel/intel_generic/intel_generic.c (revision 0) @@ -0,0 +1,85 @@ +#define NO_MICROCODE_UPDATES +#include "../intel_shared/intel_init.c" +#include "chip.h"
+/* CPU IDs for all >=PPro x86 and x86_64 Intel CPUs, as of 12/30/2007, without
- the microcode updates. Microcode updates should be done later, with recent
- kernels this is done automatically, just put the latest microcode update file
- in /etc/firmware */
+struct cpu_device_id cpu_table[] = {
+/* TODO!!! */
What exactly?
Index: src/mainboard/a-trend/atc-6220/Config.lb
--- src/mainboard/a-trend/atc-6220/Config.lb (revision 3036) +++ src/mainboard/a-trend/atc-6220/Config.lb (working copy) @@ -82,7 +82,7 @@
chip northbridge/intel/i440bx # Northbridge device apic_cluster 0 on # APIC cluster
- chip cpu/intel/slot_2 # CPU (FIXME: It's slot 1, actually)
- chip cpu/intel/slot_1 # CPU device apic 0 on end # APIC end end
Nice, thanks. This was on my TODO list, too.
Uwe.
-
Carl-Daniel Hailfinger -
Corey Osgood -
joe＠smittys.pointclark.net -
Markus -
Peter Stuge -
ron minnich -
Uwe Hermann