[MinnowBoard] about system update

Дмитрий Оботуров oboturoff at gmail.com
Sat May 16 00:48:09 UTC 2015


Ok.
Your answers to the questions 2 and 3 are clear to me.  Unfortunately I
didn't understand your answer to the question nr.1 therefore I ask it again
but with other words.

There is a concept called Device Path in efi. For example  there is Device
Path :PciRoot(0x0)/Pci(0x13,0x0)/Sata(0x0,0x0,0x0) for sata drive. There
are also variables Boot0001, Boot0002 and the variable  BootOrder which
establish the order of a  bootable device.

Is there any link between Device Path and the variables BootХХХХ? With
other words by using the following function EfiVar =
BdsLibGetVariableAndSize (
                    L"Boot0001",
                    &gEfiGlobalVariableGuid,
                    &EfiVarSize
                    );
we get the variable size in EfiVarSize and the variable content in  EfiVar.
In the graphical version of efi we can see opposite each variable BootXXXX
its Device Path in menu "Boot Manager".  How can we get Device Path for the
varables BootХХХХ from the source code of efi?

And how can we get the name of the variable BootXXXX wich Device Path is =
:PciRoot(0x0)/Pci(0x13,0x0)/Sata(0x0,0x0,0x0)?

All above described  refers to the source code of efi. We have also an
utility wich runs in userspace in linux. Therefore we have the same
question for linux. Can we get Device Path for the variable BootXXX under
linux?

I understand that this is a specifical question and we tried to find a
solution by ourselfs but we could't. Therefore we kindly ask you to help
us. Thank you in advance.


2015-05-14 5:08 GMT+03:00 Krau, Michael P <michael.p.krau at intel.com>:

>  Hello,
>
>
>
> Per your questions:
>
>
>
> 1)      The Boot0001, Boot0002… variables.  In the UEFI specification
> they are discussed as part of the “boot manager” (section 3.1 of the
> specification).  They are referred to as the “Bootxxxx” variables, which
> relate to the Bootxxxx devices.  The ‘xxxx’ is the representation of the
> hexadecimal umber , like 0001, 0002… FFFE, FFFF.
>
>
>
> The Bootxxxx variables are standard global variables defined as part of
> the boot manager operations (also Chapter 3.1 UEFI Specification).
>
>
>
> The path is not the path for the variable, but rather the variable
> establishes the order of a  bootable device in the boot device table, and
> the path you are referring is the path to that device.
>
>
>
> The UEFI specification is openly available at http://UEFI.org .  It is
> big, but  much of it is not related to your question.
>
>
>
>
>
> 2)      The GCC Build on MinnowBoard MAX is using the smaller shell as
> the MinnowBoard MAX has a limited Firmware size, and the current GCC build
> can generate more code than can fit in the part (a question of
> optimization).  Using the smaller shell allows the build to fit everything
> in the space by reducing the size (and features) of the shell.
>
>
>
> QEMU does not have that hardware limitation, so it was provided with the
> full shell.  If you wish to attempt the build in GCC with the full shell,
> look in the file: Vlv2TbltDevicePkg/PlatformPkgGcc.fdf for the string
> “shell” and you will find the following:
>
>
>
> # UEFI Shell
>
> #
>
> FILE APPLICATION =
> PCD(gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdShellFile) {
>
> #    SECTION PE32 =
> EdkShellBinPkg/FullShell/$(EDK_DXE_ARCHITECTURE)/Shell_Full.efi
>
>    SECTION PE32 =
> EdkShellBinPkg/MinimumShell/$(EDK_DXE_ARCHITECTURE)/Shell.efi
>
>   }
>
>
>
> Change to:
>
>
>
> # UEFI Shell
>
> #
>
> FILE APPLICATION =
> PCD(gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdShellFile) {
>
>    SECTION PE32 =
> EdkShellBinPkg/FullShell/$(EDK_DXE_ARCHITECTURE)/Shell_Full.efi
>
> #    SECTION PE32 =
> EdkShellBinPkg/MinimumShell/$(EDK_DXE_ARCHITECTURE)/Shell.efi
>
>   }
>
>
>
> To turn on the full shell in the build.  This will grab the prebuilt Full
> shell and add it to the firmware image.
>
>
>
> Also, you can create your own shell version using the shell sources and
> modifying the DSC to build only those components of interest.  However the
> GCC non-optimization will compound, as the pre-built shell .efi files were
> built with a more optimized build, and will therefore be smaller.
>
>
>
>
>
> 3)      I am not an expert on this section of the code, but it should be
> part of the Boot device select (BDS) phase of the boot process.  This is in
> the directory IntelFramworkModulePkg\Universal\BdsDxe.  Per the header of
> the file BdsEntry.c:
>
>
>
> This module produce main entry for BDS phase - BdsEntry.
>
>   When this module was dispatched by DxeCore, gEfiBdsArchProtocolGuid will
> be installed
>
>   which contains interface of BdsEntry.
>
>   After DxeCore finish DXE phase, gEfiBdsArchProtocolGuid->BdsEntry will
> be invoked
>
>   to enter BDS phase.
>
>
>
> It is during the boot device select phase that the boot order is parsed.
> The boot order is established by the Boot manager but you may want to
> consider looking at the Var_ functions in Variable.c in the
> IntelFramworkModulePkg\Universal\BdsDxe\BootMaint directory.
>
>
>
>
>
>
>
> 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:* Wednesday, May 13, 2015 3:24 PM
>
> *To:* MinnowBoard Development and Community Discussion
> *Subject:* Re: [MinnowBoard] about system update
>
>
>
> We have some more questions about source code of efi. We kindly ask you
> about advise.
>
> 1. There are variables Boot0001, Boot0002 and other in efi. Each variable
> has its own Device Path. And it looks like follows:
> Device Path :PciRoot(0x0)/Pci(0x13,0x0)/Sata(0x0,0x0,0x0)
>
> The variable efi can be read like follows for example (or somehow else, it
> is not the point):
> EfiVar = BdsLibGetVariableAndSize (
>                     L"Boot0001",
>                     &gEfiGlobalVariableGuid,
>                     &EfiVarSize
>                     );
>
> How can we get Device Path for this variable? And how can we get the name
> of variable having Device Path?
> 
> 2. In case uefi will be build according to ReleaseNotes.txt from the site
> http://firmware.intel.com we get the version with a small shell. At the
> same time by using the file Build/OvmfX64/DEBUG_GCC46/FV/OVMF.fd for
> running in qemu we get the full version of shell. For getting the full
> version of the file firmware - we changed the file
> Vlv2TbltDevicePkg/PlatformPkgGcc.fdf. Is it right? Where in documentation
> can we get the information about it?
>
> 3. How do you think where is the best point in the source code uefi for
> placing of our function which will change the variable BootOrder forcedly
> according to our internal logic. ( please point out the file name and
> functions where we should do it)
>
> Thank you.
>
>
>
>
>
> 2015-04-27 8:20 GMT+03:00 Wei, David <david.wei at intel.com>:
>
> Before the UEFI BIOS boot to some OS boot loader(or UEFI Shell), UEFI BIOS
> checks BootNext variable and takes it as the first bootable device if it
> exists. Then UEFI BIOS deletes the BootNext variable and boots to OS
> loader(or UEFI Shell).  So dmpstore, which runs under UEFI shell, will
> never have a chance to get  BootNext variable.
>
>
>
> Thanks,
>
> David | SSG BIOS
>
>
>
> *From:* elinux-MinnowBoard [mailto:
> elinux-minnowboard-bounces at lists.elinux.org] *On Behalf Of *Дмитрий
> Оботуров
> *Sent:* Monday, April 27, 2015 7:06 AM
>
>
> *To:* MinnowBoard Development and Community Discussion
> *Subject:* Re: [MinnowBoard] about system update
>
>
>
>
> 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
>
>
>
>
> _______________________________________________
> 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/20150516/680f0bfa/attachment-0001.html>


More information about the elinux-MinnowBoard mailing list