[U-Boot] Sharing a hardware lab
sjg at chromium.org
Wed Feb 12 18:14:32 CET 2020
On Wed, 12 Feb 2020 at 01:50, Heiko Schocher <hs at denx.de> wrote:
> Hello Simon,
> Am 05.02.2020 um 15:10 schrieb Simon Glass:
> > Hi Tom,
> > On Wed, 4 Dec 2019 at 15:30, Tom Rini <trini at konsulko.com> wrote:
> >> On Fri, Nov 29, 2019 at 09:23:43PM -0700, Simon Glass wrote:
> >>> Hi Tom,
> >>> I have been meaning to have a crack at setting up a little hardware
> >>> lab for a while.
> >>> I made some progress recently and hooked up a rpi_3 with sdwire for
> >>> USB/SD, ykush for power and a little computer to control it. It builds
> >>> U-Boot, sticks it on the SD card and runs pytest.
> >>> I pushed a tree here and hopefully you can see the 'hwlab' thing at the end:
> >>> https://gitlab.denx.de/u-boot/custodians/u-boot-dm/pipelines/148
> >>> So far it is just running the 'help' test. It seems to hang with
> >>> serial console problems if I try to do more. It is not 100% reliable
> >>> yet. I based it on Stephen's test hooks:
> >>> https://github.com/sglass68/uboot-test-hooks
> >>> Is it possible to share this so that others can use the lab when they
> >>> push trees? Is it as simple as adding to the .gitlab-ci.yml file as I
> >>> have done here?
> >>> https://gitlab.denx.de/u-boot/custodians/u-boot-dm/blob/gitlab-working/.gitlab-ci.yml
> >>> I also got tbot going in a similar way, to test booting into Linux.
> >>> Should we look at integrating that at the same time? It should be
> >>> fairly easy to do.
> >>> I have quite a lot of random boards and in principle it should not be
> >>> too hard to hook up some more of them, with sufficient SDwires, hubs
> >>> and patience.
> > Bumping this thread as I have now hooked up about about 8 mostly ARM
> > and x86 boards and have tbot and pytest automation mostly working for
> > them.
> Great news!
> added Harald Seiler to cc, as he did the tbot port to python3.6.
> Do you have somewhere your tbot integration online?
But it is tbot only. It would be good if there were a way to upstream
For pytest I am sending upstream to:
BTW I have not yet got tbot to build U-Boot and write it onto the
board. Do you have examples for that?
> I ask because on our ToDo list is to integrate pytest into tbot and may
> we can share work?
> >> There's two parts of this. The first part I think is that we need some
> >> good examples of how to have one private CI job poll / monitor other
> >> public jobs and run. I believe some labs do this today. This would be
> >> helpful as at least personally I'm kicking my hardware tests manually.
> >> This is because as best I can tell there isn't a way to include an
> >> optional stage/portion of a CI job.
> > So the model here is that people with a lab 'watch' various repos? I
> > think that would be useful. Stephen Warren does this I think, but I'm
> > not sure how the builds are kicked off.
> > But what about a full public lab? E.g. is it possible to add some of
> > the boards I have here to every build that people do?
> Here begins the hard game I think, because what happens if 2 builds
> triggered in parallel and want to test a board in the same lab
> at the same time?
The gitlab-runner thing seems to handle that.
> If you trigger the test with tbot, it should be easy to add a locking
> mechanism into tbots lab specific function power_check() 
> May in this power_check() function tbot waits until it get the board...
> The locking mechanism itself is lab specific.
> >> The second part is that long term, we need to most likely develop some
> >> LAVA experience as that will get us easier access to various kernelci
> >> labs and in turn be included in kernelci labs, when the overall SoC and
> >> lab support being able to test firmware.
> > I wonder if these are set up for replacing firmware? It specifically
> > mentions boards getting bricked, so I suspect not.
> Unfortunately I had not yet time for looking into LAVA or kernelci.
I haven't much, but I do wonder if we could add firmware testing to it.
More information about the U-Boot