NetHubArchitecture:修订间差异

来自Bouffalo Lab Docs
跳转到导航 跳转到搜索
张良留言 | 贡献
创建页面,内容为“= NetHub 架构说明 = 本文档面向需要理解模块边界和 API 的开发者。 == 1. 当前架构结论 == * 当前物理主路径是 '''SDIO''' * <code>USB / SPI</code> 目前仍保留 backend 骨架,不作为当前推荐 bringup 路径 * device 侧 Wi-Fi backend 支持 <code>fhost / wl80211</code> * 控制通道和 <code>USER virtual channel</code> 都是当前 host link 上的逻辑通道,不是独立物理接口 * host 控制 backend 运行…”
 
张良留言 | 贡献
Reduce overlap between NetHubArchitecture and NetHubVirtualChannel (2026-04-25)
 
(未显示同一用户的5个中间版本)
第1行: 第1行:
= NetHub 架构说明 =
= NetHub Architecture =


本文档面向需要理解模块边界和 API 的开发者。
This document summarizes the current NetHub architecture across the device-side module, the optional host control stack, and the current support boundaries.


== 1. 当前架构结论 ==
== 1. High-Level Model ==


* 当前物理主路径是 '''SDIO'''
NetHub runs on the device and bridges already-available Wi-Fi capability onto one selected host interface.
* <code>USB / SPI</code> 目前仍保留 backend 骨架,不作为当前推荐 bringup 路径
* device Wi-Fi backend 支持 <code>fhost / wl80211</code>
* 控制通道和 <code>USER virtual channel</code> 都是当前 host link 上的逻辑通道,不是独立物理接口
* host 控制 backend 运行时二选一:<code>tty</code> 或 <code>vchan</code>


== 2. 功能视角架构图 ==
[[文件:Nethub_arch.gif | NetHub Architecture Overview]]


<syntaxhighlight lang="text">
<syntaxhighlight lang="text">
Host
Wi-Fi backend + lwIP
  |
      |
  | network data / control payload / USER payload
      v
  v
    nethub
Host Link (current main path: SDIO)
   +-----------+
  |
   | data-path |
   +-- Data Channel  <--> nethub data bridge
   | filter    |
  +-- Control Channel <-> nethub ctrlpath <-> ATModule
   | ctrlpath  |
   +-- USER VCHAN      <-> nethub vchan user path
   | vchan    |
   |
   +-----------+
   v
      |
Device
      v
   |
host interface
   +-- nethub
(SDIO / USB / SPI)
  |    +-- data bridge
  |    +-- hard-coded Wi-Fi RX filter
  |    +-- active Wi-Fi selector (STA / AP)
  |   +-- ctrlpath
  |    +-- virtual channel
  |
  +-- Wi-Fi backend (fhost / wl80211) + lwIP
</syntaxhighlight>
</syntaxhighlight>


从功能上看,<code>nethub</code> 主要做 4 件事:
Important boundary:


* 维护 <code>Wi-Fi <-> HostLink</code> 的数据桥接
* <code>nethub</code> core does not directly depend on <code>ATModule</code>
* 用硬编码 filter 决定报文是 <code>local</code>、<code>host</code>、还是 <code>both</code>
* <code>ATModule</code> is an optional example consumer of the NetHub control path
* 维护当前生效的 Wi-Fi 通道选择 <code>STA / AP</code>
* 在同一 host link 上提供控制通道和可选的 <code>USER virtual channel</code>


== 3. 技术/API 视角架构图 ==
== 2. Current Support Matrix ==


<syntaxhighlight lang="text">
{| class="wikitable"
Application
|-
  |
! Area !! SDIO !! USB !! SPI
  +-- device public API
|-
  |   +-- nethub.h
| Device-side interface backend || yes || yes || yes
  |   +-- nethub_vchan.h
|-
  |   +-- nethub_filter.h
| Device-side data-path || yes || yes, through <code>USB ECM</code> || no
  |
|-
  +-- host public API
| Device-side control transport plumbing || yes || yes, through <code>USB ACM</code> || no
      +-- bflbwifi.h
|-
      +-- virtualchan/nethub_vchan.h
| Current in-tree host Linux stack || yes || not yet the main host path || no
 
|-
device side
| End-to-end USER virtual channel || yes || not yet aligned in-tree || no
  nethub_bootstrap()
|-
    -> profile select
| Default interface today || yes || no || no
    -> endpoint register
|}
    -> hub lifecycle
    -> Wi-Fi bridge
    -> host backend (current main path: sdio)
 
