Hi Tom, On Fri, 30 Aug 2024 at 08:30, Tom Rini <tr...@konsulko.com> wrote: > > On Thu, Aug 29, 2024 at 07:06:53PM -0600, Simon Glass wrote: > > Hi Tom, > > > > On Thu, 29 Aug 2024 at 13:30, Tom Rini <tr...@konsulko.com> wrote: > > > > > > Hey all, > > > > > > So now that I've posted my u-boot-test-hooks for labgrid: > > > https://patchwork.ozlabs.org/project/uboot/patch/20240829185620.3179866-1-tr...@konsulko.com/ > > > the next relevant parts would be how I use that. There's three scripts, > > > first of which is "uboot-hw-testcycle.sh" : > > > ------------------------ >8 ------------------------ [..] > > > ------------------------ >8 ------------------------ > > > > > > I will say, if there's one thing I don't quite like with how my > > > integrations with labgrid work right now it's that acquire/release is > > > done the way it is. This is where I think Simon's adding another hook is > > > the right direction, if there's not some other hook that can be used and > > > I'm just missing. > > > > Thanks for posting this. I know you had described it but this makes a > > lot of things clearer. > > > > So basically you have set up builds for the different boards and use > > the hook scripts to write them and do the actual power/reset/console > > munging. > > Yes. > > > How do you handle interactive build/run, e.g. to run U-Boot on a > > particular board quickly? > > Well, this is the CI lab, so that's not the primary point. But control-O > in a shell? Some platforms I have a wrapper for, some I don't.
OK. In my case I often want to try things out on particular boards, or at least that is what I have found. Perhaps I will do that less once gitlab is running. Anyway, my point is they use the same mechanism. > > > Also how would gitlab work? > > Similar to how it works in your series, but with more "make the > container build/include firmware blobs for use", most likely. Yes, it should be similar. > > > Re acquire/release, I added a -a option to auto-acquire the place and > > release it afterwards. But if the console dies then so does Labgrid so > > it doesn't release reliably...something to worry about when more > > progress is made. > > Well, that's what pre/post steps are for, IMHO. Yes that's why I added it. I think it is best to keep that, at least until we find it never goes wrong. Regards, Simon
