Hi, On Sun, Mar 1, 2026 at 4:11 PM Nicholas Chin <[email protected]> wrote:
> Hi Abdelkader, > > > As part of modernizing util/autoport to current Go idioms (patch on > Gerrit), I bumped the minimum Go version to 1.26. > > > > This got me thinking about a broader usability improvement: right now > anyone wanting to use autoport to port a new board needs Go installed > locally or do it in another machine. This is the friction i want to remove. > > > > My proposal is add a GitHub Actions workflow that triggers when > util/autoport is modified, builds a static Linux x86_64 binary, and > publishes it as a GitHub release. Contributors can then just download and > run it without setting up a Go toolchain. People who want to compile > everything, still can. > > One note about autoport is that it relies on other utilities in util, > namely ectool, inteltool, and superiotool. So if we want to ship > binaries for autoport, I think it would make sense to also ship binaries > for the other utilities it requires. That said, those are written in C, > and it's less likely someone doesn't have a C compiler compared to Go. > There's one problem: making sure the autoport binary one uses matches the state of the codebase. Although changes to autoport aren't that common, there's the possibility of making a board port with an outdated autoport version. Also, given that there's other utilities written in Go, I don't think it's that much of a big deal. Is it that hard to install a Go toolchain? Do people use Linux From Scratch on the boards they want to port or something? That being said, it would be nice to build-test autoport using the CI. > > Questions before going further: > > - Is there appetite for this in the project? > > I think there could be. We already ship precompiled versions of the > toolchain as a docker container (see coreboot-sdk), though that is only > updated periodically. I'm not sure autoport would work properly in > docker anyway given that some of the utilities it requires need root > permissions and low level hardware access. > > There are some distro packages for coreboot's utils, though I don't > think those are necessarily maintained by coreboot officially. > > > - Can coreboot's GitHub mirror have Actions enabled, or would this > need to live elsewhere? (i know it only a mirror, but that could be enable > exclusively there for all the tooling (I could also see how to do it with > jenkins). > > If we're going to bother with building these in CI, then it probably > would make sense to use our current CI infrastructure and also have it > publish build results to Gerrit. There currently is a gap in build > testing for things like some less common payloads and a lot of the > utils. Setting up CI tests also opens up the door to having autoport ran > against some test inputs to verify that it still functions after a > change to its own code, as well as that it still generates valid code > when changes are made to coreboot's code. There have been a few times > that autoport fell behind changes made to coreboot's code for an > extended period of time. > This kind of problem is something that has been bugging me for years. I think this would be much more valuable than providing precompiled versions of autoport as CI artifacts. It doesn't sound terribly hard to get a decent bit of coverage, either: have some test files in the repo, and have a test action that runs autoport using those and then tries to build the resulting mainboard code. > Cheers, > > Nicholas > _______________________________________________ > coreboot mailing list -- [email protected] > To unsubscribe send an email to [email protected] Best regards, Angel
_______________________________________________ coreboot mailing list -- [email protected] To unsubscribe send an email to [email protected]
