From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0a-002e3701.pphosted.com (mx0a-002e3701.pphosted.com [148.163.147.86]) by mx.groups.io with SMTP id smtpd.web11.47808.1584949605365489184 for ; Mon, 23 Mar 2020 00:46:45 -0700 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: hpe.com, ip: 148.163.147.86, mailfrom: prvs=03514699be=abner.chang@hpe.com) Received: from pps.filterd (m0150242.ppops.net [127.0.0.1]) by mx0a-002e3701.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 02N7hJqx004141 for ; Mon, 23 Mar 2020 07:46:45 GMT Received: from g4t3427.houston.hpe.com (g4t3427.houston.hpe.com [15.241.140.73]) by mx0a-002e3701.pphosted.com with ESMTP id 2ywddp2mep-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 23 Mar 2020 07:46:44 +0000 Received: from G2W6311.americas.hpqcorp.net (g2w6311.austin.hp.com [16.197.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by g4t3427.houston.hpe.com (Postfix) with ESMTPS id CC15E6A for ; Mon, 23 Mar 2020 07:46:43 +0000 (UTC) Received: from G4W9326.americas.hpqcorp.net (16.208.32.96) by G2W6311.americas.hpqcorp.net (16.197.64.53) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Mon, 23 Mar 2020 07:46:43 +0000 Received: from G4W10204.americas.hpqcorp.net (2002:10cf:5210::10cf:5210) by G4W9326.americas.hpqcorp.net (2002:10d0:2060::10d0:2060) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Mon, 23 Mar 2020 07:46:41 +0000 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (15.241.52.10) by G4W10204.americas.hpqcorp.net (16.207.82.16) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Mon, 23 Mar 2020 07:46:41 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BvH+cUiONVvD85nTPO01H+EaqlhBBBKrICZiDDyXvxr2pCnHAUFAJw8aGKnON1Hk6EiqWwIeImoJsB1XPJcvRmDS1hI4mzglyyERiT+4IQSVuboUqDjepBzm9uWcjXGSUISKZCiApgv9MO6bJG8ClionBPsBG5RXyQG0w6gwdpmNkV5jf/ia8OvfTtlS4Y7DAtYniEDgfd4hByky3hspXOTyhUWf0QZBfAl06riEX7nrTXJXjzE1J2GAPGcYie0zCXqWHp8qtym8ltwLtHhfSbyZ0v2ZjSoUV1OUIbltJEX18fEWvHNIcjFCT4+q6VBPXcew/lzmdbuY/1b0d5pzfA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WUF7IfZyDoVo/BhJZ19aTiWNvpakIeEisG6AyHoROvI=; b=bIdHuP6DvLi2KljJ/kv/ZYoCvux2NMjVd9sVo2X64R3Qv5AI+UXtqL85jE28ASTOZz1MoYUpEFVxZyC6icuPvI1gu4r+mRHrtyp1lDbSrF9lh6Kv3qjqPpiZxp9cjJbguKiBPM+PH0R3eMnzaFuJHeHR1kU1VNTD476EnGHeqdsihRn5iLQp3exrwzjl2F3TFX8hyVdAy8/6yUMpEnw7306LuOljsgDa3oQRX2LL6XaEQ+7zoPtooIl/Inr7vDBAGDJMcgvxI6/hq4KqsaOmHX0BKp2YgI1Q08FncF9y/HhUnoUqzUsjlIdIHITEYN4OtBLcrlSivRqdYDKszv3tiQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=hpe.com; dmarc=pass action=none header.from=hpe.com; dkim=pass header.d=hpe.com; arc=none Received: from TU4PR8401MB0429.NAMPRD84.PROD.OUTLOOK.COM (2a01:111:e400:770a::14) by TU4PR8401MB1279.NAMPRD84.PROD.OUTLOOK.COM (2a01:111:e400:770a::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2835.18; Mon, 23 Mar 2020 07:46:40 +0000 Received: from TU4PR8401MB0429.NAMPRD84.PROD.OUTLOOK.COM ([fe80::b0b5:c067:8f22:a402]) by TU4PR8401MB0429.NAMPRD84.PROD.OUTLOOK.COM ([fe80::b0b5:c067:8f22:a402%6]) with mapi id 15.20.2835.021; Mon, 23 Mar 2020 07:46:40 +0000 From: "Abner Chang" To: "Ni, Ray" , "devel@edk2.groups.io" CC: "Kinney, Michael D" , "Schaefer, Daniel (DualStudy)" , "Chen, Gilbert" Subject: Re: TianoCore Community Design Meeting Minutes - Mar 20, 2020 Thread-Topic: TianoCore Community Design Meeting Minutes - Mar 20, 2020 Thread-Index: AdX+ln/63mRZNDhhSlaiQ/rb3bppEQCLz/wwAAJ2NQAAAXOWkAADc7ygAACzdVA= Date: Mon, 23 Mar 2020 07:46:39 +0000 Message-ID: References: <734D49CCEBEEF84792F5B80ED585239D5C4A2E4C@SHSMSX104.ccr.corp.intel.com> <734D49CCEBEEF84792F5B80ED585239D5C4A74A2@SHSMSX104.ccr.corp.intel.com> <734D49CCEBEEF84792F5B80ED585239D5C4A7A8C@SHSMSX104.ccr.corp.intel.com> In-Reply-To: <734D49CCEBEEF84792F5B80ED585239D5C4A7A8C@SHSMSX104.ccr.corp.intel.com> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [16.242.247.131] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 516b3170-fe30-4049-70bc-08d7cefe52ab x-ms-traffictypediagnostic: TU4PR8401MB1279: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4303; x-forefront-prvs: 0351D213B3 x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(346002)(366004)(396003)(376002)(136003)(39860400002)(199004)(81156014)(5660300002)(8676002)(8936002)(4326008)(7696005)(52536014)(186003)(110136005)(2906002)(26005)(54906003)(66446008)(64756008)(316002)(71200400001)(66556008)(66476007)(86362001)(76116006)(33656002)(478600001)(81166006)(966005)(53546011)(55016002)(9686003)(66946007)(6506007);DIR:OUT;SFP:1102;SCL:1;SRVR:TU4PR8401MB1279;H:TU4PR8401MB0429.NAMPRD84.PROD.OUTLOOK.COM;FPR:;SPF:None;LANG:en;PTR:InfoNoRecords;A:1; received-spf: None (protection.outlook.com: hpe.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: jYp/30Fnh/+mA1ouE6JO3uaf8bKKYItEcHj6ayPVyoWD4h34N58BBK4CkmCsuokJsDfqo+dvFdV2DkbXWhu5bDrp4NaQtM9wbOdOhEKrK6FbUZWRdaWYFXUflc/10qyp02SankTLKy2gHO314+y3pYGAXUTraKArEsfs6B6kmcWNUmkXjold3DSnYHQJQ59XMlaYB9je3tqWIsWpPmARKIZVSI9xNWbIsjjcvkTYsI3r/442FfnxxZzppcCdL8E0qmkYp5v+Z3noZSG/2mjUq7qI/unUmwIt9qnQQkrjiiVoRTkXb17s3WU4IvCHhXTUsKpZEhPa1M52cmUCq2nQunOceCI31rWcANWKbToe+483wvt8JAwG1paqhDpWNO5D7dd9pasN9VZQiEkrfbrkskJ1Dd0KpBR9ai+pLPNKOZ9dXQTKjY7utvFrZWQYEvQhehWB2wG67FAaDVhdLTCJ2V5WssPmWu1uQGiTmZl6KabsgKaQHRejwpJXzYpkc3xwHLScnmdCp6f3P+lu6AvAIA== x-ms-exchange-antispam-messagedata: SjTKk7ypLpxPx+1fiGe3sk6E9Zmn7TlqOxKI5F1sCww4+o97bozOJ1p+SmkratsQAxqWKjszl81Gu4BsWajJYjotoAVKZwwnPQcuO43XXYny36way41lkwIZBWnPrO02VSwj+L8vdbSsVaHnuvhItw== X-MS-Exchange-CrossTenant-Network-Message-Id: 516b3170-fe30-4049-70bc-08d7cefe52ab X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Mar 2020 07:46:39.8727 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 105b2061-b669-4b31-92ac-24d304d195dc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: VLJSwZFXgakinSE25XvKUFIPBhTEowJqNo2c5qj5fSqK7Mq4ShomoRMTmFqozgXL+VaQN15LG+a0r7qRgF4fOQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: TU4PR8401MB1279 X-OriginatorOrg: hpe.com X-Proofpoint-UnRewURL: 4 URL's were un-rewritten MIME-Version: 1.0 X-HPE-SCL: -1 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138,18.0.645 definitions=2020-03-23_02:2020-03-21,2020-03-23 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 suspectscore=0 phishscore=0 malwarescore=0 adultscore=0 impostorscore=0 lowpriorityscore=0 bulkscore=0 mlxlogscore=999 spamscore=0 priorityscore=1501 mlxscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2003230046 Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_TU4PR8401MB0429F078B1D59A2AB1168A0CFFF00TU4PR8401MB0429_" --_000_TU4PR8401MB0429F078B1D59A2AB1168A0CFFF00TU4PR8401MB0429_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Ni, Ray [mailto:ray.ni@intel.com] Sent: Monday, March 23, 2020 3:33 PM To: Chang, Abner (HPS SW/FW Technologist) ; devel@edk2= .groups.io Cc: Kinney, Michael D ; Schaefer, Daniel (DualS= tudy) ; Chen, Gilbert Subject: RE: TianoCore Community Design Meeting Minutes - Mar 20, 2020 Please check one comment prefixed with [Ray-2]. From: Chang, Abner (HPS SW/FW Technologist) > Sent: Monday, March 23, 2020 2:40 PM To: Ni, Ray >; devel@edk2.groups.= io Cc: Kinney, Michael D >; Schaefer, Daniel (DualStudy) >; Chen, Gilbert > Subject: RE: TianoCore Community Design Meeting Minutes - Mar 20, 2020 From: Ni, Ray [mailto:ray.ni@intel.com] Sent: Monday, March 23, 2020 1:13 PM To: Chang, Abner (HPS SW/FW Technologist) >; devel@edk2.groups.io Cc: Kinney, Michael D >; Schaefer, Daniel (DualStudy) >; Chen, Gilbert > Subject: RE: TianoCore Community Design Meeting Minutes - Mar 20, 2020 Resend to devel@edk2.groups.io with my respons= es. announce@edk2.groups.io is not for tech dis= cussion and only few people have post permission. [Abner] Ok. I see. My response in below. From: Chang, Abner (HPS SW/FW Technologist) > Sent: Monday, March 23, 2020 12:05 PM To: Ni, Ray >; announce@edk2.grou= ps.io Cc: Kinney, Michael D >; Schaefer, Daniel (DualStudy) >; Chen, Gilbert > Subject: RE: TianoCore Community Design Meeting Minutes - Mar 20, 2020 Ray, my responses in line. From: Ni, Ray [mailto:ray.ni@intel.com] Sent: Friday, March 20, 2020 5:05 PM To: announce@edk2.groups.io Cc: Chang, Abner (HPS SW/FW Technologist) >; Kinney, Michael D >; Ni, Ray > Subject: TianoCore Community Design Meeting Minutes - Mar 20, 2020 Topic: 1. EDK2 DxeIpl Abstraction (Abner Chang/HPE) Slides: https://edk2.groups.io/g/devel/files/Designs/2020/0320/EDK2%20Dx= eIpl%20Abstraction.pdf Today's meeting was extended to 2 hours to discuss the overall RISC-V suppo= rt in EDKII. It makes sense because low-level design depends on the finaliz= e of high-level design. Today's RISC-V enabling in EDKII work is to provide a UEFI wrapper over RIS= C-V OpenSBI (Open Source Supervisor Binary Interface), which is an open-sou= rce reference implementation (https://github.com/riscv/opensbi) of RISC-V S= BI specification (https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-= sbi.adoc). OpenSBI itself is a boot loader. If RISC-V SBI specification is treated as = UEFI spec and OpenSBI is treated as the EDKII. Right now, Abner's work is the only effort that enables UEFI in RISC-V plat= forms. The EDKII RISC-V environment consists of three phases: SEC-PEI-DXE. A RISC-= V specific SEC module statically linked with OpenSBI exposes all interfaces= required by the UEFI wrapper. There are 3 sub-topics discussed in the meeting: 1. Which mode DXE phase is running at? RISC-V defines three privileged modes: Machine/Supervisor/User Mode. SEC and PEI run in M mode and DXE can run either in M mode or S mode whi= ch is the platform's choice. If DXE runs in S mode, some of the resources cannot be accessed. UEFI spec says RISC-V only runs in M mode during post including DXE. Spe= c needs update. [Abner] Yes, this must be updated. I will take this. 2. How to resolve MdeModulePkg's dependency on RiscVPkg? The dependency is because the M to S mode switch [Abner] This may not accurate. I think you mean the dependency is exposed d= ue to we rely on RISC-V OpenSBI execution mode switch function to put DXE p= hase in Supervisor mode. We should fix the issue which DXE IPL mixes up the= processor architecture in itself, but not to fix switch mode itself. [Ray] Your words are more accurate. But if we split the change to 2 parts: = one requires DXE phase runs in M mode, the other requires DXE phase runs in= S mode. Only the 2nd part introduces the MdeModulePkg's dependency on Risc= VPkg. We could potentially work on the first part (when the final conclusio= n is RISC-V does need SEC and PEI phases for UEFI). [Abner] We actually do not have to split DXE phase into two modes. This is = actually a very simple DXEIPL dependency issue but seems to me we led this = to even far. DXE phase could be just in M-mode or S-mode depends on platfor= m requirements and processor capability. To split DXE phases into two diffe= rent modes is unnecessary and not much value. Separate SEC/PEI and DXE/BDS = into two modes (or in the same mode) is good enough. DXE phases has M-mode = actually, that is when the OpenSBI function is trigger in SMode and execute= d in MMode. [Ray-2] https://github.com/tianocore/edk2-staging/commit/33a9bd8984163ca2a7= cc50627c15087f7574e203 adds two library instances. One of them is to simply= call SwitchStack() to DXE phase which means DXE phase runs in the same mod= e as PEI phase. The other one calls to OpenSBI to switch to S mode. [Abner] Yes. the NULL instance one (Simple call to SwitchStack()) will neve= r been used and it is there just for building RiscVPkg package. I think I s= hould remove it as Ard mentioned in his comment (I can't remember who exact= ly mentioned that). The second one is used for RISC-V platforms, ThisScratch->next_mode =3D PRV= _S is the parameters to switch to either SMode or MMode. Currently it is ha= rdcoded but could be an PCD defined in RiscVPlatformPkg and override by pla= tform dsc. Sorry, I thought "DXE phase" you mentioned refers to the entire DXE phase. This project is targeted on having RISC-V edk2 port to align with edk2 diff= erent execution phases since 2016 and presented in UEFI plugfest 2016. This= is also the current most use cases of PC and server (HPE are focusing on P= C/Server area), to skip SEC and PEI is not the initial goal of this project= . We can raise another project for skipping SEC and PEI, I assume you were = saying the UefiPayloadPkg? Abner's solution tries to address this dependency issue by introducing a= nother abstract layer. (see slides: https://edk2.groups.io/g/devel/files/De= signs/2020/0320/EDK2%20DxeIpl%20Abstraction.pdf) Mike proposes another solution: RiskVPkg exposes the mode switch interfa= ces (sbi_init ?) through PPI and the PPI definition can be in MdePkg which = might be included by PI spec. [Abner] This may not work if the PPI/Protocol still have dependency with RI= SC-V definitions. But it is ok if could we define a generic PPI/Protocol su= ch as EFI_EXECUTION_MODE_PROTOCOL(PPI) under MdePkg. Then arch provides the= implementation, however, this is our midterm plan not for now though. NULL= instance of DxeIplHadndoffLib is still a neat choice IMO. [Ray] The original plan was to expose OpenSBI interfaces through PPI/Protoc= ol defined in PI spec and MdePkg. But given the fact OpenSBI is an under-de= velopment project and your change is a UEFI wrapper over OpenSBI, it may be= hard to propose the OpenSBI interfaces to PI spec. There was an idea raise= d in the meeting which is to extend UefiPayloadPkg for RISC-V. [Abner] Actually we don't intend to have OpenSBI EFI protocol defined in PI= nor UEFI spec. The EFI version OpenSBI interface is only for RISC-V arch, = the spec will be in RISC-V github instead. UefiplayloadPkg is the firmware payload for CoreBoot or other boot loader. = This approach could be classified as another project and different from ou= r approach which is the regular EDK2 implementation aligns with x86 PC/Serv= er firmware arch. And this is the goal of this initial edk2 RISC-V port as = well, which is based on edk2 boot phases. For HPE, we won't use CoreBoot, L= inuxBoot or other boot mechanisms for now or even in the future (I can't se= e any chance so far) in our mainstream server products. Whether to use Uefi= PayloadPkg is determined by system vendors, also depends on the demands of = firmware support and corporate strategy. We should not mixed up these diffe= rent firmware mechanisms. Again, we are fine to create another project for = UefiPayloadPkg though, but that is far from HPE system firmware direction. 3. Location of RiscVPkg and RiscVPlatformPkg RiscVPkg in @edk2-platforms/Silicon/... directory. RiscVPlatformPkg in @edk2-platforms/Platform/... directory. Long term goal is to put all CPU implementation that follows industry st= andard to UefiCpuPkg, including ARM and RISC-V. [Abner] We can consider this solution to put RISC-V packages in edk2-platfo= rms in temporary. However, the final decision should be made accroding, 1. The plan for refining UefiCpuPkg. It is meaningless to put RISC-V pac= kages in edk2-platforms if the plan of UefiCpuPkg refining is something lik= e one or two years. 2. How far it is from current UefiCpuPkg implementation to the ideal gen= eric UefiCpuPkg for all archs? [Ray] RiscVPlatformPkg in @edk2-platforms doesn't depend on above 2 questio= ns. [Abner] RiscVPlatformPkg still has dependency with RiscVPkg. To speak frank= ly, that is not a good idea to separate RiscVPkg and RiscVPlatform packages= into two repos, that is a nightmare and burdens to maintain changes in two= different repos even the commit in both repos fix the same issue. 4. Which changes can be in edk2 Need Abner to look at all the changes again. But at least the INF/C chan= ges that enable individual drivers to be built by RISC-V compiler can. [Abner] yes. Thanks, Ray --_000_TU4PR8401MB0429F078B1D59A2AB1168A0CFFF00TU4PR8401MB0429_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

From: Ni, Ray [mailto:ray.ni@intel.com]
Sent: Monday, March 23, 2020 3:33 PM
To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@hpe.com>= ;; devel@edk2.groups.io
Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Schaefer, = Daniel (DualStudy) <daniel.schaefer@hpe.com>; Chen, Gilbert <gilbe= rt.chen@hpe.com>
Subject: RE: TianoCore Community Design Meeting Minutes - Mar 20, 20= 20

 

Please check one comment prefixed with [Ray-2].=

 

From: Chang, Abner (HPS SW/FW Technologist) &= lt;abner.chang@hpe.com>
Sent: Monday, March 23, 2020 2:40 PM
To: Ni, Ray <ray.ni@intel.com= >; devel@edk2.groups.io
Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Schaefer, Daniel (DualStudy) <daniel.schaefer@hpe.com>; C= hen, Gilbert <gilbert.chen@hpe.c= om>
Subject: RE: TianoCore Community Design Meeting Minutes - Mar 20, 20= 20

 

 

From: Ni, Ray [mailto:ray.ni@intel.com]
Sent: Monday, March 23, 2020 1:13 PM
To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@hpe.com>; devel@edk2.groups.io
Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Schaefer, Daniel (DualStudy) <daniel.schaefer@hpe.com>; C= hen, Gilbert <gilbert.chen@hpe.c= om>
Subject: RE: TianoCore Community Design Meeting Minutes - Mar 20, 20= 20

 

Resend to de= vel@edk2.groups.io with my responses.

 

announce@= edk2.groups.io is not for tech discussion and only few people have post= permission.

[Abner] <= /i>Ok. I see. My response in below.<= /o:p>

 

 

From: Chang, Abner (HPS SW/FW Technologist) &= lt;abner.chang@hpe.com>
Sent: Monday, March 23, 2020 12:05 PM
To: Ni, Ray <ray.ni@intel.com= >; announce@edk2.groups.io
Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Schaefer, Daniel (DualStudy) <daniel.schaefer@hpe.com>; C= hen, Gilbert <gilbert.chen@hpe.c= om>
Subject: RE: TianoCore Community Design Meeting Minutes - Mar 20, 20= 20

 

Ray, my responses in l= ine.

 

From: Ni, Ray [mailto:ray.ni@intel.com]
Sent: Friday, March 20, 2020 5:05 PM
To: announce@edk2.groups.= io
Cc: Chang, Abner (HPS SW/FW Technologist) <abner.chang@hpe.com>; Kinney, Michael D <michael.d.kinney@intel.com>; = Ni, Ray <ray.ni@intel.com>
Subject: TianoCore Community Design Meeting Minutes - Mar 20, 2020

 

Topic:

 

1. EDK2 DxeIpl Abstraction (Abner Chang/HPE)

 

   Slides: https://edk2.groups.io/g/devel/files/Designs/2020/0320/EDK2%20DxeIpl%20Abst= raction.pdf

 

 

 

Today's meeting was extended to 2 hours to discuss t= he overall RISC-V support in EDKII. It makes sense because low-level design= depends on the finalize of high-level design.

 

Today's RISC-V enabling in EDKII work is to provide = a UEFI wrapper over RISC-V OpenSBI (Open Source Supervisor Binary Interface= ), which is an open-source reference implementation (https://github.com/riscv/opensbi) of RISC-V SBI specification (https://github.com/riscv/riscv-sbi-doc/blo= b/master/riscv-sbi.adoc).

 

OpenSBI itself is a boot loader. If RISC-V SBI speci= fication is treated as UEFI spec and OpenSBI is treated as the EDKII.<= /o:p>

 

Right now, Abner's work is the only effort that enab= les UEFI in RISC-V platforms.

 

The EDKII RISC-V environment consists of three phase= s: SEC-PEI-DXE. A RISC-V specific SEC module statically linked with OpenSBI= exposes all interfaces required by the UEFI wrapper.

 

There are 3 sub-topics discussed in the meeting:

 

1. Which mode DXE phase is running at?

 

   RISC-V defines three privileged modes: = Machine/Supervisor/User Mode.

   SEC and PEI run in M mode and DXE can r= un either in M mode or S mode which is the platform's choice.

   If DXE runs in S mode, some of the reso= urces cannot be accessed.

   UEFI spec says RISC-V only runs in M mo= de during post including DXE. Spec needs update.

[Abner] Yes, thi= s must be updated. I will take this.

 

2. How to resolve MdeModulePkg's dependency on RiscV= Pkg?

 

   The dependency is because the M to S mo= de switch

[Abner] This may= not accurate. I think you mean the dependency is exposed due to we rely on= RISC-V OpenSBI execution mode switch function to put DXE phase in Supervis= or mode. We should fix the issue which DXE IPL mixes up the processor architecture in itself, but not to fix swit= ch mode itself.

[Ray] Your words are more accurate. But if we = split the change to 2 parts: one requires DXE phase runs in M mode, the oth= er requires DXE phase runs in S mode. Only the 2nd part introduc= es the MdeModulePkg’s dependency on RiscVPkg. We could potentially work on the first part (when the final conc= lusion is RISC-V does need SEC and PEI phases for UEFI).=

[Abner] We actua= lly do not have to split DXE phase into two modes. This is actually a very = simple DXEIPL dependency issue but seems to me we led this to even far. DXE= phase could be just in M-mode or S-mode depends on platform requirements and processor capability. To split DXE ph= ases into two different modes is unnecessary and not much value. Separate S= EC/PEI and DXE/BDS into two modes (or in the same mode) is good enough. DXE= phases has M-mode actually, that is when the OpenSBI function is trigger in SMode and executed in MMode.

[Ray-2] htt= ps://github.com/tianocore/edk2-staging/commit/33a9bd8984163ca2a7cc50627c150= 87f7574e203 adds two library instances. One of them is to simply call SwitchStack() to DXE phase which means DXE p= hase runs in the same mode as PEI phase. The other one calls to OpenSBI to = switch to S mode.

[Abner] Yes. the= NULL instance one (Simple call to SwitchStack()) will never been used and = it is there just for building RiscVPkg package. I think I should remove it = as Ard mentioned in his comment (I can’t remember who exactly mentioned that).

The second one i= s used for RISC-V platforms, ThisScratch->next_mode<= /span> =3D PRV_S is the parameters to switch to e= ither SMode or MMode. Currently it is hardcoded but could be an PCD defined= in RiscVPlatformPkg and override by platform dsc.

Sorry, I thought= “DXE phase” you mentioned refers to the entire DXE phase.=

 

 

This project is = targeted on having RISC-V edk2 port to align with edk2 different execution = phases since 2016 and presented in UEFI plugfest 2016. This is also the cur= rent most use cases of PC and server (HPE are focusing on PC/Server area), to skip SEC and PEI is not the initi= al goal of this project. We can raise another project for skipping SEC and = PEI, I assume you were saying the UefiPayloadPkg?=

 

   Abner's solution tries to address = this dependency issue by introducing another abstract layer. (see slides: https://edk2.groups.io/g/devel/files/Designs/2020/0320/EDK2%20DxeIpl%20Abst= raction.pdf)

   Mike proposes another solution: RiskVPk= g exposes the mode switch interfaces (sbi_init ?) through PPI and the PPI d= efinition can be in MdePkg which might be included by PI spec.

[Abner] This may= not work if the PPI/Protocol still have dependency with RISC-V definitions= . But it is ok if could we define a generic PPI/Protocol such as EFI_EXECUT= ION_MODE_PROTOCOL(PPI) under MdePkg. Then arch provides the implementation, however, this is our midterm plan n= ot for now though. NULL instance of DxeIplHadndoffLib is still a neat choic= e IMO.

[Ray] The original plan was to expose OpenSBI = interfaces through PPI/Protocol defined in PI spec and MdePkg. But given th= e fact OpenSBI is an under-development project and your change is a UEFI wr= apper over OpenSBI, it may be hard to propose the OpenSBI interfaces to PI spec. There was an idea raised in = the meeting which is to extend UefiPayloadPkg for RISC-V.

[Abner] Actually= we don’t intend to have OpenSBI EFI protocol defined in PI nor UEFI = spec. The EFI version OpenSBI interface is only for RISC-V arch, the spec w= ill be in RISC-V github instead.

 

UefiplayloadPkg = is the firmware payload for CoreBoot or other boot loader.  This appro= ach could be classified as another project and different from our approach = which is the regular EDK2 implementation aligns with x86 PC/Server firmware arch. And this is the goal of this init= ial edk2 RISC-V port as well, which is based on edk2 boot phases. For HPE, = we won’t use CoreBoot, LinuxBoot or other boot mechanisms for now or = even in the future (I can’t see any chance so far) in our mainstream server products. Whether to use UefiPayloadPkg i= s determined by system vendors, also depends on the demands of firmware sup= port and corporate strategy. We should not mixed up these different firmwar= e mechanisms. Again, we are fine to create another project for UefiPayloadPkg though, but that is far from = HPE system firmware direction.

 

3. Location of RiscVPkg and RiscVPlatformPkg

 

   RiscVPkg in @edk2-platforms/Silicon/...= directory.

   RiscVPlatformPkg in @edk2-platforms/Pla= tform/... directory.

   Long term goal is to put all CPU implem= entation that follows industry standard to UefiCpuPkg, including ARM and RI= SC-V.

[Abner] We can c= onsider this solution to put RISC-V packages in edk2-platforms in temporary= . However, the final decision should be made accroding,

  1. = The plan for refining UefiCpuPkg. It is meaningless to put RISC-V packag= es in edk2-platforms if the plan of UefiCpuPkg refining is something like o= ne or two years.
  2. How far it is from current UefiC= puPkg implementation to the ideal generic UefiCpuPkg for all archs?

[Ray] RiscVPlatformPkg in @edk2-platforms does= n’t depend on above 2 questions.

[Abner] RiscVPla= tformPkg still has dependency with RiscVPkg. To speak frankly, that is not = a good idea to separate RiscVPkg and RiscVPlatform packages into two repos,= that is a nightmare and burdens to maintain changes in two different repos even the commit in both repos fix = the same issue.

 

4. Which changes can be in edk2

 

   Need Abner to look at all the changes a= gain. But at least the INF/C changes that enable individual drivers to be b= uilt by RISC-V compiler can.

[Abner] yes.

 

Thanks,

Ray

  

--_000_TU4PR8401MB0429F078B1D59A2AB1168A0CFFF00TU4PR8401MB0429_--