Repository navigation
Conversation
|
But this portging should belong userspace, like nimble: |
| * pass through kernel objects such as FIFOs. | ||
| */ | ||
|
|
||
| struct net_buf_simple |
There was a problem hiding this comment.
netbuf provides interfaces for network byte order operations and bit-level read/write access; furthermore, when used in conjunction with TCP/IP, it ensures that there is no contention for iob resources.
| ############################################################################ | ||
| # boards/sim/sim/sim/configs/bt/defconfig | ||
| # | ||
| # Copyright (c) ByteDance Ltd. and/or its affiliates. |
There was a problem hiding this comment.
remove ALL company copyright
There was a problem hiding this comment.
is it a rewrite or a copy ? We can not remove company information without authors consent!
There was a problem hiding this comment.
the code is copied from Zephyr and adjusted by @anchao , so should drop Bytedance copyright and keep Zephyr.
There was a problem hiding this comment.
Yep, The initial version was ported from Zephyr, but all files have been adapted to support the native NuttX; the entire protocol stack utilizes NuttX kernel APIs and adheres to NuttX coding standards.
There was a problem hiding this comment.
since you are a bytedance contributor is it possible to update the license to match the rest if NuttX under ICLA or SGA for the new implemnetation
is it possible to move it to nuttx-apps
There was a problem hiding this comment.
As Xiaomi's representative, you seem perfectly comfortable with the incremental contribution model that Xiaomi benefits from in the Zephyr community. Yet when it comes to NuttX, you keep raising the bar and imposing additional barriers. Why the double standard?
There was a problem hiding this comment.
The current Nimble port in nuttx-apps calls a significant number of NuttX kernel APIs directly — APIs like k_thread_create, k_sem_, k_fifo_, various work_queue functions, and other internal kernel primitives.
This is complete nonsense. AI hallucinations, or what? Did you even verify this?
If your AI makes mistakes like these, it’s hard to have confidence in the quality of the code or any claims made about it.
There was a problem hiding this comment.
k_sem_, k_fifo_ and k_work_* are Zephyr names kept by NimBLE's mesh code, which was ported from Zephyr. It has nothing to do with nuttx porting layer.
There was a problem hiding this comment.
The new stack being proposed takes the opposite approach: it starts in the kernel where it belongs architecturally (just like TCP/IP, CAN, and other in-kernel network stacks), and then we add proper userspace access through the socket layer — the same pattern every other NuttX network subsystem follows. That's not treating Bluetooth "specially" — it's treating it consistently with the rest of the OS.
No it's not. TCP/IP, CAN and other in-kernel networks stacks occupy different OSI layers. This PR puts all OSI layers to kernel which is obviously wrong. Everything above L4-L5 that resides in the kernel is controversial. What you are proposing is equivalent to embedding HTTP, REST or CANopen into the kernel.
There was a problem hiding this comment.
Let me restate my proposal more clearly: the intention is not to keep all Bluetooth profiles in kernel space. The plan is to keep only the lower Bluetooth transport/protocol layers that need to interact closely with the network/device side in the kernel, especially L2CAP. Higher-level profiles and application-facing logic should be moved out of the kernel and maintained in libs/libbt.
So the long-term layering would be:
- kernel: controller/HCI integration, core host transport, L2CAP, and other lower-layer pieces that need kernel-side integration;
- libs/libbt: higher-level Bluetooth profiles and reusable host-stack logic;
- apps: shell commands, tools, demos, and other user-facing code.
This still follows the OSI layering principle. I am not proposing that profiles such as audio, GATT services, mesh models, or other application-level logic should permanently live in the kernel.
For the current first-stage PR, the main goal is to make the stack build and run in FLAT mode first. In FLAT mode the separation is naturally less strict, and keeping the profile code close to the stack can provide better performance and lower overhead. This is also important if we want NuttX Bluetooth to be competitive with mainstream embedded OS implementations such as Zephyr.
However, I agree that this should not become the final layout for Protected and Kernel builds. For the next stage, I plan to move the higher-level profiles into libs/libbt and keep only the necessary lower-layer kernel components in net/bt. The shell code has already been removed from this PR and will be moved to apps, so the current stack no longer contains userspace shell code.
In short, I agree with the concern about not putting all OSI layers into the kernel. My proposal is to keep L2CAP and the required lower layers in the kernel, while moving higher-level profiles to libs/libbt as part of the next-stage Protected/Kernel mode support.
| @@ -438,6 +390,7 @@ source "net/netlink/Kconfig" | |||
| source "net/tcp/Kconfig" | |||
| source "net/udp/Kconfig" | |||
| source "net/bluetooth/Kconfig" | |||
| source "net/bt/Kconfig" | |||
There was a problem hiding this comment.
but what's relationship with the original bluetooth stack? it isn't good to contain two Bluetooth stacks with the incompatible public API in the kernel space.
There was a problem hiding this comment.
The original protocol stack will be removed once we have implemented support in both the kernel and user space.
There was a problem hiding this comment.
so please finish your work in your internal git and do test before submitting the partial code to community.
There was a problem hiding this comment.
This doesn't conflict with the existing Bluetooth subsystem at all — the new stack lives under net/bt/ and is guarded by its own CONFIG_BT Kconfig option, completely independent from the legacy stack. The two can coexist and be developed in parallel.
Submitting to the community early has several benefits:
- Parallel development: The community can start testing, reviewing, and contributing fixes while we continue working on phase 2 (userspace/kernel space split). There's no need to block the initial framework on downstream work.
- Earlier feedback: The Bluetooth stack is a large piece of work — 600+ files. Getting it into the tree sooner means more eyes on the code, earlier bug discovery, and broader testing across different hardware platforms.
- Lower upstream maintenance burden: Keeping a large patch set in an internal fork and rebasing against master is painful and error-prone. Every day it stays out of tree, the merge conflict surface grows.
Asking us to fully finish phase 2 and 3 in isolation before submitting phase 1 would actually slow down the overall effort and delay the community from benefiting from a working Bluetooth stack. This is a baseline submission that gives everyone a foundation to build on — not the final product.
At this stage, the entire Bluetooth stack currently only supports flat build. Protected build and kernel build support are planned for Phase 2. Our thinking for Phase 1 is to get the full stack running with complete feature support first. I've also added flat build as a dependency under the CONFIG_BT configuration option. Once this is in place, we'll move the upper-layer profile code entirely Why flat build first?There are several benefits to this approach:
Migration PlanThe overall migration is broken down into several phases: Phase 1 (current)Submit the full-featured Bluetooth stack to the mainline so everyone can collaborate on stabilizing it together. Phase 2Provide both userspace and kernel space support: • Bluetooth profile code will move to libc. Phase 3Once the new stack fully supports NuttX's Bluetooth capabilities:
Why not do everything in one commit?A Bluetooth protocol stack is an extremely complex piece of work. It involves different profiles, different L2CAP data link layers (e.g., LE Audio and SCO), each of which may require different implementation approaches within the kernel. Supporting My initial implementation is focused on getting the full-featured stack running on NuttX with minimal resource consumption. We'll continue to invest in stabilizing and improving the framework and architecture over subsequent iterations. |
github-actions
Bot
added
Area: Bluetooth
Arch: simulator
|
As AI’s code generation capability improves, ensuring code quality becomes ever more important. Before the code finish:
I reject to merge this pr. Anyway, you can send email to dev@ and ask other people opinion. |
+1 |
|
I have concerns on the code quality and compliance Please split the contribution to small chunks which can be reviewed and discussed |
My recommendation is to keep the protocol stack implementation in the kernel, and use libc to provide the userspace isolation layer for protected/kernel build modes. This way:
This approach gives us the best of both worlds — performance when we need it (flat build), and isolation when we need it (protected/kernel build) — without the drastic rewrite of moving everything to userspace. I'd suggest everyone take another look at NuttX's current Bluetooth capabilities. The reality is that many companies are choosing not to adopt NuttX precisely because of the lack of a mature Bluetooth stack. A fully functional Bluetooth host stack is no longer optional — it's a baseline requirement for most IoT products today (BLE, LE Audio, mesh, etc.). Adding a proper Bluetooth stack to the kernel is a positive step for promoting NuttX adoption. It unlocks a whole category of use cases that are currently simply not possible, and makes NuttX a viable option for a much broader range of devices. This is good for the entire ecosystem. @jerpelea @acassis @xiaoxiang781216 |
ef6e918 to
c0d36c3
Compare
Hi @anchao I think we need to evolve the NuttX BLE and although the initial BLE stack used on NuttX is the same used on Zephyr that came from Intel, I don't know if we should use the code from Zephyr. Or is it a rewrite from scratch? I think for the size of this PR and the importance of this subject, I suggest it should be better if you send first an email to the mailing list explaining your proposal/approach. I think if we use code from Zephyr, the same CVEs which affect them will affect us. And it will prevent the diversity protection (when a company uses multiple RTOSs to avoid an single hacking put down all theirs devices). |
I agree that this is an important topic and probably deserves broader discussion on the mailing list before we decide the long-term direction. I can prepare a proposal email to explain the motivation, scope, current limitation, and the To clarify the approach: this is not a rewrite from scratch. The current PR is a port/adaptation of the Zephyr Bluetooth host stack into NuttX, with a NuttX compatibility layer for kernel primitives, work queues, timeout handling, logging, settings, net_buf, iterable sections, and build integration. The reason I took this approach is that the Bluetooth stack has evolved far beyond a basic BLE host. Today, a practical Bluetooth host needs to cover much more than GAP/GATT/ATT/SMP:
Rebuilding all of this on top of the original NuttX BLE implementation would be a very large multi-year effort. Even if we start from the existing NuttX BLE code, we would still need to implement and maintain a large amount of profile About the CVE concern: I think this is a valid point. If we import or derive code from Zephyr, some vulnerabilities may also apply to the NuttX port. But I think there are also trade-offs:
So I think the main question is the trade-off between:
For the current PR, I also want to make the limitation explicit:
|
c0d36c3 to
6d6ddbb
Compare
|
6d6ddbb to
b519d24
Compare
f5e37bd to
e8ede6c
Compare
aa6012c to
38d14a0
Compare
Thank you @anchao But using CONFIG_BT will make it impossible to change the current NuttX BLE stack name in the future. Also associating CONFIG_BT to only ZBLUE will pass an impression we don't have option to use other BT stack. Unless you find a way to dissociate CONFIG_BT from this ZBLUE implementation and make CONFIG_BT generic as a requirement for CONFIG_WIRELESS_BLUETOOTH and CONFIG_NIMBLE |
|
Regarding
Note that
|
@anchao as I said before the zblue should be an option not the default. Using the fact that nobody worked on BLE on NuttX until now doesn't mean item 3 is true, as I said I started working on it. I think it is fine to keep the convection/API used on Zephyr (bt_*), but CONFIG_BT should be like a CONFIG_NET. And CONFIG_NIBLE, CONFIG_ZBLUE or CONFIG_WIRELESS_BLUETOOTH (or CONFIG_NXBLE/NXBT/BTBLUE whatever we rename it) should be selected as the stack. Please use this opportunity to make the BLUETOOTH selection on NuttX more simple and intuitive. Assuming ZBLUE as the default and main option is not safe, some people will prefer other option (as @raiden00pl commented) |
|
I appreciate the detailed feedback, and I understand the concern about not assuming zblue as the sole option. Let me share my perspective on why I think keeping
There's no ambiguity for users — each stack has a clearly identifiable entry point. Adding a
|
|
By the way, there's an interesting comparison worth noting. Not long ago, someone proposed integrating lwIP as an auxiliary TCP/IP stack in NuttX (PR #20159 #20159 / #20160). It was ultimately rejected, and rightfully so — NuttX's native TCP/IP stack is already mature and performant; when tuned properly, it matches or exceeds lwIP. In that case, enhancing the native solution is clearly the right choice over importing a third-party one. Bluetooth on NuttX is the mirror image of this situation. The native BT capability has been so lacking that the community has repeatedly resorted to third-party imports like NimBLE just to fill the gap. For an RTOS to depend on fragmented third-party solutions for something as fundamental as Bluetooth is, frankly, not a healthy state. zblue is an attempt to fix exactly this — to provide a single, comprehensive, well-maintained Bluetooth stack that can eventually replace both the legacy |
|
@acassis on the naming question, I'd like to make one more case. I've been deeply involved in the development of most of NuttX's core kernel, driver subsystems, and network stack over the years, so I believe I have solid technical judgment on this. I've put a lot of thought into the current naming and architecture, and I remain strongly convinced that CONFIG_BT as proposed is the right approach here. |
|
@anchao I think enhancing the native stack is always the best option, because we got an implementation that is not the same code from a foreign project and are not affected by the same vulnerabilities. Just to prove my point, from 2019 until now were 73 vulnerabilities found on ZBlue: 21 only this year! You can think: good these are vulnerabilities that were fixed and we will not be affected. The problem is the year didn't finish, they will discover a lot more before the end of the year, and many more in the coming years. And since Zephyr is becoming used in more products from different vendors (like Windows) it mean any product with NuttX will be affected as well. Perhaps ZBlue could be a great stack (if you think so), but it still a big surface area from a foreign code injected on NuttX in the most critical part of NuttX (kernel), it means any vulnerability found on that stack will put a NuttX product in risk. This is why I suggested to add a Kconfig "Bluetooth Support" and inside it add: I think we need to hear more from other developers, seems like only you and I are interested on it. |
|
Thanks for sharing your concerns. I understand your point about the security surface and the risk of importing code from another project. However, I think we also need to look at the current state of the native NuttX Bluetooth stack realistically. Today it is still at a very early stage and does not yet provide a complete BLE host stack. As far as I know, there is currently no real product or project using the native NuttX Bluetooth stack as a complete BLE solution. That makes it very difficult to use it directly for product work today. For commercial products, rewriting and validating a full Bluetooth host stack from scratch is usually not a realistic option. The protocol surface is large, the qualification and interoperability cost is high, and it takes a long time to reach a production-ready level. In practice, companies usually either buy a commercial stack or base their work on an existing mature open-source stack. This is also one of the reasons why ZBlue is useful here. Before moving to an open-source solution, some vendors had to rely on expensive commercial Bluetooth stacks. Now that openvela/NuttX needs an open stack that can continue to evolve in the open, starting from ZBlue gives us a practical path forward instead of starting from zero. I agree that security is a very important concern. But I think the CVE list can also be viewed from another angle: Zephyr Bluetooth is widely used, heavily tested, and actively analyzed by security researchers. Vulnerabilities are found because the stack is used and reviewed in many real products. If we maintain the NuttX port actively and keep tracking upstream fixes, we can benefit from that ecosystem instead of carrying an untested private implementation. If the concern is that users may misunderstand the maturity or security status, I am fine with making that clearer in the Kconfig/help text and documentation. For example, we can explicitly state that ZBlue is an optional Bluetooth host stack derived from Zephyr, that users should track security updates, and that it is not meant to imply that the native NuttX Bluetooth stack is being removed. I also agree with your suggestion that the Kconfig structure should make the choice explicit. Having something like this makes sense to me: My only concern is that we should not block ZBlue just because the native stack is not yet complete. I see these as complementary options:
If this stack can be merged, my team is willing to help maintain it in NuttX. That includes tracking upstream security fixes, fixing integration issues, improving performance/resource usage, and handling compatibility problems. So I do not think this has to become an unmaintained foreign code dump. I agree that we should hear more opinions from other developers and maintainers. My main point is that adding ZBlue as an explicit optional stack gives NuttX users a practical Bluetooth solution today, while still leaving room for the native stack to continue improving. |
@anchao I agree 100% with everything you said, my only concern is assuming CONFIG_BT is ZBLUE you are removing the chance to let the NuttX native Bluetooth stack to become the default CONFIG_BT in the future. This is why I suggested using CONFIG_ZBLUE, just like we have CONFIG_NINBLE. |
I understand your concern, but I would like to clarify one point. If this were only about renaming directories, moving files, or changing the What I am trying to avoid is exposing the implementation identity in the public In my view, CONFIG_BT should mean "Bluetooth support", not necessarily "this is At this stage, CONFIG_BT does not conflict with the existing native NuttX So I do not see CONFIG_BT as taking away the future of the native stack. Instead, Maybe we can also ask projects that are currently using NimBLE(cc @raiden00pl ): if NuttX |
@anchao but NuttX Kconfig is not 1:1 to Linux or Zephyr (it shouldn't be). So I think CONFIG_BT should mean BT/BLE supoort and then we have the stack used: CONFIG_BT_NIMBLE, CONFIG_BT_ZBLUE, etc. Does it makes more sense? If we used CONFIG_BT to compile the ZBLUE stack only, it will be difficult to repurpose it to other stack later. So I think separating CONFIG_BT from the used stack makes more sense. |
Yes, I understand your point, and I agree that NuttX Kconfig does not have to be At this stage, many of the Bluetooth Kconfig options are inherited from Zephyr, So my view is that this is more like forking the current Bluetooth host stack The main reason I would still like to keep the CONFIG_BT_* naming is that the If CONFIG_BT is merged as the common Bluetooth host entry in NuttX, my For NimBLE, if there are active users or maintainers who still need it, we can So I agree with the idea that CONFIG_BT should mean Bluetooth support in NuttX. |
I think that is our main point of divergence: I think ZBlue should be an option to allow others BT/BLE stack be used in the future, you think that ZBlue should become the NuttX default BT/BLE stack. If you use CONFIG_BT_ZBLUE_HCI/L2CAP/GATT, etc, everybody will understand what it means, but selecting CONFIG_BT_HCI/etc to ZBLUE means we are giving it higher privilege (I think NimBLE and other should have the same opportunity to evolve). NimBLE for instance is actively maintained and was certified on Espressif chips: https://www.espressif.com/en/news/BLE_5.0_Certification So, my point is: I am fine to let ZBlue in, but I'm not fine to let it to become the standard/official NuttX BT/BLE stack. |
@acassis I think we've reached an impasse here. I'm unable to convince you, and I'm not willing to restructure the Kconfig naming in the way you're asking for. So I'm going to withdraw this PR for now. Thanks for the discussion. |
|
Ugh :-( I hoped this zblue stuff will land in NuttX, because it would be verified, tested, and supported solution.. from other RTOS but well NuttX could also benefit here! Regarding the zblue security there are many CVEs yes, that means the code it tested, maintained, and fixed, and probably it will have less issues in future. Our own implementation will also have bugs. More people see the code more people test code more bugs are discovered and then fixed. Because that could be standalone and independent solution users could select alternative implementations (i.e. NXBT, Nimble, ZBlue). I agree here. I know it's a hard situation, this impasse, I been there several times, but it can be fixed. I know a lot of work have been done already by Anchao and some of this needs a rework again. But this is very very important area and the implementation needs to be tip-top right from start so I would listen to the hints from the maintainers during code review. |
|
I think there are 3 technical details worth considering again. First, in ESP-IDF, Bluedroid and NimBLE are mutually exclusive host stack choices. That means users who need Classic Bluetooth have to select Bluedroid, and then they cannot use NimBLE at the same time for BLE-only features. This also means that features such as LE Mesh or LE Audio cannot naturally be combined with the Classic Bluetooth stack if they are only available from a different host stack. This is one important difference from the ZBlue direction. ZBlue provides a single host stack architecture that can cover Classic, BLE, Mesh, LE Audio, and other Bluetooth features under one Bluetooth host implementation. So from a long-term architecture point of view, I think it is not exactly the same problem as choosing between Bluedroid and NimBLE in ESP-IDF. Second, regarding the Kconfig naming, if we use ESP-IDF as a reference, I think we should also notice that its naming is not strictly stack-prefixed everywhere. For example, once Bluedroid is selected, many Classic/BLE feature options still use generic So even ESP-IDF does not consistently use That is why I still think exposing ZBlue in every Bluetooth feature Kconfig name is not necessarily the right direction. It makes the configuration look more implementation-specific than the feature itself, and I think this will be harder for Bluetooth developers to understand and maintain in the long term. Third, this naming inconsistency is even more visible in the Bluetooth controller part. ESP-IDF's BLE controller feature set is actually very similar to Zephyr's Bluetooth controller in terms of BLE 5 features, extended advertising, periodic advertising/sync, 2M PHY, and coded PHY support. However, unlike Zephyr, which uses a consistent and unified Some examples are: In Zephyr, similar controller capabilities are organized under one coherent controller namespace, for example: So if ESP-IDF is used as the reference model, I think we should also recognize that its Bluetooth configuration is not a clean, unified design. It looks more like several historical parts stitched together with different naming conventions. Is this kind of fragmented Bluetooth organization really the direction we want to carry forward in NuttX, instead of keeping a coherent Bluetooth configuration model? |
Good point, I think if we have a similar CONFIG_ZBLUE_ENABLED, CONFIG_NIMBLE_ENABLED, etc, we could keep the generic CONFIG_BT_* in place and reuse it between stacks. If you decide to modify to follow this approach I am fine with it. |
@acassis Thanks, I think this is a good compromise. I updated the PR to add an explicit At the same time, I kept the existing Bluetooth feature options under the So the configuration model is now:
Thanks for the suggestion. I think this keeps the stack selection explicit while |
38d14a0 to
f500b39
Compare
f500b39 to
6a55baa
Compare
| @@ -0,0 +1,40 @@ | |||
| # ############################################################################## | |||
| # libs/zblue/CMakeLists.txt | |||
There was a problem hiding this comment.
I still prefer zblue belong nuttx-apps.git, @raiden00pl what's your opinion?
There was a problem hiding this comment.
I won’t comment on where the Bluetooth code should be placed, but I notice this PR consists entirely of code—where are the tests? Since we already have the BSWorld simulation testing system, and it’s now supported in the default CI pipeline, we really should add corresponding Bluetooth tests for this PR. Otherwise, how can we ensure the stability of such an extensive set of fixes? Although BR/EDR is not yet supported, the vast majority of LE (Low Energy) functionality can certainly be tested.
6a55baa to
bc3479e
Compare
Add a native NuttX Bluetooth host stack under libs/zblue together with the public Bluetooth header namespace, net_buf memory support, and build integration. The stack provides a complete host-side foundation that can be built inside NuttX without requiring an external RTOS runtime, while keeping the controller interface separated through the HCI transport and driver abstraction layers. The implementation is organized by protocol layer and upper profile coverage: - Core Host: - Bluetooth address handling - identity management - HCI command and event processing - buffer ownership and monitor support - settings storage and key management - SMP pairing support - GATT database handling - ATT request processing - L2CAP channels - ISO channels - advertising and scanning - connection management - direction finding and channel sounding - common data helpers These pieces provide both the internal protocol machinery and the public APIs needed by applications, services, and profiles. - Classic BR/EDR: - inquiry and connection management - BR/EDR L2CAP - RFCOMM - SDP - SCO plumbing - secure simple pairing - A2DP - AVRCP and AVRCP cover art - GOEP and OBEX - BIP - PBAP - MAP - HFP Audio Gateway - HFP Hands-Free - HID Device and HID Host - Bluetooth Mesh: - provisioning and bearer handling - network, transport, and access layers - subnet and key management - replay protection - beacons - friend and low-power-node behavior - GATT proxy and proxy client/server - heartbeat - configuration client/server - health client/server - model message helpers - settings persistence - BLOB transfer - firmware update and distribution - remote provisioning - large composition data - directed forwarding - bridge configuration - on-demand private proxy - opcode aggregation - private beacon - SAR configuration - solicitation PDU RPL - statistics - related client and server models - LE Audio: - BAP unicast client/server - BAP broadcast source/sink - scan delegator and broadcast assistant - PACS and ASCS - CAP acceptor, initiator, and commander - AICS - VCP and VOCS - MICP - CSIP - TBS - MCS and MCC - media proxy - HAS - TMAS and TMAP - GMAP - PBP - CCID and CCP - codec helpers - LC3 preset definitions - endpoint and stream management These components provide the public headers and implementation structure needed for both unicast and broadcast audio roles as well as coordinated and content-control audio use cases. - GATT Services: - GAP - BAS - DIS - TPS - HRS - CTS - ETS - IAS - ANS - NUS - OTS - service configuration and callbacks - object transfer support - Nordic UART service instances - immediate alert client/server helpers - battery service variants - Common Support: - crypto helpers - EAD - SBC codec support - host utility code - NuttX-backed kernel object wrappers - work queues and timeout helpers - atomics - settings and logging support - device stubs - iterable sections - HCI driver registration - path-derived public header guards Keep the compatibility surface local to the Bluetooth subsystem and expose public APIs through the NuttX include tree. - Build and Configuration: - standalone libs/zblue Make build integration - CMake build integration - Kconfig coverage for the core host - Kconfig coverage for Classic, Mesh, services, and LE Audio - Kconfig coverage for crypto, common library, and net_buf support - private include paths for internal compatibility headers The build integration keeps Bluetooth implementation details from leaking into unrelated NuttX targets. Note: The current Bluetooth host stack supports only flat builds. Protected and kernel builds are not supported yet. Signed-off-by: chao an <anchao.archer@bytedance.com>
bc3479e to
47ab26d
Compare
Summary
This PR adds a native NuttX Bluetooth host stack under
net/bt, together withthe public Bluetooth header namespace,
net_bufmemory support, buildintegration, and a broad
sim:btcoverage configuration.The stack is ported from Zephyr Bluetooth host components and adapted to run
inside NuttX without requiring an external RTOS runtime. It keeps the controller
interface separated through the HCI transport and driver abstraction layers,
while exposing Bluetooth APIs through the NuttX public include tree.
This provides the foundation for BLE, BR/EDR Classic, Bluetooth Mesh, LE Audio,
GATT services, and profile-level shell/demo coverage in NuttX.
What is included
Core Bluetooth Host
This PR adds the core host-side Bluetooth protocol machinery, including:
These pieces provide both the internal host stack logic and the public APIs
needed by applications, services, profiles, and shell commands.
Classic BR/EDR Support
The PR adds Classic Bluetooth support, including:
Classic shell commands expose profile-level test and operation flows so these
features can be compiled and exercised from the NuttX shell environment.
Bluetooth Mesh Support
This PR adds Bluetooth Mesh host support, including:
LE Audio Support
The PR adds LE Audio infrastructure and profiles, including:
These components provide the public headers and implementation structure needed
for both unicast and broadcast audio roles, as well as coordinated and
content-control audio use cases.
GATT Services
This PR adds GATT service support and service implementations, including:
The
sim:btconfiguration enables common services such as BAS, DIS, TPS, andNUS so that GATT server behavior can be exercised from the simulator build.
Common Support and Compatibility Layer
This PR adds the compatibility and support infrastructure required by the host
stack, including:
net_bufandnet_buf_simplememory supportThe compatibility surface is kept local to the Bluetooth subsystem, while public
Bluetooth APIs are exposed through the NuttX include namespace.
Build and Configuration
This PR adds build-system integration for the Bluetooth stack:
net_bufsupportsim:btdefconfig for broad compile coverageThe build integration keeps Bluetooth implementation details contained within
the Bluetooth subsystem and avoids leaking internal compatibility headers into
unrelated NuttX targets.
Runtime/demo coverage
The
sim:btconfiguration includes demo-oriented behavior for exercising thestack in the simulator, including:
The runtime logs are intentionally kept in the NUS demo application layer rather
than being added to the protocol stack internals.
Current limitation
The current Bluetooth host stack supports only flat builds and therefore
CONFIG_BT depends on BUILD_FLAT.
Protected builds and kernel builds are not supported in this initial version.
Support for protected and kernel build modes is planned for 27Q2. As part of
that work, the related Bluetooth profiles will be added to the libc build where
needed so they can work correctly across NuttX protected/kernel build
boundaries.
Impact
N/A
Testing
The current test and validation coverage is limited to the simulator platform.
A simulator-based Bluetooth test framework has been completed and is used to
exercise both Classic Bluetooth and BLE paths. The
sim:btconfigurationprovides broad build coverage for the host stack, services, profiles, and demo
integration.
Validated coverage includes:
Build validation was performed with the simulator Bluetooth configuration:
Makefile:
CMake:
A2DP connection: