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

[Tom Rini]

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.

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

-- 
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/20260327/44974dee/attachment.sig>