hilinux-3599---设备学习---以及部署yolo

HiLinux 技术笔记

上电

工程师给的是 dc 12v，
然后记得是限流 1.5A

1. 设备与系统概览

该设备为典型 嵌入式 Linux 设备，常见于：

安防摄像头

视频编码 / 解码设备

工控盒

海思（HiSilicon）SoC 方案板

不属于 PC / 服务器，不用于通用计算。

1.2 操作系统

操作系统名称：

HiLinux（海思 HiSilicon SDK 定制嵌入式 Linux）

说明：

HiLinux 不是 Ubuntu / Debian / CentOS

是海思官方 SDK 提供的嵌入式 Linux 环境

基于 Linux 内核，但用户空间高度裁剪

1.3CPU 与硬件架构

aarch64
ARMv8-A

64 位架构

与 x86（Intel / AMD）完全不同

与手机、高端嵌入式设备同一体系

1.4 CPU 内核类型

cat /proc/cpuinfo

CPU architecture: 8
CPU part        : 0xd03

含义：

ARMv8

Cortex-A53

多核、低功耗

适合 7×24 小时运行

1.6Linux 内核信息

uname -r
输出：

text
复制代码
4.9.37

Linux 4.9

LTS（长期支持）内核

嵌入式领域常用，强调稳定性

1.7内核编译来源

cat /proc/version
关键内容：

text
复制代码
gcc version 6.3.0 (HC&C ...)
结论：

使用海思官方交叉编译工具链

系统由海思 SDK 构建

非个人或第三方刷机系统

1.8用户空间（BusyBox）

busybox
输出：

text
复制代码
BusyBox v1.26.2
说明：

BusyBox 是嵌入式系统常用工具集

一个可执行文件集成大量 Linux 命令

目的是：小体积、低依赖

BusyBox 带来的影响

项目 PC Linux HiLinux

shell bash ash

工具 GNU coreutils BusyBox

systemd 有 无

apt/yum 有 无

结论：

HiLinux 是"够用型 Linux"，不是"全功能 Linux"。

1.9登录方

| 方式     | 状态      |
| ------ | ------- |
| telnet | ✅ 可用    |
| ftp    | ✅ 可用    |
| ssh    | ❌ 默认关闭  |
| 串口     | ❌ 当前不可用 |

注意事项

刚开始登陆的时候，我是采用ssh 登陆但是一直不行，有个查找端口的方式。

nmap -p 1-65535 192.168.1.68

然后信息 总结

对 nmap 结果的工程级解读（结论先行）
21/tcp    open  ftp
23/tcp    open  telnet
53/tcp    open  domain
554/tcp   open  rtsp
31829/tcp open  unknown


这是一台典型的海思 / 安防 / 嵌入式 Linux 设备，并且：

✅ telnet 已开启（23） → 你可以直接拿 shell
✅ ftp 已开启（21） → 可以传文件 / 改配置
❌ SSH 未启（符合你之前的现象）

登陆方式

telnet 192.168.1.68

. 技术文档推荐标准描述（可直接使用）

本设备采用 HiLinux 嵌入式操作系统，基于 Linux 内核 4.9.37 定制开发，运行于 ARMv8-A（aarch64）64 位处理器平台。系统用户空间采用 BusyBox 工具集，通过海思官方 SDK 及 GCC 6.3.0 交叉编译工具链构建，适用于嵌入式视频与控制应用场景。

记录打开autorun的代码 它是一个可执行文件，可以利用vim打开ia

vim autorun 然后修改里面的 #./sample_vio 0

硬件与系统环境

SoC：HiSilicon Hi3559AV100

CPU 架构：AArch64

操作系统：HiLinux（glibc 2.24）

启动方式：eMMC + BusyBox 用户态

网络：eth0，静态 IP（192.168.1.68）

登录方式：telnet（无 ssh）

1.2 开发目标（阶段性）

验证 交叉编译工具链是否可用

验证 SDK 用户态 demo 是否能在板子上运行

