These are the drivers that are used to enable Linux to use a BeagleConnect Freedom as a SubGHz IEEE802.15.4 radio (gateway). They need to be part of upstream Linux to simplify on-going support. There are several gaps that are known before they are acceptable upstream
Some notes from Stefan Schmidt:
The wpanusb linux driver is missing quite a few driver ops (listen before talk, set frame retries). I added rough sketches but these are non functional due to 2.
The zephyr firmware side needs to implement these ops as well and hook it up to the zephyr radio_api
A way to read the permanent extended address from the device to use in Linux is needed
The generic aspect of the firmware driver combo is missing completely. Band, supported channel, power levels, etc is all hard-coded in the linux driver and not queried from the device firmware. Its not even giving the page on which a channel is being set when changing it.
More driver ops are coming in right now as there is heavy work towards support management frames as well as active and passive scanning on the Linux stack. Which means these would need proper handling on the firmware side as well.
Ideally, we’d figure out how to make this radio interoperate with Zigbee. Support for both 2.4GHz and SubGHz is required.
Goal: Add functional gaps, submit upstream patches for these drivers and respond to feedback Hardware Skills: Familiarity with wireless communication Software Skills: C, Linux Possible Mentors:@jkridner, @ayush1325 Expected size of project: 175 hours Rating: Medium Upstream Repository:Linux References:
@ayush1325 should we change the BCF related proposal on GSoC @ BeagleBoard.org — gsoc.beagleboard.io documentation? I’d love to see this upstream work, but I want to align with whatever we have good mentorship and interest in–this seems like it doesn’t have a ton of GSoC interest.
Well, I’m not sure if wpanusb and bcfserial are as useful anymore. Instead some of the things I would love to see as a GSoC project (since I do not think I will be able to do them before May) are as follows:
Create a Greybus Protocol to allow network interfaces to be exposed over it. This should bring feature parity with wpanusb and bcfserial.
Implement Greybus Firmware update protocol for bcf and play cc1352.
Hello, I am interested in this project as I have worked with Bluetooth and Zigbee before. I am going to do some research based on the notes by Stefan, but could you provide some suggestions as to what would be needed to bring the wpanusb and bcfserial drivers up to the quality standards of the Linux kernel? I haven’t looked at the Linux kernel code in-depth, so any suggestions would be great.
The ideas by @ayush1325 also look interesting. Could you provide some references on how to get started on them?
The approach @ayush1325 introduces might get around some issues, but I think being able to engage the radio is something Linux developers want. I think emailing Stefan, probably on list, would be good to help define the project.
For the most part, it has been about those drivers missing the ability to query and configure the common aspects of the radio and protocol. He wrote up what I thought was a pretty good summary and would likely engage anyone serious about getting one or more of these drivers upstream.
I am editing the template but haven’t made a fork yet because I am using it as more of a brainstorming doc right now. I will clean it up and commit it tomorrow.
Will you be able to give feedback on the proposal?
The normal process is to make a fork first and to commit your small edits before walking away at any time. You can always clean-up your commit history later on a different branch. Saving your work into the repo early and often is a great way to keep on the right track. Syntax errors, etc., should not be a big deal on work in progress.
Believe me, taking the route of fork-first, then edit, committing often, will accelerate your learning greatly.
Hi I am interested in contributing to this project,
I’ve been reviewing the project discussions and code for the wpanusb and bcfserial drivers for BeagleConnect Freedom, and I’m now focusing on bridging the critical gaps for upstream integration.
To date, I’ve set up the environment, forked and built both repositories, resolved build issues (e.g., loading MAC802154 for wpanusb, fixing format warnings in bcfserial), and added debug output in the bcfserial probe. While I’m still troubleshooting device matching, my next step—once the probe is triggered—is to address the missing driver operations.
Specifically, I plan to:
Implement Missing Ops: Add support for listen-before-talk and frame retries, essential for IEEE802.15.4 operation.
Dynamic Capability Querying: Transition from hard-coded parameters (such as band, supported channels, and power levels) to dynamically querying device capabilities from the firmware.
Could you provide guidance on:
The recommended approach for implementing listen-before-talk and frame retries within the current driver framework—are there specific kernel practices or design patterns you’d advise?
The best method for moving from hard-coded parameters to dynamic querying of device capabilities. Should this be handled purely in the driver, or coordinated with the Zephyr firmware side to hook into the radio API?
Your thoughts on whether to continue enhancing the current drivers versus exploring alternatives like Greybus for exposing network interfaces and firmware updates.
I appreciate any insights you can offer on these points to help prioritize and refine the next phase of development.
Hi everyone!
I’d love to hear your thoughts, suggestions, or feedback on my approach so far. Also, could you let me know if this project is expected to be part of GSoC 2025? I’m currently working on building my proposal and would greatly appreciate your insights.
Well, this is a tad bit difficult to answer. I do know that the kernel lowpan subsystem is looking to overhaul things to make everything much more suitable for having a generic lowpan over usb/uart.
But I have not been involved in the upstream discussion much, so the apporach to take here will be largely dependent on discussion in the kernel mailing list.
Thanks for your response and for sharing your perspective!
I am actively monitoring the mailing list and integrating new insights into my approach. I have also reached out to Stefan and Christopher and am currently awaiting their feedback. In the meantime, if you come across any updates or have further thoughts on how I should align my work with the evolving lowpan framework, I would be grateful for any pointers.
Additionally, I welcome opinions and suggestions from the broader community and would especially love to hear @jkridner ’s thoughts. Any further insights or alternative approaches that others have considered would be extremely valuable as I refine my approach.
Thanks for for all your valuable feedback so far! I’ve updated my initial proposal draft for “Upstream wpanusb and bcfserial” based on our recent discussions and suggestions. I’m eager to receive any further insights or recommendations as I continue refining the proposal.
Your guidance means a lot to me, and I truly appreciate all the support! I’d especially love to hear thoughts from @ayush1325 and @jkridner