NetHubArchitecture:修订间差异

来自Bouffalo Lab Docs
跳转到导航 跳转到搜索
张良留言 | 贡献
Sync NetHub docs from local Markdown
张良留言 | 贡献
Reduce overlap between NetHubArchitecture and NetHubVirtualChannel (2026-04-25)
 
(未显示同一用户的4个中间版本)
第1行: 第1行:
= NetHub Architecture Guide =
= NetHub Architecture =


This document is for developers who need to understand module boundaries and APIs.
This document summarizes the current NetHub architecture across the device-side module, the optional host control stack, and the current support boundaries.


== 1. Current Architecture Conclusions ==
== 1. High-Level Model ==


* The current physical primary path is <code>SDIO</code>
NetHub runs on the device and bridges already-available Wi-Fi capability onto one selected host interface.
* <code>USB / SPI</code> still keep backend skeletons and are not recommended bring-up paths for now
* The device-side Wi-Fi backend supports <code>fhost / wl80211</code>
* The control channel and <code>USER virtual channel</code> are logical channels on the current host link, not separate physical interfaces
* The host control backend is selected at runtime: <code>tty</code> or <code>vchan</code>


== 2. Functional Architecture Diagram ==
[[文件:Nethub_arch.gif | NetHub Architecture Overview]]


