From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt0-x241.google.com (mail-qt0-x241.google.com [IPv6:2607:f8b0:400d:c0d::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id CA8F481C35 for ; Fri, 13 Jan 2017 00:10:32 -0800 (PST) Received: by mail-qt0-x241.google.com with SMTP id a29so5324662qtb.1 for ; Fri, 13 Jan 2017 00:10:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=xl2ZFTHzb36aLVugl0MSXNW5IUdPaLmnqIccPS8ZNn0=; b=i9ncRSMoHnKvluUDl1Byc770lAGIth8LpCojMIa3gLNOeWJl5+4Zkgq2sGZDoWtYzE oXt7LbElAWiVNhaEej4cMqytruZVbtP15tAPv56Oxk1M9Oo6IGv25HkNZrYpK3RyU2+N FNenaaJWr4SI/6hQRPoNYHdcfCoanPv5R8+d2PpPrsf4O3MQp/kx6EpapZz66xhrqEhU bq5gJ5TRWVXBj2geQJVyNkJKfYWb3dtjk0oiX7JZNjEaGfO7Jg6mmwnBkjvRxLPV4WyR bF7VC2dOmT2R5kkUcPzDWHkPxNQ8bGCGtS9O35ggyk1PKazfTrE+bAcIcCGGsFB3tQ9f bBDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=xl2ZFTHzb36aLVugl0MSXNW5IUdPaLmnqIccPS8ZNn0=; b=La2+lQgsoOA3BGwUoUrj5XaCtZ1jAlZHa5EAtDWtGGRb3573DievOnZ4BEOZmH9quZ nJmT9E7lpEq+qOoQ/TePAU3K66UEbWUq4oaQX2qatgW3LDflkMATDN+fi8fVuLwCM4vw 7jXw+ZjMgBgW3gDjOtRD5DlugnCx0SlURIHVhCsoC/LaODOEDCe4nYelZKKQdBh/qWBJ pNvNPrlFoI+0fawIcq6UVOZnWxdz4XLpZ0SzI7x8DPOUrAtISLxCsnhM2f7IZzuDfV5o eGSyjtnwAhXJ48+9x7pXcxlZzUfvpHcUG3+WfFCSCDyj+o9guhPGs/3iuLQIm236h2Rf TCVw== X-Gm-Message-State: AIkVDXJBqKZ23rzKV94CbOrgpKfq1i1UtCTG9MpFKyHwnzysjw9V+CGhOZjvLeeXVdH90AjwdjBmr4IS60KeeQ== X-Received: by 10.237.33.67 with SMTP id 61mr11115531qtc.37.1484295032198; Fri, 13 Jan 2017 00:10:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.89.75 with HTTP; Fri, 13 Jan 2017 00:10:31 -0800 (PST) In-Reply-To: <74D8A39837DF1E4DA445A8C0B3885C503A8D46CC@shsmsx102.ccr.corp.intel.com> References: <20161216182547.616-1-evan.lloyd@arm.com> <734D49CCEBEEF84792F5B80ED585239D5B836C04@SHSMSX103.ccr.corp.intel.com> <734D49CCEBEEF84792F5B80ED585239D5B8371E1@SHSMSX103.ccr.corp.intel.com> <74D8A39837DF1E4DA445A8C0B3885C503A8C6C52@shsmsx102.ccr.corp.intel.com> <734D49CCEBEEF84792F5B80ED585239D5B839479@SHSMSX103.ccr.corp.intel.com> <74D8A39837DF1E4DA445A8C0B3885C503A8C6CBD@shsmsx102.ccr.corp.intel.com> <74D8A39837DF1E4DA445A8C0B3885C503A8C7026@shsmsx102.ccr.corp.intel.com> <74D8A39837DF1E4DA445A8C0B3885C503A8D46CC@shsmsx102.ccr.corp.intel.com> From: Bhupesh SHARMA Date: Fri, 13 Jan 2017 13:40:31 +0530 Message-ID: To: "Yao, Jiewen" Cc: Evan Lloyd , "Ni, Ruiyu" , "Carsey, Jaben" , Sami Mujawar , "edk2-devel@ml01.01.org" , Leif Lindholm , "ard.biesheuvel@linaro.org" Subject: Re: [PATCH] ShellPkg: Add acpiview tool to dump ACPI tables 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, 13 Jan 2017 08:10:33 -0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi All, On Fri, Dec 23, 2016 at 7:01 AM, Yao, Jiewen wrote: > HI Even > Thank you for the response. > > *Mike Kinney* is managing staging tree =E2=80=93 he may help answer the q= uestion on staging. =E2=98=BA > > I am glad to co-work with you on that. > > Merry Christmas! > > > Thank you > Yao Jiewen > > From: Evan Lloyd [mailto:Evan.Lloyd@arm.com] > Sent: Friday, December 23, 2016 2:26 AM > To: Yao, Jiewen ; Ni, Ruiyu ; C= arsey, Jaben ; Sami Mujawar > Cc: Carsey, Jaben ; edk2-devel@ml01.01.org; Leif = Lindholm ; ard.biesheuvel@linaro.org > Subject: RE: [edk2] [PATCH] ShellPkg: Add acpiview tool to dump ACPI tabl= es > > > Hi Jiewen. > I hope I have our forename there, not your surname - it can be difficult = to tell :-) > I've trimmed a lot out of the history below, for clarity. > >> >>From: Yao, Jiewen [mailto:jiewen.yao@intel.com] >>Sent: 20 December 2016 16:35 >>To: Evan Lloyd; Ni, Ruiyu; Carsey, Jaben; Sami Mujawar >>Cc: Carsey, Jaben; edk2-devel@ml01.01.org;= Leif Lindholm; ard.biesheuvel@linaro.org >>Subject: RE: [edk2] [PATCH] ShellPkg: Add acpiview tool to dump ACPI tabl= es >> >>Thank you, Lloyd. >> >>Comment inline. >> > ... >>[Jiewen] Got it. >>As you mention, I hope it can be in SHELL spec, too. >> >>So that we can have a standard way to dump all table information. >> >>For X86 system, I have written similar tool to dump X86 related info. >>I just check in to https://github.com/jyao1/EdkiiShellTool/tree/master/Ac= piToolPkg. >>It is also BSD license code. I tried by best to dump info for *all* the A= CPI table. >>But I do not validate ARM system. We complement to each other. ? > > Yes, we obviously need to get together over this. > >>... >>[Jiewen] Let me summarize current status: >>1) We know there is strong requirement to dump ACPI table in UEFI s= hell environment, for debug purposes. >>2) UEFI shell specification does not contain any ACPI dump command.= (Although it has SmbiosDump) >>3) ACPICA.ORG has sample code to dump ACPI. >>> > >Binary can be downloaded from: https://acpica.org/downloads/uefi-sup= port >>> > >Source can be downloaded from: https://github.com/acpica/acpica >>4) This patch provides dump ACPI information with consistency check= . But limitation is: it only supports the limited table on ARM platform. NO= support for X86 platform. >>5) I have similar code to dump ACPI. But the limitation is: it only= validated on X86 platform. It is not validated on ARM platform. >> >> >>So I would like to propose: >>1) DOCUMENTATION: Can we co-work to submit an ECR for SHELL, to add= AcpiDump command? So that people may get standard dump log in the future. > > This sounds fine, but I'd suggest getting it into the Shell spec is much = lower > priority than making the tool available. We believe the checking aspect = will > help people detect errors at an early stage, so want to "get it out there= ". > >>2) CODE: It seems both of our code is POC quality and has partial v= alidation only. It might not be suitable to check in EDKII immediately >>I would like to propose we co-work in EDKII staging tree - https://github= .com/tianocore/edk2-staging/ (We have 4 features there.) > > That sounds excellent. It will be a great thing to have ARM/Intel (or In= tel/ARM if you prefer) cooperation on this. > >>We can align our design, then I can help validate X86 and you can help va= lidate ARM. >>Then we can submit a complete patch to EDKII ShellPkg. >> >>What about your idea? > > I think this potentially helps everyone in UEFI. > Sadly, we are about to shut down for Christmas, and will not be back unti= l 2017-01-03. (I'm not really sad about it.) > From looking at your code, I think we will be able to learn a lot about E= DK2 programming from you. > I suggest we can discuss the design and code merge aspects off list. (And= make details of the results public in condensed form.) > > Do I need to ask anyone to give me commit rights to https://github.com/ti= anocore/edk2-staging? > Or is it pull request based? > > Regards, and Merry Christmas, > Evan > >> > Thank you >>> Yao Jiewen >> I needed a ACPI table dump tool for fixing a issue with BGRT table being passed to a x86_64 and AARCH64 Linux kernel. I just happened to evaluate and use both the excellent tools: [1]. https://github.com/jyao1/EdkiiShellTool from Yao Jiewen [2]. https://github.com/EvanLloyd/tianocore/tree/651_acpiview_v1 from Evan Since my use case was primarily to dump the BGRT ACPI table being passed to the kernel although I tried both the tool flavours, I found [1] more powerful in dumping the ACPI tables. Since I needed this tool to work on Qemu on AARCH64 as well. so I compiled [1] using AARCH64, GCC4.9 toolchain and after some changes - which I have submitted to the edk2 list for review (see [3]), I was able to use this flavour of the tool on a Qemu for AARCH64 as well to dump the relevant ACPI tools. [3]. https://lists.01.org/pipermail/edk2-devel/2017-January/006536.html I think it would be quite useful to combine the two tools and harness their power which will be specially useful to folks like me who at times need to debug issues at the firmware - kernel boundary. Please let me know if I can contribute/help test any code development/patches on this front. Thanks, Bhupesh