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

Question

我正在研发带有NAND闪存的i.MX35飞思卡尔主板。 我正在尝试从内核升级u-boot。 我在网上搜索，但我没有得到很多细节

这有可能做到这一点，我该怎么做？ 有人可以提供必要的命令和程序吗？

Answer 1

如果不了解更多关于内核配置的内容，就很难就此提出建议。

既然看起来你正在从NAND启动系统，我会假设你的内核是用mtd支持构建的 - 尽管系统完全有可能从NAND启动u-boot，然后从其他地方启动内核和根文件系统。

我的经验是使用带有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 ， barebox非易失性存储（ bareboxenv ），内核和根文件系统。

2：如果是这样，你会发现每个分区都有/dev的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文件是原始块设备，对应于步骤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

这两个地址是从块的开始和擦除的长度的偏移量

5：将图像复制到新擦除的闪光灯

cp <uboot_image> /dev/mtdblock1

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

mtd_debug还提供read和write动词-这正是做你想象的东西。 我用这些比用cp获得的成功更少

显然毋庸置疑，你想要一个备用的引导安排（大概是MMC卡），并且在尝试之前验证它是否正常工作，因为如果flash编程不起作用，你的系统很可能无法启动。

对我来说错误并且证明是痛苦的事情是用于分区的不同ECC算法。 闪存的前几个擦除单元通常保证更强大，并且将使用SoC支持的掩模PROM中的最小初始加载器的任何ECC。 这可能不是你在设备的其他部分使用的 - 当然不是我正在使用的Micron部件。

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