From af48d2128006fa31a7b1bcf61ba81a273c410c01 Mon Sep 17 00:00:00 2001 From: Konstantin Aladyshev Date: Tue, 22 Mar 2022 11:45:19 +0300 Subject: Formatting to lesson 68 Signed-off-by: Konstantin Aladyshev --- Lessons/Lesson_68/README.md | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/Lessons/Lesson_68/README.md b/Lessons/Lesson_68/README.md index 016b62c..cfc9d72 100644 --- a/Lessons/Lesson_68/README.md +++ b/Lessons/Lesson_68/README.md @@ -1,6 +1,6 @@ # `oneof` element -`oneof` element allows to select on option from the predefined set (https://edk2-docs.gitbook.io/edk-ii-vfr-specification/2_vfr_description_in_bnf/211_vfr_form_definition#2.11.6.6.2-vfr-oneof-statement-definition) +`oneof` element allows to select an option from the predefined set (https://edk2-docs.gitbook.io/edk-ii-vfr-specification/2_vfr_description_in_bnf/211_vfr_form_definition#2.11.6.6.2-vfr-oneof-statement-definition) Add the folowing code to the `UefiLessonsPkg/HIIFormDataElements/Form.vfr` ``` @@ -31,7 +31,7 @@ typedef struct { } UEFI_VARIABLE_STRUCTURE; ``` -Once you load the form, you get: +Once you load the form, you would get: ![OneOf1](OneOf1.png?raw=true "OneOf1") @@ -43,11 +43,11 @@ If you select the option 2: ![OneOf3](OneOf3.png?raw=true "OneOf3") -The variable field would get the value `0x33`. If you want to, you can verify it with `dmpstore`. +The variable field would get the value `0x33`. If you want to, you can verify it with the `dmpstore` command. ## IFR -IFR code would look like this (Build/UefiLessonsPkg/RELEASE_GCC5/X64/UefiLessonsPkg/HIIFormDataElements/HIIFormDataElements/DEBUG/Form.lst): +IFR code would look like this (`Build/UefiLessonsPkg/RELEASE_GCC5/X64/UefiLessonsPkg/HIIFormDataElements/HIIFormDataElements/DEBUG/Form.lst`): ``` oneof >000000B4: 05 91 0F 00 10 00 06 00 01 00 20 00 00 10 00 55 00 @@ -151,7 +151,7 @@ Value The union of all of the different possible values. The actual contents ( of the field depends on Type. ``` -Description says that the content of the `Value` field is dependent on the value of the `Type` field. Here are all possible value types with comments of their type flags: +Description says that the content of the `Value` field is dependent on the value of the `Type` field. Here are all the possible value types with comments of their type flags: ``` typedef union { UINT8 u8; // EFI_IFR_TYPE_NUM_SIZE_8 @@ -243,7 +243,7 @@ typedef struct { } UEFI_VARIABLE_STRUCTURE; ``` -On load form looks like this: +On load our form would look like this: ![Orderedlist1](Orderedlist1.png?raw=true "Orderedlist1") @@ -251,7 +251,7 @@ If you select the element: ![Orderedlist2](Orderedlist2.png?raw=true "Orderedlist2") -You can change order by selecting an option and moving it up or down with the help of `+` and `-` keys: +You can change its order by moving it up or down with the help of `+` and `-` keys: ![Orderedlist3](Orderedlist3.png?raw=true "Orderedlist3") @@ -266,7 +266,7 @@ This would get the following data in the `OrderedListValue` field of our UEFI va ## IFR -Let's look at the IFR code: `Build/UefiLessonsPkg/RELEASE_GCC5/X64/UefiLessonsPkg/HIIFormDataElements/HIIFormDataElements/DEBUG/Form.lst`: +Let's look at the IFR code (`Build/UefiLessonsPkg/RELEASE_GCC5/X64/UefiLessonsPkg/HIIFormDataElements/HIIFormDataElements/DEBUG/Form.lst`): ``` orderedlist >000000DC: 23 8F 14 00 15 00 07 00 01 00 21 00 00 03 00 @@ -283,7 +283,7 @@ Let's look at the IFR code: `Build/UefiLessonsPkg/RELEASE_GCC5/X64/UefiLessonsPk >00000100: 29 02 ``` -First element if `EFI_IFR_ORDERED_LIST`: +First code element is `EFI_IFR_ORDERED_LIST`: ``` EFI_IFR_ORDERED_LIST @@ -320,9 +320,9 @@ UINT8 Flags; // 0x00 Everything is in order, our element has 3 options, and therefore `MaxContainers=0x03`. -If you look at the options IFR code you could see that the options are encoded with the same opcode `EFI_IFR_ONE_OF_OPTION` that was used in `oneof` element. +If you look at the options IFR code you could see that the options are encoded with the same opcode `EFI_IFR_ONE_OF_OPTION` that was used in the `oneof` element. -Therefore the principle is the same. If you encode our data as `UINT16` instead of `UINT8` +Here the principle is the same. If you encode our data as `UINT16` instead of `UINT8` ``` UINT16 OrderedListValue[3]; ``` @@ -336,7 +336,7 @@ With the `orderedlist` it is even possible to use non-numeric data types. For ex EFI_HII_DATE OrderedListValue[3]; ``` -Change the code in VFR: +For this off course you need to change the code in VFR: ``` orderedlist varid = FormData.OrderedListValue, @@ -348,7 +348,7 @@ orderedlist endlist; ``` -If you parse IFR data now, you could see that every option is encoded with `#define EFI_IFR_TYPE_DATE 0x06` type: +If you parse IFR data for such code, you could see that every option is encoded with `#define EFI_IFR_TYPE_DATE 0x06` type: ``` orderedlist >000000DC: 23 8F 14 00 15 00 07 00 01 00 21 00 00 0C 00 @@ -365,6 +365,6 @@ If you parse IFR data now, you could see that every option is encoded with `#def >00000109: 29 02 ``` -If the data array has a size lower than amount of available option, everything would compile, but in the HII, you would see only the first `array size` options. For example `UINT8 OrderedListValue[2]` would result to: +If the data array has a size lower than amount of available options, everything would compile, but in the HII, you would see only the first `array size` options. For example `UINT8 OrderedListValue[2]` would result to: ![Orderedlistr5](Orderedlist5.png?raw=true "Orderedlist5") -- cgit v1.2.3-18-g5258