beagle-tester is a utility used to verify some BeagleBoards in production using an open source tool and triggered using either the command-line or a barcode scanner. The test setup is simple and is largely geared at self-test with minimal external requirements.
We are looking to build a cape that would provide significant interfaces to mikroBUS add-on connections opening up a significant amount of additional software testing.
More to come…
Goal: Execution on Beagle test farm with over 30 mikroBUS boards testing all mikroBUS enabled cape interfaces (PWM, ADC, UART, I2C, SPI, GPIO and interrupt) performing weekly mainline Linux regression verification
Hardware Skills: basic wiring, familiarity with embedded serial interfaces
Software Skills: device-tree, using embedded Linux, C, continuous integration with GitLab, Buildroot
Possible Mentors: @jkridner, @lorforlinux, @Anuj_Deshpande , @dhruvag2000
Expected size of project: 350 hour
Upstream Repository: Jason Kridner / Beagle Tester · GitLab
Excited about this project idea! Tooling related projects are immensely helpful but there’s not many opensource projects around it - so it’s hard to get started quickly.
One opensource project which is somewhat that I evaluated on similar lines in the past is Exclave. It might be interesting to try that out and see if there’s something that we can learn from it.
Another project on somewhat similar lines is Autokit by Balena. There’s a nice blog and video explaining how this works here.
It would be indeed cool to have a beagle test farm to ensure all SW Dev is actually working and validated. Looking forward to seeing further details on the hardware setup of how this would work.
I also recently came across Welcome to labgrid’s documentation! — labgrid 23.1a3.dev270 documentation . We can evaluate labgrid if it seems suited for such kind of a task.
Absolutely! Setting up a Beagle test farm for software development sounds like a fantastic idea. Labgrid appears promising too
Hi, can you share how can I start working on this project? I have a bit of experience with embedded linux using beaglebone black and C. What can be a good starting point to learn more and start contributing?
I think a good starting point is looking at the work to build both Debian packages and Buildroot images directly out of the beagle-tester CI. If you aren’t sure what I mean by that, let me know.
The “right” way to build Buildroot is to keep customization out of tree. I think the last place I integrated beagle-tester into Buildroot was Commits · beagle-tester · BeagleBoard.org / Buildroot · GitLab.
I know I was using something similar for my NETCONSOLE demonstration.
We have a reasonable CI build of Buildroot at:
You can read about keeping customization out-of-tree in the Buildroot manual at:
As for building Debian packages, maybe
librobotcontrol would be a suitable example.
Anyway, I always think a good place to start is to define a process for building your code in an automated way so you know when you break the build. It makes sure people can reproduce your output and you can talk about the same thing when something breaks.
After that, I’d start formalizing the discussion about how the various interfaces should be exercised in the code. There is a thesis I have that “the Linux way is the right way”, but it isn’t always obvious what is the Linux way. Our goal will be to extend the testing to all the capes in the Beagle portfolio (currently listed at EcoSystem - BeagleBoard) on all the various Beagles to which they can connect.
Somewhat in parallel, I’m defining a netlist of a Super MikroBUS Cape with about 20 mikroBUS Shuttle connectors on it. We’ll use that in the test farm to try to get about 200 MikroE Click boards and a few other non-MikroE mikroBUS add-on boards connected to a variety of Beagles.
OK, I’ve rattled on a long time, so I’ll just stop.
Thank you for the detailed reply, I’ll look into the resources you’ve provided. In the meanwhile would be really helpful if anyone could provide any exercises or resources to get familiar with the process and development, specifically for the beagle tester CI. Thank you again !
What might be good is getting familiar with Git and CI provided by GitLab/OpenBeagle in general. Best way might be to explore the site editing guide and proposal guide. If you get a fork made, you can see how the CI on OpenBeagle works in general.