[PATCH] CI: Update sjg lab to match currently actively boards

[Tom Rini]

On Thu, Mar 26, 2026 at 05:44:29AM -0600, Simon Glass wrote:
> Hi Tom,
> 
> On Wed, 25 Mar 2026 at 14:18, Tom Rini <trini at konsulko.com> wrote:
> >
> > On Tue, Mar 17, 2026 at 07:18:35AM -0600, Simon Glass wrote:
> >
> > > Various updates:
> > > - c4 lack signing so does not currently build
> > > - samus hardware is non-functional
> > > - colibrimx8, rockpro64, rock3a, rock5b, rpi5, tk1 and play are new
> > >
> > > Signed-off-by: Simon Glass <sjg at chromium.org>
> > >
> > > ---
> > > A sample run is here:
> > >
> > > https://source.denx.de/u-boot/custodians/u-boot-dm/-/pipelines/29552
> > >
> > > At present, coral, play, rpi5, snow and vf2 appear to be genuinely
> > > broken on -next
> > >
> > > The ff3399 board needs some investigation.
> > >
> > >  .gitlab-ci.yml | 46 ++++++++++++++++++++++++++++++++++++----------
> > >  1 file changed, 36 insertions(+), 10 deletions(-)
> >
> > I have two sets of problems with this patch.
> >
> > One, it doesn't do, but perhaps I wasn't clear enough when bringing it
> > up, change it so that failure to pass is a job failure (it's currently a
> > warning). This in turn means people can't tell expected failure from new
> > failure.
> 
> It looks the same as sage...can you post a snippet of what the rules should
> be? It shows failure for me, when the lab fails.

https://source.denx.de/u-boot/u-boot/-/pipelines/29670 shows a bunch of
warning for failed boards.

> > Two, when you had previously gone about adding at least colibrimx8 I
> > noted that this extended how you were having labgrid build U-Boot in an
> > even further non-upstreamable manner. As the sage lab yaml shows, we can
> > bring in external binaries for buildman (and binman) to find and use.
> > We'll need to extend that logic a bit, to be sure, but it's a solvable
> > problem with the baseline already there.
> 
> Not quite. Buildman builds U-Boot, it's just kicked off by Labgrid (via a
> U-Boot 'provider' class), with some pre-built Intel binaries for x86, plus
> BL31, etc. put in as environment variables. My design approach is different
> from Sage, in that I often connect to boards interactively, send U-Boot
> over USB in some cases (so different files are needed depending on the
> board) and at the moment I have all boards connected to a single server.
> 
> Labgrid has 90 open PRs, including my terminal one
> <https://github.com/labgrid-project/labgrid/pull/1571> from over a year
> ago. There definitely are PRs getting in though (20 so far this year). In
> terms of upstreaming, my approach has been to break things down into
> smaller PRs, but four of them are still outstanding after 18 months. I did
> ask on irc a few times but didn't get a response.

Yes, your approach requires changes to upstream labgrid, while the
approach I suggested before, and was able to finally get done a while
ago, does not, and still allows for using boards interactively. labgrid
even supports python well so whatever tooling you wanted around labgrid
and building u-boot and anything else could be written in that, instead
of shell, for example.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20260326/3a4bd4d8/attachment.sig>