验证 MPP / DPU / VB / SYS 等基础子系统是否正常

为后续 YOLOv5 / NNIE / DPU 推理部署打基础

SDK 与工具链准备情况

SDK 名称：Hi3559AV100_SDK_V2.0.3.1CP0002

MPP Sample 路径：

01.software/board/Hi3559AV100_SDK_V2.0.3.1CP0002/mpp/sample

2.2 交叉编译工具链（确认点）
which aarch64-himix100-linux-gcc
# /opt/hisi-linux/x86-arm/aarch64-himix100-linux/bin/aarch64-himix100-linux-gcc

aarch64-himix100-linux-gcc -v
# gcc version 6.3.0
# glibc 对应 2.24

工具链 ✔️

与板端 glibc 版本匹配 ✔️

可以直接用于 SDK sample 编译 ✔️

SDK Sample 成功编译

在 mpp/sample 下执行：

make linux

编译结果验证
find . -maxdepth 3 -type f -name "sample_*" -executable


发现大量可执行 demo，例如：

sample_vio

sample_dpu_main

sample_vdec

sample_venc

sample_ive

sample_hifb

SDK 在 PC 侧编译是完全成功的。

第一个大坑：文件传输失败（FTP / SCP / netcat）

初始错误现象

FTP put 文件时：

150 Ok to send data
netout: Connection reset by peer
451 Error


SCP：

ssh: connect to host 192.168.1.68 port 22: Connection refused


netcat：

cat sample_dpu_main | nc 192.168.1.68 12345
# 一直卡住

4.2 错误原因分析（重要）

板子没有 ssh 服务

FTP 默认是 ASCII 模式

网络稳定性一般

netcat 方式需要板端主动监听，且 BusyBox nc 功能有限

4.3 正确做法（最终方案）

唯一稳定方案：FTP + binary + passiv

PC 侧：

ftp 192.168.1.68
binary
passive
put sample_dpu_main


板端验证：

ls -lh sample_dpu_main
chmod +x sample_dpu_main

❌ 不要用 netcat 传可执行文件

❌ 不要用 ASCII FTP

✅ FTP + binary 是 HiLinux 下最稳方案

第二个大坑：程序"能跑但什么都没发生"

5.1 表现
./sample_dpu_main
ret=0


但：

没有输出

没有报错

什么都没做

5.2 根因
./sample_dpu_main
# Usage : sample_dpu_main <index>


这是一个带参数的 demo

正确用法

./sample_dpu_main 0

./sample_dpu_main 1

核心大坑：HI_MPI_VB_SetConf failed

[SAMPLE_COMM_SYS_Init]-370: HI_MPI_VB_SetConf failed!
program exit abnormally!

6.2 当时的误判（非常重要）

一开始错误认为是：

VB 配置错误

内存不足

demo bug

于是做了大量无效排查：

dmesg

lsmod

/proc/umap/vb

who opened /dev/vb

真正原因（关键结论）

板子开机后，autorun 自动启动了 sample_vio

证据链
ps


发现：

sample_vio_person

ls -l /proc/<pid>/fd


发现：

/dev/sys

/dev/vb

/dev/mmz_userdev

/dev/vi

/dev/vpss

👉 VB / SYS 已被占用

6.4 工程师给出的正确结论

把 autorun 里的 ./sample_vio 注释掉

autorun 机制认知纠正（重要）
7.1 错误认知

一开始以为：

autorun 是脚本

autorun 在 /etc/init.d

7.2 实际情况
find / -name autorun
# /app/autorun

ls -l /app/autorun
# 可执行 ELF 文件


autorun 是一个二进制程序，不是 shell 脚本

7.3 autorun 行为总结

开机自动运行

内部启动 sample_vio / sample_vio_person

持续占用：

/dev/sys

/dev/vb

/dev/mmz_userdev

ISP / VI / VPSS

这会导致任何后续 demo 初始化失败

8. 正确流程：关闭 autorun 后再跑 demo
8.1 操作策略

关闭 autorun 中的 sample_vio

或者不让 autorun 自动启动

重启板子

8.2 验证 VB 释放
cat /proc/umap/vb


确认：

pool 空闲

没有被 sample_vio 占用

sample_dpu_main 的真实作用说明

./sample_dpu_main <index>

index 含义

0 VI → VPSS → RECT → MATCH（实时摄像头）

1 FILE → RECT → MATCH（离线文件）

9.2 模式 0 失败原因（你没做错）
IMX477 I2C_WRITE error


原因：

传感器 I2C / 上电 / 型号不匹配

硬件级问题

与你当前目标无关

👉 不是软件 bug

又一个关键坑：DPU 文件模式缺数据

10.1 错误现象
open file ./data/input/lut/xxx.dat failed

10.2 原因

sample_dpu_main 1 强依赖 data 目录

SDK demo 不会自动生成 LUT

10.3 正确解决方案
PC 侧
cd mpp/sample/dpu
tar czvf dpu_data.tar.gz data

板端
ftp put dpu_data.tar.gz
tar xzvf dpu_data.tar.gz


保证路径结构：

./data/input/lut/

关键里程碑：sample_dpu_main 成功运行

成功表现

./sample_dpu_main 1

---------------press Enter key to exit!---------------

program exit normally!

这一步意味着什么（非常重要）

✅ 交叉编译产物可运行

✅ glibc / libstdc++ / 动态库匹配

✅ MPP 用户态 API 正常

✅ DPU / RECT / MATCH 可用

✅ 数据路径正确

为什么你会"懵逼"（正常，不是你菜）

根本原因总结

海思 SDK 假设你"已经是老用户"

autorun 默认启动 demo（非常反直觉）

demo 强依赖外部数据但不提示

错误码不直观（0xffffffff）

文档几乎不讲"运行时环境互斥关系"

👉 这是平台问题，不是你的问题

给未来自己的三条铁律（重点）

铁律 1：

任何 demo 跑之前，先确认没有别的 demo 占用 VB / SYS

ps

cat /proc/umap/vb

铁律 2：

海思 demo ≠ 单文件程序，必须检查 data / cfg / lut

铁律 3：

优先跑 FILE 模式，再跑 VI 模式

14. 当前状态总结（结论）

你现在已经完成了：

✅ SDK 编译

✅ 程序部署

✅ 运行环境验证

✅ DPU demo 跑通

✅ autorun 机制理解

你已经正式跨过"能不能跑 SDK"的门槛

下一步自然演进方向（仅列，不展开）

svp / nnie demo（最接近 YOLO）

FILE → NNIE 推理

ONNX → 海思模型

VI → VPSS → NNIE → OSD

如果你愿意，下一步我可以帮你直接做其中之一：

✅ 把 YOLOv5 映射到海思 NNIE/DPU 的完整路线图

✅ 教你怎么写一个"最小推理 demo"（不碰摄像头）

✅ 帮你整理 autorun / 系统启动控制方案

你只需要告诉我：下一步你想"干什么"，不是"怎么干"。

测试一个nnie sample里的demo

2.5 NNIE demo 验证：走到"空间不足 + 传输中断 + 模型缺失/截断"这一类问题
2.5.1 你找到了可执行的 NNIE demo

PC 端路径：mpp/sample/svp/multi-core/nnie/sample_nnie_main
并且该目录自带 data/nnie_model、data/nnie_image 等资源（很大）。

2.5.2 大文件传输踩坑：FTP 451 中断 / 板端 0 字节 / 根分区满

你尝试传 nnie_test.tar.gz（约 485MB）：

FTP 报过 451 Error

板端曾出现 0 字节 tar：tar: invalid magic / short read

根分区 / 一度 100%：/dev/root 991.9M Used 975.9M Avail 0

你做对的动作：

删除 /nnie_test.tar.gz 等大文件释放空间

df -h 回到约 50%（腾出 ~485MB）

关键经验：

根分区 1GB，装系统和组件后剩余空间非常有限

