[MinnowBoard] about system update
Krau, Michael P
michael.p.krau at intel.com
Thu Apr 2 23:03:24 UTC 2015
Glad to be of help
The application can be added to the ROM image as part of the shell, allowing you to execute it as a shell command. But that would not be automatic, unless you had a shell script (like in method 3) that launched the application at shell startup.
You could also do the same thing through the BDS modifications in step one, where BDS allow you to boot to this application (like boot to shell). However, it might be easier to modify the BDS per step one than to modify the BDS to load an application that has to be written from scratch.
As described below, the application was actually to take the place of the general boot loader to add another step in the boot strap process.
Basically the boot process, will load a boot loader (which is a an UEFI application with an understanding of how to launch the OS environment) for the boot device and the boot loader will be able to use it intrinsic understand of UEFI and the targeted OS environment to bridge the gap between the two and hand off control from UEFI to the OS.
The new application would effectively replace the OS boot loader (which would be renamed but available), and make the boot decisions (which device and boot loader to launch) once the firmware launches it.
I the case of the shell script, the shell script is actually a DOS-Like Script that requires the Shell to execute. It would typically reside on the disk drive. There may be a way to include it in the firmware part, but doing so could increase the complexity of the solution to where option 1 or two might be easier.
There are sources for this information, but I will admit that this is from a combination of UEFI training materials (available on-line) and some experience with the UEFI Specification (Chapter 3 Boot Manager), which focuses more on how things work than how to do something unique within that framework.
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: Thursday, April 02, 2015 3:28 PM
To: MinnowBoard Development and Community Discussion
Subject: Re: [MinnowBoard] about system update
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
More information about the elinux-MinnowBoard
mailing list