diff --git a/.gitignore b/.gitignore
index 98c50df103794d7fcb5c937c62d34210eb6645f2..88b3eeb54e9baae472a54541a2bc8223442b2b58 100644
--- a/.gitignore
+++ b/.gitignore
@@ -42,4 +42,4 @@ GPATH
GRTAGS
GTAGS
TAGS
-tags
+tags
\ No newline at end of file
diff --git a/conf.py b/conf.py
index 31058d77bd31a142901f727d2fad261e0ac86ace..02aa90fedb61a934ec7840b9955fbc80a1449bcf 100644
--- a/conf.py
+++ b/conf.py
@@ -147,11 +147,12 @@ html_theme_options = {
}
proposals = []
-proposal_filenames = next(walk("proposals"), (None, None, []))[2]
-for proposal_filename in proposal_filenames:
- proposal_filename = os.path.splitext(proposal_filename)[0]
- if proposal_filename != "index":
- proposals.append(proposal_filename)
+for root, _, files in os.walk("proposals"):
+ for filename in files:
+ if filename.endswith(".rst") and filename != "index.rst":
+ full_path = os.path.join(root, filename)
+ proposal_name = os.path.splitext(full_path)[0].replace(os.sep, "/")
+ proposals.append(proposal_name)
print(proposals)
@@ -177,6 +178,7 @@ html_context = {
latex_elements = {
"papersize": "a4paper",
"maketitle": open("_static/latex/title.tex").read(),
+ "fontpkg": "", #Disables Sphinx’s default FreeSerif .otf
"preamble": open("_static/latex/preamble.tex").read() + r"\let\cleardoublepage\clearpage",
"sphinxsetup": ",".join(
(
@@ -195,4 +197,5 @@ latex_engine = "xelatex"
latex_logo = str("_static/images/logo-latex.pdf")
latex_documents = []
for proposal in proposals:
- latex_documents.append(("proposals/"+proposal, proposal+".tex", "",author, "manual"))
+ tex_name = proposal.split("/")[-1]
+ latex_documents.append((proposal, tex_name + ".tex", "", author, "manual"))
\ No newline at end of file
diff --git a/proposals/2025/Assets_vidhu_beagle_tester/Flowchart.png b/proposals/2025/Assets_vidhu_beagle_tester/Flowchart.png
new file mode 100644
index 0000000000000000000000000000000000000000..f918983dbc7492dd712dde91ae578d7cbdb062ff
Binary files /dev/null and b/proposals/2025/Assets_vidhu_beagle_tester/Flowchart.png differ
diff --git a/proposals/2025/Assets_vidhu_beagle_tester/actions1.png b/proposals/2025/Assets_vidhu_beagle_tester/actions1.png
new file mode 100644
index 0000000000000000000000000000000000000000..65abe9f3b0ba5dd6799ef4508ae2e8e7c73c12b6
Binary files /dev/null and b/proposals/2025/Assets_vidhu_beagle_tester/actions1.png differ
diff --git a/proposals/2025/Assets_vidhu_beagle_tester/actions2.png b/proposals/2025/Assets_vidhu_beagle_tester/actions2.png
new file mode 100644
index 0000000000000000000000000000000000000000..7e0d9395fd320d0b583371370e0accaf0883b44a
Binary files /dev/null and b/proposals/2025/Assets_vidhu_beagle_tester/actions2.png differ
diff --git a/proposals/2025/Assets_vidhu_beagle_tester/processFlow.png b/proposals/2025/Assets_vidhu_beagle_tester/processFlow.png
new file mode 100644
index 0000000000000000000000000000000000000000..c5d72a907be9a6c53b2eb95d66e902e84ef370a8
Binary files /dev/null and b/proposals/2025/Assets_vidhu_beagle_tester/processFlow.png differ
diff --git a/proposals/2025/index.rst b/proposals/2025/index.rst
index 68a613c4ea9d6996f0973cb902e3e3370a88c204..163dcb2319e58a30c5f7845e4f8a4ff36092d312 100644
--- a/proposals/2025/index.rst
+++ b/proposals/2025/index.rst
@@ -7,3 +7,5 @@ Start writing your proposal for GSoC 2025 today and add it here!
.. toctree::
:maxdepth: 1
+
+ vidhu_tingurr
\ No newline at end of file
diff --git a/proposals/2025/vidhu_tingurr.rst b/proposals/2025/vidhu_tingurr.rst
new file mode 100644
index 0000000000000000000000000000000000000000..fad4a6ad18f001c95fccd8fc065f14692881c55a
--- /dev/null
+++ b/proposals/2025/vidhu_tingurr.rst
@@ -0,0 +1,725 @@
+
+Update beagle-tester for mainline testing - Vidhu Sarwal
+########################################################
+
+Introduction
+*************
+
+Summary links
+=============
+
+- **Contributor:** `Vidhu Sarwal <https://forum.beagleboard.org/u/vidhu/>`_
+- **Mentors:** `Jason Kridner <https://forum.beagleboard.org/u/jkridner/>`_, `Deepak Khatri <https://forum.beagleboard.org/u/lorforlinux/>`_, `Anuj Deshpande <https://forum.beagleboard.org/u/Anuj_Deshpande>`_, `Dhruva gole <https://forum.beagleboard.org/u/dhruvag2000/>`_
+- **Code:** `TBD`
+- **Documentation:** `TBD`
+- **GSoC:** `TBD`
+
+Status
+=======
+
+This project is currently just a proposal.
+
+Proposal
+========
+
+- Created accounts accross `OpenBeagle <https://openbeagle.org/vidhusarwal>`_, `Discord <https://discord.com/users/1160628301149241394>`_ and `Beagle Forum <https://forum.beagleboard.org/u/vidhu/>`_
+- The PR Request for Cross Compilation: `#197 <https://github.com/jadonk/gsoc-application/pull/197>`_
+- Created a project proposal using the `proposed template <https://gsoc.beagleboard.io/proposals/template.html>`_.
+
+
+About
+=====
+
+- **Forum:** :fab:`discourse` `u/vidhu (Vidhu Sarwal) <https://forum.beagleboard.org/u/vidhu/>`__
+- **OpenBeagle:** :fab:`gitlab` `vidhusarwal (Vidhu Sarwal) <https://openbeagle.org/vidhusarwal>`__
+- **Github:** :fab:`github` `vidhusarwal (Vidhu Sarwal) <https://github.com/Vidhu Sarwal>`__
+- **School:** :fas:`school` `Thapar Institute of Engineering and Technology <https://www.thapar.edu>`_
+- **Country:** :fas:`flag` India
+- **Primary language:** :fas:`language` English
+- **Typical work hours:** :fas:`clock` 8AM-5PM Indian Standard Time
+- **Previous GSoC participation:** :fab:`google` N/A
+
+Project
+********
+
+**Project name:** Update beagle-tester for mainline testing
+
+Description
+============
+
+Beagle-Tester is a test automation framework designed for BeagleBoard devices, allowing hardware validation across multiple boards. This project aims to enhance Beagle-Tester by incorporating mikroBUS support and updating it for mainline kernel testing. The goal is to create an automated regression test suite for Linux kernel and device-tree overlays on BeagleBoard-based hardware, enabling continuous validation in the OpenBeagle CI server.
+
+Key objectives include:
+
+- Adding mikroBUS support to Beagle-Tester to validate peripherals like PWM, ADC, UART, I2C, SPI, GPIO, and interrupts.
+
+- Integrating automated power cycling and remote control capabilities for test farms with multiple boards.
+
+- Building a web interface for monitoring and managing test results efficiently.
+
+- Optimizing Beagle-Tester for Buildroot to streamline deployment.
+
+.. figure:: Assets_vidhu_beagle_tester/Flowchart.png
+ :align: center
+ :alt: Flowchart of objectives
+
+ **Figure 1:** Flowchart of objectives (The following does not represent the implementation steps of the project, for that refer milestones.)
+
+The project will benefit BeagleBoard developers, Linux kernel maintainers, and embedded engineers by providing a robust testing framework for validating hardware and software compatibility with weekly mainline Linux updates. The implementation will use Python, Bash scripting, Linux device-tree modifications, and udev rules to ensure automation and scalability
+
+MikroBus and Click boards
+-------------------------
+
+I am going to provide some background on how MikroBus can be detected and tested.
+
+Detecting MikroBus:
+^^^^^^^^^^^^^^^^^^^
+
+
+If the board inserted contains an EEPROM with relevant information, it can be detected using:
+
+.. code-block:: bash
+
+ dmesg | grep mikrobus
+
+Sample output:
+
+.. code-block:: none
+
+ [ 2.096254] mikrobus:mikrobus_port_register: registering port mikrobus-0
+ [ 2.663698] mikrobus_manifest:mikrobus_manifest_attach_device: parsed device 1, driver=opt3001, protocol=3, reg=44
+ [ 2.663783] mikrobus mikrobus-0: registering device : opt3001
+
+Then we can check if the device is registered under `IIO <https://www.kernel.org/doc/html/v4.16/driver-api/iio/index.html>`_:
+
+.. code-block:: bash
+
+ ls /sys/bus/iio/devices/
+
+Sample output:
+
+.. code-block:: none
+
+ iio:device0
+
+In case of using, for example, an I2C device, its address can be verified using:
+
+.. code-block:: bash
+
+ i2cdetect -y 2
+
+Testing MikroBus Device
+^^^^^^^^^^^^^^^^^^^^^^^
+
+a. Read sensor data from:
+
+ .. code-block:: bash
+
+ ls /sys/bus/iio/devices/
+
+b. Verify the value against some threshold/chart depending on the type of sensor.
+c. Send the sample output for logging.
+
+Automating MikroBus Device Testing
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+We can automate this using a small script.
+
+a. For Ex. a temperature sensor, we can run:
+
+ .. code-block:: bash
+
+ RAW_TEMP=$(cat /sys/bus/iio/devices/iio\:device0/in_temp_raw)
+ SCALE=$(cat /sys/bus/iio/devices/iio\:device0/in_temp_scale)
+ TEMP=$(echo "$RAW_TEMP * $SCALE" | bc)
+ echo "Temperature = ${TEMP}°C"
+
+b. Save this as a `.sh` file and run it:
+
+ .. code-block:: bash
+
+ chmod +x sensor_test.sh
+ ./sensor_test.sh
+
+.. important::
+ If your Click board does not have ClickID, you must manually install its manifest file. To install manifests for supported boards, run:
+
+ .. code-block:: bash
+
+ sudo apt update
+ sudo apt install bbb.io-clickid-manifest
+
+.. important::
+ Dynamic Runtime Pinmuxing cannot be implemented for now. As per my discussion with members on Discord #linux, Global dynamic overlays will never be added upstream. Upstream wants local dynamic overlays
+ `Lore <https://lore.kernel.org/all/9c326bb7-e09a-4c21-944f-006b3fad1870@beagleboard.org/>`_
+
+Regression Testing
+------------------
+
+Here, I will provide information on how regression testing can be set up on a farm.
+
+1. Install and set up **Beagle-tester** with its related dependencies beforehand.
+2. The **Device Under Test (DUT)** is flashed with a production Debian image, and Beagle-tester is installed to execute interface-specific tests.
+3. **GitLab CI/CD pipeline** is configured with:
+
+ - Build and test stages for automating Beagle-tester workflows.
+ - Scripts to run tests, log results, and collect artifacts.
+
+
+**As discussed during application period**, I have implemented a Github actions script demo which generates Buildroot image whenever a new push is made to .config file. This can also be edited to generate images every week for weekly regression test.
+The demo can be found here `Link to Git <https://github.com/VidhuSarwal/buildroot_image_gen.git>`_
+I am attaching a screenshot of the pipeline as well here.
+
+.. figure:: Assets_vidhu_beagle_tester/actions1.png
+ :align: center
+ :alt: Representation of Pipeline stages.
+
+ **Figure:** Representation of Pipeline stages.
+
+.. figure:: Assets_vidhu_beagle_tester/actions2.png
+ :align: center
+ :alt: Representation of Demo. The image is provided in the artifact.
+
+ **Figure:** Representation of Demo. The image is provided in the artifact.
+
+Weekly regression tests are scheduled in **GitLab CI** to ensure that kernel updates or software changes do not break **mikroBUS compatibility**.
+
+Testing Protocols
+-----------------
+
+I am going to provide an idea on how tests can be developed for protocols. Say, for example, I2C/SPI needs an approach that verifies both functional operation and error handling.
+
+- **Using Logic Protocol Analyzers** *Functional Testing*
+ We can implement a logic analyzer for protocol testing. An inexpensive FX2-based logic analyzer can be used to read signals from the DUT. After installing Sigrok and connecting the necessary probes to the peripherals of the DUT, it can be monitored using:
+
+ .. code-block:: bash
+
+ sigrok-cli --config samplerate=1M --driver=fx2lafw --continuous -P spi:mosi=1:clk=3:cs=4
+
+ This can be automated as well to publish the results automatically to the web server or even GitLab's CI for weekly tests.
+
+ A basic communication test can be performed as follows:
+
+ .. code-block:: bash
+
+ #!/bin/bash
+ # I2C Basic Communication Test
+ DEVICE="fx2lafw"
+ SAMPLERATE="1M"
+ CHANNELS="0=SCL,1=SDA"
+ echo "detecting I2C devices:"
+ i2cdetect -y 2
+ # capture I2C transaction
+ echo "capturing I2C txn"
+ sigrok-cli --driver=$DEVICE --config samplerate=$SAMPLERATE --channels=$CHANNELS \
+ --time 3s -P i2c:scl=0:sda=1 > i2c_capture.txt
+
+ # validate communication
+ echo "validating I2C communication..."
+ if grep -q "Address write" i2c_capture.txt && grep -q "ACK" i2c_capture.txt; then
+ echo "I2C communication successful"
+ else
+ echo "I2C communication error"
+ fi
+
+ Additional tests for Address Recognition and Clock Stretching can also be added.
+
+- **Test Case Design Methodology**
+
+ Here's an example implementation in C for I2C EEPROM testing:
+
+ .. code-block:: c
+
+ /**
+ * I2C EEPROM Read/Write Test Case
+ * Purpose: Validates I2C communication and EEPROM functionality
+ * Success Criteria: Write/read verification with <5% bit error rate
+ */
+ int test_i2c_eeprom(uint8_t device_address) {
+ int fd;
+ uint8_t test_data[] = "BeagleTester";
+ uint8_t read_data[sizeof(test_data)];
+ uint8_t reg_addr = 0x00;
+ int error_count = 0;
+ float error_rate = 0.0;
+
+ // Open I2C bus
+ if ((fd = open("/dev/i2c-2", O_RDWR)) < 0) {
+ log_error("Failed to open I2C bus");
+ return -1;
+ }
+
+ // Set slave address
+ if (ioctl(fd, I2C_SLAVE, device_address) < 0) {
+ log_error("Failed to acquire bus access");
+ close(fd);
+ return -1;
+ }
+
+ // write to EEPROM
+ if (i2c_smbus_write_i2c_block_data(fd, reg_addr, sizeof(test_data), test_data) < 0) {
+ log_error("Failed to write to EEPROM");
+ close(fd);
+ return -1;
+ }
+
+ usleep(100000); // 100ms delay
+
+ // read back data
+ if (i2c_smbus_read_i2c_block_data(fd, reg_addr, sizeof(test_data), read_data) < 0) {
+ log_error("Failed to read from EEPROM");
+ close(fd);
+ return -1;
+ }
+
+ // error rate calc
+ for (int i = 0; i < sizeof(test_data); i++) {
+ if (test_data[i] != read_data[i]) error_count++;
+ }
+ error_rate = (float)error_count / sizeof(test_data) * 100.0;
+
+ // logging
+ log_info("I2C EEPROM Test: %s", (error_rate < 5.0) ? "PASS" : "FAIL");
+ log_info("Bit Error Rate: %.2f%%", error_rate);
+
+ // Cleanup
+ memset(test_data, 0xFF, sizeof(test_data));
+ i2c_smbus_write_i2c_block_data(fd, reg_addr, sizeof(test_data), test_data);
+ close(fd);
+
+ return (error_rate < 5.0) ? 0 : -1;
+ }
+
+**Test Case Features**
+This test case implementation demonstrates:
+
+- **Boundary Testing**: Uses specific payload size to test I2C block transfers.
+- **Timing Validation**: Incorporates EEPROM write cycle timing requirements.
+- **Metric Collection**: Quantifies bit error rates for performance regression tracking.
+- **Cleanup Protocol**: Restores initial state to prevent test contamination.
+
+**Integration with Regression Testing Framework
+**
+The test integrates with the proposed regression testing framework by providing:
+
+- Clear pass/fail criteria based on error rate thresholds.
+- Detailed logging for troubleshooting and historical analysis.
+- Proper resource management with cleanup procedures.
+
+
+
+Computer Vision for Barcode Scanning
+------------------------------------
+
+In the current version of Beagle-tester, the barcode displayed on the boot needs to be manually scanned to continue with testing. This can be automated by using a HDMI to USB video card. This will also help with HDMI testing.
+
+We can use OpenCV and ZBar for this purpose. OpenCV will be used to capture frame from HDMi(from the video source).
+
+`Link to script <https://gist.github.com/VidhuSarwal/f72e5a83428cc6162f30425d592d4612>`_
+
+**HDMI Barcode Detection Process**
+
+1. **Initialize Video Capture**
+ Open HDMI input device.
+
+2. **Initialize Barcode Scanner**
+ Setup ZBar scanner.
+
+3. **Start Capture Loop**
+ - Read frame from HDMI input.
+ - If frame capture fails, retry.
+
+4. **Extract Region of Interest (ROI)**
+ Crop frame to fixed coordinates (`ROI_X`, `ROI_Y`, `ROI_WIDTH`, `ROI_HEIGHT`).
+
+5. **Detect Barcode**
+ - Convert ROI to grayscale.
+ - Scan for barcodes in the ROI.
+
+6. **Validate 16-bit Barcode**
+ - If valid barcode found → Store result and exit.
+ - If no barcode found → Continue loop until timeout.
+
+7. **Handle Timeout**
+ If no barcode is detected in 30 seconds, exit with failure.
+
+
+
+
+Extra Features Which Can Be Added If Approved
+---------------------------------------------
+
+On the forum, I discussed adding some additional features.
+
+1. **Computer Vision for Barcode Scanning**
+ One proposed feature is using **computer vision** to automatically scan the barcode of the **Device Under Test (DUT)** using an **HDMI-to-USB Encoder**, commonly used in display capture. This would help eliminate manual labor.
+ More details can be found in the forum discussion:
+ `Forum discussion on Barcode Scanning <https://forum.beagleboard.org/t/update-beagle-tester-for-cape-mikrobus-new-board-and-upstream-testing/37279/37?u=Vidhu>`_
+
+2. **Web Server for Data Display**
+ Another feature worth adding is a **web server**. A server can be used to send data and display it on a webpage once the network is available. This can be achieved using **Mongoose** as the web server.
+ More details can be found in the forum discussion:
+ `Forum discussion on Web Server <https://forum.beagleboard.org/t/update-beagle-tester-for-cape-mikrobus-new-board-and-upstream-testing/37279/39?u=vidhu>`_
+
+These features have been added to the timeline below but can be removed as needed.
+
+
+
+Software
+=========
+
+- Python (for test scripting and automation)
+
+- Bash (for system-level automation)
+
+- Linux kernel/device-tree (for hardware validation and overlay support)
+
+- Buildroot (for firmware and testing framework optimization)
+
+
+- Beagle-Tester (core test framework)
+
+- Mongoose (for web-based test monitoring interface)
+
+Hardware
+========
+
+- BeagleBone Black / BeagleBone AI-64 / PocketBeagle 2 (for portable testing)
+
+- mikroBUS Cape (custom cape for interfacing mikroBUS modules)
+
+- Multiple mikroBUS modules (PWM, ADC, UART, I2C, SPI, GPIO peripherals)
+
+- 8-port USB hub with Ethernet and power control (for automated power cycling)
+
+- External monitor (for HDMI signal validation)
+
+- Power control module (for remote board reset)
+
+Timeline
+********
+
+The project will be broadly divided into 4 parts as mentioned below in the Flowchart.
+
+.. figure:: Assets_vidhu_beagle_tester/processFlow.png
+ :scale: 100%
+ :alt: Process Flow
+
+ **Figure 2:** Representation of steps to complete project. Checkout the table below for exact timeline)
+
+Timeline summary
+=================
+
+.. table::
+
+ +------------------------+----------------------------------------------------------------------------------------------------+
+ | Date | Activity |
+ +========================+====================================================================================================+
+ | February 27 | Connect with possible mentors and request review on first draft |
+ +------------------------+----------------------------------------------------------------------------------------------------+
+ | March 4 | Complete prerequisites, verify value to community and request review on second draft |
+ +------------------------+----------------------------------------------------------------------------------------------------+
+ | March 11 | Finalized timeline and request review on final draft |
+ +------------------------+----------------------------------------------------------------------------------------------------+
+ | April 8 | Submit application |
+ +------------------------+----------------------------------------------------------------------------------------------------+
+ | May 8 | :ref:`gsoc-beagle-tester-vidhu-bonding` |
+ +------------------------+----------------------------------------------------------------------------------------------------+
+ | June 2 | :ref:`gsoc-beagle-tester-vidhu-m1` |
+ +------------------------+----------------------------------------------------------------------------------------------------+
+ | June 9 | :ref:`gsoc-beagle-tester-vidhu-m2` |
+ +------------------------+----------------------------------------------------------------------------------------------------+
+ | June 17 | :ref:`gsoc-beagle-tester-vidhu-m3` |
+ +------------------------+----------------------------------------------------------------------------------------------------+
+ | June 24 | :ref:`gsoc-beagle-tester-vidhu-m4` |
+ +------------------------+----------------------------------------------------------------------------------------------------+
+ | July 1 | :ref:`gsoc-beagle-tester-vidhu-m5` |
+ +------------------------+----------------------------------------------------------------------------------------------------+
+ | July 7 | :ref:`gsoc-beagle-tester-vidhu-m6` |
+ +------------------------+----------------------------------------------------------------------------------------------------+
+ | July 14 | :ref:`gsoc-beagle-tester-vidhu-midterm` |
+ +------------------------+----------------------------------------------------------------------------------------------------+
+ | July 21 | :ref:`gsoc-beagle-tester-vidhu-m7` |
+ +------------------------+----------------------------------------------------------------------------------------------------+
+ | July 28 | :ref:`gsoc-beagle-tester-vidhu-m8` |
+ +------------------------+----------------------------------------------------------------------------------------------------+
+ | August 4 | :ref:`gsoc-beagle-tester-vidhu-m9` |
+ +------------------------+----------------------------------------------------------------------------------------------------+
+ | August 11 | :ref:`gsoc-beagle-tester-vidhu-m10` |
+ +------------------------+----------------------------------------------------------------------------------------------------+
+ | August 25 - Sept 1 | :ref:`gsoc-beagle-tester-vidhu-final` |
+ +------------------------+----------------------------------------------------------------------------------------------------+
+
+
+Timeline detailed
+=================
+
+.. important::
+
+ - I have my end-semester evaluation scheduled from **17th May 2025 till 1st June 2025**.
+ - Other than that, I will have my summer vacations in June and July, so I will be able to dedicate around 35-37 hours per week. This will total approximately **300-330 hours over the summer**.
+ - At the end of June, I may need to take **two days off (27-28 June)** for traveling back to campus.
+ - After my next academic session begins in August, I will be able to commit about 12 hours per week, adding another **48-50 hours** to the project. This is why I aim to complete major implementations before my session starts and leave primarily documentation for the last step in August. I have also included **buffer weeks in July and August** to accommodate any unexpected delays.
+
+.. important::
+
+ Once the coding period starts, the documentation will be updated weekly, and progress will be reported weekly via a blog post.
+
+
+.. _gsoc-beagle-tester-vidhu-bonding:
+
+Community Bonding Period (May 8 – June 1)
+=========================================
+
+Week 1 (May 8 – May 14): Finalize Execution Plan
+------------------------------------------------
+
+- **What will be done**:
+ - Discuss project goals with mentors and finalize the enhanced execution plan.
+ - Review existing documentation for mikroBUS cape and Beagle Tester.
+- **How it will be done**:
+ - Conduct meetings with mentors to refine objectives and milestones.
+ - Analyze `cape_interface_spec.md` and identify areas requiring updates.
+ - Set up the development environment.
+
+Week 2 (May 15 – May 21): Familiarization with Tools
+----------------------------------------------------
+
+- **What will be done**:
+ - Setup and initialize with tools like OpenCV, Mongoose server, Buildroot configurations, and GitLab CI pipelines.
+- **How it will be done**:
+ - Install and test OpenCV for video processing tasks.
+ - Set up a lightweight web server using Mongoose for hosting test results.
+ - Explore Buildroot configurations for BeagleBoard variants.
+
+Week 3 (May 22 – June 1): Initial Test Farm Design
+--------------------------------------------------
+
+- **What will be done**:
+ - Begin discussions on modular test farm design to ensure scalability.
+- **How it will be done**:
+ - Research hardware integration options, including PocketBeagle boards and USB hubs.
+ - Plan power cycling capabilities inspired by Balena AutoKit setups.
+
+---
+
+.. _gsoc-beagle-tester-vidhu-coding:
+
+Step 1: Software Development (June 2 – July 13)
+================================================
+
+.. _gsoc-beagle-tester-vidhu-m1:
+
+Week 4 (June 2 – June 8): Device Tree Updates
+---------------------------------------------
+
+- **What will be done**:
+ - Removed [Map mikroBUS socket pins to Device Tree overlays.]
+ - Add support for ClickID detection to automate driver loading and test selection.
+- **How it will be done**:
+ - Update `cape_interface_spec.md` with pin mappings for all interfaces.
+ - Write scripts to detect ClickID and dynamically load drivers.
+
+.. _gsoc-beagle-tester-vidhu-m2:
+
+Week 5 (June 9 – June 16): Kernel Enhancements
+----------------------------------------------
+
+- **What will be done**:
+ - Removed [Develop kernel patches to support mikroBUS drivers for all interfaces].
+- **How it will be done**:
+ - Implement kernel patches for SPI, I2C, UART, ADC, PWM, GPIO, SDIO interfaces.
+ - Push updates to Linux mainline for long-term support.
+
+
+.. _gsoc-beagle-tester-vidhu-m3:
+
+Week 6 (June 17 – June 23): Regression Testing Framework
+--------------------------------------------------------
+
+- **What will be done**:
+ - Extend Beagle Tester to include automated regression tests for mikroBUS-enabled interfaces.
+- **How it will be done**:
+ - Write modular regression test scripts covering SPI, I2C, UART, ADC, GPIO, PWM.
+ - Use OpenCV-based video processing to analyze HDMI output during tests.
+
+.. _gsoc-beagle-tester-vidhu-m4:
+
+Week 7 (June 24 – June 30): Lightweight Web Server Integration
+---------------------------------------------------------------
+
+- **What will be done**:
+ - Integrate a lightweight web server to host real-time test results over the network.
+- **How it will be done**:
+ - Use Mongoose server to serve test results from Beagle Tester in real-time.
+ - Provide options to display results on an attached screen or remotely via a browser.
+
+.. _gsoc-beagle-tester-vidhu-m5:
+
+Week 8 (July 1 – July 6): Finalize Software Features
+-----------------------------------------------------
+
+- **What will be done**:
+ - Complete all pending software tasks and ensure compatibility with advanced features like HDMI video processing and parallel LCD testing.
+- **How it will be done**:
+ - Refactor codebase for maintainability and readability.
+ - Conduct comprehensive regression testing using GitLab CI pipelines.
+
+---
+
+.. _gsoc-beagle-tester-vidhu-midterm:
+
+Submit midterm evaluations (July 14th)
+----------------------------------------------------------
+
+
+Step 2: Continuous Integration Setup (July 19 – August 8)
+==========================================================
+
+.. _gsoc-beagle-tester-vidhu-m6:
+
+Week 9 & 10 (July 7 – July 20): Buildroot Integration
+-----------------------------------------------------
+
+- **What will be done**:
+ - Update Buildroot configurations for each BeagleBoard variant (AI-64, Black, BeagleY, PocketBeagle).
+ - Automate Buildroot image generation with mikroBUS support and pre-installed Beagle Tester utilities.
+- **How it will be done**:
+ - Configure Buildroot for supported boards and generate images automatically using scripts.
+ - Test generated images by booting them on supported hardware.
+
+.. _gsoc-beagle-tester-vidhu-m7:
+
+Week 11 (July 21 – July 27): CI Pipeline Design
+-------------------------------------------------
+
+- **What will be done**:
+ - Set up GitLab CI pipelines to automate regression testing weekly.
+ - Include power cycling capabilities using USB hubs with Ethernet and individual port power switching inspired by Balena AutoKit setups.
+- **How it will be done**:
+ - Design modular CI workflows that include dynamic test selection based on ClickID detection.
+ - Integrate automated power cycling into the pipeline.
+
+---
+
+Step 3: Test Farm Design (August 9 – August 25)
+================================================
+
+.. _gsoc-beagle-tester-vidhu-m8:
+
+Week 12 (July 28 – August 4): Hardware Integration
+-----------------------------------------------------
+
+- **What will be done**:
+ - Use a PocketBeagle and an eight-board USB hub as building blocks for the test farm.
+ - Integrate power connectors and remote power cycling capabilities inspired by Balena AutoKit setups.
+- **How it will be done**:
+ - Assemble the hardware setup with modular components like USB hubs and PocketBeagle boards.
+ - Add LCD displays and LEDs to indicate test status visually.
+
+
+.. _gsoc-beagle-tester-vidhu-m9:
+
+Week 13 (August 4 – August 10): Advanced Monitoring Tools
+----------------------------------------------------------
+
+- **What will be done**:
+ - Integrate real-time monitoring tools (e.g., protocol analyzers) for debugging SPI/I2C/UART communication in real-time.
+ - Include logging mechanisms to capture test results and facilitate debugging.
+ - Add support for additional interfaces like HATs or PocketCape headers.
+- **How it will be done**:
+ - Set up protocol analyzers for communication monitoring.
+ - Implement a logging system to track test status and results.
+ - Research and integrate support for additional interface components into the test farm.
+
+---
+
+.. _gsoc-beagle-tester-vidhu-m10:
+
+Documentation & Final Deliverables (August 11 – August 25)
+===========================================================
+
+- **What will be done**:
+ - Update `cape_interface_spec.md` with fixes based on hardware mapping feedback.
+ - Document the process for setting up the test farm using defined hardware/software tools.
+ - Provide guidelines for extending tests to new mikroBUS-enabled boards and integrating additional interfaces like Robotics Cape or HATs.
+ - Create user-friendly tutorials on how to use the Beagle Tester with mikroBUS cape.
+ - Prepare final deliverables, including codebase cleanup, detailed documentation, and packaging all materials for submission.
+- **How it will be done**:
+ - Review hardware and software feedback for any necessary updates.
+ - Write thorough setup and usage documentation, including code examples.
+ - Prepare submission materials, ensuring everything is well-documented and ready for deployment.
+
+.. _gsoc-beagle-tester-vidhu-final:
+
+Final Submission
+================
+
+- Submit final work product by **September 1st** at the latest.
+
+
+.. important::
+
+ **August 25 - September 1 - 18:00 UTC:** Final week: GSoC contributors submit their final work product and their final mentor evaluation (standard coding period)
+
+ **September 1 - September 8 - 18:00 UTC:** Mentors submit final GSoC contributor evaluations (standard coding period)
+
+Initial results (September 9)
+-----------------------------------------------------------
+
+.. important::
+ **September 9 - November 9:** GSoC contributors with extended timelines continue coding
+
+ **November 10 - 18:00 UTC:** Final date for all GSoC contributors to submit their final work product and final evaluation
+
+ **November 17 - 18:00 UTC:** Final date for mentors to submit evaluations for GSoC contributor projects with extended deadlines
+
+
+Experience and approach
+***********************
+- Currently a Sophomore majoring in Computer Science and Engineering.
+- Proficient in Python, C, Bash, Go, and JavaScript.
+- Familiar with CI/CD workflows and automated hardware testing.
+- Designed and developed Caffeen IoT Home Board, an ESP8266-based smart home automation system, and won the Digikey & EW Project Challenge 2024.
+- Successfully implemented IoT systems using ESP microcontrollers and MQTT protocols at **Sentinal Innovations**, ensuring seamless device-cloud communication also worked on DevOps for testing.
+- Engineered an AI-powered expert matching system (ExpeRelate), integrating NLP, Go, and FastAPI**, and won Government of India's Smart India Hackathon 2024 under **Ministry of Education**.
+- Developing a GenAI-Worklet Generator Agent at Samsung Research Institute, utilizing LLMs and agentic frameworks for automating R&D worklet generation. (Expected to finish by march end)
+
+Contingency
+===========
+
+If I encounter blockers when my mentor is unavailable, I will take the following steps:
+
+- Research and Documentation: I will refer to BeagleBoard.org documentation, the Beagle-Tester source code, Linux kernel documentation, and relevant technical forums.
+- Community Support: I will seek help from the BeagleBoard.org community on Discord and the BeagleBoard forum.
+- Debugging and Alternative Approaches: I will systematically debug issues, analyze logs, and experiment with alternative solutions before escalating problems.
+
+Benefit
+========
+A community member on the BeagleBoard forum stated:
+"Having automated regression testing for mikroBUS capes will be a huge step forward for kernel and device-tree overlay maintainers."
+
+The successful completion of this project will greatly enhance the BeagleBoard.org community’s ability to test and verify mainline Linux kernel changes. By integrating mikroBUS support into Beagle-Tester, we will enable automated regression testing for a wide range of sensor and peripheral interfaces, reducing manual testing efforts and ensuring high hardware reliability.
+
+This work will contribute to the OpenBeagle CI server, helping developers verify kernel patches more efficiently. The project also aligns with BeagleBoard.org’s mission to provide open-source, community-driven hardware solutions.
+
+
+Misc
+====
+
+I will ensure compliance with all GSoC general requirements and submit my merge request to the BeagleBoard GitHub repository. The link to the merge request will be provided once I finalize my initial implementation
+
+
+Suggestions
+===========
+
+Well, If you read this far, then please give me a review for this proposal as well. Thanks.
+
+References
+==========
+
+1. `Using MikroBus <https://docs.beagleboard.org/boards/beagleplay/demos-and-tutorials/using-mikrobus.html>`_
+2. `Exclave Repository <https://github.com/exclave/exclave>`_
+3. `Beagle-Tester README <https://openbeagle.org/jkridner/beagle-tester/-/blob/master/README.md?ref_type=heads>`_
+4. `Buildroot Manual <https://buildroot.org/downloads/manual/manual.html#outside-br-custom>`_
+5. `Kernel Mailing List Discussion <https://lore.kernel.org/all/9c326bb7-e09a-4c21-944f-006b3fad1870@beagleboard.org/>`_