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.
9

Week 3: Integrating the Modernized Camera Stack

This week focused on upstreaming and integrating the camera subsystem changes developed during the previous weeks. After several review iterations and debugging sessions, PR #108 was merged into main.

Accomplishments

  • Addressed review feedback and finalized the Greybus Camera modernization work.
  • Replaced legacy camera device lookup paths with Devicetree-based device discovery using Zephyr APIs.
  • Updated the camera subsystem to operate entirely on the modern Greybus infrastructure, removing remaining dependencies on legacy allocation mechanisms.
  • Added format handling fixes and protocol mappings required for successful host-side camera enumeration.
  • Verified compatibility across all build configurations, with all CI checks passing.

Engineering Challenges

The primary challenge this week was not inside the camera driver itself, but in the Greybus connection layer.

While the capability translation work from the previous week was functional, requests originating from the host were not consistently reaching the camera handlers after the migration away from the legacy architecture. Debugging this required tracing how devices were allocated, registered, and resolved through the Greybus CPort infrastructure.

A significant amount of time was spent investigating greybus_cport.c, following request routing paths, and understanding how the connection layer associated incoming messages with protocol handlers. The migration to Devicetree-based device discovery exposed several assumptions in the older implementation that no longer held true.

After updating the routing path and device resolution logic, host requests could successfully traverse the Greybus stack and reach the camera subsystem through the new infrastructure.

Current Status

The Greybus Camera subsystem is now integrated with the modern Zephyr device model and Greybus messaging framework. Capability requests can be routed from the host through the Greybus transport layer to the camera backend and return protocol-compliant responses.

Plans for Next Week

  • Implement stream configuration operations and complete the flush and capture support.
  • Start initial development of the Greybus Audio protocol.
10

Week 4: Camera Data Plane Bring-up & Streaming Validation

Accomplishments

  • Implemented the initial Camera Data Plane architecture on top of the Camera Control Plane foundation. Finished the flush and capture support as well with the stream configuration operations.

  • Established an end-to-end streaming path in native_sim:

    video buffer -> dequeue -> fragment frame -> transport send -> recycle buffer

  • Successfully validated frame fragmentation by transmitting 4096-byte frames as four 1024-byte Greybus DATA packets.

  • Added comprehensive ztest coverage for capture, streaming, and flush operations.

  • Opened a stacked Draft PR for the Camera Data Plane implementation, building on top of the Camera Control Plane work from the previous weeks.

Technical Highlights

  • Implemented frame fragmentation and buffer lifecycle management for the Camera DATA path.
  • Validated correct buffer recycling after transmission to prevent buffer starvation during continuous streaming.
  • Performed extensive instrumentation and debugging of the streaming pipeline to understand behavior under sustained data traffic.

Challenges & Debugging

While validating continuous streaming, I encountered a series of issues that only became visible once real data began flowing through the pipeline.

  • Initially, streaming appeared to stall during the first DATA fragment transmission.
  • After instrumenting the allocation path, I found that repeated fragment allocations were exhausting the default Greybus heap.
  • Increasing the heap size allowed transmission to proceed further, which then exposed a second bottleneck: the dummy transport queue filling faster than it could be drained.

These investigations helped separate Camera protocol logic issues from transport-layer limitations and provided a much clearer understanding of how high-bandwidth Greybus protocols interact with the underlying transport infrastructure.

Following discussions with the maintainers, I also learned more about the intended architecture for high-bandwidth protocols, including protocol-owned memory pools, direct transport submission paths, and the tradeoffs involved in different transport implementations.

Plans for Next Week

  • Clean up and refine the Camera Data Plane implementation based on maintainer feedback.
  • Continue evaluating memory-management strategies for sustained high-bandwidth streaming.
  • Begin initial work on the Audio protocol implementation while Camera Data Plane reviews are ongoing.
11

Week 5: Camera Upstream Merge & Audio Control Plane MVP

Accomplishments

  • Camera Control Plane Merged: The foundational Camera Control Plane PR was reviewed, approved, and merged into the upstream repository.
  • Camera Data Plane Progress: Updated the stacked Camera Data Plane PR after the control-plane merge by rebasing it onto main. Continued development of the streaming pipeline, including dynamic stream configuration and capture handling.
  • Audio Control Plane MVP: Implemented a lightweight fake_audio codec driver for the native_sim environment. This mock driver provides a software-only hardware abstraction layer for validating Greybus Audio control operations without requiring physical hardware.
  • Audio ztests: Added an initial ztest suite covering codec configuration, input/output volume, mute control, and codec start/stop operations. All implemented tests pass locally and in CI.

