NetHubQuickBringup：修订间差异

来自Bouffalo Lab Docs
跳转到导航 跳转到搜索
←上一编辑下一编辑→
可视化wikitext
张良​（留言 | 贡献）
133次编辑
小 Sync NetHub docs from local Markdown
张良​（留言 | 贡献）
133次编辑
小 Sync NetHub docs from local Markdown (2026-04-24)
第1行： 第1行：
= NetHub Quick Start =
= NetHub Quick Start =


This document is for customers who are using NetHub for the first time. The goal is to help you complete device and host bring-up as quickly as possible.
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]]
[[文件:Nethub_sdio_quickstart_demo.gif | NetHub SDIO Quick Start Demo]]


If you only care about the currently available solution, keep these points in mind:
== 1. Start with the Current Support Matrix ==
 
* The current primary path is <code>SDIO</code>
* The device runs <code>Wi-Fi backend (fhost / wl80211) + lwIP</code>
* <code>nethub</code> bridges device-side Wi-Fi capabilities to the host
* The control channel and <code>USER virtual channel</code> both run on the same host link
 
Active directories:
 
* device side
** <code>components/net/nethub</code>
** <code>examples/wifi/nethub</code>
* host side
** <code>bsp/common/msg_router/linux_host/kernel</code>
** <code>bsp/common/msg_router/linux_host/userspace/nethub</code>
 
== 1. Confirm Two Choices Before Bring-Up ==
 
=== 1.1 Choose the Wi-Fi Backend ===
 
Default configuration:
 
* <code>CONFIG_WL80211</code> is disabled
* <code>fhost</code> is used
 
If you want to switch to <code>wl80211</code>, enable this option 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
* The current <code>nethub</code> implementation supports both device-side Wi-Fi backends
 
=== 1.2 Choose the Control Channel ===
 
device and host settings must match:


{| class="wikitable"
{| class="wikitable"
|-
|-
! device configuration !! host startup
! 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>
|-
|-
| <code>CONFIG_NETHUB_AT_USE_VCHAN=n</code> || <code>./output/bflbwifid</code> or <code>./output/bflbwifid -c tty -p /dev/ttyAT0</code>
| Optional AT control solution || available, but not required for data-only use cases
|-
|-
| <code>CONFIG_NETHUB_AT_USE_VCHAN=y</code> || <code>./output/bflbwifid -c vchan</code>
| Low power || currently <code>BL618DG</code> only
|}
|}


The default configuration is:
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


<syntaxhighlight lang="makefile">
== 2. Decide Whether You Need Only Data or Data Plus Control ==
CONFIG_NETHUB_AT_USE_VCHAN=n
</syntaxhighlight>


That means the control channel uses <code>TTY</code> by default.
NetHub core always focuses on the data plane first.


Additional notes:
* 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 host side always builds both <code>tty + vchan</code>
The important boundary is:
* The actual selection happens at <code>bflbwifid</code> runtime


== 2. Build and Flash the Device Firmware ==
* <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


<syntaxhighlight lang="bash">
== 3. Choose the Host-Link Profile ==
cd examples/wifi/nethub


# BL616
The profile is selected at build time through exactly one <code>CONFIG_NETHUB_PROFILE_*</code> option.
make CHIP=bl616 BOARD=bl616dk


# BL616CL
=== 3.1 SDIO ===
make CHIP=bl616cl BOARD=bl616cldk


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


Flash example:
What you get:


<syntaxhighlight lang="bash">
* current in-tree reference data path
cd examples/wifi/nethub
* current in-tree host Linux stack
make flash CHIP=bl618dg COMX=/dev/ttyUSB0
* current in-tree USER virtual-channel path
</syntaxhighlight>


The most relevant bring-up configuration is located in:
=== 3.2 USB ===


* <code>examples/wifi/nethub/defconfig</code>
Use this when you specifically want the device-side USB backend.


Common options:
Current device-side behavior:


* <code>CONFIG_NETHUB=y</code>
* data path through <code>USB CDC ECM</code>
* <code>CONFIG_MR_NETDEV=y</code>
* control transport plumbing through <code>USB CDC ACM</code>
* <code>CONFIG_MR_TTY=y</code>
* <code>CONFIG_MR_VIRTUALCHAN=y</code>
* <code>CONFIG_NETHUB_AT_USE_VCHAN=n</code>


== 3. Build and Start the Host Software ==
Current limitation:


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


