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
Rating: medium
Upstream Repository: Jason Kridner / Beagle Tester · GitLab
References:
3 Likes
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.
4 Likes
Hi,
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.
2 Likes
Absolutely! Setting up a Beagle test farm for software development sounds like a fantastic idea. Labgrid appears promising too
1 Like
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.
https://bbb.io/pbmcgist
We have a reasonable CI build of Buildroot at:
You can read about keeping customization out-of-tree in the Buildroot manual at:
https://buildroot.org/downloads/manual/manual.html#outside-br-custom
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. 
4 Likes
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.
2 Likes
@Saiprasad_Patil are you still interested in this idea?
Feel free to ping us on this thread or discord if you are thinking of submitting an application based on this thread
Yup! Got caught up with examinations so couldn’t update. Currently trying to get familiar with the project and am starting work on the application. I would like to know if there are any prerequisites that I need to complete before submitting my proposal?
Hi, created a PR for the task for contribution(point 3). I’ll soon send in my proposal for review. Sorry for the delay!
Feel free to discuss the technical aspects of what you want to do as part of this project on discord and this forum. We have very little time left and this project hasn’t been discussed enough.
The proposal is the final submission but you need to figure out the finer details with the potential mentors soon
I would like to know more about the technical goals of the projects and the requirements. I have access to a Beagle Bone Black as of now and would like to test out some parts of the project to understand it better and understand how I can contribute before presenting the proposal.
As Jason mentioned
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.
You can start with the above to get an idea of what you will be dealing with.
Has the ’ roboticscape’ package moved? I tried the DUT setup but I seems to fail with:
E: Unable to locate package roboticscape
Correct me if I’m wrong. @jkridner
I think a good starting point is looking at the work to build both Debian packages and Build root images directly out of the beagle-tester CI. If you aren’t sure what I mean by that, let me know.
This refers to having build root and Debian packages build and added to releases on git lab with br2-external mechanism right?
Or am I reading this wrong. Would appreciate some pointers on it.
Well, I don’t know where @RobertCNelson has it in the official feed, but we have a CI build up at https://beagleboard.beagleboard.io/librobotcontrol, though it needs to be updated to actually represent a feed. You can see how it is built at BeagleBoard.org / librobotcontrol · GitLab.
As @Anuj_Deshpande pointed out, this idea needs a bit more discussion, but I’ll create a draft proposal as soon as possible.