Technical Highlights

  • Native Zephyr Audio Integration: Rather than introducing a custom abstraction layer, the fake codec was implemented directly against Zephyr’s existing audio_codec_api, allowing future Greybus protocol handlers to interact with the standard codec interface.
  • Control-Plane State Validation: The fake codec retains configuration and property state (volume, mute, start/stop) internally, allowing ztests to verify protocol behavior without depending on physical audio hardware.
  • Isolated Test Environment: Configured a dedicated Devicetree overlay and Kconfig setup for native_sim, enabling the audio control plane to be developed and validated independently of the Greybus protocol implementation.

Challenges & Debugging

  • CI Build Differences: While the driver built successfully locally, GitHub Actions failed because the project enables -Werror, exposing issues that were not immediately visible during local development.
  • Driver API Pattern: While implementing the mock codec, I initially used the newer DEVICE_API helper. After comparing with the existing Zephyr audio drivers, I aligned the implementation with the subsystem’s established pattern by using static const struct audio_codec_api, ensuring consistency with the current audio driver architecture.
  • Build System Integration: Worked through Kconfig, CMake, and device initialization issues while integrating the new driver into the Zephyr build system, resulting in a clean build for the software-only testing environment.

Plans for Next Week

  • Begin implementing the Greybus Audio protocol handlers in subsys/greybus/audio.c.
  • Translate Greybus Audio requests into the corresponding Zephyr audio_codec operations.
  • Continue addressing maintainer feedback on the Camera Data Plane PR as reviews come in.
12

Week 6: Audio Protocol Handlers, ztest Integration & Midterm Evaluation

Accomplishments

  • Audio MVP Merged Upstream: The fake_audio codec driver (Audio Control Plane MVP) was successfully merged upstream, validating the implementation approach of closely following Zephyr’s audio_codec_api patterns and coding conventions.

  • Audio Protocol Development: Began implementing the Greybus Audio protocol in subsys/greybus/audio.c, starting with the protocol initialization flow through the GB_AUDIO_TYPE_PROTOCOL_VERSION handler.

  • ztest Integration: Integrated the new Audio Control Plane handlers into Zephyr’s testing infrastructure by wiring them into the build system and creating ztest-based unit tests that validate protocol behavior using mocked Greybus messages.

  • GSoC Midterm Evaluation: Successfully completed and submitted the GSoC Midterm Evaluation.

Technical Highlights

  • Modernizing the Audio Stack: While bringing up the protocol implementation, I initially searched for legacy Project Ara audio definitions before discovering that modern Zephyr already provides the required Greybus Audio protocol structures and operation IDs through greybus_protocols.h. This eliminated unnecessary legacy dependencies and allowed the implementation to remain aligned with Zephyr’s current architecture, requiring only the protocol version operation (0x01) to be defined locally.

  • Testing Around Internal Abstractions: The Greybus core intentionally hides struct gb_driver behind an internal header to preserve subsystem boundaries. Rather than breaking this abstraction for testing, I adapted the design by exposing the protocol handler functions directly to the test suite. This enabled comprehensive unit testing of the connection lifecycle and operation handlers while preserving the driver’s encapsulation.

Challenges & Debugging

  • Mocking Flexible Array Structures: Constructing test Greybus messages required working around struct gb_message, which uses a flexible array member for payload storage. Instead of assigning payload pointers directly, I created properly aligned byte buffers and cast them to struct gb_message, allowing realistic protocol packets to be constructed for testing.

  • Resolving Cross-Directory Build Issues: Integrating a test suite located under tests/greybus/integration/audio/ with implementation files in subsys/greybus/ exposed several CMake include path and source dependency issues. After adjusting target_include_directories() and explicitly linking the required subsystem sources into the test application, the Audio Control Plane could be built and tested successfully within Zephyr’s ztest framework.

Plans for Next Week

  • Implement the remaining Greybus Audio protocol handlers, including topology and control operations.

  • Connect Greybus protocol requests to the Zephyr audio_codec API provided by the newly merged fake codec driver.

  • Expand the ztest suite to cover complete Audio Control Plane configuration workflows and additional protocol edge cases.

