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.