<div dir="ltr"><div>Thank you for such a detailed reply. <br><br></div><div>Your information is very useful for us. Such information can not be found in any manuals.<br><br></div><div>Could I ask you a clarification question acc. points 2 and 3:<br></div><div>Are uefi script and uefi apllicaton to be on the sata-disk? Or can they be embeded into uefi firmware image?</div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-04-01 23:34 GMT+04:00 Krau, Michael P <span dir="ltr"><<a href="mailto:michael.p.krau@intel.com" target="_blank">michael.p.krau@intel.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<br>
If I understand you correctly, you are basically performing the following:<br>
<br>
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.<br>
<br>
2) Once that process is complete, you wish to reboot the system to another operating environment (from another disk).<br>
<br>
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.<br>
(in a nutshell).<br>
<br>
>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.<br>
<br>
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)<br>
<br>
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.<br>
<br>
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).<br>
<br>
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:<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Sincerely,<br>
<br>
<br>
<br>
Michael Krau<br>
<br>
While I am an Intel employee, I do not represent Intel and am not authorized to speak for Intel. <br>
<br>
From: elinux-MinnowBoard [mailto:<a href="mailto:elinux-minnowboard-bounces@lists.elinux.org">elinux-minnowboard-bounces@lists.elinux.org</a>] On Behalf Of ??????? ????????<br>
Sent: Tuesday, March 31, 2015 11:14 PM<br>
To: <a href="mailto:elinux-minnowboard@lists.elinux.org">elinux-minnowboard@lists.elinux.org</a><br>
Subject: [MinnowBoard] about system update<br>
<div><div class="h5"><br>
Hello,<br>
<br>
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. <br>
Operating procedure looks like the following:<br>
- During updating the system is rewriting on the disk which is not booting at the moment. <br>
- 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.<br>
- There is the efi variable named "first_boot_done", which is used for algorithm correctness verifying of a new OS version.<br>
- 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:<br>
1. the booting disk is changed<br>
2. first_boot_done=0<br>
- 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.<br>
- 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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
We consider the followng variant at the moment:<br>
1. To embed the analysis codes "os_changed" and "first_boot_done" into the code EFI.<br>
<br>
<br>
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.<br>
Thank you.<br>
</div></div>_______________________________________________<br>
elinux-MinnowBoard mailing list<br>
<a href="mailto:elinux-MinnowBoard@lists.elinux.org">elinux-MinnowBoard@lists.elinux.org</a><br>
<a href="http://lists.elinux.org/mailman/listinfo/elinux-minnowboard" target="_blank">http://lists.elinux.org/mailman/listinfo/elinux-minnowboard</a><br>
</blockquote></div><br></div>