13

Week 7: Camera Finalization and Audio Protocol Kickoff

Accomplishments

  • Camera PR Merged & Migrated: Successfully got the Camera Protocol implementation merged into the main tree. Right before the merge, I handled a last-minute upstream API migration by porting the subsystem to use the newly introduced video_driver_flush API.

  • Audio Subsystem Kickoff (SET_PCM): Transitioned to the Greybus Audio protocol. Implemented the PCM configuration handler, which parses incoming Greybus sample rate and bit-depth payloads and maps them to a Zephyr audio_codec_cfg structure to configure the virtual codec.

  • Audio Control Routing (SET_CONTROL): Implemented the handler to map Greybus control requests (such as Volume and Mute) directly to Zephyr’s audio_property_t APIs, allowing the host to successfully modify audio states on the Zephyr side.

Tech Driving Decisions

  • Property Mapping Abstraction: Instead of hardcoding if/else statements for every audio control, I built a gb_audio_lookup_property lookup table to map Greybus Control IDs to Zephyr’s AUDIO_PROPERTY_OUTPUT_VOLUME and AUDIO_PROPERTY_INPUT_MUTE. This keeps the driver modular and simplifies adding new controls in the future.

Challenges Faced & Roadblocks

  • Last-Minute API Changes: Migrating to video_driver_flush right before the merge required re-validating the end-to-end stream stopping logic to ensure it behaved exactly as dictated by the Greybus specification.

  • Data Type Translation: Mapping Greybus’s 32-bit little-endian audio control payloads to Zephyr’s native audio_property_value_t union required careful endian conversion (sys_le32_to_cpu) to avoid corrupting volume levels on the device.

Ongoing Blockers

  • None.

Plans for Next Week

  • Tackle the ALSA GET_TOPOLOGY handshake to allow the Linux host to dynamically discover the audio capabilities exposed by the Greybus Audio protocol.

  • Implement stream activation support (ACTIVATE_TX / ACTIVATE_RX).

14

Week 8: Dynamic Audio Topology and Stream Activation

Accomplishments

  • Dynamic ALSA Topology Handshake: Successfully implemented the GET_TOPOLOGY_SIZE and GET_TOPOLOGY operations. Instead of returning static mock data, the Zephyr device now dynamically constructs a compliant hardware topology (DAIs, Controls, and Widgets such as Speakers and Microphones) and sends it to the Linux host, allowing ALSA to automatically generate the sound card and expose the appropriate audio controls.

  • Stream Activation Handlers: Implemented ACTIVATE_TX and ACTIVATE_RX, enforcing the Greybus Audio state machine so that physical audio streams cannot be activated until PCM parameters have been successfully configured by the host.

  • Test Coverage: Wrote comprehensive ztest suites for all newly implemented audio operations, with all tests passing in the native_sim environment.

Tech Driving Decisions

  • RTOS-Safe Memory Management: For the topology payload, I deliberately avoided both the thread stack (to prevent stack overflows) and dynamic heap allocation (to prevent fragmentation). Instead, I used a statically allocated and aligned buffer (static uint8_t buffer[AUDIO_TOPOLOGY_MAX_SIZE] __aligned(4)). This guarantees predictable memory usage in resource-constrained RTOS environments and prevents ARM unaligned access faults.

  • Hardware Abstraction vs. Protocol Compliance: Zephyr’s current audio codec API heavily favors playback and does not yet expose an audio_codec_start_input() equivalent. To maintain strict Greybus protocol compliance during recording attempts (ACTIVATE_RX), I architected the handler to return a successful Greybus response while decoupling the protocol layer from the underlying API limitations. This preserves Linux ALSA compatibility today while allowing seamless integration once native input support becomes available in Zephyr.

Challenges Faced & Roadblocks

  • Flexible Array Pointer Arithmetic: Packing the variable-length data[] array at the end of the topology structure required meticulous tracking of a moving data_ptr cursor using C pointer arithmetic. Even a single misaligned byte could cause the Linux kernel ALSA driver to silently reject the entire topology blob during device probing.

  • Legacy Header Compatibility: Discovered a legacy typo in the upstream Greybus specification (GB_AUDIO_WIDGET_STATE_ENAABLED). To maintain compatibility with the existing Greybus headers, the Zephyr implementation intentionally preserves the misspelled identifier.

  • State Machine Testing: During ztest implementation for stream activation, I refined the test logic to correctly assert that the driver remains in STATE_CONFIGURED during active streaming, as stream activation does not modify the fundamental PCM configuration state.

Ongoing Blockers

  • None currently.

Plans for Next Week

  • Implement the SEND_DATA mechanism to handle PCM audio payload streaming.

  • Handle audio interrupt events

15

:sparkles: Milestone Checkpoint :sparkles: : Camera Merged & Audio Foundation Complete

Before diving into the next set of technical weekly updates, I wanted to provide a quick high-level status check on the project’s milestones.

Camera Protocol tested on native_sim: 100% Merged The Greybus Camera Protocol implementation is officially merged upstream! The final polish involved migrating the subsystem to use the newly introduced video_driver_flush API, ensuring our implementation perfectly aligns with Zephyr’s latest video subsystem standards.

Audio Protocol: Core Architecture Ready With the camera wrapped, the core foundation for the Greybus Audio protocol is now built. The implementation currently supports:

  • SET_PCM (Codec configuration)
  • SET_CONTROL (Mapping Greybus properties like Volume/Mute to Zephyr APIs)
  • GET_TOPOLOGY_SIZE & GET_TOPOLOGY (Dynamic ALSA hardware map generation and strict Little-Endian memory packing)
  • ACTIVATE_TX & ACTIVATE_RX (Stream activation mapped to the internal state machine)

Dynamic ALSA Topology Handshake: Initially, I considered using a static lookup table to mock control IDs (like Volume and Mute) simply to test the SET_CONTROL parsing logic in native_sim. However, after consulting with my mentors, I pivoted to implementing the full GET_TOPOLOGY_SIZE and GET_TOPOLOGY operations. Because the Greybus specification strictly mirrors Linux ALSA, the Linux kernel expects audio hardware to dynamically report its own capabilities. By building this complete handshake, the Zephyr device dynamically constructs and transmits a compliant hardware map (DAIs, Controls, and Widgets), guaranteeing that the Linux host can automatically generate the correct soundcard and UI without relying on hardcoded assumptions.

Validation Status Implementation + Validation: All implemented audio operations are fully covered by native_sim ztest suites. The tests strictly enforce the audio state machine (e.g., rejecting ACTIVATE commands if SET_PCM hasn’t configured the device), and all tests are currently passing with 100% success.

1 Like
GSoC 2026 Final Report: Greybus Camera & Audio Protocol Implementation in Zephyr
GSoC 2026 Final Report: Greybus Camera & Audio Protocol Implementation in Zephyr
16

Week 9: Audio Completion & Final Native Sim PR Merged

Accomplishments

  • Final Audio PR Merged!
    The comprehensive PR covering Greybus Audio Teardown, Events, and Power Management has been officially merged upstream. This marks the completion of the Greybus Audio protocol implementation and validation in the native_sim environment.

  • Event Handling Implementation:
    Successfully implemented asynchronous reporting for JACK_EVENT and BUTTON_EVENT, allowing the Zephyr device to proactively notify the Linux host of hardware state changes (such as a headphone being plugged in) without waiting for a host poll.

  • Stream Lifecycle Completion:
    Implemented the remaining PCM teardown and power management handlers, ensuring that buffers are properly flushed and hardware is safely powered down when the ALSA host closes the audio stream.

Tech Driving Decisions

  • IRQ-Safe Event Queues:
    Since audio jack and button events originate from hardware interrupts, they cannot safely block while sending Greybus network messages. The event handler was therefore designed to push state changes to a dedicated background work queue, decoupling interrupt context from the Greybus transport layer.

Challenges Faced & Roadblocks

  • Audio Data Plane (SEND_DATA):
    Bridging the synchronous ALSA data stream with the asynchronous Zephyr audio buffer queue required careful handling of Zephyr’s memory slabs. Ensuring deterministic memory allocation without starving the kernel during high-throughput audio streaming required significant tuning in the ztest environment.

Ongoing Blockers

  • None. The native_sim foundation is officially complete.

Plans for Next Week

  • Transition out of software simulation.
  • Begin physical hardware testing using the BeaglePlay and BeagleConnect Freedom
17

Week 10: Physical Hardware Transition & Sub-GHz Debugging