<pre>
<syntaxhighlight lang="text">
flowchart LR
Wi-Fi backend + lwIP
    Host["Host"]
      |
    Link["Host Link
      v
current main path: SDIO"]
    nethub
     Data["Data Channel"]
  +-----------+
    Ctrl["Control Channel"]
  | data-path |
    User["USER VCHAN"]
  | filter    |
  | ctrlpath  |
  | vchan     |
  +-----------+
      |
      v
host interface
(SDIO / USB / SPI)
</syntaxhighlight>


    subgraph Device["Device"]
Important boundary:
        subgraph Hub["nethub"]
            Bridge["data bridge"]
            Filter["hard-coded Wi-Fi RX filter"]
            Active["active Wi-Fi selector
STA / AP"]
            CtrlPath["ctrlpath"]
            Vchan["virtual channel"]
        end
        Wifi["Wi-Fi backend
fhost / wl80211 + lwIP"]
        AT["ATModule"]
    end


    Host --> Link
* <code>nethub</code> core does not directly depend on <code>ATModule</code>
    Link --> Data
* <code>ATModule</code> is an optional example consumer of the NetHub control path
    Link --> Ctrl
    Link --> User


    Data --> Bridge
== 2. Current Support Matrix ==
    Bridge --> Active
    Active --> Wifi
    Wifi --> Filter
    Filter --> Bridge


    Ctrl --> CtrlPath
{| class="wikitable"
    CtrlPath --> AT
|-
    AT --> Wifi
! Area !! SDIO !! USB !! SPI
|-
| Device-side interface backend || yes || yes || yes
|-
| Device-side data-path || yes || yes, through <code>USB ECM</code> || no
|-
| Device-side control transport plumbing || yes || yes, through <code>USB ACM</code> || 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
|}


    User --> Vchan
== 3. Device-Side Layers ==
</pre>


From a functional view, <code>nethub</code> mainly does four things:
Public headers:


* maintain the <code>Wi-Fi &lt;-&gt; HostLink</code> data bridge
* <code>components/net/nethub/include/nethub.h</code>
* use a hard-coded filter to decide whether a packet is <code>local</code>, <code>host</code>, or <code>both</code>
* <code>components/net/nethub/include/nethub_vchan.h</code>
* maintain the currently active Wi-Fi channel, <code>STA / AP</code>
* <code>components/net/nethub/include/nethub_filter.h</code>
* provide a control channel and an optional <code>USER virtual channel</code> on the same host link


== 3. Technical / API Architecture Diagram ==
Internal layers:


<pre>
* <code>bootstrap/</code>
flowchart TB
* <code>core/</code>
    App["Application"]
* <code>profile/</code>
* <code>backend/wifi/</code>
* <code>backend/host/sdio/</code>
* <code>backend/host/usb/</code>
* <code>backend/host/spi/</code>


    subgraph DevicePublic["device public API"]
Main public APIs:
        DevAPI["nethub.h"]
        DevVchan["nethub_vchan.h"]
        DevFilter["nethub_filter.h"]
    end


    subgraph DeviceSide["device side"]
* <code>nethub_bootstrap()</code>
        Bootstrap["nethub_bootstrap()"]
* <code>nethub_shutdown()</code>
        Profile["profile select"]
* <code>nethub_get_status()</code>
        Endpoint["endpoint register"]
* <code>nethub_set_active_wifi_channel()</code>
        Hub["hub lifecycle"]
* <code>nethub_ctrl_upld_send()</code>
        WifiBridge["Wi-Fi bridge"]
* <code>nethub_ctrl_dnld_register()</code>
        HostBackend["host backend
* <code>nethub_vchan_user_send()</code>
current main path: sdio"]
* <code>nethub_vchan_user_recv_register()</code>
    end
* <code>nethub_set_wifi_rx_filter()</code>


    subgraph HostPublic["host public API"]
== 4. Data-Path ==
        HostAPI["bflbwifi.h"]
        HostVchan["virtualchan/nethub_vchan.h"]
    end


    subgraph HostSide["host side"]
The data-path is the main NetHub function.
        CLI["bflbwifictrl"]
        IPC["local IPC"]
        Daemon["bflbwifid"]
        Lib["libbflbwifi"]
        Facade["channel facade"]
        TTY["tty backend"]
        VCHAN["vchan backend"]
        Kernel["mr_sdio.ko + msg_router"]
    end


    App --> DevAPI
<syntaxhighlight lang="text">
    App --> DevVchan
host payload -> host interface backend -> nethub -> active Wi-Fi endpoint
     App --> DevFilter
Wi-Fi RX     -> nethub filter     -> local / host / both
     App --> HostAPI
</syntaxhighlight>
    App --> HostVchan


    DevAPI --> Bootstrap
Device-side Wi-Fi is already owned by the Wi-Fi backend. NetHub mainly wires the selected host interface to that Wi-Fi backend.
    DevVchan --> HostBackend
    DevFilter --> WifiBridge
    Bootstrap --> Profile
    Bootstrap --> Endpoint
    Bootstrap --> Hub
    Hub --> WifiBridge
    Endpoint --> HostBackend


    CLI --> IPC
== 5. Control Path ==
    IPC --> Daemon
    Daemon --> Lib
    Lib --> Facade
    Facade --> TTY
    Facade --> VCHAN
    TTY --> Kernel
    VCHAN --> Kernel
    HostVchan --> Kernel
</pre>


== 4. device-side Public Interfaces ==
NetHub exposes a stable control path facade:


Headers:
<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>


* <code>components/net/nethub/include/nethub.h</code>
That facade is implemented per interface.
* <code>components/net/nethub/include/nethub_vchan.h</code>
 
* <code>components/net/nethub/include/nethub_filter.h</code>
Current interpretation:
 
* <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>CONFIG_NETHUB_CTRLCHANNEL_USE_ATMODULE=y</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


Core APIs:
<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>nethub_bootstrap()</code>
== 6. Virtual Channel ==
* <code>nethub_shutdown()</code>
* <code>nethub_get_status()</code>
* <code>nethub_set_active_wifi_channel()</code>
* <code>nethub_ctrl_upld_send()</code>
* <code>nethub_ctrl_dnld_register()</code>
* <code>nethub_vchan_user_send()</code>
* <code>nethub_vchan_user_recv_register()</code>
* <code>nethub_set_wifi_rx_filter()</code>


Boundary notes:
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_ctrl_*</code> maps to the logical control channel on the host link
Architecture role:
* <code>nethub_vchan_user_*</code> maps to the logical <code>USER</code> channel on the host link
* <code>nethub_set_wifi_rx_filter()</code> fully replaces the built-in Wi-Fi RX filter and must be called before <code>nethub_bootstrap()</code>


== 5. host-side Public Interfaces ==
* device side uses <code>components/net/nethub/include/nethub_vchan.h</code>
* host side uses <code>bsp/common/msg_router/linux_host/userspace/nethub/virtualchan/nethub_vchan.h</code>
* the API is intentionally transport-neutral across host interfaces


Headers:
Current implementation boundary:


* <code>bsp/common/msg_router/linux_host/userspace/nethub/bflbwifictrl/include/bflbwifi.h</code>
* the current in-tree end-to-end USER virtual channel path follows the default <code>SDIO</code> interface
* <code>bsp/common/msg_router/linux_host/userspace/nethub/virtualchan/nethub_vchan.h</code>
* 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


Control-plane capabilities:
For prerequisites, detailed APIs, usage order, and limits, read [[NetHubVirtualChannel|NetHubVirtualChannel.md]].


* <code>bflbwifi_ctrl_config_init()</code>
== 7. Host-Side Optional Stack ==
* <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 capabilities:
When the optional AT control solution is used, the typical host-side stack is:


* <code>nethub_vchan_init()</code>
<syntaxhighlight lang="text">
* <code>nethub_vchan_deinit()</code>
bflbwifictrl -> bflbwifid -> libbflbwifi -> tty or vchan backend
* <code>nethub_vchan_user_send()</code>
</syntaxhighlight>
* <code>nethub_vchan_user_register_callback()</code>
* <code>nethub_vchan_get_state_snapshot()</code>
* <code>nethub_vchan_register_link_event_callback()</code>


== 6. Key Data Flows ==
Notes:


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


# The user runs <code>bflbwifictrl connect_ap &lt;ssid&gt; &lt;password&gt;</code>
== 8. Low-Power Scope ==
# The CLI sends the command to <code>bflbwifid</code> through local IPC
# The daemon calls <code>libbflbwifi</code>
# <code>libbflbwifi</code> sends control messages through the <code>tty</code> or <code>vchan</code> backend
# The device-side <code>ATModule</code> performs the Wi-Fi control operation
# The device reports responses and state updates, and the host refreshes the state and returns the result


=== 6.2 Data Plane ===
Current low-power support is <code>BL618DG</code> only.


# Host network traffic enters <code>mr_eth0</code>
The example configuration automatically disables <code>CONFIG_NETHUB_LOWPOWER_ENABLE</code> on other chips.
# The kernel / <code>msg_router</code> communicates with the device over SDIO
# Device-side <code>nethub</code> forwards host data to the currently active Wi-Fi
# After Wi-Fi RX packets pass through the <code>nethub</code> filter, they are handled locally, forwarded to the host, or both


== 7. Recommended Reading Order ==
== 9. Recommended Reading ==


* First-time bring-up: [[NetHubQuickBringup|NetHubQuickBringup.md]]
* [[NetHub|NetHub.md]]
* Understanding the <code>USER</code> channel: [[NetHubVirtualChannel|NetHubVirtualChannel.md]]
* [[NetHubQuickBringup|NetHubQuickBringup.md]]
* Top-level entry: [[NetHub|NetHub.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