烧录官网下载的desktop或server都能成功，但是烧录自编译emmc_disk.img成功，但是启动失败反复打印同一段log，如下：
失败点在分区表：Writing 'boot' FAILED (remote: 'cannot find partition') 加上前面的 boot partition size: 0，说明板子当前 fastboot 读不到有效的 GPT，单独烧 boot 分区自然找不到目标（多半是之前全镜像烧录失败把分区表弄坏了）。串口里 ubootenv bad CRC, using default environment 是正常现象（ubootenv.img 默认就是空的），不是问题原因。
按下面顺序恢复：
1. 从 0 地址整体烧录（含分区表），不要单独烧 boot
串口进 U-Boot 命令行，执行 fastboot 0，然后在 PC 的 out/product 目录下：
fastboot flash addr:0x0 emmc_disk.simg
fastboot reboot
官方步骤见 2.5 系统镜像烧写 → 使用 fastboot 命令烧录镜像。
2. 用 xburn 重烧自编译全镜像时注意三点
- 「镜像文件目录」要选整个
out/product目录，工具靠里面的x5-soc-release-gpt.json获取分区表，只给单个 img 不行； - 你的产物在
\\app3.si-in.com网络共享上，建议先把out/product完整拷到本地磁盘再烧，网络路径读取超时很容易导致烧录中途失败； - 板子当前系统已不完整的话，下载模式别选纯 Fastboot（它要求非空板、镜像可正常启动），改用
dfu_fastboot或xmodem_fastboot空板烧录模式，会用out/product/uart_usb里的固件先引导再写全镜像，见 烧录方式简介。
另外你串口日志里有 SD Card detected, entering UMS update system on mmc 1，烧 eMMC 时建议把 SD 卡拔掉，避免 U-Boot 走进 UMS 流程干扰烧录。
系统能正常起来之后，日常只更新 kernel 再单独 fastboot flash boot boot.img 就没问题了。如果第 1 步 flash addr:0x0 还报错，把当时的串口完整输出贴上来看看。
我看了你这个问题，目前还缺几项复现实验需要的材料：
- 自编译所用的 X5 BSP 源码版本（仓库地址/tag 或 commit）与完整编译命令、实际使用的板级配置文件（device/horizon/x5/board_x5_*_config.mk）
- out/product 下的关键产物：board_config.mk、x5-soc-release-gpt.json、gpt.img、boot.img（以及可选的 emmc_disk.img、miniboot_all.img），位于你本机 out/product 目录，可直接打包上传
- 完整编译日志 out/build_log/build_*.log（尤其 mk_boot.sh 与打包阶段）和完整串口启动日志文本（从 BL2 到反复循环的全文，不要只给截图）
- 完整 fastboot 输出与所用烧录方式/配置文件（指定分区烧录时的 x5-soc-release-gpt.json 或 XBurn 配置），以及你烧录后可正常启动的官方镜像版本号（可与官方 X5 下载页的发布镜像对比）
- 板卡确切规格：RDK X5 4GB 还是 8GB、eMMC 容量、是 RDK X5 板还是 X5 EVB/Module（用于确定应使用的默认板级配置与分区表）
请直接在本帖回复补充，也可以编辑原帖。补充后我会自动重新评估；材料和板卡条件满足时，就继续安排实验。
实验补充材料：materials-35783-b17289ea98cadcbf5add6a8846f45339516001b664a9923e4149d7edc795577f
执行上面烧录命令后，板子烧成砖了
原始代码下载自：1.6 下载资源汇总 | RDK X3/X5 DOC
配制的是 board_x5_soc_release_config.mk
product及log见附件
Downloads.zip (7.8 MB)
编译日志：
build_log.zip (94.1 KB)
单板规格：RDK X5 4GB
我可以在我们的板卡上帮你在自有 RDK X5 4GB 开发板（x5-4g，官方 Ubuntu SD 卡系统）上做只读存储枚举核查：确认该型号开发板是否存在 eMMC（mmc0），用于判断用户串口日志中 “eMMC or SD Card not detected on mmchost 0” 是该型号的正常状态还是硬件损坏。。是否需要我继续？
我们是要在RDK X5平台导入我们自研的TOF sensor模组，所以
第一步要用你们的SDK自编译完整系统并烧录启动
第二步移植我们的TOF驱动到kernel然后调试
目前卡在第一步，烧录编译的版本都起不来，能否帮忙验证如何用platform_source_code编译出能在RDK X5 4GB上能运行的版本。
我可以在我们的板卡上帮你在自有 RDK X5 4GB 开发板（x5-4g，官方 Ubuntu SD 卡系统）上做只读存储枚举核查：确认该型号开发板是否存在 eMMC（mmc0），用于判断用户串口日志中 “eMMC or SD Card not detected on mmchost 0” 是该型号的正常状态还是硬件损坏。。是否需要我继续？
好的，帮忙看看哦。
收到。我先在我们自己的 RDK X5 4GB（官方 Ubuntu SD 卡系统）上做一轮只读存储枚举：核对开发板是否存在 eMMC（mmc0）、SD 卡与 rootfs 实际所在设备、以及 SPI NAND 的分区布局，用来确认你串口日志里 “eMMC or SD Card not detected on mmchost 0” 是该型号的正常状态还是异常。结果出来后再给你自编译应选的板级配置和对应烧录路径。
同时麻烦贴一份材料：官网镜像包 product_20260408 目录里 board_config.mk 的内容（它记录官方镜像编译时用的板级配置），我据此核对 platform_source_code 里该 lunch 哪个配置。
在结论明确前请不要再对板子执行 fastboot 写命令：上次 fastboot flash addr:0x0 emmc_disk.simg 覆盖了启动区导致变砖，恢复方式就是你已经做过的 miniboot 升级。
product_20260408.zip (6.7 MB)
结论：board_x5_soc_release_config.mk 是 eMMC 启动的板级配置（面向带 eMMC 的 X5 Module/载体板），不适用于 RDK X5 4GB 开发板。官方烧录概述写得很明确：RDK X5 开发板的系统镜像写入 Micro SD 卡，eMMC 烧录只出现在 Module 一栏；你的串口日志 “eMMC or SD Card not detected on mmchost 0”、mmc1 才检测到 SD 也佐证这块板没有 eMMC，启动链是板载 SPI NAND（miniboot/U-Boot）+ SD 卡。所以 soc 配置产出的 emmc_disk.img（eMMC GPT、根设备指向 eMMC）写到任何介质上都起不来，循环 log 就是 uboot 在反复探 mmc；soc 配置下 fastboot 的烧录介质和分区表都指向 eMMC，于是 fastboot flash boot 报 cannot find partition。之前变砖正是把 eMMC 全盘镜像写进了开发板的 0 地址，后续不要再在这块板上执行 fastboot flash addr:0x0 emmc_disk.simg。
product_20260408 这套已经切到与零售板对应的 rdk 板级配置（x5-rdk-ubuntu-nand-gpt.json，零售板内核设备树即 x5-rdk-v1p0.dts），方向是对的，但镜像集合不完整：目录里只有 nand_disk.img（约 8.7MB，只装得下 miniboot_all+uboot+ubootenv 这类 NAND 侧固件）、mbr/miniboot/uboot/ubootenv/misc 和 uart_usb，没有 boot.img、system.img、app.img 等根文件系统镜像，这套东西烧进去也起不了完整系统，怀疑当时编译没走完整打包流程。
麻烦补两项信息，我据此给出 3.5.0 platform_source_code 的准确编译+烧录顺序（哪部分进 NAND、哪部分进 SD 卡）：1) product_20260408 里 board_config.mk 的内容（或当时 lunch 选的配置全名）；2) 实际执行的编译命令（是完整 ./bd.sh all 还是只编了部分模块、有没有跑 pack）。我们这边的 X5 4GB 板卡恢复后（当前一台在 recovery、一台 offline），会用同版本源码直接做一轮"编译→烧录→启动"验证并在帖里同步结论；第一步通了之后你们的 TOF 内核驱动移植可以接着这条路径走。
SDK 需要使用X5 Module
X5 参考BSP 源码 https://github.com/D-Robotics/x5-rdk-gen
之前lunch 7
然后
./bd.sh all
./bd.sh pack
product_20260408目录里board_config.mk内容：
#!/bin/bash
export HR_TARGET_VENDOR="rdk"
export HR_TARGET_CHIP="x5"
export HR_SECURE_CHIP=y
export HR_TARGET_BIT="64"
export HR_TARGET_MODE="debug"
# 板级名称，对应每一个新的硬件型号
export HR_BOARD_TYPE="soc"
export HR_MEDIUM_TYPE="nand"
# 编译out目录
export HR_BUILD_OUTPUT_DIR=${HR_TOP_DIR}/out
# 编译中间文件输出目录，如uboot、kernel、hbre的编译目录
export HR_TARGET_BUILD_DIR=${HR_BUILD_OUTPUT_DIR}/build
# 产出镜像输出路径，本目录下的镜像文件用于烧录和发布
export HR_TARGET_PRODUCT_DIR=${HR_BUILD_OUTPUT_DIR}/product
# 从build到product的中间产物，如内核、设备树、根文件系统的原始目录和文件
export HR_TARGET_DEPLOY_DIR=${HR_BUILD_OUTPUT_DIR}/deploy
# 编译日志保存目录
export HR_BUILD_LOG_DIR=${HR_BUILD_OUTPUT_DIR}/build_log
# 板级配置文件存放目录
export HR_BOARD_CONF_DIR=${HR_TOP_DIR}/"device/rdk/${HR_TARGET_CHIP}/board_cfg/${HR_BOARD_TYPE}"
# 配置交叉编译工具链
export ARCH="arm64"
export TOOLCHAIN_PATH=/opt/gcc-arm-11.2-2022.02-x86_64-aarch64-none-linux-gnu
export CROSS_COMPILE=${TOOLCHAIN_PATH}/bin/aarch64-none-linux-gnu-
# 使能ccache，加速编译
export HR_CCACHE_SUPPORT=y
export CCACHE_COMMAND="ccache"
export HR_APPEND_CXX_OPTIONS="-DCMAKE_CXX_COMPILER=\"${CCACHE_COMMAND}\" -DCMAKE_CXX_COMPILER_ARG1=\"${CROSS_COMPILE}g++\" -DCMAKE_C_COMPILER=\"${CCACHE_COMMAND}\" -DCMAKE_C_COMPILER_ARG1=\"${CROSS_COMPILE}gcc\""
export HR_CCACHE_DIR="$HOME/.ccache"
# 构建系统常用的工具软件存放路径，比如fiptool
export HR_BUILD_TOOL_PATH=${HR_TOP_DIR}/build/tools
# 分区表，mbr，gpt内容处理的工具软件存放路径
export HR_PARTITION_TOOL_PATH=${HR_TOP_DIR}/build/tools/partition_tools
# avbtools工具脚本存放路径，在对kernel和分区文件系统添加校验信息时需要使用到（mk_system.sh）
export HR_AVB_TOOLS_PATH=${HR_TOP_DIR}/build/tools/android_tools/avbtools
export HR_BD_IMG_TOOLS_PATH=${HR_TOP_DIR}/build/tools/android_tools/build_image
# 分区表配置文件所在目录和文件名
export HR_PART_CONF_FILENAME=${HR_BOARD_CONF_DIR}/x5-rdk-ubuntu-nand-gpt.json
export BLK_SZ=512
export NAND_ERASE_SIZE=131072
export NAND_PAGE_SIZE=2048
export NAND_SIZE=$((128 * 1024 * 1024))
# uboot 编译配置文件
export HR_UBOOT_CONFIG_FILE=hobot_x5_rdk_nand_defconfig
export HR_ARCH_UBOOT="arm"
# 指定uboot源码的输出目录，如果不设置，则在源码目录下编译
export HR_UBOOT_OUTPUT_DIR=${HR_TARGET_BUILD_DIR}/uboot
# 环境变量配置标志，用来标识当前env环境已经完成了板级配置项的设置
export HR_IS_BOARD_CONFIG_EXPORT="true"
结论：两次自编译配置都和零售 RDK X5 4GB 开发板的存储布局不匹配，所以都起不来；这块板的官方源码构建入口也不是 platform_source_code 的 soc/nand 配置。
依据和现象对应：
- 零售 RDK X5 开发板的 Ubuntu 系统跑在 Micro SD 卡上，板载 128MiB SPI NAND 只放 miniboot/uboot 等启动固件，没有 eMMC（烧录概述里 eMMC 烧录只列在 RDK X5 Module 一栏；你的串口 log 里 mmchost 0 检测不到也印证）。platform_source_code（芯片 SDK）里 soc 系列配置面向 eMMC/NAND 主存：board_x5_soc_release_config.mk 产出 emmc_disk.img + eMMC GPT（你第一张 product 截图就是），lunch 7 那份 board_config.mk 是 HR_MEDIUM_TYPE=nand、x5-rdk-ubuntu-nand-gpt.json、hobot_x5_rdk_nand_defconfig 的 NAND 主存配置。
- 循环 log：uboot 从 NAND 起来后按 eMMC/NAND 主存的预期找系统分区，mmc0 无设备、SD 上又不是它认识的布局，于是反复 probe mmc0/1/2。
fastboot flash boot报 cannot find partition、boot partition size 0：当前分区表里根本没有 boot 分区。开发板官方流程是整盘 SD 镜像写卡（Rufus/XBurn/RDK Studio），不支持 fastboot 单烧 kernel，这条路在这块板上不成立。fastboot flash addr:0x0 emmc_disk.simg把整盘 eMMC 镜像（含分区表和启动区）写到当前介质 0 地址，覆盖启动区，这就是变砖那一步；miniboot 救回后不要再对该板执行这条。- 第二份 product（product_20260408）里只有 nand_disk.img（约 8.7MiB，仅 miniboot/uboot/ubootenv/misc 等启动固件）和 mbr/misc，没有 boot.img/system.img/app.img：这个配置没把 Ubuntu rootfs 打成可烧镜像，烧了也无从启动。
正确路径：rdk_x_doc《7.2.1 开发环境搭建及编译说明》明确 RDK X5（开发板）的源码托管在 GitHub x5-rdk-gen 仓库，README 覆盖环境搭建到系统镜像编译；platform_source_code 的 soc/evb 配置对应 eMMC/NAND 主存板（Module/EVB 类），和帖里 Marcelo 的说明一致。你们的目标（自编译系统 + TOF 驱动进 kernel）建议：clone x5-rdk-gen → 按 README 构建 RDK X5 开发板 SD 系统镜像 → 在其 kernel（6.1.83，开发板设备树 x5-rdk-v1p0 系列）里移植 TOF 驱动 → 整盘写 SD 卡启动。
关于验证请求：我们可以在自有 RDK X5 4GB 开发板上走一遍 x5-rdk-gen 构建 + 写卡启动，并顺带验证单独替换 kernel 的路径，供你们 TOF 驱动调试参考；这边两块 X5 目前一块占用、一块 recovery，恢复后排队。请确认是否按 x5-rdk-gen 路线做这个验证；如果仍希望我们在开发板上实测 platform_source_code 的某个 lunch 配置作为对照，也请说明，实测结论会一并给出。
没有单独的「免 root 版本」。X5 BSP 编译里真正需要权限的只有两处，手册对这两处都给了普通用户的替代做法：
- 主机依赖：官方脚本是
sudo build/install_host_deps.sh（等价的手动 apt 包列表见手册 4.1.2.2）。没有 root 就请管理员一次性把这批包装上，或改走容器编译。 - 工具链：不必放
/opt。手册 4.1.2.3 专门写了无 sudo 用户的路径——把toolchain/下的工具链包解压到自己的家目录，例如tar -xvf toolchain/<工具链包>.tar.xz -C ~/，再把你当前生效的板级配置里的TOOLCHAIN_PATH指到这个路径，之后照常./bd.sh lunch→./bd.sh all→./bd.sh pack即可。
容器路线见同一手册 4.1.5/4.1.6：cd build && docker build -t dr_xbuild/ubuntu20.04:1.0 .，回到源码根目录执行 ./build/start_docker.sh 进容器里编译（需要管理员把你加入 docker 组一次）；也行的话手册另有 Podman 方式，Podman 支持非特权用户运行。
另外选型上先确认一下：platform_source_code 在下载页里是归在 RDK X5 Module 名下的（Buildroot，eMMC/NAND 主存），RDK X5 4GB 开发板的系统镜像对应的是 x5-rdk-gen（手册 7.2.1 里 X5 的源码仓库），其环境要求以该仓库 README 为准。如果你的目标是在这块 4GB 开发板上跑通并移植 TOF 驱动，建议把内核侧的改动放到 x5-rdk-gen 上做。
你现在是卡在哪一步报的错——install_host_deps.sh/apt 阶段，还是 bd.sh 编译中途某个脚本？把那条命令和完整输出贴上来（截图的报错文本也行），我按实际失败点给具体改法。
您回的是platform_source_code上没有root权限如何规避
上面说了RDK X5需要用上面的源码，所以现在源码是基于x5-rdk-gen编译：
里面很多地方都需要root权限，服务器上没有root权限该怎么办
sudo ./pack_image.sh
cd samplefs
chmod +x make_ubuntu_rootfs.sh
# 默认编译 desktop 的 samplefs
sudo ./make_ubuntu_rootfs.sh
# 指定编译 server 版本的 samplefs
sudo ./make_ubuntu_rootfs.sh server
编译能免 root，官方 X5 BSP 文档里只有一步明确要 root：用 multistrap 制作 Ubuntu 根文件系统。你只是要加 TOF 内核驱动，那一步可以整段绕开。
1）把交叉工具链从 /opt 换到家目录——文档 4.1.2.3 专门写了无 sudo 用户的路径（文件名/版本以你手上的 SDK 为准）：
tar -xvf toolchain/arm-gnu-toolchain-11.3.rel1-x86_64-aarch64-none-linux-gnu.tar.xz -C $HOME
然后改你正在用的板级配置（如 device/horizon/x5/board_x5_soc_release_config.mk）：
export TOOLCHAIN_PATH=$HOME/arm-gnu-toolchain-11.3.rel1-x86_64-aarch64-none-linux-gnu
kernel/uboot/hbre/app 的编译和 pack 都不再往系统目录写东西。
2）不做根文件系统定制就别碰 multistrap：源码树里本来就有预编译 rootfs 包（system/ubuntu/prebuilt/dr-system-jammy_.deb、system/buildroot/prebuilt/dr-system_.deb），只编内核、只重打包即可：
./bd.sh boot # kernel + dts → out/product/boot.img
./bd.sh pack # 重新打完整镜像
改了 kernel/dts 后单独更新 boot 分区就行（FAQ 7.2.24）。如果确实要重建 Ubuntu rootfs，官方原文是必须加 sudo，否则首次烧录后要在板端 dpkg --configure -a 逐个配置软件包——这一步没有免 root 的官方做法。
3）官方也给了容器编译方式（build/Dockerfile + ./build/start_docker.sh，Podman 一路是 start_podman.sh），用来隔离依赖；但文档里的 BSP 容器示例命令本身也都带 sudo，能不能整条流程无根跑通取决于服务器上是否已有现成可用的 docker/podman。
你贴的 sudo ./pack_image.sh、samplefs/make_ubuntu_rootfs.sh 属于 x5-rdk-gen（RDK OS）那套流程，芯片 SDK 文档里用的是 ./bd.sh pack；RDK X5 手册对 x5-rdk-gen 只指向它的 GitHub README，没有免 root 的替代流程说明。
麻烦补两点我才能判断你这步能不能绕开：报权限错误的那条命令和错误首行（截图里看不清，重点看是不是卡在 rootfs 解压/挂载）；服务器上是否已装 docker 或 podman、你能否直接用。
现在是x5-rdk-gen，前面还是你说RDK X5 4GB只有基于这套代码开发，该如何规避root
公司服务器没装docker，只有普通user权限，没有root权限