Tianocore/edk2-platforms.git/Platform/Hisilicon/D03, branch CodeCleanup

Platform,Silicon: drop redundant uses of PcdArmArchTimerFreqInHz

2024-06-21T11:31:20+00:00

PcdArmArchTimerFreqInHz is about to be removed, as it is now obsolete. Some platforms already explicitly set it to 0, which is the default. And some modules reference it in their .inf without actually ever using it. Drop these redundant uses first. Cc: Ard Biesheuvel Cc: Chuong Tran Cc: Graeme Gregory Cc: Marcin Juszkiewicz Cc: Meenakshi Aggarwal Cc: Nhi Pham Cc: Rebecca Cran Cc: Sami Mujawar Cc: Thomas Abraham Cc: Wenyi Xie Signed-off-by: Leif Lindholm Reviewed-by: Ard Biesheuvel Reviewed-by: Nhi Pham

Hisilicon/DS3231RealTimeClockLib: remove superfluous instance init steps

2023-10-24T13:17:57+00:00

RealTimeClockLib instances are consumed by edk2's EmbeddedPkg/RealTimeClockRuntimeDxe driver. In its entry point function InitializeRealTimeClock(), the driver: (1) calls LibRtcInitialize(), (2) sets the GetTime(), SetTime(), GetWakeupTime() and SetWakeupTime() runtime services to its own similarly-named functions -- where those functions wrap the corresponding RealTimeClockLib APIs, (3) installs EFI_REAL_TIME_CLOCK_ARCH_PROTOCOL with a NULL protocol interface. Steps (2) and (3) conform to PI v1.8 sections II-9.7.2.4 through II-9.7.2.7. However, this means that LibRtcInitialize() (of any RealTimeClockLib instance) should not itself (a) set the GetTime(), SetTime(), GetWakeupTime() and SetWakeupTime() runtime services, nor (b) install EFI_REAL_TIME_CLOCK_ARCH_PROTOCOL. The runtime service pointers will be overwritten in step (2) anyway, and step (3) will uselessly install a second (NULL-interface) EFI_REAL_TIME_CLOCK_ARCH_PROTOCOL instance in the protocol database. (The protocol only serves to notify the DXE Foundation about said runtime services being available.) Clean up Hisilicon/DS3231RealTimeClockLib accordingly. (Note that the lib instance INF file already does not list UefiBootServicesTableLib, UefiRuntimeServicesTableLib, and gEfiRealTimeClockArchProtocolGuid.) Build-tested only (with the D03 and D05 platforms). Cc: Ard Biesheuvel Cc: Leif Lindholm Cc: Wenyi Xie Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4565 Signed-off-by: Laszlo Ersek Message-Id: <20231020121903.44986-2-lersek@redhat.com> Acked-by: Ard Biesheuvel

Hisilicon/DS3231RealTimeClockLib: drop LibRtcVirtualNotifyEvent

2023-10-13T10:11:29+00:00

The RealTimeClockLib class header in edk2 mistakenly declares a function called LibRtcVirtualNotifyEvent(). No component ever calls this function crossing module boundaries; all RealTimeClockLib instances in edk2 and edk2-platforms are supposed to register (and do register) their SetVirtualAddressMap() notification functions. In particular, DS3231RealTimeClockLib *itself* doesn't even use LibRtcVirtualNotifyEvent() -- the function is defined with an empty body, clearly in an understandable, but misguided, attempt, to conform to the (bogus) library interface. Remove the function. Build-tested only (with the Hisilicon platforms). Cc: Leif Lindholm Cc: Wenyi Xie Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4564 Signed-off-by: Laszlo Ersek Reviewed-by: Ard Biesheuvel

Hisilicon: rename OemMiscLib class to HisiOemMiscLib

2023-10-13T10:11:01+00:00

Edk2 commit [1] introduced the library class header to ArmPkg; commit [2] introduced the first OemMiscLib instance to ArmPkg; and commit [3] introduced (retroactively) the library class itself to ArmPkg. Alas, when all these edk2 commits were made, edk2-platforms already had a (Hisilicon-specific) library class called OemMiscLib -- and many of the Hisilicon modules would use both "HisiPkg.dec" and "ArmPkg.dec". Therefore the edk2 OemMiscLib brought about a library class conflict, breaking both edk2-platforms and edk2-non-osi content. Rename the original OemMiscLib class to HisiOemMiscLib, and update all references. This patch is necessary for building the D03, D05, D06, HiKey, and HiKey960 platforms. [1] 2c7c64fc04a0 ("ArmPkg: Add Library/OemMiscLib.h", 2021-02-08) [2] 0e51d7e445e0 ("ArmPkg: Add Universal/Smbios/OemMiscLibNull", 2021-02-08) [3] d03f71dd8be6 ("ArmPkg: Add missing library headers to ArmPkg.dec", 2021-04-28) Cc: Leif Lindholm Cc: Wenyi Xie Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4564 Signed-off-by: Laszlo Ersek Reviewed-by: Ard Biesheuvel

Hisilicon: enable NOOPT builds

2023-10-13T10:10:16+00:00

