world leader in high performance signal processing
Trace: » upgrading

Upgrading U-Boot

As described in the Compiling U-Boot section, when U-Boot is built, it generates some bootable images. Make sure you've selected the proper binary file for your target board and boot mode. U-Boot has the flexibility of upgrading itself on the fly by re-flashing the board without having to resort to a JTAG cable.

Once you have the right binary file, it must be transferred to the target by either Ethernet, or Serial. You can upgrade U-Boot either while the kernel is running, or while U-Boot is running. We'll show examples of all of these methods.

The examples here are for a BF533-STAMP running in Bypass mode, but it should be trivial for you to adapt to your specific board/boot mode.

If a mistake or failure occurs during this procedure the development board will have to be recovered, perhaps using a JTAG interface. For more information see Loading U-Boot.

From U-Boot

via Ethernet

Before U-Boot can be upgraded, a TFTP server must be set up on the host computer and the TFTP directory must contain the U-Boot image file. Also, U-Boot's environment variables must be setup to communicate with the TFTP server (see Setting up a TFTP Server).

When you load the file to your board, it'll go something like this:

bfin> tftp 0x1000000 u-boot.bin
Filename 'u-boot.bin'.
Load Address:  0x1000000
Loading:  ##########################
done
Bytes Transfered = 131120  (20030 hex)

For more information, consult the loading files via TFTP page.

The number of bytes transferred are displayed in decimal as well as in hexadecimal. This value is automatically stored by U-Boot in a variable called filesize.

via Serial

To load via serial, start the receiver, with the loadb command, and then escape to the terminal program's send file option, and send the file.

When you load the file to your board, it'll go something like this:

bfin> loadb
Load Address:  0x1000000
Loading:  ##########################
done
Bytes Transfered = 131120  (20030 hex)

For more information, consult the loading files via the Serial port page.

Testing

Once the new U-boot has been loaded into the target, you can test it without erasing and re-programming the flash. This way you can make sure things are mostly sane before actually reflashing the board.

Simply use the go command:

bfin> go 0x1000000

For more information, see the testing new U-Boot page.

Remember, this simply loads U-Boot into external memory and executes it there. Nowhere is any non-volatile storage modified (such as flash). So as soon as you reset, the code that exists in flash will be executed, not the code you loaded into external memory.

Parallel NOR Flash

By default, U-Boot will protect the sectors in flash where it is stored so as to prevent accidental erasure/writing.

To turn off the sector protection:

bfin> protect off all
Un-Protect Flash Bank # 1
................................................................... done

Now you need to erase the sectors where U-Boot lives. The exact sector addresses may be different (consult the output of flinfo). These addresses though should work for all STAMP and EZKIT boards.

bfin> erase 0x20000000 0x200fffff
.............. done
Erased 19 sectors

Next the new U-Boot must be written into flash. If you just loaded the U-Boot file, you should be able to use the filesize variable to streamline things.

bfin> cp.b 0x1000000 0x20000000 $(filesize)
Copy to Flash... done

Finally, verify that things copied properly to flash. You can use the cmp command to compare regions of memory to make sure they are byte-for-byte the same.

bfin> cmp.b 0x1000000 0x20000000 $(filesize)
Total of 131120 bytes were the same

If any of these steps failed, you should not reset the board. Doing so may mean your system will no longer boot and you will need to recover via Loading U-Boot. Review and retrace your steps until everything checks out. Then you can safely reset or power cycle the board.

For more information, please consult the parallel-flash document.

Serial NOR flash

Updating serial flash is similar. Assuming nothing lives in the first 512KiB of your SPI flash:

bfin> sf erase 0 0x80000
bfin> sf write 0x1000000 0 $(filesize)

For more information, please consult the serial-flash document.

From Linux

For now, don't use this - I am still testing

Downloading to the board

There are some simple instructions for downloading files to a running kernel.

Ensuring you have the correct mtd drivers

To access the flash inside Linux, you use the memory technology device subsystem. To look at the way the kernel understands the flash, you can check the /proc filesystem:

root:~> cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00800000 00001000 "ROMfs"

This means that the either the correct maps, or drivers are not in the kernel. On a default BF537-STAMP configuration, the drivers and maps are compiled as modules which can be included into the kernel at run time.

Erasing the Flash

The [n]] should be replaced with the actual number of the U-Boot partition, in this case 1.

# flash-eraseall /dev/mtd[n]
Erased 256 Kibyte @ 0 -- 100% complete.

Writing U-Boot into Flash

# dd if=/tmp/uboot.bin of=/dev/mtd0 bs=128k conv=sync
1+1 records in
2+0 records out