Environment for running local DHCOM Update: Difference between revisions
Pzimmermann (talk | contribs) Finished writing the draft of the documentation |
Pzimmermann (talk | contribs) Added explanation of some additional variables |
||
(2 intermediate revisions by the same user not shown) | |||
Line 6: | Line 6: | ||
* A spare partition on the eMMC (NAND-flash is usually too small) where the components of the update are stored. | * A spare partition on the eMMC (NAND-flash is usually too small) where the components of the update are stored. | ||
* U-Boot must be built with the <tt>setexpr</tt>-command included (This command is used for arithmetic expressions). | * U-Boot must be built with the <tt>setexpr</tt>-command included (This command is used for arithmetic expressions). | ||
* The Linux on the DHSOM-System needs the fw-tools for accessing the bootloader environment. '''WARNING''': The configuration of the fw-tools must match the layout of the bootflash, else when setting the environment, the command | * The Linux on the DHSOM-System needs the <tt>fw-tools</tt> for accessing the bootloader environment. '''WARNING''': The configuration of the <tt>fw-tools</tt> must match the layout of the bootflash, else when setting the environment, the command may write to the wrong location on the flash. This may cause that the system won't work anymore. | ||
== Setting up the Environment == | == Setting up the Environment == | ||
Line 34: | Line 34: | ||
|} | |} | ||
You have to alter the <tt>bootcmd</tt> variable that the check is run. You have to add <tt> run check_if_local_update;</tt> after the <tt>update auto;</tt> part. | These variables are referenced by the prior variables: | ||
{| class="wikitable" | |||
|- | |||
! Name !! Function of the variable | |||
|- | |||
| src_intf|| This is the type of interface where the update is located (mmc or usb). The variable has to be set when the update is activated. | |||
|- | |||
| src_dev_part || Here the device number of the used device and the partition where the update is stored in the form <tt><device_number>:<partition></tt>. The variable has to be set when the update is activated. Note that the device numbers start with 0, while the partition numbers start with 1. | |||
|- | |||
| loadaddr || This variable contains an address where the kernel is loaded onto RAM. This is preset in the environment and nothing has to be changed here by the user. | |||
|- | |||
| setupdateargs || This variable contains a script, which sets up the bootargs of the update-kernel. <tt>src_intf</tt> and <tt>src_dev_part</tt> are given to the kernel as arguments, so the software inside the kernel can determine where the update is located (the <tt>CMDLINE</tt> environment variable contains a list of all bootargs of the kernel). | |||
|} | |||
You have to alter the <tt>bootcmd</tt> variable (is always executed at startup of the module) that the check is run. You have to add <tt> run check_if_local_update;</tt> after the <tt>update auto;</tt> part. | |||
For a standard i.MX6-based DHSOM-module the needed command should look like this: | For a standard i.MX6-based DHSOM-module the needed command should look like this: | ||
<tt>fw_setenv bootcmd 'update auto; run check_if_local_update; mmc dev ${mmcdev}; if mmc rescan; then run bootlinux; else echo Boot failed, because mmc${mmcdev} not found!;fi;</tt> | <tt>fw_setenv bootcmd 'update auto; run check_if_local_update; mmc dev ${mmcdev}; if mmc rescan; then run bootlinux; else echo Boot failed, because mmc${mmcdev} not found!;fi;</tt> | ||
Line 45: | Line 59: | ||
== Activate Booting Update Kernel == | == Activate Booting Update Kernel == | ||
After the update image and the update-kernel is put onto the device, you can activate the update from inside the Linux. The following example assumes that the components of the update are on the third partition of the eMMC of an i.MX6 based DHSOM-module. The eMMC on the i.MX6 has the device number 2, on other modules this can be different (like the AM335X: There the eMMC has the device number 1). | |||
<tt>fw_setenv local_update true | <tt>fw_setenv local_update true | ||
Line 61: | Line 75: | ||
fw_setenv src_dev_part</tt> | fw_setenv src_dev_part</tt> | ||
If the update fails the update tried again until <tt>local_update_tries</tt> hits the number in <tt>local_update_max_tries</tt>. After that the bootloader tries to boot the system as normal. You can see that the update was aborted from inside the Linux system if the variables <tt>local_update</tt> is <tt>true</tt> and <tt>local_update_tries</tt> contains the same number as <tt>local_update_max_tries</tt>. You can use the command <tt>fw_printenv</tt> to read the content of these variables. | If the update fails the update will be tried again until <tt>local_update_tries</tt> hits the number in <tt>local_update_max_tries</tt>. After that the bootloader tries to boot the system as normal. You can see that the update was aborted from inside the Linux system if the variables <tt>local_update</tt> is <tt>true</tt> and <tt>local_update_tries</tt> contains the same number as <tt>local_update_max_tries</tt>. You can use the command <tt>fw_printenv</tt> to read the content of these variables. |
Latest revision as of 11:00, 1 February 2021
If you want to make a update of your DHSOM system, without using an USB-stick or a SD-card, it is possible to alter the environment of U-Boot to start a local version of the DHCOM Update Mechanism.
Requirements
The DHSOM system requires the following things:
- A spare partition on the eMMC (NAND-flash is usually too small) where the components of the update are stored.
- U-Boot must be built with the setexpr-command included (This command is used for arithmetic expressions).
- The Linux on the DHSOM-System needs the fw-tools for accessing the bootloader environment. WARNING: The configuration of the fw-tools must match the layout of the bootflash, else when setting the environment, the command may write to the wrong location on the flash. This may cause that the system won't work anymore.
Setting up the Environment
Use the following commands as root (or prepend them with sudo) to set up the bootloader environment:
fw_setenv local_update false fw_setenv local_update_tries 0 fw_setenv local_update_max_tries 3 fw_setenv check_if_local_update 'if test "${local_update}" = "true" -a ${local_update_tries} -lt ${local_update_max_tries} ; then run do_local_update; fi' fw_setenv do_local_update 'setexpr local_update_tries ${local_update_tries} + 1; saveenv; load ${src_intf} ${src_dev_part} ${loadaddr} zImage_${dhcom}.update; run setupdateargs; bootz ${loadaddr}'
Here is a short explanation what each variable does:
Name | Function of the variable |
---|---|
local_update | This is a flag which determines if an update via local DHCOM_Update should be made. The user can set this to true to activate the update. |
local_update_tries | Here the number of tries to update the system is stored. On each start of an update this counter is increased by one. If the update finishes successful the counter should be set to 0. |
local_update_max_tries | This variable stores a number which says how often an update should be tried, before it is aborted. At the command atop this is set to 3. |
check_if_local_update | This variable contains a script. Here is checked if local_update is true and if local_update_tries is less then local_update_max_tries. If both are true, the script at variable do_local_update is run, else nothing happens. |
do_local_update | This script increments local_update_tries by one and saves the new value. Then the update-kernel is loaded into memory. The variables src_intf and src_dev_part determine which interface, device and partition are used for this. After that the script setupdateargs (which is also used by the regular update kernel) is run. Now the update-kernel is loaded. |
These variables are referenced by the prior variables:
Name | Function of the variable |
---|---|
src_intf | This is the type of interface where the update is located (mmc or usb). The variable has to be set when the update is activated. |
src_dev_part | Here the device number of the used device and the partition where the update is stored in the form <device_number>:<partition>. The variable has to be set when the update is activated. Note that the device numbers start with 0, while the partition numbers start with 1. |
loadaddr | This variable contains an address where the kernel is loaded onto RAM. This is preset in the environment and nothing has to be changed here by the user. |
setupdateargs | This variable contains a script, which sets up the bootargs of the update-kernel. src_intf and src_dev_part are given to the kernel as arguments, so the software inside the kernel can determine where the update is located (the CMDLINE environment variable contains a list of all bootargs of the kernel). |
You have to alter the bootcmd variable (is always executed at startup of the module) that the check is run. You have to add run check_if_local_update; after the update auto; part. For a standard i.MX6-based DHSOM-module the needed command should look like this:
fw_setenv bootcmd 'update auto; run check_if_local_update; mmc dev ${mmcdev}; if mmc rescan; then run bootlinux; else echo Boot failed, because mmc${mmcdev} not found!;fi;
On other DHSOM-modules the needed bootcmd may vary.
When connected to the DHSOM module via serial cable, it is also possible to make these changes to the environment from the U-Boot console. There are two differences when doing this from the U-Boot console:
- Instead of using the fw_setenv command you have to use setenv which is the built in command of U-Boot.
- After the last command you have to use saveenv to save the changed environment. Without doing this the changes will be lost after the next reboot of the module.
Activate Booting Update Kernel
After the update image and the update-kernel is put onto the device, you can activate the update from inside the Linux. The following example assumes that the components of the update are on the third partition of the eMMC of an i.MX6 based DHSOM-module. The eMMC on the i.MX6 has the device number 2, on other modules this can be different (like the AM335X: There the eMMC has the device number 1).
fw_setenv local_update true fw_setenv local_update_tries 0 fw_setenv src_intf mmc fw_setenv src_dev_part 2:3
At the next reboot the update will be executed.
After the update has finished, the update mechanism must disable the local update or else the update will be triggered again. The following commands do unset the source variables and reset the counter and flag:
fw_setenv local_update false fw_setenv local_update_tries 0 fw_setenv src_intf fw_setenv src_dev_part
If the update fails the update will be tried again until local_update_tries hits the number in local_update_max_tries. After that the bootloader tries to boot the system as normal. You can see that the update was aborted from inside the Linux system if the variables local_update is true and local_update_tries contains the same number as local_update_max_tries. You can use the command fw_printenv to read the content of these variables.