[U-Boot] Sharing a hardware lab

[Heiko Schocher]

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?

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?

If you trigger the test with tbot, it should be easy to add a locking
mechanism into tbots lab specific function power_check() [1]

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.

bye,
Heiko

[1] https://github.com/Rahix/tbot/blob/master/tbot/machine/board/board.py#L58
-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: hs at denx.de