* 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