On Sun, Sep 01, 2024 at 02:09:58PM -0600, Simon Glass wrote: > Hi Tom, > > On Fri, 30 Aug 2024 at 08:26, Tom Rini <tr...@konsulko.com> wrote: > > > > On Thu, Aug 29, 2024 at 07:04:36PM -0600, Simon Glass wrote: > > > Hi Tom, > > > > > > On Thu, 29 Aug 2024 at 10:59, Tom Rini <tr...@konsulko.com> wrote: > > > > > > > > On Thu, Aug 29, 2024 at 09:01:17AM -0600, Simon Glass wrote: > > > > > Hi Neil, > > > > > > > > > > On Thu, 29 Aug 2024 at 08:26, <neil.armstr...@linaro.org> wrote: > > > > > > > > > > > > On 29/08/2024 00:08, Simon Glass wrote: > > > > > > > Send the Labgrid quit characters to ask it to exit gracefully. > > > > > > > This > > > > > > > typically allows it to power off the board being used. > > > > > > > > > > > > Sending those characters every time could collide with other CI > > > > > > systems, > > > > > > I don't think it's a good idea. > > > > > > > > > > What systems are you thinking about and what sort of collision would > > > > > occur? > > > > > > > > > > What do you suggest instead? > > > > > > > > Why do we need this at all? Did I miss where we send picocom the > > > > disconnect nicely key-combination? > > > > > > When labgrid gets a signal, it exits. It doesn't continue its > > > co-routines and execute the end strategy to power things off, etc. I > > > suspect it could be made to do that, but I already have 62 Labgrid > > > patches, so I thought this would be expedient... > > > > > > I can make this conditional on the new USE_LABGRID variable. > > > > It sounds to me like we need to make generic improvements to our hooks > > then, if there's not a "now call poweroff" hook. > > The thing is, Labgrid has its own internal console, which allows me to > see all the output from reset. If I use picocom or some other program > then some of the output is gone by the time I connect, particularly > when using USB download. Because of that, just killing Labgrid, which > is what pytest does, is a pretty heavy hammer and leaves things in an > unknown state. So I added this method to give it a software signal.
OK, but we shouldn't care? You can have the console available to pytest and a terminal at the same time, with labgrid. If you need to see before pytest grabs it, have the terminal be the first console, not pytest? This gets back again I think to your specific way of making use of labgrid contrasting with just generally supporting labgrid with however another physical lab has set it up. Does killing one connection really reset all of them? Or was it just a conflict with your auto-acquire/release? -- Tom
signature.asc
Description: PGP signature