文章目录1.镜像根文件系统1.镜像根文件系统一、核心概念对照表概念定义举例类比根文件系统Linux 运行时挂载的/目录树是内容/bin、/etc、/opt/camera书的内容镜像存储介质的逐字节副本是一个文件sdcard.img、rootfs.img书的影印件固件固化在芯片里的程序单片机 hex、路由器系统硬件里刻的字烧录把镜像写入存储介质dd ifxxx.img of/dev/mmcblk0复印量产把原型方案批量复制到多台设备生产线批量烧录批量印刷二、MCU 与 MPU 的本质区别维度单片机MCU微处理器MPU跑 Linux运行内容只有一个程序Bootloader Kernel 根文件系统 多个服务启动流程复位 → 执行main()BootROM → SPL → U-Boot → Kernel → systemd → 你的服务量产方式烧录 hex/bin 到 Flash制作整机镜像批量写入 eMMC/SD用户程序形态就是整个程序是系统里的一个服务差异化一般无每台设备需唯一 token/序列号/MAC关键结论MCU 烧程序MPU 烧系统 服务。三、Linux 启动与自启动机制3.1 完整启动链路芯片复位 ↓ BootROM芯片固化无法修改 ↓ SPL二级引导很小 ↓ U-Boot大引导加载内核 ↓ Kernel加载驱动、挂载根文件系统 ↓ init / systemdPID1总调度器 ↓ systemd 读取所有 .service 文件 ↓ camera.service 被触发 → 执行 start_camera.sh ↓ 启动 mediamtx / frpc / ffmpeg3.2 为什么 .service 能自动运行systemd 启动时扫描/etc/systemd/system/等目录下的.service文件。执行systemctl enable camera.service时systemd 在/etc/systemd/system/multi-user.target.wants/下创建一个软链接。开机进入multi-user.target时systemd 会启动所有被想要Wanted的服务。WantedBymulti-user.target就是告诉 systemd“我要跟着多用户模式一起启动”。本质enable 创建软链接。3.3 为什么不能用 rc.local对比项rc.localsystemd依赖管理无靠sleep硬等声明After、Wants自动排序崩溃重启无Restarton-failure自动拉起日志需自己重定向journalctl统一管理并行启动串行慢并行快量产可控性弱强结论rc.local 是玩具systemd 是产品。四、你的项目架构回顾4.1 数据流向USB摄像头 → FFmpeg(H.264编码) → MediaMTX(本机RTSP) → frpc(内网穿透) → 阿里云服务器(frps) → 手机VLC远程拉流4.2 目录结构原型阶段/home/baiwen/video1/ ├── mediamtx # MediaMTX 可执行文件 ├── mediamtx.yml # MediaMTX 配置 ├── frp_0.71.0_linux_arm64/ # FRP 客户端目录 │ ├── frpc │ └── frpc.toml ├── start_camera.sh # 开机自启脚本 └── camera.log # 运行日志4.3 三个关键文件文件作用位置start_camera.sh启动脚本负责依次拉起三个服务/home/baiwen/video1/camera.servicesystemd 服务定义实现开机自启/etc/systemd/system/frpc.tomlFRP 客户端配置含 token/home/baiwen/video1/frp_xxx/五、从原型到量产四个阶段阶段 1原型验证你现在做法手动配置逐台操作装系统拷贝文件到/home/baiwen/video1/写camera.servicesystemctl enable重启验证特点能跑通但不能批量复制。阶段 2小批量试产5~20 台做法SD 卡克隆 手动改 token在一台样机上配好所有东西用dd把 SD 卡做成.img每台烧完后手动 SSH 改frpc.toml的 token验证硬件和软件一致性# 制作镜像ddif/dev/mmcblk0ofsdcard.imgbs4M# 烧录到新卡ddifsdcard.imgof/dev/mmcblk0bs4M缺点手动改 token效率低易出错。阶段 3中批量100 台以上做法定制镜像 first-boot 自动化用Yocto或Buildroot定制精简根文件系统把mediamtx、frpc、脚本、camera.service直接编入镜像用厂商烧录工具如 RKDevTool、uuu批量烧录 eMMC首次启动运行first-boot.service自动个性化first-boot 脚本要做的事#!/bin/bash# 1. 生成唯一 tokenTOKEN$(openssl rand-hex16)# 2. 生成唯一序列号用 MAC 地址SERIAL$(cat/sys/class/net/eth0/address|tr-d:)# 3. 从模板生成配置文件seds/__TOKEN__/$TOKEN//opt/camera/frpc.toml.template/etc/frp/frpc.toml# 4. 设置唯一主机名echocamera-$SERIAL/etc/hostname# 5. 自我禁用只跑一次systemctl disable first-boot.service阶段 4正式产品做法CI/CD OTA 升级Yocto/Buildroot做完整构建流水线代码提交 → 自动编译 → 生成镜像镜像里预置应用打包成.deb或放到/opt/systemd 服务RAUC / SWUpdate做 OTA 升级框架A/B 分区方案升级失败可回滚生产线用夹具 自动化工具烧录写入序列号、MAC、密钥出厂后通过 OTA 推送更新六、量产镜像里应该装什么6.1 完整交付包结构你的应用包/ ├── opt/camera/ # 应用目录 │ ├── mediamtx # 可执行文件 │ ├── mediamtx.yml # 配置 │ ├── frpc # FRP 客户端 │ ├── frpc.toml.template # 配置模板token 留空首启时填 │ └── start_camera.sh # 启动脚本 ├── etc/systemd/system/ │ ├── camera.service # 服务定义 │ └── first-boot.service # 首启个性化服务 └── etc/first-boot.d/ └── 01-personalize.sh # 个性化脚本6.2 关键点项目原型阶段量产阶段token硬编码在 frpc.toml用模板 首启生成主机名手动设置用 MAC 地址自动生成服务启动手动systemctl start编入镜像开机自动升级方式手动 SSH 替换OTA 推送七、打包方式对比方式适合场景做法直接拷贝到 rootfs自己维护镜像放进 Yocto/Buildroot 的recipes或overlay打成.deb包Debian/Ubuntudpkg-deb --build生成安装自动放好服务Docker 容器应用隔离应用做成镜像宿主 systemd 拉起容器只读分区防篡改根文件系统只读应用分区单独可写八、镜像 vs 根文件系统核心区别维度根文件系统镜像本质目录树内容文件副本运行时是活的被挂载使用是死的只能被读写包含关系是镜像的一部分可以包含根文件系统路径/xxx.img制作方式用cp、dpkg填充用dd、mkfs、mksquashfs生成使用方式挂载后直接访问用dd写入存储介质类比书的内容书的影印件一句话根文件系统是 Linux 运行时看到的/镜像是把它打包成的.img文件。九、术语速查表术语含义类比镜像 (Image)存储介质的逐字节副本书的影印件根文件系统 (rootfs)Linux 运行时的/目录树书的内容固件 (Firmware)固化在芯片里的程序硬件里刻的字Bootloader启动引导程序U-Boot电脑的 BIOSKernelLinux 内核操作系统的心脏systemdLinux 的总调度器PID1工厂的调度中心Servicesystemd 管理的服务单元工厂里的一条产线烧录把镜像写入存储介质复印量产批量复制到多台设备批量印刷OTA空中升级手机系统更新A/B 分区双分区互为备份升级失败可回滚双系统启动first-boot首次启动时运行的个性化脚本新手机开机设置十、给你的下一步建议当前状态原型验证完成 ✅短期目标如果你想做几台设备自用在一台样机上配好所有东西用dd做成.img每台烧完后手动改 token验证一致性中期目标如果想做小批量产品学 Yocto 或 Buildroot做定制镜像写first-boot.sh做自动化个性化用厂商烧录工具批量写入长期目标如果要做正式产品引入 OTA 升级框架A/B 分区支持失败回滚云端设备管理十一、一句话总结整个项目你做的不是烧一个程序而是部署一个系统。镜像是打包方式根文件系统是运行内容systemd 服务是启动机制first-boot是个性化方案OTA是升级方案。这五点就是嵌入式 Linux 产品化的全部骨架。
文章目录1.镜像根文件系统1.镜像根文件系统一、核心概念对照表概念定义举例类比根文件系统Linux 运行时挂载的/目录树是内容/bin、/etc、/opt/camera书的内容镜像存储介质的逐字节副本是一个文件sdcard.img、rootfs.img书的影印件固件固化在芯片里的程序单片机 hex、路由器系统硬件里刻的字烧录把镜像写入存储介质dd ifxxx.img of/dev/mmcblk0复印量产把原型方案批量复制到多台设备生产线批量烧录批量印刷二、MCU 与 MPU 的本质区别维度单片机MCU微处理器MPU跑 Linux运行内容只有一个程序Bootloader Kernel 根文件系统 多个服务启动流程复位 → 执行main()BootROM → SPL → U-Boot → Kernel → systemd → 你的服务量产方式烧录 hex/bin 到 Flash制作整机镜像批量写入 eMMC/SD用户程序形态就是整个程序是系统里的一个服务差异化一般无每台设备需唯一 token/序列号/MAC关键结论MCU 烧程序MPU 烧系统 服务。三、Linux 启动与自启动机制3.1 完整启动链路芯片复位 ↓ BootROM芯片固化无法修改 ↓ SPL二级引导很小 ↓ U-Boot大引导加载内核 ↓ Kernel加载驱动、挂载根文件系统 ↓ init / systemdPID1总调度器 ↓ systemd 读取所有 .service 文件 ↓ camera.service 被触发 → 执行 start_camera.sh ↓ 启动 mediamtx / frpc / ffmpeg3.2 为什么 .service 能自动运行systemd 启动时扫描/etc/systemd/system/等目录下的.service文件。执行systemctl enable camera.service时systemd 在/etc/systemd/system/multi-user.target.wants/下创建一个软链接。开机进入multi-user.target时systemd 会启动所有被想要Wanted的服务。WantedBymulti-user.target就是告诉 systemd“我要跟着多用户模式一起启动”。本质enable 创建软链接。3.3 为什么不能用 rc.local对比项rc.localsystemd依赖管理无靠sleep硬等声明After、Wants自动排序崩溃重启无Restarton-failure自动拉起日志需自己重定向journalctl统一管理并行启动串行慢并行快量产可控性弱强结论rc.local 是玩具systemd 是产品。四、你的项目架构回顾4.1 数据流向USB摄像头 → FFmpeg(H.264编码) → MediaMTX(本机RTSP) → frpc(内网穿透) → 阿里云服务器(frps) → 手机VLC远程拉流4.2 目录结构原型阶段/home/baiwen/video1/ ├── mediamtx # MediaMTX 可执行文件 ├── mediamtx.yml # MediaMTX 配置 ├── frp_0.71.0_linux_arm64/ # FRP 客户端目录 │ ├── frpc │ └── frpc.toml ├── start_camera.sh # 开机自启脚本 └── camera.log # 运行日志4.3 三个关键文件文件作用位置start_camera.sh启动脚本负责依次拉起三个服务/home/baiwen/video1/camera.servicesystemd 服务定义实现开机自启/etc/systemd/system/frpc.tomlFRP 客户端配置含 token/home/baiwen/video1/frp_xxx/五、从原型到量产四个阶段阶段 1原型验证你现在做法手动配置逐台操作装系统拷贝文件到/home/baiwen/video1/写camera.servicesystemctl enable重启验证特点能跑通但不能批量复制。阶段 2小批量试产5~20 台做法SD 卡克隆 手动改 token在一台样机上配好所有东西用dd把 SD 卡做成.img每台烧完后手动 SSH 改frpc.toml的 token验证硬件和软件一致性# 制作镜像ddif/dev/mmcblk0ofsdcard.imgbs4M# 烧录到新卡ddifsdcard.imgof/dev/mmcblk0bs4M缺点手动改 token效率低易出错。阶段 3中批量100 台以上做法定制镜像 first-boot 自动化用Yocto或Buildroot定制精简根文件系统把mediamtx、frpc、脚本、camera.service直接编入镜像用厂商烧录工具如 RKDevTool、uuu批量烧录 eMMC首次启动运行first-boot.service自动个性化first-boot 脚本要做的事#!/bin/bash# 1. 生成唯一 tokenTOKEN$(openssl rand-hex16)# 2. 生成唯一序列号用 MAC 地址SERIAL$(cat/sys/class/net/eth0/address|tr-d:)# 3. 从模板生成配置文件seds/__TOKEN__/$TOKEN//opt/camera/frpc.toml.template/etc/frp/frpc.toml# 4. 设置唯一主机名echocamera-$SERIAL/etc/hostname# 5. 自我禁用只跑一次systemctl disable first-boot.service阶段 4正式产品做法CI/CD OTA 升级Yocto/Buildroot做完整构建流水线代码提交 → 自动编译 → 生成镜像镜像里预置应用打包成.deb或放到/opt/systemd 服务RAUC / SWUpdate做 OTA 升级框架A/B 分区方案升级失败可回滚生产线用夹具 自动化工具烧录写入序列号、MAC、密钥出厂后通过 OTA 推送更新六、量产镜像里应该装什么6.1 完整交付包结构你的应用包/ ├── opt/camera/ # 应用目录 │ ├── mediamtx # 可执行文件 │ ├── mediamtx.yml # 配置 │ ├── frpc # FRP 客户端 │ ├── frpc.toml.template # 配置模板token 留空首启时填 │ └── start_camera.sh # 启动脚本 ├── etc/systemd/system/ │ ├── camera.service # 服务定义 │ └── first-boot.service # 首启个性化服务 └── etc/first-boot.d/ └── 01-personalize.sh # 个性化脚本6.2 关键点项目原型阶段量产阶段token硬编码在 frpc.toml用模板 首启生成主机名手动设置用 MAC 地址自动生成服务启动手动systemctl start编入镜像开机自动升级方式手动 SSH 替换OTA 推送七、打包方式对比方式适合场景做法直接拷贝到 rootfs自己维护镜像放进 Yocto/Buildroot 的recipes或overlay打成.deb包Debian/Ubuntudpkg-deb --build生成安装自动放好服务Docker 容器应用隔离应用做成镜像宿主 systemd 拉起容器只读分区防篡改根文件系统只读应用分区单独可写八、镜像 vs 根文件系统核心区别维度根文件系统镜像本质目录树内容文件副本运行时是活的被挂载使用是死的只能被读写包含关系是镜像的一部分可以包含根文件系统路径/xxx.img制作方式用cp、dpkg填充用dd、mkfs、mksquashfs生成使用方式挂载后直接访问用dd写入存储介质类比书的内容书的影印件一句话根文件系统是 Linux 运行时看到的/镜像是把它打包成的.img文件。九、术语速查表术语含义类比镜像 (Image)存储介质的逐字节副本书的影印件根文件系统 (rootfs)Linux 运行时的/目录树书的内容固件 (Firmware)固化在芯片里的程序硬件里刻的字Bootloader启动引导程序U-Boot电脑的 BIOSKernelLinux 内核操作系统的心脏systemdLinux 的总调度器PID1工厂的调度中心Servicesystemd 管理的服务单元工厂里的一条产线烧录把镜像写入存储介质复印量产批量复制到多台设备批量印刷OTA空中升级手机系统更新A/B 分区双分区互为备份升级失败可回滚双系统启动first-boot首次启动时运行的个性化脚本新手机开机设置十、给你的下一步建议当前状态原型验证完成 ✅短期目标如果你想做几台设备自用在一台样机上配好所有东西用dd做成.img每台烧完后手动改 token验证一致性中期目标如果想做小批量产品学 Yocto 或 Buildroot做定制镜像写first-boot.sh做自动化个性化用厂商烧录工具批量写入长期目标如果要做正式产品引入 OTA 升级框架A/B 分区支持失败回滚云端设备管理十一、一句话总结整个项目你做的不是烧一个程序而是部署一个系统。镜像是打包方式根文件系统是运行内容systemd 服务是启动机制first-boot是个性化方案OTA是升级方案。这五点就是嵌入式 Linux 产品化的全部骨架。