Accomplishments

  • Transition to Physical Hardware: Moved the project out of native_sim and began deploying the Greybus protocol stack onto physical Beagle hardware.
  • Correct Node Firmware Deployment: Successfully built and flashed the Greybus net sample directly onto the BeagleConnect Freedom (BCF) via USB (west flash), ensuring the correct transport configuration was applied (-DOVERLAY_CONFIG=overlay-802154-subg.conf).
  • Root-Caused Gateway Flashing Issues: Identified why the internal BeaglePlay gateway radio was failing to update, tracing it back to the 5.10 kernel’s serdev driver locking the ttyS1 UART and breaking userspace flasher tools.

Tech Driving Decisions

  • Bypassing Legacy Host Kernels via USB Flashing: Instead of burning more time fighting deprecated 5.10 kernel drivers to update the BeaglePlay gateway, Made the decision to pivot. Bypassed the host kernel entirely by building and flashing the Greybus Zephyr application directly onto the standalone BCF node via USB from my development workstation (venus), isolating the variables for testing.

Challenges Faced & Roadblocks

  • Gateway Firmware vs. Node Firmware: Ran into an initial build failure by accidentally trying to compile the internal BeaglePlay gateway coprocessor firmware (cc1352-firmware) for the standalone BCF board target. I resolved this by properly distinguishing the gateway repo from the greybus-zephyr/samples/subsys/greybus/net/ application space.
  • Overlay Configuration Syntax: The sub-GHz transport layer requires specific Zephyr configurations to bridge Greybus packets over the radio. I initially passed these using the incorrect CMake flag (-DEXTRA_CONF_FILE), which failed. Corrected this by using the proper subsystem overlay hook (-DOVERLAY_CONFIG=overlay-802154-subg.conf).
  • Network Bridging / Enumeration: Despite flashing the correct firmware to the BCF, the 802.15.4 sub-GHz link is not fully establishing. Running gpiodetect on the BeaglePlay host does not yet enumerate the remote Greybus GPIO endpoints, indicating a breakdown in the transport handshake.

Ongoing Blockers

  • Debugging the sub-GHz transport link between the BeaglePlay gateway and the BCF node to successfully enumerate the remote endpoints via gpiodetect.

Plans for Next Week

  • Resolve the Greybus 802.15.4 link issue so the host can communicate with the node.
  • Finalize bandwidth profiling for Camera/Audio payload fragmentation over the 250kbps sub-GHz connection.
  • Draft and submit the GSoC 2026 Final Work Product.
18

:sparkles: Milestone Checkpoint :sparkles: : First Hardware Validation

The Greybus GPIO implementation is now successfully validated on physical hardware that I got.
After completing the native simulation testing, I moved to hardware validation using the BeagleConnect Freedom (BCF) + BeaglePlay setup.

The final end-to-end path is now working:

BeaglePlay

↓

Linux Greybus GPIO

↓

Greybus transport

↓

Zephyr on BCF

↓

CC1352P7 GPIO

↓

Physical LED

The BCF is successfully discovered by Linux as:
gpiochip4 [greybus_gpio] (32 lines)
I was then able to control the BCF’s LED_LINK (GPIO 18) directly from the BeaglePlay using gpioset. The LED could be switched on and off successfully.

Hardware Bring-up

Getting to this point involved a few challenges with the flashing and kernel environment.
The newer flashing mechanism was not working with the 5.x kernel on my setup, so I moved to kernel 6.18. During the process, I also accidentally moved to an unofficial 7.1 kernel, which broke the setup.
Since I did not have a dedicated TTL adapter available, I recovered the board back to the 5.x environment using a Black Pill as a makeshift USB-to-TTL serial interface, and subsequently moved to 6.18 for the hardware flashing.
After resolving the bring-up issues, the firmware was successfully flashed and the Greybus connection was established end-to-end.

Current Status- Done

  • Greybus GPIO implementation
  • Native simulation validation
  • CC1352P7 firmware build
  • Hardware flashing
  • Greybus connection between BeaglePlay and BCF
  • Linux greybus_gpio registration
  • End-to-end GPIO operation
  • Physical LED control on BCF

This marks the first successful physical hardware validation of a Greybus protocol before I move on to the camera and audio subsystem on hardware

Next Step

The next focus is the Camera subsystem.
I will begin hardware validation by generating and transmitting fake camera frames through the Greybus camera pipeline, and verify the end-to-end data path on hardware.