[MinnowBoard] about system update

Дмитрий Оботуров oboturoff at gmail.com
Sun Apr 26 23:05:42 UTC 2015


Thank you for your informative replies.

It took us some time to get more information about uefi.

Now we develop functions which implement our algorythm for uefi and at the
same time we write userspace application to get an opportunity for
modifying of uefi variables from userspace linux.

Please help us in resolving of the following question.
There is the "efibootmgr" utility in linux.
1. We run it from the command line as follows: efibootmgr -N
2. Then we run it again: efibootmgr -n 0001
3. We reboot MinnowBoardMax and enter Shell uefi. Then we run dmpstore
BootNext. uefi can't find the variable BootNext. What is the reason of this
problem? At the same time the modifying of the BootOrder variable performs
correctly by using of efibootmgr


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

> 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
>
> _______________________________________________
> 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/20150427/5bb48bba/attachment.html>


More information about the elinux-MinnowBoard mailing list