Environment for running local DHCOM Update: Difference between revisions

From Wiki-DB
Jump to navigationJump to search
Finished writing the draft of the documentation
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 will write to the wrong location on the flash. This may cause that the system won't work anymore.
* 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 ==


When 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, other modules can differ here (like the AM335X: There the eMMC has the device number 1).
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.