Weekly Progress Report: upstream wpanusb bcfserial

Google Summer of Code
1

Hello everyone!
I’m Manas, I’ll be working on the project upstream wpanusb bcfserial as part of Google Summer of Code 2025, under the guidance of my mentors @vaishnav @ayush1325 and @Vedant_Paranjape

The goal of this project is to upstream the wpanusb and bcfserial drivers, which are essential for enabling Linux-based systems (like BeagleConnect Freedom) to act as Sub-GHz IEEE802.15.4 gateways. These drivers currently live outside the mainline kernel and have several known functional gaps. My work this summer will involve:

  • Adding missing driver ops (e.g., Listen Before Talk, frame retries, etc.)
  • Implementing the corresponding firmware-side logic in Zephyr
  • Enabling Linux to query key radio parameters (band, power, supported channels)
  • Supporting dynamic reading of the extended address
  • Laying the groundwork for Zigbee and multi-band (2.4GHz/SubGHz) support

This thread will serve as my weekly devlog, where I’ll document:

  • What I accomplished each week
  • Current roadblocks and how I’m addressing them
  • Any unresolved blockers or tricky issues
  • Plans and goals for the upcoming week

I’ll also be using this space to share relevant patches, RFCs, and discussions with the upstream kernel and linux-wpan communities.

Please feel free to chime in with feedback, suggestions, or just drop by to follow the progress. I’m really excited to contribute and collaborate with the broader community this summer!

Looking forward to a challenging and rewarding journey ahead!

Warm regards,
Manas Gupta

1 Like
2

Week 0

:white_check_mark: Accomplishments

  • Engaged with mentors for feedback and discussion regarding approach, and timeline finalization
  • Acquired the BeagleConnect Freedom hardware, the primary development platform
  • Initiated a systematic audit of wpanusb.c and bcfserial.c to identify hard-coded parameters, mapping the communication flow between Linux drivers and Zephyr firmware and document unimplemented driver operations LINK : https://www.notion.so/GSoC-25-upstream-wpanusb-bcfserial-blog-20560fe7db43801b8cb0f44fc375a927?source=copy_link
    I’ll work on converting this into a blog website
  • Studied IEEE 802.15.4 specifications and analyzed Zephyr’s radio_api implementation to understand extension points
  • Started configuring the ARM cross-compilation environment for BeagleConnect Freedom targets
  • Installed and configured the b4 tool to streamline interactions with Linux kml
  • Delivered a detailed design document outlining the dynamic configuration strategy
  • Recorded and published an introductory YouTube video summarizing project goals and design. link: hi all, I’ve made a introductory video. link here: https://www.youtube.com/watch?v=MP_S028ihf4

:hammer_and_wrench: Resolution to Blockers

  • Hardware Acquisition: The BeagleConnect Freedom hardware, has been acquired. This unblocks tasks dependent on the physical hardware.

:warning: Ongoing Blockers

  • Hardware Setup Completion & Familiarization: The complete setup of the BeagleConnect Freedom development environment and thorough familiarization is still in progress. This is necessary before intensive hardware-specific development and testing can fully commence.

:date: Plans for Next Week

  • Implement prototype enhancements in the Linux drivers:
    • Implement the basic structure for Listen Before Talk (LBT) in both wpanusb and bcfserial drivers, including parameter validation in wpanusb_set_lbt() and preparing the parameter passing mechanism.
    • Add the framework for the frame retry mechanism, updating wpanusb_set_frame_retries() and implementing equivalent functionality in bcfserial.
    • Replace hard-coded power arrays with placeholder query functions.
    • Develop unit tests to validate these new functionalities.
  • Set up CI/CD pipelines for automated testing of code changes.
  • Run existing drivers with diagnostic logging to establish a baseline for current functionality.
  • Document all current limitations with specific code references.
  • Define data structures for device capability information.
  • Create a detailed mapping of required new firmware API functions (e.g., get_ext_address(), get_band(), get_supported_channels()) to the corresponding Linux driver routines.
  • Outline where and how these API calls will be incorporated into driver initialization and configuration.
  • Share the updated design specification with mentors for feedback.

Feel free to share any suggestions or feedback. Looking forward to an exciting and productive journey with you all!

1 Like
3

Week 2

:white_check_mark: Accomplishments

  • Continued deep-diving into the wpanusb.c and wpanusb.h driver code to understand internal flow and hook points for new functionality
  • Finalized the design plan for implementing wpanusb_set_lbt() and wpanusb_set_frame_retries() along with required USB control message formatting
  • Began planning the firmware-side API additions (get_extended_addr(), get_supported_channels(), get_tx_power_levels()) required for Milestone 3.
  • Outlined how to replace hardcoded power arrays with placeholder query functions as a first step toward dynamic configuration.

:hammer_and_wrench: Resolution to Blockers

  • Verified readiness of the development setup to begin coding and testing changes this week.

:warning: Ongoing Blockers

  • Out-of-station period (June 5–8) and academic commitments slowed down live testing and code push

:date: Plans for Next Week

  • Implement prototype enhancements in the Linux drivers:
    • Implement the basic structure for Listen Before Talk (LBT) in both wpanusb and bcfserial drivers, including parameter validation in wpanusb_set_lbt() and preparing the parameter passing mechanism.
    • Add the framework for the frame retry mechanism, updating wpanusb_set_frame_retries() and implementing equivalent functionality in bcfserial.
    • Replace hard-coded power arrays with placeholder query functions.
    • Develop unit tests to validate these new functionalities.
  • Set up CI/CD pipelines for automated testing of code changes.
  • Create a detailed mapping of required new firmware API functions (e.g., get_ext_address(), get_band(), get_supported_channels()) to the corresponding Linux driver routines.
  • Outline where and how these API calls will be incorporated into driver initialization and configuration.

Looking forward to wrapping up both Milestone 2 and Milestone 3 by next week. Feedback and suggestions are welcome!