host side
  bflbwifictrl
    -> IPC
    -> bflbwifid
    -> libbflbwifi
    -> channel facade
      +-- tty backend
      +-- vchan backend
    -> mr_sdio.ko + msg_router
</syntaxhighlight>


== 4. Device 侧公共接口 ==
== 3. Device-Side Layers ==


头文件:
Public headers:


* <code>components/net/nethub/include/nethub.h</code>
* <code>components/net/nethub/include/nethub.h</code>
第85行: 第58行:
* <code>components/net/nethub/include/nethub_filter.h</code>
* <code>components/net/nethub/include/nethub_filter.h</code>


核心 API:
Internal layers:
 
* <code>bootstrap/</code>
* <code>core/</code>
* <code>profile/</code>
* <code>backend/wifi/</code>
* <code>backend/host/sdio/</code>
* <code>backend/host/usb/</code>
* <code>backend/host/spi/</code>
 
Main public APIs:


* <code>nethub_bootstrap()</code>
* <code>nethub_bootstrap()</code>
第97行: 第80行:
* <code>nethub_set_wifi_rx_filter()</code>
* <code>nethub_set_wifi_rx_filter()</code>


边界说明:
== 4. Data-Path ==
 
The data-path is the main NetHub function.
 
<syntaxhighlight lang="text">
host payload -> host interface backend -> nethub -> active Wi-Fi endpoint
Wi-Fi RX    -> nethub filter    -> local / host / both
</syntaxhighlight>
 
Device-side Wi-Fi is already owned by the Wi-Fi backend. NetHub mainly wires the selected host interface to that Wi-Fi backend.
 
== 5. Control Path ==
 
NetHub exposes a stable control path facade:
 
<syntaxhighlight lang="c">
int nethub_ctrl_upld_send(uint8_t *data_buff, uint32_t data_size);
int nethub_ctrl_dnld_register(nethub_ctrl_rx_cb_t dnld_cb, void *cbpri_arg);
</syntaxhighlight>
 
That facade is implemented per interface.


* <code>nethub_ctrl_*</code> 对应 host link 上的逻辑控制通道
Current interpretation:
* <code>nethub_vchan_user_*</code> 对应 host link 上的逻辑 <code>USER</code> 通道
* <code>nethub_set_wifi_rx_filter()</code> 用于完全替换内建 Wi-Fi RX filter,必须在 <code>nethub_bootstrap()</code> 前调用


== 5. Host 侧公共接口 ==
* <code>SDIO</code>: implemented in-tree
* <code>USB</code>: device-side ACM transport plumbing implemented
* <code>SPI</code>: not implemented


头文件:
Main build-time switches related to this area:


* <code>bsp/common/msg_router/linux_host/userspace/nethub/bflbwifictrl/include/bflbwifi.h</code>
* <code>CONFIG_NETHUB_CTRLCHANNEL_USE_ATMODULE=y</code>
* <code>bsp/common/msg_router/linux_host/userspace/nethub/virtualchan/nethub_vchan.h</code>
** the example enables <code>ATModule</code> plus host <code>bflbwifid / bflbwifictrl</code>
* <code>CONFIG_NETHUB_CTRLCHANNEL_USE_ATMODULE=n</code>
** <code>ATModule</code> does not participate in the build


控制面能力:
<code>CONFIG_NETHUB_AT_USE_VCHAN</code> should be documented carefully as an example or legacy SDIO-specific control path convention, not as a finished transport-wide selector.