传 485MB 的压缩包 + 解压，会直接把空间打爆

即使压缩包能放下，也可能解压时空间不足

2.5.3 改用 lftp 传输更稳定，但仍受空间约束

lftp 能成功 put，但出现过：

一次传 1GB 多（明显重复 put、或断点/重传逻辑导致体积异常）

一次传 510MB

板端 tar -tzf 能列目录，说明"tar 文件整体可读"

但 tar -xzf 解压失败：No space left on device

2.5.4 关键突破：利用 tmpfs(/dev) 的 489MB 空间做"运行环境"

你注意到：

/dev 是 tmpfs，有 ~489MB 可用

你把 sample_nnie_main 和 data/ 放到了 /dev（或等价位置）

运行：

./sample_nnie_main 4（CNN）成功跑通

输出：

Svp mpi init ok!

Cnn Load model! ... Cnn result ...

Svp mpi exit ok!

说明：

NNIE 驱动/库/运行时 OK

demo 能正常加载模型并推理

tmpfs 跑法可行（至少对 CNN 这类相对轻量模型）

2.5.5 YOLO 分支失败（两种典型失败模式）

./sample_nnie_main 8（Yolov3）：

open model file failed

结论：模型路径/文件名不对，或模型文件不存在（更偏"缺文件"）

./sample_nnie_main 7（Yolov2）：

model_buf->size(...) is less than ...

结论：模型文件存在但被截断/不完整，或模型版本不匹配（更偏"文件损坏/不一致"）

今日 NNIE 结论：

CNN 已验证成功（证明 NNIE 通路可用）。

YOLO 失败不再是"环境/驱动问题"，而是"模型文件管理/一致性问题"。

根因高度可疑：之前传输中断、0字节 tar、磁盘满导致文件不完整；以及 sample 期望的模型文件名与实际不一致。

3. 今日你犯的典型错误（必须记录，避免明天重蹈覆辙）
错误 1：把"0 字节程序"当成可运行程序

现象：FTP 断线后仍去 chmod +x 并执行，看到 ret=0 就以为成功

正确做法：

任何传输后第一件事：ls -lh 看大小

必须大于 0 且接近 PC 端大小，再谈运行

错误 2：没有区分"demo 本体"和"data 依赖"

DPU FILE 模式依赖 ./data/input/lut/...

NNIE 大量依赖 ./data/nnie_model/...、./data/nnie_image/...

正确做法：

先 strings demo | grep data/ 或查看代码确认依赖

传输时按"最小运行集合"传（不是整包瞎传）

错误 3：没有先清理"系统自启占用进程"

你一开始在 VB 报错上反复挣扎，其实是被 /app/person/sample_vio_person 占用

正确做法：

第一步就应确认：

是否有 sample 在跑：ps | grep sample

谁打开了 /dev/vb：遍历 /proc/*/fd

先停掉占用，再跑自己的 demo

错误 4：在 1GB 根分区里强行传/解压 485MB 包

结果：反复满盘、tar 损坏、短读、重复传输

正确做法：

明确存储策略：rootfs 只存最小二进制；大数据走外部存储/NFS/或 tmpfs 分段

错误 5：传输工具混用，没有形成"标准流程"

ftp/tftp/nc/scp 混用导致排障噪声很大

正确做法：

统一成 1-2 个稳定工具（ftp 或 lftp）

每次传输都做校验（大小/MD5）

4. 今日已经达成的可复用成果（非常重要）

结论性状态

"autorun 已禁用，VB 资源不再被自启动程序抢占"（效果成立）

sample_dpu_main 1 在 /app/dpu_test（或等效目录）稳定运行（按你给的结论记录）

sample_nnie_main 4 (CNN) 在 /dev tmpfs 环境可运行（NNIE 通路可用）

已掌握的排障方法（可复用）

查 VB/SYS/MMZ 占用：/proc/*/fd 搜 /dev/vb /dev/sys /dev/mmz_userdev

查 VB 状态：cat /proc/umap/vb

