Eric -
Here was my original proposal (see the bottom of the thread)
BTW, I suggest that the buffer grammar in VFR be "{" byte-list "}" and
byte-list := <byte-list "," integer> | integer
So the example would be:
option text = STRING_TOKEN(0x006F), value = {2, 1, 3}, flags =
0;
For a buffer case, I'm not sure how the UI would display it. One way is to
create something like this:
Xxx // UINT8 option
Yyy // UINT8 option
-------
USB First // Buffer option
That is, they would all appear in the list, with a separator to show the buffer
options.
Tim
From: Dong, Eric [mailto:eric.d...@intel.com]
Sent: Wednesday, September 24, 2014 12:31 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] HII ORDERED_LIST support
I think this sample code is always return UINT8 type, the difference between
your proposal and my proposal is the "," or " ", just like below
Your proposal:
option text = STRING_TOKEN(0x006F), value = 2, 1, 3, flags = 0;
My proposal:
option text = STRING_TOKEN(0x006F), value = 2 1 3, flags = 0;
I think our proposal both has the same problem which is raised by you.
Also I think if enable option opcode for buffer type, we can't describe it when
it used in the ordered list op-code. Sample code shows below. do you think so?
If we support buffer type for option, take below code for example:
orderedlist
varid = MyIfrNVData.BootOrder,
prompt = STRING_TOKEN(0x006D),
help = STRING_TOKEN(0x0059),
option text = STRING_TOKEN(0x006F), value = 2, 1, 3, flags = 0;
endlist;
the result shows like below, how can user to change the order for this case?
[cid:image004.png@01CFD72D.0304CC60]
Thanks,
Eric
From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Wednesday, September 24, 2014 3:51 AM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: Re: [edk2] HII ORDERED_LIST support
Eric -
The new grammar is ambiguous because it is impossible to tell whether the
following statement is a UINT8 or a Buffer of size 1.
option text = STRING_TOKEN(0x006F), value = 2, flags = 0;
Since, in my proposal, the behavior of these two value types have different
behaviors for ORDERED_LIST, it is important to distinguish between them.
Tim
From: Dong, Eric [mailto:eric.d...@intel.com]
Sent: Thursday, September 04, 2014 8:02 PM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: Re: [edk2] HII ORDERED_LIST support
Tim,
For option, current it only has one value and one prompt string " EFI_STRING_ID
Option; ". For below example:
orderedlist
varid = MyIfrNVData.BootOrder,
prompt = STRING_TOKEN(0x006D),
help = STRING_TOKEN(0x0059),
option text = STRING_TOKEN(0x006F), value = 2, flags = 0;
option text = STRING_TOKEN(0x006E), value = 1, flags = DEFAULT;
option text = STRING_TOKEN(0x0070), value = 3, flags = 0;
endlist;
the result shows like below, and user can change the option order.
[cid:image002.png@01CFD7D4.96067D40]
If we support buffer type for option, take below code for example:
orderedlist
varid = MyIfrNVData.BootOrder,
prompt = STRING_TOKEN(0x006D),
help = STRING_TOKEN(0x0059),
option text = STRING_TOKEN(0x006F), value = 2, 1, 3, flags = 0;
endlist;
the result shows like below, how can user to change the order for this case?
[cid:image001.png@01CFD7D4.96067D40]
For the buffer grammar in VFR, because we already has an opcode "ideqvallist"
which has the similar format, so I follow this style to define the buffer
grammar.
numeric varid = MyIfrNVData.HowOldAreYouInYearsManual,
prompt = STRING_TOKEN(STR_NUMERIC_MANUAL_PROMPT),
help = STRING_TOKEN(STR_NUMERIC_HELP0),
minimum = 0,
maximum = 0xf0,
step = 0,
default value = questionrefval(devicepath = STRING_TOKEN
(STR_DEVICE_PATH), guid = DRIVER_SAMPLE_FORMSET_GUID, 0x1111),
inconsistentif prompt = STRING_TOKEN(STR_ERROR_POPUP),
ideqval MyIfrNVData.HowOldAreYouInYearsManual == 99
OR
ideqid MyIfrNVData.HowOldAreYouInYearsManual == MyEfiVar.Field8
OR
ideqvallist MyIfrNVData.HowOldAreYouInYearsManual == 1 3 5 7
endif
endnumeric;
orderedlist
varid = MyIfrNVData.BootOrder,
prompt = STRING_TOKEN(0x006D),
help = STRING_TOKEN(0x0059),
option text = STRING_TOKEN(0x006F), value = 2 1 3, flags = 0;
endlist;
Thanks,
Eric
From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Friday, September 05, 2014 8:09 AM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: Re: [edk2] HII ORDERED_LIST support
Eric -
Here is the basic idea:
typedef struct _EFI_IFR_ONE_OF_OPTION {
EFI_IFR_OP_HEADER Header;
EFI_STRING_ID Option;
UINT8 Flags;
UINT8 Type; <<= For ORDERED_LIST, can be EFI_IFR_TYPE_NUM_SIZE_8 or
EFI_IFR_TYPE_BUFFER
EFI_IFR_TYPE_VALUE Value;
} EFI_IFR_ONE_OF_OPTION;
typedef struct _EFI_IFR_DEFAULT {
EFI_IFR_OP_HEADER Header;
UINT16 DefaultId;
UINT8 Type; <<= For ORDERED_LIST, can be EFI_IFR_TYPE_NUM_SIZE_8 or
EFI_IFR_TYPE_BUFFER
EFI_IFR_TYPE_VALUE Value;
} EFI_IFR_DEFAULT;
For EFI_IFR_ORDERED_LIST only, the nested EFI_IFR_ONE_OF_OPTION can be either
EFI_IFR_TYPE_NUM_SIZE_8 or EFI_IFR_TYPE_BUFFER. If it is
EFI_IFR_TYPE_NUM_SIZE_8, then the option value is only for a single container.
But if it is EFI_IFR_TYPE_BUFFER, then it is for all containers. If
EFI_IFR_TYPE_BUFFER and the number of bytes is smaller than the number of
containers, then remaining containers are set to 0 (empty)
Same with EFI_IFR_DEFAULT.
BTW, I suggest that the buffer grammar in VFR be "{" byte-list "}" and
byte-list := <byte-list "," integer> | integer
Tim
From: Dong, Eric [mailto:eric.d...@intel.com]
Sent: Wednesday, September 03, 2014 6:31 PM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: Re: [edk2] HII ORDERED_LIST support
Tim,
Add my comments below.
From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Thursday, September 04, 2014 12:04 AM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: Re: [edk2] HII ORDERED_LIST support
Eric -
Here is what I am thinking: we can extend the UEFI specification (which I will
do in a separate ECR), to allow either the UINT8 or the BUFFER value for
"option" and "default" If UINT8, then it will work on a single container. If
BUFFER then it works on all containers. It may take me a week (after IDF) to
get the ECR written for UEFI.
[[[Eric]]] If in BUFFER type, we can create a sample like below. In this case,
only one "text" for this option, how to show the different value for this
orderedlist? Maybe we need to update the "text" field also? I agree it has
value to support BUFFER type for default opcode, because in this case we can
set default value for "orderedlist" opcode. But I don't know the value to
support BUFFER for "option"? It will make the "option" more complicate to
handle. Also the "option" can be used for "Oneof" opcode, we also need consider
this opcode when we clarify the "option" opcode.
orderedlist
varid = MyIfrNVData.BootOrder,
prompt = STRING_TOKEN(0x006D),
help = STRING_TOKEN(0x0059),
option text = STRING_TOKEN(0x006F), value = 2 1 3, flags = 0;
endlist;
I think that if we document this behavior, it will be useful.
Are there any other question types where there are multiple value types
possible? Obviously UINTx. How about CHECKBOX with integer? Or NUMERIC with
BOOLEAN? Just thinking ahead.
[[[Eric]]] I think we don't have that question.
Tim
From: Dong, Eric [mailto:eric.d...@intel.com]
Sent: Tuesday, September 02, 2014 10:45 PM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: Re: [edk2] HII ORDERED_LIST support
After internal discussion, we agree default opcode can support ordered list
opcode, I will follow up to enable it.
For your proposal, item 2 I think it's not an acceptable proposal, take below
code for example:
orderedlist
varid = MyIfrNVData.BootOrder,
prompt = STRING_TOKEN(0x006D),
help = STRING_TOKEN(0x0059),
option text = STRING_TOKEN(0x006F), value = 2, flags = 0;
option text = STRING_TOKEN(0x006E), value = 1, flags = DEFAULT;
option text = STRING_TOKEN(0x0070), value = 3, flags = 0;
endlist;
normally, we can see option 2/option 1/option 3 for this ordered list. But base
on your proposal, the default for this ordered list opcode is option 1/option
1/option 1, do you think this is an valid ordered list result? I think if
DEFAULT flag is set, we can just skip this flag. We can use default opcode to
set default for ordered list opcode.
For your proposal, I think you can submit an ECR for it.
Thanks,
Eric
From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Wednesday, September 03, 2014 10:24 AM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: Re: [edk2] HII ORDERED_LIST support
Again, these are EDK2 decisions. They are not limitations of the specification.
The UEFI specification does not indicate that the EFI_IFR_ONE_OF_OPTION default
flag cannot work for ordered list. The UEFI specification does not say that
there is any limitation to the default opcode. It does not say that
EFI_IFR_TYPE_BUFFER cannot be used. These are EDK2 and VFR limitations, not
specification limits.
So, that is why I made the proposal below: to try and clarify the behavior if
these exist based on the UEFI specification language.
Tim
From: Dong, Eric [mailto:eric.d...@intel.com]
Sent: Tuesday, September 02, 2014 7:10 PM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: Re: [edk2] HII ORDERED_LIST support
For ordered list opcode, we not support set default flags in the option field.
It is useful for oneof opcode not for ordered list opcode. Also I think your
proposal of item 2) also not acceptable. We not support set default value
through option for ordered list opcode.
The value for ordered list opcode is buffer type, but the default opcode not
support save buffer type value(The EFI_IFR_TYPE_VALUE not support buffer type),
so the default opcode can't be used by ordered list opcode.
[cid:image003.jpg@01CFD7D4.96067D40]
[cid:image004.jpg@01CFD7D4.96067D40]
Current for ordered list opcode, browser based on the current option order nest
in this question to set the default value for it.
From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Wednesday, September 03, 2014 5:32 AM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: Re: [edk2] HII ORDERED_LIST support
Eric -
I believe that what you say is useful. But I don't think the specification
describes that behavior.
The next question, which was asked by someone else on the EDK2 list, is what to
do with "default" Both the flag for the "option" and the separate "default"
opcode. The "just the value for the one container" does not seem like a good
usage for default, since normally the engineer would like to saw the default
values for all containers. But if "option" is for 1 container, then how does
that work for default?
So here is a proposal for a clarification I would like to see in the UEFI
specification:
1) That, for ordered list, the "option values" should refer to a single
container.
2) When setting the default value using "option" then all containers will
be filled with that value.
3) When setting the default value using "default" then the "value" will be
a Buffer type, with one byte of the Buffer per container. If the default value
is smaller than the Buffer size, then the remaining containers will be filled
with 0.
Tim
From: Dong, Eric [mailto:eric.d...@intel.com]
Sent: Monday, September 01, 2014 6:40 PM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: Re: [edk2] HII ORDERED_LIST support
Tim,
I admit that one container should only has one byte, and I think one option is
corresponding to one container, do you agree this assumption?
For below sample code, current code use UINT16 for BootOrder array, so the
value for each option is UINT16. Now I think we should not use UINT16 array for
ordered list, we should only user BYTE type(UINT8) array for the ordered list
opcode. Right?
varid = MyIfrNVData.BootOrder,
prompt = STRING_TOKEN(0x006D),
help = STRING_TOKEN(0x0059),
option text = STRING_TOKEN(0x006F), value = 2, flags =
RESET_REQUIRED;
option text = STRING_TOKEN(0x006E), value = 1, flags =
RESET_REQUIRED;
option text = STRING_TOKEN(0x0070), value = 3, flags =
RESET_REQUIRED;
suppressif ideqval MyIfrNVData.BootOrderLarge == 0;
option text = STRING_TOKEN(0x0071), value = 4, flags =
RESET_REQUIRED;
endif
endlist;
typedef struct {
...
UINT16 BootOrder[8];
...
} DRIVER_SAMPLE_CONFIGURATION;
Thanks,
Eric
From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Tuesday, September 02, 2014 9:25 AM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: Re: [edk2] HII ORDERED_LIST support
Eric -
It is pretty clear from the spec that the value size for ordered list is 1 byte
per container. See 29.2.5.4.8,
"Storage The set questions are stored as a Buffer with one byte for each
Container."
There is no indication, either in the IFR or VFR specification that "option"
values refer to a single container value. There is also no indication in these
specifications that an option is a 16-bit value.
Tim
From: Dong, Eric [mailto:eric.d...@intel.com]
Sent: Monday, September 01, 2014 6:18 PM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: Re: [edk2] HII ORDERED_LIST support
Tim,
I agree "Value of the question is the entire buffer, not just one byte." But I
don't think "the value in a ONE_OF_OPTION is the value for the entire value
storage, not just one byte of the value storage. "
Take below code for example, the value for this question is 0002,0001,0003,0004
(8 byte), and the value type if buffer type. but for each option, the value is
different(0002/0001/0003/004), and type is UINT16 (2 byte), not 8 byte.
orderedlist
varid = MyIfrNVData.BootOrder,
prompt = STRING_TOKEN(0x006D),
help = STRING_TOKEN(0x0059),
option text = STRING_TOKEN(0x006F), value = 2, flags =
RESET_REQUIRED;
option text = STRING_TOKEN(0x006E), value = 1, flags =
RESET_REQUIRED;
option text = STRING_TOKEN(0x0070), value = 3, flags =
RESET_REQUIRED;
suppressif ideqval MyIfrNVData.BootOrderLarge == 0;
option text = STRING_TOKEN(0x0071), value = 4, flags =
RESET_REQUIRED;
endif
endlist;
so I think current issue for vfrcompile is it not restrict the data type for
each container is 1 byte.
Thanks,
Eric
From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Monday, August 25, 2014 3:11 PM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: Re: [edk2] HII ORDERED_LIST support
Eric -
For #1, this seems like a VFR compiler error, since the Form Browser does not
place the container value in each element of the array (if the array is UINT16)
For #2, please refer to section 29.2.5.4.8, where it says:
"Storage The set questions are stored as a Buffer with one byte for each
Container."
Then also see 29.2.5.4.1: "Question values are a data type listed in Section
29.2.5.7.4." For an ordered list, the value is a Buffer (not one byte in a
buffer) See also the Callback for CHANGING/CHANGED where the Ordered List value
should be a buffer. The defaults 29.2.5.8 says "Defaults are pre-defined
question values." Options say they "give ...description of a particular
question value" (29.2.5.5)
This means that the Value of the question is the entire buffer, not just one
byte.
Consider this case: I want to set the default boot order to 5,6,7,8,0,2,4. I
understand that it is useful to see the value as one byte, and this might work
best for one-of, but not for default. In any case, either the Form Browser
needs to be changed or the specification needs to be changed for the
ordered-list case.
Tim
From: Dong, Eric [mailto:eric.d...@intel.com]
Sent: Monday, August 25, 2014 2:40 PM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: Re: [edk2] HII ORDERED_LIST support
Tim,
Add my comments below.
From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Friday, August 22, 2014 12:40 AM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: [edk2] HII ORDERED_LIST support
In DriverSampleDxe, the boot order item is listed in storage as:
UINT16 BootOrder[8];
And here is the ordered list which manipulates this item:
orderedlist
varid = MyIfrNVData.BootOrder,
prompt = STRING_TOKEN(0x006D),
help = STRING_TOKEN(0x0059),
option text = STRING_TOKEN(0x006F), value = 2, flags =
RESET_REQUIRED;
option text = STRING_TOKEN(0x006E), value = 1, flags =
RESET_REQUIRED;
option text = STRING_TOKEN(0x0070), value = 3, flags =
RESET_REQUIRED;
suppressif ideqval MyIfrNVData.BootOrderLarge == 0;
option text = STRING_TOKEN(0x0071), value = 4, flags =
RESET_REQUIRED;
endif
endlist;
This leads to a number of questions:
1) The BootOrder is defined as UINT16, but the UEFI specification clearly
states that an orderedlist will work on a buffer with one byte per container.
(See 29.2.5.4.8 where it says, "The set questions are stored as a Buffer with
one byte for each Container."
[[[Eric]]] Truly spec has this description but vfrcompile and browser not do
this check, also current code may already has samples which already violate
this rule, so I need more discussion to provide a good proposal for this case.
[TIM] I am not worried about the actual struct members. BootOrder is 16 bytes
(8 x sizeof(UINT16). So that means that MaxContainers will be 16, right? The
VFR spec says: "NOTE: maxcontainers is optional, and the default value depends
on the variable size defined by varid in vfrQuestionHeader" So it seems that,
even though the code will work, using UINT8
BootOrder[16] would be easier to understand than UINT16 BootOrder[8]"
[[[Eric]]] Base on current implementation, the maxcontainer value is the array
size. So for "UINT16 BootOrder[8]", the maxcontainer = 8 and for "UINT8
BootOrder[16]", the maxcontainer = 16. I think we need to add check for the
code first, only support one byte for each container.
2) The option values are all integers. But the storage type of an ordered
list is a BUFFER. To me this implies (I haven't looked this up) that the value
an option is being used as the option for a single container. That makes sense,
but it is not the behavior described in the UEFI specification. Also, there
seems to be no way to create a value for a question of type buffer.
[[[Eric]]] no catch what's your mean is.
[TIM] For example, for "oneof" the value storage size is UINT8/UINT16/UINT32 or
UINT64. The value storage size for "checkbox" is BOOLEAN. But what is the value
storage size of "orderedlist" When I read the UEFI specification, the "value
storage size" of orderedlist is maxcontainers x sizeof(UINT8). So, if
maxcontainers is 16, then 16 bytes. BUT: the size of the value in an "option"
inside the "orderedlist" in these examples is sizeof(UINT8), not maxcontainers
x sizeof(UINT8).
According to the UEFI specification, as I read it today, the value in a
ONE_OF_OPTION is the value for the entire value storage, not just one byte of
the value storage. So every container in the ordered list value should be set
to 2 when the first "ONE_OF_OPTION" (in the example above) is selected by the
user.
[[[Eric]]] I can't find this information from the spec, which page in UEFI spec
2.4b describe it?
But I do not believe this is what the EDK2 Form browser does today. I believe
that it only changes a single container to the value 2 (not the whole buffer).
3) Likewise, there seems to be no way to provide a default for an ordered
list.
[[[Eric]]] yes, ordered list opcode just base on the current option order to
set the default value. For your above example, the default value is 2,1,3,4.
[TIM] If I put a "default = 2" in the example above, will it set one container
to "2" or all containers to "2" Again, this is a problem with the way the
specification describes values for ordered list opcodes. It is fairly clear
that the EDK2 form browser takes a different approach than the current
specification.
Here is an example display:
Boot Order: [boot order 1] [boot order 2][boot order 3][boot order 4][boot
order 5][boot order 6][boot order 7][boot order 8]
Each [boot order x] is a container. If the user goes to [boot order 2] and uses
one of the ONE_OF_OPTION pre-defined values, does it change only [boot order 2]
or all [boot order x]? Now, what does the UEFI specification say should happen?
[[[Eric]]] what's your mean of "uses one of the ONE_OF_OPTION pre-defined
values"? for ordered list opcode, we can only change the order of the options,
can't only select one option, I don't know your means about this sample?
Tim
------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
