[PATCH] Gitlab: Add a "sage-lab" stage to access a board farm

[Tom Rini]

On Mon, Nov 17, 2025 at 11:16:05AM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Fri, 14 Nov 2025 at 07:34, Tom Rini <trini at konsulko.com> wrote:
> >
> > On Fri, Nov 14, 2025 at 05:43:57AM -0700, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Tue, 11 Nov 2025 at 06:56, Tom Rini <trini at konsulko.com> wrote:
> > > >
> > > > On Tue, Nov 11, 2025 at 05:58:22AM -0700, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Mon, 10 Nov 2025 at 08:42, Tom Rini <trini at konsulko.com> wrote:
> > > > > >
> > > > > > This is the Gitlab side of adding support for the board lab connected to
> > > > > > the "konsulko-sage" runner. On the software side, this lab uses only
> > > > > > upstream labgrid. On the hardware side, each device under test is
> > > > > > connected to its own exporter (typically a Raspberry Pi 4) that must be
> > > > > > turned on (and cleanly turned off) as part of a given test cycle.
> > > > > >
> > > > > > Add support for testing on a SolidRun Hummingboard 2 (imx6), Raspberry
> > > > > > Pi 3 and Raspberry Pi 4. In all cases, we enable additional options to
> > > > > > run more tests on the board. As we have some networking tests, we test
> > > > > > both the legacy network stack and lwIP. In the case of Pi platforms, we
> > > > > > test all of 32bit configuration, plain configuration and rpi_arm64, and
> > > > > > again with and without lwIP.
> > > > > >
> > > > > > Signed-off-by: Tom Rini <trini at konsulko.com>
> > > > > > ---
> > > > > > Note that for the Pi platforms we enable/disable CMD_BOOTEFI_SELFTEST
> > > > > > based on overall binary size. I've created
> > > > > > https://source.denx.de/u-boot/custodians/u-boot-raspberrypi/-/issues/2
> > > > > > to track addressing that issue.
> > > > > > ---
> > > > > >  .gitlab-ci-sage-lab.yml | 182 ++++++++++++++++++++++++++++++++++++++++
> > > > > >  .gitlab-ci.yml          |   5 ++
> > > > > >  2 files changed, 187 insertions(+)
> > > > > >  create mode 100644 .gitlab-ci-sage-lab.yml
> > > > >
> > > > > Would it be possible to add some docs about this? Does the exporting
> > > > > rpi do a full system boot and then run some scripts to load things
> > > > > onto the board, then shut down?
> > > >
> > > > I don't understand your question. Yes, the exporter is powered on/off in
> > > > the test job, as explained in the commit message. When it comes up it
> > > > registers the device under test with the coordinator (and unregisters
> > > > when powering off).
> > >
> > > So does that mean that all the logic for talking to the board is not
> > > in the hooks or Labgrid, but somewhere else? I'm just trying to
> > > understand how it is put together and compare it with what I did.
> >
> > I still don't understand what you're asking. Maybe you missed the patch
> > that added sage to u-boot-test-hooks as well? That contains the labgrid
> > environment yaml file. The boards are just in labgrid, the exporter
> > registers them with the coordinator when the exporter comes online.
> 
> I saw the hooks patch. But I am missing the logic that actually writes
> U-Boot to the board, powers it on/off, etc. Where is that?

Already in the repository or a different patch I posted for a new SoC.
It's just calls to the appropriate labgrid-client subcommand.

> > And FWIW, this isn't ideally how I'd do the labgrid integration, but
> > tees up the next steps nicely. We need to abstract how our pytest
> > portion grabs console/flashes/etc so that someone could write a python
> > native set of classes (since labgrid supports pytest directly).
> > Iterating on that is easier however when starting with something that
> > works.
> 
> Yes, that would be nice. It would also make it easier to know when to
> expect the board to respond, rather than the long timeouts we have
> today. I started looking at this in June but didn't finish.

I'm not sure how one is connected to the other there, but yes, doing it
all within python might make some cleanup / configuration easier too.

-- 
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/20251117/7eb4d6a0/attachment.sig>