Weekly Progress Report: Implement Missing Greybus Protocols in Zephyr

Google Summer of Code
1

I’m thrilled to kick off my GSoC 2026 journey working on “Implementing Missing Greybus Protocols in Zephyr”. Instead of just listing out my commits each week, I want to use this thread to document my actual engineering process- what I am building, the technical constraints driving those decisions, and the roadblocks I hit along the way.
Feel free to share any suggestions or feedback. Looking forward to an exciting and productive journey with you all!

1 Like
2

Kickoff- Community Bonding and Architecture Planning

Accomplishments

  • Mapped out the complete software architecture strategy for the Greybus Camera and Audio protocol integrations.
  • Conducted a deep dive into the Zephyr source tree to analyze existing drivers and evaluate API compatibility with Greybus operations.
  • Established the core development roadmap- Prioritizing the Camera protocol first, followed by the Audio protocol implementation
  • Front-loaded heavy architectural planning to accommodate upcoming university semester exams.
  • Reused and built upon the existing Greybus codebase infrastructure that had already been established through previous PRs.

Tech Driving Decisions

Hardware Independence

Made the strategic decision to execute all initial development inside Zephyr’s native_sim environment. This completely decouples the protocol routing logic from physical hardware constraints and allows for pure software validation before deploying to embedded hardware.

Target Hardware Platform

The final intended deployment target for the implementation is: BeaglePlay as the Host and BeagleConnect Freedom and/or BeagleConnect Zepto as the Greybus node devices

Challenges Faced & Roadblocks

API Discovery

Navigating Zephyr’s massive subsystem tree to locate the exact structures and APIs (such as video.h and i2s.h) that align cleanly with the Greybus specification expectations, ensuring existing Zephyr abstractions are leveraged instead of reinventing subsystem logic.

Ongoing Blockers

  • None currently.

Plans for Next Week

  • Establish the native_sim environment locally.
  • Implement a virtual video driver: fake_camera.c
3

Week 0: Community Bonding: Local Prototyping & Planning

Accomplishments

  • Successfully established the native_sim testing environment in my local laptop.
  • Implemented a fully functional virtual video driver (fake_camera.c) mapped directly to Zephyr’s official <zephyr/drivers/video.h> API locally.
  • Engineered the virtual camera using k_fifo queues for zero-copy memory management and a k_timer to simulate hardware sensor interrupts at 10 FPS.

Tech Driving Decisions

Zero-Copy Memory
  • Strict adherence to Zephyr’s memory model by utilizing video_buffer pointers instead of duplicating data, ensuring the Greybus handler operates highly efficiently.

Challenges Faced & Roadblocks

The Moving Upstream Target
  • During compilation, severe type-casting errors occurred inside the video.h API implementation.
  • Upon investigating the upstream Zephyr source tree, I discovered the core API had recently been refactored (dropping the enum video_endpoint_id parameter).
  • Updated the mocked function signatures to adapt to the live open-source ecosystem and maintain compatibility with upstream Zephyr changes.

Ongoing Blockers

  • None currently. The simulation pipeline and protocol handler are compiling cleanly.

Plans for Next Week (Official Coding Period)

  • Officially begin the GSoC coding period and commit the locally tested prototype changes to the repository.
  • Develop the Greybus Camera Protocol handler (gb_camera.c) to bridge the operations.
  • Wrap the entire camera protocol pipeline in comprehensive ztest suites to mock host packets and automatically assert responses.
4

Wouldn’t week 1 start on May 24, when the coding period starts?

5

I numbered them as week 0 (may 5–12) and week 1 (may 13–20) to reflect the actual timeline of my local prototyping and architecture planning. The code I mentioned was just work built in my local setup and tested and it has not been pushed to GitHub yet. If needed, I shall rename these posts to ‘Pre-Coding/Community Bonding’ updates, and officially start ‘Week 1’ on May 24th when I officially push the code to match the GSoC schedule.

6

Yeah, I think Pre-Conding/Comunity Bodning would be better. Week 1 should match GSoC schedule.

1 Like
7

Week 1: Virtual Camera Implementation & Linker Script Quirks

