> 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 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 >>>> +++ >>>>>>>> .../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] MdeModulePkg/DxeIplPeim: RISC-V >>>>>>> arch >>>>>> DxeIpl. >>>>>>> >>>>>>> On 2016-05-07 21:23:36, Abner Chang wrote: >>>>>>>> From: AbnerChang <abner.ch...@hpe.com> >>>>>>>> >>>>>>> >>>>>>> git config settings. :) >>>>>>> >>>>>>>> The implementation of RISC-V DxeIpl. >>>>>>>> >>>>>>>> Contributed-under: TianoCore Contribution Agreement 1.0 >>>>>>>> Signed-off-by: Abner Chang<abner.ch...@hpe.com> >>>>>>> >>>>>>> space before < >>>>>>> >>>>>>>> --- >>>>>>>> MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf | 6 +- >>>>>>>> MdeModulePkg/Core/DxeIplPeim/Riscv64/DxeLoadFunc.c | 79 >>>>>>>> ++++++++++++++++++++++ >>>>>>> >>>>>>> Is it Riscv64 or RiscV64? >>>>>>> >>>>>>> Like MdePkg, I think MdeModulePkg only supports achitectures >>>>>>> in the >>>> UEFI >>>>>> spec. >>>>>>> >>>>>>> -Jordan >>>>>>> >>>>>>>> 2 files changed, 84 insertions(+), 1 deletion(-) create >>>>>>>> mode >>>>>>>> 100644 MdeModulePkg/Core/DxeIplPeim/Riscv64/DxeLoadFunc.c >>>>>>>> >>>>>>>> diff --git a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf >>>>>>>> b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf >>>>>>>> index 04ad928..13c0852 100644 >>>>>>>> --- a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf >>>>>>>> +++ b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf >>>>>>>> @@ -6,6 +6,7 @@ >>>>>>>> # needed to run the DXE Foundation. >>>>>>>> # >>>>>>>> # Copyright (c) 2006 - 2015, Intel Corporation. All rights >>>>>>>> reserved.<BR> >>>>>>>> +# Copyright (c) 2016, Hewlett Packard Enterprise Development >> LP. >>>>>>>> +All rights reserved.<BR> >>>>>>>> # This program and the accompanying materials # are >>>> licensed >>>>>> and >>>>>>>> made available under the terms and conditions of the BSD >>>>>>>> License # which accompanies this distribution. The full >>>>>>>> text of the license may be found at @@ -29,7 +30,7 @@ # # >>>>>>>> The following >>>> information >>>>>> is >>>>>>>> for reference only and not required by the build tools. >>>>>>>> # >>>>>>>> -# VALID_ARCHITECTURES = IA32 X64 IPF EBC (EBC is >>>> for >>>>>> build only) AARCH64 >>>>>>>> +# VALID_ARCHITECTURES = IA32 X64 IPF EBC (EBC is >>>> for >>>>>> build only) AARCH64 RISCV64 >>>>>>>> # >>>>>>>> >>>>>>>> [Sources] >>>>>>>> @@ -57,6 +58,9 @@ >>>>>>>> [Sources.ARM, Sources.AARCH64] >>>>>>>> Arm/DxeLoadFunc.c >>>>>>>> >>>>>>>> +[Sources.RISCV64] >>>>>>>> + Riscv64/DxeLoadFunc.c >>>>>>>> + >>>>>>>> [Packages] >>>>>>>> MdePkg/MdePkg.dec >>>>>>>> MdeModulePkg/MdeModulePkg.dec diff --git >>>>>>>> a/MdeModulePkg/Core/DxeIplPeim/Riscv64/DxeLoadFunc.c >>>>>>>> b/MdeModulePkg/Core/DxeIplPeim/Riscv64/DxeLoadFunc.c >>>>>>>> new file mode 100644 >>>>>>>> index 0000000..6b42e44 >>>>>>>> --- /dev/null >>>>>>>> +++ b/MdeModulePkg/Core/DxeIplPeim/Riscv64/DxeLoadFunc.c >>>>>>>> @@ -0,0 +1,79 @@ >>>>>>>> +/** @file >>>>>>>> + RISC-V specific functionality for DxeLoad. >>>>>>>> + >>>>>>>> + Copyright (c) 2016, Hewlett Packard Enterprise Development LP. >>>>>>>> + All rights reserved.<BR> >>>>>>>> + >>>>>>>> + This program and the accompanying materials are licensed >>>>>>>> + and made available under the terms and conditions of the >>>>>>>> + BSD License which accompanies this distribution. The full >>>>>>>> + text of the license may be found at >>>>>>>> + http://opensource.org/licenses/bsd-license.php >>>>>>>> + >>>>>>>> + THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN >>>> "AS >>>>>> IS" >>>>>>>> +BASIS, >>>>>>>> + WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, >>>> EITHER >>>>>> EXPRESS OR IMPLIED. >>>>>>>> +**/ >>>>>>>> + >>>>>>>> +#include "DxeIpl.h" >>>>>>>> + >>>>>>>> +typedef >>>>>>>> +VOID* >>>>>>>> +(EFIAPI *DXEENTRYPOINT) ( >>>>>>>> + IN VOID *HobStart >>>>>>>> + ); >>>>>>>> + >>>>>>>> +/** >>>>>>>> + Transfers control to DxeCore. >>>>>>>> + >>>>>>>> + This function performs a CPU architecture specific >>>>>>>> + operations to >>>>>> execute >>>>>>>> + the entry point of DxeCore with the parameters of HobList. >>>>>>>> + It also installs EFI_END_OF_PEI_PPI to signal the end of >>>>>>>> + PEI >>>> phase. >>>>>>>> + >>>>>>>> + @param DxeCoreEntryPoint The entry point of >>>> DxeCore. >>>>>>>> + @param HobList The start of HobList >>>> passed >>>>>> to DxeCore. >>>>>>>> + >>>>>>>> +**/ >>>>>>>> +VOID >>>>>>>> +HandOffToDxeCore ( >>>>>>>> + IN EFI_PHYSICAL_ADDRESS DxeCoreEntryPoint, >>>>>>>> + IN EFI_PEI_HOB_POINTERS HobList >>>>>>>> + ) >>>>>>>> +{ >>>>>>>> + VOID *BaseOfStack; >>>>>>>> + VOID *TopOfStack; >>>>>>>> + EFI_STATUS Status; >>>>>>>> + // >>>>>>>> + // >>>>>>>> + // Allocate 128KB for the Stack >>>>>>>> + // >>>>>>>> + BaseOfStack = AllocatePages (EFI_SIZE_TO_PAGES >>>>>>>> +(STACK_SIZE)); >>>>>>>> + ASSERT (BaseOfStack != NULL); >>>>>>>> + >>>>>>>> + // >>>>>>>> + // Compute the top of the stack we were allocated. >>>>>>>> + Pre-allocate a UINTN // for safety. >>>>>>>> + // >>>>>>>> + TopOfStack = (VOID *) ((UINTN) BaseOfStack + >>>> EFI_SIZE_TO_PAGES >>>>>>>> + (STACK_SIZE) * EFI_PAGE_SIZE - CPU_STACK_ALIGNMENT); >>>>>> TopOfStack = >>>>>>>> + ALIGN_POINTER (TopOfStack, CPU_STACK_ALIGNMENT); >>>>>>>> + >>>>>>>> + // >>>>>>>> + // End of PEI phase signal // Status = >>>>>>>> + PeiServicesInstallPpi (&gEndOfPeiSignalPpi); >>>>>>>> + ASSERT_EFI_ERROR (Status); >>>>>>>> + >>>>>>>> + // >>>>>>>> + // Update the contents of BSP stack HOB to reflect the >>>>>>>> + real stack >>>> info >>>>>> passed to DxeCore. >>>>>>>> + // >>>>>>>> + UpdateStackHob ((EFI_PHYSICAL_ADDRESS)(UINTN) >>>>>>>> + BaseOfStack, STACK_SIZE); >>>>>>>> + >>>>>>>> + DEBUG ((EFI_D_INFO, "DXE Core new stack at %x, stack >>>>>>>> + pointer >>>> at >>>>>>>> + %x\n", BaseOfStack, TopOfStack)); >>>>>>>> + >>>>>>>> + // >>>>>>>> + // Transfer the control to the entry point of DxeCore. >>>>>>>> + // >>>>>>>> + SwitchStack ( >>>>>>>> + (SWITCH_STACK_ENTRY_POINT)(UINTN)DxeCoreEntryPoint, >>>>>>>> + HobList.Raw, >>>>>>>> + NULL, >>>>>>>> + TopOfStack >>>>>>>> + ); >>>>>>>> +} >>>>>>>> -- >>>>>>>> 1.9.5.msysgit.0 >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> edk2-devel mailing list >>>>>>>> edk2-devel@lists.01.org >>>>>>>> https://lists.01.org/mailman/listinfo/edk2-devel >>>>>>> _______________________________________________ >>>>>>> edk2-devel mailing list >>>>>>> edk2-devel@lists.01.org >>>>>>> https://lists.01.org/mailman/listinfo/edk2-devel >>>>>> _______________________________________________ >>>>>> edk2-devel mailing list >>>>>> edk2-devel@lists.01.org >>>>>> https://lists.01.org/mailman/listinfo/edk2-devel >> _______________________________________________ >> edk2-devel mailing list >> edk2-devel@lists.01.org >> https://lists.01.org/mailman/listinfo/edk2-devel > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
