Hi Tom,
On Fri, 30 Aug 2024 at 08:30, Tom Rini trini@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 trini@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... 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