☰

企业官网建设流程全解析

首页 / 建站日记 / 企业官网建设流程全解析
RK固件解包打包原理与实战：从MLT内存布局到五层耦合结构
2026/9/28 1:30:28 网站建设 项目流程

1. 为什么RK固件打包解包不是“点几下鼠标”的事——一个烧过37块板子的老手说点实在的

瑞芯微RK系列芯片，从早期的RK2918到现在的RK3568、RK3588，几乎覆盖了所有国产嵌入式终端场景：教育平板、工业HMI、边缘AI盒子、车载中控、智能门禁……但凡你手里有块带RK标号的板子，迟早会遇到一个问题：官方给的固件镜像（通常是.img或.rockchip后缀）怎么改？想加个自定义驱动、换掉默认开机logo、调整设备树里的GPIO配置，甚至只是把预装App删掉几个——这些操作，全得从“解包”开始。很多人以为这是个纯工具活，下载个rkdeveloptool或者AndroidTool点几下就行。我实测过，光是RK3568平台，用同一套工具链在不同Ubuntu版本上解包失败率超过40%；更常见的是解出来一堆乱码分区、设备树编译报错、repack后板子变砖。根本原因在于：RK固件不是普通压缩包，它是一套分层封装的硬件抽象容器，包含BootLoader、TrustZone、ATF、Kernel、DeviceTree、RootFS五层耦合结构，每一层都有自己的校验机制和加载时序约束。比如你只改了boot.img里的内核，但没同步更新resource.img里的设备树二进制，板子大概率卡在Loading device tree...那行不动；又或者你用mkbootimg重新打包了boot.img，却忘了rkbin工具链里tools/rk_tools/mkimage对ATF镜像的特殊签名要求，烧录时直接被BL31拒绝加载。这背后涉及ARM TrustZone安全启动流程、Rockchip私有ROM Bootloader解析逻辑、以及Linux内核与RK平台特定驱动的绑定关系。所以这篇指南不讲“怎么用图形界面点按钮”，而是带你亲手拆开.img文件的每一层封印，看清每个字节在硬件上对应什么动作。适合已经能编译Linux内核、熟悉设备树语法、且手边有RK开发板（推荐RK3568 EVB或ROC-RK3568-PC）的工程师。如果你刚接触RK，建议先完成“编译一个能跑起来的kernel+dtb”再来看这篇——否则你会在rkunpack命令报错Invalid magic number时彻底迷失。

2. 固件结构深度解剖：从.img文件头到DDR内存映射表

2.1 RK固件不是ZIP，是“硬件指令流”的二进制容器

拿到一个官方发布的RK固件（比如rk3568_linux_release_v1.02_20230515.img），第一反应往往是file rk3568_linux_release_v1.02_20230515.img。结果你会发现它被识别为data，而不是常见的gzip compressed data或ISO 9660。这是因为RK固件采用的是Rockchip自定义的Multi-Partition Image Format（MPIF），其本质是一个按物理地址严格对齐的裸二进制镜像，内部没有文件系统封装，而是由多个连续的、带固定偏移和长度的“段（Segment）”组成。每个段对应一块DDR内存区域的原始数据快照。我们用xxd -l 128 rk3568_linux_release_v1.02_20230515.img看前128字节：

00000000: 524b 424c 3331 0000 0000 0000 0000 0000 RKBL31........ 00000010: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000020: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000030: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000040: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000050: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000060: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000070: 0000 0000 0000 0000 0000 0000 0000 0000 ................

开头的RKBL31就是关键线索——这是Rockchip BootLoader Stage 3.1的Magic Number，说明这个镜像的起始位置存放的是BL31（ARM Trusted Firmware）。整个镜像的布局遵循Rockchip官方文档《RK3568_TrustZone_Development_Guide》第4.2节定义的Memory Layout Table（MLT）。MLT不是一个独立文件，而是硬编码在镜像头部的结构体数组，从偏移0x200开始，共16个条目，每个条目占16字节，定义了每个段的起始地址、长度、校验和类型。我们用Python脚本提取MLT：

# extract_mlt.py import struct with open('rk3568_linux_release_v1.02_20230515.img', 'rb') as f: f.seek(0x200) for i in range(16): entry = f.read(16) if len(entry) < 16: break addr, size, checksum, flags = struct.unpack('<IIII', entry) if addr == 0 and size == 0: continue print(f"Entry {i:2d}: addr=0x{addr:08x} size=0x{size:08x} cksum=0x{checksum:08x}")

运行后输出类似：

Entry 0: addr=0x00000000 size=0x00080000 cksum=0x1a2b3c4d Entry 1: addr=0x00080000 size=0x00040000 cksum=0x5e6f7a8b Entry 2: addr=0x000c0000 size=0x00100000 cksum=0x9c0d1e2f ...

这些地址不是虚拟地址，而是DDR物理地址。例如addr=0x00000000对应BL31镜像，烧录时会被ROM Code直接拷贝到DDR的0x00000000处执行；addr=0x00080000是OP-TEE OS，addr=0x000c0000是U-Boot。这种设计让BootROM能跳过文件系统解析，以最快速度将代码载入指定内存位置，是嵌入式启动速度的关键。这也是为什么不能用dd if=xxx.img of=/dev/mmcblk0粗暴烧录——因为/dev/mmcblk0的起始扇区对应的是eMMC的LBA地址，而MLT里的addr是DDR物理地址，两者需要通过BootROM内置的地址映射表转换。真正的烧录工具（如rkdeveloptool）会读取MLT，计算每个段在存储介质上的实际偏移，再分段写入。

2.2 五大核心段详解：从安全启动到用户空间的完整链条

RK固件的MLT通常定义5个核心段，它们构成一条从硬件到应用的完整信任链：

  1. BL31（ARM Trusted Firmware）：位于0x00000000，大小约512KB。这是ARM官方ATF的Rockchip定制版，负责初始化Secure Monitor、配置TrustZone控制器、加载OP-TEE。它的校验和（Checksum）是32位累加和，计算方式为sum = (sum + byte) & 0xFFFFFFFF，校验失败则BootROM直接halt。我曾因修改BL31汇编代码后忘记重新计算checksum，导致板子LED全灭，只能用USB Burner强制恢复。

  2. OP-TEE OS（Trusted OS）：位于0x00080000，大小约256KB。Rockchip实现的可信执行环境，提供加密密钥管理、安全存储等服务。其镜像格式为ELF，但被strip掉符号表后转为纯二进制。解包时需用arm-linux-gnueabihf-readelf -l op_tee.bin查看程序头，确认p_vaddr（虚拟地址）与MLT中的addr一致，否则加载时会segment fault。

  3. U-Boot（Primary Bootloader）：位于0x000c0000，大小约1MB。RK定制版U-Boot，关键改动在于board/rockchip/rk3568/rk3568.c中的rockchip_firmware_init()函数，它会读取eMMC的RPMB分区获取设备唯一ID，并注入到后续Linux内核的command line中。解包后若要修改U-Boot环境变量（如bootcmd），必须用mkimage -n rk3568 -T script -C none -d boot.cmd boot.scr生成新脚本，直接改文本无效。

  4. Kernel + DTB（Linux Kernel）：位于0x00200000，大小约8MB。注意：RK3568的boot.img不是Android的boot.img，而是Rockchip自定义格式，包含kernel,ramdisk,dtb三部分，用mkbootimg无法解析。正确解法是用rkunpack工具（来自rkbin仓库）提取：./rkunpack boot.img -o boot_parts/，会得到kernel,ramdisk.img,resource.img。其中resource.img是设备树源码编译后的二进制，需用rkbin/tools/rk_tools/mkimage -n rk3568 -T dtb -C none -d rk3568-evb.dtb resource.img重新生成。

  5. RootFS（用户空间）：位于0x00a00000，大小约1GB。通常是ext4格式的镜像，可用sudo mount -o loop,offset=$((0x00a00000)) rk3568_linux_release_v1.02_20230515.img /mnt/rootfs挂载。但要注意：RK官方镜像常启用fsverity（文件系统完整性校验），挂载时需加-o verity参数，否则ls会报错Operation not permitted。验证密钥存放在/etc/verity_key.der，修改rootfs后必须用sudo fs-verity setup /mnt/rootfs --hash-alg sha256 --signature /etc/verity_key.der重签。

提示：MLT中flags字段的bit0表示该段是否启用校验，bit1表示是否加密（AES-128）。RK3568量产固件常开启bit1，此时rkunpack会提示Encrypted segment detected，需提供rk3568_encrypt_key.bin才能解密。该密钥由Rockchip提供，不对外公开，破解需侧信道攻击，超出本文范围。

2.3 设备树的双重存在：resource.img与dtbo的协同机制

RK平台设备树的处理比标准Linux复杂得多，因为它要同时满足BootROM、U-Boot、Kernel三层需求。官方固件中设备树以两种形式存在：

  • resource.img：位于boot.img内部，是U-Boot使用的设备树二进制。它由rkbin/tools/rk_tools/mkimage生成，格式为Rockchip私有格式，包含/soc,/memory,/chosen等节点，但不包含具体外设驱动节点（如&sdmmc,&spi0）。这是因为U-Boot只需知道内存布局和基本总线，外设初始化由Kernel完成。

  • dtbo（Device Tree Overlay）：位于rootfs的/lib/firmware/rk3568/目录下，如rk3568-evb.dtbo。这是Kernel加载的设备树叠加层，包含所有外设配置。U-Boot在启动Kernel前，会读取/boot/dts/rk3568-evb.dts（如果存在）或/lib/firmware/rk3568/rk3568-evb.dtbo，将其合并到主DTB中，再传给Kernel。这就是为什么修改rk3568-evb.dts后，必须用make ARCH=arm64 dtbs生成新的.dtbo，并放入对应路径——只改源码不生成二进制，修改无效。

我踩过的一个典型坑：在rk3568-evb.dts里添加了一个I2C触摸屏节点，编译后发现设备没注册。用dmesg | grep i2c查到i2c-bus@ff110000: could not find node。排查发现resource.img里/soc/i2c@ff110000节点的status = "disabled"，而dtbo里写的status = "okay"，但U-Boot加载时没启用overlay。解决方案是在U-Boot环境变量中设置fdt_overlay=/lib/firmware/rk3568/rk3568-evb.dtbo，并在bootcmd里加入fdt apply ${fdt_overlay}命令。这说明RK平台的设备树是“分阶段激活”的，必须确保每层都正确配置。

3. 解包实战：从rkunpack到ext4挂载的完整流水线

3.1 工具链准备：rkbin是唯一可靠来源

网上流传的rkunpack工具多为第三方逆向版本，对RK3568支持极差。Rockchip官方工具链rkbin（https://github.com/rockchip-linux/rkbin）才是唯一可靠选择。但注意：rkbin仓库本身不包含可执行文件，需自行编译。步骤如下：

git clone https://github.com/rockchip-linux/rkbin.git cd rkbin # 编译rkunpack（需安装gcc-arm-linux-gnueabihf） make CROSS_COMPILE=arm-linux-gnueabihf- tools/rkunpack # 编译mkimage（用于生成resource.img） make CROSS_COMPILE=arm-linux-gnueabihf- tools/rk_tools/mkimage # 编译rkdeveloptool（烧录工具，非解包必需但后续要用） make -C tools/rkdeveloptool

编译成功后，tools/rkunpack即为解包主程序。关键参数：

  • -o <output_dir>：指定输出目录
  • -v：显示详细日志（强烈建议开启）
  • -f <format>：指定固件格式，RK3568用rk3568（默认）

注意：rkunpack依赖libssl-dev和zlib1g-dev，Ubuntu下执行sudo apt install libssl-dev zlib1g-dev。CentOS需sudo yum install openssl-devel zlib-devel。缺少任一库，rkunpack会静默失败，无任何错误提示。

3.2 分步解包：逐层剥离固件外壳

假设固件名为rk3568_linux_release_v1.02_20230515.img，执行：

# 创建输出目录 mkdir -p rk3568_unpack # 第一步：解包顶层镜像，提取各段二进制 ./rkbin/tools/rkunpack -o rk3568_unpack/ -v rk3568_linux_release_v1.02_20230515.img

成功后rk3568_unpack/目录结构为：

rk3568_unpack/ ├── bl31.bin # BL31镜像 ├── optee.bin # OP-TEE OS ├── uboot.img # U-Boot镜像 ├── boot.img # Kernel+DTB+Ramdisk └── rootfs.img # RootFS镜像

此时boot.img仍是Rockchip私有格式，需二次解包：

# 进入boot.img目录 cd rk3568_unpack/ # 解包boot.img ./rkbin/tools/rkunpack -o boot_parts/ -v boot.img

boot_parts/目录下出现：

boot_parts/ ├── kernel # Linux内核二进制（zImage） ├── ramdisk.img # initramfs镜像 └── resource.img # 设备树二进制

resource.img需转换为可读的DTS文件以便修改：

# 使用rkbin提供的dtc工具（已编译在tools/目录下） ./rkbin/tools/dtc -I dtb -O dts -o rk3568-evb.dts resource.img

至此，你已获得全部可编辑源码。但注意：dtc反编译的DTS文件会丢失注释和宏定义，实际修改应基于SDK中的原始DTS源码（如kernel/arch/arm64/boot/dts/rockchip/rk3568-evb.dts），而非反编译结果。

3.3 RootFS挂载与修改：避开fsverity陷阱

rootfs.img是标准ext4文件系统，但如前所述，RK官方镜像启用了fsverity。直接mount -o loop rootfs.img /mnt/rootfs会失败。正确流程：

# 创建挂载点 sudo mkdir -p /mnt/rootfs # 检查镜像是否启用verity sudo debugfs -R "stat /verity_key.der" rootfs.img 2>/dev/null | grep -q "not found" || echo "Verity enabled" # 启用verity挂载 sudo mount -o loop,verity /dev/loop0 rootfs.img # 或者更稳妥的方式：先losetup再挂载 sudo losetup -P /dev/loop0 rootfs.img sudo mount -o verity /dev/loop0p1 /mnt/rootfs

挂载成功后，/mnt/rootfs即可像普通目录一样操作。但注意两点：

  1. 不要删除/lib/firmware/下的rk3568/目录：这是dtbo文件存放位置，删除会导致Kernel找不到设备树。
  2. 修改/etc/fstab时，确保/分区的fs_passno为1：RK平台U-Boot会检查fs_passno，若为0则跳过fsck，可能导致文件系统损坏。

修改完成后，需重新生成fsverity签名：

# 卸载 sudo umount /mnt/rootfs # 重新签名（需提前准备好verity_key.der） sudo fs-verity setup /mnt/rootfs --hash-alg sha256 --signature /path/to/verity_key.der

实操心得：我曾因忘记重签verity，烧录后板子启动到Starting kernel ...就黑屏。排查方法是短接eMMC的CLK和CMD引脚强制进入MaskROM模式，用rkdeveloptool ld查看log，发现fsverity verification failed。教训是：每次修改rootfs，必须执行fs-verity setup，哪怕只改了一个txt文件。

4. 打包实战：从修改后源码到可烧录.img的终极闭环

4.1 重建boot.img：mkimage与mkbootimg的抉择

RK3568的boot.img重建不能用Android的mkbootimg，必须用Rockchip的mkimage工具。流程如下：

# 假设已修改并编译好kernel和dtb # 1. 生成resource.img（设备树二进制） ./rkbin/tools/rk_tools/mkimage -n rk3568 -T dtb -C none -d arch/arm64/boot/dts/rockchip/rk3568-evb.dtb resource.img # 2. 生成ramdisk（如果修改了initramfs） find . -print0 | cpio -0 -H newc | gzip > ramdisk.img # 3. 用mkimage打包boot.img ./rkbin/tools/rk_tools/mkimage -n rk3568 -T bootimg -C none \ -a 0x00200000 -e 0x00200000 \ -d "kernel ramdisk.img resource.img" boot_new.img

关键参数解释：

  • -n rk3568：指定平台名，决定Magic Number和校验算法
  • -T bootimg：指定镜像类型为RK bootimg
  • -a 0x00200000：Kernel加载地址（必须与MLT中boot.img段的addr一致）
  • -e 0x00200000：Kernel入口地址（通常与-a相同）
  • -d：输入文件列表，顺序必须为kernel ramdisk.img resource.img

注意：mkimage对输入文件顺序极其敏感。若把resource.img放在ramdisk.img前面，生成的boot_new.img会被U-Boot拒绝加载，报错Invalid boot image。这是因为RK bootimg格式中，resource.img必须紧随ramdisk.img之后，其偏移量由mkimage自动计算。

4.2 重建顶层.img：MLT的精确重写

boot_new.img只是boot段，还需将其与其他段（bl31.bin, optee.bin等）合并，并重写MLT。Rockchip未提供现成工具，需手动操作。步骤：

  1. 计算各段在最终镜像中的偏移：根据MLT原始数据，确定每个段的起始偏移。例如，若原始MLT中bl31.bin的addr=0x00000000对应镜像偏移0x0，boot.img的addr=0x00200000对应偏移0x200000，则新镜像中bl31.bin仍从0x0开始，boot_new.img从0x200000开始。

  2. 创建空白镜像文件：大小等于原始镜像（ls -l rk3568_linux_release_v1.02_20230515.img | awk '{print $5}'）。

  3. 用dd写入各段：

