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

Question

I am working on i.MX35 Freescale board with NAND flash. I am trying to upgrade the u-boot from Kernel. I searched in net, but i didnt get much details there

Is this possible to do this and how can I do it? Can someone provide the necessary commands and procedure to do this?

Answer 1

It's going to be very hard to give advice on this one without knowing more about what your kernel is configured with.

Since it appears you are booting the system from NAND, i'll assume your kernel is built with mtd support - although it's entirely possible that the system boots the u-boot from NAND, and then the kernel and root filing system from somewhere else.

My experience is with an OMAP2 board with Micron NAND flash, but the general steps should be the same. There seems to be no particularly nice source of documentation other than just trying it.

1: With any luck, your NAND is partitioned and the mtd subsystem compiled into your kernel subsystem, and it found the partitions on the NAND (the sizes are specified either on the kernel boot-line or maybe programmatically in your board-file).

On the console at boot you might see something like this: [caveat: some of this logging might be disabled]

[    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"

Note that I'm using an OMAP2 system here, with Barebox instead of u-boot, but the same applies. Here we have the primary loader partition xload , the main bootloader barebox , non volatile storage for barebox ( bareboxenv ), the kernel and root filing system.

2: If so, you'll find that there each of these partitions has a dev file in /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

The mtdblock files are raw block devices correspond to partitions in step 1

3: You can use mtdinfo -a for more info:

....
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: You can erase a partition (eg block1):

mtd_debug erase /dev/mtdblock1 0x0 0x8000

The two addresses are the offset from the start of the block and the length to erase

5: Copy your image to the newly erased flash

cp <uboot_image> /dev/mtdblock1

This seems to work for me which is perhaps surprising although most NAND flashes have very specific programming sizes - although these are probably multiples of a block.

mtd_debug also provides read and write verbs - which do precisely what you'd imagine. I had less success with these than with cp

It obviously goes without saying that you want an alternative boot arrangement (presumably MMC Card) handy and verified to work before trying this, as your system may well be unbootable afterwards if flash programming didn't work.

Things that have gone wrong for me and proved a pain have been different ECC algorithms used for the partitions. The first couple of erase units of the flash are usually guaranteed to be more robust, and will use whatever ECC the minimal initial loader in mask PROM in your SoC supports. This may well not be what you use on the rest of the device - certainly isn't with the Micron parts I'm using.

This will mean that the bootloader and kernel might not be able to read and write each others' partitions without some modification.