<syntaxhighlight lang="bash">
=== 3.3 SPI ===
cd bsp/common/msg_router/linux_host/userspace/nethub
./build.sh build
</syntaxhighlight>


Artifacts:
Not implemented yet.


* <code>output/mr_sdio.ko</code>
== 4. Choose the Wi-Fi Backend ==
* <code>output/bflbwifid</code>
* <code>output/bflbwifictrl</code>
* <code>output/libnethub_vchan.a</code>
* <code>output/nethub_vchan_app</code>


=== 3.2 Load the Kernel Module ===
Default configuration:


<syntaxhighlight lang="bash">
* <code>CONFIG_WL80211</code> disabled
cd bsp/common/msg_router/linux_host/userspace/nethub
* <code>fhost</code> selected
sudo ./build.sh load
</syntaxhighlight>


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


<syntaxhighlight lang="bash">
<syntaxhighlight lang="makefile">
sudo ./build.sh unload
CONFIG_WL80211=y
</syntaxhighlight>
</syntaxhighlight>


=== 3.3 Start the Host Daemon ===
Notes:


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


<syntaxhighlight lang="bash">
== 5. Device Build and Flash ==
sudo ./output/bflbwifid
</syntaxhighlight>


Explicit TTY mode:
Build:


<syntaxhighlight lang="bash">
<syntaxhighlight lang="bash">
sudo ./output/bflbwifid -c tty -p /dev/ttyAT0
cd examples/wifi/nethub
</syntaxhighlight>


VCHAN mode:
# BL616
make CHIP=bl616 BOARD=bl616dk


<syntaxhighlight lang="bash">
# BL616CL
sudo ./output/bflbwifid -c vchan
make CHIP=bl616cl BOARD=bl616cldk
</syntaxhighlight>


== 4. Basic Verification Flow ==
# BL618DG
 
make CHIP=bl618dg BOARD=bl618dgdk CPU_ID=ap
Recommended sequence:
 
=== 4.1 Check the Current Status ===
 
<syntaxhighlight lang="bash">
sudo ./output/bflbwifictrl status
</syntaxhighlight>
</syntaxhighlight>


=== 4.2 Scan APs ===
Flash example:


<syntaxhighlight lang="bash">
<syntaxhighlight lang="bash">
sudo ./output/bflbwifictrl scan
cd examples/wifi/nethub
make flash CHIP=bl618dg COMX=/dev/ttyUSB0
</syntaxhighlight>
</syntaxhighlight>


=== 4.3 Connect to an AP ===
== 6. Important Configuration Switches ==


<syntaxhighlight lang="bash">
Main configuration file:
sudo ./output/bflbwifictrl connect_ap "<ssid>" "<password>"
</syntaxhighlight>


=== 4.4 Check Status Again ===
* <code>examples/wifi/nethub/defconfig</code>


<syntaxhighlight lang="bash">
Important switches:
sudo ./output/bflbwifictrl status
</syntaxhighlight>


If the connection succeeds, you will usually see:
* <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>


* the backend is connected
About <code>CONFIG_NETHUB_AT_USE_VCHAN</code>:
* the Wi-Fi state is <code>CONNECTED</code> or <code>GOTIP</code>
* <code>IP / Gateway / Netmask / DNS</code> after an address is assigned


=== 4.5 Disconnect ===
* 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


<syntaxhighlight lang="bash">
Current default example facts:
sudo ./output/bflbwifictrl disconnect
</syntaxhighlight>


== 5. Common Commands ==
* <code>CONFIG_NETHUB_PROFILE_SDIO=y</code>
 
* <code>CONFIG_NETHUB_PROFILE_USB=n</code>
The public CLI surface is fixed to 9 commands:
* <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>


* <code>connect_ap</code>
== 7. Hardware Interface Pins ==
* <code>disconnect</code>
* <code>scan</code>
* <code>status</code>
* <code>version</code>
* <code>reboot</code>
* <code>ota</code>
* <code>start_ap</code>
* <code>stop_ap</code>


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


<syntaxhighlight lang="bash">
Reference sources in the repository:
sudo ./output/bflbwifictrl version
sudo ./output/bflbwifictrl reboot
sudo ./output/bflbwifictrl start_ap "<ssid>" "<password>"
sudo ./output/bflbwifictrl stop_ap
</syntaxhighlight>


== 6. SDIO Hardware Information ==
* 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>


For the current customer bring-up path, use <code>SDIO</code> directly. <code>USB / SPI</code> still keep architecture skeletons for now and are not the recommended bring-up path.
=== 7.1 Default SDIO Pins ===


=== 6.1 Chip Support Matrix ===
These are the current <code>board_sdh_gpio_init()</code> mappings used by the BSP.


{| class="wikitable"
{| class="wikitable"
|-
|-
! Interface !! BL616 / BL618 !! BL618DG !! BL616CL
! 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>
|-
|-
| SDIO || Supported || Supported || Supported
| <code>SDIO_CLK</code> || <code>GPIO13</code> || <code>GPIO46</code> || <code>GPIO9</code>
|-
|-
| USB || Planned || Planned || Planned
| <code>SDIO_DAT0</code> || <code>GPIO14</code> || <code>GPIO47</code> || <code>GPIO10</code>
|-
|-
| SPI || Planned || Planned || Planned
| <code>SDIO_DAT1</code> || <code>GPIO15</code> || <code>GPIO48</code> || <code>GPIO11</code>
|}
|}


=== 6.2 SDIO Pins ===
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"
{| class="wikitable"
|-
|-
! Pin Function !! BL616 / BL618 !! BL618DG !! BL616CL
! Chip / Board family !! Default USB pins in current BSP !! Current BSP behavior !! Notes
|-
|-
| SDIO_DAT2 || GPIO10 || GPIO43 || GPIO6
| 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
|-
|-
| SDIO_DAT3 || GPIO11 || GPIO44 || GPIO7
| 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
|-
|-
| SDIO_CMD || GPIO12 || GPIO45 || GPIO8
| 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
|-
| SDIO_CLK || GPIO13 || GPIO46 || GPIO9
|-
| SDIO_DATA0 || GPIO14 || GPIO47 || GPIO10
|-
| SDIO_DATA1 || GPIO15 || GPIO48 || GPIO11
|}
|}
== 7. USER Virtual Channel ==
If you need to transfer private messages between the host and device, use the <code>USER virtual channel</code>.


Notes:
Notes:


* The <code>USER</code> channel and the control channel are parallel logical channels
* 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>
* It is not a separate physical interface; it is a logical channel carried on the current host link
* 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
=== 7.1 device-side APIs ===
 
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>
 
=== 7.2 host-side APIs ===
 
Header:
 
* <code>bsp/common/msg_router/linux_host/userspace/nethub/virtualchan/nethub_vchan.h</code>
 
Common APIs:
 
<syntaxhighlight lang="c">
int nethub_vchan_init(void);
int nethub_vchan_deinit(void);


int nethub_vchan_user_send(const void *data, size_t len);
== 8. Host Bring-Up Guidance ==
int nethub_vchan_user_register_callback(nethub_vchan_recv_callback_t callback);


int nethub_vchan_get_state_snapshot(nethub_vchan_state_snapshot_t *snapshot);
For the current in-tree host Linux reference stack, use:
</syntaxhighlight>


Typical host-side usage order:
* <code>bsp/common/msg_router/linux_host/userspace/nethub/README.md</code>


# <code>nethub_vchan_init()</code>
Today that host stack is primarily the <code>SDIO</code> reference flow.
# <code>nethub_vchan_user_register_callback()</code>
# <code>nethub_vchan_user_send()</code>
# Call <code>nethub_vchan_deinit()</code> when finished


If you need to check whether the link is ready, you can optionally query:
For USB projects, keep expectations aligned with current code status:


* <code>link_state == NETHUB_VCHAN_LINK_UP</code>
* device-side <code>ECM + ACM</code> backend exists
** the link is ready for TX/RX
* host-side transport flattening into the same <code>nethub_vchan</code> behavior as SDIO is not fully documented or aligned in-tree yet
* <code>host_state == NETHUB_VCHAN_HOST_STATE_DEVICE_RUN</code>
** the host has completed the handshake with the device


== 8. Common Issues ==
== 9. USER Virtual Channel Guidance ==


=== 8.1 <code>bflbwifid</code> Fails to Start ===
If you need private application messages between host and device:


Check first:
* 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>


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


=== 8.2 <code>connect_ap</code> Succeeds but the Host Has No Network Access ===
* 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


Check first:
== 10. Low-Power Note ==


* whether <code>status</code> has reached <code>GOTIP</code>
<code>CONFIG_NETHUB_LOWPOWER_ENABLE</code> is currently supported only on <code>BL618DG</code>. The example configuration automatically disables it on other chips.
* whether <code>mr_eth0</code> has an address
* whether services such as <code>NetworkManager</code> or <code>dhcpcd</code> override the NetHub configuration