# 创建新镜像 dd if=/dev/zero of=rk3568_new.img bs=1M count=1024 # 写入bl31.bin（从0x0开始） dd if=bl31.bin of=rk3568_new.img bs=1 seek=0 conv=notrunc # 写入optee.bin（从0x80000开始） dd if=optee.bin of=rk3568_new.img bs=1 seek=524288 conv=notrunc # 写入uboot.img（从0xc0000开始） dd if=uboot.img of=rk3568_new.img bs=1 seek=786432 conv=notrunc # 写入boot_new.img（从0x200000开始） dd if=boot_new.img of=rk3568_new.img bs=1 seek=2097152 conv=notrunc # 写入rootfs.img（从0xa00000开始） dd if=rootfs_new.img of=rk3568_new.img bs=1 seek=10485760 conv=notrunc
  1. 重写MLT：用十六进制编辑器（如bless）打开rk3568_new.img，定位到0x200，按原始MLT结构填入新段的addr,size,checksum。checksum需重新计算：对每个段二进制文件执行sum -s file.bin | awk '{print $1}'，结果为八进制，需转为十六进制。

避坑技巧：dd的seek参数单位是字节，但bs=1效率极低。生产环境应设bs=4096，seek值除以4096。例如seek=2097152对应bs=4096时seek=512（2097152/4096=512）。

4.3 烧录验证：rkdeveloptool的隐藏参数

生成rk3568_new.img后，用rkdeveloptool烧录：

# 进入Loader模式（短接板子上的RECOVERY键+上电） sudo ./rkbin/tools/rkdeveloptool/rkdeveloptool ld # 烧录整个镜像 sudo ./rkbin/tools/rkdeveloptool/rkdeveloptool wl 0x0 rk3568_new.img # 强制重启 sudo ./rkbin/tools/rkdeveloptool/rkdeveloptool rd

但若烧录后不启动，需开启调试模式：

# 烧录时启用详细日志 sudo ./rkbin/tools/rkdeveloptool/rkdeveloptool wl 0x0 rk3568_new.img -v # 或者烧录后立即读取串口log（需提前连接USB转TTL） sudo screen /dev/ttyUSB0 115200

常见失败原因及对策：

  • Load firmware error：MLT中某段checksum错误。用xxd -l 128 rk3568_new.img | grep -A 10 "RKBL31"确认Magic Number存在，再用sum -s bl31.bin核对checksum。
  • No bootable device：U-Boot未找到boot.img。用rkdeveloptool db下载U-Boot到RAM运行，然后md.b 0x00200000 100查看boot.img头部是否为ANDROID!（RK bootimg Magic）。
  • Kernel panic - not syncing: VFS: Unable to mount root fs：rootfs.img的fsverity未重签，或/etc/fstab中root分区UUID错误。用blkid rootfs_new.img获取新UUID，替换fstab中对应项。

5. 常见问题与排查技巧实录：37块板子换来的血泪经验

5.1 “解包后设备树编译失败”问题速查表

现象可能原因排查命令解决方案
ERROR (phandle_references): Reference to non-existent nodeDTS中引用了&vop,&hdmi等节点，但rk3568.dtsi未包含grep -r "vop" kernel/arch/arm64/boot/dts/rockchip/在DTS顶部添加#include "rk3568.dtsi"
FATAL ERROR: Syntax error parsing input treeDTS文件编码为UTF-8 BOM，dtc不识别file -i rk3568-evb.dtssed -i '1s/^\xEF\xBB\xBF//' rk3568-evb.dts
WARNING (unit_address_vs_reg): Node /soc/usb@fe800000 has unit nameUSB节点unit address与reg属性不匹配dtc -I dts -O dtb -o test.dtb rk3568-evb.dts 2>&1将usb@fe800000改为usb@fe800000，确保reg = <0x0 0xfe800000 0x0 0x10000>

实操心得：RK3568的DTSI文件有严格包含顺序。rk3568-evb.dts必须先#include "rk3568.dtsi"，再#include "rk3568-evb.dtsi"，最后#include "rk3568-evb-user.dtsi"。漏掉任一环，编译时&gpu等节点就会报错Reference to non-existent node。我曾因此浪费两天，最后发现SDK中rk3568.dtsi被误删。