查驱动/设备：lsmod、ls /dev、dmesg | tail

文件完整性快速判断：tar -tzf（只验证可读）、tar -xzf（验证可解）、md5sum（验证一致）

5. 问题清单与根因分析（给明天用的"定位地图"）
问题 A：HI_MPI_VB_SetConf failed

根因：自启动 sample（sample_vio_person 等）占用 VB/SYS/MMZ

解决：禁用 autorun / 停进程 / 保证板子空闲后再跑 demo

状态：已解决（至少你目前验证有效）

问题 B：sample_dpu_main 0 I2C 写寄存器失败

根因方向：传感器/硬件/I2C/设备树/驱动配置不匹配

解决方向：确认传感器型号、mipi/isp 配置、I2C 地址、板卡连接

状态：未解决（但非阻塞，因为 FILE 模式可跑）

问题 C：sample_dpu_main 1 LUT 文件缺失

根因：未携带 data 文件到正确相对路径

解决：打包/拷贝 data 目录到运行目录下，保持 ./data/... 结构

状态：已解决（能稳定运行）

问题 D：NNIE tar 包传输/解压失败

根因：根分区空间不足 + 传输中断/0 字节文件导致 tar 损坏

解决：

不再用大包全量解压到 /

使用 tmpfs /dev 或外部存储/NFS

只传最小运行集合（某个模型 + 某个 demo）

状态：部分解决（CNN 可跑；整体包解压仍受空间约束）

问题 E：YOLO demo 失败（NNIE）

Yolov3：open model file failed → 模型路径/文件名缺失

Yolov2：model_buf->size < ... → 模型文件截断/不完整或版本不匹配

状态：未解决，但根因范围已明确锁定在"模型文件管理/一致性"

文件挂载 解决内存问题 nfs

rootfs 满的问题定位与解决 Hi3559 的 / 只是系统盘，不能当开发盘用

两种解决办法：

一种就是挂载到运行内存上

tmpfs 的作用与使用

手动挂载：mount -t tmpfs tmpfs /tmp

特点：

在 DDR 中

重启即丢

适合小程序、临时文件

二种就是挂载到pc电脑上

NFS 作为工程开发盘（核心能力）

PC 端

✅ 第 1 步：在 PC 上准备 NFS 目录（必须）

在 PC（192.168.1.#） 上执行：

安装：

sudo mkdir -p /srv/nfs/hi3559
sudo chmod 777 /srv/nfs/hi3559

sudo apt install nfs-kernel-server

导出目录：

sudo vim /etc/exports
/srv/nfs/hi3559 192.168.1.0/24(rw,sync,no_root_squash,no_subtree_check)

/srv/nfs/hi3559 192.168.1.0/24(rw,sync,no_root_squash,no_subtree_check)

重载：

sudo exportfs -rav

第 4 步：确认 NFS 服务状态（PC 上）

sudo systemctl status nfs-kernel-server

第 5 步：在板子上"只测试，不挂载"（关键）

在 Hi3559 板子上执行：

showmount -e 192.168.1.#

✅ 正确结果应该是：

Export list for 192.168.1.100:

/srv/nfs/hi3559 192.168.1.0/24

⚠️ 如果这一步都不通，不要继续 mount

第 6 步：在板子上正式挂载（推荐参数）

板端

挂载：

mkdir -p /nfsroot

mount -t nfs -o vers=3,proto=udp,nolock 192.168.1.77:/srv/nfs/hi3559 /nfsroot

验证：

df -h /nfsroot
touch /nfsroot/test

重启后的必做两步

mount -t tmpfs tmpfs /tmp
mount -t nfs -o vers=3,proto=udp,nolock 192.168.1.77:/srv/nfs/hi3559 /nfsroot

NNIE 工程层面（核心

./sample_nnie_main <index>

4) Cnn(Read File)      ← MNIST 分类
5) SSD(Read File)
6) YOLOv1(Read File)
7) YOLOv2(Read File)
8) YOLOv3(Read File)
0) RFCN(VI->VPSS->NNIE->VGS->VO) ← 实时视频链路

