From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0b-002e3701.pphosted.com (mx0b-002e3701.pphosted.com [148.163.143.35]) by mx.groups.io with SMTP id smtpd.web11.6496.1646128591357612732 for ; Tue, 01 Mar 2022 01:56:32 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@hpe.com header.s=pps0720 header.b=C+fStUhc; spf=permerror, err=parse error for token &{10 18 %{ir}.%{v}.%{d}.spf.has.pphosted.com}: invalid domain name (domain: hpe.com, ip: 148.163.143.35, mailfrom: prvs=0059c8a80e=abner.chang@hpe.com) Received: from pps.filterd (m0148664.ppops.net [127.0.0.1]) by mx0b-002e3701.pphosted.com (8.16.1.2/8.16.1.2) with ESMTP id 2219a9vZ019381; Tue, 1 Mar 2022 09:56:26 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hpe.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=pps0720; bh=TShpWDtKuWXc2EhB9jWC7nDZmtPey+Q8ogZ6qh3RPwY=; b=C+fStUhcHXt3vkGahsY0RIxgQoVaPNQzZzEi4WhcXCQeA2YeGpxYumj0U86gmt3k7w2z /M+EacXkgaOuPJA/v9FVbQ2PeSaQslBYdCNdqN8Un4C0bN7EznOCqHa3al+V3sSCXhUw v/P4V4ccRywmfGlsO1uKDXgjiVH4TCtcOrczhwYPdrLWlhif45xUEDA3Zz43W+QuK2sY fY2FE4yTKuGD6rux5gxfOgTXwUpvyBDdoBu2StWcQkw91u0Sf31idm6/aRwpA3U8jRVY j974QUJZ+2l2y2vBkeJH3q9TfW5SZG6K++ryU0eNWrhlaH6YIUlMUnE1dtysLuSO9VeW IQ== Received: from g9t5008.houston.hpe.com (g9t5008.houston.hpe.com [15.241.48.72]) by mx0b-002e3701.pphosted.com (PPS) with ESMTPS id 3eh2r3y7k3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 01 Mar 2022 09:56:24 +0000 Received: from G1W8107.americas.hpqcorp.net (g1w8107.austin.hp.com [16.193.72.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by g9t5008.houston.hpe.com (Postfix) with ESMTPS id D705B57; Tue, 1 Mar 2022 09:56:15 +0000 (UTC) Received: from G1W8108.americas.hpqcorp.net (2002:10c1:483c::10c1:483c) by G1W8107.americas.hpqcorp.net (2002:10c1:483b::10c1:483b) with Microsoft SMTP Server (TLS) id 15.0.1497.23; Tue, 1 Mar 2022 09:56:15 +0000 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (15.241.52.12) by G1W8108.americas.hpqcorp.net (16.193.72.60) with Microsoft SMTP Server (TLS) id 15.0.1497.23 via Frontend Transport; Tue, 1 Mar 2022 09:56:15 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JpD3wcDlzskAOWatx9WdFLIPD4CyWHnS8fY+PM3KHrdkhH12PTa9yKJaofYDnMbKU1D9v5G45WCCmngP0fkRnU5G+GwttbJMtuAe2JGJTM7WJekQfAbr9oqgHYmvkR1W/0AIi+FdMhGTEYi1KMMBcIkyyfWTLDb2dXEciiK0uV/0UN7STPQ5fHEahU+wVrUqDBGxPSpYrKqnkruD/PoFTj9mF16bv+phvHmRgdDfnC/lN2Nt4aoKO0vgbkc6KenPVDzHRijkggGBTXo1vzFSbCCBllGnHqYMi5apBkpptDYueiwCkggMprZODksdyiisPtteYDH2fMNiJ7joHaC5VA== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=pY0q2pvtzM1+/7Gb0pRrEmryReWmyy86LGfL9BmDdZ4=; b=TalqK92756/06v3lokCZm7sSQdU4i3NV3Psi/ZqJ4w0qf8gXNKE+dzcaYeMSkl80aXt/BzRYGP+2xk90ujjnUUmnLs5+VChqOy86KT1NUevuFZfMQZeNYnlJVQQYLy7URKMZk4BBRCLFwYhf7+qZJHyvU60KwZXqTaRv0w4AwViFJmfKCNmYpSmclRTS2eYX7U/DUwCgRlXKIRTwKrAtnq3r8CvYUn74qrmjjJDnQFCVn+Ni+4sym40gFNsr56lidXMnLmfNlvWKP+7e5YGEZGunYGWin2bXsDO/3VdpNCLJjEhpC9qJSlYuucgXh+uN7KK/vQh2ogUF262m+5+ZPw== 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 PH7PR84MB1885.NAMPRD84.PROD.OUTLOOK.COM (2603:10b6:510:154::18) by PH7PR84MB2985.NAMPRD84.PROD.OUTLOOK.COM (2603:10b6:510:15c::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5017.24; Tue, 1 Mar 2022 09:56:12 +0000 Received: from PH7PR84MB1885.NAMPRD84.PROD.OUTLOOK.COM ([fe80::5ce:79b4:a546:d527]) by PH7PR84MB1885.NAMPRD84.PROD.OUTLOOK.COM ([fe80::5ce:79b4:a546:d527%3]) with mapi id 15.20.5017.026; Tue, 1 Mar 2022 09:56:12 +0000 From: "Abner Chang" To: "Ni, Ray" , "Kinney, Michael D" , Leif Lindholm , "devel@edk2.groups.io" , LiChao CC: Andrew Fish , Sami Mujawar , "Schaefer, Daniel (ROM Janitor)" , Sunil V L Subject: Re: RFC: UefiCpuPkg for all processor archs Thread-Topic: RFC: UefiCpuPkg for all processor archs Thread-Index: AQHYLQtESpAa1qZtgkOiyqk+FuK0eayqHAOAgAAt3tw= Date: Tue, 1 Mar 2022 09:56:12 +0000 Message-ID: References: <20220108040753.15926-1-abner.chang@hpe.com> In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: suggested_attachment_session_id: 00ecbd4f-53f5-2f7a-f2ab-c2f3ad05f778 x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a00af813-b767-42e1-14be-08d9fb69b7f7 x-ms-traffictypediagnostic: PH7PR84MB2985:EE_ x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: yCsxbgcXnQSow+LZZbREh0A2XWC8eeinODSatXG2yY24ezqSpJ6MLuW8m18QovfULiutsVpfNeSFlHcxT48bzMrtUHdp9TS8fTE87ZmEcKQSJtKlaCYMDl6lQaB4QnNXIeVrjmNFR9BSVhbtIiXrSDb56QTXYu1k2hJ5PV7Bs+uuZWsmKeaZm8DLOfmMs9C1lgL95cbmrQAJlQbYPd6gZm6mm9AKXd1HBS4ug7q2LMLfkUnhlG7fVQ/yxb7J+1/y6nRvV+0C9SoqeTUbVEaHP0MegjJuViMYdqCPbK5CHHuNCRZeNdHY7DF5xxTa9YlO2JK6hJnRohedVvO2wT6oreoDtKvgtmKkNoHNTLL396eAs3ylB7VlUVjDx5evWsW3kIjtS0SPXQjU/Ocfv7plfc2BAQpsRvCOAfbGenbkRepEXQyZT+stO4MZRmp+CSEjkeP5WraRrcWzcMqvy7RSkBl8RgR0bgWr6GnRS4j2T7/lZAv0kuyLLlfcyrKN2sQA3vXYmTvUJJn9HcszFDtef1sX68qR3ZZ7q/kBBq0hIjIiqKwtD/udIRRr+Xuk6ZAR+CBEF590CElRxgvDuXr7/+dxYbGfciRuCxbqm3AEXqXtUT03fCHJfKmEa6mkqVhYwtTlO/9C85KEQZqMHbtBjYd3KI3yRj8oFPEdysmlHAp6GC067hV0GK2EYXA0jMFm0d/5TfNBoaOBVHT0IjQSgXOfstrxkBiA6jhHa8rD+71yjV7+Jt0ZQIprnXL0ykCpJVvYzWmHylcPhk211seI6v61LkqH1pOjLkLu9hnglsATOiWDDq96tE7GZFqSBSFBM6MYc8q3o5+Rvdv8XNMj5w== x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH7PR84MB1885.NAMPRD84.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230001)(366004)(316002)(19627235002)(110136005)(7696005)(6506007)(54906003)(53546011)(71200400001)(186003)(9686003)(966005)(26005)(166002)(52536014)(508600001)(30864003)(8936002)(5660300002)(83380400001)(86362001)(2906002)(19627405001)(33656002)(38100700002)(66556008)(66946007)(76116006)(55016003)(82960400001)(66476007)(122000001)(91956017)(66446008)(4326008)(8676002)(38070700005)(64756008)(559001)(579004);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?gPpIvmu1HHsq1a2K74LaRVenv9b6CSuN9kAlpmBJu2LMn3WedP8Sa4zZ?= =?Windows-1252?Q?LD9Y4W3yFaM4aZ7zAQMrmcDqL0amhBfLNSLpONztKpK2hAnYu0rv03KO?= =?Windows-1252?Q?UZDVZNB5JB1a6OmxDDacZxJeAiSExMEo9EomfpQyvxkH5LgUrK2k2olP?= =?Windows-1252?Q?SsL7PcNXQwLHvbUspmdk1e71Vimf3CnvDtuwaQLOo6CghQ1R9wx7XKN4?= =?Windows-1252?Q?hCZPGq8WiZrJwqhtb1VBiVijzFLuZJJWhlROF9GmFUeiCi44JUi1xkly?= =?Windows-1252?Q?VywmmSkKe7yD/K+RLdfIBeMxIkvf1W0pOZUI5PNy3zTEo6CS0t1HuTEq?= =?Windows-1252?Q?kUXgM5UwPreGuNJC46vA4ISNdDpu5+fbORxBPVf+I6l2p0erdZPq461Q?= =?Windows-1252?Q?E5ocCYcF65FXoagF2ugGtUIJfKh6EmWoJHDrshKA+Fy+fl30MjoG6Rdd?= =?Windows-1252?Q?TOhCya06OPcqdPBMzTfLhKsKx/pepaHWY71SEf12FsUy09hWxy79xXdV?= =?Windows-1252?Q?s9XDhEX6cIU+pfis/6i+jnJHFWIRvHdLmBTp34hLHRMN5Rz71G89O2Kf?= =?Windows-1252?Q?TzNw0I6UT0VWcjqLJCIGoLqNqiLzBt9Cm3iWBnMDGol8aAvl+z3DCXmJ?= =?Windows-1252?Q?lvFLC0DpJKg+o7W0s8nxNmv150PCDOniI9SGYLSdyb7Iyi4pQhC6T5qw?= =?Windows-1252?Q?r5NSIb5+UPiAfC3H0r7tsoa9DAVT/8FhnZAeYRTYXSly9GV3Omxp0Ii9?= =?Windows-1252?Q?z7NV639I+wGqPvFMxMjJo2+34qGe3TxHAZDF5+zegmDSKo394fXqNyfd?= =?Windows-1252?Q?CcIXyWWkiCYf3jA1zqZ2QBGqzLxoiS4ch3Jz3U7Nq7fTvP1vHpasEyUU?= =?Windows-1252?Q?QoD//I2SZSa1a/gGFfq/DKaZkrSqbXVUpqeaLmVW3cBrxpfiAfAGVAYe?= =?Windows-1252?Q?BnlR8NPPu0j2YX2lgwCgL3Og5O1IDsF9ztEnlWB57nSOWixFmJoQw7dW?= =?Windows-1252?Q?LnolE/mhKTzEQUiimXzDrCOwccuB6J9+BMMjyOCWbsjvGCGH8zw+h5LJ?= =?Windows-1252?Q?pria+uN5B9PXYjQ22nFV63vaOFAoyn9VZhNfLCoL7hkZJSNwV1qdxuDZ?= =?Windows-1252?Q?T3IflOMOwYSeHgMwVnWxVRKHikIdJirpCOW9cNFvICBzbLWRoRR9rX8J?= =?Windows-1252?Q?0z2ofC2LEBc5Uh5KpH4oDOJWqdGP2PgAFv0eBmfOr87HSzogqPIRubPY?= =?Windows-1252?Q?6+2iFULJvsXHi/XUxdKSA5ucnunNNNYd7EDR3j0vTfn9650CQtlWtppn?= =?Windows-1252?Q?Qxxh0vnfn92ng0EwHKsHdOCGxo4xS6T20lgqpp2BQlcC2B7f65Vaidh/?= =?Windows-1252?Q?a54RylV0l7gos+/frbW8anTs3aO5gZW7U0uzQNv+VeCrVb5CAZWyBk7u?= =?Windows-1252?Q?c0kt2ijNRxuFOeJ6EArhPJFWMvqiLj8TsjIkuusFs5Ow0cWCthWsAcUj?= =?Windows-1252?Q?1Srq8TVjkq25EMOZAKueKgCwIplIOKcTpqSr9aVvCr9PoHWClv/LnVug?= =?Windows-1252?Q?wYYs34F6du0R6NBbIY7TCe0ktyRgGyOvcIRZjBgxGeIj5bzOL9OFJ8l0?= =?Windows-1252?Q?1yOXNCLhRW5bNHSIhRatPx1JlLGcYUgujb6Tu3g05HjhqISFn7kM0LGX?= =?Windows-1252?Q?TMwpj8nJr5wJWvhN2rq8noa2WUASJ+/zbPxIqST8WS40hZo/AJRjTA?= =?Windows-1252?Q?=3D=3D?= X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH7PR84MB1885.NAMPRD84.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: a00af813-b767-42e1-14be-08d9fb69b7f7 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Mar 2022 09:56:12.4467 (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: ECNKiV2EMGoch8VT098OuoZVBIFltgQ/eXnt9dKNgxx04Jd0cP8Mhq++FLjBcH3wTkivTL53C+QniSUPiYmYMg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR84MB2985 X-OriginatorOrg: hpe.com X-Proofpoint-ORIG-GUID: UkSf0EYPenjYEKZCkh8aZknMoHGS4CxT X-Proofpoint-GUID: UkSf0EYPenjYEKZCkh8aZknMoHGS4CxT X-Proofpoint-UnRewURL: 12 URL's were un-rewritten MIME-Version: 1.0 X-HPE-SCL: -1 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.816,Hydra:6.0.425,FMLib:17.11.64.514 definitions=2022-02-28_10,2022-02-26_01,2022-02-23_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1015 priorityscore=1501 lowpriorityscore=0 suspectscore=0 mlxlogscore=999 adultscore=0 phishscore=0 bulkscore=0 mlxscore=0 spamscore=0 impostorscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2201110000 definitions=main-2203010051 Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_PH7PR84MB188578F5E35ED88047E79A8AFF029PH7PR84MB1885NAMP_" --_000_PH7PR84MB188578F5E35ED88047E79A8AFF029PH7PR84MB1885NAMP_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Ray, RISC-V doesn't have the similar functions as those are provided in BaseUefi= CpuLib.c. In this case, what we can do is just leverage the library class b= ut different implementation for archs? At least we don't need another library class for RISC-V. We can have the co= mmon source file if all archs provided the same functionality later. Regards, Abner ________________________________ From: Ni, Ray Sent: Tuesday, March 1, 2022 3:07 PM To: Chang, Abner (HPS SW/FW Technologist) ; Kinney, Mi= chael D ; Leif Lindholm ; de= vel@edk2.groups.io ; LiChao Cc: Andrew Fish ; Sami Mujawar ; LiC= hao ; Schaefer, Daniel (ROM Janitor) ; Sunil V L Subject: RE: RFC: UefiCpuPkg for all processor archs Abner, UefiCpuPkg\SecCore\SecCoreNative.inf is a module that might not depend on X= 86. It assumes the UefiCpuPkg/ResetVector inits the CPU well. UefiCpuPKg/BaseUefiCpuLib 1. Rename BaseUefiCpuLib.c to BaseUefiCpuLibIa32X64.c BaseUefiCpuLibRiscV64.c for RISC-V arch and assembly code under /RISCV64 2. Or move all X86 source files to under BaseUefiCpuLib/X86, BaseUefiCpuLib= /RISC-V for RISC-V arch (I prefer this way, the directory looks clean) That depends on whether the RISC-V or LoongArch can implement the same API = as that in X86 version. Maybe some of the APIs are too X86 specific that ma= kes it hard for implementing for other ARCHs. That might lead to a more abs= traction. Without the concrete implementation available, I have no idea wha= t abstraction is. Thanks, Ray From: Chang, Abner (HPS SW/FW Technologist) Sent: Tuesday, March 1, 2022 9:26 AM To: Kinney, Michael D ; Leif Lindholm ; devel@edk2.groups.io; Ni, Ray ; LiChao Cc: Andrew Fish ; Sami Mujawar ; LiC= hao ; Schaefer, Daniel ; Sunil= V L Subject: RFC: UefiCpuPkg for all processor archs Hi Mike and Ray, I just got a chance to back on this topic and below are few questions regar= ding the UefiCpuPkg for all processor archs. I change the subject and loop Chao Li from Loongsoon who is contributing Lo= ongarch64 to Uefi/edk2. He may have to handle the similar things for Loonga= rch64. I went through RISC-V modules that currently located on edk2-platforms repo= (Platform/RISC-V/PlatformPKg and Silicon/RISC-V/ProcessorPkg) and figure o= ut the modules we would move to under UefiCpuPkg and MdeModulePkg. We coul= d go through the proposal in the design meeting later, however I would like= to confirm the proposal of revising modules under /UEfiCpuPkg those were i= mplemented in X86 oriented before we get to that point. * UefiCpuPKg\SecCore * The implementation of this module is very x86 oriented. There is like= ly nothing to leverage between archs. My thought was * 1. Having RISC-V SecCore in its own folder, e.g. UefiCpuPkg/RISC-V/Se= cCore and create the individual INF for archs. * However, 2. We can also consider having the separate section in SecCore/SecCore.inf.= Move all X86 source files to under UefiCpuPkg/SecCore/X86 and have /RISC-V= folder under UefiCpuPkg/SecCore for RISC-V arch. (I prefer this way) * * UefiCpuPKg/BaseUefiCpuLib * 1. Rename BaseUefiCpuLib.c to BaseUefiCpuLibIa32X64.c * BaseUefiCpuLibRiscV64.c for RISC-V arch and assembly code under /R= ISCV64 * 2. Or move all X86 source files to under BaseUefiCpuLib/X86, BaseUefi= CpuLib/RISC-V for RISC-V arch (I prefer this way, the directory looks clean= ) * * UefiCpuPKg/CpuExceptionHandlerLib Too many X86 source files, move all X86 source files to under CpuExecptionH= ander/X86, CpuExecptionHander/RISC-V for RISC-V arch * Having abstract level under /CpuExecptionHander, e.g. INF, PeiExcepti= on.c, DxeException.c and etc. * * UefiCpuPKg\Library\CpuTimerLib * 1. Rename BaseCpuTimerLib.c to BaseCpuTimerLibIa32X64.c, BaseCpuTimer= LibRiscV64.c for RISC-V arch. * 2. Or move all X86 source files to under BaseUefiCpuLib/X86, BaseUefi= CpuLib/RISC-V for RISC-V arch (I prefer this way) * * UefiCpuPKg/CpuDxe * Revise CpuDxe.c and CpuDxe.h to be abstract for the processor archs. * Move all x86 implementations to under /X86, CpuDxe/RISC-V for RISC-V = CpuDxe implementation Let me know your thoughts, I can initiate the PoC code after we get on the = same page. Thanks Abner ________________________________ From: Chang, Abner (HPS SW/FW Technologist) Sent: Saturday, February 5, 2022 10:56 PM To: Kinney, Michael D >; Leif Lindholm >; de= vel@edk2.groups.io >; Ni, Ray > Cc: Andrew Fish >; Sami Mujawar > Subject: RE: [edk2-devel] [PATCH 01/79] ProcessorPkg/Include: Add header fi= les of RISC-V processor package Thanks Mike. The reason I asked this question is we are working on the OvmfRiscV64 as yo= u suggested. However as you know that both RISC-V processor and platform pa= ckages are currently stay in edk2-platforms. We have to make sure CI won= =92t throw errors if we use the edk2 modules in edk2-platforms. We are in r= ush to have RISC-V edk2 OVMF for RISC-V community. We will start to move RI= SC-V edk2 port to UefiCpuPkg or MdePkg once RISC-V OVMF port is upstream. Abner From: Kinney, Michael D > Sent: Saturday, February 5, 2022 4:22 AM To: Chang, Abner (HPS SW/FW Technologist) >; Leif Lindholm >; devel@edk2.groups.io; Ni, Ray > Cc: Andrew Fish >; Sami Mujawar > Subject: RE: [edk2-devel] [PATCH 01/79] ProcessorPkg/Include: Add header fi= les of RISC-V processor package Abner, I do not know if this patter is being used yet, but there is great value in= it for all platforms that are intended to be synced with edk2. The idea of testing an edk2 change against all available open source platfo= rms that use edk2 would increase confidence in the edk2 change. >>From a CI agent perspective, there are no issues with pulling more repos an= d running tests and providing results that can block an edk2 change if it b= reaks a specific platform. Mike From: Chang, Abner (HPS SW/FW Technologist) > Sent: Friday, February 4, 2022 8:15 AM To: Kinney, Michael D >; Leif Lindholm >; de= vel@edk2.groups.io; Ni, Ray > Cc: Andrew Fish >; Sami Mujawar > Subject: Re: [edk2-devel] [PATCH 01/79] ProcessorPkg/Include: Add header fi= les of RISC-V processor package BTW Mike, Can Core CI on edk2 repo allow the modules referred in the DSC/FDF (e.g., O= vmgRiscV64.dsc) to stay in edk2-platform? Abner ________________________________ From: Kinney, Michael D > Sent: Saturday, January 22, 2022 1:37 AM To: Chang, Abner (HPS SW/FW Technologist) >; Leif Lindholm >; devel@edk2.groups.io >; Ni, Ray >; Kinney, Michael D > Cc: Andrew Fish >; Sami Mujawar > Subject: RE: [edk2-devel] [PATCH 01/79] ProcessorPkg/Include: Add header fi= les of RISC-V processor package I would recommend adding the Platform DSC required to run RISC-V with QEMU = to OvmfPkg so it can be part of CI for edk2 repo so any change to edk2 that= is used by RISC-V can be verified by build and boot to shell. I would like to see the ArmVirtPkg merged into OvmfPkg too so OvmfPkg provi= dse FW build for all support CPU Archs running through QEMU to support edk2= CI that can build and boot to shell in an Azure Pipelines agent. Mike From: Chang, Abner (HPS SW/FW Technologist) > Sent: Friday, January 21, 2022 9:13 AM To: Kinney, Michael D >; Leif Lindholm >; de= vel@edk2.groups.io; Ni, Ray > Cc: Andrew Fish >; Sami Mujawar > Subject: Re: [edk2-devel] [PATCH 01/79] ProcessorPkg/Include: Add header fi= les of RISC-V processor package Ok Mike and Leif, Another question regarding to the location of RISC-V Virtual package for QE= MU. What is the location and package you think RISC-V or other processor ar= chitectures should stay with? Thanks Abner ________________________________ From: Kinney, Michael D > Sent: Saturday, January 15, 2022 12:21 AM To: Chang, Abner (HPS SW/FW Technologist) >; Leif Lindholm >; devel@edk2.groups.io >; Ni, Ray >; Kinney, Michael D > Cc: Andrew Fish >; Sami Mujawar > Subject: RE: [edk2-devel] [PATCH 01/79] ProcessorPkg/Include: Add header fi= les of RISC-V processor package Hi Abner, We already have a package for common platform content in the edk2 repo. This is the MdeModulePkg. However, the number of common platform features added to the MdeModulePkg o= ver time has made this a very large package, and this can be measured by how co= mplex the Maintainer.txt rules are for this package. The revised approach is to create feature packages that platforms can add if their platform requires that specific feature category. Examples are NetworkPkg, SecurityPkg, FmpDevicePkg, FatPkg, RedfishPkg, SourceLevelDebug= Pkg. Instead of adding another generic package such as CommonPlatformPkg, I would prefer to see the libs/modules either added to existing packages that match the feature category, or create new feature packages if there is a new feature category. We also try to limit the edk2 repo to components that are directly related the UEFI/PI specifications and are not Si/Platform specific. Si/Platform specific features go into the edk2-platforms repo. An example of a generic feature in the edk2-platforms repo is Features/Ext4. The UEFI spec only specifies FAT for UEFI boot from file system. There are a number of other feature packages in edk2-platforms in the Features directory, so you should review those as well to see if there is natural landing zone for any of your components. Mike > -----Original Message----- > From: Chang, Abner (HPS SW/FW Technologist) > > Sent: Friday, January 14, 2022 3:15 AM > To: Kinney, Michael D >; Leif Lindholm >; = devel@edk2.groups.io; Ni, Ray > > > Cc: Andrew Fish >; Sami Mujawar <= Sami.Mujawar@arm.com> > Subject: RE: [edk2-devel] [PATCH 01/79] ProcessorPkg/Include: Add header = files of RISC-V processor package > > > > > -----Original Message----- > > From: Kinney, Michael D > > > Sent: Friday, January 14, 2022 12:38 AM > > To: Chang, Abner (HPS SW/FW Technologist) >; Leif > > Lindholm >; devel@edk2.grou= ps.io; Ni, Ray > > >; Kinney, Michael D > > > Cc: Andrew Fish >; Sami Mujawar > > > > > Subject: RE: [edk2-devel] [PATCH 01/79] ProcessorPkg/Include: Add heade= r > > files of RISC-V processor package > > > > Hi Abner, > > > > General recommendations included below. Of course each > > lib/modules/include needs to be reviewed and the > > best location selected. I am aware that there are components in edk2 t= hat > > do not follow these general > > recommendations. This is due to content that was added before these > > recommendations were established > > and we have work to do to get everything aligned. > > > > Mike > > > > > -----Original Message----- > > > From: Chang, Abner (HPS SW/FW Technologist) > > > > Sent: Wednesday, January 12, 2022 9:34 PM > > > To: Kinney, Michael D >; Leif Lindholm > > >; devel@edk2.groups.io; Ni, Ray > > > > > > > Cc: Andrew Fish >; Sami Mujaw= ar > > > > > > Subject: RE: [edk2-devel] [PATCH 01/79] ProcessorPkg/Include: Add > > header files of RISC-V processor package > > > > > > HI Mike, > > > It is no problem to meet there. However, I am not available to join t= he > > design meeting in the next two weeks. Before we can get > > > together to discuss the best locations, do you have information regar= ding > > the rationale of driver/library location? > > > > > > What is the best location for, > > > - Processor ARCH dependent modules > > > > MdePkg for libs > > UefiCpuPkg for modules > > > > > - Common modules for all processor ARCHs > > > > Feature Packages based on the common feature. Add to existing if it fi= ts. > > Create new for completely new feature area. > > > > > - Platform module that is specific to processor ARCH? > > > > edk2-platform repository > How about Leif's suggestion? The CommonPlatformPkg on edk2? > > Abner > > > > > The only exception so far are platform modules used to support > > OvmfPkg/QEMU to support CI. > > In this case the modules are added to OvmfPkg. > > > > > - Platform module that is common to processor ARCHs? > > > > edk2-platform repository > > > > The only exception so far are platform modules used to support > > OvmfPkg/QEMU to support CI. > > In this case the modules are added to OvmfPkg. > > > > > > > > Thanks > > > Abner > > > > > > > -----Original Message----- > > > > From: Kinney, Michael D > > > > > Sent: Monday, January 10, 2022 11:58 PM > > > > To: Leif Lindholm >; de= vel@edk2.groups.io; Chang, > > Abner > > > > (HPS SW/FW Technologist) >; Kinney, Michael D > > > > >; Ni= , Ray > > > > > Cc: Andrew Fish >; Sami Muj= awar > > > > > > > > > Subject: RE: [edk2-devel] [PATCH 01/79] ProcessorPkg/Include: Add > > header > > > > files of RISC-V processor package > > > > > > > > Hi Abner, > > > > > > > > I see comments from Leif as well. > > > > > > > > Do you think a discussion in the design meeting Ray Ni runs would b= e > > > > valuable > > > > to review all the modules/libs/includes and discuss options for the= best > > > > location for them to reside in the edk2 repos? > > > > > > > > Thanks, > > > > > > > > Mike > > > > > > > > > -----Original Message----- > > > > > From: Kinney, Michael D > > > > > > Sent: Monday, January 10, 2022 7:55 AM > > > > > To: Leif Lindholm >; = devel@edk2.groups.io; Chang, > > > > Abner >; Kinney, Mi= chael D > > > > > > > > > > > Cc: Andrew Fish >; Sami M= ujawar > > > > > > > > > > Subject: RE: [edk2-devel] [PATCH 01/79] ProcessorPkg/Include: Add > > > > header files of RISC-V processor package > > > > > > > > > > Hi Abner, > > > > > > > > > > I would also like to see some proposals on adding the RiscV CPU s= coped > > > > content > > > > > to the existing MdePkg/UefiCpuPkg instead of adding a new top lev= el > > CPU > > > > package. > > > > > > > > > > There is already some work started to move some of the ARM specif= ic > > > > content > > > > > from ARM CPU packages into MdePkg. > > > > > > > > > > Thanks, > > > > > > > > > > Mike > > > > > > > > > > > -----Original Message----- > > > > > > From: Leif Lindholm > > > > > > > Sent: Monday, January 10, 2022 5:11 AM > > > > > > To: devel@edk2.groups.io; Chang, A= bner > > > > > > > Cc: Andrew Fish >; Kinn= ey, Michael D > > > > >; Sa= mi Mujawar > > > > > > > > > Subject: Re: [edk2-devel] [PATCH 01/79] ProcessorPkg/Include: A= dd > > > > header files of RISC-V processor package > > > > > > > > > > > > On Sat, Jan 08, 2022 at 12:07:53 +0800, Abner Chang wrote: > > > > > > > (This is migrated from edk2-platforms:Silicon/RISC-V) > > > > > > > > > > > > > > RISC-V processor package library definitions. > > > > > > > > > > > > > > IndustryStandard/RiscV.h > > > > > > > -Add RiscV.h which conform with RISC-V Privilege Spec v1.10. > > > > > > > > > > > > > > RiscVImpl.h > > > > > > > -Definition of EDK2 RISC-V implementation. > > > > > > > > > > > > > > Signed-off-by: Abner Chang > > > > > > > > Co-authored-by: Daniel Schaefer > > > > > > > > Co-authored-by: Gilbert Chen > > > > > > > > Reviewed-by: Leif Lindholm > > > > > > > > > > > > > Hmm, no. > > > > > > I gave a reviewed-by for that patch to be merged into edk2-plat= forms > > > > > > once upon a time. This is not relevant for migration to edk2. > > > > > > > > > > > > My proposal for migrating this code would be as follows: > > > > > > - Announce a hold on merging new code to RiscV portions of > > > > > > edk2-platforms. > > > > > > - Apply any and all bugfixes and CI/uncrustify fixes in place i= n > > > > > > edk2-platforms. > > > > > > - Get some level of agreement for what to do instead of > > > > > > RiscVPlatformPkg - i.e. slot into MdeModulePkg instead. > > > > > > - If that cannot be reached within a few days, create a new > > > > > > top-level directory called "CommonPlatformPkg" or somethin= g, > > > > > > with you, Daniel(/Gilbert?), Sami, me as maintainers. > > > > > > - Move all of the RiscVPlatformPkg code under there instea= d. > > > > > > - I'll follow with ArmPlatformPkg. > > > > > > - PC/AT code should move across too over time. > > > > > > - Move the rest of the code across unmodified as massive single > > > > > > patches per package (potentially more patches than that for > > > > > > RiscVPlatformPkg). > > > > > > - Drop all existing Reviewed-by/Acked-by. > > > > > > - After each "move" patch, insert a "fixup" patch to address = the > > > > > > things that need fixing due to path/name changes. > > > > > > > > > > > > / > > > > > > Leif > > > > > > > > > > > > > Cc: Leif Lindholm > > > > > > > > Cc: Gilbert Chen > > > > > > > > --- > > > > > > > .../Include/IndustryStandard/RiscV.h | 156 > > ++++++++++++++++++ > > > > > > > .../RISC-V/ProcessorPkg/Include/RiscVImpl.h | 87 ++++++++= ++ > > > > > > > 2 files changed, 243 insertions(+) > > > > > > > create mode 100644 Silicon/RISC- > > > > V/ProcessorPkg/Include/IndustryStandard/RiscV.h > > > > > > > create mode 100644 Silicon/RISC- > > V/ProcessorPkg/Include/RiscVImpl.h > > > > > > > > > > > > > > diff --git a/Silicon/RISC- > > > > V/ProcessorPkg/Include/IndustryStandard/RiscV.h b/Silicon/RISC- > > > > > > V/ProcessorPkg/Include/IndustryStandard/RiscV.h > > > > > > > new file mode 100644 > > > > > > > index 0000000000..2a992394ed > > > > > > > --- /dev/null > > > > > > > +++ b/Silicon/RISC- > > V/ProcessorPkg/Include/IndustryStandard/RiscV.h > > > > > > > @@ -0,0 +1,156 @@ > > > > > > > +/** @file > > > > > > > + RISC-V package definitions. > > > > > > > + > > > > > > > + Copyright (c) 2019, Hewlett Packard Enterprise Development= LP. > > All > > > > rights reserved.
> > > > > > > + > > > > > > > + SPDX-License-Identifier: BSD-2-Clause-Patent > > > > > > > + > > > > > > > +**/ > > > > > > > + > > > > > > > +#ifndef RISCV_INDUSTRY_STANDARD_H_ > > > > > > > +#define RISCV_INDUSTRY_STANDARD_H_ > > > > > > > + > > > > > > > +#if defined (MDE_CPU_RISCV64) > > > > > > > +#define RISC_V_XLEN_BITS 64 > > > > > > > +#else > > > > > > > +#endif > > > > > > > + > > > > > > > +#define RISC_V_ISA_ATOMIC_EXTENSION (0x00000= 001 << > > 0) > > > > > > > +#define RISC_V_ISA_BIT_OPERATION_EXTENSION > > (0x00000001 > > > > << 1) > > > > > > > +#define RISC_V_ISA_COMPRESSED_EXTENSION (0x00000= 001 > > << > > > > 2) > > > > > > > +#define RISC_V_ISA_DOUBLE_PRECISION_FP_EXTENSION > > > > (0x00000001 << 3) > > > > > > > +#define RISC_V_ISA_RV32E_ISA (0x00000= 001 << 4) > > > > > > > +#define RISC_V_ISA_SINGLE_PRECISION_FP_EXTENSION > > > > (0x00000001 << 5) > > > > > > > +#define RISC_V_ISA_ADDITIONAL_STANDARD_EXTENSION > > > > (0x00000001 << 6) > > > > > > > +#define RISC_V_ISA_RESERVED_1 (0x00000= 001 << 7) > > > > > > > +#define RISC_V_ISA_INTEGER_ISA_EXTENSION (0x00000= 001 > > << > > > > 8) > > > > > > > +#define > > > > RISC_V_ISA_DYNAMICALLY_TRANSLATED_LANGUAGE_EXTENSION > > > > (0x00000001 << 9) > > > > > > > +#define RISC_V_ISA_RESERVED_2 (0x00000= 001 << 10) > > > > > > > +#define RISC_V_ISA_DECIMAL_FP_EXTENSION (0x00000= 001 > > << > > > > 11) > > > > > > > +#define RISC_V_ISA_INTEGER_MUL_DIV_EXTENSION > > (0x00000001 > > > > << 12) > > > > > > > +#define RISC_V_ISA_USER_LEVEL_INTERRUPT_SUPPORTED > > > > (0x00000001 << 13) > > > > > > > +#define RISC_V_ISA_RESERVED_3 (0x00000= 001 << 14) > > > > > > > +#define RISC_V_ISA_PACKED_SIMD_EXTENSION > > (0x00000001 << > > > > 15) > > > > > > > +#define RISC_V_ISA_QUAD_PRECISION_FP_EXTENSION > > > > (0x00000001 << 16) > > > > > > > +#define RISC_V_ISA_RESERVED_4 (0x00000= 001 << 17) > > > > > > > +#define RISC_V_ISA_SUPERVISOR_MODE_IMPLEMENTED > > > > (0x00000001 << 18) > > > > > > > +#define RISC_V_ISA_TRANSATIONAL_MEMORY_EXTENSION > > > > (0x00000001 << 19) > > > > > > > +#define RISC_V_ISA_USER_MODE_IMPLEMENTED > > (0x00000001 > > > > << 20) > > > > > > > +#define RISC_V_ISA_VECTOR_EXTENSION (0x00000= 001 << > > 21) > > > > > > > +#define RISC_V_ISA_RESERVED_5 (0x00000= 001 << 22) > > > > > > > +#define RISC_V_ISA_NON_STANDARD_EXTENSION > > (0x00000001 > > > > << 23) > > > > > > > +#define RISC_V_ISA_RESERVED_6 (0x00000= 001 << 24) > > > > > > > +#define RISC_V_ISA_RESERVED_7 (0x00000= 001 << 25) > > > > > > > + > > > > > > > +// > > > > > > > +// RISC-V CSR definitions. > > > > > > > +// > > > > > > > +// > > > > > > > +// Machine information > > > > > > > +// > > > > > > > +#define RISCV_CSR_MACHINE_MVENDORID 0xF11 > > > > > > > +#define RISCV_CSR_MACHINE_MARCHID 0xF12 > > > > > > > +#define RISCV_CSR_MACHINE_MIMPID 0xF13 > > > > > > > +#define RISCV_CSR_MACHINE_HARRID 0xF14 > > > > > > > +// > > > > > > > +// Machine Trap Setup. > > > > > > > +// > > > > > > > +#define RISCV_CSR_MACHINE_MSTATUS 0x300 > > > > > > > +#define RISCV_CSR_MACHINE_MISA 0x301 > > > > > > > +#define RISCV_CSR_MACHINE_MEDELEG 0x302 > > > > > > > +#define RISCV_CSR_MACHINE_MIDELEG 0x303 > > > > > > > +#define RISCV_CSR_MACHINE_MIE 0x304 > > > > > > > +#define RISCV_CSR_MACHINE_MTVEC 0x305 > > > > > > > + > > > > > > > +#define RISCV_TIMER_COMPARE_BITS 32 > > > > > > > +// > > > > > > > +// Machine Timer and Counter. > > > > > > > +// > > > > > > > +//#define RISCV_CSR_MACHINE_MTIME 0x701 > > > > > > > +//#define RISCV_CSR_MACHINE_MTIMEH 0x741 > > > > > > > +// > > > > > > > +// Machine Trap Handling. > > > > > > > +// > > > > > > > +#define RISCV_CSR_MACHINE_MSCRATCH 0x340 > > > > > > > +#define RISCV_CSR_MACHINE_MEPC 0x341 > > > > > > > +#define RISCV_CSR_MACHINE_MCAUSE 0x342 > > > > > > > + #define MACHINE_MCAUSE_EXCEPTION_ MASK 0x0f > > > > > > > + #define MACHINE_MCAUSE_INTERRUPT (RISC_V_XLEN_BITS - > > 1) > > > > > > > +#define RISCV_CSR_MACHINE_MBADADDR 0x343 > > > > > > > +#define RISCV_CSR_MACHINE_MIP 0x344 > > > > > > > + > > > > > > > +// > > > > > > > +// Machine Protection and Translation. > > > > > > > +// > > > > > > > +#define RISCV_CSR_MACHINE_MBASE 0x380 > > > > > > > +#define RISCV_CSR_MACHINE_MBOUND 0x381 > > > > > > > +#define RISCV_CSR_MACHINE_MIBASE 0x382 > > > > > > > +#define RISCV_CSR_MACHINE_MIBOUND 0x383 > > > > > > > +#define RISCV_CSR_MACHINE_MDBASE 0x384 > > > > > > > +#define RISCV_CSR_MACHINE_MDBOUND 0x385 > > > > > > > + > > > > > > > +// > > > > > > > +// Supervisor mode CSR. > > > > > > > +// > > > > > > > +#define RISCV_CSR_SUPERVISOR_SSTATUS 0x100 > > > > > > > + #define SSTATUS_SIE_BIT_POSITION 1 > > > > > > > + #define SSTATUS_SPP_BIT_POSITION 8 > > > > > > > +#define RISCV_CSR_SUPERVISOR_SIE 0x104 > > > > > > > +#define RISCV_CSR_SUPERVISOR_SSCRATCH 0x140 > > > > > > > +#define RISCV_CSR_SUPERVISOR_SEPC 0x141 > > > > > > > +#define RISCV_CSR_SUPERVISOR_SCAUSE 0x142 > > > > > > > + #define SCAUSE_USER_SOFTWARE_INT 0 > > > > > > > + #define SCAUSE_SUPERVISOR_SOFTWARE_INT 1 > > > > > > > + #define SCAUSE_USER_TIMER_INT 4 > > > > > > > + #define SCAUSE_SUPERVISOR_TIMER_INT 5 > > > > > > > + #define SCAUSE_USER_EXTERNAL_INT 8 > > > > > > > + #define SCAUSE_SUPERVISOR_EXTERNAL_INT 9 > > > > > > > +#define RISCV_CSR_SUPERVISOR_STVAL 0x143 > > > > > > > +#define RISCV_CSR_SUPERVISOR_SIP 0x144 > > > > > > > +#define RISCV_CSR_SUPERVISOR_SATP 0x180 > > > > > > > + > > > > > > > +#if defined (MDE_CPU_RISCV64) > > > > > > > + #define RISCV_SATP_MODE_MASK 0xF000000000000000 > > > > > > > + #define RISCV_SATP_MODE_BIT_POSITION 60 > > > > > > > +#endif > > > > > > > + #define RISCV_SATP_MODE_OFF 0 > > > > > > > + #define RISCV_SATP_MODE_SV32 1 > > > > > > > + #define RISCV_SATP_MODE_SV39 8 > > > > > > > + #define RISCV_SATP_MODE_SV48 9 > > > > > > > + #define RISCV_SATP_MODE_SV57 10 > > > > > > > + #define RISCV_SATP_MODE_SV64 11 > > > > > > > + > > > > > > > + #define SATP64_ASID_MASK 0x0FFFF00000000000 > > > > > > > + #define SATP64_PPN_MASK 0x00000FFFFFFFFFFF > > > > > > > + > > > > > > > +#define RISCV_CAUSE_MISALIGNED_FETCH 0x0 > > > > > > > +#define RISCV_CAUSE_FETCH_ACCESS 0x1 > > > > > > > +#define RISCV_CAUSE_ILLEGAL_INSTRUCTION 0x2 > > > > > > > +#define RISCV_CAUSE_BREAKPOINT 0x3 > > > > > > > +#define RISCV_CAUSE_MISALIGNED_LOAD 0x4 > > > > > > > +#define RISCV_CAUSE_LOAD_ACCESS 0x5 > > > > > > > +#define RISCV_CAUSE_MISALIGNED_STORE 0x6 > > > > > > > +#define RISCV_CAUSE_STORE_ACCESS 0x7 > > > > > > > +#define RISCV_CAUSE_USER_ECALL 0x8 > > > > > > > +#define RISCV_CAUSE_HYPERVISOR_ECALL 0x9 > > > > > > > +#define RISCV_CAUSE_SUPERVISOR_ECALL 0xa > > > > > > > +#define RISCV_CAUSE_MACHINE_ECALL 0xb > > > > > > > +#define RISCV_CAUSE_FETCH_PAGE_FAULT 0xc > > > > > > > +#define RISCV_CAUSE_LOAD_PAGE_FAULT 0xd > > > > > > > +#define RISCV_CAUSE_STORE_PAGE_FAULT 0xf > > > > > > > +#define RISCV_CAUSE_FETCH_GUEST_PAGE_FAULT 0x14 > > > > > > > +#define RISCV_CAUSE_LOAD_GUEST_PAGE_FAULT 0x15 > > > > > > > +#define RISCV_CAUSE_STORE_GUEST_PAGE_FAULT 0x17 > > > > > > > + > > > > > > > +// > > > > > > > +// Machine Read-Write Shadow of Hypervisor Read-Only Registe= rs > > > > > > > +// > > > > > > > +#define RISCV_CSR_HTIMEW 0xB01 > > > > > > > +#define RISCV_CSR_HTIMEHW 0xB81 > > > > > > > +// > > > > > > > +// Machine Host-Target Interface (Non-Standard Berkeley > > Extension) > > > > > > > +// > > > > > > > +#define RISCV_CSR_MTOHOST 0x780 > > > > > > > +#define RISCV_CSR_MFROMHOST 0x781 > > > > > > > + > > > > > > > +#endif > > > > > > > diff --git a/Silicon/RISC-V/ProcessorPkg/Include/RiscVImpl.h > > > > b/Silicon/RISC-V/ProcessorPkg/Include/RiscVImpl.h > > > > > > > new file mode 100644 > > > > > > > index 0000000000..14092df174 > > > > > > > --- /dev/null > > > > > > > +++ b/Silicon/RISC-V/ProcessorPkg/Include/RiscVImpl.h > > > > > > > @@ -0,0 +1,87 @@ > > > > > > > +/** @file > > > > > > > + RISC-V package definitions. > > > > > > > + > > > > > > > + Copyright (c) 2016 - 2019, Hewlett Packard Enterprise > > Development > > > > LP. All rights reserved.
> > > > > > > + > > > > > > > + SPDX-License-Identifier: BSD-2-Clause-Patent > > > > > > > + > > > > > > > +**/ > > > > > > > + > > > > > > > +#ifndef RISCV_H_ > > > > > > > +#define RISCV_H_ > > > > > > > + > > > > > > > +#include > > > > > > > +#include > > > > > > > + > > > > > > > +#define _ASM_FUNC(Name, Section) \ > > > > > > > + .global Name ; \ > > > > > > > + .section #Section, "ax" ; \ > > > > > > > + .type Name, %function ; \ > > > > > > > + .p2align 2 ; \ > > > > > > > + Name: > > > > > > > + > > > > > > > +#define ASM_FUNC(Name) _ASM_FUNC(ASM_PFX(Name), .text. > > ## > > > > Name) > > > > > > > + > > > > > > > +#if defined (MDE_CPU_RISCV64) > > > > > > > +typedef UINT64 RISC_V_REGS_PROTOTYPE; > > > > > > > +#else > > > > > > > +#endif > > > > > > > + > > > > > > > +// > > > > > > > +// Structure for 128-bit value > > > > > > > +// > > > > > > > +typedef struct { > > > > > > > + UINT64 Value64_L; > > > > > > > + UINT64 Value64_H; > > > > > > > +} RISCV_UINT128; > > > > > > > + > > > > > > > +#define RISCV_MACHINE_CONTEXT_SIZE 0x1000 > > > > > > > +typedef struct _RISCV_MACHINE_MODE_CONTEXT > > > > RISCV_MACHINE_MODE_CONTEXT; > > > > > > > + > > > > > > > +/// > > > > > > > +/// Exception handlers in context. > > > > > > > +/// > > > > > > > +typedef struct _EXCEPTION_HANDLER_CONTEXT { > > > > > > > + EFI_PHYSICAL_ADDRESS InstAddressMisalignedHander; > > > > > > > + EFI_PHYSICAL_ADDRESS InstAccessFaultHander; > > > > > > > + EFI_PHYSICAL_ADDRESS IllegalInstHander; > > > > > > > + EFI_PHYSICAL_ADDRESS BreakpointHander; > > > > > > > + EFI_PHYSICAL_ADDRESS LoadAddrMisalignedHander; > > > > > > > + EFI_PHYSICAL_ADDRESS LoadAccessFaultHander; > > > > > > > + EFI_PHYSICAL_ADDRESS StoreAmoAddrMisalignedHander; > > > > > > > + EFI_PHYSICAL_ADDRESS StoreAmoAccessFaultHander; > > > > > > > + EFI_PHYSICAL_ADDRESS EnvCallFromUModeHander; > > > > > > > + EFI_PHYSICAL_ADDRESS EnvCallFromSModeHander; > > > > > > > + EFI_PHYSICAL_ADDRESS EnvCallFromHModeHander; > > > > > > > + EFI_PHYSICAL_ADDRESS EnvCallFromMModeHander; > > > > > > > +} EXCEPTION_HANDLER_CONTEXT; > > > > > > > + > > > > > > > +/// > > > > > > > +/// Exception handlers in context. > > > > > > > +/// > > > > > > > +typedef struct _INTERRUPT_HANDLER_CONTEXT { > > > > > > > + EFI_PHYSICAL_ADDRESS SoftwareIntHandler; > > > > > > > + EFI_PHYSICAL_ADDRESS TimerIntHandler; > > > > > > > +} INTERRUPT_HANDLER_CONTEXT; > > > > > > > + > > > > > > > +/// > > > > > > > +/// Interrupt handlers in context. > > > > > > > +/// > > > > > > > +typedef struct _TRAP_HANDLER_CONTEXT { > > > > > > > + EXCEPTION_HANDLER_CONTEXT ExceptionHandlerContext; > > > > > > > + INTERRUPT_HANDLER_CONTEXT IntHandlerContext; > > > > > > > +} TRAP_HANDLER_CONTEXT; > > > > > > > + > > > > > > > +/// > > > > > > > +/// Machine mode context used for saveing hart-local context= . > > > > > > > +/// > > > > > > > +typedef struct _RISCV_MACHINE_MODE_CONTEXT { > > > > > > > + EFI_PHYSICAL_ADDRESS PeiService; /// PEI se= rvice. > > > > > > > + EFI_PHYSICAL_ADDRESS MachineModeTrapHandler; /// > > Machine > > > > mode trap handler. > > > > > > > + EFI_PHYSICAL_ADDRESS HypervisorModeTrapHandler; /// > > Hypervisor > > > > mode trap handler. > > > > > > > + EFI_PHYSICAL_ADDRESS SupervisorModeTrapHandler; /// > > Supervisor > > > > mode trap handler. > > > > > > > + EFI_PHYSICAL_ADDRESS UserModeTrapHandler; /// USer > > mode > > > > trap handler. > > > > > > > + TRAP_HANDLER_CONTEXT MModeHandler; /// Handle= r for > > > > machine mode. > > > > > > > +} RISCV_MACHINE_MODE_CONTEXT; > > > > > > > + > > > > > > > +#endif > > > > > > > -- > > > > > > > 2.31.1 > > > > > > > > > > > > > > > > > > > > > > > > > > > >=20 > > > > > > > > > > > > > > > --_000_PH7PR84MB188578F5E35ED88047E79A8AFF029PH7PR84MB1885NAMP_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi Ray,
RISC-V doesn't have the similar functions as those are provided in BaseUefi= CpuLib.c. In this case, what we can do is just leverage the library class b= ut different implementation for archs?
At least we don't need another library class for RISC-V. We can have the co= mmon source file if all archs provided the same functionality later.

Regards,
Abner
From: Ni, Ray <ray.ni@in= tel.com>
Sent: Tuesday, March 1, 2022 3:07 PM
To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@hpe.com>= ;; Kinney, Michael D <michael.d.kinney@intel.com>; Leif Lindholm <= leif@nuviainc.com>; devel@edk2.groups.io <devel@edk2.groups.io>; L= iChao <lichao@loongson.cn>
Cc: Andrew Fish <afish@apple.com>; Sami Mujawar <Sami.Mujaw= ar@arm.com>; LiChao <lichao@loongson.cn>; Schaefer, Daniel (ROM Ja= nitor) <daniel.schaefer@hpe.com>; Sunil V L <sunilvl@ventanamicro.= com>
Subject: RE: RFC: UefiCpuPkg for all processor archs
 

Abner,

UefiCpuPkg\SecCore\SecCoreNative.inf is a module t= hat might not depend on X86. It assumes the UefiCpuPkg/ResetVector inits th= e CPU well.

 

UefiCpuPKg/Bas= eUefiCpuLib

1. Rename Base= UefiCpuLib.c to BaseUefiCpuLibIa32X64.c

   B= aseUefiCpuLibRiscV64.c for RISC-V arch and assembly code under /RISCV64

2. Or move all= X86 source files to under BaseUefiCpuLib/X86, BaseUefiCpuLib/RISC-V for RI= SC-V arch (I prefer this way, the directory looks clean)

 

That depends on whether the RISC-V or LoongArch ca= n implement the same API as that in X86 version. Maybe some of the APIs are= too X86 specific that makes it hard for implementing for other ARCHs. That= might lead to a more abstraction. Without the concrete implementation available, I have no idea what abstrac= tion is.

 

Thanks,

Ray

 

From: Chang, Abner (HPS SW/FW Technologist)= <abner.chang@hpe.com>
Sent: Tuesday, March 1, 2022 9:26 AM
To: Kinney, Michael D <michael.d.kinney@intel.com>; Leif Lindh= olm <leif@nuviainc.com>; devel@edk2.groups.io; Ni, Ray <ray.ni@int= el.com>; LiChao <lichao@loongson.cn>
Cc: Andrew Fish <afish@apple.com>; Sami Mujawar <Sami.Mujaw= ar@arm.com>; LiChao <lichao@loongson.cn>; Schaefer, Daniel <dan= iel.schaefer@hpe.com>; Sunil V L <sunilvl@ventanamicro.com>
Subject: RFC: UefiCpuPkg for all processor archs

 

Hi Mike and Ray,

I just got a chance to back on this topic and below = are few questions regarding the UefiCpuPkg for all processor archs.

I change the subject and loop Chao Li from Loongsoon= who is contributing Loongarch64 to Uefi/edk2. He may have to handle the si= milar things for Loongarch64.

 

I went through RISC-V modules that currently located= on edk2-platforms repo (Platform/RISC-V/PlatformPKg and Silicon/RISC-V/Pro= cessorPkg) and figure out the modules we would move to under UefiCpuPkg and MdeModulePkg.  We could go thro= ugh the proposal in the design meeting later, however I would like to confi= rm the proposal of revising modules under /UEfiCpuPkg those were implemente= d in X86 oriented before we get to that point.

 

  • UefiCpuPKg\SecCore
  • The implementation of this module is very x86 oriented. There is likely = nothing to leverage between archs. My thought was 
  • 1. Having RISC-V SecCore in its own folder, e.g. UefiCpuPkg= /RISC-V/SecCore and create the individual INF for archs.
  • However, 
    2. We can also consider having the separate section in SecCore/SecCore.inf.= Move all X86 source files to under UefiCpuPkg/SecCore/X86 and have /RISC-V folder under UefiCpuPkg/SecCore  for RISC-V arch. (I prefer this way)
  •  
  • UefiCpuPKg/BaseUefiCpuLib
  • 1. Rename BaseUefiCpuLib.c to BaseUefiCpu= LibIa32X64.c
  •    BaseUefiCpuLib= RiscV64.c for RISC-V arch and assembly code under /RISCV64
  • 2. Or move all X86 source files to under BaseUefiCpuLib/= X86, BaseUefiCpuLib/RISC-V for RISC-V arch (I prefer this way, the directory looks clean)
  •  
    • <= li class=3D"x_MsoNormal" style=3D"color:black; background:white">UefiCpuPKg/CpuExceptionHandlerLib

Too many X86 source files, move al= l X86 source files to under CpuExecptionHander/X86, CpuExecptionHander= /RISC-V for RISC-V arch

  • Having abstract level under /CpuExecptionHander, e.g. INF, PeiException.c, DxeException.c and= etc.
  •  
  • UefiCpuPKg\Library\CpuTimerLib
  • 1. Rename BaseCpuTimerLib.c to BaseCpuTimerLibIa32X64.c,&nbs= p;BaseCpuTimerLibRiscV64.c for RISC-V arch.
  • 2. Or move all X86 source files to under BaseUefiCpuLib/X86, BaseUefiCp= uLib/RISC-V for RISC-V arch (I prefer= this way)
  •  
  • UefiCpuPKg/CpuDxe
  • = Revise CpuDxe.c and CpuDxe.h to be abstract for the processor archs.=
  • Move all x86 implementations to under /X86,&nb= sp;CpuDxe/RISC-V for RISC-V CpuDxe implementation

Let me know your thoughts, I can initiate the PoC co= de after we get on the same page.

Thanks

Abner

 

From: Chang, Abner (HPS SW/FW Technologist)
Sent: Saturday, February 5, 2022 10:56 PM
To: Kinney, Michael D <michael.d.kinney@intel.com>; Leif Lindholm <leif@nuviainc.com>; devel@edk2.groups.io <devel@edk2.groups.io>; Ni, Ray <= ;ray.ni@intel.com>
Cc: Andrew Fish <afish@apple.c= om>; Sami Mujawar <Sami.M= ujawar@arm.com>
Subject: RE: [edk2-devel] [PATCH 01/79] ProcessorPkg/Include: Add he= ader files of RISC-V processor package

 

Thanks Mike.

The reason I asked this question is we are workin= g on the OvmfRiscV64 as you suggested. However as you know that both RISC-V= processor and platform packages are currently stay in edk2-platforms. &nbs= p;We have to make sure  CI won=92t throw errors if we use the edk2 modules in edk2-platforms. We are in rush to hav= e RISC-V edk2 OVMF for RISC-V community. We will start to move RISC-V edk2 = port to UefiCpuPkg or MdePkg once RISC-V OVMF port is upstream.

 

Abner

 

From: Kinney, Michael D <michael.d.kinney@intel.com>
Sent: Saturday, February 5, 2022 4:22 AM
To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@hpe.com>; Leif Lindholm <leif@nuviainc.com>; devel@edk2.groups.io; Ni, Ray &= lt;ray.ni@intel.com>
Cc: Andrew Fish <afish@apple.c= om>; Sami Mujawar <Sami.M= ujawar@arm.com>
Subject: RE: [edk2-devel] [PATCH 01/79] ProcessorPkg/Include: Add he= ader files of RISC-V processor package

 

Abner,

 

I do not know if this patter is being used yet, b= ut there is great value in it for all platforms that are intended to be syn= ced with edk2.

 

The idea of testing an edk2 change against all av= ailable open source platforms that use edk2 would increase confidence in th= e edk2 change.

 

From a CI agent perspective, there are no issues = with pulling more repos and running tests and providing results that can bl= ock an edk2 change if it breaks a specific platform.

 

Mike

 

From: Chang, Abner (HPS SW/FW Technologist= ) <abner.chang@hpe.com>
Sent: Friday, February 4, 2022 8:15 AM
To: Kinney, Michael D <michael.d.kinney@intel.com>; Leif Lindholm <leif@nuviainc.com>; devel@edk2.groups.io; Ni, Ray &= lt;ray.ni@intel.com>
Cc: Andrew Fish <afish@apple.c= om>; Sami Mujawar <Sami.M= ujawar@arm.com>
Subject: Re: [edk2-devel] [PATCH 01/79] ProcessorPkg/Include: Add he= ader files of RISC-V processor package

 

BTW Mike,

Can Core CI on edk2 repo allow the modules referred= in the DSC/FDF (e.g., OvmgRiscV64.dsc) to stay in edk2-platform?

 

Abner

&nb= sp;

From: Kinney, Michael D <michael.d.kinney@intel.com>
Sent: Saturday, January 22, 2022 1:37 AM
To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@hpe.com>; Leif Lindholm <leif@nuviainc.com>; devel@edk2.groups.io <devel@edk2.groups.io>; Ni, Ray <= ;ray.ni@intel.com>; Kinney, Mich= ael D <michael.d.kinney@in= tel.com>
Cc: Andrew Fish <afish@apple.c= om>; Sami Mujawar <Sami.M= ujawar@arm.com>
Subject: RE: [edk2-devel] [PATCH 01/79] ProcessorPkg/Include: Add he= ader files of RISC-V processor package

 

I would recommend adding the Platform DSC requir= ed to run RISC-V with QEMU to OvmfPkg so it can be part of CI for edk2 = repo so any change to edk2 that is used by RISC-V can be verified by build = and boot to shell.

 

I would like to see the ArmVirtPkg merged into OvmfPkg too so OvmfPkg providse FW build for all support CPU Archs running through QEMU to support edk2 CI that can build and boo= t to shell in an Azure Pipelines agent.

 

Mike

 

From: Chang, Abner (HPS SW/FW Technologis= t) <abner.chang@hpe.com>
Sent: Friday, January 21, 2022 9:13 AM
To: Kinney, Michael D <michael.d.kinney@intel.com>; Leif Lindholm <leif@nuviainc.com>; devel@edk2.groups.io; Ni, Ray &= lt;ray.ni@intel.com>
Cc: Andrew Fish <afish@apple.c= om>; Sami Mujawar <Sami.M= ujawar@arm.com>
Subject: Re: [edk2-devel] [PATCH 01/79] ProcessorPkg/Include: Add he= ader files of RISC-V processor package

 

Ok Mike and Leif,

Another question regarding to the location of RISC= -V Virtual package for QEMU. What is the location and package you thin= k RISC-V or other processor architectures should stay with?

 

Thanks

Abner

From:<= span style=3D"color:black"> Kinney, Michael D <michael.d.kinney@intel.com>
Sent: Saturday, January 15, 2022 12:21 AM
To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@hpe.com>; Leif Lindholm <leif@nuviainc.com>; devel@edk2.groups.io <devel@edk2.groups.io>; Ni, Ray <= ;ray.ni@intel.com>; Kinney, Mich= ael D <michael.d.kinney@in= tel.com>
Cc: Andrew Fish <afish@apple.c= om>; Sami Mujawar <Sami.M= ujawar@arm.com>
Subject: RE: [edk2-devel] [PATCH 01/79] ProcessorPkg/Include: Add he= ader files of RISC-V processor package

 

Hi Abner,

We already have a package for common platform content in the edk2 repo.
This is the MdeModulePkg.

However, the number of common platform features added to the MdeModulePkg o= ver
time has made this a very large package, and this can be measured by how co= mplex the
Maintainer.txt rules are for this package.

The revised approach is to create feature packages that platforms can add if their platform requires that specific feature category.  Examples a= re
NetworkPkg, SecurityPkg, FmpDevicePkg, FatPkg, RedfishPkg, SourceLevelDebug= Pkg.

Instead of adding another generic package such as CommonPlatformPkg, I
would prefer to see the libs/modules either added to existing packages
that match the feature category, or create new feature packages if
there is a new feature category.

We also try to limit the edk2 repo to components that are directly related<= br> the UEFI/PI specifications and are not Si/Platform specific.  Si/Platf= orm
specific features go into the edk2-platforms repo.  An example of a ge= neric
feature in the edk2-platforms repo is Features/Ext4.  The UEFI spec on= ly
specifies FAT for UEFI boot from file system.

There are a number of other feature packages in edk2-platforms in the
Features directory, so you should review those as well to see if there
is natural landing zone for any of your components.

Mike


> -----Original Message-----
> From: Chang, Abner (HPS SW/FW Technologist) <abner.chang@hpe.com>
> Sent: Friday, January 14, 2022 3:15 AM
> To: Kinney, Michael D <michael.d.kinney@intel.com>; Leif Lindholm <leif@nuviainc.com>; devel@edk2.groups.io; Ni, Ray > <ray.ni@intel.com>
> Cc: Andrew Fish <afish@apple.com= >; Sami Mujawar <Sami.Muj= awar@arm.com>
> Subject: RE: [edk2-devel] [PATCH 01/79] ProcessorPkg/Include: Add head= er files of RISC-V processor package
>
>
>
> > -----Original Message-----
> > From: Kinney, Michael D <michael.d.kinney@intel.com>
> > Sent: Friday, January 14, 2022 12:38 AM
> > To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@hpe.com>; Leif
> > Lindholm <leif@nuviainc.c= om>; devel@edk2.groups.io; Ni, Ray
> > <ray.ni@intel.com>;= Kinney, Michael D <michae= l.d.kinney@intel.com>
> > Cc: Andrew Fish <afish@appl= e.com>; Sami Mujawar
> > <Sami.Mujawar@arm.com<= /a>>
> > Subject: RE: [edk2-devel] [PATCH 01/79] ProcessorPkg/Include: Add= header
> > files of RISC-V processor package
> >
> > Hi Abner,
> >
> > General recommendations included below.  Of course each
> > lib/modules/include needs to be reviewed and the
> > best location selected.  I am aware that there are component= s in edk2 that
> > do not follow these general
> > recommendations.  This is due to content that was added befo= re these
> > recommendations were established
> > and we have work to do to get everything aligned.
> >
> > Mike
> >
> > > -----Original Message-----
> > > From: Chang, Abner (HPS SW/FW Technologist) <abner.chang@hpe.com>
> > > Sent: Wednesday, January 12, 2022 9:34 PM
> > > To: Kinney, Michael D <michael.d.kinney@intel.com>; Leif Lindholm
> > <leif@nuviainc.com>= ;; devel@edk2.groups.io; Ni, Ra= y
> > > <ray.ni@intel.com= >
> > > Cc: Andrew Fish <afish= @apple.com>; Sami Mujawar
> > <Sami.Mujawar@arm.com<= /a>>
> > > Subject: RE: [edk2-devel] [PATCH 01/79] ProcessorPkg/Include= : Add
> > header files of RISC-V processor package
> > >
> > > HI Mike,
> > > It is no problem to meet there. However, I am not available = to join the
> > design meeting in the next two weeks. Before we can get
> > > together to discuss the best locations, do you have informat= ion regarding
> > the rationale of driver/library location?
> > >
> > > What is the best location for,
> > > - Processor ARCH dependent modules
> >
> > MdePkg for libs
> > UefiCpuPkg for modules
> >
> > > - Common modules for all processor ARCHs
> >
> > Feature Packages based on the common feature.  Add to existi= ng if it fits.
> > Create new for completely new feature area.
> >
> > > - Platform module that is specific to processor ARCH?
> >
> > edk2-platform repository
> How about Leif's suggestion? The CommonPlatformPkg on edk2?
>
> Abner
>
> >
> > The only exception so far are platform modules used to support > > OvmfPkg/QEMU to support CI.
> > In this case the modules are added to OvmfPkg.
> >
> > > - Platform module that is common to processor ARCHs?
> >
> > edk2-platform repository
> >
> > The only exception so far are platform modules used to support > > OvmfPkg/QEMU to support CI.
> > In this case the modules are added to OvmfPkg.
> >
> > >
> > > Thanks
> > > Abner
> > >
> > > > -----Original Message-----
> > > > From: Kinney, Michael D <michael.d.kinney@intel.com>
> > > > Sent: Monday, January 10, 2022 11:58 PM
> > > > To: Leif Lindholm <leif@nuviainc.com>; devel@edk2.groups.io; Chang, > > Abner
> > > > (HPS SW/FW Technologist) <abner.chang@hpe.com>; Kinney, Michael D
> > > > <micha= el.d.kinney@intel.com>; Ni, Ray <ray.ni@intel.com>
> > > > Cc: Andrew Fish <= afish@apple.com>; Sami Mujawar
> > > > <Sami.Mujawa= r@arm.com>
> > > > Subject: RE: [edk2-devel] [PATCH 01/79] ProcessorPkg/In= clude: Add
> > header
> > > > files of RISC-V processor package
> > > >
> > > > Hi Abner,
> > > >
> > > > I see comments from Leif as well.
> > > >
> > > > Do you think a discussion in the design meeting Ray Ni = runs would be
> > > > valuable
> > > > to review all the modules/libs/includes and discuss opt= ions for the best
> > > > location for them to reside in the edk2 repos?
> > > >
> > > > Thanks,
> > > >
> > > > Mike
> > > >
> > > > > -----Original Message-----
> > > > > From: Kinney, Michael D <michael.d.kinney@intel.com>
> > > > > Sent: Monday, January 10, 2022 7:55 AM
> > > > > To: Leif Lindholm <leif@nuviainc.com>; devel@edk2.groups.io; Chang, > > > > Abner <abner.= chang@hpe.com>; Kinney, Michael D
> > > > > <= michael.d.kinney@intel.com>
> > > > > Cc: Andrew Fish <afish@apple.com>; Sami Mujawar
> > > > <Sami.Mujawa= r@arm.com>
> > > > > Subject: RE: [edk2-devel] [PATCH 01/79] ProcessorP= kg/Include: Add
> > > > header files of RISC-V processor package
> > > > >
> > > > > Hi Abner,
> > > > >
> > > > > I would also like to see some proposals on adding = the RiscV CPU scoped
> > > > content
> > > > > to the existing MdePkg/UefiCpuPkg instead of addin= g a new top level
> > CPU
> > > > package.
> > > > >
> > > > > There is already some work started to move some of= the ARM specific
> > > > content
> > > > > from ARM CPU packages into MdePkg.
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Mike
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Leif Lindholm <leif@nuviainc.com>
> > > > > > Sent: Monday, January 10, 2022 5:11 AM
> > > > > > To: d= evel@edk2.groups.io; Chang, Abner <abner.chang@hpe.com>
> > > > > > Cc: Andrew Fish <afish@apple.com>; Kinney, Michael D
> > > > <micha= el.d.kinney@intel.com>; Sami Mujawar
> > <Sami.Mujawar@arm.com<= /a>>
> > > > > > Subject: Re: [edk2-devel] [PATCH 01/79] Proce= ssorPkg/Include: Add
> > > > header files of RISC-V processor package
> > > > > >
> > > > > > On Sat, Jan 08, 2022 at 12:07:53 +0800, Abner= Chang wrote:
> > > > > > > (This is migrated from edk2-platforms:Si= licon/RISC-V)
> > > > > > >
> > > > > > > RISC-V processor package library definit= ions.
> > > > > > >
> > > > > > > IndustryStandard/RiscV.h
> > > > > > > -Add RiscV.h which conform with RISC-V P= rivilege Spec v1.10.
> > > > > > >
> > > > > > > RiscVImpl.h
> > > > > > > -Definition of EDK2 RISC-V implementatio= n.
> > > > > > >
> > > > > > > Signed-off-by: Abner Chang <abner.chang@hpe.com>
> > > > > > > Co-authored-by: Daniel Schaefer <daniel.schaefer@hpe.com>
> > > > > > > Co-authored-by: Gilbert Chen <gilbert.chen@hpe.com>
> > > > > > > Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
> > > > > >
> > > > > > Hmm, no.
> > > > > > I gave a reviewed-by for that patch to be mer= ged into edk2-platforms
> > > > > > once upon a time. This is not relevant for mi= gration to edk2.
> > > > > >
> > > > > > My proposal for migrating this code would be = as follows:
> > > > > > - Announce a hold on merging new code to Risc= V portions of
> > > > > >   edk2-platforms.
> > > > > > - Apply any and all bugfixes and CI/uncrustif= y fixes in place in
> > > > > >   edk2-platforms.
> > > > > > - Get some level of agreement for what to do = instead of
> > > > > >   RiscVPlatformPkg - i.e. slot into= MdeModulePkg instead.
> > > > > >   -  If that cannot be reached= within a few days, create a new
> > > > > >      top-level direc= tory called "CommonPlatformPkg" or something,
> > > > > >      with you, Danie= l(/Gilbert?), Sami, me as maintainers.
> > > > > >      - Move all of t= he RiscVPlatformPkg code under there instead.
> > > > > >      - I'll follow w= ith ArmPlatformPkg.
> > > > > >      - PC/AT code sh= ould move across too over time.
> > > > > > - Move the rest of the code across unmodified= as massive single
> > > > > >   patches per package (potentially = more patches than that for
> > > > > >   RiscVPlatformPkg).
> > > > > >   - Drop all existing Reviewed-by/A= cked-by.
> > > > > >   - After each "move" pat= ch, insert a "fixup" patch to address the
> > > > > >     things that need fixi= ng due to path/name changes.
> > > > > >
> > > > > > /
> > > > > >     Leif
> > > > > >
> > > > > > > Cc: Leif Lindholm <leif.lindholm@linaro.org>
> > > > > > > Cc: Gilbert Chen <gilbert.chen@hpe.com>
> > > > > > > ---
> > > > > > >  .../Include/IndustryStandard/RiscV= .h          | 156
> > ++++++++++++++++++
> > > > > > >  .../RISC-V/ProcessorPkg/Include/Ri= scVImpl.h   |  87 ++++++++++
> > > > > > >  2 files changed, 243 insertions(+)=
> > > > > > >  create mode 100644 Silicon/RISC- > > > > V/ProcessorPkg/Include/IndustryStandard/RiscV.h
> > > > > > >  create mode 100644 Silicon/RISC- > > V/ProcessorPkg/Include/RiscVImpl.h
> > > > > > >
> > > > > > > diff --git a/Silicon/RISC-
> > > > V/ProcessorPkg/Include/IndustryStandard/RiscV.h b/Silic= on/RISC-
> > > > > > V/ProcessorPkg/Include/IndustryStandard/RiscV= .h
> > > > > > > new file mode 100644
> > > > > > > index 0000000000..2a992394ed
> > > > > > > --- /dev/null
> > > > > > > +++ b/Silicon/RISC-
> > V/ProcessorPkg/Include/IndustryStandard/RiscV.h
> > > > > > > @@ -0,0 +1,156 @@
> > > > > > > +/** @file
> > > > > > > +  RISC-V package definitions.
> > > > > > > +
> > > > > > > +  Copyright (c) 2019, Hewlett Pack= ard Enterprise Development LP.
> > All
> > > > rights reserved.<BR>
> > > > > > > +
> > > > > > > +  SPDX-License-Identifier: BSD-2-C= lause-Patent
> > > > > > > +
> > > > > > > +**/
> > > > > > > +
> > > > > > > +#ifndef RISCV_INDUSTRY_STANDARD_H_
> > > > > > > +#define RISCV_INDUSTRY_STANDARD_H_
> > > > > > > +
> > > > > > > +#if defined (MDE_CPU_RISCV64)
> > > > > > > +#define RISC_V_XLEN_BITS 64
> > > > > > > +#else
> > > > > > > +#endif
> > > > > > > +
> > > > > > > +#define RISC_V_ISA_ATOMIC_EXTENSION&nbs= p;            &= nbsp;   (0x00000001 <<
> > 0)
> > > > > > > +#define RISC_V_ISA_BIT_OPERATION_EXTENS= ION
> > (0x00000001
> > > > << 1)
> > > > > > > +#define RISC_V_ISA_COMPRESSED_EXTENSION=              (0= x00000001
> > <<
> > > > 2)
> > > > > > > +#define RISC_V_ISA_DOUBLE_PRECISION_FP_= EXTENSION
> > > > (0x00000001 << 3)
> > > > > > > +#define RISC_V_ISA_RV32E_ISA  = ;            &n= bsp;         (0x00000001 << 4= )
> > > > > > > +#define RISC_V_ISA_SINGLE_PRECISION_FP_= EXTENSION
> > > > (0x00000001 << 5)
> > > > > > > +#define RISC_V_ISA_ADDITIONAL_STANDARD_= EXTENSION
> > > > (0x00000001 << 6)
> > > > > > > +#define RISC_V_ISA_RESERVED_1 &nbs= p;            &= nbsp;        (0x00000001 << 7)
> > > > > > > +#define RISC_V_ISA_INTEGER_ISA_EXTENSIO= N            (0x0000= 0001
> > <<
> > > > 8)
> > > > > > > +#define
> > > > RISC_V_ISA_DYNAMICALLY_TRANSLATED_LANGUAGE_EXTENSION > > > > (0x00000001 << 9)
> > > > > > > +#define RISC_V_ISA_RESERVED_2 &nbs= p;            &= nbsp;        (0x00000001 << 10) > > > > > > > +#define RISC_V_ISA_DECIMAL_FP_EXTENSION=              (0= x00000001
> > <<
> > > > 11)
> > > > > > > +#define RISC_V_ISA_INTEGER_MUL_DIV_EXTE= NSION
> > (0x00000001
> > > > << 12)
> > > > > > > +#define RISC_V_ISA_USER_LEVEL_INTERRUPT= _SUPPORTED
> > > > (0x00000001 << 13)
> > > > > > > +#define RISC_V_ISA_RESERVED_3 &nbs= p;            &= nbsp;        (0x00000001 << 14) > > > > > > > +#define RISC_V_ISA_PACKED_SIMD_EXTENSIO= N
> > (0x00000001 <<
> > > > 15)
> > > > > > > +#define RISC_V_ISA_QUAD_PRECISION_FP_EX= TENSION
> > > > (0x00000001 << 16)
> > > > > > > +#define RISC_V_ISA_RESERVED_4 &nbs= p;            &= nbsp;        (0x00000001 << 17) > > > > > > > +#define RISC_V_ISA_SUPERVISOR_MODE_IMPL= EMENTED
> > > > (0x00000001 << 18)
> > > > > > > +#define RISC_V_ISA_TRANSATIONAL_MEMORY_= EXTENSION
> > > > (0x00000001 << 19)
> > > > > > > +#define RISC_V_ISA_USER_MODE_IMPLEMENTE= D
> > (0x00000001
> > > > << 20)
> > > > > > > +#define RISC_V_ISA_VECTOR_EXTENSION&nbs= p;            &= nbsp;   (0x00000001 <<
> > 21)
> > > > > > > +#define RISC_V_ISA_RESERVED_5 &nbs= p;            &= nbsp;        (0x00000001 << 22) > > > > > > > +#define RISC_V_ISA_NON_STANDARD_EXTENSI= ON
> > (0x00000001
> > > > << 23)
> > > > > > > +#define RISC_V_ISA_RESERVED_6 &nbs= p;            &= nbsp;        (0x00000001 << 24) > > > > > > > +#define RISC_V_ISA_RESERVED_7 &nbs= p;            &= nbsp;        (0x00000001 << 25) > > > > > > > +
> > > > > > > +//
> > > > > > > +// RISC-V CSR definitions.
> > > > > > > +//
> > > > > > > +//
> > > > > > > +// Machine information
> > > > > > > +//
> > > > > > > +#define RISCV_CSR_MACHINE_MVENDORID&nbs= p;    0xF11
> > > > > > > +#define RISCV_CSR_MACHINE_MARCHID =       0xF12
> > > > > > > +#define RISCV_CSR_MACHINE_MIMPID &= nbsp;      0xF13
> > > > > > > +#define RISCV_CSR_MACHINE_HARRID &= nbsp;      0xF14
> > > > > > > +//
> > > > > > > +// Machine Trap Setup.
> > > > > > > +//
> > > > > > > +#define RISCV_CSR_MACHINE_MSTATUS =       0x300
> > > > > > > +#define RISCV_CSR_MACHINE_MISA &nb= sp;        0x301
> > > > > > > +#define RISCV_CSR_MACHINE_MEDELEG =       0x302
> > > > > > > +#define RISCV_CSR_MACHINE_MIDELEG =       0x303
> > > > > > > +#define RISCV_CSR_MACHINE_MIE &nbs= p;         0x304
> > > > > > > +#define RISCV_CSR_MACHINE_MTVEC &n= bsp;       0x305
> > > > > > > +
> > > > > > > +#define RISCV_TIMER_COMPARE_BITS &= nbsp;    32
> > > > > > > +//
> > > > > > > +// Machine Timer and Counter.
> > > > > > > +//
> > > > > > > +//#define RISCV_CSR_MACHINE_MTIME =         0x701
> > > > > > > +//#define RISCV_CSR_MACHINE_MTIMEH = ;       0x741
> > > > > > > +//
> > > > > > > +// Machine Trap Handling.
> > > > > > > +//
> > > > > > > +#define RISCV_CSR_MACHINE_MSCRATCH = ;     0x340
> > > > > > > +#define RISCV_CSR_MACHINE_MEPC &nb= sp;        0x341
> > > > > > > +#define RISCV_CSR_MACHINE_MCAUSE &= nbsp;      0x342
> > > > > > > +  #define MACHINE_MCAUSE_EXCEPTION= _ MASK 0x0f
> > > > > > > +  #define MACHINE_MCAUSE_INTERRUPT=       (RISC_V_XLEN_BITS -
> > 1)
> > > > > > > +#define RISCV_CSR_MACHINE_MBADADDR = ;     0x343
> > > > > > > +#define RISCV_CSR_MACHINE_MIP &nbs= p;         0x344
> > > > > > > +
> > > > > > > +//
> > > > > > > +// Machine Protection and Translation.<= br> > > > > > > > +//
> > > > > > > +#define RISCV_CSR_MACHINE_MBASE &n= bsp;       0x380
> > > > > > > +#define RISCV_CSR_MACHINE_MBOUND &= nbsp;      0x381
> > > > > > > +#define RISCV_CSR_MACHINE_MIBASE &= nbsp;      0x382
> > > > > > > +#define RISCV_CSR_MACHINE_MIBOUND =       0x383
> > > > > > > +#define RISCV_CSR_MACHINE_MDBASE &= nbsp;      0x384
> > > > > > > +#define RISCV_CSR_MACHINE_MDBOUND =       0x385
> > > > > > > +
> > > > > > > +//
> > > > > > > +// Supervisor mode CSR.
> > > > > > > +//
> > > > > > > +#define RISCV_CSR_SUPERVISOR_SSTATUS&nb= sp;   0x100
> > > > > > > +  #define SSTATUS_SIE_BIT_POSITION=       1
> > > > > > > +  #define SSTATUS_SPP_BIT_POSITION=       8
> > > > > > > +#define RISCV_CSR_SUPERVISOR_SIE &= nbsp;      0x104
> > > > > > > +#define RISCV_CSR_SUPERVISOR_SSCRATCH&n= bsp;  0x140
> > > > > > > +#define RISCV_CSR_SUPERVISOR_SEPC =       0x141
> > > > > > > +#define RISCV_CSR_SUPERVISOR_SCAUSE&nbs= p;    0x142
> > > > > > > +  #define SCAUSE_USER_SOFTWARE_INT=         0
> > > > > > > +  #define SCAUSE_SUPERVISOR_SOFTWA= RE_INT  1
> > > > > > > +  #define SCAUSE_USER_TIMER_INT&nb= sp;          4
> > > > > > > +  #define SCAUSE_SUPERVISOR_TIMER_= INT     5
> > > > > > > +  #define SCAUSE_USER_EXTERNAL_INT=         8
> > > > > > > +  #define SCAUSE_SUPERVISOR_EXTERN= AL_INT  9
> > > > > > > +#define RISCV_CSR_SUPERVISOR_STVAL = ;     0x143
> > > > > > > +#define RISCV_CSR_SUPERVISOR_SIP &= nbsp;      0x144
> > > > > > > +#define RISCV_CSR_SUPERVISOR_SATP =       0x180
> > > > > > > +
> > > > > > > +#if defined (MDE_CPU_RISCV64)
> > > > > > > +  #define RISCV_SATP_MODE_MASK&nbs= p;         0xF000000000000000
> > > > > > > +  #define RISCV_SATP_MODE_BIT_POSI= TION  60
> > > > > > > +#endif
> > > > > > > +    #define RISCV_SATP_M= ODE_OFF         0
> > > > > > > +    #define RISCV_SATP_M= ODE_SV32        1
> > > > > > > +    #define RISCV_SATP_M= ODE_SV39        8
> > > > > > > +    #define RISCV_SATP_M= ODE_SV48        9
> > > > > > > +    #define RISCV_SATP_M= ODE_SV57        10
> > > > > > > +    #define RISCV_SATP_M= ODE_SV64        11
> > > > > > > +
> > > > > > > +  #define SATP64_ASID_MASK &n= bsp;            0x0F= FFF00000000000
> > > > > > > +  #define SATP64_PPN_MASK &nb= sp;            = 0x00000FFFFFFFFFFF
> > > > > > > +
> > > > > > > +#define RISCV_CAUSE_MISALIGNED_FETCH&nb= sp;       0x0
> > > > > > > +#define RISCV_CAUSE_FETCH_ACCESS &= nbsp;          0x1
> > > > > > > +#define RISCV_CAUSE_ILLEGAL_INSTRUCTION=      0x2
> > > > > > > +#define RISCV_CAUSE_BREAKPOINT &nb= sp;            0x3 > > > > > > > +#define RISCV_CAUSE_MISALIGNED_LOAD&nbs= p;        0x4
> > > > > > > +#define RISCV_CAUSE_LOAD_ACCESS &n= bsp;           0x5
> > > > > > > +#define RISCV_CAUSE_MISALIGNED_STORE&nb= sp;       0x6
> > > > > > > +#define RISCV_CAUSE_STORE_ACCESS &= nbsp;          0x7
> > > > > > > +#define RISCV_CAUSE_USER_ECALL &nb= sp;            0x8 > > > > > > > +#define RISCV_CAUSE_HYPERVISOR_ECALL&nb= sp;       0x9
> > > > > > > +#define RISCV_CAUSE_SUPERVISOR_ECALL&nb= sp;       0xa
> > > > > > > +#define RISCV_CAUSE_MACHINE_ECALL =           0xb
> > > > > > > +#define RISCV_CAUSE_FETCH_PAGE_FAULT&nb= sp;       0xc
> > > > > > > +#define RISCV_CAUSE_LOAD_PAGE_FAULT&nbs= p;        0xd
> > > > > > > +#define RISCV_CAUSE_STORE_PAGE_FAULT&nb= sp;       0xf
> > > > > > > +#define RISCV_CAUSE_FETCH_GUEST_PAGE_FA= ULT  0x14
> > > > > > > +#define RISCV_CAUSE_LOAD_GUEST_PAGE_FAU= LT   0x15
> > > > > > > +#define RISCV_CAUSE_STORE_GUEST_PAGE_FA= ULT  0x17
> > > > > > > +
> > > > > > > +//
> > > > > > > +// Machine Read-Write Shadow of Hypervi= sor Read-Only Registers
> > > > > > > +//
> > > > > > > +#define RISCV_CSR_HTIMEW  &nb= sp;            = 0xB01
> > > > > > > +#define RISCV_CSR_HTIMEHW  &n= bsp;            0xB8= 1
> > > > > > > +//
> > > > > > > +// Machine Host-Target Interface (Non-S= tandard Berkeley
> > Extension)
> > > > > > > +//
> > > > > > > +#define RISCV_CSR_MTOHOST  &n= bsp;            0x78= 0
> > > > > > > +#define RISCV_CSR_MFROMHOST  =            0x781
> > > > > > > +
> > > > > > > +#endif
> > > > > > > diff --git a/Silicon/RISC-V/ProcessorPkg= /Include/RiscVImpl.h
> > > > b/Silicon/RISC-V/ProcessorPkg/Include/RiscVImpl.h
> > > > > > > new file mode 100644
> > > > > > > index 0000000000..14092df174
> > > > > > > --- /dev/null
> > > > > > > +++ b/Silicon/RISC-V/ProcessorPkg/Includ= e/RiscVImpl.h
> > > > > > > @@ -0,0 +1,87 @@
> > > > > > > +/** @file
> > > > > > > +  RISC-V package definitions.
> > > > > > > +
> > > > > > > +  Copyright (c) 2016 - 2019, Hewle= tt Packard Enterprise
> > Development
> > > > LP. All rights reserved.<BR>
> > > > > > > +
> > > > > > > +  SPDX-License-Identifier: BSD-2-C= lause-Patent
> > > > > > > +
> > > > > > > +**/
> > > > > > > +
> > > > > > > +#ifndef RISCV_H_
> > > > > > > +#define RISCV_H_
> > > > > > > +
> > > > > > > +#include <Uefi.h>
> > > > > > > +#include <IndustryStandard/RiscV.h&g= t;
> > > > > > > +
> > > > > > > +#define _ASM_FUNC(Name, Section) &= nbsp;  \
> > > > > > > +  .global   Name &n= bsp;            = ;    ; \
> > > > > > > +  .section  #Section, "a= x"        ; \
> > > > > > > +  .type     Na= me, %function       ; \
> > > > > > > +  .p2align  2  &nbs= p;            &= nbsp;     ; \
> > > > > > > +  Name:
> > > > > > > +
> > > > > > > +#define ASM_FUNC(Name) _ASM_FUNC(ASM_PF= X(Name), .text.
> > ##
> > > > Name)
> > > > > > > +
> > > > > > > +#if defined (MDE_CPU_RISCV64)
> > > > > > > +typedef UINT64 RISC_V_REGS_PROTOTYPE; > > > > > > > +#else
> > > > > > > +#endif
> > > > > > > +
> > > > > > > +//
> > > > > > > +// Structure for 128-bit value
> > > > > > > +//
> > > > > > > +typedef struct {
> > > > > > > +  UINT64    &n= bsp;       Value64_L;
> > > > > > > +  UINT64    &n= bsp;       Value64_H;
> > > > > > > +} RISCV_UINT128;
> > > > > > > +
> > > > > > > +#define RISCV_MACHINE_CONTEXT_SIZE = ; 0x1000
> > > > > > > +typedef struct _RISCV_MACHINE_MODE_CONT= EXT
> > > > RISCV_MACHINE_MODE_CONTEXT;
> > > > > > > +
> > > > > > > +///
> > > > > > > +/// Exception handlers in context.
> > > > > > > +///
> > > > > > > +typedef struct _EXCEPTION_HANDLER_CONTE= XT {
> > > > > > > +  EFI_PHYSICAL_ADDRESS InstAddress= MisalignedHander;
> > > > > > > +  EFI_PHYSICAL_ADDRESS InstAccessF= aultHander;
> > > > > > > +  EFI_PHYSICAL_ADDRESS IllegalInst= Hander;
> > > > > > > +  EFI_PHYSICAL_ADDRESS BreakpointH= ander;
> > > > > > > +  EFI_PHYSICAL_ADDRESS LoadAddrMis= alignedHander;
> > > > > > > +  EFI_PHYSICAL_ADDRESS LoadAccessF= aultHander;
> > > > > > > +  EFI_PHYSICAL_ADDRESS StoreAmoAdd= rMisalignedHander;
> > > > > > > +  EFI_PHYSICAL_ADDRESS StoreAmoAcc= essFaultHander;
> > > > > > > +  EFI_PHYSICAL_ADDRESS EnvCallFrom= UModeHander;
> > > > > > > +  EFI_PHYSICAL_ADDRESS EnvCallFrom= SModeHander;
> > > > > > > +  EFI_PHYSICAL_ADDRESS EnvCallFrom= HModeHander;
> > > > > > > +  EFI_PHYSICAL_ADDRESS EnvCallFrom= MModeHander;
> > > > > > > +} EXCEPTION_HANDLER_CONTEXT;
> > > > > > > +
> > > > > > > +///
> > > > > > > +/// Exception handlers in context.
> > > > > > > +///
> > > > > > > +typedef struct _INTERRUPT_HANDLER_CONTE= XT {
> > > > > > > +  EFI_PHYSICAL_ADDRESS SoftwareInt= Handler;
> > > > > > > +  EFI_PHYSICAL_ADDRESS TimerIntHan= dler;
> > > > > > > +} INTERRUPT_HANDLER_CONTEXT;
> > > > > > > +
> > > > > > > +///
> > > > > > > +/// Interrupt handlers in context.
> > > > > > > +///
> > > > > > > +typedef struct _TRAP_HANDLER_CONTEXT {<= br> > > > > > > > +  EXCEPTION_HANDLER_CONTEXT Except= ionHandlerContext;
> > > > > > > +  INTERRUPT_HANDLER_CONTEXT IntHan= dlerContext;
> > > > > > > +} TRAP_HANDLER_CONTEXT;
> > > > > > > +
> > > > > > > +///
> > > > > > > +/// Machine mode context used for savei= ng hart-local context.
> > > > > > > +///
> > > > > > > +typedef struct _RISCV_MACHINE_MODE_CONT= EXT {
> > > > > > > +  EFI_PHYSICAL_ADDRESS PeiService;=             &nb= sp;   /// PEI service.
> > > > > > > +  EFI_PHYSICAL_ADDRESS MachineMode= TrapHandler;    ///
> > Machine
> > > > mode trap handler.
> > > > > > > +  EFI_PHYSICAL_ADDRESS HypervisorM= odeTrapHandler; ///
> > Hypervisor
> > > > mode trap handler.
> > > > > > > +  EFI_PHYSICAL_ADDRESS SupervisorM= odeTrapHandler; ///
> > Supervisor
> > > > mode trap handler.
> > > > > > > +  EFI_PHYSICAL_ADDRESS UserModeTra= pHandler;       /// USer
> > mode
> > > > trap handler.
> > > > > > > +  TRAP_HANDLER_CONTEXT MModeHandle= r;            &= nbsp; /// Handler for
> > > > machine mode.
> > > > > > > +} RISCV_MACHINE_MODE_CONTEXT;
> > > > > > > +
> > > > > > > +#endif
> > > > > > > --
> > > > > > > 2.31.1
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
>

--_000_PH7PR84MB188578F5E35ED88047E79A8AFF029PH7PR84MB1885NAMP_--