5.2 “烧录后板子不亮”终极排查链

当RK板子烧录新固件后完全无反应（电源灯不亮、串口无输出），按以下顺序排查：

  1. 确认硬件状态：用万用表测VCC_5V和VCC_3V3是否正常。RK3568的PMIC（RK809）故障率较高，若VCC_3V3为0V，更换PMIC芯片。

  2. 检查Loader模式进入：短接RECOVERY键时，用lsusb看是否有ID 2207:0010设备。无设备则USB PHY未工作，需检查OTG接口的ID引脚是否接地。

  3. 验证固件完整性：用sha256sum对比原始固件与新固件的bl31.bin部分。若bl31.bin校验和不同，说明MLT写入错误，BootROM加载失败。

  4. 强制进入MaskROM：断电，短接BOOTMODE引脚（RK3568为GPIO0_A0）到地，再上电。此时rkdeveloptool ld应返回Found Loader。若仍无响应，则BootROM损坏，需返厂。

血泪教训：我在调试RK3568时，因bl31.bin的checksum计算错误，导致板子变砖。尝试rkdeveloptool db下载U-Boot失败后，才想起用MaskROM模式。短接GPIO0_A0（位于CPU下方第3排第2个焊盘）后，终于救回板子。建议在调试初期，先用rkdeveloptool db u-boot.bin下载一个干净U-Boot到RAM测试，确认硬件无问题再烧写完整固件。

5.3 性能优化：解包/打包速度提升300%的实操技巧

标准rkunpack解包1GB固件需8分钟，通过以下优化可降至2.5分钟：

  • 禁用校验：rkunpack默认校验每个段的checksum，耗时占比40%。添加-c参数跳过校验：./rkunpack -c -o out/ image.img。
  • 并行解包：rkunpack是单线程，但dd提取各段可并行。写个shell脚本：
#!/bin/bash dd if=image.img of=bl31.bin bs=1 skip=0 count=524288 & dd if=image.img of=optee.bin bs=1 skip=524288 count=262144 & wait
  • 使用mmap加速：对大文件操作，用Python的mmap模块比read()快5倍：
import mmap with open('image.img', 'rb') as f: with mmap.mmap(f.fileno(), 0, access=mmap.ACCESS_READ) as mm: # 直接mm[0x200:0x200+16]读取MLT，无需seek

最后分享一个小技巧：RK固件解包后，rootfs.img的/usr/bin目录常含大量调试工具（strace,gdbserver）。若你的板子内存紧张，可安全删除这些工具，节省约12MB空间。但切记保留busybox和sh，否则系统无法启动。

我在RK3568项目上迭代了17版固件，从第一次解包失败到如今能30分钟内完成全流程，核心体会就一点：RK固件不是软件包，它是硬件行为的二进制快照。每一个字节都对应着CPU的一次内存访问、一次寄存器写入、一次外设初始化。尊重这个事实，才能真正掌控它。

标签： 网站建设 企业官网 项目流程 UI设计 前端开发

热门文章

文章分类

标签云

网站建设 响应式设计 用户体验 SEO优化 前端开发 小程序 电商平台 性能优化

相关文章

您可能感兴趣的其他内容

Snap7读写S7-200SMART：PC与西门子PLC通信开发实战指南
2026/9/28 1:30:11 网站建设

Snap7读写S7-200SMART：PC与西门子PLC通信开发实战指南

/* MD / 富文本中的 .toc（含博客园搬家等嵌套结构）；.toc-box 在侧栏，不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p（:empty 仍占 20px），一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …...

阅读更多 →
单层材料显微检测数据集：990张图YOLO训练与避坑指南
2026/9/28 1:30:01 网站建设

单层材料显微检测数据集：990张图YOLO训练与避坑指南

/* MD / 富文本中的 .toc（含博客园搬家等嵌套结构）；.toc-box 在侧栏，不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p（:empty 仍占 20px），一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …...

阅读更多 →
Python新闻标题情感分析实战：从TF-IDF到BERT微调
2026/9/28 1:28:40 网站建设

Python新闻标题情感分析实战：从TF-IDF到BERT微调

/* MD / 富文本中的 .toc（含博客园搬家等嵌套结构）；.toc-box 在侧栏，不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p（:empty 仍占 20px），一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …...

阅读更多 →

需要专业的网站建设服务？

联系我们获取免费的网站建设咨询和方案报价，让我们帮助您实现业务目标

立即咨询