Bouffalo Lab Docs - 用户贡献 [zh-cn]

DebuggingBouffaloLabChipsWithGDBForWindows

2026-06-24T05:47:02Z

张良：

= How to debug the DVK light development board via CKLink: =

==== 1. Connect to the PC via USB. ====
GPIO 1 TCK

GPIO 3 TDI

GPIO 2 TDO

GPIO 0 TMS

[[文件:BL616DVK Light CKLinkLite.jpg| 600像素 | BL616DVKLight_CKLinkLite]]

==== 2. Perform GDB debugging. ====

Windows environments are also supported, but the setup is more complicated. We strongly recommend using the Ubuntu development environment.
If you choose to use a Windows environment:

* 2.1 debugserver

Debugserver can be used in a Windows environment. For details, please refer to the compressed package and the following two links:

https://www.xrvm.cn/document?temp=install-t-head-debugserver-and-ice-drivers&slug=t-head-debug-server-user-manual

https://www.xrvm.cn/document?temp=main-interface-menu-toolbar-introduction&slug=t-head-debug-server-user-manual

* 2.2 gdb
For GDB, I recommend installing Ubuntu under WSL.
<code>riscv64-unknown-elf-gdb *.elf</code>

DebuggingBouffaloLabChipsWithGDBForWindows

2026-06-24T05:46:30Z

张良：创建页面，内容为“ = How to debug the DVK light development board via CKLink: = ==== 1. Connect to the PC via USB. ==== GPIO 1 TCK GPIO 3 TDI GPIO 2 TDO GPIO 0 TMS BL616DVKLight_CKLinkLite ==== 2. Perform GDB debugging. ==== Windows environments are also supported, but the setup is more complicated. We strongly recommend using the Ubuntu deve…”

= How to debug the DVK light development board via CKLink: =

==== 1. Connect to the PC via USB. ====
GPIO 1 TCK

GPIO 3 TDI

GPIO 2 TDO

GPIO 0 TMS

[[index.php?title=文件:BL616DVK_Light_CKLinkLite.jpg|链接=文件:BL616DVK_Light_CKLinkLite.jpg|800x800像素| BL616DVKLight_CKLinkLite]]

==== 2. Perform GDB debugging. ====

Windows environments are also supported, but the setup is more complicated. We strongly recommend using the Ubuntu development environment.
If you choose to use a Windows environment:

* 2.1 debugserver

Debugserver can be used in a Windows environment. For details, please refer to the compressed package and the following two links:

https://www.xrvm.cn/document?temp=install-t-head-debugserver-and-ice-drivers&slug=t-head-debug-server-user-manual

https://www.xrvm.cn/document?temp=main-interface-menu-toolbar-introduction&slug=t-head-debug-server-user-manual

* 2.2 gdb
For GDB, I recommend installing Ubuntu under WSL.
<code>riscv64-unknown-elf-gdb *.elf</code>

DebuggingBouffaloLabChipsWithGDB

2026-06-24T01:09:59Z

张良：/* 1. Connect to the PC via USB. */

= How to debug the DVK light development board via CKLink: =

==== 1. Connect to the PC via USB. ====
GPIO 1 TCK

GPIO 3 TDI

GPIO 2 TDO

GPIO 0 TMS

[[文件:BL616DVK Light CKLinkLite.jpg| 600像素 | BL616DVKLight_CKLinkLite]]

==== 2. Perform GDB debugging. ====

Using Ubuntu as an example, run the following two commands separately:<code>DebugServerConsole</code>

<code>riscv64-unknown-elf-gdb *.elf</code>

[[文件:BL616DVKLight_CKLinkLite.gif| BL616DVKLight_CKLinkLite]]

DebuggingBouffaloLabChipsWithGDB

2026-06-24T01:04:31Z

张良：

= How to debug the DVK light development board via CKLink: =

==== 1. Connect to the PC via USB. ====

[[文件:BL616DVK Light CKLinkLite.jpg| 600像素 | BL616DVKLight_CKLinkLite]]

==== 2. Perform GDB debugging. ====

Using Ubuntu as an example, run the following two commands separately:<code>DebugServerConsole</code>

<code>riscv64-unknown-elf-gdb *.elf</code>

[[文件:BL616DVKLight_CKLinkLite.gif| BL616DVKLight_CKLinkLite]]

FlashWholeBin

2026-05-28T08:28:36Z

张良：

1. After pressing '''boot''', press and release '''chip_en''', and the device will enter '''programming mode'''.

2. Open '''BLFlashCube-ubuntu''' ('''BLFlashCube.exe'''), then go to Flash Utils -> Port/SN(/dev/ttyUSB0) -> Flash Program (Browse) -> select lg_demo_20260528.bin -> '''Download'''.

[[文件:Flash_wholebin.gif | Flash_wholebin Overview]]

3. Open the serial port (baud rate '''2M'''), then press '''chip_en'''(reset) to view the log.

FlashWholeBin

2026-05-28T08:25:49Z

张良：

1. After pressing boot, press and release chip_en, and the device will enter programming mode.

2. Open BLFlashCube-ubuntu (BLFlashCube.exe), then go to Flash Utils -> Port/SN(/dev/ttyUSB0) -> Flash Program (Browse) -> select lg_demo_20260528.bin -> Download.

[[文件:Flash_wholebin.gif | Flash_wholebin Overview]]

3. Open the serial port (baud rate 2M), then press rst to view the log.

FlashWholeBin

2026-05-28T08:24:47Z

张良：

1. After pressing boot, press and release chip_en, and the device will enter programming mode.

2. Open BLFlashCube-ubuntu (BLFlashCube.exe), then go to Flash Utils -> Port/SN(/dev/ttyUSB0) -> Flash Program (Browse) -> select lg_demo_20260528.bin -> Download.

[[index.php?title=文件:Flash_wholebin.gif|链接=文件:Flash_wholebin.gif| Flash_wholebin]]

3. Open the serial port (baud rate 2M), then press rst to view the log.

FlashWholeBin

2026-05-28T08:24:01Z

张良：

1. After pressing boot, press and release chip_en, and the device will enter programming mode.

2. Open BLFlashCube-ubuntu (BLFlashCube.exe), then go to Flash Utils -> Port/SN(/dev/ttyUSB0) -> Flash Program (Browse) -> select lg_demo_20260528.bin -> Download.

[[index.php?title=文件:Flash_wholebin.gif|链接=文件:Flash_wholebin.gif| Flash_wholebin]]

3. Open the serial port (baud rate 2M), then press rst to view the log.

文件:Flash wholebin.gif

2026-05-28T08:22:06Z

张良：Flash wholebin

== 摘要 ==
Flash wholebin

FlashWholeBin

2026-05-28T08:19:50Z

张良：创建页面，内容为“ 1. After pressing boot, press and release chip_en, and the device will enter programming mode. 2. Open BLFlashCube-ubuntu (BLFlashCube.exe), then go to Flash Utils -> Port/SN(/dev/ttyUSB0) -> Flash Program (Browse) -> select lg_demo_20260528.bin -> Download. 3. Open the serial port (baud rate 2M), then press rst to view the log.”

1. After pressing boot, press and release chip_en, and the device will enter programming mode.

2. Open BLFlashCube-ubuntu (BLFlashCube.exe), then go to Flash Utils -> Port/SN(/dev/ttyUSB0) -> Flash Program (Browse) -> select lg_demo_20260528.bin -> Download.

3. Open the serial port (baud rate 2M), then press rst to view the log.

文件:Nethub arch.gif

2026-04-24T17:15:00Z

张良：张良上传文件:Nethub arch.gif的新版本

== 摘要 ==
nethub sdio usb interface arch.

NetHubVirtualChannel

2026-04-24T17:13:00Z

张良：Reduce overlap between NetHubArchitecture and NetHubVirtualChannel (2026-04-25)

= NetHub USER Virtual Channel =

This document describes the current NetHub USER virtual channel support.

It focuses on USER virtual channel usage, prerequisites, APIs, and limits. For the full NetHub architecture and the broader interface support matrix, read [[NetHubArchitecture|NetHubArchitecture.md]].

== 1. Concept ==

USER virtual channel is a logical message channel carried on the active host interface.

It is not a separate physical interface. The public API is transport-neutral, while the current in-tree implementation is still centered on the default <code>SDIO</code> interface.

Common logical types:

{| class="wikitable"
|-
! Type !! Meaning
|-
| <code>USER</code> || private customer or application data
|-
| <code>AT</code> || control payloads
|-
| <code>SYSTEM</code> || internal coordination messages
|}

== 2. Current Scope ==

Current implementation summary:

* the public API is transport-neutral by design
* the current in-tree end-to-end USER virtual channel path follows the default <code>SDIO</code> interface
* the device-side implementation is currently in <code>backend/host/sdio/virtualchan.c</code>
* the host userspace library is currently aligned with <code>mr_sdio.ko + netlink</code>
* USB device-side ACM transport exists, but in-tree host <code>nethub_vchan</code> alignment is not finished
* SPI is not supported

== 3. Prerequisites ==

Before using the current in-tree USER virtual channel path, confirm:

* device side is built with <code>CONFIG_NETHUB=y</code>
* device side enables <code>CONFIG_MR_VIRTUALCHAN=y</code>
* the selected bring-up path uses the default <code>SDIO</code> interface
* host side has loaded <code>mr_sdio.ko</code>
* the host-device link is already working

Notes:

* USER and AT are parallel logical channels
* customer private data should stay on the <code>USER</code> type
* documentation should not describe USB and SPI as if they already share a finished end-to-end virtual channel stack

== 4. Device-Side API ==

Header:

* <code>components/net/nethub/include/nethub_vchan.h</code>

Common APIs:

<syntaxhighlight lang="c">
int nethub_vchan_user_send(const void *data, uint16_t len);
int nethub_vchan_user_recv_register(nethub_vchan_recv_cb_t recv_cb, void *cb_arg);
</syntaxhighlight>

== 5. Host-Side API ==

Header:

* <code>bsp/common/msg_router/linux_host/userspace/nethub/virtualchan/nethub_vchan.h</code>

Initialization and cleanup:

<syntaxhighlight lang="c">
int nethub_vchan_init(void);
int nethub_vchan_deinit(void);
</syntaxhighlight>

USER channel:

<syntaxhighlight lang="c">
typedef void (*nethub_vchan_recv_callback_t)(const void *data, size_t len);

int nethub_vchan_user_send(const void *data, size_t len);
int nethub_vchan_user_register_callback(nethub_vchan_recv_callback_t callback);
</syntaxhighlight>

Optional state query:

<syntaxhighlight lang="c">
typedef struct {
nethub_vchan_link_state_t link_state;
nethub_vchan_host_state_t host_state;
} nethub_vchan_state_snapshot_t;

int nethub_vchan_get_state_snapshot(nethub_vchan_state_snapshot_t *snapshot);
</syntaxhighlight>

Optional link event callback:

<syntaxhighlight lang="c">
int nethub_vchan_register_link_event_callback(
nethub_vchan_link_event_callback_t callback,
void *user_data);
</syntaxhighlight>

== 6. Typical Usage Order ==

# <code>nethub_vchan_init()</code>
# <code>nethub_vchan_user_register_callback()</code>
# <code>nethub_vchan_user_send()</code>
# <code>nethub_vchan_deinit()</code> when finished

Example:

<syntaxhighlight lang="c">
#include <stdio.h>
#include <string.h>

#include "nethub_vchan.h"

static void user_rx_cb(const void *data, size_t len)
{
printf("recv USER data: %.*s\n", (int)len, (const char *)data);
}

int main(void)
{
const char *msg = "hello from host";

if (nethub_vchan_init() != 0) {
return -1;
}

nethub_vchan_user_register_callback(user_rx_cb);
nethub_vchan_user_send(msg, strlen(msg));

nethub_vchan_deinit();
return 0;
}
</syntaxhighlight>

== 7. Limits and Notes ==

* maximum payload length per message is <code>1500</code> bytes
* USER virtual channel is packet-oriented, not a byte stream
* the current in-tree end-to-end path is SDIO-based
* if the device side does not enable <code>CONFIG_MR_VIRTUALCHAN</code>, the current in-tree USER virtual channel path will not work
* if control traffic and USER traffic coexist, keep private application traffic on <code>USER</code> and do not reuse the <code>AT</code> type

== 8. Related Pages ==

* [[NetHub|NetHub.md]]
* [[NetHubQuickBringup|NetHubQuickBringup.md]]
* [[NetHubArchitecture|NetHubArchitecture.md]]

NetHubArchitecture

2026-04-24T17:12:58Z

张良：Reduce overlap between NetHubArchitecture and NetHubVirtualChannel (2026-04-25)

= 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_arch.gif | NetHub Architecture Overview]]

<syntaxhighlight lang="text">
Wi-Fi backend + lwIP
|
v
nethub
+-----------+
| data-path |
| filter |
| ctrlpath |
| vchan |
+-----------+
|
v
host interface
(SDIO / USB / SPI)
</syntaxhighlight>

Important boundary:

* <code>nethub</code> core does not directly depend on <code>ATModule</code>
* <code>ATModule</code> is an optional example consumer of the NetHub control path

== 2. Current Support Matrix ==

{| class="wikitable"
|-
! 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
|}

== 3. Device-Side Layers ==

Public headers:

* <code>components/net/nethub/include/nethub.h</code>
* <code>components/net/nethub/include/nethub_vchan.h</code>
* <code>components/net/nethub/include/nethub_filter.h</code>

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_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>

== 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.

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

<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.

== 6. 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.

Architecture role:

* 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

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>

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 <code>BL618DG</code> only.

The example configuration automatically disables <code>CONFIG_NETHUB_LOWPOWER_ENABLE</code> on other chips.

== 9. Recommended Reading ==

* [[NetHub|NetHub.md]]
* [[NetHubQuickBringup|NetHubQuickBringup.md]]
* [[NetHubVirtualChannel|NetHubVirtualChannel.md]]

NetHubArchitecture

2026-04-24T17:07:50Z

张良：Add NetHub architecture diagram to docs (2026-04-25)

= 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_arch.gif | NetHub Architecture Overview]]

<syntaxhighlight lang="text">
Wi-Fi backend + lwIP
|
v
nethub
+-----------+
| data-path |
| filter |
| ctrlpath |
| vchan |
+-----------+
|
v
host interface
(SDIO / USB / SPI)
</syntaxhighlight>

Important boundary:

* <code>nethub</code> core does not directly depend on <code>ATModule</code>
* <code>ATModule</code> is an optional example consumer of the NetHub control path

== 2. Current Support Matrix ==

{| class="wikitable"
|-
! 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
|}

== 3. Device-Side Layers ==

Public headers:

* <code>components/net/nethub/include/nethub.h</code>
* <code>components/net/nethub/include/nethub_vchan.h</code>
* <code>components/net/nethub/include/nethub_filter.h</code>

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_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>

== 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.

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

<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.

== 6. Virtual Channel ==

NetHub also exposes a logical virtual channel API:

<syntaxhighlight lang="c">
int nethub_vchan_user_send(const void *data, uint16_t len);
int nethub_vchan_user_recv_register(nethub_vchan_recv_cb_t recv_cb, void *cb_arg);
</syntaxhighlight>

API intent:

* stable logical message API across host interfaces

Current implementation:

* the in-tree implementation is still SDIO-backed
* the host userspace <code>nethub_vchan</code> library is also SDIO-based today
* therefore the current end-to-end USER virtual channel path follows the default <code>SDIO</code> interface

== 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>

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 <code>BL618DG</code> only.

The example configuration automatically disables <code>CONFIG_NETHUB_LOWPOWER_ENABLE</code> on other chips.

== 9. Recommended Reading ==

* [[NetHub|NetHub.md]]
* [[NetHubQuickBringup|NetHubQuickBringup.md]]
* [[NetHubVirtualChannel|NetHubVirtualChannel.md]]

文件:Nethub arch.gif

2026-04-24T17:01:58Z

张良：张良上传文件:Nethub arch.gif的新版本

== 摘要 ==
nethub sdio usb interface arch.

文件:Nethub arch.gif

2026-04-24T16:59:30Z

张良：张良上传文件:Nethub arch.gif的新版本

== 摘要 ==
nethub sdio usb interface arch.

文件:Nethub arch.gif

2026-04-24T16:57:51Z

张良：nethub sdio usb interface arch.

== 摘要 ==
nethub sdio usb interface arch.

NetHubQuickBringup

2026-04-24T15:11:47Z

张良：Add more NetHubQuickBringup FAQs (2026-04-24)

= NetHub Quick Start =

This document is for customers using NetHub for the first time. The goal is to get you to the current default interface as quickly as possible.

[[文件:Nethub_sdio_quickstart_demo.gif | NetHub SDIO Quick Start Demo]]

== 1. Current Support Matrix ==

{| class="wikitable"
|-
! Item !! Current status
|-
| Default interface || <code>SDIO</code>
|-
| USB interface || device-side backend implemented with <code>USB ECM + USB ACM</code>
|-
| SPI interface || not implemented
|-
| USER virtual channel || default interface is <code>SDIO</code>
|-
| Optional AT control solution || available, but not mandatory
|-
| Low power || currently <code>BL618DG</code> only
|}

Read this table literally:

* if you want the shortest successful path today, choose <code>SDIO</code>
* if you are evaluating the USB interface, focus on the device-side backend and USB descriptors first
* do not plan on <code>SPI</code> bring-up yet

== 2. Main Configuration Switches ==

For most users, the main configuration changes are these:

<syntaxhighlight lang="makefile">
CONFIG_NETHUB_CTRLCHANNEL_USE_ATMODULE =y
CONFIG_NETHUB_LOWPOWER_ENABLE =y
CONFIG_NETHUB_PROFILE_USB =n
CONFIG_NETHUB_PROFILE_SDIO =y
</syntaxhighlight>

Notes:

* the config symbol names still use <code>PROFILE</code>, but they select the active host interface
* set <code>CONFIG_NETHUB_PROFILE_SDIO=y</code> for the current default interface
* set <code>CONFIG_NETHUB_PROFILE_USB=y</code> only when you want to evaluate the USB interface
* <code>CONFIG_NETHUB_CTRLCHANNEL_USE_ATMODULE=n</code> means <code>ATModule</code> will not participate in the build
* <code>CONFIG_NETHUB_LOWPOWER_ENABLE=y</code> is currently meaningful only on <code>BL618DG</code>

Additional current default facts in <code>examples/wifi/nethub/defconfig</code>:

* <code>CONFIG_MR_VIRTUALCHAN=y</code>
* <code>CONFIG_NETHUB_AT_USE_VCHAN=n</code>
* <code>CONFIG_MR_TTY=n</code>

== 3. Wi-Fi Backend Selection ==

Default configuration:

* <code>CONFIG_WL80211</code> disabled
* <code>fhost</code> selected

If you want <code>wl80211</code>, enable this in <code>examples/wifi/nethub/defconfig</code>:

<syntaxhighlight lang="makefile">
CONFIG_WL80211=y
</syntaxhighlight>

Notes:

* <code>fhost</code> and <code>wl80211</code> are mutually exclusive
* current NetHub supports both device-side Wi-Fi backends

== 4. Device Build and Flash ==

Build:

<syntaxhighlight lang="bash">
cd examples/wifi/nethub

# BL616
make CHIP=bl616 BOARD=bl616dk

# BL616CL
make CHIP=bl616cl BOARD=bl616cldk

# BL618DG
make CHIP=bl618dg BOARD=bl618dgdk CPU_ID=ap
</syntaxhighlight>

Flash example:

<syntaxhighlight lang="bash">
cd examples/wifi/nethub
make flash CHIP=bl618dg COMX=/dev/ttyUSB0
</syntaxhighlight>

== 5. Hardware Interface Pins ==

The pin tables below are the current default mappings used by the in-tree BSP board helpers.

Reference sources in the repository:

* <code>bsp/board/bl616dk/board_gpio.c</code>
* <code>bsp/board/bl616cldk/board_gpio.c</code>
* <code>bsp/board/bl618dgdk/board_gpio.c</code>

=== 5.1 Default SDIO Pins ===

These are the current <code>board_sdh_gpio_init()</code> mappings used by the BSP.

{| class="wikitable"
|-
! Pin Function !! BL616 / BL618 (<code>bl616dk</code>) !! BL618DG (<code>bl618dgdk</code>) !! BL616CL (<code>bl616cldk</code>)
|-
| <code>SDIO_DAT2</code> || <code>GPIO10</code> || <code>GPIO43</code> || <code>GPIO6</code>
|-
| <code>SDIO_DAT3</code> || <code>GPIO11</code> || <code>GPIO44</code> || <code>GPIO7</code>
|-
| <code>SDIO_CMD</code> || <code>GPIO12</code> || <code>GPIO45</code> || <code>GPIO8</code>
|-
| <code>SDIO_CLK</code> || <code>GPIO13</code> || <code>GPIO46</code> || <code>GPIO9</code>
|-
| <code>SDIO_DAT0</code> || <code>GPIO14</code> || <code>GPIO47</code> || <code>GPIO10</code>
|-
| <code>SDIO_DAT1</code> || <code>GPIO15</code> || <code>GPIO48</code> || <code>GPIO11</code>
|}

Notes:

* this table shows the current default 4-bit SDIO wiring used by the NetHub SDIO data-path
* 1-line mode is also supported; if you use 1-line mode, keep <code>CMD</code>, <code>CLK</code>, and <code>DAT0</code> first
* the BSP configures these pins with <code>GPIO_FUNC_SDH | GPIO_ALTERNATE | GPIO_PULLUP | GPIO_SMT_EN | GPIO_DRV_1</code>

=== 5.2 Default USB Pins ===

The current USB interface uses the board's default USB differential pair.

{| class="wikitable"
|-
! Chip / Board family !! Default USB pins in current BSP !! Current BSP behavior !! Notes
|-
| BL616 / BL618 (<code>bl616dk</code>) || board default USB port path || current BSP enables USB clock in <code>board.c</code>, but does not expose a dedicated <code>board_usb_gpio_init()</code> helper || treat this as the board's fixed default USB routing in the current example
|-
| BL616CL (<code>bl616cldk</code>) || <code>GPIO32</code>, <code>GPIO33</code> || <code>board_usb_gpio_init()</code> configures the pair as analog pins || current BSP documents the pair, not separate <code>DP</code> / <code>DM</code> labels
|-
| BL618DG (<code>bl618dgdk</code>) || <code>GPIO40</code>, <code>GPIO41</code> || <code>board_usb_gpio_init()</code> configures the pair as analog pins || current BSP documents the pair, not separate <code>DP</code> / <code>DM</code> labels
|}

Notes:

* for <code>BL616CL</code> and <code>BL618DG</code>, the BSP helper only tells us the USB pair used by the board, not which pin is <code>D+</code> and which pin is <code>D-</code>
* if you are wiring a custom board and need explicit <code>DP</code> / <code>DM</code> polarity, confirm it from the board schematic or chip or package documentation

== 6. Host Bring-Up Guidance ==

For the current in-tree host Linux stack, use:

* <code>bsp/common/msg_router/linux_host/userspace/nethub/README.md</code>

Today that host stack follows the default <code>SDIO</code> interface.

For USB projects, keep expectations aligned with current code status:

* device-side <code>ECM + ACM</code> backend exists
* host-side transport flattening into the same <code>nethub_vchan</code> behavior as SDIO is not fully documented or aligned in-tree yet

== 7. USER Virtual Channel ==

If you need private application messages between host and device, read:

* [[NetHubVirtualChannel|NetHubVirtualChannel.md]]

Current implementation:

* the current in-tree end-to-end USER virtual channel follows the default <code>SDIO</code> interface
* the public device API is transport-neutral by design
* the in-tree implementation behind it is still SDIO-backed today

== 8. Low-Power Note ==

Low power is currently supported only on <code>BL618DG</code>.

For other chips, <code>examples/wifi/nethub/defconfig</code> automatically turns <code>CONFIG_NETHUB_LOWPOWER_ENABLE</code> off. In practice, you normally keep this option enabled only for <code>BL618DG</code> builds.

== 9. Common Questions ==

=== 9.1 <code>bflbwifid</code> Fails to Start ===

This question is relevant only when you use the optional host control stack.

Check first:

* whether the device and host control backends match
* whether <code>/dev/ttyAT0</code> exists
* whether <code>mr_sdio.ko</code> has been loaded successfully
* whether the SDIO hardware link is working properly

=== 9.2 <code>connect_ap</code> Succeeds but the Host Has No Network Access ===

Check first:

* whether <code>status</code> has reached <code>GOTIP</code>
* whether <code>mr_eth0</code> has an address
* whether services such as <code>NetworkManager</code> or <code>dhcpcd</code> override the NetHub configuration

Notes:

* <code>build.sh</code> builds userspace with <code>ENABLE_NETIF_AUTO_CONFIG=1</code> by default
* after the device reports <code>GOTIP</code>, the host automatically configures the IP, gateway, and DNS of <code>mr_eth0</code>

=== 9.3 <code>build.sh unload</code> Reports That the Module Is Busy ===

Check first:

* whether <code>bflbwifid</code> is still running
* whether <code>nethub_vchan_app</code> is still running

=== 9.4 How Do I Change the Host-Side Virtual Interface Name <code>mr_eth0</code>? ===

The default host-side virtual network interface name comes from:

* <code>bsp/common/msg_router/linux_host/kernel/netdev/mr_netdev.c</code>

The macro is:

<syntaxhighlight lang="c">
#define ETH_DRV_NAME "mr_eth%d"
</syntaxhighlight>

The first created interface therefore appears as <code>mr_eth0</code>.

To change the interface name, update <code>ETH_DRV_NAME</code> to the pattern you want. For example:

<syntaxhighlight lang="c">
#define ETH_DRV_NAME "nethub%d"
</syntaxhighlight>

Notes:

* keep <code>%d</code> if you want Linux to allocate names such as <code>nethub0</code>, <code>nethub1</code>, and so on
* rebuild the host software after the change and reload the host-side kernel module
* if any local scripts or service configuration still refer to <code>mr_eth0</code>, update them accordingly

=== 9.5 Can the Host Expose <code>AP</code> and <code>STA</code> at the Same Time? ===

No. Due to the current software implementation, this is not supported yet.

Current behavior:

* the host side exposes only one virtual interface at a time
* the default active Wi-Fi channel is <code>STA</code>

If you need to switch between <code>AP</code> and <code>STA</code>, call <code>nethub_set_active_wifi_channel()</code> directly:

* use <code>NETHUB_CHANNEL_WIFI_AP</code> to switch to <code>AP</code>
* use <code>NETHUB_CHANNEL_WIFI_STA</code> to switch to <code>STA</code>
* the default value is <code>NETHUB_CHANNEL_WIFI_STA</code>

=== 9.6 What Should the Host Side Handle When <code>CONFIG_NETHUB_CTRLCHANNEL_USE_ATMODULE=n</code>? ===

When <code>CONFIG_NETHUB_CTRLCHANNEL_USE_ATMODULE=n</code>, the optional AT-based host control solution is not part of the build.

What you need to handle yourself:

* you need your own private control path to carry required messages between host and device
* this includes, but is not limited to, host netdev link-up handling
* this also includes host-side IP address and netmask configuration

In short, NetHub still provides the data-path, but the host-side control workflow becomes your own responsibility.

=== 9.7 Why Does <code>ifconfig</code> Not Show the Virtual Interface? ===

Check first:

* use a command such as <code>ifconfig -a</code> to list interfaces that are currently down
* find the virtual interface and bring it up manually, for example: <code>sudo ifconfig mr_eth0 up</code>

Notes:

* some Linux systems, including newer Raspberry Pi OS releases, run <code>NetworkManager</code> by default
* because of that, the exact behavior depends on your host environment and may need host-specific analysis

=== 9.8 For Dual-Stack Traffic, Can Users Customize the Filter? Is There Any Difference Between USB and SDIO? ===

Yes. The default configuration already covers most scenarios, but users can still customize the Wi-Fi RX filter if needed.

Important points:

* the filter is not bound to one interface type; there is no special filter split between <code>USB</code> and <code>SDIO</code>
* the current built-in policy is shared by both <code>SDIO</code> and <code>USB</code>
* you can refer to <code>components/net/nethub/profile/nh_profile_sdio.c</code> and <code>components/net/nethub/profile/nh_profile_usb.c</code>; both use the same built-in Wi-Fi RX policy

Default built-in policy reference:

* <code>components/net/nethub/profile/nh_profile_builtin.c</code>
* <code>NH_FILTER_MATCH_8021X</code>: handled locally and not delivered to the host
* <code>NH_FILTER_MATCH_ARP</code>: handled locally and also delivered to the host
* <code>NH_FILTER_MATCH_DHCP4</code>: handled locally
* <code>NH_FILTER_MATCH_ICMP4</code>: handled locally
* other packets: delivered to the host by default

If the default policy does not match your requirement:

* you can call <code>nethub_set_wifi_rx_filter(nethub_wifi_rx_filter_cb_t filter_cb, void *user_ctx)</code> from <code>components/net/nethub/include/nethub_filter.h</code>
* for the callback behavior, refer to <code>nh_filter_apply_policy()</code> in <code>components/net/nethub/core/nh_filter.c</code>
* if you need a more complex policy, it is also fine to contact us directly

=== 9.9 Why Can the Host Not Ping Other Devices on the Same LAN? ===

This is expected with the current default policy.

Reason:

* <code>ICMP</code> packets are handled locally on the device side by default
* they are not delivered to the host by default

So, by default:

* other LAN devices pinging the device can work
* host-side ping visibility to other LAN devices is not part of the default behavior

== 10. Where to Go Next ==

* overall entry: [[NetHub|NetHub.md]]
* architecture: [[NetHubArchitecture|NetHubArchitecture.md]]
* USER virtual channel: [[NetHubVirtualChannel|NetHubVirtualChannel.md]]

NetHubQuickBringup

2026-04-24T14:37:57Z

张良：Restore FAQ and add AP/STA host-interface FAQ (2026-04-24)

= NetHub Quick Start =

This document is for customers using NetHub for the first time. The goal is to get you to the current default interface as quickly as possible.

[[文件:Nethub_sdio_quickstart_demo.gif | NetHub SDIO Quick Start Demo]]

== 1. Current Support Matrix ==

{| class="wikitable"
|-
! Item !! Current status
|-
| Default interface || <code>SDIO</code>
|-
| USB interface || device-side backend implemented with <code>USB ECM + USB ACM</code>
|-
| SPI interface || not implemented
|-
| USER virtual channel || default interface is <code>SDIO</code>
|-
| Optional AT control solution || available, but not mandatory
|-
| Low power || currently <code>BL618DG</code> only
|}

Read this table literally:

* if you want the shortest successful path today, choose <code>SDIO</code>
* if you are evaluating the USB interface, focus on the device-side backend and USB descriptors first
* do not plan on <code>SPI</code> bring-up yet

== 2. Main Configuration Switches ==

For most users, the main configuration changes are these:

<syntaxhighlight lang="makefile">
CONFIG_NETHUB_CTRLCHANNEL_USE_ATMODULE =y
CONFIG_NETHUB_LOWPOWER_ENABLE =y
CONFIG_NETHUB_PROFILE_USB =n
CONFIG_NETHUB_PROFILE_SDIO =y
</syntaxhighlight>

Notes:

* the config symbol names still use <code>PROFILE</code>, but they select the active host interface
* set <code>CONFIG_NETHUB_PROFILE_SDIO=y</code> for the current default interface
* set <code>CONFIG_NETHUB_PROFILE_USB=y</code> only when you want to evaluate the USB interface
* <code>CONFIG_NETHUB_CTRLCHANNEL_USE_ATMODULE=n</code> means <code>ATModule</code> will not participate in the build
* <code>CONFIG_NETHUB_LOWPOWER_ENABLE=y</code> is currently meaningful only on <code>BL618DG</code>

Additional current default facts in <code>examples/wifi/nethub/defconfig</code>:

* <code>CONFIG_MR_VIRTUALCHAN=y</code>
* <code>CONFIG_NETHUB_AT_USE_VCHAN=n</code>
* <code>CONFIG_MR_TTY=n</code>

== 3. Wi-Fi Backend Selection ==

Default configuration:

* <code>CONFIG_WL80211</code> disabled
* <code>fhost</code> selected

If you want <code>wl80211</code>, enable this in <code>examples/wifi/nethub/defconfig</code>:

<syntaxhighlight lang="makefile">
CONFIG_WL80211=y
</syntaxhighlight>

Notes:

* <code>fhost</code> and <code>wl80211</code> are mutually exclusive
* current NetHub supports both device-side Wi-Fi backends

== 4. Device Build and Flash ==

Build:

<syntaxhighlight lang="bash">
cd examples/wifi/nethub

# BL616
make CHIP=bl616 BOARD=bl616dk

# BL616CL
make CHIP=bl616cl BOARD=bl616cldk

# BL618DG
make CHIP=bl618dg BOARD=bl618dgdk CPU_ID=ap
</syntaxhighlight>

Flash example:

<syntaxhighlight lang="bash">
cd examples/wifi/nethub
make flash CHIP=bl618dg COMX=/dev/ttyUSB0
</syntaxhighlight>

== 5. Hardware Interface Pins ==

The pin tables below are the current default mappings used by the in-tree BSP board helpers.

Reference sources in the repository:

* <code>bsp/board/bl616dk/board_gpio.c</code>
* <code>bsp/board/bl616cldk/board_gpio.c</code>
* <code>bsp/board/bl618dgdk/board_gpio.c</code>

=== 5.1 Default SDIO Pins ===

These are the current <code>board_sdh_gpio_init()</code> mappings used by the BSP.

{| class="wikitable"
|-
! Pin Function !! BL616 / BL618 (<code>bl616dk</code>) !! BL618DG (<code>bl618dgdk</code>) !! BL616CL (<code>bl616cldk</code>)
|-
| <code>SDIO_DAT2</code> || <code>GPIO10</code> || <code>GPIO43</code> || <code>GPIO6</code>
|-
| <code>SDIO_DAT3</code> || <code>GPIO11</code> || <code>GPIO44</code> || <code>GPIO7</code>
|-
| <code>SDIO_CMD</code> || <code>GPIO12</code> || <code>GPIO45</code> || <code>GPIO8</code>
|-
| <code>SDIO_CLK</code> || <code>GPIO13</code> || <code>GPIO46</code> || <code>GPIO9</code>
|-
| <code>SDIO_DAT0</code> || <code>GPIO14</code> || <code>GPIO47</code> || <code>GPIO10</code>
|-
| <code>SDIO_DAT1</code> || <code>GPIO15</code> || <code>GPIO48</code> || <code>GPIO11</code>
|}

Notes:

* this table shows the current default 4-bit SDIO wiring used by the NetHub SDIO data-path
* 1-line mode is also supported; if you use 1-line mode, keep <code>CMD</code>, <code>CLK</code>, and <code>DAT0</code> first
* the BSP configures these pins with <code>GPIO_FUNC_SDH | GPIO_ALTERNATE | GPIO_PULLUP | GPIO_SMT_EN | GPIO_DRV_1</code>

=== 5.2 Default USB Pins ===

The current USB interface uses the board's default USB differential pair.

{| class="wikitable"
|-
! Chip / Board family !! Default USB pins in current BSP !! Current BSP behavior !! Notes
|-
| BL616 / BL618 (<code>bl616dk</code>) || board default USB port path || current BSP enables USB clock in <code>board.c</code>, but does not expose a dedicated <code>board_usb_gpio_init()</code> helper || treat this as the board's fixed default USB routing in the current example
|-
| BL616CL (<code>bl616cldk</code>) || <code>GPIO32</code>, <code>GPIO33</code> || <code>board_usb_gpio_init()</code> configures the pair as analog pins || current BSP documents the pair, not separate <code>DP</code> / <code>DM</code> labels
|-
| BL618DG (<code>bl618dgdk</code>) || <code>GPIO40</code>, <code>GPIO41</code> || <code>board_usb_gpio_init()</code> configures the pair as analog pins || current BSP documents the pair, not separate <code>DP</code> / <code>DM</code> labels
|}

Notes:

* for <code>BL616CL</code> and <code>BL618DG</code>, the BSP helper only tells us the USB pair used by the board, not which pin is <code>D+</code> and which pin is <code>D-</code>
* if you are wiring a custom board and need explicit <code>DP</code> / <code>DM</code> polarity, confirm it from the board schematic or chip or package documentation

== 6. Host Bring-Up Guidance ==

For the current in-tree host Linux stack, use:

* <code>bsp/common/msg_router/linux_host/userspace/nethub/README.md</code>

Today that host stack follows the default <code>SDIO</code> interface.

For USB projects, keep expectations aligned with current code status:

* device-side <code>ECM + ACM</code> backend exists
* host-side transport flattening into the same <code>nethub_vchan</code> behavior as SDIO is not fully documented or aligned in-tree yet

== 7. USER Virtual Channel ==

If you need private application messages between host and device, read:

* [[NetHubVirtualChannel|NetHubVirtualChannel.md]]

Current implementation:

* the current in-tree end-to-end USER virtual channel follows the default <code>SDIO</code> interface
* the public device API is transport-neutral by design
* the in-tree implementation behind it is still SDIO-backed today

== 8. Low-Power Note ==

Low power is currently supported only on <code>BL618DG</code>.

For other chips, <code>examples/wifi/nethub/defconfig</code> automatically turns <code>CONFIG_NETHUB_LOWPOWER_ENABLE</code> off. In practice, you normally keep this option enabled only for <code>BL618DG</code> builds.

== 9. Common Questions ==

=== 9.1 <code>bflbwifid</code> Fails to Start ===

This question is relevant only when you use the optional host control stack.

Check first:

* whether the device and host control backends match
* whether <code>/dev/ttyAT0</code> exists
* whether <code>mr_sdio.ko</code> has been loaded successfully
* whether the SDIO hardware link is working properly

=== 9.2 <code>connect_ap</code> Succeeds but the Host Has No Network Access ===

Check first:

* whether <code>status</code> has reached <code>GOTIP</code>
* whether <code>mr_eth0</code> has an address
* whether services such as <code>NetworkManager</code> or <code>dhcpcd</code> override the NetHub configuration

Notes:

* <code>build.sh</code> builds userspace with <code>ENABLE_NETIF_AUTO_CONFIG=1</code> by default
* after the device reports <code>GOTIP</code>, the host automatically configures the IP, gateway, and DNS of <code>mr_eth0</code>

=== 9.3 <code>build.sh unload</code> Reports That the Module Is Busy ===

Check first:

* whether <code>bflbwifid</code> is still running
* whether <code>nethub_vchan_app</code> is still running

=== 9.4 How Do I Change the Host-Side Virtual Interface Name <code>mr_eth0</code>? ===

The default host-side virtual network interface name comes from:

* <code>bsp/common/msg_router/linux_host/kernel/netdev/mr_netdev.c</code>

The macro is:

<syntaxhighlight lang="c">
#define ETH_DRV_NAME "mr_eth%d"
</syntaxhighlight>

The first created interface therefore appears as <code>mr_eth0</code>.

To change the interface name, update <code>ETH_DRV_NAME</code> to the pattern you want. For example:

<syntaxhighlight lang="c">
#define ETH_DRV_NAME "nethub%d"
</syntaxhighlight>

Notes:

* keep <code>%d</code> if you want Linux to allocate names such as <code>nethub0</code>, <code>nethub1</code>, and so on
* rebuild the host software after the change and reload the host-side kernel module
* if any local scripts or service configuration still refer to <code>mr_eth0</code>, update them accordingly

=== 9.5 Can the Host Expose <code>AP</code> and <code>STA</code> at the Same Time? ===

No. Due to the current software implementation, this is not supported yet.

Current behavior:

* the host side exposes only one virtual interface at a time
* the default active Wi-Fi channel is <code>STA</code>

If you need to switch between <code>AP</code> and <code>STA</code>, call <code>nethub_set_active_wifi_channel()</code> directly:

* use <code>NETHUB_CHANNEL_WIFI_AP</code> to switch to <code>AP</code>
* use <code>NETHUB_CHANNEL_WIFI_STA</code> to switch to <code>STA</code>
* the default value is <code>NETHUB_CHANNEL_WIFI_STA</code>

== 10. Where to Go Next ==

* overall entry: [[NetHub|NetHub.md]]
* architecture: [[NetHubArchitecture|NetHubArchitecture.md]]
* USER virtual channel: [[NetHubVirtualChannel|NetHubVirtualChannel.md]]

NetHubVirtualChannel

2026-04-24T14:27:37Z

张良：Unify tone and terminology across NetHub docs (2026-04-24)

= NetHub USER Virtual Channel =

This document describes the current NetHub USER virtual channel support.

== 1. Concept ==

USER virtual channel is a logical message channel carried on the active host interface.

It is not a separate physical interface. The public API is transport-neutral, while the current in-tree implementation is still centered on the default <code>SDIO</code> interface.

Common logical types:

{| class="wikitable"
|-
! Type !! Meaning
|-
| <code>USER</code> || private customer or application data
|-
| <code>AT</code> || control payloads
|-
| <code>SYSTEM</code> || internal coordination messages
|}

== 2. Current Support Status ==

{| class="wikitable"
|-
! Area !! Current status
|-
| Device API surface || transport-neutral by design
|-
| Device in-tree implementation || currently in <code>backend/host/sdio/virtualchan.c</code>
|-
| Host userspace library || currently aligned with <code>mr_sdio.ko + netlink</code>
|-
| Default interface for the current in-tree USER virtual channel path || <code>SDIO</code>
|-
| USB || device-side ACM transport exists, but in-tree host <code>nethub_vchan</code> alignment is not finished
|-
| SPI || not supported
|}

== 3. Prerequisites ==

Before using the current in-tree USER virtual channel path, confirm:

* device side is built with <code>CONFIG_NETHUB=y</code>
* device side enables <code>CONFIG_MR_VIRTUALCHAN=y</code>
* the selected bring-up path uses the default <code>SDIO</code> interface
* host side has loaded <code>mr_sdio.ko</code>
* the host-device link is already working

Notes:

* USER and AT are parallel logical channels
* customer private data should stay on the <code>USER</code> type
* documentation should not describe USB and SPI as if they already share a finished end-to-end virtual channel stack

== 4. Device-Side API ==

Header:

* <code>components/net/nethub/include/nethub_vchan.h</code>

Common APIs:

<syntaxhighlight lang="c">
int nethub_vchan_user_send(const void *data, uint16_t len);
int nethub_vchan_user_recv_register(nethub_vchan_recv_cb_t recv_cb, void *cb_arg);
</syntaxhighlight>

== 5. Host-Side API ==

Header:

* <code>bsp/common/msg_router/linux_host/userspace/nethub/virtualchan/nethub_vchan.h</code>

Initialization and cleanup:

<syntaxhighlight lang="c">
int nethub_vchan_init(void);
int nethub_vchan_deinit(void);
</syntaxhighlight>

USER channel:

<syntaxhighlight lang="c">
typedef void (*nethub_vchan_recv_callback_t)(const void *data, size_t len);

int nethub_vchan_user_send(const void *data, size_t len);
int nethub_vchan_user_register_callback(nethub_vchan_recv_callback_t callback);
</syntaxhighlight>

Optional state query:

<syntaxhighlight lang="c">
typedef struct {
nethub_vchan_link_state_t link_state;
nethub_vchan_host_state_t host_state;
} nethub_vchan_state_snapshot_t;

int nethub_vchan_get_state_snapshot(nethub_vchan_state_snapshot_t *snapshot);
</syntaxhighlight>

Optional link event callback:

<syntaxhighlight lang="c">
int nethub_vchan_register_link_event_callback(
nethub_vchan_link_event_callback_t callback,
void *user_data);
</syntaxhighlight>

== 6. Typical Usage Order ==

# <code>nethub_vchan_init()</code>
# <code>nethub_vchan_user_register_callback()</code>
# <code>nethub_vchan_user_send()</code>
# <code>nethub_vchan_deinit()</code> when finished

Example:

<syntaxhighlight lang="c">
#include <stdio.h>
#include <string.h>

#include "nethub_vchan.h"

static void user_rx_cb(const void *data, size_t len)
{
printf("recv USER data: %.*s\n", (int)len, (const char *)data);
}

int main(void)
{
const char *msg = "hello from host";

if (nethub_vchan_init() != 0) {
return -1;
}

nethub_vchan_user_register_callback(user_rx_cb);
nethub_vchan_user_send(msg, strlen(msg));

nethub_vchan_deinit();
return 0;
}
</syntaxhighlight>

== 7. Limits and Notes ==

* maximum payload length per message is <code>1500</code> bytes
* USER virtual channel is packet-oriented, not a byte stream
* the current in-tree end-to-end path is SDIO-based
* if the device side does not enable <code>CONFIG_MR_VIRTUALCHAN</code>, the current in-tree USER virtual channel path will not work
* if control traffic and USER traffic coexist, keep private application traffic on <code>USER</code> and do not reuse the <code>AT</code> type

== 8. Related Pages ==

* [[NetHub|NetHub.md]]
* [[NetHubQuickBringup|NetHubQuickBringup.md]]
* [[NetHubArchitecture|NetHubArchitecture.md]]

NetHubArchitecture

2026-04-24T14:27:34Z

张良：Unify tone and terminology across NetHub docs (2026-04-24)

= 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.

<syntaxhighlight lang="text">
Wi-Fi backend + lwIP
|
v
nethub
+-----------+
| data-path |
| filter |
| ctrlpath |
| vchan |
+-----------+
|
v
host interface
(SDIO / USB / SPI)
</syntaxhighlight>

Important boundary:

* <code>nethub</code> core does not directly depend on <code>ATModule</code>
* <code>ATModule</code> is an optional example consumer of the NetHub control path

== 2. Current Support Matrix ==

{| class="wikitable"
|-
! 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
|}

== 3. Device-Side Layers ==

Public headers:

* <code>components/net/nethub/include/nethub.h</code>
* <code>components/net/nethub/include/nethub_vchan.h</code>
* <code>components/net/nethub/include/nethub_filter.h</code>

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_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>

== 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.

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

<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.

== 6. Virtual Channel ==

NetHub also exposes a logical virtual channel API:

<syntaxhighlight lang="c">
int nethub_vchan_user_send(const void *data, uint16_t len);
int nethub_vchan_user_recv_register(nethub_vchan_recv_cb_t recv_cb, void *cb_arg);
</syntaxhighlight>

API intent:

* stable logical message API across host interfaces

Current implementation:

* the in-tree implementation is still SDIO-backed
* the host userspace <code>nethub_vchan</code> library is also SDIO-based today
* therefore the current end-to-end USER virtual channel path follows the default <code>SDIO</code> interface

== 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>

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 <code>BL618DG</code> only.

The example configuration automatically disables <code>CONFIG_NETHUB_LOWPOWER_ENABLE</code> on other chips.

== 9. Recommended Reading ==

* [[NetHub|NetHub.md]]
* [[NetHubQuickBringup|NetHubQuickBringup.md]]
* [[NetHubVirtualChannel|NetHubVirtualChannel.md]]

NetHubQuickBringup

2026-04-24T14:27:32Z

张良：Unify tone and terminology across NetHub docs (2026-04-24)

NetHub

2026-04-24T14:27:32Z

张良：Unify tone and terminology across NetHub docs (2026-04-24)

= NetHub =

NetHub bridges device-side Wi-Fi capability to a selected host interface.

The current solution targets Wi-Fi SoCs such as <code>BL616 / BL618 / BL616CL / BL618DG</code>.

== Current Status ==

{| class="wikitable"
|-
! Item !! Current status
|-
| Default interface || <code>SDIO</code>
|-
| USB data-path || device-side <code>USB ECM</code> backend implemented
|-
| USB control transport || device-side <code>USB ACM</code> transport plumbing implemented
|-
| SPI || not implemented
|-
| USER virtual channel || default interface is <code>SDIO</code>
|-
| Low power || currently <code>BL618DG</code> only
|-
| Optional ATModule control solution || available, but not mandatory
|}

== Document Guide ==

Use these documents according to what you need:

{| class="wikitable"
|-
! Document !! Focus
|-
| [[NetHubQuickBringup|NetHubQuickBringup.md]] || default interface, main configuration switches, build and flash, SDIO and USB pins
|-
| [[NetHubArchitecture|NetHubArchitecture.md]] || internal layering, public APIs, support matrix, and interface differences
|-
| [[NetHubVirtualChannel|NetHubVirtualChannel.md]] || USER virtual channel scope, prerequisites, APIs, and limits
|}

== Key Points ==

* <code>SDIO</code> is the current default interface for the in-tree bring-up path.
* <code>USB</code> device-side backend is implemented with <code>ECM + ACM</code>.
* <code>SPI</code> is still a stub and is not ready for bring-up.
* <code>nethub</code> core exposes data-path, control path, and virtual channel facades without directly depending on <code>ATModule</code>.
* The optional <code>ATModule + bflbwifid + bflbwifictrl</code> flow is available, but not mandatory.

== In-Repo Reference Directories ==

* <code>examples/wifi/nethub</code>
* <code>components/net/nethub</code>
* <code>bsp/common/msg_router/linux_host/userspace/nethub</code>

== Local Documentation Source ==

The in-repo documentation source is:

* <code>examples/wifi/nethub/docs/</code>

== Online Wiki ==

