* Need clarification on ImageUpdatable field in EFI_FIRMWARE_MANAGEMENT_PROTOCOL.CheckImage()
@ 2018-10-09 9:07 Varun Kumar
2018-10-09 9:26 ` Laszlo Ersek
0 siblings, 1 reply; 3+ messages in thread
From: Varun Kumar @ 2018-10-09 9:07 UTC (permalink / raw)
To: edk2-devel
Hi,
I need clarification on ImageUpdatable field in
EFI_FIRMWARE_MANAGEMENT_PROTOCOL.CheckImage(). ImageUpdatable is of 32 bit
wide but ImageUpdatable Definitions for this field is of 64 bit wide. I
hope it's not defined intentionally if so, please clarify me on this.
Please find the attached screenshot for reference.
Thanks,
Varun Kumar Reddy Yaparla.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Need clarification on ImageUpdatable field in EFI_FIRMWARE_MANAGEMENT_PROTOCOL.CheckImage()
2018-10-09 9:07 Need clarification on ImageUpdatable field in EFI_FIRMWARE_MANAGEMENT_PROTOCOL.CheckImage() Varun Kumar
@ 2018-10-09 9:26 ` Laszlo Ersek
2018-10-09 9:50 ` Varun Kumar
0 siblings, 1 reply; 3+ messages in thread
From: Laszlo Ersek @ 2018-10-09 9:26 UTC (permalink / raw)
To: Varun Kumar; +Cc: edk2-devel
Hi,
On 10/09/18 11:07, Varun Kumar wrote:
> I need clarification on ImageUpdatable field in
> EFI_FIRMWARE_MANAGEMENT_PROTOCOL.CheckImage(). ImageUpdatable is of 32
> bit wide
That seems to be the case, yes. (OUT UINT32 *).
> but ImageUpdatable Definitions for this field is of 64 bit wide.
That's not the case; the macros
- IMAGE_UPDATABLE_VALID,
- IMAGE_UPDATABLE_INVALID,
- IMAGE_UPDATABLE_INVALID_TYPE,
- IMAGE_UPDATABLE_INVALID_OLD,
- IMAGE_UPDATABLE_VALID_WITH_VENDOR_CODE
all have type INT32.
(Using the last one as an example, the integer constant
0x0000000000000010 has type INT32.)
I agree that the large number of leading zeroes is confusing. Please
consider filing a Mantis ticket for the UEFI spec, for cleaning those
up.
> I hope it's not defined intentionally if so, please clarify me on
> this. Please find the attached screenshot for reference.
Two comments on the screenshot:
- Currently the edk2-devel list strips attachments (most types, if not
all). That's a bug, but it's very hard to fix. Either way, the image
you may have attached hasn't reached the list.
- Sending a screenshot (I assume: from the UEFI spec) is not a bad idea
(assuming you use a lossless compression format, like PNG). It can be
improved further if you also provide textual pointers, such as: spec
release (e.g. "2.7"), and page number or section number.
Thanks!
Laszlo
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Need clarification on ImageUpdatable field in EFI_FIRMWARE_MANAGEMENT_PROTOCOL.CheckImage()
2018-10-09 9:26 ` Laszlo Ersek
@ 2018-10-09 9:50 ` Varun Kumar
0 siblings, 0 replies; 3+ messages in thread
From: Varun Kumar @ 2018-10-09 9:50 UTC (permalink / raw)
To: Laszlo Ersek; +Cc: edk2-devel
Awesome, thanks!
On Tue, 9 Oct 2018, 2:56 pm Laszlo Ersek, <lersek@redhat.com> wrote:
> Hi,
>
> On 10/09/18 11:07, Varun Kumar wrote:
> > I need clarification on ImageUpdatable field in
> > EFI_FIRMWARE_MANAGEMENT_PROTOCOL.CheckImage(). ImageUpdatable is of 32
> > bit wide
>
> That seems to be the case, yes. (OUT UINT32 *).
>
> > but ImageUpdatable Definitions for this field is of 64 bit wide.
>
> That's not the case; the macros
> - IMAGE_UPDATABLE_VALID,
> - IMAGE_UPDATABLE_INVALID,
> - IMAGE_UPDATABLE_INVALID_TYPE,
> - IMAGE_UPDATABLE_INVALID_OLD,
> - IMAGE_UPDATABLE_VALID_WITH_VENDOR_CODE
> all have type INT32.
>
> (Using the last one as an example, the integer constant
> 0x0000000000000010 has type INT32.)
>
> I agree that the large number of leading zeroes is confusing. Please
> consider filing a Mantis ticket for the UEFI spec, for cleaning those
> up.
>
> > I hope it's not defined intentionally if so, please clarify me on
> > this. Please find the attached screenshot for reference.
>
> Two comments on the screenshot:
>
> - Currently the edk2-devel list strips attachments (most types, if not
> all). That's a bug, but it's very hard to fix. Either way, the image
> you may have attached hasn't reached the list.
>
> - Sending a screenshot (I assume: from the UEFI spec) is not a bad idea
> (assuming you use a lossless compression format, like PNG). It can be
> improved further if you also provide textual pointers, such as: spec
> release (e.g. "2.7"), and page number or section number.
>
> Thanks!
> Laszlo
>
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2018-10-09 9:50 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-10-09 9:07 Need clarification on ImageUpdatable field in EFI_FIRMWARE_MANAGEMENT_PROTOCOL.CheckImage() Varun Kumar
2018-10-09 9:26 ` Laszlo Ersek
2018-10-09 9:50 ` Varun Kumar
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox