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

[Simon Glass]

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?

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

Regards,
Simon