* <code>bflbwifi_ctrl_config_init()</code>
== 6. Virtual Channel ==
* <code>bflbwifi_ctrl_config_use_tty()</code>
* <code>bflbwifi_ctrl_config_use_vchan()</code>
* <code>bflbwifi_init_ex()</code>
* <code>bflbwifi_get_ctrl_status()</code>
* <code>bflbwifi_sta_connect()</code>
* <code>bflbwifi_sta_disconnect()</code>
* <code>bflbwifi_sta_get_state()</code>
* <code>bflbwifi_scan()</code>
* <code>bflbwifi_get_version()</code>
* <code>bflbwifi_restart()</code>
* <code>bflbwifi_ota_upgrade()</code>
* <code>bflbwifi_ap_start()</code>
* <code>bflbwifi_ap_stop()</code>


USER virtual channel 能力:
NetHub also exposes a logical virtual channel layer for message-style traffic such as <code>USER</code>, <code>AT</code>, and internal coordination payloads.


* <code>nethub_vchan_init()</code>
Architecture role:
* <code>nethub_vchan_deinit()</code>
 
* <code>nethub_vchan_user_send()</code>
* device side uses <code>components/net/nethub/include/nethub_vchan.h</code>
* <code>nethub_vchan_user_register_callback()</code>
* host side uses <code>bsp/common/msg_router/linux_host/userspace/nethub/virtualchan/nethub_vchan.h</code>
* <code>nethub_vchan_get_state_snapshot()</code>
* the API is intentionally transport-neutral across host interfaces
* <code>nethub_vchan_register_link_event_callback()</code>
 
Current implementation boundary:
 
* the current in-tree end-to-end USER virtual channel path follows the default <code>SDIO</code> interface
* the device-side implementation is still centered on the SDIO backend
* the host userspace <code>nethub_vchan</code> library is also SDIO-based today
* USB device-side ACM transport exists, but the host-side wrapper is not yet aligned as a finished end-to-end virtual channel path
 
For prerequisites, detailed APIs, usage order, and limits, read [[NetHubVirtualChannel|NetHubVirtualChannel.md]].
 
== 7. Host-Side Optional Stack ==
 
When the optional AT control solution is used, the typical host-side stack is:
 
<syntaxhighlight lang="text">
bflbwifictrl -> bflbwifid -> libbflbwifi -> tty or vchan backend
</syntaxhighlight>


== 6. 关键数据流 ==
Notes:


=== 6.1 connect_ap ===
* this stack is not mandatory for NetHub data-path-only products
* the in-tree host Linux stack is still centered on the SDIO path


# 用户执行 <code>bflbwifictrl connect_ap &lt;ssid&gt; &lt;password&gt;</code>
== 8. Low-Power Scope ==
# CLI 通过本地 IPC 把命令发给 <code>bflbwifid</code>
# daemon 调用 <code>libbflbwifi</code>
# <code>libbflbwifi</code> 通过 <code>tty</code> 或 <code>vchan</code> backend 下发控制消息
# device 侧 <code>ATModule</code> 执行 Wi-Fi 控制
# device 侧上报响应和状态,host 侧刷新状态并返回结果


=== 6.2 数据面 ===
Current low-power support is <code>BL618DG</code> only.


# host 网络流量进入 <code>mr_eth0</code>
The example configuration automatically disables <code>CONFIG_NETHUB_LOWPOWER_ENABLE</code> on other chips.
# kernel/msg_router 通过 SDIO 与 device 通信
# device 侧 <code>nethub</code> 把 host data 转给当前 active Wi-Fi
# Wi-Fi RX 包经过 <code>nethub</code> filter 判断后,决定是本地处理、发给 host,还是两边都处理


== 7. 推荐阅读顺序 ==
== 9. Recommended Reading ==


* 首次 bringup:[[NetHubQuickBringup|NetHub 快速上手]]
* [[NetHub|NetHub.md]]
* 理解 <code>USER</code> 通道:[[NetHubVirtualChannel|NetHub USER Virtual Channel]]
* [[NetHubQuickBringup|NetHubQuickBringup.md]]
* [[NetHubVirtualChannel|NetHubVirtualChannel.md]]

2026年4月24日 (五) 17:12的最新版本

NetHub Architecture

This document summarizes the current NetHub architecture across the device-side module, the optional host control stack, and the current support boundaries.

1. High-Level Model

NetHub runs on the device and bridges already-available Wi-Fi capability onto one selected host interface.

