BMC update via TFTP

Milton Miller II miltonm at us.ibm.com
Thu Dec 12 08:51:24 AEDT 2019


On 12/10/2019 around 10:57PM in some timezone, Bonnie Lo/WYHQ/Wiwynn  wrote:
>In my understanding, the BMC firmware update flow is as below:
>1. Trigger reboot 
>2. Systemd stop all service
>3. Unmount file system
>4. image is in /run/initramfs 
>5. Do the flashcp command to update the flash 
>
>If there is any misunderstanding, please correct me.
>
>Based on the discussion with Neeraj.
>We want to be able to update BMC firmware without having to trigger
>the BMC reboot command before the system do flashcp command.
>It means that we can do the flashcp first. If the flashcp command
>complete and success, then we do the reset manually.
>Is it workable on current upstream code?
>If not, why? I means is there any advantage to trigger the reboot
>before we do the flashcp.

The init script in the initramfs takes options from u-boot variables 
and the kernel command line.  Some of the options allow that the
read-only and files in the read-write partition are copied into RAM
before the file systems are mounted, which allows the BMC to be
operational while the new flash image is transfered and written into
the flash.  Note that if a reboot is triggered for some reason you 
can still end up needing additional recovery.

This state can be initiated by "prepare for update" mentioned in
the REST documentation for code-update.  I don't think it can be
initiated in the current Redfish.

The flow is:

1. Trigger "prepare for update" 

    - This uses the variable cleared every boot to copy 
       rw partition content to ram (tmpfs), and the mtd ro partition 
       ram (as a file then mounted by loop device).

2. Upload images as before

    - They will be signature checked as compiled then coped to /run/initramfs

3. run /run/initramfs/update

  - This script will look at /proc/mounts and see that the mtd-ro and mtdrw
   partitions are not present, and proceed to flashcp the files to the flash

  - WARNING: do not try to hide the mounts by unmounting the mtd ro and
   rw partitions.  The root file system is overlayfs and will retain write access
  to the flash, and your BMC will crash


4. Initiate reboot at leisure to move to new code level

  - the contents of the tmpfs with the overlay files will be copied back to 
    the rwfs file system in the mtd partitions

Note:  This is not the normal operation in part because the rwfs is
in tmpfs and therefore any panic or power cut will result in all modifications
to the rwfs being lost.


If needed I can lookup the exact variable names and contents to 
communicate the desired maintenance actions from the phosphor 
init script.  There are two variables, one for persistent settings, 
one for transient settings which a script clears each time.   One
can also customize or disable this features by adding additional
customization files into the initramfs recipe. 

milton


>>Thanks,
>Bonnie
>



More information about the openbmc mailing list