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
