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.web10.12193.1591185764217788649 for ; Wed, 03 Jun 2020 05:02:44 -0700 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: hpe.com, ip: 148.163.147.86, mailfrom: prvs=0423df82e3=daniel.schaefer@hpe.com) Received: from pps.filterd (m0148663.ppops.net [127.0.0.1]) by mx0a-002e3701.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 053BvrrQ000864; Wed, 3 Jun 2020 12:02:43 GMT Received: from g4t3426.houston.hpe.com (g4t3426.houston.hpe.com [15.241.140.75]) by mx0a-002e3701.pphosted.com with ESMTP id 31e7uv9r1q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 03 Jun 2020 12:02:42 +0000 Received: from G1W8106.americas.hpqcorp.net (g1w8106.austin.hp.com [16.193.72.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by g4t3426.houston.hpe.com (Postfix) with ESMTPS id 00CE170; Wed, 3 Jun 2020 11:57:41 +0000 (UTC) Received: from G9W8675.americas.hpqcorp.net (16.220.49.22) by G1W8106.americas.hpqcorp.net (16.193.72.61) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 3 Jun 2020 11:57:37 +0000 Received: from G2W6311.americas.hpqcorp.net (16.197.64.53) by G9W8675.americas.hpqcorp.net (16.220.49.22) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 3 Jun 2020 11:57:36 +0000 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (15.241.52.11) by G2W6311.americas.hpqcorp.net (16.197.64.53) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 3 Jun 2020 11:57:36 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PaJ5E3C921L7tgDVSSMQ3mw/AOqq3dCmVt+hU2rVCUJdkOUHaLWiIYRqlZ7Kcwza8vQ0MBuNBokh6CpBn4hnOqJclgG/pOdDBM2fkKKizjUZKcDaglKC0KXZSjnjR73142k+FLqE1kNh8RBUmjy9eHVljep+KqA6GOU0tZcXOvxr2gWrZovU6w+r+lbGEC0oNcWfxfncUduOXQ/DrW6X2oRukoD2uKkknavN6dvt4FAMBjdJjPIhzyFrq7hlcTlOyHy6bDcGhwY1tZ0rimpWLiCMwS6QbBm4FWl0mOnplaZZegcCxkbEqQJZmsQStJjAossur+8Q/iQeWj5phIAKlA== 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=Xpl4V/88BuJALGtxpa0iMeq3BvUdq3eqwBYqZjMFAy0=; b=REy4DIu0yRvao2FZU9UOth7TztW90UYi/I1qij+Htt0K3DHyL1K0SS40pxn7fUFQxak0vTWKavOF6ETGud/4aBlsq7gDDw+ELB2dODLvrLuAetTOaZua0HrotT9QPwd5mwqHdTo7yhIMbKMFKzRq2Vive4VdBQxcmrZBMfnDek/wASrIM/X5vzLQ73gBFMcobyL2rdTeVOCzcqWCOEzV3EQGKqK20+07Y8lZjxERsTtHWWzdM7SVGeyENnkbVwIuphzt20R64DWxKZMn9+hYjfIBVHZFqWDUbdEViYtjVee8E6zbjNdIRmdYOngY9bsqv91utBJn93hPNNdTjyHQSQ== 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 Authentication-Results: edk2.groups.io; dkim=none (message not signed) header.d=none;edk2.groups.io; dmarc=none action=none header.from=hpe.com; Received: from AT5PR8401MB0466.NAMPRD84.PROD.OUTLOOK.COM (2a01:111:e400:741f::10) by AT5PR8401MB1075.NAMPRD84.PROD.OUTLOOK.COM (2a01:111:e400:7428::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18; Wed, 3 Jun 2020 11:57:35 +0000 Received: from AT5PR8401MB0466.NAMPRD84.PROD.OUTLOOK.COM ([fe80::70f2:6970:9f7e:6ab6]) by AT5PR8401MB0466.NAMPRD84.PROD.OUTLOOK.COM ([fe80::70f2:6970:9f7e:6ab6%10]) with mapi id 15.20.3066.018; Wed, 3 Jun 2020 11:57:35 +0000 Subject: [edk2-devel] Where to put RISC-V packages To: Sean Brogan , "Kinney, Michael D" , "Chang, Abner (HPS SW/FW Technologist)" , Bret Barkelew , "Ard Biesheuvel (ard.biesheuvel@linaro.org)" , "Zimmer, Vincent" , Leif Lindholm CC: "devel@edk2.groups.io" References: <20200515133937.29909-1-daniel.schaefer@hpe.com> <20200520114336.GK1923@vanye> <6f0d755e-4e69-5080-ef69-caf7259ce9ee@hpe.com> <27d3bf55-eb2e-75e1-e5fa-17af59e105aa@hpe.com> <20200528115449.GE1923@vanye> From: "Daniel Schaefer" Message-ID: Date: Wed, 3 Jun 2020 13:57:29 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 In-Reply-To: X-ClientProxiedBy: SN4PR0501CA0151.namprd05.prod.outlook.com (2603:10b6:803:2c::29) To AT5PR8401MB0466.NAMPRD84.PROD.OUTLOOK.COM (2a01:111:e400:741f::10) X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.178.165] (93.215.223.132) by SN4PR0501CA0151.namprd05.prod.outlook.com (2603:10b6:803:2c::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.8 via Frontend Transport; Wed, 3 Jun 2020 11:57:32 +0000 X-Originating-IP: [93.215.223.132] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: eb27f020-1f38-4ddc-95e5-08d807b54dc9 X-MS-TrafficTypeDiagnostic: AT5PR8401MB1075: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-Forefront-PRVS: 04238CD941 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: F7RVN5yjO7ycPtWoY4JiPBhh/lr9LplrrPLHcgg7W0CjHDiSRBeJqCe3d2vm8pfvQE+cve9NbD+4/xSJI+mNhAieH2diKTzCwhcyrNmj8QrPc046z42D5KK8CXwqM+BW1NqXXm7U+OtiaDg+XROIb5XlQvcDpO7x1iiHPbyc6mEn9pG8KAyRi5+UFCz4xqAWFuH+hb/j92Zxnx2nbMDhYMpL3bo8jLzL0Gs46pBFAaCg43r4xCFrj6oWH1TEXFwIAulYV5FPrbTuLm0U/ww55KJ1BMZJjpy0q9DkV6kBYdQVlpyYJE/2Q/m0SSYnuHoIJfNcPR5uopE0/AKMiJM93zzMo+atUiWqE8NkQA86NEmQ/MAXDOHP5z8ijJW8HVICpsIZBVcQd93CvT6h6yaJEg== X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AT5PR8401MB0466.NAMPRD84.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFTY:;SFS:(376002)(346002)(366004)(136003)(39860400002)(396003)(83380400001)(30864003)(31686004)(8676002)(45080400002)(66556008)(4326008)(956004)(16576012)(2906002)(2616005)(66946007)(31696002)(53546011)(66476007)(110136005)(44832011)(8936002)(478600001)(316002)(6666004)(16526019)(52116002)(86362001)(36756003)(6486002)(26005)(186003)(5660300002)(921003)(43740500002);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData: plO+tKKcjAP+clNqXam2vIjbLLm+/OSWh/7F8brRJhHlwLoLQrsYGILysPSHuqXhyXQ7j41+chHPKO0ZM9Hy9Ih5x/Cz4ZnY8JPILj1aGC7lYZQJGBokGtZGf3IdQ74ZCg6Ecf0K8EiAbtSwHRBwb0INd+vBgyHJP6vKPHg4lwsxufK2eR/BHEmasGKbiKJKqFVjN1sDmSeNwyiTxUkv5ZqP3CGt80QZiNM3plYvEjefNYNNrycXxoaaFkfdSGhjh8zPzk0DL8G5w9cYKU7+ToyGeIXH9EzUg2R9XnQUOL03Jxf9fJixjE8K9MgdtCmFnvTDdl1o7GJA/4DGlhH8k/PwbagD5sIHxStaB9RVAkUCKtCD1tM/ZcbRQesGCUOnScucEhV0LaXDnMOqR7XaKkAEbVDL2u5x2GgcK4w81UG/ZoRixG3BM14g3+5tTxS/bKU4kGKp0wFc5gB9RGMhMS5Beh0gibRBi4TX0jLH/YfN7a6GDjJhZw5aWpvu3Lun X-MS-Exchange-CrossTenant-Network-Message-Id: eb27f020-1f38-4ddc-95e5-08d807b54dc9 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Jun 2020 11:57:35.3104 (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: 5gdcyPfIoRN2TYjwHOWwGYuov0rTRPP64faPkeFkDlKQxwOJdQ8UZpgVi5A1iEHsnkzLl9UC34qy6EAC8AxQKQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AT5PR8401MB1075 X-OriginatorOrg: hpe.com X-Proofpoint-UnRewURL: 0 URL was un-rewritten MIME-Version: 1.0 X-HPE-SCL: -1 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216,18.0.687 definitions=2020-06-03_11:2020-06-02,2020-06-03 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 malwarescore=0 spamscore=0 suspectscore=2 mlxlogscore=999 bulkscore=0 cotscore=-2147483648 adultscore=0 priorityscore=1501 mlxscore=0 clxscore=1011 impostorscore=0 phishscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006030095 X-MIME-Autoconverted: from 8bit to quoted-printable by mx0a-002e3701.pphosted.com id 053BvrrQ000864 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hi all, (CC edk2 devel ML - shouldn't be a private discussion again) let me try to summarize the points of each: - edk2-platforms isn't a less stable edk2 per se - edk2-platforms can be used for architectural decisions that are not stable yet and therefore different platforms might implement them differently - Still we'd rather put unstable things in edk2-platforms for now - In the future CPU Init shouldn't be totally separate packages but the overlapping code should be combined in UefiCpuPkg/MdePkg/MdeModulePkg/... - This applies to RISC-V, as well as ARM - UefiCpuPkg is too x86 focused -> needs lots of work and RISC-V shouldn't wait for that - RISC-V changes should preferably be integrated into existing packages instead of building an entirely separate hierarchy -> We have done this. For example DxeIpl is now in edk2 in MdeModulePkg. I hope everyone can agree with this summary. I suggest that we do the following: - Merge all of the RISC-V code to edk2-platforms - Evaluate the packages individually and move them to edk2 one by one, or to merge them into existing edk2 packages - In the end in edk2-platforms should only remain code for specific platforms, like the SiFive Unleashed board. No generic RISC-V code, right? I'm not experienced enough with EDK2 to evaluate whether packages might fit into EDK2 directly. Maybe we should have a call and have a look at each on individually? Below I looked into the libraries and drivers of every package that we want to upstream with our branch. I describe, what they do and if they are platform specific. Then I issue my guess for where it would belong. I hope that gives everyone a bit more insight into all of the code we'd like to merge. Again: Would it be okay to merge everything as is into edk2-platforms.=20 (DxeIpl was previously merged into edk2). And then slowly migrate them over into=20 edk2? Or should be evaluate each package individually now instead of merging everything at once. - Platform/RISC-V/PlatformPkg - FirmwareContextProcessorSpecificLib Take processors specific data from SMBIOS and put in HOB =3D> edk2 - OpensbiPlatformLibNull Null library for platform provided OpenSBI functions. Those functions are defined in the SiFive directories =3D> edk2 - PlatformBootManagerLib I'm not sure why this is there. It doesn't look RISC-V specific. cc: Abner =3D> ??? - PlatformMemoryTestLibNull Same as above =3D> ??? - PlatformUpdateProgressLibNull Same as above =3D> ??? - RiscVPlatformTempMemoryInitLibNull Initialize temporary RAM on stack. Same on every RISC-V CPU Depends on platform's PCD values =3D> edk2 - Sec SEC Phase, same for every RISC-V CPU =3D> edk2 - Silicon/RISC-V/ProcessorPkg - PeiServicesTablePointerLibOpenSbi Saving/loading PeiServicesTable in RISC-V scratch space with OpenSBI On every RISC-V CPU =3D> edk2 - RiscVCpuLib ASM functions to read RISC-V CSRs on every RISC-V CPU For UefiCpuPkg? =3D> edk2 - RiscVEdk2SbiLib Wrapper library to call the SBI ecalls on every RISC-V CPU =3D> edk2 - RiscVExceptionLib CpuExceptionHandlerLib implementation for RISC-V Currently only uses CSR accesses cc Abner: Will this be platform specific with the CLIC proposals? =3D> edk2/edk2-platforms?? - RiscVOpensbiLib OpenSBI library Needs to be called in early init on every RISC-V CPU =3D> edk2? - RiscVPlatformTimerLibNull,RiscVTimerLib TimerLib implementation for RISC-V Depends on platform specific PCDs only =3D> edk2? - CpuDxe Produces: gEfiCpuArchProtocolGuid Would go into UefiCpuPkg =3D> edk2 - SmbiosDxe Create SMBIOS entries type 4, type 7 and type 44 Values need to be set by platform =3D> edk2-platforms All packages under edk2-platforms/{Silicon,Platform}/SiFive/ are not included here, as they are obviously platform specific and need to go into edk2-platforms. Thanks, Daniel On 5/29/20 7:25 AM, Sean Brogan wrote: > Sorry was just getting to this.=C2=A0 You guys are fast.=C2=A0 This is = mostly to=20 > Daniel=E2=80=99s original email but I think it lines up with Abner=E2=80= =99s questions=20 > and Mike=E2=80=99s response. >=20 > Daniel, >=20 > I think both Mike and Bret said most everything needed but I'll clarify= =20 > just in case. >=20 > I don't think the conversations below (Daniels) is accurate for my=20 > concerns about RiscV support or my view of edk2-platforms. >=20 > In my view Edk2 packages are best when they are functionality based. =20 > This allows for proper code base layering and makes sure that=20 > abstractions are created in a way that will facilitate cross platform=20 > core development.=C2=A0 For packages that are based on other characteri= stics,=20 > like architecture, dependencies at the package level usually become=20 > tangled and brittle which slowly leaks out into the rest of the code=20 > base and then makes the entire repository harder to work with. >=20 > For that reason I advocated that the RiscV support be integrated into=20 > the appropriate packages and modules.=C2=A0 Where there is unique=20 > functionality that then needs to be evaluated to determine if its core=20 > functionality or platform functionality. Depending on that it would the= n=20 > land in the appropriate edk2 package or something in edk2-platforms. >=20 > Thanks >=20 > Sean >=20 > *From:* Kinney, Michael D > *Sent:* Thursday, May 28, 2020 10:18 PM > *To:* Chang, Abner (HPS SW/FW Technologist) ; Bret= =20 > Barkelew ; Schaefer, Daniel (DualStudy)=20 > ; Sean Brogan ; Ard= =20 > Biesheuvel (ard.biesheuvel@linaro.org) ;=20 > Zimmer, Vincent ; Kinney, Michael D=20 > > *Cc:* Leif Lindholm > *Subject:* [EXTERNAL] RE: Re: [edk2-devel] [PATCH v2 0/3] New RISC-V=20 > Patches - Why in edk2-platforms >=20 > Abner, >=20 > The architectural RISCV CPU content that does not change between RISCV=20 > CPU implementations would be a candidate for MdePkg, MdeModulePkg, or=20 > UefiCpuPkg.=C2=A0 We would need to do another review of the content alo= ng=20 > with the ARM/AARCH64 content to see how best to organize the CPU relate= d=20 > content for now and future. >=20 > RISCV platform content would still need to go into edk2-platforms. =20 > Non-architectural RISCV CPU content would also need to go into=20 > edk2-platforms. >=20 > Mike >=20 > *From:* Chang, Abner (HPS SW/FW Technologist) > > *Sent:* Thursday, May 28, 2020 10:01 PM > *To:* Kinney, Michael D >; Bret Barkelew=20 > >;=20 > Schaefer, Daniel (DualStudy) >; Sean Brogan=20 > >; Ard=20 > Biesheuvel (ard.biesheuvel@linaro.org=20 > ) >; Zimmer, Vincent=20 > > > *Cc:* Leif Lindholm > > *Subject:* RE: Re: [edk2-devel] [PATCH v2 0/3] New RISC-V Patches - Why= =20 > in edk2-platforms >=20 > *From:* Kinney, Michael D [mailto:michael.d.kinney@intel.com] > *Sent:* Friday, May 29, 2020 12:36 PM > *To:* Bret Barkelew >; Schaefer, Daniel (DualStudy)=20 > >; Sean Brogan= =20 > >; Ard=20 > Biesheuvel (ard.biesheuvel@linaro.org=20 > ) >; Kinney, Michael D=20 > >;=20 > Zimmer, Vincent > > *Cc:* Leif Lindholm >;=20 > Chang, Abner (HPS SW/FW Technologist) > > *Subject:* RE: [EXTERNAL] Re: [edk2-devel] [PATCH v2 0/3] New RISC-V=20 > Patches - Why in edk2-platforms >=20 > We did a community review meeting.=C2=A0 I recall Ard and Vincent being= present. >=20 > We discuss the CPU execution mode for PEI and DXE and there was a=20 > discussion that RISCV has 2 modes and they want flexibility to use=20 > both.=C2=A0 This choice is not defined in the PI spec yet.=C2=A0 We sug= gested that=20 > it could follow the ARM/Thumb model and RISCV could choose a single mod= e=20 > for all PEIMs and DXE drivers and choose to go into the other mode in=20 > the module implementation as needed. >=20 > */[Abner] Yes. we done this as we discussed in the community meeting.=20 > Those code are belong to RiscV*pkg and currently lay on=20 > devel-riscvplatfoms which Leif is reviewing now./* >=20 > Given that these fundamental CPU execution mode design choices were=20 > still in flux, it did not seem like it was ready for edk2 yet. >=20 > */[Abner] The current implementation is PEI/DXE are in the same mode./* >=20 > edk2-staging or an edk2-platforms branch seemed more appropriate until=20 > all that was worked out. >=20 > */[Abner] Seems like that work is done. Maybe I have to review PI/UEFI=20 > spec for the necessary changes./* >=20 > edk2-platforms/master seemed ok as well if different RISCV CPU modes=20 > would be used for different platform solutions until a unified approach= =20 > by the RISCV vendors could be determined=C2=A0 Once that was solidified= ,=20 > promoting to edk2 would be possible. >=20 > */[Abner] this means RicsVPkg and RicsVPlatformPkg eventually will be=20 > located in edk2 but not edk2-platforms if above issues are addressed? W= e=20 > don=E2=80=99t have to consider UefiCpuPkg for each arch now? We are goo= d with=20 > this though./* >=20 > Hopefully this clarifies for Leif why there was some resistance to edk2= =20 > repo right now.=C2=A0 Still on deck for the future. >=20 > Mike >=20 > *From:* Bret Barkelew > > *Sent:* Thursday, May 28, 2020 8:11 PM > *To:* Daniel Schaefer >; Kinney, Michael D=20 > >; Sean=20 > Brogan > > *Cc:* Leif Lindholm >;=20 > Chang, Abner (HPS SW/FW Technologist) > > *Subject:* RE: [EXTERNAL] Re: [edk2-devel] [PATCH v2 0/3] New RISC-V=20 > Patches - Why in edk2-platforms >=20 > I think Sean has his own feedback, but my response to Abner was that=20 > that I didn=E2=80=99t like the idea of continuing a pattern of separate= packages=20 > for significant portions of the CPU init. There have been a few times=20 > where it has created unnecessary divergence that made it very difficult= =20 > to write cross-architecture code. I, personally, wasn=E2=80=99t fightin= g the=20 > code landing in edk2 (except for RiscVPlatform, because it had platform= =20 > in the name), but I was inquiring to see whether it made more sense to=20 > break things up among Mde, UefiCpu, and a couple other packages to=20 > encourage adhering to similar patterns and interfaces between all the=20 > different architectures. I=E2=80=99ve previously wondered openly whethe= r it made=20 > sense to do the same with the Arm packages. >=20 > I=E2=80=99ll be honest about not being super familiar with the RISCV co= de and it=20 > would be easy for me to just shrug and say put it wherever, but I know=20 > that architecture mobility/agility is important for us and wouldn=E2=80= =99t be=20 > surprised if I had to use RISCV in the future, and so wanted to make=20 > sure that it was as close to what I was familiar with as possible. >=20 > - Bret >=20 > *From: *Daniel Schaefer > *Sent: *Thursday, May 28, 2020 8:44 AM > *To: *Kinney, Michael D ; Bret=20 > Barkelew ; Sean Brogan=20 > > *Cc: *Leif Lindholm ; Chang, Abner (HPS SW/FW= =20 > Technologist) > *Subject: *[EXTERNAL] Re: [edk2-devel] [PATCH v2 0/3] New RISC-V Patche= s=20 > - Why in edk2-platforms >=20 > Hi Mike, Bret and Sean, >=20 > you have previously expressed concern about merging HPE's RISC-V code > into edk2 and suggested merging it into edk2-platforms. Apparently you > discussed this with Abner in a private email thread. According to that > information I tried to summarize your points in an email on the edk2 ML. > I hope I got it right. >=20 > As you can see, we have followed that suggestion and sent the new > patches required for that to the ML. >=20 > Leif, and I, are still not convinced it's the right choice to not > include it in edk2 proper. > We would appreciate if you could address the concerns Leif has mentione= d > in the below email on the public ML. >=20 > Thanks! > Daniel >=20 > On 5/28/20 1:54 PM, Leif Lindholm wrote: > > Hi Abner, > > > > Sorry, I should have followed up on this sooner. > > > > On Thu, May 21, 2020 at 06:59:20 +0000, Chang, Abner (HPS SW/FW=20 > Technologist) wrote: > >>> On 5/20/20 6:07 PM, Daniel Schaefer wrote: > >>>> please reply here, fixed Mike's email address, sorry... > >>>> > >>>> On 5/20/20 6:03 PM, Daniel Schaefer wrote: > >>>>> On 5/20/20 1:43 PM, Leif Lindholm wrote: > >>>>>> On Fri, May 15, 2020 at 15:39:34 +0200, Daniel Schaefer wrote: > >>>>>>> Previously we had two packages just for RISC-V on our edk2 bra= nch: > >>>>>>>=C2=A0 =C2=A0=C2=A0 RiscVPkg and RiscVPlatformPkg > >>>>>>> They are now under > >>>>>>>=C2=A0 =C2=A0=C2=A0 Platform/RISC-V/PlatformPkg and Silicon/RIS= C-V/ProcessorPkg in > >>>>>>> edk2-platforms. > >>>>>> > >>>>>> Understood. I took my eye off the ball there for a while, but I= 'm a > >>>>>> bit confused as to why RiscVPkg isn't going into EDK2. That is = very > >>>>>> counterintuitive. And clearly it will need revisiting if we are= to > >>>>>> add first-class CI checks like those we do with OvmfPkg/ArmVirt= Pkg. > >>>>> > >>>>> Yes, I understand your concern. Personally I'd like it also to b= e in > >>>>> EDK2 straight away, however Mike, Bret and Sean have raised vali= d > >>>>> concerns: > > > > Can you point me to the conversation I have missed? > > > >>>>> 1. RISC-V is very new and potentially unstable - it's quicker to= make > >>>>> changes in edk2-platforms. > > > > I don't see this as a valid argument. > > It's not edk2-unstable, it is edk2-platforms. > > > > edk2-platforms exists because there used to be strong feelings again= st > > holding *real* platforms in edk2, with edk2 being originally intende= d > > only as a code library for IBV/ISV to cherry-pick from. > > > > But fundamentally, if code is too immature to go into the master > > branch of edk2, it is too immature to go into the master branch of > > edk2-platforms. If we want edk2-might-be-a-bit-shaky-but-who-cares, > > then someone will have to create it. > > > >>>>> 2. If we define new interfaces and libraries in edk2, we can't r= emove > >>>>> them easily because it would be a backwards-incompatible change. > >>>>> edk2-platforms isn't quite as strict. > > > > Yes it is. > > The only thing making it less strict is its contents - platform port= s > > and device drivers. The changes tend to be self-contained. Where the= y > > are not, they need to be carefully managed. > > > >>>>> 3. Long-term, I think many agree, we should aim to move much of = the > >>>>> RISC-V code into UefiCpuPkg and OvmfPkg. Mike mentioned that wou= ld > >>>>> need coordination with ARM maintainers because it might make sen= se to > >>>>> move their code there as well. > > > > I don't think there is any need to tie the two together. > > Yes, UefiCpuPkg should be a generic place where not only x86 support > > can be contained, but the paths for ARM* and RISC-V into there do no= t > > have any interdependencies. >=20