Question

首先了解一些背景

在基于iMX6的嵌入式系统中，我们进行了以下设置。有两个U-Boot分区和两个系统（Linux）分区。当前，我们仅使用第一个U-Boot分区，它使用标准方法来选择，运行和回滚（如果需要）系统分区。

我们现在正在寻找一种类似的方案来升级U-Boot本身（这种情况很少发生，但是我们确实希望能够做到这一点而不必将设备退回基础）。

但是，这更加危险，因为一旦告诉iMX6设备从备用U-Boot分区启动，就可以了-如果启动失败，将没有U-Boot / watchdog组合恢复到前一个，因此，糟糕的更新会冒着严重的风险，使设备变砖，直到我们将其退回维修基地为止（这是一项昂贵的选择，这就是为什么我们试图尽可能减轻它的负担）。

选择的方法是一个分为两步的U-Boot安装过程，由“写入”和“激活”组成。它取决于我们能否成功确定如果设备重新引导（选定的一个）将运行哪个U-Boot分区，以及当前正在运行的U-Boot分区（已引导的一个）。我们已经解决了这一点。

但是我们缺少的是UBoot在某些情况下能够将控制权转移到 other UBoot分区的能力。我们完全根据UBoot环境执行以下操作：

首先，mmcboot添加了前缀，以便检查控制传输，特别是将其设置为run ub_xer_chk ; <original content of mmcboot>。

第二，我们有一个变量ub_xfer_flag，通常设置为0。

第三，我们具有检查功能ub_xfer_chk，定义为：

if test ${ub_xfer_flag} -eq 1 ; then
    echo Soft-booting other UBoot...
    setenv ub_xfer_flag 0
    saveenv
    weave_magic
fi

我们遇到麻烦的地方是weave_magic代码：-)的想法是，这会将另一个UBoot分区加载到内存中（位于CONFIS_SYS_TEXT_BASE的{{1}}处）并执行它就像实际设备已经完成了。

我们已经通过使用0x1780000代替reset测试了该解决方案的实质，它成功地重新启动了设备一次，因此我们可以确保它安全。

我的具体问题是：如何我可以说服U-Boot从另一个分区加载第二个副本并运行它吗？

两个UBoot分区位于weave_magic和/dev/mmcblk3boot0设备中，可从系统分区访问它们，它们是2M文件，包括1K导入标头和末尾的填充部分。 / p>

更新：

我们实际上已经成功了，并成功使用以下命令从启动分区加载了IMX映像：

/dev/mmcblk3boot1

但是，当尝试使用以下命令执行时：

ext4load mmc ${mmcdev}:${mmcpart} 0x17800000 ${bootdir}/u-boot.imx

我们收到一条非法指令并立即重启：

go 0x17800000

所以我猜这不是该文件开头的可执行代码。有什么想法可以从这里去吗？

Answer 1

IMX文件中的实际 code 不在开头。您可以通过将excellent on-line disassembler与armv5 big-endian no-thumb体系结构一起使用来发现这一事实，以找出开头的字节经常为您提供无效和/或不太敏感的代码：

ldtdmi  a1, [a1], -a2             ; <UNPREDICTABLE>
strne   a1, [a1, a1]
andeq   a1, a1, a1
ldrbne  pc, [pc, -ip, lsr #8]!    ; <UNPREDICTABLE>

在任何情况下，已知IMX文件开头的数据都是标题信息（开头的d1是指示IVT标题的“魔术”标记，并且还应该有一个DCD块但是，即使超出 IVT和DCD块（基于标头字段中声称的长度），代码也不合理。

但是，在大量0xc00字节之后，偏移量0x00处有可行的信息：

00000be0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000bf0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000c00: 0f00 00ea 14f0 9fe5 14f0 9fe5 14f0 9fe5  ................
00000c10: 14f0 9fe5 14f0 9fe5 14f0 9fe5 14f0 9fe5  ................

将偏移量0xc00处的十六进制字节放入反汇编程序，并调整被分支跳过的区域，将显示有效的和合理的ARM代码。

事实上，用以下方法剥离IMX文件：

dd if=u-boot.imx bs=1 skip=3072 of=ub-at-c00.imx

应该给您一个可以用来启动的文件：

ext4load mmc ${mmcdev}:${mmcpart} 0x17800000 ${bootdir}/ub-at-c00.imx
go 0x17800000

执行此操作时，它输出：

U-Boot 2014.04 (Nov 07 2018 - 19:05:32)
CPU:   Freescale i.MX6Q rev1.5 at 792 MHz
CPU:   Temperature 32 C, calibration data: 0x5764e169
Reset cause: unknown reset
Board: DTI BRD0208 (Spitfire I) 05/01/2017
I2C:   ready
DRAM:  1 GiB

我们知道这是较新的UBoot，仅仅是因为我们使用的普通UBoot输出的是10月日期而不是11月的日期。

不幸的是，它当时挂起，看门狗计时器最终启动并重新启动回原来的UBoot，但我怀疑与UBoot有关的是不喜欢设备的当前状态（即，它不喜欢初始化两次）。

因此，我们必须弄清楚如何说服它这样做，但是至少我们已经让它引导了它本身的另一个副本，这就是问题所在。

iMX6获得U-Boot来临时引导另一个U-Boot

1 个答案: