Why does it makes sense to downgrade U-Boot?
F&S modules that are not customized are shipped only with U-Boot installed. This is done because most of our customers install their own kernel, root file system etc..
But U-Boot versions differ too and can have an impact to your kernel.
For example fsimx6v2.x release is a version that doesn't use devicetrees. With the newer kernel provided with version 3.0 this has changed. Now U-Boot provides an additional partition for the device tree and wants to use it when starting the kernel.
If you are developing on a fsimx6v2.x release without devicetrees (and you want to stay with it) you have to downgrade the U-Boot bootloader to be compatible.
So be aware that modules equipped with a new bootloader do not have to be compatible with your older version. In this case it is recommended to replace your U-Boot bootloader.
How to downgrade U-Boot?
F&S provides a script that downgrades your bootloader and restore your network address(es) afterwards. You can adjust it to your needs. The script runs in two iterations. First it exports the network address(es) and an additional variable in RAM and replaces the bootloader. Then it performs a reboot. In the second step the script checks if the additional variable is available. If so it knows that the first step has already been processed and won't repeat it. Now it sets the network adress(es) back as it had been before.
You can add more variables that you want to keep save during the downgrade. The text file of the script needs to be compiled with the mkimage tool. The result is an image with a checksum. To compile tpye:
This is how the script looks like:
- # This script can be used as part of an update/installation procedure. It
- # replaces the U-Boot bootloader to a different version (older or newer),
- # but keeps the network address(es). It is based on the F&S update mechanism
- # available in U-Boot, i.e. it assumes to be on an update device (USB stick or
- # SD card) and to be started automatically after a reboot.
- #
- # To convert the script text file to a U-Boot script image call:
- #
- # mkimage -A arm -O u-boot -T script -C none -n "Update script" \
- # -d update.txt update.scr
- #
- # - The script image has to be called "update.scr".
- # - It expects the "new" U-Boot image as "uboot.nb0" on the update device.
- # - It assumes that $loadaddr is the same in both U-Boot versions.
- # - The script is started twice, once in the existing "old" U-Boot and once in
- # the freshly installed "new" U-Boot after a reboot. It uses an exported
- # variable U=1 as a magic number in RAM to distinguish between the two runs.
- # - Variable $updatedev can be used to refer to the storage device that is
- # currently active in this update run, i.e. USB stick or SD card.
- #
- # RAM address where the exported environment is saved across the reboot
- setexpr upd $loadaddr - 0x100000
- #
- # In the first run, export environment to RAM and replace U-Boot
- # (value 0x0a313d55 of the test is "U=1<LF>" in little-endian byte order)
- if itest.l *$upd != 0x0a313d55
- then
- echo "---- Export environment ----"
- setenv U 1
- env export -t $upd U ethaddr eth1addr eth2addr
- echo "---- Replace U-Boot image ----"
- load $updatedev $loadaddr uboot.nb0
- nand erase.part UBoot
- nand write $loadaddr UBoot $filesize
- nand erase.part UBootEnv
- echo "---- Reboot ----"
- reset
- fi
- #
- # In the second run, import environment from RAM
- echo "---- Import saved environment ----"
- env import -t $upd U ethaddr eth1addr eth2addr
- env delete U
- saveenv
- #
- # Add your own update/installation commands here; avoid blank lines as this is
- # like just pressing Return which might re-execute the previous command
Best Regards
Your F&S Support Team
