Re: [edk2] [PATCH] MdeModulePkg/DxeIplPeim: RISC-V arch DxeIpl.
> On May 12, 2016, at 1:46 AM, Chang, Abner (HPS SW/FW Technologist) > <abner.ch...@hpe.com> wrote: > > Hi Andrew, > Yes. I get the same messages from Mark and Dong to work on a staging branch > for RISC-V as this is a public branch. I will work on branch first and then > Dong will submit the ECRs. > Regards to a driver which provides the version of RISC-V implementation, I > think OSs/softwares can recognize this by checking the EFI spec version from > the system table. Says UEFI spec 2.6 is the pre-UEFI spec RISC-V UEFI system > if RISC-V processor binding is published in UEFI spec 2.7. This works? I was being paranoid about the version, as some one could merge the wrong thing and mess it up. It is a public repo so it can be cloned by others. If the Cpu DXE driver published the version protocol then it takes a git commit to remove it and it is less likely to get broken. Thanks, Andrew Fish > Thanks > Abner > -Original Message- > From: af...@apple.com [mailto:af...@apple.com] > Sent: Thursday, May 12, 2016 5:46 AM > To: Chang, Abner (HPS SW/FW Technologist) <abner.ch...@hpe.com> > Cc: Jordan Justen <jordan.l.jus...@intel.com>; Yao, Jiewen > <jiewen@intel.com>; edk2-devel@lists.01.org; Mike Kinney > <michael.d.kin...@intel.com>; Gao, Liming <liming....@intel.com>; Mangefeste, > Tony <tony.mangefe...@intel.com> > Subject: Re: [edk2] [PATCH] MdeModulePkg/DxeIplPeim: RISC-V arch DxeIpl. > > >> On May 9, 2016, at 11:24 AM, Mangefeste, Tony <tony.mangefe...@intel.com> >> wrote: >> >> Yao has the best idea, which is for Abner to package this into a RiscV*.pkg, >> and perhaps into a platform branch or staging branch (depending on a number >> of factors). >> >> Abner, run this through the PIWG as you stated, that's external to our >> Tianocore community. He can at least stage the code somewhere, so that the >> community can use the code, play with it, and give him feedback. >> > > Abner, > > I started a conversation with Mike Kinney and Leif Lindholm about how we > should handle RISC-V. A staging branch (you are adding an new CPU binding) or > a platform branch (you need one to test the new CPU) is a good place to > start. If having the RISC-V port in the branch becomes an issue we can > discuss promoting it to master. It is a given we will push the RISC-V port to > master when the binding shows up in a UEFI spec, but we don't want UEFI Spec > getting published to block progress on other open source projects so we are > willing to try and do the right thing for the broader open source community > if needed. > > One of the main reasons for the UEFI spec writing black out period is to > prevent vendors form rushing to market with incompatible implementations. > Given this it would be useful for any code in your branch that touches > current edk2 components to have comments documenting the experimental > processor binding (fell free to chose better terminology). After the binding > gets added to the UEFI Spec the comments can be updated to reference the UEFI > spec version they conform to. > > I was also thinking it would be a good idea for all the current RISC-V > implementations to publish a protocol that documents the version of the > implementation. An OS for example could figure out this is the pre UEFI spec > version of RISC-V based on knowing the protocol exists. I assume the versions > in this protocol could be RISC-V spec versions, and/or other versions that > make sense for the RISC-V EFI project. The goal is to make it discoverable by > software that this is a pre-UEFI Spec RISC-V UEFI system. > > Thanks, > > Andrew Fish > >> Good discussion. >> >>> -Original Message- >>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf >>> Of Jordan Justen >>> Sent: Monday, May 9, 2016 10:46 AM >>> To: Yao, Jiewen <jiewen@intel.com>; Chang, Abner (HPS SW/FW >>> Technologist) <abner.ch...@hpe.com>; edk2-devel@lists.01.org >>> Cc: Kinney, Michael D <michael.d.kin...@intel.com>; Gao, Liming >>> <liming@intel.com> >>> Subject: Re: [edk2] [PATCH] MdeModulePkg/DxeIplPeim: RISC-V arch >>> DxeIpl. >>> >>> On 2016-05-09 08:53:12, Yao, Jiewen wrote: >>>> Jordan >>>> Do you know why we have ArmPkg and ArmPlatformPkg? >>>> >>> >>> One reason is because we don't have a DriversPkg. Another reason is >>> probably because the effort wasn't made to put them into common >>> packages. >>> >>>> If you take
Re: [edk2] [PATCH] MdeModulePkg/DxeIplPeim: RISC-V arch DxeIpl.
Ha, will let them know. Thanks Abner -Original Message- From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] Sent: Friday, May 13, 2016 3:17 PM To: Chang, Abner (HPS SW/FW Technologist) <abner.ch...@hpe.com> Cc: Jordan Justen <jordan.l.jus...@intel.com>; edk2-devel@lists.01.org; liming@intel.com Subject: Re: [edk2] [PATCH] MdeModulePkg/DxeIplPeim: RISC-V arch DxeIpl. On 13 May 2016 at 04:05, Chang, Abner (HPS SW/FW Technologist) <abner.ch...@hpe.com> wrote: > Hi Ard, > Here is the PE/COFF spec update for RISC-V. Already published. > http://download.microsoft.com/download/9/C/5/9C5B2167-8017-4BAE-9FDE-D599BAC8184A/pecoff_v83.docx. > Thanks. Strangely enough, the filename itself says 'v83' while the doc says v9.3 > > -Original Message- > From: Chang, Abner (HPS SW/FW Technologist) > Sent: Monday, May 09, 2016 10:35 PM > To: 'Ard Biesheuvel' <ard.biesheu...@linaro.org> > Cc: Jordan Justen <jordan.l.jus...@intel.com>; > edk2-devel@lists.01.org; liming@intel.com > Subject: RE: [edk2] [PATCH] MdeModulePkg/DxeIplPeim: RISC-V arch DxeIpl. > > Hi Ard, > Yes. Microsoft has the definitions of RISC-V machine and relocation types in > PE/COFF spec. The values of RISC-V image and relocation types were provided > by us, so the values are consistent in both code and spec. > In Feb this year, they said the new revision of PE/COFF spec is in the > process of getting published. However, I didn’t get the notice yet. > Thanks > Abner > > -Original Message- > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] > Sent: Monday, May 09, 2016 10:06 PM > To: Chang, Abner (HPS SW/FW Technologist) <abner.ch...@hpe.com> > Cc: Jordan Justen <jordan.l.jus...@intel.com>; > edk2-devel@lists.01.org; liming@intel.com > Subject: Re: [edk2] [PATCH] MdeModulePkg/DxeIplPeim: RISC-V arch DxeIpl. > > On 8 May 2016 at 13:19, Chang, Abner (HPS SW/FW Technologist) > <abner.ch...@hpe.com> wrote: >> Hi Jordan, >> The UEFI/PI ECR for RISC-V is ready but not yet send to UEFI for review. I >> have been told to upstream RISC-V code first and then submit the spec. I >> will confirm this again. > > Hello Abner, > > Is the PE/COFF support that you implemented based on the PE/COFF spec? > > Regards, > Ard. ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] MdeModulePkg/DxeIplPeim: RISC-V arch DxeIpl.
Hi Ard, Here is the PE/COFF spec update for RISC-V. Already published. http://download.microsoft.com/download/9/C/5/9C5B2167-8017-4BAE-9FDE-D599BAC8184A/pecoff_v83.docx. -Original Message- From: Chang, Abner (HPS SW/FW Technologist) Sent: Monday, May 09, 2016 10:35 PM To: 'Ard Biesheuvel' <ard.biesheu...@linaro.org> Cc: Jordan Justen <jordan.l.jus...@intel.com>; edk2-devel@lists.01.org; liming@intel.com Subject: RE: [edk2] [PATCH] MdeModulePkg/DxeIplPeim: RISC-V arch DxeIpl. Hi Ard, Yes. Microsoft has the definitions of RISC-V machine and relocation types in PE/COFF spec. The values of RISC-V image and relocation types were provided by us, so the values are consistent in both code and spec. In Feb this year, they said the new revision of PE/COFF spec is in the process of getting published. However, I didn’t get the notice yet. Thanks Abner -Original Message- From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] Sent: Monday, May 09, 2016 10:06 PM To: Chang, Abner (HPS SW/FW Technologist) <abner.ch...@hpe.com> Cc: Jordan Justen <jordan.l.jus...@intel.com>; edk2-devel@lists.01.org; liming@intel.com Subject: Re: [edk2] [PATCH] MdeModulePkg/DxeIplPeim: RISC-V arch DxeIpl. On 8 May 2016 at 13:19, Chang, Abner (HPS SW/FW Technologist) <abner.ch...@hpe.com> wrote: > Hi Jordan, > The UEFI/PI ECR for RISC-V is ready but not yet send to UEFI for review. I > have been told to upstream RISC-V code first and then submit the spec. I will > confirm this again. Hello Abner, Is the PE/COFF support that you implemented based on the PE/COFF spec? Regards, Ard. ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] MdeModulePkg/DxeIplPeim: RISC-V arch DxeIpl.
Hi Andrew, Yes. I get the same messages from Mark and Dong to work on a staging branch for RISC-V as this is a public branch. I will work on branch first and then Dong will submit the ECRs. Regards to a driver which provides the version of RISC-V implementation, I think OSs/softwares can recognize this by checking the EFI spec version from the system table. Says UEFI spec 2.6 is the pre-UEFI spec RISC-V UEFI system if RISC-V processor binding is published in UEFI spec 2.7. This works? Thanks Abner -Original Message- From: af...@apple.com [mailto:af...@apple.com] Sent: Thursday, May 12, 2016 5:46 AM To: Chang, Abner (HPS SW/FW Technologist) <abner.ch...@hpe.com> Cc: Jordan Justen <jordan.l.jus...@intel.com>; Yao, Jiewen <jiewen@intel.com>; edk2-devel@lists.01.org; Mike Kinney <michael.d.kin...@intel.com>; Gao, Liming <liming@intel.com>; Mangefeste, Tony <tony.mangefe...@intel.com> Subject: Re: [edk2] [PATCH] MdeModulePkg/DxeIplPeim: RISC-V arch DxeIpl. > On May 9, 2016, at 11:24 AM, Mangefeste, Tony <tony.mangefe...@intel.com> > wrote: > > Yao has the best idea, which is for Abner to package this into a RiscV*.pkg, > and perhaps into a platform branch or staging branch (depending on a number > of factors). > > Abner, run this through the PIWG as you stated, that's external to our > Tianocore community. He can at least stage the code somewhere, so that the > community can use the code, play with it, and give him feedback. > Abner, I started a conversation with Mike Kinney and Leif Lindholm about how we should handle RISC-V. A staging branch (you are adding an new CPU binding) or a platform branch (you need one to test the new CPU) is a good place to start. If having the RISC-V port in the branch becomes an issue we can discuss promoting it to master. It is a given we will push the RISC-V port to master when the binding shows up in a UEFI spec, but we don't want UEFI Spec getting published to block progress on other open source projects so we are willing to try and do the right thing for the broader open source community if needed. One of the main reasons for the UEFI spec writing black out period is to prevent vendors form rushing to market with incompatible implementations. Given this it would be useful for any code in your branch that touches current edk2 components to have comments documenting the experimental processor binding (fell free to chose better terminology). After the binding gets added to the UEFI Spec the comments can be updated to reference the UEFI spec version they conform to. I was also thinking it would be a good idea for all the current RISC-V implementations to publish a protocol that documents the version of the implementation. An OS for example could figure out this is the pre UEFI spec version of RISC-V based on knowing the protocol exists. I assume the versions in this protocol could be RISC-V spec versions, and/or other versions that make sense for the RISC-V EFI project. The goal is to make it discoverable by software that this is a pre-UEFI Spec RISC-V UEFI system. Thanks, Andrew Fish > Good discussion. > >> -Original Message- >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf >> Of Jordan Justen >> Sent: Monday, May 9, 2016 10:46 AM >> To: Yao, Jiewen <jiewen@intel.com>; Chang, Abner (HPS SW/FW >> Technologist) <abner.ch...@hpe.com>; edk2-devel@lists.01.org >> Cc: Kinney, Michael D <michael.d.kin...@intel.com>; Gao, Liming >> <liming@intel.com> >> Subject: Re: [edk2] [PATCH] MdeModulePkg/DxeIplPeim: RISC-V arch >> DxeIpl. >> >> On 2016-05-09 08:53:12, Yao, Jiewen wrote: >>> Jordan >>> Do you know why we have ArmPkg and ArmPlatformPkg? >>> >> >> One reason is because we don't have a DriversPkg. Another reason is >> probably because the effort wasn't made to put them into common >> packages. >> >>> If you take a look at that, you will find many Arm specific driver >>> there, including CpuDxe/CpuPei/BaseMemoryLib/ >>> PeiServicesTablePointerLib/etc... >>> >> >> Should we create a package for IA32 and X64 to do the same? I think >> instead we put the IA32/X64 modules in other locations, and I think that >> made sense. >> If it made sense for IA32 and X64, then it should make sense for >> other architectures as well. >> >>> I do not think it is bad idea to have RiscVPkg, when we are not >>> clear on where to put it. >>> >> >> So this is the place to dump things that we don't know where else to >> put them? That doesn't inspire too much confidence. :) >> >> I agree that it might be needed, but can we
Re: [edk2] [PATCH] MdeModulePkg/DxeIplPeim: RISC-V arch DxeIpl.
> On May 9, 2016, at 11:24 AM, Mangefeste, Tony <tony.mangefe...@intel.com> > wrote: > > Yao has the best idea, which is for Abner to package this into a RiscV*.pkg, > and perhaps into a platform branch or staging branch (depending on a number > of factors). > > Abner, run this through the PIWG as you stated, that's external to our > Tianocore community. He can at least stage the code somewhere, so that the > community can use the code, play with it, and give him feedback. > Abner, I started a conversation with Mike Kinney and Leif Lindholm about how we should handle RISC-V. A staging branch (you are adding an new CPU binding) or a platform branch (you need one to test the new CPU) is a good place to start. If having the RISC-V port in the branch becomes an issue we can discuss promoting it to master. It is a given we will push the RISC-V port to master when the binding shows up in a UEFI spec, but we don't want UEFI Spec getting published to block progress on other open source projects so we are willing to try and do the right thing for the broader open source community if needed. One of the main reasons for the UEFI spec writing black out period is to prevent vendors form rushing to market with incompatible implementations. Given this it would be useful for any code in your branch that touches current edk2 components to have comments documenting the experimental processor binding (fell free to chose better terminology). After the binding gets added to the UEFI Spec the comments can be updated to reference the UEFI spec version they conform to. I was also thinking it would be a good idea for all the current RISC-V implementations to publish a protocol that documents the version of the implementation. An OS for example could figure out this is the pre UEFI spec version of RISC-V based on knowing the protocol exists. I assume the versions in this protocol could be RISC-V spec versions, and/or other versions that make sense for the RISC-V EFI project. The goal is to make it discoverable by software that this is a pre-UEFI Spec RISC-V UEFI system. Thanks, Andrew Fish > Good discussion. > >> -Original Message- >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of >> Jordan Justen >> Sent: Monday, May 9, 2016 10:46 AM >> To: Yao, Jiewen <jiewen@intel.com>; Chang, Abner (HPS SW/FW >> Technologist) <abner.ch...@hpe.com>; edk2-devel@lists.01.org >> Cc: Kinney, Michael D <michael.d.kin...@intel.com>; Gao, Liming >> <liming@intel.com> >> Subject: Re: [edk2] [PATCH] MdeModulePkg/DxeIplPeim: RISC-V arch >> DxeIpl. >> >> On 2016-05-09 08:53:12, Yao, Jiewen wrote: >>> Jordan >>> Do you know why we have ArmPkg and ArmPlatformPkg? >>> >> >> One reason is because we don't have a DriversPkg. Another reason is >> probably because the effort wasn't made to put them into common >> packages. >> >>> If you take a look at that, you will find many Arm specific driver >>> there, including CpuDxe/CpuPei/BaseMemoryLib/ >>> PeiServicesTablePointerLib/etc... >>> >> >> Should we create a package for IA32 and X64 to do the same? I think instead >> we put the IA32/X64 modules in other locations, and I think that made sense. >> If it made sense for IA32 and X64, then it should make sense for other >> architectures as well. >> >>> I do not think it is bad idea to have RiscVPkg, when we are not clear >>> on where to put it. >>> >> >> So this is the place to dump things that we don't know where else to put >> them? That doesn't inspire too much confidence. :) >> >> I agree that it might be needed, but can we try to minimize it? >> >> -Jordan >> >>> >>>> -Original Message- >>>> From: Justen, Jordan L >>>> Sent: Monday, May 9, 2016 11:46 PM >>>> To: Yao, Jiewen <jiewen@intel.com>; Chang, Abner (HPS SW/FW >>>> Technologist) <abner.ch...@hpe.com>; edk2-devel@lists.01.org >>>> Cc: Gao, Liming <liming@intel.com> >>>> Subject: RE: [edk2] [PATCH] MdeModulePkg/DxeIplPeim: RISC-V arch >> DxeIpl. >>>> >>>> On 2016-05-09 08:12:20, Yao, Jiewen wrote: >>>>> Thank Abner. >>>>> For RiscVPkg, my personally feeling is that it should stick to >>>>> RiscV architecture, like ArmPkg. >>>>> >>>> >>>> I don't agree. Why don't we have an X64Pkg? I think it is because >>>> we've defined good locations already for most modules, and many of >>>> those modules already supp
Re: [edk2] [PATCH] MdeModulePkg/DxeIplPeim: RISC-V arch DxeIpl.
On 2016-05-09 08:53:12, Yao, Jiewen wrote: > Jordan > Do you know why we have ArmPkg and ArmPlatformPkg? > One reason is because we don't have a DriversPkg. Another reason is probably because the effort wasn't made to put them into common packages. > If you take a look at that, you will find many Arm specific driver > there, including CpuDxe/CpuPei/BaseMemoryLib/ > PeiServicesTablePointerLib/etc... > Should we create a package for IA32 and X64 to do the same? I think instead we put the IA32/X64 modules in other locations, and I think that made sense. If it made sense for IA32 and X64, then it should make sense for other architectures as well. > I do not think it is bad idea to have RiscVPkg, when we are not > clear on where to put it. > So this is the place to dump things that we don't know where else to put them? That doesn't inspire too much confidence. :) I agree that it might be needed, but can we try to minimize it? -Jordan > > > -Original Message- > > From: Justen, Jordan L > > Sent: Monday, May 9, 2016 11:46 PM > > To: Yao, Jiewen <jiewen@intel.com>; Chang, Abner (HPS SW/FW > > Technologist) <abner.ch...@hpe.com>; edk2-devel@lists.01.org > > Cc: Gao, Liming <liming....@intel.com> > > Subject: RE: [edk2] [PATCH] MdeModulePkg/DxeIplPeim: RISC-V arch DxeIpl. > > > > On 2016-05-09 08:12:20, Yao, Jiewen wrote: > > > Thank Abner. > > > For RiscVPkg, my personally feeling is that it should stick to RiscV > > > architecture, like ArmPkg. > > > > > > > I don't agree. Why don't we have an X64Pkg? I think it is because > > we've defined good locations already for most modules, and many of > > those modules already support multiple architectures. > > > > Can't the first try be to see if we can get by without adding new > > architecture specific packages? > > > > > Below module seems to be software concept only. They are independent > > > to RISV-V architecture, right? > > > I am not sure if it is proper to put to RiscVPkg. > > > > > > > RiscVPkg/Universal/Logo/Logo.uni | Bin 0 -> > > 1948 bytes > > > > RiscVPkg/Universal/Logo/LogoExtra.uni | Bin 0 -> > > 1342 bytes > > > > RiscVPkg/Universal/Logo/RiscvUefiLogo.bmp | Bin 0 -> > > 12446 bytes > > > > RiscVPkg/Universal/Logo/RiscvUefiLogo.inf | 34 + > > > > RiscVPkg/Universal/RiscvBadgingDxe/RiscvBadging.c | 107 +++ > > > > RiscVPkg/Universal/RiscvBadgingDxe/RiscvBadging.h | 32 + > > > > .../Universal/RiscvBadgingDxe/RiscvBadgingDxe.inf | 54 ++ > > > > > > Maybe we can put to a RiscV platform pkg? > > > > > > > I think it would be better to add the logo to a common location like, > > perhaps MdeModulePkg/Universal/Logo/RiscV. > > > > Actually, I don't think the new logo is needed. We don't have > > architecture specific logos in other cases, and I don't think it is > > needed here. > > > > -Jordan > > > > > > > > > -Original Message- > > > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf > > Of > > > > Chang, Abner (HPS SW/FW Technologist) > > > > Sent: Monday, May 9, 2016 10:10 PM > > > > To: Justen, Jordan L <jordan.l.jus...@intel.com>; > > edk2-devel@lists.01.org > > > > Cc: Yao, Jiewen <jiewen@intel.com>; Gao, Liming > > > > <liming@intel.com> > > > > Subject: Re: [edk2] [PATCH] MdeModulePkg/DxeIplPeim: RISC-V arch > > DxeIpl. > > > > > > > > Hi Jordan, > > > > I will send out another draft version of patches which address all > > comments. > > > > Then upstream RISC-V code to the branch. > > > > Sure, I am pleased to check if there is any reusable modules for RISC-V. > > > > Thanks > > > > Abner > > > > > > > > -Original Message- > > > > From: Jordan Justen [mailto:jordan.l.jus...@intel.com] > > > > Sent: Monday, May 09, 2016 2:25 PM > > > > To: Chang, Abner (HPS SW/FW Technologist) <abner.ch...@hpe.com>; > > > > edk2-devel@lists.01.org > > > > Cc: liming@intel.com; Yao, Jiewen <jiewen@intel.com> > > > > Subject: Re: [edk2] [PATCH] MdeModulePkg/DxeIplPeim: RISC-V arch > > DxeIpl. > > > > > > > > On 2016-05-08 04:19:08, Chang, Abner (HPS SW/FW Technologist) wrote: > > > > > Hi Jordan, > > > > > The UEFI/PI EC
Re: [edk2] [PATCH] MdeModulePkg/DxeIplPeim: RISC-V arch DxeIpl.
On 2016-05-09 08:31:38, Laszlo Ersek wrote: > On 05/08/16 13:19, Chang, Abner (HPS SW/FW Technologist) wrote: > > What would prevent this from living under OvmfPkg? Say > OvmfPkg/OvmfPkgRiscV64.dsc? > > > I think it should be no problem to use OvmfPkg as common > > processor/platform emulator. Just you still can see few Intel things. > > ARM QEMU implementation must be considered as well if we move RISC-V > > to OvmfPkg, thus we can have the consistent implementation. RISC-V > > QEMU implementation just follows ARM QEMU implement, that is to have > > a separate package. But I agree with you that all > > processors/platforms emulator should be under OvmfPkg. > > I strongly disagree with this. Although OvmfPkg currently contains both > platform-specific modules (for Ia32 and X64), and a number of reusable, > platform-independent modules, it should not be considered a grab-bag of > guest platform code for any and all hypervisors (and their various targets). > > ArmVirtPkg has always been separate, despite being "just another" > upstream QEMU target. It has worked splendidly. > > Xen support lives right under OvmfPkg, and it has worked terribly. > My opinion on this is reversed. I wish more effort had been made to have arm-virt in OVMF, and I can't see how splitting Xen out to separate packages would have helped. > It all comes down to maintenance. Maintainers in edk2 are assigned to > top-level Pkg directories. If you introduce Risc-V virt in a separate > top level package, and become its maintainer, I welcome that with open > arms. If you try to push Risc-V stuff under OvmfPkg, which will make me > responsible for reviewing patches and fighting regressions for the sake > of a platform I have no interest in, I will definitely block that. > > ISA- and platform-specific modules live in separate directories in all > of the projects I can think of as examples. QEMU? Check. The kernel? > Check. Inter-mixing within a module is done only if the customization is > minimal. (There are a few examples in OvmfPkg, and I dislike them.) > > If edk2 elects to introduce a finer (= subdirectory- and file-level) > granularity to Maintainers.txt, *and* we can carve out a well separated > directory structure for RISC-V under OvmfPkg, then maybe I could be > convinced. > I think we should alter Maintainers.txt to work best for the tree rather than having the tree bend to Maintainers.txt. My main concern about Maintainers.txt is adding too many committers. Maybe we could add a reviewer level for people that can review for a package, but not commit. They can review and prep branches/patches for the maintainers to fetch and then push. In this case, maybe a RISC-V reviewer would work well for OVMF... I also note that ShellBinPkg seems to have some arch specific maintainers. -Jordan > For example, this *too* has worked perfectly well under ArmVirtPkg. In > ArmVirtPkg the separation between Xen and QEMU is utterly clear (thanks > again Ard!), and I immediately know if a quick skim and an Acked-by are > enough from me, or I need to dive in and spend a week or more on > reviewing patches. > > Regressions are terrible if they affect the code that I run, while they > are "meh" *for me* if they affect Xen. (This is not to say that Xen > should be ignored. Instead, it means that Xen people should delegate > their own full-time edk2 maintainers, and we should assign them with the > right granularity in Maintainers.txt. This happens to work very well in > ArmVirtPkg, where we informally follow such a subdivision with Ard.) > > Thanks > Laszlo > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] MdeModulePkg/DxeIplPeim: RISC-V arch DxeIpl.
On 2016-05-09 08:12:20, Yao, Jiewen wrote: > Thank Abner. > For RiscVPkg, my personally feeling is that it should stick to RiscV > architecture, like ArmPkg. > I don't agree. Why don't we have an X64Pkg? I think it is because we've defined good locations already for most modules, and many of those modules already support multiple architectures. Can't the first try be to see if we can get by without adding new architecture specific packages? > Below module seems to be software concept only. They are independent > to RISV-V architecture, right? > I am not sure if it is proper to put to RiscVPkg. > > > RiscVPkg/Universal/Logo/Logo.uni | Bin 0 -> 1948 bytes > > RiscVPkg/Universal/Logo/LogoExtra.uni | Bin 0 -> 1342 bytes > > RiscVPkg/Universal/Logo/RiscvUefiLogo.bmp | Bin 0 -> 12446 bytes > > RiscVPkg/Universal/Logo/RiscvUefiLogo.inf | 34 + > > RiscVPkg/Universal/RiscvBadgingDxe/RiscvBadging.c | 107 +++ > > RiscVPkg/Universal/RiscvBadgingDxe/RiscvBadging.h | 32 + > > .../Universal/RiscvBadgingDxe/RiscvBadgingDxe.inf | 54 ++ > > Maybe we can put to a RiscV platform pkg? > I think it would be better to add the logo to a common location like, perhaps MdeModulePkg/Universal/Logo/RiscV. Actually, I don't think the new logo is needed. We don't have architecture specific logos in other cases, and I don't think it is needed here. -Jordan > > > -Original Message- > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > > Chang, Abner (HPS SW/FW Technologist) > > Sent: Monday, May 9, 2016 10:10 PM > > To: Justen, Jordan L <jordan.l.jus...@intel.com>; edk2-devel@lists.01.org > > Cc: Yao, Jiewen <jiewen@intel.com>; Gao, Liming > > <liming@intel.com> > > Subject: Re: [edk2] [PATCH] MdeModulePkg/DxeIplPeim: RISC-V arch DxeIpl. > > > > Hi Jordan, > > I will send out another draft version of patches which address all comments. > > Then upstream RISC-V code to the branch. > > Sure, I am pleased to check if there is any reusable modules for RISC-V. > > Thanks > > Abner > > > > -Original Message- > > From: Jordan Justen [mailto:jordan.l.jus...@intel.com] > > Sent: Monday, May 09, 2016 2:25 PM > > To: Chang, Abner (HPS SW/FW Technologist) <abner.ch...@hpe.com>; > > edk2-devel@lists.01.org > > Cc: liming@intel.com; Yao, Jiewen <jiewen@intel.com> > > Subject: Re: [edk2] [PATCH] MdeModulePkg/DxeIplPeim: RISC-V arch DxeIpl. > > > > On 2016-05-08 04:19:08, Chang, Abner (HPS SW/FW Technologist) wrote: > > > Hi Jordan, > > > The UEFI/PI ECR for RISC-V is ready but not yet send to UEFI for > > > review. I have been told to upstream RISC-V code first and then submit > > > the spec. I will confirm this again. > > > > You were told to upstream EDK II support before the UEFI spec documented > > the architecture? Or, maybe to just prepare the EDK II code so it would be > > ready for upstream once it is in the spec? > > > > Maybe EDK II could adopt a new idea of an "unsupported architecture", but > > it seems like EDK II might make some mistakes if it doesn't wait for UEFI to > > standardize the architecture. For example, what if the calling convention > > changes before it makes it into the spec? > > > > I think Jiewen's idea of edk2-staging is good. But, before that, it seems > > you > > should make another draft version of the patches in fork of EDK II on > > github. > > > > In a few cases, I asked if the modules could be added to more generic > > locations. How about trying to look over everything in a RiscV*Pkg, and ask > > if it could instead live in Mde*Pkg, UefiCpuPkg or OvmfPkg? > > (And, hopefully by maximally reusing existing modules with architecture > > specific sources as needed...) > > > > For example, we don't have a X64*Pkg... > > > > -Jordan > > > > > Below response to your comments, > > > > --- > > > > MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf| 6 +- > > > > MdeModulePkg/Core/DxeIplPeim/Riscv64/DxeLoadFunc.c | 79 > > > > ++ > > > >>>Is it Riscv64 or RiscV64? > > > >>>Like MdePkg, I think MdeModulePkg only upports achitectures in the > > UEFI spec. > > > > > > This is typo, should be RiscV64. RISC-V arch UEFI spec is ready for > > > review. > > > > > > > > > > > --- > > > > RiscVPkg/Include/RiscV.h | 105 +++
Re: [edk2] [PATCH] MdeModulePkg/DxeIplPeim: RISC-V arch DxeIpl.
Thank Abner. For RiscVPkg, my personally feeling is that it should stick to RiscV architecture, like ArmPkg. Below module seems to be software concept only. They are independent to RISV-V architecture, right? I am not sure if it is proper to put to RiscVPkg. > RiscVPkg/Universal/Logo/Logo.uni | Bin 0 -> 1948 bytes > RiscVPkg/Universal/Logo/LogoExtra.uni | Bin 0 -> 1342 bytes > RiscVPkg/Universal/Logo/RiscvUefiLogo.bmp | Bin 0 -> 12446 bytes > RiscVPkg/Universal/Logo/RiscvUefiLogo.inf | 34 + > RiscVPkg/Universal/RiscvBadgingDxe/RiscvBadging.c | 107 +++ > RiscVPkg/Universal/RiscvBadgingDxe/RiscvBadging.h | 32 + > .../Universal/RiscvBadgingDxe/RiscvBadgingDxe.inf | 54 ++ Maybe we can put to a RiscV platform pkg? Thank you Yao Jiewen > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Chang, Abner (HPS SW/FW Technologist) > Sent: Monday, May 9, 2016 10:10 PM > To: Justen, Jordan L <jordan.l.jus...@intel.com>; edk2-devel@lists.01.org > Cc: Yao, Jiewen <jiewen@intel.com>; Gao, Liming > <liming....@intel.com> > Subject: Re: [edk2] [PATCH] MdeModulePkg/DxeIplPeim: RISC-V arch DxeIpl. > > Hi Jordan, > I will send out another draft version of patches which address all comments. > Then upstream RISC-V code to the branch. > Sure, I am pleased to check if there is any reusable modules for RISC-V. > Thanks > Abner > > -Original Message- > From: Jordan Justen [mailto:jordan.l.jus...@intel.com] > Sent: Monday, May 09, 2016 2:25 PM > To: Chang, Abner (HPS SW/FW Technologist) <abner.ch...@hpe.com>; > edk2-devel@lists.01.org > Cc: liming@intel.com; Yao, Jiewen <jiewen@intel.com> > Subject: Re: [edk2] [PATCH] MdeModulePkg/DxeIplPeim: RISC-V arch DxeIpl. > > On 2016-05-08 04:19:08, Chang, Abner (HPS SW/FW Technologist) wrote: > > Hi Jordan, > > The UEFI/PI ECR for RISC-V is ready but not yet send to UEFI for > > review. I have been told to upstream RISC-V code first and then submit > > the spec. I will confirm this again. > > You were told to upstream EDK II support before the UEFI spec documented > the architecture? Or, maybe to just prepare the EDK II code so it would be > ready for upstream once it is in the spec? > > Maybe EDK II could adopt a new idea of an "unsupported architecture", but > it seems like EDK II might make some mistakes if it doesn't wait for UEFI to > standardize the architecture. For example, what if the calling convention > changes before it makes it into the spec? > > I think Jiewen's idea of edk2-staging is good. But, before that, it seems you > should make another draft version of the patches in fork of EDK II on github. > > In a few cases, I asked if the modules could be added to more generic > locations. How about trying to look over everything in a RiscV*Pkg, and ask > if it could instead live in Mde*Pkg, UefiCpuPkg or OvmfPkg? > (And, hopefully by maximally reusing existing modules with architecture > specific sources as needed...) > > For example, we don't have a X64*Pkg... > > -Jordan > > > Below response to your comments, > > > --- > > > MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf| 6 +- > > > MdeModulePkg/Core/DxeIplPeim/Riscv64/DxeLoadFunc.c | 79 > > > ++ > > >>>Is it Riscv64 or RiscV64? > > >>>Like MdePkg, I think MdeModulePkg only upports achitectures in the > UEFI spec. > > > > This is typo, should be RiscV64. RISC-V arch UEFI spec is ready for review. > > > > > > > > --- > > > RiscVPkg/Include/RiscV.h | 105 +++ > > > .../PeiServicesTablePointer.c | 121 +++ > > > .../PeiServicesTablePointerLib.inf | 46 ++ > > > .../PeiServicesTablePointerLib.uni | Bin 0 -> 2520 > bytes > > > > > >>> utf-8. (See other my other email.) > > >>> > > >>>I think this library should live in MdePkg, except MdePkg only > > >>>supports architectures that are in the UEFI spec. > > PeiServerTablePointer lib is very processor depends. PI spec changes for > this is ready for review as well. > > > > >>> RiscVPkg, > > >>>This package seems to be mash up of things that possibly should be > > >>>in MdePkg, UefiCpuPkg, a chipset package, and possibly platform > packages. > > >>> > > Modules and libraries under RiscVPkg are all processor specific. Like Timer > is provided by RISC-V processor itself instead of using something
Re: [edk2] [PATCH] MdeModulePkg/DxeIplPeim: RISC-V arch DxeIpl.
On 2016-05-08 04:19:08, Chang, Abner (HPS SW/FW Technologist) wrote: > Hi Jordan, > The UEFI/PI ECR for RISC-V is ready but not yet send to UEFI for > review. I have been told to upstream RISC-V code first and then > submit the spec. I will confirm this again. You were told to upstream EDK II support before the UEFI spec documented the architecture? Or, maybe to just prepare the EDK II code so it would be ready for upstream once it is in the spec? Maybe EDK II could adopt a new idea of an "unsupported architecture", but it seems like EDK II might make some mistakes if it doesn't wait for UEFI to standardize the architecture. For example, what if the calling convention changes before it makes it into the spec? I think Jiewen's idea of edk2-staging is good. But, before that, it seems you should make another draft version of the patches in fork of EDK II on github. In a few cases, I asked if the modules could be added to more generic locations. How about trying to look over everything in a RiscV*Pkg, and ask if it could instead live in Mde*Pkg, UefiCpuPkg or OvmfPkg? (And, hopefully by maximally reusing existing modules with architecture specific sources as needed...) For example, we don't have a X64*Pkg... -Jordan > Below response to your comments, > > --- > > MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf| 6 +- > > MdeModulePkg/Core/DxeIplPeim/Riscv64/DxeLoadFunc.c | 79 > > ++ > >>>Is it Riscv64 or RiscV64? > >>>Like MdePkg, I think MdeModulePkg only upports achitectures in the UEFI > >>>spec. > > This is typo, should be RiscV64. RISC-V arch UEFI spec is ready for review. > > > > > --- > > RiscVPkg/Include/RiscV.h | 105 +++ > > .../PeiServicesTablePointer.c | 121 +++ > > .../PeiServicesTablePointerLib.inf | 46 ++ > > .../PeiServicesTablePointerLib.uni | Bin 0 -> 2520 bytes > > > >>> utf-8. (See other my other email.) > >>> > >>>I think this library should live in MdePkg, except MdePkg only > >>>supports architectures that are in the UEFI spec. > PeiServerTablePointer lib is very processor depends. PI spec changes for this > is ready for review as well. > > >>> RiscVPkg, > >>>This package seems to be mash up of things that possibly should be in > >>>MdePkg, UefiCpuPkg, a chipset package, and possibly platform packages. > >>> > Modules and libraries under RiscVPkg are all processor specific. Like Timer > is provided by RISC-V processor itself instead of using something else on > platform. ResetVector, Sec, exception and etc. are all the same. > UefiCpuPkg seems to me still not clean enough for common CPU usage. Like sec > and ResetVector, we still have to use the modules from other processor > package. So put RISC-V modules under its own package is mush clean in my > opinion for now. > > >>>What is the status of the QEMU port? > >>>I don't think we should put this upstream into EDK II until QEMU has > >>>it upstream. Maybe https://github.com/tianocore/edk2-platforms in a > >>>ovmf-riscv branch? > There is no official QEMU supports RISC-V yet. The QEMU which supports RISC-V > QEMU is on RISC-V Github. However, I have another RISC-V QEMU port for PC/AT > which uses PCI as the platform bus spec because RISC-V platform spec is not > yet ready. > The RISC-V QEMU PC/AT port is on my github. The detail is mentioned in the > readme file in RiscVVirtPkg. You also can refer to this link > https://github.com/AbnerChang/RiscVQemuPcat > > >>>What would prevent this from living under OvmfPkg? Say > >>>OvmfPkg/OvmfPkgRiscV64.dsc? > I think it should be no problem to use OvmfPkg as common processor/platform > emulator. Just you still can see few Intel things. ARM QEMU implementation > must be considered as well if we move RISC-V to OvmfPkg, thus we can have the > consistent implementation. > RISC-V QEMU implementation just follows ARM QEMU implement, that is to have a > separate package. But I agree with you that all processors/platforms emulator > should be under OvmfPkg. > > >>>This should be utf-8: > >>>BaseTools/Scripts/ConvertUni.py > I will fix this. > > I think I set the configurations when submit patches. Will figure it out. > Thanks > Abner > > -Original Message- > From: Jordan Justen [mailto:jordan.l.jus...@intel.com] > Sent: Sunday, May 08, 2016 1:53 PM > To: Chang, Abner (HPS SW/FW Technologist) <abner.ch...@hpe.com>; > edk2-devel@lists.01.org > Cc: liming@intel.com > Subject: Re: [edk2] [PATCH] Md
Re: [edk2] [PATCH] MdeModulePkg/DxeIplPeim: RISC-V arch DxeIpl.
Hi Abner I think it is great to have more arch for UEFI. Thanks for your great contribution. As you mentioned, this RISC-V seems not in public UEFI standard yet, code might be subject to change. If so, do you think it might be a better idea to check in this as staging tree, which follow EDKII staging process? You can find link here https://github.com/tianocore/edk2-staging It is still public available. And you may find 2 examples (HTTPS-TLS, Customized-Secure-Boot) there. https://github.com/tianocore/edk2-staging/branches Once RISC-V is added to UEFI spec officially, we can move support from staging tree to trunk. Thank you Yao Jiewen > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Chang, Abner (HPS SW/FW Technologist) > Sent: Sunday, May 8, 2016 7:19 PM > To: Justen, Jordan L <jordan.l.jus...@intel.com>; edk2-devel@lists.01.org > Cc: Gao, Liming <liming@intel.com> > Subject: Re: [edk2] [PATCH] MdeModulePkg/DxeIplPeim: RISC-V arch DxeIpl. > > Hi Jordan, > The UEFI/PI ECR for RISC-V is ready but not yet send to UEFI for review. I > have been told to upstream RISC-V code first and then submit the spec. I will > confirm this again. > Below response to your comments, > > --- > > MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf| 6 +- > > MdeModulePkg/Core/DxeIplPeim/Riscv64/DxeLoadFunc.c | 79 > > ++ > >>>Is it Riscv64 or RiscV64? > >>>Like MdePkg, I think MdeModulePkg only upports achitectures in the > UEFI spec. > > This is typo, should be RiscV64. RISC-V arch UEFI spec is ready for review. > > > > > --- > > RiscVPkg/Include/RiscV.h | 105 +++ > > .../PeiServicesTablePointer.c | 121 +++ > > .../PeiServicesTablePointerLib.inf | 46 ++ > > .../PeiServicesTablePointerLib.uni | Bin 0 -> 2520 > bytes > > > >>> utf-8. (See other my other email.) > >>> > >>>I think this library should live in MdePkg, except MdePkg only > >>>supports architectures that are in the UEFI spec. > PeiServerTablePointer lib is very processor depends. PI spec changes for this > is ready for review as well. > > >>> RiscVPkg, > >>>This package seems to be mash up of things that possibly should be in > >>>MdePkg, UefiCpuPkg, a chipset package, and possibly platform > packages. > >>> > Modules and libraries under RiscVPkg are all processor specific. Like Timer is > provided by RISC-V processor itself instead of using something else on > platform. ResetVector, Sec, exception and etc. are all the same. > UefiCpuPkg seems to me still not clean enough for common CPU usage. Like > sec and ResetVector, we still have to use the modules from other processor > package. So put RISC-V modules under its own package is mush clean in my > opinion for now. > > >>>What is the status of the QEMU port? > >>>I don't think we should put this upstream into EDK II until QEMU has > >>>it upstream. Maybe https://github.com/tianocore/edk2-platforms in a > >>>ovmf-riscv branch? > There is no official QEMU supports RISC-V yet. The QEMU which supports > RISC-V QEMU is on RISC-V Github. However, I have another RISC-V QEMU > port for PC/AT which uses PCI as the platform bus spec because RISC-V > platform spec is not yet ready. > The RISC-V QEMU PC/AT port is on my github. The detail is mentioned in the > readme file in RiscVVirtPkg. You also can refer to this link > https://github.com/AbnerChang/RiscVQemuPcat > > >>>What would prevent this from living under OvmfPkg? Say > >>>OvmfPkg/OvmfPkgRiscV64.dsc? > I think it should be no problem to use OvmfPkg as common > processor/platform emulator. Just you still can see few Intel things. ARM > QEMU implementation must be considered as well if we move RISC-V to > OvmfPkg, thus we can have the consistent implementation. > RISC-V QEMU implementation just follows ARM QEMU implement, that is to > have a separate package. But I agree with you that all processors/platforms > emulator should be under OvmfPkg. > > >>>This should be utf-8: > >>>BaseTools/Scripts/ConvertUni.py > I will fix this. > > I think I set the configurations when submit patches. Will figure it out. > Thanks > Abner > > -Original Message- > From: Jordan Justen [mailto:jordan.l.jus...@intel.com] > Sent: Sunday, May 08, 2016 1:53 PM > To: Chang, Abner (HPS SW/FW Technologist) <abner.ch...@hpe.com>; > edk2-devel@lists.01.org > Cc: liming@intel.com > Subject: Re: [edk2] [PATCH] MdeM