Notes:
== 11. Where to Go Next ==
 
* <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>
 
=== 8.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
 
=== 8.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>:
 
<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
* overall entry: [[NetHub|NetHub.md]]
* Rebuild the host software after the change and reload the host-side kernel module
* architecture: [[NetHubArchitecture|NetHubArchitecture.md]]
* If any local scripts or service configuration still refer to <code>mr_eth0</code>, update them accordingly
* USER virtual channel: [[NetHubVirtualChannel|NetHubVirtualChannel.md]]

2026年4月24日 (五) 13:48的版本

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 Quick Start Demo

1. Start with the Current Support Matrix

Item Current status
Recommended end-to-end reference path SDIO
USB profile device-side backend implemented with USB ECM + USB ACM
SPI profile not implemented
USER virtual channel current in-tree end-to-end path is SDIO
Optional AT control solution available, but not required for data-only use cases
Low power currently BL618DG only

Read this table literally:

  • if you want the shortest successful path today, choose SDIO
  • if you are evaluating the new USB device-side backend, focus on the device profile and USB descriptors first
  • do not plan on SPI 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 nethub
    • do not depend on ATModule
    • host users simply use the exposed netdev path
  • data plus AT-style control products
    • optionally enable the example composition built around ATModule + bflbwifid + bflbwifictrl

The important boundary is:

  • nethub core does not directly depend on ATModule
  • ATModule 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 CONFIG_NETHUB_PROFILE_* 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 USB CDC ECM
  • control transport plumbing through USB CDC ACM

Current limitation:

  • the in-tree host Linux docs and nethub_vchan wrapper are still centered on the SDIO reference path

3.3 SPI

Not implemented yet.

4. Choose the Wi-Fi Backend

Default configuration:

  • CONFIG_WL80211 disabled
  • fhost selected

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

CONFIG_WL80211=y

Notes:

  • fhost and wl80211 are mutually exclusive
  • current NetHub supports both device-side Wi-Fi backends

5. Device Build and Flash

Build: 

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

6. Important Configuration Switches

Main configuration file:

  • examples/wifi/nethub/defconfig

Important switches:

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

About CONFIG_NETHUB_AT_USE_VCHAN:

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

  • CONFIG_NETHUB_PROFILE_SDIO=y
  • CONFIG_NETHUB_PROFILE_USB=n
  • CONFIG_NETHUB_CTRLCHANNEL_USE_ATMODULE=y
  • CONFIG_MR_VIRTUALCHAN=y
  • CONFIG_NETHUB_AT_USE_VCHAN=n
  • CONFIG_MR_TTY=n

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
    • bsp/board/bl616dk/board_gpio.c
    • bsp/board/bl616cldk/board_gpio.c
    • bsp/board/bl618dgdk/board_gpio.c

7.1 Default SDIO Pins

These are the current board_sdh_gpio_init() mappings used by the BSP.

Pin Function BL616 / BL618 (bl616dk) BL618DG (bl618dgdk) BL616CL (bl616cldk)
SDIO_DAT2 GPIO10 GPIO43 GPIO6
SDIO_DAT3 GPIO11 GPIO44 GPIO7
SDIO_CMD GPIO12 GPIO45 GPIO8
SDIO_CLK GPIO13 GPIO46 GPIO9
SDIO_DAT0 GPIO14 GPIO47 GPIO10
SDIO_DAT1 GPIO15 GPIO48 GPIO11

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.

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

Notes:

  • for BL616CL and BL618DG, the BSP helper only tells us the USB pair used by the board, not which pin is D+ and which pin is D-
  • if you are wiring a custom board and need explicit DP / DM 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:

  • bsp/common/msg_router/linux_host/userspace/nethub/README.md

Today that host stack is primarily the SDIO reference flow.

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

  • device-side ECM + ACM backend exists
  • host-side transport flattening into the same nethub_vchan 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: components/net/nethub/include/nethub_vchan.h
  • host API: bsp/common/msg_router/linux_host/userspace/nethub/virtualchan/nethub_vchan.h

Current reality:

  • end-to-end in-tree USER virtual channel is the SDIO 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

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

11. Where to Go Next

检索自“https://docs.bouffalolab.com/index.php?title=NetHubQuickBringup&oldid=280”