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
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:image001.jpg@01CFC77D.381BA910]
[cid:image002.jpg@01CFC77D.381BA910]
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
------------------------------------------------------------------------------
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
