ARTICLE DETAIL

资讯详情

深耕网站建设、视觉设计与SEO优化的一线实战洞察。

orin flash.sh刷机报错:找不到PARTUUID=fc0e9609-b0c4-43d4-b824-227bc42ae694

orin flash.sh刷机报错:找不到PARTUUID=fc0e9609-b0c4-43d4-b824-227bc42ae694

Jetson AGX Orin 升级sdk从35.1到JetPack-36.2.

尝试按照之前35.1的刷机命令刷机:

sudo ./flash.sh -r jetson-agx-orin-devkit mmcblk3p1

发现kernel启动后无法挂载/mnt分区,报错信息

mount:/mnt/:can't find PARTUUID=fc0e9609-b0c4-43d4-b824-227bc42ae694.

解决方案:

刷机命令使用internal参数

$ sudo ./flash.sh -r jetson-agx-orin-devkit internal

排查过程

正常分区挂载log:

/dev/mmcblk3p1:UUID="98ac79cb-f2a1-45ce-9fce-dbf5bb3b629” BLOCK SIZE="4096"TYPE="ext4"PARTLABEL="APP" PARTUUID="fc0e9609-b0c4-43d4-b824-227bc42ae694"

也就是挂载失败是因为APP子分区没找到,

flash刷机log:

Writing partition APP with system.img [ 6556678244 bytes ]

也就是system.img刷的不对??但刷机log显示已经刷完了。

b8c5b8f4ac43971f62c8afdc60defd90 bootloader/system.img flash路径

23b7ec45a31e344f8a1c4138ef012227 ./bootloader/system.img sdkmanager路径

UUID和PARTUUID都是唯一标识符,一个与文件系统相关,因此在重新格式化分区时会发生变化,另一个与分区相关联,因此与分区本身相关联(重新格式化时不会更改)。==》按照这个说法,partuuid的值,和system.img相关,那么打包的脚本是不是有问题?

grep flash路径下的systemm.img找不到partuuid的字符串,

如果partuuid跟随img的话,复制sdkmanager的system.img到flash路径下,刷机看看。==》不行

flash时会判断并重新写uuid,uuid文件为:

bootloader/l4t-rootfs-uuid.txt

尝试修改这个文件的uuid,但是看flash.sh使用mmcblk参数貌似调不到。

按照论坛的说法,需要将分区的partuuid写入这个文件,在kernel启动时cmdline会使用这个参数。按照这个思路,查看flash.sh脚本,发现传参数mmcblk3p1时,cmdline在启动时找的是mmcblk3p1,而不是找partuuid,但是orin似乎没有生效,修改这个文件对cmdline没有影响,在失败的kernel下cat /proc/cmdline,root=partuuid,而不是mmcblk。

猜测cmdline由dts配置,搜索没找到dts中哪里有配置cmdline,以防万一,回退dts试试。=》不行dts中有表示,cmdline可能是从emmc中读取的,那么system.img就得需要重新配置partuuid了。但是为什么sdkmanager中的system.img也不行?

flash脚本中,使用参数“internal”能跑到配置uuid中:

$ sudo ./flash.sh -r jetson-agx-orin-devkit internal

flash的log:

Copy /home/nvidia/orin-36.2/Jetson_Linux_R36.2.0_aarch64/Linux_for_Tegra/kernel/dtb/tegra234-p3737-0000+p3701-0000-nv.dtb to /home/nvidia/orin-36.2/Jetson_Linux_R36.2.0_aarch64/Linux_for_Tegra/kernel/dtb/tegra234-p3737-0000+p3701-0000-nv.dtb.rec 
Using UUID fc0e9609-b0c4-43d4-b824-227bc42ae694 for mounting root APP partition.

返回列表