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 <rminn...@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 <pmen...@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-le...@coreboot.org >> > _______________________________________________ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org >
_______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
