Yes. It makes sense. I will create a RISC-V platform for these modules. Thanks Abner
-----Original Message----- From: Yao, Jiewen [mailto:[email protected]] Sent: Monday, May 09, 2016 11:12 PM To: Chang, Abner (HPS SW/FW Technologist) <[email protected]>; Justen, Jordan L <[email protected]>; [email protected] Cc: Gao, Liming <[email protected]> Subject: 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:[email protected]] On Behalf Of > Chang, Abner (HPS SW/FW Technologist) > Sent: Monday, May 9, 2016 10:10 PM > To: Justen, Jordan L <[email protected]>; > [email protected] > Cc: Yao, Jiewen <[email protected]>; Gao, Liming > <[email protected]> > 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:[email protected]] > Sent: Monday, May 09, 2016 2:25 PM > To: Chang, Abner (HPS SW/FW Technologist) <[email protected]>; > [email protected] > Cc: [email protected]; Yao, Jiewen <[email protected]> > 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:[email protected]] > > Sent: Sunday, May 08, 2016 1:53 PM > > To: Chang, Abner (HPS SW/FW Technologist) <[email protected]>; > > [email protected] > > Cc: [email protected] > > Subject: Re: [edk2] [PATCH] MdeModulePkg/DxeIplPeim: RISC-V arch > DxeIpl. > > > > On 2016-05-07 21:23:36, Abner Chang wrote: > > > From: AbnerChang <[email protected]> > > > > > > > git config settings. :) > > > > > The implementation of RISC-V DxeIpl. > > > > > > Contributed-under: TianoCore Contribution Agreement 1.0 > > > Signed-off-by: Abner Chang<[email protected]> > > > > 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 > > > [email protected] > > > https://lists.01.org/mailman/listinfo/edk2-devel > > _______________________________________________ > > edk2-devel mailing list > > [email protected] > > https://lists.01.org/mailman/listinfo/edk2-devel > _______________________________________________ > edk2-devel mailing list > [email protected] > https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
