[MinnowBoard] about system update

Thu Apr 2 22:27:32 UTC 2015

Thank you for such a detailed reply.

Your information is very useful for us. Such information can not be found
in any manuals.

Could I ask you a clarification question acc. points 2 and 3:
Are uefi script and uefi apllicaton to be on the sata-disk? Or can they be
embeded into uefi firmware image?

2015-04-01 23:34 GMT+04:00 Krau, Michael P <michael.p.krau at intel.com>:

> Hello,
>
> If I understand you correctly, you are basically performing the following:
>
> 1) Upon the initial boot at power up, you wish to load an run one
> operating environment (from one SATA device), to perform some diagnostics
> or configuration modifications.
>
> 2) Once that process is complete, you wish to reboot the system to another
> operating environment (from another disk).
>
> The determination of where you are in the process (and success of each
> stage of the process) is handled by variables/flags tracking that data.
> (in a nutshell).
>
> From an UEFI point of view, there are three places (and methods) I can
> think of on how to perform this kind of operation.  They are basically
> targeting different points in the UEFI boot process, and vary in both
> inherent complexity and integration accordingly.
>
> 1) The most complex and integrated method would be to make modifications
> in the Boot Device Select part of the Firmware and create a custom firmware
> image for your platform.  This method would make the behavior a part of the
> platform, but also requires a degree of UEFI knowledge and the ability to
> create an entire firmware image from the Open Sources.  Basically, you
> would put your selection logic in the firmware code that makes the
> determination of where it will boot, and make the system perform to your
> custom boot policy.  (this requires not only UEFI knowledge, but will
> require making modifications to existing modules that go into the firmware
> image)
>
> 2) The middle ground is to intercept the boot loader on the disk with one
> of your own.  In this case, you create an UEFI application which launches
> the actual boot loaders from the drives based upon the values of the
> flags.  This will require you to write an UEFI application and place it on
> a boot drive in place of the primary boot loader (always booting to that
> device and application).  That application is stand alone, does not have to
> be in the Flash, and will work with the standard firmware image.  However
> it will require the following UEFI knowledge: How to read variables and how
> to launch other applications from multiple devices.
>
> 3) The least complex method is to create an UEFI shell script that will
> basically do the process under the shell and launch the appropriate boot
> loader form the appropriate disk.  Think of an Autoexec.bat which launches
> the correct OS based upon the parameters it can read.  Also, the shell
> program can simply drop you into the shell if the flag condition gets so
> confused that the logic has no correct option (letting you manually sort
> things out).  This method basically allows you to do a lot with minimal
> UEFI experience, but will also have the overhead of launching an
> intermediate execution environment for reach reboot (the shell).
>
> Regardless of the method you use, you will need to have a mechanism to
> report form your operating environment back into the boot process.  There
> are two mechanisms I can think of for this:
>
> 1) Use the UEFI non-volatile variables to set your flags accordingly
> (through UEFI runtime services when performed in your OS evironments).
>  This is more complex, but cleaner for the UEFI side of things, and makes
> for a more seamless flow.
>
> 2) Use the file system to store data in the form of a flag data.  This is
> a bit clunker, but does have the advantage of allowing you to easily change
> the flags in both operating environments and the UEFI shell, if manual
> testing and debug is necessary.
>
> So you can see where you have a lot of options, the question is what
> option would best meet your needs and the return on investment of the time
> to learn varying complexity  UEFI implementations.
>
> Sincerely,
>
>
>
> Michael Krau
>
> While I am an Intel employee, I do not represent Intel and am not
> authorized to speak for Intel.
>
> From: elinux-MinnowBoard [mailto:
> elinux-minnowboard-bounces at lists.elinux.org] On Behalf Of ??????? ????????
> Sent: Tuesday, March 31, 2015 11:14 PM
> To: elinux-minnowboard at lists.elinux.org
> Subject: [MinnowBoard] about system update
>
> Hello,
>
> In our project based on MinnowBoard Max we are planning to use two SATA
> disks for storage of two OS images. It is required for failure tolerance
> during updating the system and for failure of SATA disks.
> Operating procedure looks like the following:
> - During updating the system is rewriting on the disk which is not booting
> at the moment.
> - There is the efi variable named "os_changed". os_changed=1 in the system
> in the case of OS updatig and if the change of the boot disk is required.
> - There is the efi variable named "first_boot_done", which is used for
> algorithm correctness verifying of a new OS version.
> - After recording of a new OS version on the disk the system is rebooting.
> The variable "os_changed" is beeing analysed during rebooting. If
> os_changed=1 then:
>  1. the booting disk is changed
>  2. first_boot_done=0
> - By successful booting the OS and successful starting up the software
> first_boot_done=1, if something is wrong then the value of
> "first_boot_done" is equal to zero, os_changed=0 and the system are
> rebooting.
> - After rebooting the state of the variable "os_changed" and
> "first_boot_done" is analysing. If both of the variables are equal to 0,
> then the updated OS was not booted correctly and it is required to place
> back the previous boot disk.
>
> So we are planning to work out a problem of software fault tolerance  and
> power supply of the updating system. We tested this procedure in our
> embedded systems where we use the ARM processors and UBOOT loader.
>
> For the first time we deal with X86 and EFI and we have the following
> question how to realyse this procedure in EFI enviroment in the best way.
>
> We consider the followng variant at the moment:
> 1. To embed the analysis codes "os_changed" and "first_boot_done" into the
> code EFI.
>
>
> Perhaps there are any other ways of working out this problem. Because of
> the fact that we are newcomers in EFI we kindly ask the commnity to give us
> the professional advise for working out this problem in the best way in the
> point of safety and easy-to-use.
> Thank you.
> _______________________________________________
> elinux-MinnowBoard mailing list
> elinux-MinnowBoard at lists.elinux.org
> http://lists.elinux.org/mailman/listinfo/elinux-minnowboard
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.elinux.org/pipermail/elinux-minnowboard/attachments/20150403/d2f75b87/attachment.html>