There's no reason for not supporting NOOPT in the Hisilicon platform DSCs, and there is a reason for supporting them: build-only testing. Add NOOPT wherever it's missing, and stick to a consistent order wherever NOOPT already exists. Cc: Leif Lindholm Cc: Wenyi Xie Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4564 Signed-off-by: Laszlo Ersek Reviewed-by: Ard Biesheuvel

Platform/Hisilicon: Use PcdPciIoTranslation PCD from MdePkg

2021-10-14T04:10:08+00:00

Compliant with BZ: #3665 https://bugzilla.tianocore.org/show_bug.cgi?id=3665 PcdPciIoTranslation PCD is relocated to MdePkg that leveraged by both ARM and RISC-V arch. This patch uses the one from MdePkg instead the one under ArmVirtPkg. Signed-off-by: Abner Chang Cc: Leif Lindholm Cc: Ard Biesheuvel Cc: Wenyi Xie Cc: Daniel Schaefer Acked-by: Leif Lindholm

Platform/Hisilicon: Consume MdeLibs.dsc.inc for RegisterFilterLib

2021-03-31T06:20:15+00:00

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3246 MdeLibs.dsc.inc was added for some basic/default library instances provided by MdePkg and RegisterFilterLibNull Library was also added into it as the first version of MdeLibs.dsc.inc. So update platform dsc to consume MdeLibs.dsc.inc for RegisterFilterLibNull which will be consumed by IoLib and BaseLib. Cc: Leif Lindholm Cc: Ard Biesheuvel Cc: Wenyi Xie Signed-off-by: Dandan Bi Reviewed-by: Michael D Kinney

ARM Silicon and Platforms: add OrderedCollectionLib class resolution

2021-01-18T08:12:06+00:00

The edk2 patch ShellPkg/ShellCommandLib: add ShellSortFileList for BZ#3151 will make the ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.inf instance dependent on the OrderedCollectionLib class. Because the shell binaries in the ARM silicon and platform DSCs consume the above UefiShellCommandLib instance, resolve the OrderedCollectionLib class in them. Cc: Ard Biesheuvel Cc: Leif Lindholm Cc: Marcin Wojtas Cc: Meenakshi Aggarwal Cc: Philippe Mathieu-Daudé Cc: Thomas Abraham Cc: Wenyi Xie Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3151 Signed-off-by: Laszlo Ersek Message-Id: <20210113082843.9095-3-lersek@redhat.com> Acked-by: Ard Biesheuvel Acked-by: Ard Biesheuvel Acked-by: Leif Lindholm Reviewed-by: Philippe Mathieu-Daudé Reviewed-by: Marcin Wojtas

Hisilicon: Convert UNI files from UTF-16 to UTF-8

2019-10-03T22:04:07+00:00

https://bugzilla.tianocore.org/show_bug.cgi?id=2199 Cc: Ard Biesheuvel Cc: Leif Lindholm Signed-off-by: Michael D Kinney Acked-by: Ard Biesheuvel

Hisilicon/D0x: Use StatusCode Router & Handler in MdeModulePkg

2019-06-12T00:19:01+00:00

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1800 This commit adopts a similar approach to edk2 commit a6d594c5fabd8da2273d2794826ec086cf9c3c04. Currently, Hisilicon platforms use modules from under "IntelFrameworkModulePkg/Universal/StatusCode/", which produce EFI_PEI_PROGRESS_CODE_PPI and EFI_STATUS_CODE_PROTOCOL directly, and write the status codes, as they are reported, to the serial port or to a memory buffer. This is called "handling" the status codes. MdeModulePkg offers a PEIM under "MdeModulePkg/Universal/ReportStatusCodeRouter/Pei" that produces both EFI_PEI_PROGRESS_CODE_PPI and EFI_PEI_RSC_HANDLER_PPI, and a runtime DXE driver under "MdeModulePkg/Universal/ReportStatusCodeRouter/RuntimeDxe" that produces both EFI_STATUS_CODE_PROTOCOL and EFI_RSC_HANDLER_PROTOCOL. MdeModulePkg also offers status code handler modules under MdeModulePkg/Universal/StatusCodeHandler/ that depend on EFI_PEI_RSC_HANDLER_PPI and EFI_RSC_HANDLER_PROTOCOL, respectively. The StatusCodeHandler modules register themselves with ReportStatusCodeRouter through EFI_PEI_RSC_HANDLER_PPI / EFI_RSC_HANDLER_PROTOCOL. When another module reports a status code through EFI_PEI_PROGRESS_CODE_PPI / EFI_STATUS_CODE_PROTOCOL, it reaches the phase-matching ReportStatusCodeRouter module first, which in turn passes the status code to the pre-registered, phase-matching StatusCodeHandler module. The status code handling in the StatusCodeHandler modules is identical to the one currently provided by the IntelFrameworkModulePkg modules. Replace the IntelFrameworkModulePkg modules with the MdeModulePkg ones, so we can decrease our dependency on IntelFrameworkModulePkg. OS boot verified by Ming Huang : https://edk2.groups.io/g/devel/message/41419 Cc: Ard Biesheuvel Cc: Michael D Kinney Signed-off-by: Hao A Wu Acked-by: Leif Lindholm