linux - 从 i.MX51 中的内核升级 u-boot

Question

我正在研究带有 NAND 闪存的 i.MX35 Freescale 开发板。我正在尝试从内核升级 u-boot。我在网上搜索过，但我没有得到太多细节

这可能吗？我该怎么做？有人可以提供执行此操作所需的命令和程序吗？

Answer 1

如果不进一步了解您的内核配置情况，就很难就此提出建议。

因为看起来你是从 NAND 引导系统，我假设你的内核是用 mtd 支持构建的 - 尽管系统完全有可能从 NAND 引导 u-boot，然后从 NAND 引导内核和根文件系统别的地方。

我的经验是使用带有 Micron NAND 闪存的 OMAP2 板，但一般步骤应该是相同的。除了尝试之外，似乎没有特别好的文档来源。

1:运气好的话，你的 NAND 被分区了，mtd 子系统被编译到你的内核子系统中，它在 NAND 上找到了分区(大小在内核引导行上指定，或者可能在你的主板上以编程方式指定 -文件)。

在启动时的控制台上，您可能会看到类似这样的内容:[警告:某些日志记录可能被禁用]

[    1.670471] Creating 5 MTD partitions on "omap2-nand.0":
[    1.676086] 0x000000000000-0x000000020000 : "xload"
[    1.684814] 0x000000020000-0x0000000a0000 : "barebox"
[    1.692626] 0x0000000a0000-0x0000000c0000 : "bareboxenv"
[    1.700622] 0x0000000c0000-0x0000004c0000 : "kernel"
[    1.709899] 0x0000004c0000-0x000040000000 : "root"

请注意，我在这里使用的是 OMAP2 系统，使用 Barebox 而不是 u-boot，但同样适用。这里我们有主加载程序分区 xload , 主引导加载程序 barebox ，裸机的非 volatile 存储(bareboxenv)，内核和根文件系统。

2: 如果是这样，你会发现这些分区中的每一个在/dev 中都有一个开发文件。

root@fk-00A0DE4648fe:~# ls /dev/
block               mtd4                tty11               tty49
bus                 mtd4ro              tty12               tty52
char                mtdblock0           tty13               tty50
console             mtdblock1           tty14               tty51
core                mtdblock2           tty15               tty520
cpu_dma_latency     mtdblock3           tty16               tty53trl
disk                mtdblock4           tty17               tty54om

mtdblock文件是原始 block 设备，对应步骤1中的分区

3:可以使用mtdinfo -a了解更多信息:

....
Name:                           barebox
Type:                           nand
Eraseblock size:                131072 bytes, 128.0 KiB
Amount of eraseblocks:          4 (524288 bytes, 512.0 KiB)
Minimum input/output unit size: 2048 bytes
Sub-page size:                  2048 bytes
OOB size:                       64 bytes
Character device major/minor:   90:2
Bad blocks are allowed:         true
Device is writable:             true
....

4:您可以删除一个分区(例如block1):

mtd_debug erase /dev/mtdblock1 0x0 0x8000

这两个地址是从 block 开始的偏移量和要删除的长度

5:复制你的图像到新删除的flash

cp <uboot_image> /dev/mtdblock1

这似乎对我有用，这也许令人惊讶，尽管大多数 NAND 闪存具有非常特定的编程大小——尽管这些可能是 block 的倍数。

mtd_debug还提供read和 write动词 - 完全符合您的想象。我在这些方面的成功不如 cp

很明显，您需要一个替代的引导装置(可能是 MMC 卡)，并在尝试之前验证它是否可以工作，因为如果闪存编程不起作用，您的系统很可能在之后无法启动。

对我来说出现问题并证明是痛苦的事情是用于分区的不同 ECC 算法。闪存的前几个删除单元通常保证更稳健，并且将使用 SoC 中掩码 PROM 中支持的最小初始加载程序的任何 ECC。这很可能不是您在设备的其余部分使用的 - 当然不是我正在使用的 Micron 部件。

这意味着引导加载程序和内核可能无法在不进行某些修改的情况下读取和写入彼此的分区。