Issue #460 has been updated by Angel Pons.
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. ---------------------------------------- Refactoring #460: Make mainboards using the variant concept https://ticket.coreboot.org/issues/460#change-1443 * Author: Felix Singer * Status: New * Priority: Normal * Target version: none * Start date: 2023-02-14 ---------------------------------------- * asrock/ivybridge * asrock/b75pro3-m * asrock/h77pro4-m -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
