Refactoring #460
openMake mainboards using the variant concept
Added by Felix Singer almost 2 years ago. Updated over 1 year ago.
0%
Description
- asrock/ivybridge
- asrock/b75pro3-m
- asrock/h77pro4-m
Updated by akjuxr3 akjuxr3 almost 2 years ago
Felix Singer wrote:
asrock/ivybridge
- asrock/b75pro3-m
- asrock/h77pro4-m
asrock/haswell
- asrock/b85m_pro4
- asrock/h81m-hds
I vote against renaming any x7x board to ivybridge. Ivybridge is the CPU you put into the x7x board. Not the board itself.
If you put a sandybridge CPU into the socket of the h77pro4-m, then its still ivybridge? No.
If you put a ivybridge CPU into a Thinkpad T420 (coreboot add support for ivybridge) is it then suddenly ivybridge? More likely, but still not really.
Please dont do such a renaming. Its also unclear what scheme it would follow in the future. Would then also all H61 boards get suddnely renamed to 'ivybridge' because they support such CPU's? I hope not.
If creating a group of the 70-series chipset is the goal, please name it x7x. It would follow the scheme coreboot have for years with the x4x mainboard series.
Your example would then look like this:
asrock/x7x
- asrock/b75pro3-m
- asrock/h77pro4-m
asrock/x8x
- asrock/b85m_pro4
- asrock/h81m-hds
Updated by Nicholas Chin almost 2 years ago
akjuxr3 akjuxr3 wrote in #note-1:
I vote against renaming any x7x board to ivybridge. Ivybridge is the CPU you put into the x7x board. Not the board itself.
If you put a sandybridge CPU into the socket of the h77pro4-m, then its still ivybridge? No.
If you put a ivybridge CPU into a Thinkpad T420 (coreboot add support for ivybridge) is it then suddenly ivybridge? More likely, but still not really.
While I don't disagree with this sentiment, the 7-series (Panther Point) chipsets are most closely associated with the Ivy Bridge series of CPUs. The coreboot codebase also doesn't really make a distinction between Sandy Bridge and Ivy Bridge, as they are essentially identical from a code point of view. Both of them are supported by code in src/northbridge/intel/sandybridge
and src/southbridge/intel/bx82x6x
.
Please dont do such a renaming. Its also unclear what scheme it would follow in the future. Would then also all H61 boards get suddnely renamed to 'ivybridge' because they support such CPU's? I hope not.
If creating a group of the 70-series chipset is the goal, please name it x7x. It would follow the scheme coreboot have for years with the x4x mainboard series.
Your example would then look like this:
asrock/x7x
- asrock/b75pro3-m
- asrock/h77pro4-m
asrock/x8x
- asrock/b85m_pro4
- asrock/h81m-hds
The xNx naming scheme also doesn't work in the general case. Because they share a codebase, it's theoretically possible that a 6-series and a 7-series board could be set up as variants with a common base board (it's even possible this has already been done with some boards). There's also chipsets that share an architecture (and thus share a codebase) but do not share the naming scheme, such as Q77 and C216 chipsets. Both of these are Panther Point chipsets but the x7x naming scheme does not capture this. There is even an existing case where boards with these chipsets were set up as variants: src/mainboard/dell/snb_ivb_workstations
which supports the Optiplex 9010 (Q77 chipset) and Precision T1650 (C216 chipset).
So really, without listing every compatible platform in the name, in general there is no succinct way of accurately expressing a particular grouping of platforms which share a codebase but may not share the exact same brandings (CPU family, chipset family, the codenames associated with them, etc) from Intel. So coreboot devs just choose a name that works well enough, otherwise we would need to resort to absurdly long names that accurately captures everything or duplicate code by forcing separate directories to be created for parts with incompatible names but otherwise compatible code. Yes, it makes things more confusing to navigate using the folder structure but I think that's already been accepted as a reality given the naming of the chipset directories and usage of the variant scheme for mainboards.
Updated by Nico Huber almost 2 years ago
It's actually quite simple to put an accurate name on it: Use something that is soldered to the mainboard. In case of platform code that supports multiple chipsets, it's usually the CPU socket that they have in common. lga1155
should work here and similar names are used already in the tree.
Updated by Nico Huber almost 2 years ago
I mean lga1155
and lga1150
respectively.
Updated by akjuxr3 akjuxr3 almost 2 years ago
The xNx naming scheme also doesn't work in the general case.
I know. In x4x the best example is the Intel X48 chipset. Its not supported by coreboot. Reason for not supporting it is that its completely different generation. Its x3x-generation (X38) renamed and tuned by intel. But still collide into the x4x coreboot naming.
But my point is, that naming x4x like its named is better, then if it were named for example c2d (for core 2 duo) or c2q (for core 2 quad). You can stick your socket 771 hardwaremodded intel xeon (the CPU) in this boards without any modification to the x4x board. Also different generations of cpu codenames work with the x4x codebase.
There's also chipsets that share an architecture (and thus share a codebase) but do not share the naming scheme, such as Q77 and C216 chipsets. Both of these are Panther Point chipsets but the x7x naming scheme does not capture this.
Yes, you are correct. Thanks for mentioning this.
otherwise we would need to resort to absurdly long names that accurately captures everything or duplicate code by forcing separate directories to be created for parts with incompatible names but otherwise compatible code.
My point was not about the naming-lenght. It is about naming it about something that is not a general part of the thing the code is written for.
Yes, it makes things more confusing to navigate using the folder structure but I think that's already been accepted as a reality given the naming of the chipset directories and usage of the variant scheme for mainboards.
My point is not about the simplicity of navigation in the folders. It was about naming it about something that is not a general hardwarepart(cpu) of the thing the code is written for(the mainboard).
It's actually quite simple to put an accurate name on it: Use something that is soldered to the mainboard. In case of platform code that supports multiple chipsets, it's usually the CPU socket that they have in common. lga1155 should work here and similar names are used already in the tree.
Perfect! This also include the C216 chipsets. The coreboot codebase is then in general understandable (not naming it after parts (CPUs) that are not part of the hardwareproduct the code is written for) again like it is in x4x and like its wished its combined in one directory.
Then it would be nice and consistent when
src/mainboard/dell/snb_ivb_workstations
could be renamed to src/mainboard/dell/lga1155_workstations
Updated by Angel Pons over 1 year ago
akjuxr3 akjuxr3 wrote in #note-5:
The xNx naming scheme also doesn't work in the general case.
I know. In x4x the best example is the Intel X48 chipset. Its not supported by coreboot. Reason for not supporting it is that its completely different generation. Its x3x-generation (X38) renamed and tuned by intel. But still collide into the x4x coreboot naming.
But my point is, that naming x4x like its named is better, then if it were named for example c2d (for core 2 duo) or c2q (for core 2 quad). You can stick your socket 771 hardwaremodded intel xeon (the CPU) in this boards without any modification to the x4x board. Also different generations of cpu codenames work with the x4x codebase.
The most precise name for the set of northbridges supported by northbridge/intel/x4x
is "eaglelake", the codename. Even "4-series" can be confusing, because there's X48 (codename "bearlake", which includes 3-series desktop northbridges) as well as the mobile northbridges (northbridge/intel/gm45
, officially known as "Mobile 4-series" and codename "cantiga") which are different beasts.
That being said, we don't usually rename chipsets. We did rename "nehalem" to "ironlake", however, as the original name was incorrect. The code does not support any 45nm Nehalem CPUs, but rather Arrandale mobile processors consisting of a 32nm Westmere dual-core CPU die and a 45nm integrated northbridge die (we've tested the code on a desktop Clarkdale processor, raminit isn't happy about it). See https://en.wikipedia.org/wiki/Westmere_(microarchitecture) https://en.wikipedia.org/wiki/Arrandale and https://en.wikipedia.org/wiki/Clarkdale_(microprocessor) for more information.
There's also chipsets that share an architecture (and thus share a codebase) but do not share the naming scheme, such as Q77 and C216 chipsets. Both of these are Panther Point chipsets but the x7x naming scheme does not capture this.
Yes, you are correct. Thanks for mentioning this.
And the codebase is also shared with 6-series PCHs, which include "UP server" (uniprocessor server, the term Intel uses to refer to servers using the same technology as "client" desktops) PCHs. It's hard to pick a name in such cases. Typically, the name for the older generation is used because support for the newer generation gets added later. This is the case for cpu/intel/haswell
, which now supports Broadwell as well.
otherwise we would need to resort to absurdly long names that accurately captures everything or duplicate code by forcing separate directories to be created for parts with incompatible names but otherwise compatible code.
My point was not about the naming-lenght. It is about naming it about something that is not a general part of the thing the code is written for.
Naming can be difficult. There's several HP laptops supported under mainboard/hp/snb_ivb_laptops
for lack of a better name. Besides the CPU and chipset, the only other thing they have in common is the SMSC KBC1126 EC.
Yes, it makes things more confusing to navigate using the folder structure but I think that's already been accepted as a reality given the naming of the chipset directories and usage of the variant scheme for mainboards.
My point is not about the simplicity of navigation in the folders. It was about naming it about something that is not a general hardwarepart(cpu) of the thing the code is written for(the mainboard).
Simplicity of navigation doesn't change much when using variants, it's more that the specific supported models are less visible. This can be compensated by improving the supported boards list. Given that board-status got a rewrite in Go recently, it should be easier than ever to add proper support for variants (per-variant board_info.txt
parsing, for instance).
It's actually quite simple to put an accurate name on it: Use something that is soldered to the mainboard. In case of platform code that supports multiple chipsets, it's usually the CPU socket that they have in common. lga1155 should work here and similar names are used already in the tree.
Perfect! This also include the C216 chipsets. The coreboot codebase is then in general understandable (not naming it after parts (CPUs) that are not part of the hardwareproduct the code is written for) again like it is in x4x and like its wished its combined in one directory.
It's reasonable, but there's some pitfalls. First of all, there's two incompatible types of LGA1151 socket: the Skylake/Kaby Lake LGA1151 and the Coffee Lake LGA1151). Moreover, there can be variant setups with laptops using a soldered-down CPU and a socketed CPU (would happen most often on Sandy/Ivy Bridge and earlier platforms), e.g. ThinkPads. In such cases, the socket wouldn't be common. But we can cross the bridge when we get there.
Then it would be nice and consistent when
src/mainboard/dell/snb_ivb_workstations
could be renamed to src/mainboard/dell/lga1155_workstations
It's very likely that this name was chosen because of the aforementioned HP laptops. Regarding consistency, one hard lesson we've learned after nearly five years of contributing to coreboot is that maintaining consistency across the entire project is impossible when so many different people contribute. There are many valid ways to do things; it's possible that an approach that is optimal for a certain situation happens to be far from optimal in a similar yet different situation.