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

[Simon Glass]

Hi Tom,

On Thu, 26 Mar 2026 at 09:47, Tom Rini <trini at konsulko.com> wrote:
>
> 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.

OK, but how did you generate that? Did you see SJG_LAB=1 for the
pipeline? The rules look the same as sage, but perhaps I am missing
something.

>
> > > 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.

Yes I suspect you are right. One of the design decisions I made was to
put all of the config in one file (the labgrid environment file).
That's not something that the labgrid projects wants.

I really can't operate with an external terminal program though, as it
loses output at the top for some boards. Also I need the USB drivers
and QEMU changes. Perhaps tougher are the changes to the UBootStrategy
to support sending over USB, different power/reset combinations, etc.

If I could get some of these smaller PRs upstream then I could start
to do some rework. But until then I'm not it is worth the effort, as
everything will still be downstream.

I'm definitely keen to replace the shell scripts, probably with
Python. I've had good results with uman being fast to start, having
shell aliases, etc.

Regards,
Simon