Accomplishments

  • Implemented fake_camera.c, a virtual video driver running entirely inside Zephyr’s native_sim environment.
  • Built the basicintegration.camera ztest suite to validate buffer queuing and timer synchronization.
  • PR Merged- The baseline camera infrastructure is now in the greybus-zephyr tree (* PR #105).
  • Fixed the certificate configurations and corrected the BeagleConnect Freedom board targets to ensure the deployment pipeline is stable for physical hardware testing.

Engineering Deep Dive

The main roadblock this week was a severe environment mismatch. My code passed locally with ASAN, strict -Os, and tight stack limits, but it consistently failed in GitHub Actions with a silent rc=1.

The internal handler.log revealed a kernel panic caused by a strict new security assertion introduced in Zephyr 4.4.

The Cause

My local tree was on v4.2.0, while CI was running main (v4.4.0). In Zephyr 4.4, the kernel strictly validates that dev->api falls within the _video_driver_api_list_start memory boundary to prevent thread jumping attacks. Because I used a standard static const struct, the compiler placed it in generic .rodata. The Zephyr linker script did not classify it as a video driver API object, leaving it outside the approved memory region and triggering the panic.

The Fix

I updated my local tree to main and refactored the driver to use the DEVICE_API(video, ...) macro. This automatically applies the required GCC section attributes, allowing the Zephyr linker script to correctly place the API structure within the approved memory boundaries.

Plans for Next Week

With the isolated virtual camera stable, I am moving on to the Greybus handlers:

  • Protocol Handlers: Map operation IDs and implement the initial Greybus camera handlers (eg- Capabilities, Config).
  • Testing: Expand the ztest suite to validate the new Greybus handler pathways.
  • Stretch Goal: If the camera handlers are completed ahead of schedule, begin architectural mapping and initial implementation for the Greybus Audio protocol.
8

Week 2: Greybus Camera Refactoring & ExtCSI Capability Translation

This week focused on modernizing the Greybus Camera subsystem and implementing the foundation for camera protocol support in Zephyr. The existing camera.c implementation was based on an older architecture (nuttx) and relied on deprecated APIs that no longer compile cleanly with modern Zephyr. Rather than patching individual issues, I refactored the subsystem to align with the current Greybus and Zephyr infrastructure.

Accomplishments

  • Re-architected the legacy Greybus Camera subsystem (camera.c), migrating it from the deprecated gb_operation architecture to the modern gb_message transport API. Implemented camera protocol version handling.
  • Added the first capability translation path between Zephyr’s Video API and the Greybus Camera protocol.
  • Introduced greybus_camera.h, defining the packed ExtCSI protocol structures required by the Linux host.
  • Implemented dynamic capability payload generation based on the formats reported by the underlying Zephyr video device.
  • Opened PR #108 for upstream review.
  • Restored the subsystem to a clean build state with all build checks (127/127) passing.

Engineering Deep Dive

The main challenge this week was translating camera capability data between Zephyr’s video subsystem and the Greybus Camera protocol expected by the Linux host.

Zephyr exposes camera capabilities through struct video_caps, while the Linux Greybus driver expects a tightly packed ExtCSI payload matching the protocol specification. There was no existing mechanism to translate between these two representations.

To solve this, I implemented a capability translation layer that:
→ Queries the Zephyr video device for supported formats.
→ Dynamically determines the number of available formats.
→ Allocates protocol payload memory based on the discovered capabilities.
→ Translates Zephyr pixel formats into their Greybus equivalents.
→ Serializes the results into protocol-compliant ExtCSI structures for transmission to the host.

To ensure the payload layout matches the protocol specification exactly, I introduced packed ExtCSI structures and overlaid them onto the dynamically allocated response buffer before transmission.

Current Status

The Greybus camera subsystem can now:

  • Receive capability requests from the host.
  • Query the Zephyr Video API.
  • Dynamically construct ExtCSI capability payloads.
  • Return protocol-compliant responses through the Greybus transport layer.

Plans for Next Week

  • Expand the native_sim ztest suite to validate capability translation, dynamic payload sizing, and memory bounds and continue implementing additional Greybus Camera protocol operations.
  • Begin architectural work on the Greybus Audio Control protocol.