上面这个是 hi3599的demo功能
截至现在 只测试了 minst分类功能
也就是4.

输入模型 图片

模型与输入路径锁定
模型
/nfsroot/data/nnie_model/classification/inst_mnist_cycle.wk

输入
/nfsroot/data/nnie_image/y/0_28x28.y


格式：

28 × 28

单通道

raw 灰度字节流（784 bytes）

NNIE 的 模型加载 → 输入喂入 → 推理 → 输出 blob 读取

因为：

0~9 类中只有一类是 4096

所以：

argmax(index) = 分类结果

只是 sample 没帮你封装成：

pred = 1

流程

NNIE 的典型执行流程（通用模板）

SYS / VB init
→ Load WK model
→ Param init
→ Fill input blob
→ NNIE_Forward
→ Read output blob
→ Post-process
→ SYS exit

这套流程对：

CNN
SSD
YOLO
LSTM
全部通用，只是：
输入格式不同
输出后处理复杂度不同

调试成功部署yolov3

平台：HiSilicon Hi3559 + NNIE

模型：YOLOv3（inst_yolov3_cycle.wk）

运行方式：Read File → NNIE → Software Postprocess

一、环境问题与解决方案：根文件系统空间不足

1.1 问题现象
/dev/root 100% used
tar: write error: No space left on device


板载 rootfs 只有 ~1GB，无法解压 NNIE 模型与样本。

1.2 解决方案：使用 NFS 作为运行目录

PC 端：

sudo mkdir -p /srv/nfs/hi3559
sudo chmod 777 /srv/nfs/hi3559


/etc/exports：

/srv/nfs/hi3559 *(rw,sync,no_root_squash,no_subtree_check)


刷新：

sudo exportfs -rav


板端：

mkdir -p /nfsroot
mount -t nfs -o vers=3,proto=udp,nolock 192.168.1.77:/srv/nfs/hi3559 /nfsroot

✅ 经验总结

NNIE sample 默认使用相对路径 ./data/...

必须在 /nfsroot 目录下运行程序

NFS 是嵌入式 AI 调试的标准方式

二、sample_nnie 工程结构解析

主入口：sample_nnie_main.c

int main(int argc, char *argv[])
{
    switch (*argv[1])
    {
        case '8':
            SAMPLE_SVP_NNIE_Yolov3();
            break;
    }
}

编译架构

编译结构来自 Makefile
SRCS += ./sample/*.c
SRCS += ./sample_nnie_software/*.c
SRCS += ../common/*.c


模块职责：

目录	作用
sample/	各网络流程（YOLO/CNN/SSD等）
sample_nnie_software/	后处理算法（TopN/NMS/Decode）
common/	SYS/VB/MMZ 初

YOLOv3 推理完整链路

函数：SAMPLE_SVP_NNIE_Yolov3()

3.1 输入与模型路径
pcSrcFile   = "./data/nnie_image/rgb_planar/dog_bike_car_416x416.bgr";
pcModelName = "./data/nnie_model/detection/inst_yolov3_cycle.wk";


说明：

输入为 BGR planar 格式

分辨率必须匹配网络输入尺寸（416x416）

推理流程分解

CheckSysInit()
LoadModel()
ParamInit()
FillSrcData()     ← 图像加载 + 预处理 + 拷贝
Forward()         ← NNIE 硬件推理
GetResult()       ← CPU 后处理（decode + NMS）
PrintResult()
Deinit()
CheckSysExit()

YOLOv3 冒烟测试结果判定标准

4.1 成功标志

日志包含：

Load model!

parameter initialization!

start!

result:

class box info

exit ok

==== The 17th class box info====
65 165 175 387 0.998291

4.2 类别映射（COCO）

sample 内已给出完整说明：

class 1: person
class 2: bicycle
class 3: car
...
class 17: dog


所以：

class 2 → bicycle

class 8 → truck

class 17 → dog

与测试图像内容完全一致，说明模型与后处理正确。