On Thu, Aug 29, 2024 at 09:02:38AM -0600, Simon Glass wrote: > Hi Neil, > > On Thu, 29 Aug 2024 at 08:44, <neil.armstr...@linaro.org> wrote: > > > > On 29/08/2024 14:17, Simon Glass wrote: > > > Hi Peter, > > > > > > On Thu, 29 Aug 2024 at 04:43, Peter Robinson <pbrobin...@gmail.com> wrote: > > >> > > >> On Wed, 28 Aug 2024 at 22:25, Simon Glass <s...@chromium.org> wrote: > > >>> > > >>> Hi Peter, > > >>> > > >>> On Wed, 28 Aug 2024 at 12:14, Peter Robinson <pbrobin...@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 <s...@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. > > > > > > I am somewhat familiar with LAVA and I believe it can be used to test > > > U-Boot, although I need to learn how. Looking at a test run [2] for > > > beaglebone black I see that it is using a recent kernel but the U-Boot > > > seems to be older. > > > > > >> > > >> 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 > > > > > > Yes. I had heard from Tom that Labgrid is the new hotness for now. > > > Having dug into it I believe it is a good solution, although it can > > > certainly be improved to handle scale better. > > > > > > Anyway, IMO the current test hooks are not a great solution, just > > > because the configuration is spread all over the place and it relies > > > on lots of little shell scripts. So I believe that the Labgrid > > > integration is a closer to where we want to be with others that come > > > along. > > > > I'd say all those scripts are actually here to ease integration with any > > system, booting U-Boot and Linux are two different beasts. > > That's fine, go ahead and use the scripts. My point is that Labgrid > doesn't need them and in fact it makes everything pretty painful if we > try to use all of them.
I guess I really need to clean-up and post my former co-workers scripts as I strongly disagree with that statement. The only "painful" part is the shared pain, regardless of framework, for "put blob $X at location $Y", which I believe you abstract out in to python? -- Tom
signature.asc
Description: PGP signature
