On Thu, Aug 29, 2024 at 11:43:12AM +0100, Peter Robinson wrote:
On Wed, 28 Aug 2024 at 22:25, Simon Glass sjg@chromium.org wrote:
Hi Peter,
On Wed, 28 Aug 2024 at 12:14, Peter Robinson pbrobinson@gmail.com wrote:
Hi Simon,
With Labgrid we don't need to specify the various methods, except for the console, which simply calls labgrid-client.
This allows supporting any boards in your lab, without adding per-board configuration to these hooks.
Provide ellesmere files as an example.
What's ellesmere?
It is a lake but also the name of a computer.
Signed-off-by: Simon Glass sjg@chromium.org
Changes in v4:
- Support pytest fully with dual-build boards like Beagleplay
Changes in v3:
- Update scripts for latest version of Labgrid integration
- Add poweroff.none and poweron.none
- Provide -n flag when querying board info
- Target the grpc version of Labgrid which is now in -master
- Update README to cover the changes
Changes in v2:
- Make use of the common script (only) to set bin_dir
README.md | 50 ++++++++++++++++++++++++++++++++++++
Maybe that should be in a separate labsgrid readme?
My hope is that Labgrid becomes the normal way of running these tests,
Generally I agree with automated testing platforms, I think <insert you're preferred platform here> makes sense, there's a bunch like Linaro and a bunch in the arm ecosystem use LAVA [1] and there's a bunch more that I'm aware of.
Does it make sense, of course at some point in the future post this being merged, make sense to look at a general way of making it easier to plugin these sort of HW test platforms using this as a basis? I ask mostly because putting a bunch of my devices into some sort of platform can auto test things and of course everyone has an opinion to which is the best one :-P
Well, as the repository stands today, yes, assuming there's a handful of CLI tools for LAVA for "give me console", "change power state" and "write blob to filesystem/location", LAVA could be integrated fairly easily.
The alternative for labgrid support is what I'm using where U-Boot is built outside of test.py, and we have labgrid-client console/power cycle and then more per-SoC "write" scripts (as Pi is different from TI K3 which is different from rockchip ...).