From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0731.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe4a::731]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 78B3D82133 for ; Fri, 17 Feb 2017 07:42:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=HPEnterprise.onmicrosoft.com; s=selector1-hpe-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=1PH72GFY0dux8KTHvwlC08qWKqp8NnLqToiw2+CjX/Y=; b=AfxmkIlY43cnp4BLccUmPBPFH4rKdSgW54bAaFBk0GeaR5NSi4DnFkX9g9UxgUbODtm/IqRpLshzzXyWPOeQp1NBZ/C/UNRUZkcPjr+h1MFgf07plX4GHiz1oZlOWYNdC9WrcUR27CLfyBMVAVvzwQDHyDiE7Nq9Zu82R7PXNlw= Received: from CS1PR84MB0024.NAMPRD84.PROD.OUTLOOK.COM (10.162.189.142) by CS1PR84MB0024.NAMPRD84.PROD.OUTLOOK.COM (10.162.189.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.919.13; Fri, 17 Feb 2017 15:42:13 +0000 Received: from CS1PR84MB0024.NAMPRD84.PROD.OUTLOOK.COM ([10.162.189.142]) by CS1PR84MB0024.NAMPRD84.PROD.OUTLOOK.COM ([10.162.189.142]) with mapi id 15.01.0919.013; Fri, 17 Feb 2017 15:42:13 +0000 From: "Shah, Tapan" To: "Yao, Jiewen" , Rebecca Cran , "edk2-devel@lists.01.org" , "Gao, Liming" , "Carsey, Jaben" Thread-Topic: [edk2] EFI_FIRMWARE_IMAGE_DESCRIPTOR v1/v2/v3: MdePkg and ShellPkg Thread-Index: AQHSiKa2WPCt1iY9LkCol48OgScXA6FsPYpAgAAFhACAARADgA== Date: Fri, 17 Feb 2017 15:42:13 +0000 Message-ID: References: <27f6c46b-aebe-a250-eb17-b93267c12a82@bluestop.org> <74D8A39837DF1E4DA445A8C0B3885C503A8EFF4F@shsmsx102.ccr.corp.intel.com> In-Reply-To: <74D8A39837DF1E4DA445A8C0B3885C503A8EFF4F@shsmsx102.ccr.corp.intel.com> Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tapandshah@hpe.com; x-originating-ip: [15.203.227.12] x-ms-office365-filtering-correlation-id: f4233a9b-e026-4dea-5eac-08d4574b8b4c x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CS1PR84MB0024; x-microsoft-exchange-diagnostics: 1; CS1PR84MB0024; 7:COYrWUWegpsRmcmjxbUa2f/MKK1UHXdyu3XmOxdAEj152iiEoakcOVuRFofjDdy1zYkjXuq1jh1QR7XFmkwjWaUHaxv47Eq+MJrCELGEe22Ll0evbo6FWCp3m1SXQHEiS6wUwqLGT0SXvB5jJ2GTvo6ADgsMfvYmwHl6uFfyrXYcO9L/AsDyNu13tWT8ATTvyb6epwo0JqlI97GnN6cdq9blgg78kcDlEZDq/m22hCLlvPKsTRrLEvaxmgU8ckybQFoo0GiIFrO6cqOmaJ/0P7G5szj15dLBRlH60DSudf3zVst6UFLgSUxjFHA57MgRMiwgy0w/Uc43MRHmYynMmQ== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(227479698468861)(162533806227266)(21748063052155)(228905959029699); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123555025)(20161123564025)(20161123562025)(20161123560025)(20161123558025)(6072148); SRVR:CS1PR84MB0024; BCL:0; PCL:0; RULEID:; SRVR:CS1PR84MB0024; x-forefront-prvs: 02213C82F8 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39450400003)(39860400002)(39840400002)(39850400002)(39410400002)(189002)(377454003)(199003)(13464003)(606005)(8936002)(9686003)(6436002)(102836003)(6116002)(3846002)(790700001)(81156014)(3660700001)(7696004)(189998001)(53546006)(97736004)(122556002)(2906002)(3280700002)(54896002)(2501003)(236005)(99936001)(6306002)(86362001)(66066001)(55016002)(5890100001)(81166006)(68736007)(53936002)(76176999)(54356999)(229853002)(6246003)(106116001)(77096006)(92566002)(101416001)(106356001)(6506006)(7906003)(8676002)(7736002)(105586002)(5660300001)(2950100002)(2900100001)(50986999)(38730400002)(74316002)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:CS1PR84MB0024; H:CS1PR84MB0024.NAMPRD84.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: hpe.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: hpe.com X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Feb 2017 15:42:13.5082 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 105b2061-b669-4b31-92ac-24d304d195dc X-MS-Exchange-Transport-CrossTenantHeadersStamped: CS1PR84MB0024 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 Subject: Re: EFI_FIRMWARE_IMAGE_DESCRIPTOR v1/v2/v3: MdePkg and ShellPkg X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 15:42:18 -0000 X-Groupsio-MsgNum: 7551 Content-Language: en-US Content-Type: multipart/mixed; boundary="_004_CS1PR84MB00248B02952C8BBBE90002DBD45D0CS1PR84MB0024NAMP_" --_004_CS1PR84MB00248B02952C8BBBE90002DBD45D0CS1PR84MB0024NAMP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There is no rule that says consumer of the code cannot define their own str= uctures (in this case UefiHandleParsingLib in ShellPkg needs to consume V1 = and V2). Having V1, V2 structures make it easy to decode the data in a stru= ctural way instead of hard-coded method to parse the data. Liming and Jaben agreed on this idea of having V1, V2 in UefiHandleParsingL= ib when we decided to add FMP V1,V2,V3 decode support in 'dh' command. See = attached old discussion on this agreement. From: Yao, Jiewen [mailto:jiewen.yao@intel.com] Sent: Thursday, February 16, 2017 5:13 PM To: Shah, Tapan ; Rebecca Cran ; = edk2-devel@lists.01.org; Gao, Liming Subject: RE: [edk2] EFI_FIRMWARE_IMAGE_DESCRIPTOR v1/v2/v3: MdePkg and Shel= lPkg Yes, I agree that SHELL pkg should dump V1 only and V2 only data structure. I just think there is no need to add new data structure there. The shell pkg can just skip LowestSupportedImageVersion in V1 and skip Last= AttemptVersion/ LastAttemptStatus/ HardwareInstance in V2. Thank you Yao Jiewen > -----Original Message----- > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Sh= ah, > Tapan > Sent: Thursday, February 16, 2017 3:00 PM > To: Rebecca Cran >; edk= 2-devel@lists.01.org; Gao, Liming > > > Subject: Re: [edk2] EFI_FIRMWARE_IMAGE_DESCRIPTOR v1/v2/v3: MdePkg and > ShellPkg > > UEFI Spec does not have old FMP image descriptor structures V1 and V2 def= ined. > > MdePkg only follows the spec, so it contains the latest version # 3. But = there are > still drivers using old V1, V2 revisions and Shell 'dh' command needs to = support > decoding all revisions and needs to remain in ShellPkg. > > > -----Original Message----- > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of > Rebecca Cran > Sent: Thursday, February 16, 2017 4:48 PM > To: edk2-devel@lists.01.org > Subject: [edk2] EFI_FIRMWARE_IMAGE_DESCRIPTOR v1/v2/v3: MdePkg and > ShellPkg > > I'm a bit confused about why Firmware Management Protocol image descripto= r > structures are split between MdePkg and ShellPkg: > > In MdePkg/Include/Protocol/FirmwareInformation.h there's the definition o= f > EFI_FIRMWARE_IMAGE_DESCRIPTOR (version 3). But then the > EFI_FIRMWARE_IMAGE_DESCRIPTOR_V1 and > EFI_FIRMWARE_IMAGE_DESCRIPTOR_V2 struct definitions are in > ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.h along with s= ome > seemingly-unrelated stuff - and that file appears to have a ridiculous nu= mber of > #include's! > > > Is there a reasoning behind putting the older structures in ShellPkg, or = should > they be moved to FirmwareInformation.h? > > > -- > > Rebecca > > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel --_004_CS1PR84MB00248B02952C8BBBE90002DBD45D0CS1PR84MB0024NAMP_ Content-Type: message/rfc822 Content-Disposition: attachment; creation-date="Fri, 17 Feb 2017 15:42:10 GMT"; modification-date="Fri, 17 Feb 2017 15:42:10 GMT" Received: from CS1PR84MB0230.NAMPRD84.PROD.OUTLOOK.COM (10.162.190.152) by CS1PR84MB0229.NAMPRD84.PROD.OUTLOOK.COM (10.162.190.151) with Microsoft SMTP Server (TLS) id 15.1.443.12 via Mailbox Transport; Fri, 18 Mar 2016 14:55:35 +0000 Received: from CS1PR84MB0150.NAMPRD84.PROD.OUTLOOK.COM (10.162.189.29) by CS1PR84MB0230.NAMPRD84.PROD.OUTLOOK.COM (10.162.190.152) with Microsoft SMTP Server (TLS) id 15.1.443.12; Fri, 18 Mar 2016 14:55:35 +0000 Received: from AT5PR84CA0019.NAMPRD84.PROD.OUTLOOK.COM (10.162.136.29) by CS1PR84MB0150.NAMPRD84.PROD.OUTLOOK.COM (10.162.189.29) with Microsoft SMTP Server (TLS) id 15.1.443.12; Fri, 18 Mar 2016 14:55:34 +0000 Received: from BN1AFFO11FD007.protection.gbl (2a01:111:f400:7c10::111) by AT5PR84CA0019.outlook.office365.com (2a01:111:e400:7400::29) with Microsoft SMTP Server (TLS) id 15.1.443.12 via Frontend Transport; Fri, 18 Mar 2016 14:55:34 +0000 Received: from G2W6309.americas.hpqcorp.net (15.219.163.14) by BN1AFFO11FD007.mail.protection.outlook.com (10.58.52.67) with Microsoft SMTP Server (TLS) id 15.1.443.6 via Frontend Transport; Fri, 18 Mar 2016 14:55:33 +0000 Received: from G2W6310.americas.hpqcorp.net (16.197.64.52) by G2W6309.americas.hpqcorp.net (16.197.64.51) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Fri, 18 Mar 2016 14:55:10 +0000 Received: from g9t5007.houston.hp.com (15.240.92.65) by G2W6310.americas.hpqcorp.net (16.197.64.52) with Microsoft SMTP Server (TLS) id 15.0.1076.9 via Frontend Transport; Fri, 18 Mar 2016 14:55:11 +0000 Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by g9t5007.houston.hp.com (Postfix) with ESMTP id C1FD280; Fri, 18 Mar 2016 14:55:09 +0000 (UTC) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga103.fm.intel.com with ESMTP; 18 Mar 2016 07:55:10 -0700 Received: from fmsmsx108.amr.corp.intel.com ([10.18.124.206]) by orsmga003.jf.intel.com with ESMTP; 18 Mar 2016 07:55:08 -0700 Received: from fmsmsx117.amr.corp.intel.com (10.18.116.17) by FMSMSX108.amr.corp.intel.com (10.18.124.206) with Microsoft SMTP Server (TLS) id 14.3.248.2; Fri, 18 Mar 2016 07:55:08 -0700 Received: from fmsmsx103.amr.corp.intel.com ([169.254.2.94]) by fmsmsx117.amr.corp.intel.com ([10.18.116.17]) with mapi id 14.03.0248.002; Fri, 18 Mar 2016 07:55:08 -0700 From: "Carsey, Jaben" To: "Gao, Liming" , "El-Haj-Mahmoud, Samer" , "Shah, Tapan" , "Kinney, Michael D" , "Rothman, Michael A" CC: "Qiu, Shumin" , "Ni, Ruiyu" , "Carsey, Jaben" Subject: RE: [PATCH] MdePkg: Add EFI_FIRMWARE_IMAGE_DESCRIPTOR V1 and V2 structure definition. Thread-Topic: [PATCH] MdePkg: Add EFI_FIRMWARE_IMAGE_DESCRIPTOR V1 and V2 structure definition. Thread-Index: AQHRf6mt1olPU4lP/0uyJ/Z6Nnnhq59cW2GAgAAgMFCAAGSJgIAA0I1AgAD8F4CAAIg28IAADuWAgAAA1ICAAAhRgA== Date: Fri, 18 Mar 2016 14:55:07 +0000 Message-ID: References: <1458149476-3464-1-git-send-email-tapandshah@hpe.com> <4A89E2EF3DFEDB4C8BFDE51014F606A1155741AD@shsmsx102.ccr.corp.intel.com> <4A89E2EF3DFEDB4C8BFDE51014F606A1155750A1@shsmsx102.ccr.corp.intel.com> <4A89E2EF3DFEDB4C8BFDE51014F606A115575512@shsmsx102.ccr.corp.intel.com> In-Reply-To: <4A89E2EF3DFEDB4C8BFDE51014F606A115575512@shsmsx102.ccr.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Exchange-Organization-AuthAs: External X-MS-Exchange-Organization-AuthMechanism: 10 X-MS-Exchange-Organization-AuthSource: G2W6310.americas.hpqcorp.net X-MS-Has-Attach: X-MS-Exchange-Organization-Network-Message-Id: 008d891d-313f-4e04-c311-08d34f3d5bb3 X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: x-originating-ip: [10.1.200.107] x-pmx-spam: Gauge=IIIIIIIII, Probability=9%, Report=' MULTIPLE_RCPTS 0.1, HTML_00_01 0.05, HTML_00_10 0.05, SUPERLONG_LINE 0.05, BODYTEXTH_SIZE_3000_MORE 0, BODY_SIZE_10000_PLUS 0, NO_URI_HTTPS 0, REFERENCES 0, WEBMAIL_SOURCE 0, WEBMAIL_XOIP 0, WEBMAIL_X_IP_HDR 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CANPHARM_COPYRIGHT 0, __CP_MEDIA_BODY 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_ALT 0, __FORWARDED_MSG 0, __HAS_FROM 0, __HAS_MSGID 0, __HAS_XOIP 0, __IMS_MSGID 0, __IN_REP_TO 0, __MIME_HTML 0, __MIME_VERSION 0, __MULTIPLE_RCPTS_CC_X2 0, __MULTIPLE_RCPTS_TO_X5 0, __REFERENCES 0, __SANE_MSGID 0, __SUBJ_ALPHA_NEGATE 0, __TO_MALFORMED_2 0, __URI_NO_WWW 0, __URI_NS ' x-pmx-version: 6.2.0.2453472, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.3.18.144816 x-extloop1: 1 x-ironport-av: E=Sophos;i="5.24,355,1455004800"; d="scan'208,217";a="766843645" received-spf: Fail (protection.outlook.com: domain of intel.com does not designate 15.219.163.14 as permitted sender) receiver=protection.outlook.com; client-ip=15.219.163.14; helo=G2W6309.americas.hpqcorp.net; MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am ok. From: Gao, Liming Sent: Friday, March 18, 2016 7:25 AM To: El-Haj-Mahmoud, Samer ; Shah, Tapan ; Kinney, Michael D ; Carsey, Ja= ben ; Rothman, Michael A Cc: Qiu, Shumin ; Ni, Ruiyu ; Gao= , Liming Subject: RE: [PATCH] MdePkg: Add EFI_FIRMWARE_IMAGE_DESCRIPTOR V1 and V2 st= ructure definition. Importance: High + Ruiyu and Shumin I am OK to add them into ShellPkg. Thanks Liming From: El-Haj-Mahmoud, Samer [mailto:samer.el-haj-mahmoud@hpe.com] Sent: Friday, March 18, 2016 10:22 PM To: Shah, Tapan >; Gao, Limin= g >; Kinney, Michael D >; Carsey, Jabe= n >; Gao, Liming >; Rothman, Michael A > Cc: El-Haj-Mahmoud, Samer > Subject: RE: [PATCH] MdePkg: Add EFI_FIRMWARE_IMAGE_DESCRIPTOR V1 and V2 st= ructure definition. + Liming and Mike Rothman We need the Shell DH command to be able to dump the FMP information from pr= evious as well as most recent UEFI spec implementations. There are a wide r= ange of IHV drivers in the wild that support a mix of V1, V2, and the lates= t V3. I think putting these definitions in the ShellPkg UefiHandleParsingLib shou= ld be acceptable. Jaben? Thanks, --Samer -----Original Message----- From: Shah, Tapan Sent: Friday, March 18, 2016 8:42 AM To: Gao, Liming ; Kinney, Michael D ; Carsey, Jaben Cc: El-Haj-Mahmoud, Samer Subject: RE: [PATCH] MdePkg: Add EFI_FIRMWARE_IMAGE_DESCRIPTOR V1 and V2 st= ructure definition. Jaben, UefiHandleParsingLib library of ShellPkg is the consumer of this V1/V2 stru= cture for 'dh' command. Is it OK for you if we add these definitions in Uef= iHandleParsingLib.h file? Thanks, Tapan -----Original Message----- From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Gao,= Liming Sent: Friday, March 18, 2016 12:22 AM To: Shah, Tapan ; edk2-devel@lists.01.org; = Kinney, Michael D Cc: Carsey, Jaben Subject: Re: [edk2] [PATCH] MdePkg: Add EFI_FIRMWARE_IMAGE_DESCRIPTOR V1 an= d V2 structure definition. Tapan: UEFI spec doesn't define EFI_FIRMWARE_IMAGE_DESCRIPTOR_V1 and EFI_FIRMWARE_= IMAGE_DESCRIPTOR_V2. MdePkg definitions follows UEFI/PI/IndustryStandard sp= ecification. For this case, the consumer code can base on current definitio= n to use the different version structure. So, I don't think we need to add = V1 and V2 structure into UEFI spec and MdePkg. But, they can still be added= into your local driver for your development. Thanks Liming From: Shah, Tapan [mailto:tapandshah@hpe.com] Sent: Thursday, March 17, 2016 10:30 PM To: Gao, Liming; edk2-devel@lists.01.org; K= inney, Michael D Cc: Carsey, Jaben; El-Haj-Mahmoud, Samer Subject: RE: [PATCH] MdePkg: Add EFI_FIRMWARE_IMAGE_DESCRIPTOR V1 and V2 st= ructure definition. Liming, Having old version structure definition makes it clean for consumer to deco= de structure without being deterministic for which fields exists in structu= re based on its version and size. The only structure definition exist in .h= file does not provide a clean way to decode the data. Tapan -----Original Message----- From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Gao,= Liming Sent: Wednesday, March 16, 2016 8:53 PM To: Shah, Tapan ; edk2-devel@lists.01.org; = Kinney, Michael D Cc: Carsey, Jaben Subject: Re: [edk2] [PATCH] MdePkg: Add EFI_FIRMWARE_IMAGE_DESCRIPTOR V1 an= d V2 structure definition. Tapan: Consumer can base on version value to know the structure size and date. We = don't need to add old version structure definition. Thanks Liming From: Shah, Tapan [mailto:tapandshah@hpe.com] Sent: Thursday, March 17, 2016 3:54 AM To: edk2-devel@lists.01.org; Kinney, Michae= l D ; Gao, Liming Cc: Carsey, Jaben ; El-Haj-Mahmoud, Samer Subject: RE: [PATCH] MdePkg: Add EFI_FIRMWARE_IMAGE_DESCRIPTOR V1 and V2 st= ructure definition. Michael / Liming, Can you please help review this change? Thanks, Tapan -----Original Message----- From: Carsey, Jaben [mailto:jaben.carsey@intel.com] Sent: Wednesday, March 16, 2016 12:58 PM To: Shah, Tapan ; edk2-devel@lists.01.org Cc: El-Haj-Mahmoud, Samer ; Carsey, Jaben Subject: RE: [PATCH] MdePkg: Add EFI_FIRMWARE_IMAGE_DESCRIPTOR V1 and V2 st= ructure definition. Looks good. Reviewed-by: Jaben Carsey > -----Original Message----- > From: Tapan Shah [mailto:tapandshah@hpe.com] > Sent: Wednesday, March 16, 2016 10:31 AM > To: edk2-devel@lists.01.org > Cc: samer.el-haj-mahmoud@hpe.com; > Carsey, Jaben ; Tapan Shah > Subject: [PATCH] MdePkg: Add EFI_FIRMWARE_IMAGE_DESCRIPTOR V1 and > V2 structure definition. > > Add V1 and V2 structure definitions for EFI_FIRMWARE_IMAGE_DESCRIPTOR > structure. Consumer of the protocol needs correct structure definition > to decode structure fields correctly. > > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Tapan Shah > --- > MdePkg/Include/Protocol/FirmwareManagement.h | 116 > +++++++++++++++++++++++++++ > 1 file changed, 116 insertions(+) > > diff --git a/MdePkg/Include/Protocol/FirmwareManagement.h > b/MdePkg/Include/Protocol/FirmwareManagement.h > index e615573..67f19fd 100644 > --- a/MdePkg/Include/Protocol/FirmwareManagement.h > +++ b/MdePkg/Include/Protocol/FirmwareManagement.h > @@ -10,6 +10,7 @@ > > Copyright (c) 2009 - 2015, Intel Corporation. All rights reserved. > Copyright (c) 2013 - 2014, Hewlett-Packard Development Company, L.P. > + (C) Copyright 2016 Hewlett Packard Enterprise Development LP > This program and the accompanying materials are licensed and made > available under the terms and conditions of the BSD License which > accompanies this distribution. The full text of the license may be > found at @@ -119,6 +120,121 @@ typedef struct { > UINT64 HardwareInstance; > } EFI_FIRMWARE_IMAGE_DESCRIPTOR; > > +#define EFI_FIRMWARE_IMAGE_DESCRIPTOR_VERSION_V1 1 #define > +EFI_FIRMWARE_IMAGE_DESCRIPTOR_VERSION_V2 2 > + > +/// > +/// EFI_FIRMWARE_IMAGE_DESCRIPTOR in UEFI spec < 2.4a /// typedef > +struct { /// /// A unique number identifying the firmware image > +within the device. The > number is > + /// between 1 and DescriptorCount. > + /// > + UINT8 ImageIndex; > + /// > + /// A unique number identifying the firmware image type. > + /// > + EFI_GUID ImageTypeId; > + /// > + /// A unique number identifying the firmware image. > + /// > + UINT64 ImageId; > + /// > + /// A pointer to a null-terminated string representing the firmware > + image > name. > + /// > + CHAR16 *ImageIdName; > + /// > + /// Identifies the version of the device firmware. The format is > + vendor > specific and new > + /// version must have a greater value than an old version. > + /// > + UINT32 Version; > + /// > + /// A pointer to a null-terminated string representing the firmware > + image > version name. > + /// > + CHAR16 *VersionName; > + /// > + /// Size of the image in bytes. If size=3D0, then only ImageIndex and > ImageTypeId are valid. > + /// > + UINTN Size; > + /// > + /// Image attributes that are supported by this device. See 'Image > + Attribute > Definitions' > + /// for possible returned values of this parameter. A value of 1 > + indicates > the attribute is > + /// supported and the current setting value is indicated in AttributesS= etting. > A > + /// value of 0 indicates the attribute is not supported and the > + current > setting value in > + /// AttributesSetting is meaningless. > + /// > + UINT64 AttributesSupported; > + /// > + /// Image attributes. See 'Image Attribute Definitions' for possible > + returned > values of > + /// this parameter. > + /// > + UINT64 AttributesSetting; > + /// > + /// Image compatibilities. See 'Image Compatibility Definitions' > + for possible > returned > + /// values of this parameter. > + /// > + UINT64 Compatibilities; > +} EFI_FIRMWARE_IMAGE_DESCRIPTOR_V1; > + > + > +/// > +/// EFI_FIRMWARE_IMAGE_DESCRIPTOR in UEFI spec > 2.4a and < 2.5 /// > +typedef struct { /// /// A unique number identifying the firmware > +image within the device. The > number is > + /// between 1 and DescriptorCount. > + /// > + UINT8 ImageIndex; > + /// > + /// A unique number identifying the firmware image type. > + /// > + EFI_GUID ImageTypeId; > + /// > + /// A unique number identifying the firmware image. > + /// > + UINT64 ImageId; > + /// > + /// A pointer to a null-terminated string representing the firmware > + image > name. > + /// > + CHAR16 *ImageIdName; > + /// > + /// Identifies the version of the device firmware. The format is > + vendor > specific and new > + /// version must have a greater value than an old version. > + /// > + UINT32 Version; > + /// > + /// A pointer to a null-terminated string representing the firmware > + image > version name. > + /// > + CHAR16 *VersionName; > + /// > + /// Size of the image in bytes. If size=3D0, then only ImageIndex and > ImageTypeId are valid. > + /// > + UINTN Size; > + /// > + /// Image attributes that are supported by this device. See 'Image > + Attribute > Definitions' > + /// for possible returned values of this parameter. A value of 1 > + indicates > the attribute is > + /// supported and the current setting value is indicated in AttributesS= etting. > A > + /// value of 0 indicates the attribute is not supported and the > + current > setting value in > + /// AttributesSetting is meaningless. > + /// > + UINT64 AttributesSupported; > + /// > + /// Image attributes. See 'Image Attribute Definitions' for possible > + returned > values of > + /// this parameter. > + /// > + UINT64 AttributesSetting; > + /// > + /// Image compatibilities. See 'Image Compatibility Definitions' > + for possible > returned > + /// values of this parameter. > + /// > + UINT64 Compatibilities; > + /// > + /// Describes the lowest ImageDescriptor version that the device > + will > accept. Only > + /// present in version 2 or higher. > + UINT32 LowestSupportedImageVersion; > +} EFI_FIRMWARE_IMAGE_DESCRIPTOR_V2; > > // > // Image Attribute Definitions > -- > 2.6.2.windows.1 _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel --_004_CS1PR84MB00248B02952C8BBBE90002DBD45D0CS1PR84MB0024NAMP_--