[MinnowBoard] about system update
Krau, Michael P
michael.p.krau at intel.com
Thu May 14 02:08:07 UTC 2015
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<mailto: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<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<mailto: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<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<mailto: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<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<mailto: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<mailto:elinux-MinnowBoard at lists.elinux.org>
http://lists.elinux.org/mailman/listinfo/elinux-minnowboard
_______________________________________________
elinux-MinnowBoard mailing list
elinux-MinnowBoard at lists.elinux.org<mailto:elinux-MinnowBoard at lists.elinux.org>
http://lists.elinux.org/mailman/listinfo/elinux-minnowboard
_______________________________________________
elinux-MinnowBoard mailing list
elinux-MinnowBoard at lists.elinux.org<mailto: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/20150514/5f70fd93/attachment-0001.html>
More information about the elinux-MinnowBoard
mailing list