Thanks everyone for this great discussion. I looked at making Transformers a variant of Archer City CRB, but came to the conclusion that others foresaw which is that a multi-vendor variant model is not a good fit in this case.
In this case the SOC support is new to the tree and we have boards developed in parallel by multiple entities, so it's unsurprising to see some redundant bits. As Angel mentioned it will be easier to refactor portions of the code with the large patches merged in a buildable and (hopefully) usable/testable state.
On Tue, Jun 20, 2023 at 1:51 AM Lean Sheng Tan sheng.tan@9elements.com wrote:
Thanks again everyone for chipping in, this was a pleasant discussion (a bit surprise to me TBH :D ) I agree with Nico and Ron, and also with Angel's suggestion. For now, we can let the MB code go in first, and if there is something in common we can always restructure it, like we used to before. But if I understand correctly on how usually ODM/OEM boards evolves, the first generation will usually be much closer to Intel CRB, but there will be a few more variants of MB to be chucked out later on under same vendor, so it makes perfect sense to let it host under individual vendor folder.
On Tue, 20 Jun 2023 at 00:47, ron minnich rminnich@gmail.com wrote:
There have always been two approaches to new mainboards in coreboot.
The first, "copy and convert", is to take the most similar board, copy the code, and then change it. I believe this is the strategy paul is unhappy with.
The second, "embrace and extend", is to modify existing board in place to support a new board.
The question of "copy and convert" vs "extend and embrace" has come up many times in the last 23 years. There are no ideal answers, we have found.
When the boards are variants from a single vendor, it can work well. chromebook boards are a good example. One vendor will (we hope) make sure that, as new variants are added, they do not break old variants.
We've had trouble over the years merging boards from different vendors. Even in the simple case, with similar boards from more than one vendor, a merged board will look like the union, with a greatly expanded set of build options. But in some early coreboot experience, e.g. with Opteron ca 2004, we found that some options were incompatible. CKE was a big pain.
In the earliest days, we did make an effort to have common code for similar boards. Problems arose as boards from one vendor changed in ways incompatible with other vendors. We saw this from the beginning with boards that used SiS 630 chipsets, which led to a panic debug session for SC 2000 as we dealt with a new board, allegedly compatible with an earlier board, which had some key differences that could not be accommodated in a single board source tree. We went with copy and convert.
I think it's great to have as much common code as possible. But calling an inventec board and a bytedance board variants just because they happen to use SPR? I think that's a mistake.
On Mon, Jun 19, 2023 at 2:02 PM Paul Menzel pmenzel@molgen.mpg.de wrote:
Dear Martin,
Thank you very much for taking the time to answer.
Am 19.06.23 um 22:31 schrieb Martin Roth:
Duplicated code between mainboards isn't a big issue in my opinion. It allows the boards to be customized without worrying about other companies' mainboards. We've tried to make mainboards as small as we can, and we can keep refactoring things out where it makes sense.
Are you talking in general or in this specific SRP boards. As stated by others, a lot of code was copy-pasted.
If some common code fits under the SoC, that's great, and I'm all for moving it there, but let's not force the burden of that refactoring work onto inexperienced mainboard maintainers. Doing so just encourages vendors to keep their mainboards in private repositories - the opposite of what we should be working for. Even if this means that it doesn't get refactored and gets a bit out-of-date, I find that preferable to making contributors (more) frustrated about getting their boards accepted.
I haven’t seen any frustration. Do you know more? I agree, nobody should be frustrated. The question has to be answered though, who is going to do that general maintenance work – I think Kyösti raised a similar question a few weeks back. I welcome all new contributors, but it has to be clear, that coreboot – especially for commercial offerings – needs and expects some kind of maintenance commitment. I am pretty sure, the vendors are going to understand the benefits. It just has to be communicated transparently.
CRBs are (as the name says) reference boards and it should be absolutely fine to duplicate their code when another mainboard vendor uses the CRB as their base - that's what the CRB is for - as an example. Forcing the board to be under the intel vendor directory tells me that intel is responsible for the board, when that isn't the case.
Isn’t `MAINTAINERS` the source for the responsibilities?
In my opinion, Mainboards should be free to customize anything and everything in their directories without having to worry about what other mainboards are affected. I think for the most part, variants should be reserved for duplicates that are owned/maintained by the same vendor. Whitelabel vendors like Clevo can be an exception to this, but the chip vendors' CRBs should not be forced as a baseboard for some other company's design.
Well, that is the thing to discuss. What differences are there going to be and can variants be extended or a new model be found to make it easier to maintain the hopefully vast number of new server boards?
Maybe Angel’s suggestion to submit the boards and then refactor is good. The other way would be to try variants first, and if that does not work, split them out. I’d welcome, that there is some commitment for further work on that though, and I try to avoid that the AGESA experience repeats, where coreboot didn’t want to frustrate AMD and trusted AMD’s promises, but, due to whatever reasons, it only resulted in frustration in the project itself.
Kind regards,
Paul _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org