Upstream all models to coreboot

[ghost]

I was wondering why the lemp9 is current the only device from you which is upstream in the Coreboot Repo

In this Repo and firmware-open Repo

• addw1
• addw2
• bonw14
• darp5
• darp6
• darp7
• galp2
• galp3
• galp3-b
• galp3-c
• galp4
• galp5
• gaze14
• gaze15
• gaze16
• lemp9
• lemp10
• oryp5
• oryp6
• oryp7
• oryp8

Why the are all not upstream in Coreboot? I think it's good that you develop Coreboot for these models, but I don't think it's good that they don't go upstream into Coreboot.

You (and other OEMs) are use Barebones from Clevo.

[jackpot51]

We try, but there are drivers to upstream and some are still unapproved

[c0d3z3r0]

@jackpot51 what drivers are you referring to?

[c0d3z3r0]

• https://review.coreboot.org/c/coreboot/+/43614 - you have a TODO
• https://review.coreboot.org/c/coreboot/+/46300 - system76 failed to adapt the commit message and did not respond
• https://review.coreboot.org/c/coreboot/+/43615 - no response from system76 since July; TODO on your side: make driver generic
• https://review.coreboot.org/c/coreboot/+/43616 - rework after review needed; no response from system76 since August
• https://review.coreboot.org/c/coreboot/+/35802 - rework after review needed; no reponse from system76

So, you see, it's not our fault but yours ;)

[ghost]

@jackpot51 Please leave the Issue open until the most models are upstream
@c0d3z3r0 In my opinion, this does not shed any good light on System76

[jackpot51]

Since it is one of our goals to upstream every supported model, I will reopen this issue.

Our priority is to develop open source, production quality firmware for our products. We do this regardless of upstream constraints. We sometimes work around missing features or bugs in upstream in ways that are not acceptable for upstream patches, such as https://review.coreboot.org/c/coreboot/+/43615. Preparing such patches for upstream is time consuming, and does not change the end user experience. This means that while there are outstanding issues or new models to develop, preparing such patches for upstream is not our highest priority.

So please understand that while our goal is to move all of the changes upstream that are required to build production quality firmware for our products, this goal is one that is often sidelined by the need to have the production quality firmware in the first place. We perform all pre-release product development absolutely in the open under either the license of the project or GPLv3, even though this is not necessary for compliance until products begin to ship to end users. For us to continue to do this, it is required that we are able to stage changes in our own fork of the project which we use to produce the first versions of production firmware. This model worked well with the lemp9, which was the first system upstreamed.

The upstreaming process of the next two products, the oryp6 and bonw14, has been stalled due to issues with the NVIDIA Optimus and I2C smart amp patches mentioned above. We do not have a good method to make the NVIDIA Optimus patch generic at this time, but are hoping that the PCIe RTD3 patches recently submitted for use on TGL-U products will serve as a good base for this functionality. When we have solutions to upstream review comments, these solutions will be uploaded as new patches.

[crawfxrd]

All non-TGL boards now have an upstream MR. Most are WIP as I do not have the model with me to test on.

[crawfxrd]

Models have been rebased and TGL-U models have been added.

[crawfxrd]

Good enough. Most will be in the upcoming 4.15 release.

bonw14 support is questionable due to it only having NVIDIA graphics, and being a PITA to flash if something goes wrong.
gaze16 and oryp8 may still have more changes to be upstreamed. (Or maybe TGL in general; we need to figure out what's up with TBT.)