Hello Simon,

Am 05.02.2020 um 15:10 schrieb Simon Glass:
Hi Tom,

On Wed, 4 Dec 2019 at 15:30, Tom Rini <tr...@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: h...@denx.de

Reply via email to