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

Sun Apr 5 14:13:29 CEST 2026

Hi Tom,

On Fri, 27 Mar 2026 at 10:53, Tom Rini <trini at konsulko.com> wrote:
>
> On Thu, Mar 26, 2026 at 01:46:24PM -0600, Simon Glass wrote:
> > 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.
>
> Yes, I ran the lab job (via the UI instead) in that case and I'm not
> sure what you're missing in how you've got your lab setup.

Just to check, did you pass SJG_LAB=1 when you pushed to the pipeline?

>
> > > > > 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.
>
> You've outlined a direction above that I don't think is good for the
> project as a whole which is why I don't want to encourage it by adding
> more machines that will only ever work in your version of labgrid and so
> it not replicable for others. I don't think anything you're describing
> above can't be done today without making upstream changes and that
> you've designed yourself in to a corner.

Here are the main things that are absolutely required:
- USB drivers for Tegra, Samsung and Sunxi
- Servo driver (for Chromebooks)
- Internal terminal, so that boot output is not lost for some boards
(I believe we discussed this issue at some length but you have not
seen this problem yourself)
- Update U-Boot strategy to support sending over USB and different
reset/recovery combinations, as well as things like colibri-mx8 which
need some work-arounds

I have PRs up for the first three.

Re the last point, I suspect you would argue for separate 'labgrid'
commands to power on, set reset/recovery, do delays, etc. But that
logic needs to live...somewhere.

It is certainly possible for others to replicate the setup[1]. I went
to a lot of trouble to document it carefully, too. I did a rebase a
few days ago.

As to the direction, I would like to see some progress on the existing
PRs first, since without that I would only be able to support a small
subset boards anyway.

I do have concerns about performance too. How long does it take to run
a smoke test for a typical board in your lab?

The main issue is that Labgrid's support for multiple boards in the
environment is incomplete, but it is improving, e.g. [2]. When I asked
about this I was told that I should be using a separate environment
file for each board. I suspect I could move in that direction with a
bit more tooling.

I'd also like to move the scripts to Python. For your lab, do you have
scripts for interactive use, smoke test, running pytests, etc.?

Simon

[1] https://github.com/labgrid-project/labgrid/pull/1411
[2] https://github.com/labgrid-project/labgrid/issues/1194