* [https://docs.bouffalolab.com/index.php?title=NetHub NetHub]
* [https://docs.bouffalolab.com/index.php?title=NetHubQuickBringup NetHubQuickBringup]
* [https://docs.bouffalolab.com/index.php?title=NetHubArchitecture NetHubArchitecture]
* [https://docs.bouffalolab.com/index.php?title=NetHubVirtualChannel NetHubVirtualChannel]

NetHubVirtualChannel

2026-04-24T14:20:29Z

张良：Sync NetHub docs from local Markdown (2026-04-24 wording update)

= NetHub USER Virtual Channel =

This document describes the current NetHub USER virtual-channel support.

== 1. Concept ==

USER virtual channel is a logical message channel carried on the active host link.

It is not a separate physical interface. The public API is designed to be transport-neutral, while the current in-tree implementation is still centered on the SDIO reference path.

Common logical types:

{| class="wikitable"
|-
! Type !! Meaning
|-
| <code>USER</code> || private customer or application data
|-
| <code>AT</code> || control payloads
|-
| <code>SYSTEM</code> || internal coordination messages
|}

== 2. Current Support Status ==

{| class="wikitable"
|-
! Area !! Current status
|-
| Device API surface || transport-neutral by design
|-
| Device in-tree implementation || currently in <code>backend/host/sdio/virtualchan.c</code>
|-
| Host userspace library || currently aligned with <code>mr_sdio.ko + netlink</code>
|-
| Default interface for the current in-tree USER vchan path || <code>SDIO</code>
|-
| USB || device-side ACM transport exists, but in-tree host <code>nethub_vchan</code> alignment is not finished
|-
| SPI || not supported
|}

== 3. Prerequisites ==

Before using the current in-tree USER virtual-channel path, confirm:

* device side is built with <code>CONFIG_NETHUB=y</code>
* device side enables <code>CONFIG_MR_VIRTUALCHAN=y</code>
* the selected bring-up path is the current SDIO reference flow
* host side has loaded <code>mr_sdio.ko</code>
* the host-device link is already working

Notes:

* USER and AT are parallel logical channels
* customer private data should stay on the <code>USER</code> type
* documentation should not claim that USB and SPI already share the same finished end-to-end virtual-channel stack

== 4. Device-Side API ==

Header:

* <code>components/net/nethub/include/nethub_vchan.h</code>

Common APIs:

<syntaxhighlight lang="c">
int nethub_vchan_user_send(const void *data, uint16_t len);
int nethub_vchan_user_recv_register(nethub_vchan_recv_cb_t recv_cb, void *cb_arg);
</syntaxhighlight>

== 5. Host-Side API ==

Header:

* <code>bsp/common/msg_router/linux_host/userspace/nethub/virtualchan/nethub_vchan.h</code>

Initialization and cleanup:

<syntaxhighlight lang="c">
int nethub_vchan_init(void);
int nethub_vchan_deinit(void);
</syntaxhighlight>

USER channel:

<syntaxhighlight lang="c">
typedef void (*nethub_vchan_recv_callback_t)(const void *data, size_t len);

int nethub_vchan_user_send(const void *data, size_t len);
int nethub_vchan_user_register_callback(nethub_vchan_recv_callback_t callback);
</syntaxhighlight>

Optional state query:

<syntaxhighlight lang="c">
typedef struct {
nethub_vchan_link_state_t link_state;
nethub_vchan_host_state_t host_state;
} nethub_vchan_state_snapshot_t;

int nethub_vchan_get_state_snapshot(nethub_vchan_state_snapshot_t *snapshot);
</syntaxhighlight>

Optional link event callback:

<syntaxhighlight lang="c">
int nethub_vchan_register_link_event_callback(
nethub_vchan_link_event_callback_t callback,
void *user_data);
</syntaxhighlight>

== 6. Typical Usage Order ==

# <code>nethub_vchan_init()</code>
# <code>nethub_vchan_user_register_callback()</code>
# <code>nethub_vchan_user_send()</code>
# <code>nethub_vchan_deinit()</code> when finished

Example:

<syntaxhighlight lang="c">
#include <stdio.h>
#include <string.h>

#include "nethub_vchan.h"

static void user_rx_cb(const void *data, size_t len)
{
printf("recv USER data: %.*s\n", (int)len, (const char *)data);
}

int main(void)
{
const char *msg = "hello from host";

if (nethub_vchan_init() != 0) {
return -1;
}

nethub_vchan_user_register_callback(user_rx_cb);
nethub_vchan_user_send(msg, strlen(msg));

nethub_vchan_deinit();
return 0;
}
</syntaxhighlight>

== 7. Limits and Notes ==

* maximum payload length per message is <code>1500</code> bytes
* USER virtual channel is packet-oriented, not a byte stream
* the current in-tree end-to-end path is SDIO-based
* if the device side does not enable <code>CONFIG_MR_VIRTUALCHAN</code>, the current in-tree USER virtual-channel path will not work
* if control traffic and USER traffic coexist, keep private application traffic on <code>USER</code> and do not reuse the <code>AT</code> type

== 8. Related Pages ==

* [[NetHub|NetHub.md]]
* [[NetHubQuickBringup|NetHubQuickBringup.md]]
* [[NetHubArchitecture|NetHubArchitecture.md]]

NetHubArchitecture

2026-04-24T14:20:27Z

张良：Sync NetHub docs from local Markdown (2026-04-24 wording update)

= NetHub Architecture =

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

== 1. High-Level Model ==

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

<syntaxhighlight lang="text">
Wi-Fi backend + lwIP
|
v
nethub
+-----------+
| data-path |
| filter |
| ctrlpath |
| vchan |
+-----------+
|
v
host-link profile
(SDIO / USB / SPI)
</syntaxhighlight>

Important boundary:

* <code>nethub</code> core does not directly depend on <code>ATModule</code>
* <code>ATModule</code> is an optional example consumer of the NetHub control path

== 2. Current Support Matrix ==

{| class="wikitable"
|-
! Area !! SDIO !! USB !! SPI
|-
| Device-side profile || 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 reference path || yes || not yet the main reference path || no
|-
| End-to-end USER virtual channel || yes || not yet aligned in-tree || no
|-
| Current default interface || yes || no || no
|}

== 3. Device-Side Layers ==

Public headers:

* <code>components/net/nethub/include/nethub.h</code>
* <code>components/net/nethub/include/nethub_vchan.h</code>
* <code>components/net/nethub/include/nethub_filter.h</code>

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_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>

== 4. Data-Path ==

The data-path is the main NetHub function.

<syntaxhighlight lang="text">
host payload -> host-link 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 host-link side 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 profile.

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

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

== 6. Virtual Channel ==

NetHub also exposes a logical virtual-channel API:

<syntaxhighlight lang="c">
int nethub_vchan_user_send(const void *data, uint16_t len);
int nethub_vchan_user_recv_register(nethub_vchan_recv_cb_t recv_cb, void *cb_arg);
</syntaxhighlight>

API intent:

* stable logical message API across host-link types

Current backend reality:

* the in-tree implementation is still SDIO-backed
* the host userspace <code>nethub_vchan</code> library is also SDIO-based today
* therefore the current end-to-end USER virtual-channel story follows the default <code>SDIO</code> interface

== 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>

Notes:

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

== 8. Low-Power Scope ==

Current low-power support is <code>BL618DG</code> only.

The example configuration automatically disables <code>CONFIG_NETHUB_LOWPOWER_ENABLE</code> on other chips.

== 9. Recommended Reading ==

* [[NetHub|NetHub.md]]
* [[NetHubQuickBringup|NetHubQuickBringup.md]]
* [[NetHubVirtualChannel|NetHubVirtualChannel.md]]

NetHubQuickBringup

2026-04-24T14:20:25Z

张良：Sync NetHub docs from local Markdown (2026-04-24 wording update)

NetHub

2026-04-24T14:20:25Z

张良：Sync NetHub docs from local Markdown (2026-04-24 wording update)

= NetHub =

NetHub bridges device-side Wi-Fi capability to a selected host-link backend.

The current solution targets Wi-Fi SoCs such as <code>BL616 / BL618 / BL616CL / BL618DG</code>.

== Current Status ==

{| class="wikitable"
|-
! Item !! Current status
|-
| Default interface || <code>SDIO</code>
|-
| USB data-path || device-side <code>USB ECM</code> backend implemented
|-
| USB control transport || device-side <code>USB ACM</code> transport plumbing implemented
|-
| SPI || not implemented
|-
| USER virtual channel || default interface is <code>SDIO</code>
|-
| Low power || currently <code>BL618DG</code> only
|-
| Optional ATModule control solution || available, but not mandatory
|}

== Document Guide ==

Use these documents according to what you need:

{| class="wikitable"
|-
! Document !! Focus
|-
| [[NetHubQuickBringup|NetHubQuickBringup.md]] || default interface, main configuration switches, build and flash, SDIO and USB pins
|-
| [[NetHubArchitecture|NetHubArchitecture.md]] || internal layering, public APIs, support matrix, and host-link differences
|-
| [[NetHubVirtualChannel|NetHubVirtualChannel.md]] || USER virtual channel scope, prerequisites, APIs, and limits
|}

== Key Points ==

* <code>SDIO</code> is the current default interface and the current in-tree reference path.
* <code>USB</code> device-side backend is implemented with <code>ECM + ACM</code>.
* <code>SPI</code> is still a stub and is not ready for bring-up.
* <code>nethub</code> core exposes data-path, control-path, and virtual-channel facades without directly depending on <code>ATModule</code>.
* The optional <code>ATModule + bflbwifid + bflbwifictrl</code> flow is available, but it is not required.

== In-Repo Reference Directories ==

* <code>examples/wifi/nethub</code>
* <code>components/net/nethub</code>
* <code>bsp/common/msg_router/linux_host/userspace/nethub</code>

== Local Documentation Source ==

The in-repo documentation source is:

* <code>examples/wifi/nethub/docs/</code>

== Online Wiki ==

* [https://docs.bouffalolab.com/index.php?title=NetHub NetHub]
* [https://docs.bouffalolab.com/index.php?title=NetHubQuickBringup NetHubQuickBringup]
* [https://docs.bouffalolab.com/index.php?title=NetHubArchitecture NetHubArchitecture]
* [https://docs.bouffalolab.com/index.php?title=NetHubVirtualChannel NetHubVirtualChannel]

NetHubVirtualChannel

2026-04-24T13:48:39Z

张良：Sync NetHub docs from local Markdown (2026-04-24)

= NetHub USER Virtual Channel =

This document describes the current NetHub USER virtual-channel support.

== 1. Concept ==

USER virtual channel is a logical message channel carried on the active host link.

It is not a separate physical interface. The public API is designed to be transport-neutral, while the current in-tree implementation is still centered on the SDIO reference path.

Common logical types are:

***** <code>USER</code>
****** private customer or application data
***** <code>AT</code>
****** control payloads
***** <code>SYSTEM</code>
****** internal coordination messages

== 2. Current Support Status ==

{| class="wikitable"
|-
! Area !! Current status
|-
| Device API surface || transport-neutral by design
|-
| Device in-tree implementation || currently in <code>backend/host/sdio/virtualchan.c</code>
|-
| Host userspace library || currently aligned with <code>mr_sdio.ko + netlink</code>
|-
| End-to-end USER vchan reference path || <code>SDIO</code>
|-
| USB || device-side ACM transport exists, but in-tree host <code>nethub_vchan</code> alignment is not finished
|-
| SPI || not supported
|}

== 3. Prerequisites ==

Before using the current in-tree USER virtual-channel path, confirm:

***** device side is built with <code>CONFIG_NETHUB=y</code>
***** device side enables <code>CONFIG_MR_VIRTUALCHAN=y</code>
***** the selected bring-up path is the current SDIO reference flow
***** host side has loaded <code>mr_sdio.ko</code>
***** the host-device link is already working

Notes:

***** USER and AT are parallel logical channels
***** customer private data should stay on the <code>USER</code> type
***** documentation should not claim that USB and SPI already share the same finished end-to-end virtual-channel stack

== 4. Device-Side API ==

Header:

***** <code>components/net/nethub/include/nethub_vchan.h</code>

Common APIs:

<syntaxhighlight lang="c">
int nethub_vchan_user_send(const void *data, uint16_t len);
int nethub_vchan_user_recv_register(nethub_vchan_recv_cb_t recv_cb, void *cb_arg);
</syntaxhighlight>

== 5. Host-Side API ==

Header:

***** <code>bsp/common/msg_router/linux_host/userspace/nethub/virtualchan/nethub_vchan.h</code>

Initialization and cleanup:

<syntaxhighlight lang="c">
int nethub_vchan_init(void);
int nethub_vchan_deinit(void);
</syntaxhighlight>

USER channel:

<syntaxhighlight lang="c">
typedef void (*nethub_vchan_recv_callback_t)(const void *data, size_t len);

int nethub_vchan_user_send(const void *data, size_t len);
int nethub_vchan_user_register_callback(nethub_vchan_recv_callback_t callback);
</syntaxhighlight>

Optional state query:

<syntaxhighlight lang="c">
typedef struct {
nethub_vchan_link_state_t link_state;
nethub_vchan_host_state_t host_state;
} nethub_vchan_state_snapshot_t;

int nethub_vchan_get_state_snapshot(nethub_vchan_state_snapshot_t *snapshot);
</syntaxhighlight>

Optional link event callback:

<syntaxhighlight lang="c">
int nethub_vchan_register_link_event_callback(
nethub_vchan_link_event_callback_t callback,
void *user_data);
</syntaxhighlight>

== 6. Typical Usage Order ==

##### <code>nethub_vchan_init()</code>
##### <code>nethub_vchan_user_register_callback()</code>
##### <code>nethub_vchan_user_send()</code>
##### <code>nethub_vchan_deinit()</code> when finished

Example:

<syntaxhighlight lang="c">
#include <stdio.h>
#include <string.h>

#include "nethub_vchan.h"

static void user_rx_cb(const void *data, size_t len)
{
printf("recv USER data: %.*s
", (int)len, (const char *)data);
}

int main(void)
{
const char *msg = "hello from host";

if (nethub_vchan_init() != 0) {
return -1;
}

nethub_vchan_user_register_callback(user_rx_cb);
nethub_vchan_user_send(msg, strlen(msg));

nethub_vchan_deinit();
return 0;
}
</syntaxhighlight>

== 7. Limits and Notes ==

***** maximum payload length per message is <code>1500</code> bytes
***** USER virtual channel is packet-oriented, not a byte stream
***** the current in-tree end-to-end path is SDIO-based
***** if the device side does not enable <code>CONFIG_MR_VIRTUALCHAN</code>, the current in-tree USER virtual-channel path will not work
***** if control traffic and USER traffic coexist, keep private application traffic on <code>USER</code> and do not reuse the <code>AT</code> type

== 8. Related Pages ==

***** [[NetHub|NetHub.md]]
***** [[NetHubQuickBringup|NetHubQuickBringup.md]]
***** [[NetHubArchitecture|NetHubArchitecture.md]]

NetHubArchitecture

2026-04-24T13:48:37Z

张良：Sync NetHub docs from local Markdown (2026-04-24)

= NetHub Architecture =

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

== 1. High-Level Model ==

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

<syntaxhighlight lang="text">
Wi-Fi backend + lwIP
|
v
nethub
+-----------+
| data path |
| filter |
| ctrlpath |
| vchan |
+-----------+
|
v
host-link profile
(SDIO / USB / SPI)
</syntaxhighlight>

Important boundary:

* <code>nethub</code> core does not directly depend on <code>ATModule</code>
* <code>ATModule</code> is an optional example consumer of the NetHub control path

== 2. Current Support Matrix ==

{| class="wikitable"
|-
! Area !! SDIO !! USB !! SPI
|-
| Device-side profile || 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 reference path || yes || not yet the main reference path || no
|-
| End-to-end USER virtual channel || yes || not yet aligned in-tree || no
|-
| Recommended today || yes || evaluation only || no
|}

== 3. Device-Side Layers ==

Public headers:

* <code>components/net/nethub/include/nethub.h</code>
* <code>components/net/nethub/include/nethub_vchan.h</code>
* <code>components/net/nethub/include/nethub_filter.h</code>

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_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>

== 4. Data Plane ==

The data plane is the main NetHub function.

<syntaxhighlight lang="text">
host payload -> host-link 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 host-link side 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 profile.

Current interpretation:

* <code>SDIO</code>: implemented in-tree
* <code>USB</code>: device-side ACM transport plumbing implemented
* <code>SPI</code>: not implemented

Optional AT solution:

* <code>CONFIG_NETHUB_CTRLCHANNEL_USE_ATMODULE=y</code>
** example enables <code>ATModule</code> plus host <code>bflbwifid / bflbwifictrl</code>
* <code>CONFIG_NETHUB_CTRLCHANNEL_USE_ATMODULE=n</code>
** data-plane-only products can omit the example control chain

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

== 6. Virtual Channel ==

NetHub also exposes a logical virtual-channel API:

<syntaxhighlight lang="c">
int nethub_vchan_user_send(const void *data, uint16_t len);
int nethub_vchan_user_recv_register(nethub_vchan_recv_cb_t recv_cb, void *cb_arg);
</syntaxhighlight>

API intent:

* stable logical message API across host-link types

Current backend reality:

* the in-tree implementation is still SDIO-backed
* the host userspace <code>nethub_vchan</code> library is also SDIO-based today
* therefore the current end-to-end USER virtual-channel story is the SDIO reference path

== 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>

Notes:

* this is not required for NetHub data-plane-only products
* the in-tree host Linux reference stack is still centered on the SDIO path

== 8. Low-Power Scope ==

Current low-power support is <code>BL618DG</code> only.

The example configuration automatically disables <code>CONFIG_NETHUB_LOWPOWER_ENABLE</code> on other chips.

== 9. Recommended Reading ==

* [[NetHub|NetHub.md]]
* [[NetHubQuickBringup|NetHubQuickBringup.md]]
* [[NetHubVirtualChannel|NetHubVirtualChannel.md]]

NetHubQuickBringup

2026-04-24T13:48:35Z

张良：Sync NetHub docs from local Markdown (2026-04-24)

= NetHub Quick Start =

This document is for customers using NetHub for the first time. The goal is to get you to the currently supported bring-up path as quickly as possible.

[[文件:Nethub_sdio_quickstart_demo.gif | NetHub SDIO Quick Start Demo]]

== 1. Start with the Current Support Matrix ==

{| class="wikitable"
|-
! Item !! Current status
|-
| Recommended end-to-end reference path || <code>SDIO</code>
|-
| USB profile || device-side backend implemented with <code>USB ECM + USB ACM</code>
|-
| SPI profile || not implemented
|-
| USER virtual channel || current in-tree end-to-end path is <code>SDIO</code>
|-
| Optional AT control solution || available, but not required for data-only use cases
|-
| Low power || currently <code>BL618DG</code> only
|}

Read this table literally:

* if you want the shortest successful path today, choose <code>SDIO</code>
* if you are evaluating the new USB device-side backend, focus on the device profile and USB descriptors first
* do not plan on <code>SPI</code> bring-up yet

== 2. Decide Whether You Need Only Data or Data Plus Control ==

NetHub core always focuses on the data plane first.

* data-only products
** keep <code>nethub</code>
** do not depend on <code>ATModule</code>
** host users simply use the exposed netdev path
* data plus AT-style control products
** optionally enable the example composition built around <code>ATModule + bflbwifid + bflbwifictrl</code>

The important boundary is:

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

== 3. Choose the Host-Link Profile ==

The profile is selected at build time through exactly one <code>CONFIG_NETHUB_PROFILE_*</code> option.

=== 3.1 SDIO ===

Recommended today.

What you get:

* current in-tree reference data path
* current in-tree host Linux stack
* current in-tree USER virtual-channel path

=== 3.2 USB ===

Use this when you specifically want the device-side USB backend.

Current device-side behavior:

* data path through <code>USB CDC ECM</code>
* control transport plumbing through <code>USB CDC ACM</code>

Current limitation:

* the in-tree host Linux docs and <code>nethub_vchan</code> wrapper are still centered on the SDIO reference path

=== 3.3 SPI ===

Not implemented yet.

== 4. Choose the Wi-Fi Backend ==

Default configuration:

* <code>CONFIG_WL80211</code> disabled
* <code>fhost</code> selected

If you want <code>wl80211</code>, enable this in <code>examples/wifi/nethub/defconfig</code>:

<syntaxhighlight lang="makefile">
CONFIG_WL80211=y
</syntaxhighlight>

Notes:

* <code>fhost</code> and <code>wl80211</code> are mutually exclusive
* current NetHub supports both device-side Wi-Fi backends

== 5. Device Build and Flash ==

Build:

<syntaxhighlight lang="bash">
cd examples/wifi/nethub

# BL616
make CHIP=bl616 BOARD=bl616dk

# BL616CL
make CHIP=bl616cl BOARD=bl616cldk

# BL618DG
make CHIP=bl618dg BOARD=bl618dgdk CPU_ID=ap
</syntaxhighlight>

Flash example:

<syntaxhighlight lang="bash">
cd examples/wifi/nethub
make flash CHIP=bl618dg COMX=/dev/ttyUSB0
</syntaxhighlight>

== 6. Important Configuration Switches ==

Main configuration file:

* <code>examples/wifi/nethub/defconfig</code>

Important switches:

* <code>CONFIG_NETHUB=y</code>
* <code>CONFIG_NETHUB_PROFILE_SDIO=y</code>
* <code>CONFIG_NETHUB_PROFILE_USB=y</code>
* <code>CONFIG_NETHUB_PROFILE_SPI=y</code>
** choose exactly one profile per build
* <code>CONFIG_NETHUB_CTRLCHANNEL_USE_ATMODULE=y</code>
** enable the optional example AT control solution
* <code>CONFIG_MR_VIRTUALCHAN=y</code>
** required for the current in-tree SDIO virtual-channel path
* <code>CONFIG_NETHUB_LOWPOWER_ENABLE=y</code>
** currently meaningful only on <code>BL618DG</code>

About <code>CONFIG_NETHUB_AT_USE_VCHAN</code>:

* it still exists in the example configuration
* it is best treated as an example or legacy SDIO control-path switch
* do not document it as the core selector for all NetHub interfaces

Current default example facts:

* <code>CONFIG_NETHUB_PROFILE_SDIO=y</code>
* <code>CONFIG_NETHUB_PROFILE_USB=n</code>
* <code>CONFIG_NETHUB_CTRLCHANNEL_USE_ATMODULE=y</code>
* <code>CONFIG_MR_VIRTUALCHAN=y</code>
* <code>CONFIG_NETHUB_AT_USE_VCHAN=n</code>
* <code>CONFIG_MR_TTY=n</code>

== 7. Hardware Interface Pins ==

The pin tables below are the current default mappings used by the in-tree BSP board helpers.

Reference sources in the repository:

* SDIO/USB pins
** <code>bsp/board/bl616dk/board_gpio.c</code>
** <code>bsp/board/bl616cldk/board_gpio.c</code>
** <code>bsp/board/bl618dgdk/board_gpio.c</code>

=== 7.1 Default SDIO Pins ===

These are the current <code>board_sdh_gpio_init()</code> mappings used by the BSP.

{| class="wikitable"
|-
! Pin Function !! BL616 / BL618 (<code>bl616dk</code>) !! BL618DG (<code>bl618dgdk</code>) !! BL616CL (<code>bl616cldk</code>)
|-
| <code>SDIO_DAT2</code> || <code>GPIO10</code> || <code>GPIO43</code> || <code>GPIO6</code>
|-
| <code>SDIO_DAT3</code> || <code>GPIO11</code> || <code>GPIO44</code> || <code>GPIO7</code>
|-
| <code>SDIO_CMD</code> || <code>GPIO12</code> || <code>GPIO45</code> || <code>GPIO8</code>
|-
| <code>SDIO_CLK</code> || <code>GPIO13</code> || <code>GPIO46</code> || <code>GPIO9</code>
|-
| <code>SDIO_DAT0</code> || <code>GPIO14</code> || <code>GPIO47</code> || <code>GPIO10</code>
|-
| <code>SDIO_DAT1</code> || <code>GPIO15</code> || <code>GPIO48</code> || <code>GPIO11</code>
|}

Notes:

* this is the current 4-bit SDIO reference wiring used by the NetHub SDIO path
* the BSP configures these pins with `GPIO_FUNC_SDH | GPIO_ALTERNATE | GPIO_PULLUP | GPIO_SMT_EN | GPIO_DRV_1`
* if you are doing first bring-up, use this exact mapping first before trying a custom board layout

=== 7.2 Default USB Pins ===

The current USB profile uses the board's default USB differential pair.

{| class="wikitable"
|-
! Chip / Board family !! Default USB pins in current BSP !! Current BSP behavior !! Notes
|-
| BL616 / BL618 (<code>bl616dk</code>) || board default USB port path || current BSP enables USB clock in <code>board.c</code>, but does not expose a dedicated <code>board_usb_gpio_init()</code> helper || treat this as the board's fixed default USB routing in the current example
|-
| BL616CL (<code>bl616cldk</code>) || <code>GPIO32</code>, <code>GPIO33</code> || <code>board_usb_gpio_init()</code> configures the pair as analog pins || current BSP documents the pair, not separate <code>DP</code> / <code>DM</code> labels
|-
| BL618DG (<code>bl618dgdk</code>) || <code>GPIO40</code>, <code>GPIO41</code> || <code>board_usb_gpio_init()</code> configures the pair as analog pins || current BSP documents the pair, not separate <code>DP</code> / <code>DM</code> labels
|}

Notes:

* for <code>BL616CL</code> and <code>BL618DG</code>, the BSP helper only tells us the USB pair used by the board, not which pin is <code>D+</code> and which pin is <code>D-</code>
* if you are wiring a custom board and need explicit <code>DP</code> / <code>DM</code> polarity, confirm it from the board schematic or chip/package documentation
* for the current in-tree NetHub reference flow, USB is device-side bring-up work, while the full host reference stack is still centered on SDIO

== 8. Host Bring-Up Guidance ==

For the current in-tree host Linux reference stack, use:

* <code>bsp/common/msg_router/linux_host/userspace/nethub/README.md</code>

Today that host stack is primarily the <code>SDIO</code> reference flow.

For USB projects, keep expectations aligned with current code status:

* device-side <code>ECM + ACM</code> backend exists
* host-side transport flattening into the same <code>nethub_vchan</code> behavior as SDIO is not fully documented or aligned in-tree yet

== 9. USER Virtual Channel Guidance ==

If you need private application messages between host and device:

* device API: <code>components/net/nethub/include/nethub_vchan.h</code>
* host API: <code>bsp/common/msg_router/linux_host/userspace/nethub/virtualchan/nethub_vchan.h</code>

Current reality:

* end-to-end in-tree USER virtual channel is the <code>SDIO</code> path
* the public device API is transport-neutral by design
* the in-tree implementation behind it is still SDIO-backed today

== 10. Low-Power Note ==

<code>CONFIG_NETHUB_LOWPOWER_ENABLE</code> is currently supported only on <code>BL618DG</code>. The example configuration automatically disables it on other chips.

== 11. Where to Go Next ==

* overall entry: [[NetHub|NetHub.md]]
* architecture: [[NetHubArchitecture|NetHubArchitecture.md]]
* USER virtual channel: [[NetHubVirtualChannel|NetHubVirtualChannel.md]]

NetHub

2026-04-24T13:48:34Z

张良：Sync NetHub docs from local Markdown (2026-04-24)

= NetHub =

NetHub bridges device-side Wi-Fi capability to a selected host-link backend.

The current solution targets Wi-Fi SoCs such as <code>BL616 / BL618 / BL616CL / BL618DG</code>.

== Current Status ==

{| class="wikitable"
|-
! Item !! Current status
|-
| Reference bring-up path || <code>SDIO</code>
|-
| USB data path || device-side <code>USB ECM</code> backend implemented
|-
| USB control transport || device-side <code>USB ACM</code> transport plumbing implemented
|-
| SPI || not implemented
|-
| USER virtual channel || currently end-to-end in-tree on <code>SDIO</code>
|-
| Low power || currently <code>BL618DG</code> only
|-
| ATModule dependency || optional example composition only; not a NetHub core dependency
|}

== Documentation Guide ==

* [[NetHubQuickBringup|NetHubQuickBringup.md]]
** first-time bring-up and current support limits
* [[NetHubArchitecture|NetHubArchitecture.md]]
** current device and host architecture, profile boundaries, and APIs
* [[NetHubVirtualChannel|NetHubVirtualChannel.md]]
** current USER virtual-channel usage and limits

== Current Conclusions ==

* <code>SDIO</code> is the current in-tree reference path.
* <code>USB</code> device-side backend exists now and provides <code>ECM + ACM</code>.
* <code>SPI</code> is still a stub.
* <code>nethub</code> core exposes data-plane, control-path, and virtual-channel facades without directly depending on <code>ATModule</code>.
* The optional <code>ATModule + bflbwifid + bflbwifictrl</code> flow is an example composition, not a hard requirement for NetHub data-path use cases.

== In-Repo Reference Directories ==

* <code>examples/wifi/nethub</code>
* <code>components/net/nethub</code>
* <code>bsp/common/msg_router/linux_host/userspace/nethub</code>

== Local Documentation Source ==

The in-repo documentation source is:

* <code>examples/wifi/nethub/docs/</code>

== Online Wiki ==

* [https://docs.bouffalolab.com/index.php?title=NetHub NetHub]
* [https://docs.bouffalolab.com/index.php?title=NetHubQuickBringup NetHubQuickBringup]
* [https://docs.bouffalolab.com/index.php?title=NetHubArchitecture NetHubArchitecture]
* [https://docs.bouffalolab.com/index.php?title=NetHubVirtualChannel NetHubVirtualChannel]

DebuggingBouffaloLabChipsWithGDB

2026-04-10T01:05:38Z

张良：

= 通过CKLink调试DVK light开发板 =

==== 通过USB连接到PC ====

[[文件:BL616DVK Light CKLinkLite.jpg| 600像素 | BL616DVKLight_CKLinkLite]]

==== 进行GDB调试 ====

这里以Ubuntu为例，分别运行如下两条命令

<code>DebugServerConsole</code>

<code>riscv64-unknown-elf-gdb *.elf</code>

[[文件:BL616DVKLight_CKLinkLite.gif| BL616DVKLight_CKLinkLite]]

首页

2026-04-09T07:06:24Z

张良：

= Getting Started =

* [https://github.com/bouffalolab/bouffalo_sdk 如何获取SDK]
* [[如何在Ubuntu上搭建编译环境]]
* [[如何在Windows上搭建编译环境]]
* [[如何获取开发板]]
* [[烧录固件到开发板]]
* [[DebuggingBouffaloLabChipsWithGDB|如何调试博流开发板]]

= Bouffalo SDK =
'''BouffaloSDK''' 是 Bouffalo Lab 提供的 IOT 和 MCU 软件开发包，支持博流智能所有系列芯片，也是 '''bl_mcu_sdk''' 和 '''bl_iot_sdk''' 的结合体。

[[文件:BouffaloSDK.png|无框|600x600像素]]

= Peripherals =

{| border="0" cellpadding="10" width="100%"
|-
|width="32%" valign="top" align="left"|
*[[I2S]]
*[[I2C]]
*[[CVBS]]
*[[Watchdog]]
*[[GSM/GPRS]]
*[[Codec]]
*[[PCIe]]
*[[GPIO]]
*[[eMMC]]
|width="32%" valign="top" align="left"|
*[[WiFi]]
*[[LED]]
*[[Serial port]]
*[[PWM]]
*[[SPI]]
*[[USB OTG]]
*[[LCD]]
*[[CPU]]
*[[Network]]
|width="32%" valign="top" align="left"|
*[[Bluetooth]]
*[[HDMI]]
*[[Camera]]
*[[Memory]]
*[[RTC]]
*[[EEPROM]]
*[[MIPI-DSI]]
*[[NPU]]
*[[VPU]]
|}

= Products =
{| border="0" cellpadding="10" width="100%"
|-
|width="50%" valign="top" align="left"|
* [[BL602]]
* [[BL702]]
* [[BL618]]
* [[BL606P]]
|width="50%" valign="top" align="left"|
* [[BL702L]]
* [[BL616]]
|}

= Develop Boards =
* BL602EVB

= Application Notes =
* [[NetHub]]
* [[BL616低功耗开发手册]]
* [[USB Wi-Fi用户手册]]

= Demos =

{| border="0" cellpadding="10" width="100%"
|-
|width="32%" valign="top" align="left"|
*[[Demo:FreeRTOS]]
* [[Demo:wifi sta]]
* [[Demo:boot2_isp]]
* [[Demo:helloworld]]
* [[Demo:smartconfig ble]]
|width="32%" valign="top" align="left"|
*[[Demo:DMA]]
* [[Demo:Btble]]
* [[Demo:coremark]]
* [[Demo:littlefs]]
* [[Demo:posix freertos]]
|width="32%" valign="top" align="left"|
*[[Demo:Flash]]
* [[Demo:Basical case]]
* [[Demo:dsp]]
* [[Demo:cks]]
|}

使用GDB调试

2026-04-09T07:05:28Z

张良：张良移动页面使用GDB调试至DebuggingBouffaloLabChipsWithGDB

#重定向 [[DebuggingBouffaloLabChipsWithGDB]]

DebuggingBouffaloLabChipsWithGDB

2026-04-09T07:05:28Z

张良：张良移动页面使用GDB调试至DebuggingBouffaloLabChipsWithGDB

= 通过CKLink调试DVK light开发板 =

==== 通过USB连接到PC ====

[[文件:BL616DVK Light CKLinkLite.jpg| 600像素 | BL616DVKLight_CKLinkLite]]

==== 进行GDB调试 ====

这里以Ubuntu为例，此时应该可以看到 <code>/dev/ttyACM0</code> 设备（以实际为准）

分别运行如下两条命令

<code>DebugServerConsole</code>

<code>riscv64-unknown-elf-gdb *.elf</code>

[[文件:BL616DVKLight_CKLinkLite.gif| BL616DVKLight_CKLinkLite]]

DebuggingBouffaloLabChipsWithGDB

2026-04-09T07:03:23Z

张良：/* 进行GDB调试 */

DebuggingBouffaloLabChipsWithGDB

2026-04-09T07:02:34Z

张良：

= 通过CKLink调试DVK light开发板 =

==== 通过USB连接到PC ====

[[文件:BL616DVK Light CKLinkLite.jpg| 600像素 | BL616DVKLight_CKLinkLite]]

==== 进行GDB调试 ====

这里以Ubuntu为例，此时应该可以看到 <code>/dev/ttyACM0</code> 设备（以实际为准）
分别运行如下两条命令
<code>DebugServerConsole</code>
<code>riscv64-unknown-elf-gdb *.elf</code>

[[文件:BL616DVKLight_CKLinkLite.gif| BL616DVKLight_CKLinkLite]]

文件:BL616DVK Light CKLinkLite.jpg

2026-04-09T07:00:05Z

张良：BL616DVKLight_CKLinkLite.jpg

== 摘要 ==
BL616DVKLight_CKLinkLite.jpg

DebuggingBouffaloLabChipsWithGDB

2026-04-09T06:58:21Z

张良：

= 通过CKLink调试DVK light开发板 =

==== 通过USB连接到PC ====

[[文件:BL616DVK Light_CKLinkLite.jpg | BL616DVK Light_CKLinkLite]]

==== 进行GDB调试 ====

这里以Ubuntu为例，此时应该可以看到 <code>/dev/ttyACM0</code> 设备（以实际为准）
分别运行如下两条命令
<code>DebugServerConsole</code>
<code>riscv64-unknown-elf-gdb *.elf</code>

[[文件:BL616DVKLight_CKLinkLite.gif| BL616DVKLight_CKLinkLite]]

文件:BL616DVKLight CKLinkLite.gif

2026-04-09T06:57:24Z

张良：BL616DVKLight_CKLinkLite.gif

== 摘要 ==
BL616DVKLight_CKLinkLite.gif

DebuggingBouffaloLabChipsWithGDB

2026-04-09T06:55:42Z

张良：

文件:BL616DVK Light CKLinkLite.jpg.jpg

2026-04-09T06:54:55Z

张良：

BL616DVK Light_CKLinkLite.jpg

DebuggingBouffaloLabChipsWithGDB

2026-04-09T06:49:53Z

张良：创建页面，内容为“ 通过CKLink调试DVK light开发板”

通过CKLink调试DVK light开发板

Windows wsl bringup

2026-04-09T02:22:22Z

张良：

== 1. Build and Flash the Device Firmware ==

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

cd examples/wifi/nethub

''# BL616''
make CHIP=bl616 BOARD=bl616dk

''# BL616CL''
make CHIP=bl616cl BOARD=bl616cldk

''# BL618DG''
make CHIP=bl618dg BOARD=bl618dgdk CPU_ID=ap
Flash example:
cd examples/wifi/nethub
make flash CHIP=bl618dg COMX=/dev/ttyUSB0

make flash CHIP=bl616cl COMX=/dev/ttyUSB0

make flash CHIP=bl616cl COMX=COM5

export PATH=$HOME/work/toolchain_riscv_thead_linux64/bin:$PATH

Windows wsl bringup

2026-04-08T03:49:13Z

张良：/* 1. Build and Flash the Device Firmware */

== 1. Build and Flash the Device Firmware ==

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

cd examples/wifi/nethub

''# BL616''
make CHIP=bl616 BOARD=bl616dk

''# BL616CL''
make CHIP=bl616cl BOARD=bl616cldk

''# BL618DG''
make CHIP=bl618dg BOARD=bl618dgdk CPU_ID=ap
Flash example:
cd examples/wifi/nethub
make flash CHIP=bl618dg COMX=/dev/ttyUSB0

make flash CHIP=bl616cl COMX=/dev/ttyUSB0

make flash CHIP=bl616cl COMX=COM5

git clone git@code.bouffalolab.com:liangzhang/bouffalo_sdk_rel.git

git clone git@code.bouffalolab.com:bouffalo_sw/toolchain_riscv_thead_linux64.git

export PATH=$HOME/work/toolchain_riscv_thead_linux64/bin:$PATH

Windows wsl bringup

2026-04-08T03:45:27Z

张良：/* 2. Build and Flash the Device Firmware */

== 1. Build and Flash the Device Firmware ==
cd examples/wifi/nethub

''# BL616''
make CHIP=bl616 BOARD=bl616dk

''# BL616CL''
make CHIP=bl616cl BOARD=bl616cldk

''# BL618DG''
make CHIP=bl618dg BOARD=bl618dgdk CPU_ID=ap
Flash example:
cd examples/wifi/nethub
make flash CHIP=bl618dg COMX=/dev/ttyUSB0

make flash CHIP=bl616cl COMX=/dev/ttyUSB0

make flash CHIP=bl616cl COMX=COM5

git clone git@code.bouffalolab.com:liangzhang/bouffalo_sdk_rel.git

git clone git@code.bouffalolab.com:bouffalo_sw/toolchain_riscv_thead_linux64.git

export PATH=$HOME/work/toolchain_riscv_thead_linux64/bin:$PATH

Windows wsl bringup

2026-04-08T03:32:53Z

张良：

== 2. Build and Flash the Device Firmware ==
cd examples/wifi/nethub

''# BL616''
make CHIP=bl616 BOARD=bl616dk

''# BL616CL''
make CHIP=bl616cl BOARD=bl616cldk

''# BL618DG''
make CHIP=bl618dg BOARD=bl618dgdk CPU_ID=ap
Flash example:
cd examples/wifi/nethub
make flash CHIP=bl618dg COMX=/dev/ttyUSB0

make flash CHIP=bl616cl COMX=/dev/ttyUSB0

git clone git@code.bouffalolab.com:liangzhang/bouffalo_sdk_rel.git

git clone git@code.bouffalolab.com:bouffalo_sw/toolchain_riscv_thead_linux64.git

export PATH=$HOME/work/toolchain_riscv_thead_linux64/bin:$PATH

Windows wsl bringup

2026-04-08T03:30:36Z

张良：创建页面，内容为“ git clone git@code.bouffalolab.com:liangzhang/bouffalo_sdk_rel.git git clone git@code.bouffalolab.com:bouffalo_sw/toolchain_riscv_thead_linux64.git export PATH=$HOME/work/toolchain_riscv_thead_linux64/bin:$PATH”

git clone git@code.bouffalolab.com:liangzhang/bouffalo_sdk_rel.git

git clone git@code.bouffalolab.com:bouffalo_sw/toolchain_riscv_thead_linux64.git

export PATH=$HOME/work/toolchain_riscv_thead_linux64/bin:$PATH

烧录固件到开发板

2026-04-01T11:00:28Z

张良：/* 查看运行log */

= 如何烧录到DVK light开发板 =

==== 通过USB连接到PC ====

[[文件:BL616DVK Light.jpg | BL616DVK_light | 400px]]

这里以Ubuntu为例，此时应该可以看到 <code>/dev/ttyACM0</code> 设备（以实际为准）

==== 设备进入烧录模式 ====
按住 <code>BOOT</code> 键，trigger 一下 <code>reset</code> 按键，设备即进入烧录模式

==== 编译并烧录 ====
<pre>
cd examples/wifi/sta/wifi_tcp
make CHIP=bl616 BOARD=bl616dk
make flash CHIP=bl616 COMX=/dev/ttyACM0
</pre>

==== 查看运行log ====
通过串口终端查看运行的log即可，默认波特率2M（刚烧录完需要手动按一下Reset按键）

烧录固件到开发板

2026-04-01T10:59:24Z

张良：