I wanted to check if there’s a possibility of having this project included in GSoC 2025. I’m interested in contributing to the development of the Beagle Test Farm to help ensure all software developments are working as expected.
I have experience with embedded serial interfaces and have worked with device tree configurations. I’ve also gone through the references that Jason provided earlier to get a good understanding of the project.
Could anyone advise on how I can start contributing? I’d appreciate any guidance on initial steps or tasks I can focus on to get involved. Looking forward to hearing your thoughts!
anything to narrow down an approach and make it achievable is progress. the balena setup is a good thought. Let’s ping some folks on the Discord to try to brainstorm.
configure a testing environment with OpenBeagle CI, Buildroot and beagle-tester utility to validate hardware, software, and mikroBUS-enabled cape interfaces.
Develop and implement regression tests for kernel updates, dynamic DT overlays, and mikroBUS features, ensuring compatibility with all major interfaces (PWM, ADC, UART, I2C, SPI, GPIO, SDIO).
Design a Buildroot-based CI pipeline for automated testing, weekly regression checks, and configuration validation across mikroBUS boards.
Integrate features like barcode scanning to streamline test initiation and automate deployment of optimized Buildroot Linux images.
Update and refine the Cape Interface Specification.
Lasty, Document workflows, testing frameworks, and setup processes, ensuring compatibility and collaboration within the BeagleBoard community.
Let me know the pre-requisites to prove my qualification for it.
Thanks
In my opinion you need a firm and well defined road map that outlines bb & Ti hardware and software dev for current and future builds.
They have already transitioned to a single header with less I/O and that is an issue critical to your success. No point in working on project that is heading into a dead end. If bb can make a firm commitment and one that aligns with Ti’s agenda this would be a much needed project.
Your success is also contingent upon working with the device tree, device tree overlays and the drivers.
Regarding mikroBUS-enabled interfaces, mikroBUS has ip on the interface that prevents others from developing snap in boards that use the bus. They are should not be on the list, they are making money on this and have locked out others so they should be on their own with regards to mikroBUS.
The site below mentions that “mikroBUS is an open standard.”
If I am correct, what I can deduce is that the designs of Click Boards by MikroElektronika are their intellectual property, but the mikroBUS interface itself is an open standard, so we can design our own boards using the mikroBUS protocol.
The only restriction would be trademarked terms like “Click Board,” but calling it a “mikroBUS-compatible module” or “Click-compatible board” is perfectly fine.
The part that goes on the board is open source, the geometry and configuration of the board that inserts into the socket is proprietary. Until they release both halves of the socket to open source you are at risk.
FYI, you don’t need the board to “click” in, just use extended pins on the bottom of a board that WILL NOT click into the socket. Most certainly check with you Patent / IP attorney before proceeding with anything.
Correct, but let’s use MikroBUS and avoid the use of their unlicensed brand entirely. mikroBUS is still trademarked, but licensed freely with adherence to the standard.
Both halves have open source implementations. The Click boards are not, but the published specifications provide all necessary information and the mikroBUS trademark is freely licensed based on self-cerified adherence to the specification.
Created by MikroElektronika, mikroBUS™ is an open standard —
anyone can implement mikroBUS™ in their hardware design, as
long as the requirements set by this document are being met.
Regarding “click boards”
click boards™ are MikroElektronika’s brand of mikroBUS™ add-on boards. The click
board™ name is MikroElektronika’s trademark. Third party developers are not allowed
to call their own mikroBUS™ add-on boards click boards™, nor use the word “click” on
the silkscreen. To learn more about click boards™ visit Click Boards - MIKROE
Both the “mainboard” socket and the “add-on board” are specified.
Personally, I find this far more of a fruitful approach than following a format like Feather, that is loosely specified based on the routing to pin headers of a particular MCU on a particular board.
I find it to be very open and care about the openness deeply, so I want to stop the fear, uncertainty and doubt here if it isn’t justified.
Note that to handle the capacity of connections for this project, we’ll also be using the “Shuttle” connector, which isn’t really part of the specification, just a pinout they used on a board that breaks out 1 mikroBUS socket to 4 mikroBUS sockets using ribbon cables.
To help define the testing board, which would use a series of mikroBUS connections to enable testing various interfaces, I’ve started a mapping of the cape-specification along with fixes and additions to the specification to a series of mikroBUS sockets (with the expectations that several of them would be via “Shuttle” connectors, especially the parallel LCD, which would probably take 2-3 of these connectors.
The idea is that by focusing on bringing connectors, we can do several setups with the same cape to perform regression testing on multiple different designs. The ClickID would enable detection of the connected device to foster automated test selection.
While using the same pin on multiple mikroBUS sockets is not absolutely desired, it will be necessary to be able to test all of the various functions on a cape pin. It should be possible to quickly identify these conflicts from this document to avoid connecting add-on board to multiple sockets that would prevent proper function.
I think I’ll be adding HAT and PocketCape headers as well. I’ll want a power connector and the ability to remotely power cycle boards as well. Ideas from the Balena AutoKit setup will dominate the approach. A PocketBeagle 2 and an 8-board USB hub with Ethernet and individual port power switching might make a good building block, though it could be on a separate board–but don’t want to make the mechanical constraints hard.
I’ll try to make the PCB footprint compatible with AI-64, Black, BeagleY and PocketBeagle 2. Think big board, board under test face down, slightly skinny pins to reduce insertion force, cut-outs to enable it to sit without making really long pin headers.
It was on their website, they no longer mention the “open source” part. I did not find that flipping through the legal. To my recollection it was on the website at one time, and pretty sure that is why we did go any further with it.
They clearly state the Socket, not the plug in part. You need to get a written release from the person of authority in the company before using it so you will avoid legal issues. If the plug end of the board was not IP protected you would see knock offs of those boards all over amazon.
Does it directly state the plug end is open source, no, you need to evaluate the statement and have an attorney involved if you plan on getting involved with this.
I’m starting this project by testing all the testers on the BeagleBoard YI-Ai Board and exploring more mikroBUS functions. My first step is to check if everything is working correctly and fix any issues I find.
I’m also looking into mikroBUS to see what features it supports and how different Click boards can be used with it. At the same time, I’ll be working with OpenBeagle CI, Buildroot, and beagle-tester to understand how they help with testing and making things run smoothly.
To detect and verify the CSIPR HDMI output, are we planning to use a computer vision-based approach to analyze the output, scan barcodes, and automate the testing process? Or will this step remain a manual verification process?
Also, Some Ideas from balena AutoKit, like Containerization, Remote Device management can be added here.
I see your point, Vidhi. A manual verification process might be more practical, especially considering the complexity and additional hardware required for a vision-based system. If we keep it manual, we could still optimize the process by defining a structured checklist or automating certain aspects of logging the results.
For the automation side, ideas from Balena AutoKit, like containerization and remote device management, could still be beneficial for other parts of the workflow.
For things that are done before network is available, USB to HDMI converters are dirt cheap now. So using them to get the HDMI out and doing some video processing on that is not too difficult. The other computer just treats it like a regular USB webcam - so anything opencv just works.
For things that come later - after we’ve gotten network on the device - I think we can host a simple server and serve the test results as a simple webpage. Mongoose is probably a lightweight enough solution to run a simple c server from within beagle-tester (given its all C right now and we’d like to keep it that way).
Then you could show the output on an attached screen - or you could skip the screen completely and access it remotely.
Also - IIRC hardware design is typically not a part of GSoC. So we would have to either make do with as little hardware prototyping or spin some dev PCBs well in advance.