NetHub Architecture Overview

Wi-Fi backend + lwIP
       |
       v
     nethub
  +-----------+
  | data-path |
  | filter    |
  | ctrlpath  |
  | vchan     |
  +-----------+
       |
       v
host interface
(SDIO / USB / SPI)

Important boundary:

  • nethub core does not directly depend on ATModule
  • ATModule is an optional example consumer of the NetHub control path

2. Current Support Matrix

Area SDIO USB SPI
Device-side interface backend yes yes yes
Device-side data-path yes yes, through USB ECM no
Device-side control transport plumbing yes yes, through USB ACM no
Current in-tree host Linux stack yes not yet the main host path no
End-to-end USER virtual channel yes not yet aligned in-tree no
Default interface today yes no no

3. Device-Side Layers

Public headers:

  • components/net/nethub/include/nethub.h
  • components/net/nethub/include/nethub_vchan.h
  • components/net/nethub/include/nethub_filter.h

Internal layers:

  • bootstrap/
  • core/
  • profile/
  • backend/wifi/
  • backend/host/sdio/
  • backend/host/usb/
  • backend/host/spi/

Main public APIs:

  • nethub_bootstrap()
  • nethub_shutdown()
  • nethub_get_status()
  • nethub_set_active_wifi_channel()
  • nethub_ctrl_upld_send()
  • nethub_ctrl_dnld_register()
  • nethub_vchan_user_send()
  • nethub_vchan_user_recv_register()
  • nethub_set_wifi_rx_filter()

4. Data-Path

The data-path is the main NetHub function.

host payload -> host interface backend -> nethub -> active Wi-Fi endpoint
Wi-Fi RX     -> nethub filter     -> local / host / both

Device-side Wi-Fi is already owned by the Wi-Fi backend. NetHub mainly wires the selected host interface to that Wi-Fi backend.

5. Control Path

NetHub exposes a stable control path facade:

int nethub_ctrl_upld_send(uint8_t *data_buff, uint32_t data_size);
int nethub_ctrl_dnld_register(nethub_ctrl_rx_cb_t dnld_cb, void *cbpri_arg);

That facade is implemented per interface.

Current interpretation:

  • SDIO: implemented in-tree
  • USB: device-side ACM transport plumbing implemented
  • SPI: not implemented

Main build-time switches related to this area:

  • CONFIG_NETHUB_CTRLCHANNEL_USE_ATMODULE=y
    • the example enables ATModule plus host bflbwifid / bflbwifictrl
  • CONFIG_NETHUB_CTRLCHANNEL_USE_ATMODULE=n
    • ATModule does not participate in the build

CONFIG_NETHUB_AT_USE_VCHAN should be documented carefully as an example or legacy SDIO-specific control path convention, not as a finished transport-wide selector.

6. Virtual Channel

NetHub also exposes a logical virtual channel layer for message-style traffic such as USER, AT, and internal coordination payloads.

Architecture role:

  • device side uses components/net/nethub/include/nethub_vchan.h
  • host side uses bsp/common/msg_router/linux_host/userspace/nethub/virtualchan/nethub_vchan.h
  • the API is intentionally transport-neutral across host interfaces

Current implementation boundary:

  • the current in-tree end-to-end USER virtual channel path follows the default SDIO interface
  • the device-side implementation is still centered on the SDIO backend
  • the host userspace nethub_vchan library is also SDIO-based today
  • USB device-side ACM transport exists, but the host-side wrapper is not yet aligned as a finished end-to-end virtual channel path

For prerequisites, detailed APIs, usage order, and limits, read NetHubVirtualChannel.md.

7. Host-Side Optional Stack

When the optional AT control solution is used, the typical host-side stack is:

bflbwifictrl -> bflbwifid -> libbflbwifi -> tty or vchan backend

Notes:

  • this stack is not mandatory for NetHub data-path-only products
  • the in-tree host Linux stack is still centered on the SDIO path

8. Low-Power Scope

Current low-power support is BL618DG only.

The example configuration automatically disables CONFIG_NETHUB_LOWPOWER_ENABLE on other chips.

9. Recommended Reading