Hi Tom, On Fri, 14 Nov 2025 at 07:34, Tom Rini <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> > > > > > --- > > > > > 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
