Update beagle-tester for cape, mikrobus, new board and upstream testing

Google Summer of Code
, , ,
42

Connecting HDMI using this wire and verifying it through a camera should work if an external device, such as a camera, is already connected. Alternatively, performing an RGB test—where all colors are displayed correctly—can also be a valid approach.

For weekly tests, we can display RGB colors, and if they appear correctly, the test passes for the connected HDMI. This can also be verified using a camera.

Looking forward to your thoughts on this approach!

43

@ketanthorat.ai I suggest you take a look at what Jason linked again (the HDMI capture card) and figure out how it works

44

Hi @Anuj_Deshpande I have made a draft proposal for the project, Please check it out and let me know the changes I need to make.

https://gsoc-beagleboard-io-vidhusarwal-ef1b2cdd91ef66a680f6b424374fd90.beagleboard.io/proposals/vidhu_tingurr.html

I am fixing the timeline (Dates might be a bit off) and also adding more information. I have added a flowchart as well. Please let me know the changes I need to make. Thanks.

45

Got it. A bit of Video Processing can be integrated then to automate the process as I suggested here.

46

Oh, okay! I get your point now. Since you mentioned the USB to HDMI converter, I initially assumed HDMI was being used as an output. Never mind, I understand now. However, the HDMI port on the board still remains untested. If we attempt to project an output using OpenCV, we can verify its functionality. If the final goal is to test the display drivers, then that should be fine.

47

Also drafting a detailed proposal for this project sooner.

48

I suggest you take a look at what Jason linked again (the HDMI capture card) and figure out how it works - the HDMI output of the beagleboard will be a USB input for another device (or even the same device)

For example - here I am using the HDMI output of my computer as a camera input for the same computer. Would you say this is testing the HDMI output of my computer?

image
image2247×1421 267 KB

49

Oh, I see! I already knew how it works—I just thought it was for the BB Y-AI Board. Sorry for the misunderstanding! I was actually running the tests on the Y-AI Board.

51

Hey, This seems very interesting project. I would like to work on it. I have a pretty good experience with building linux images using Yocto, I have build number of images for Raspberry Pi and BeagleBone Black. I’ll start checking out buildroot too.

52

@Anuj_Deshpande
I have a few questions regarding the project.

  1. Are we using Dynamic Pinmuxing for peripheral testing? If so, will we be using device tree overlays?
  2. What about implementing Computer Vision to automate testing and barcode scanning as well as HDMI output testing, Is that a yes?

Also, remote access to any of the compatible boards would be lovely to help with writing some scripts for the same.

Thanks.

53

@Anuj_Deshpande @lorforlinux

Hi All, Hope you guys are doing well!
For the project “Update beagle-tester for mainline testing” I just submitted an MR with my proposal linked below. Please have a look and help me with a review.
Thanks in Advanced!

54

Hey everyone,

Originally I’ve expressed interest in working on this project on this GSoC 2025 by implementing it for FD CAN Click boards. There are 28 of them: CAN | Interface - MIKROE). I have “CAN FD 6 Click” currently, but ordering them is a few days shipping since I live near where they manufacture and ship :D.

However, I was advised on Discord that this might be too small for a GSoC project:

So, I’d like to get your thoughts on:

  1. Would a full CAN validation standalone module for stress testing, fault injection, CI integration be more valuable?
  2. Or would supporting multiple mikroBUS Clicks in Beagle-Tester (not just CAN) bring more impact?
  3. What bits and piece would make up for a project big enough for GSoC (in beagle-tester context)?

Refocusing beagle-tester’s goals:

I’ve tried to follow-up with the entire discussion above. My opinion is that, while HDMI verification is interesting, I feel like we’ve drifted away from the core goal of Beagle-Tester: “automated self-
testing for BeagleBoards with minimal external requirements.”

Basing on the initial post, the primary focus was on validating mikroBUS-connected peripherals (PWM, ADC, I2C, GPIO, SPI…) and making sure there’s a weekly regression test against the mainline.

Additional Questions:
Also I’m interested is there any reason (beside IP legal) for not using the mikroBUS Cape ?
I’ve also got a few additional questions to clarify the project scope:

  1. I’ve found another post that suggest flipped TX/RX using one of their CAN modules, should this be accounted for in Device Tree overlays?
  2. Will designing a cape will be part of this project ?
  3. What is the current state of the test farm?
    • is it being built, will be built, already exists?
    • is it the idea to have a super cape? for 1 BB (~20 x clicks)
55

Nothing like that, The HDMI verification is just an added feature. we will still be doing the rest of the goals mentioned in the issue and Topmost Post. Both the weekly regression tests and Peripheral testing is included.

No, Hardware design is not expected in GSOC as it’s an software focused program.
That and the test farm will be designed by @jkridner as discussed here Update beagle-tester for cape, mikrobus, new board and upstream testing - #33 by jkridner

Rest let the mentors confirm with the details.

56

Got it, thanks for confirming!
Since hdmi is just an extra feature and not the main focus, is there a good example of tests already defined for mikroBUS peripheral validation, or should I start structuring those based on what’s currently available in beagle-tester any prefered structure elsewhere?
Also, should we keep track the test farm discussions separately, or in simple terms I’m asking whether the test farm setup (hardware side) is separate from the test framework (software side)