UefiPayloadPkg: Add AARCH64 support #6545

AjanZhong · 2024-12-17T07:27:44Z

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4849

Description

Add base FIT image support on the AARCH64 architecture, introduce new dsc and fdf files for AARCH64 architecture, and introduce new PCD: PcdUseUniversalPayloadSerialPort to indicate which serial port component is used due to some serial port parameters are fixed for ARM SoC and Platform.

Breaking change?
- N/A
Impacts security?
- N/A
Includes tests?
- N/A

How This Was Tested

Validated on top of qemu-system-x86_64 and qemu-system-aarch64.

Integration Instructions

export GCC5_AARCH64_PREFIX=aarch64-linux-gnu-
python UefiPayloadPkg/UniversalPayloadBuild.py -a AARCH64 -t GCC5 -b DEBUG --Fit

mergify · 2024-12-19T04:44:01Z

PR can not be merged due to conflict. Please rebase and resubmit

UefiPayloadPkg/Library/PlatformHookLib/PlatformHookLib.c

AjanZhong · 2024-12-22T07:16:19Z

@leiflindholm @benjamindoron This PR (6545) is created to address comments in PR 6339, using existing DSC/FDF to build UPL for both X64 and AARCH64 architectures. I have built X64 and AARCH64 separately by command: "build -a X64" and "build -a AARCh64" successfully.

However, CI check will build X64, AARCh64 at one build by command "build -a X64 -a AARCH64". This is CI check, for instance module BdsDXE will be built for both X64/AARCH64, then trigger this error:
"Module built under multiple ARCHs ['AARCH64', 'X64']. Not able to determine which output to put into flash for Module MdeModulePkg/Universal/BdsDxe/BdsDxe.inf."

Any suggestion to fix this issue?

leiflindholm · 2025-01-07T15:14:24Z

@leiflindholm @benjamindoron This PR (6545) is created to address comments in PR 6339, using existing DSC/FDF to build UPL for both X64 and AARCH64 architectures. I have built X64 and AARCH64 separately by command: "build -a X64" and "build -a AARCh64" successfully.

However, CI check will build X64, AARCh64 at one build by command "build -a X64 -a AARCH64". This is CI check, for instance module BdsDXE will be built for both X64/AARCH64, then trigger this error: "Module built under multiple ARCHs ['AARCH64', 'X64']. Not able to determine which output to put into flash for Module MdeModulePkg/Universal/BdsDxe/BdsDxe.inf."

Any suggestion to fix this issue?

That's the same issue I ran into with #6262, and a good solution was not obvious to me.
It also showed me that I had misunderstood how the ARCH variable is populated when expanded in the .dsc.

And I still haven't thought of an appealing workaround for it. Let me fire off an email to the mailing list on that topic.

leiflindholm · 2025-01-07T15:48:54Z

That's the same issue I ran into with #6262, and a good solution was not obvious to me. It also showed me that I had misunderstood how the ARCH variable is populated when expanded in the .dsc.

OK, not the same issue - related to that issue.

AjanZhong · 2025-01-08T07:17:12Z

That's the same issue I ran into with #6262, and a good solution was not obvious to me. It also showed me that I had misunderstood how the ARCH variable is populated when expanded in the .dsc.

OK, not the same issue - related to that issue.

Thanks @leiflindholm, you provided a constructive suggestion. :)

As you suggested, I used following content to passed all build:
[Defines.IA32]
OUTPUT_DIRECTORY = Build/UefiPayloadPkgIA32
FLASH_DEFINITION = UefiPayloadPkg/UefiPayloadPkg.fdf
[Defines.X64]
OUTPUT_DIRECTORY = Build/UefiPayloadPkgX64
FLASH_DEFINITION = UefiPayloadPkg/UefiPayloadPkg.fdf
[Defines.AARCH64]
OUTPUT_DIRECTORY = Build/UefiPayloadPkgAARCH64
FLASH_DEFINITION = UefiPayloadPkg/UefiPayloadPkg.fdf

I have tried following build commands, they all succeed to build corresponding binaries:

build -p UefiPayloadPkg/UefiPayloadPkg.dsc -b DEBUG -a IA32 -a X64 -a AARCH64 -t GCC5
python UefiPayloadPkg/UniversalPayloadBuild.py -t GCC5 -b DEBUG --FIT
python UefiPayloadPkg/UniversalPayloadBuild.py -t GCC5 -a IA32 -b DEBUG --FIT
python UefiPayloadPkg/UniversalPayloadBuild.py -t GCC5 -a AARCH -b DEBUG --FIT

Let's wait for github CI result.

AjanZhong · 2025-01-08T12:58:52Z

That's the same issue I ran into with #6262, and a good solution was not obvious to me. It also showed me that I had misunderstood how the ARCH variable is populated when expanded in the .dsc.

OK, not the same issue - related to that issue.

Thanks @leiflindholm, you provided a constructive suggestion. :)

As you suggested, I used following content to passed all build: [Defines.IA32] OUTPUT_DIRECTORY = Build/UefiPayloadPkgIA32 FLASH_DEFINITION = UefiPayloadPkg/UefiPayloadPkg.fdf [Defines.X64] OUTPUT_DIRECTORY = Build/UefiPayloadPkgX64 FLASH_DEFINITION = UefiPayloadPkg/UefiPayloadPkg.fdf [Defines.AARCH64] OUTPUT_DIRECTORY = Build/UefiPayloadPkgAARCH64 FLASH_DEFINITION = UefiPayloadPkg/UefiPayloadPkg.fdf

I have tried following build commands, they all succeed to build corresponding binaries:

build -p UefiPayloadPkg/UefiPayloadPkg.dsc -b DEBUG -a IA32 -a X64 -a AARCH64 -t GCC5

python UefiPayloadPkg/UniversalPayloadBuild.py -t GCC5 -b DEBUG --FIT

python UefiPayloadPkg/UniversalPayloadBuild.py -t GCC5 -a IA32 -b DEBUG --FIT

python UefiPayloadPkg/UniversalPayloadBuild.py -t GCC5 -a AARCH -b DEBUG --FIT

Let's wait for github CI result.

FLASH_DEFINITION does not take effort, since FV is not generated for each architecture.

Add basic support for FIT image on the AARCH64 architecture, reuse exsitting DSC and FDF files for IA32, X64 and AARCH64 architectures. Introduce new PCD: PcdUseUniversalPayloadSerialPort to indicate which serial port module is used due to some serial port parameters are fixed for ARM SoC and Platform. Please use following command to build AARCH64 UPL FIT image: " export GCC5_AARCH64_PREFIX=aarch64-linux-gnu- python UefiPayloadPkg/UniversalPayloadBuild.py -a AARCH64 -t GCC5 -b DEBUG --Fit " Signed-off-by: Amos Bu <[email protected]> Signed-off-by: Ajan Zhong <[email protected]>

AARCH64 CpuDxe takes charge of constructing Translation Tables with memory map information provided by bootloader, and enabling MMU, setting EOImode to perform both priority drop and deactivation. Signed-off-by: Ajan Zhong <[email protected]>

Enable CpuDxeAArch64 in UefiPayloadPkg for AARCH64 architecture. Signed-off-by: Ajan Zhong <[email protected]>

Azure Ubuntu GCC5 pipeline builds packages with all architectures. However, UefiPayloadPkg supports multiple architectures, including IA32, X64 and AARCH64. In this case, Azure pipeline builds modules for IA32, X64 and AARCH64 architectures, generates FD with same FDF file. It leads build system failed to locate which module should be integrated into Flash image. Add Build.Archlist to specify architectures to be build with, and separate TARGET_UEFIPAYLOAD to TARGET_UEFIPAYLOAD_IA32_X64 and TARGET_UEFIPAYLOAD_AARCH64 to cover all supported architectures for UefiPayloadPkg package. Signed-off-by: Ajan Zhong <[email protected]>

tianocore-assign-reviewers · 2025-01-09T13:30:57Z

⚠ WARNING: Cannot add some reviewers: A user specified as a reviewer for this PR is not a collaborator of the repository. Please add them as a collaborator to the repository so they can be requested in the future.

Non-collaborators requested:

@Javagedes

Attn Admins:

Admin Instructions:

Add the non-collaborators as collaborators to the appropriate team(s) listed in teams
If they are no longer needed as reviewers, remove them from Maintainers.txt

leiflindholm · 2025-01-09T13:47:20Z

UefiCpuPkg/CpuDxeAArch64/ArmCacheMaintenanceLib.c

@@ -0,0 +1,149 @@
+/** @file


This commit (which github does not let me comment on directly as a whole) seems to pull in source code from multiple existing libraries into this new CpuDxeAArch64.
I would very much like to avoid that if possible.

Is this in order to not have dependencies on the ArmPkg versions?
If so, I'd rather take this opportunity to chip away a bit further on #10289

Yes, you are right. ArmPkg cannot be used in UefiCpuPkg, so I porting required methods from ArmPkg.
About removing ArmPkg, how about let us do it in coming commits which focus on #10289, since we will have other modules which resides in ArmPkg. If we do it (remove ArmPkg) in this PR, we need plenty of effort for porting, validation.

There is no porting or validation needed - it would just be moving of code.

Meanwhile, duplicating existing architectural operations would absolutely not be acceptable.

We did a partway thing recently - f2b9d54. I think we should do the similar thing here. But don't fret about it being invasive - it's just mechanics.

leiflindholm · 2025-01-09T13:57:45Z

UefiPayloadPkg/UefiPayloadEntry/AArch64/DxeHandoff.c

+  SPDX-License-Identifier: BSD-2-Clause-Patent
+**/
+
+#include <PiPei.h>


This file seems to be a copy of MdeModulePkg/Core/DxeIplPeim/DxeHandoff.c, with mainly the if (PcdGetBool (PcdSetNxForStack)) { part removed.
I'm guessing UefiPayloadPkg effectively replaces DxeIpl, but is there a particular reason for why this needs to become architecture-specific?
(This does not need resolving now, but I would like to understand.)

Good question. This file is introduced here to keep architecture design logic unchanged, since UefiPayloadEntry has already introduced Ia32/RiscV64/X64. This commit is used to keep UefiPayloadEntry module design philosophy unchanged.

leiflindholm · 2025-01-09T14:02:15Z

UefiPayloadPkg/UefiPayloadEntry/AArch64/SupportLib.c

+  VOID
+  )
+{
+  return 44;


No :)
(Setting aside previous comment about ArmPkg, this should be a call that ends up in
Library/ArmLib/AArch64/ArmLibSupport.S:ASM_FUNC(ArmGetPhysicalAddressBits)
If we need to create a wrapper function to export that, we can absolutely do that.

No :) (Setting aside previous comment about ArmPkg, this should be a call that ends up in Library/ArmLib/AArch64/ArmLibSupport.S:ASM_FUNC(ArmGetPhysicalAddressBits) If we need to create a wrapper function to export that, we can absolutely do that.

Sure, let will refine in.

leiflindholm · 2025-01-09T14:04:33Z

UefiPayloadPkg/UefiPayloadEntry/Ia32/SupportLib.c

@@ -0,0 +1,25 @@
+/** @file


It would be a lot cleaner to break this change, and the corresonding ones in UefiPayloadEntry.c and UefiPayloadEntry.h, out into a separate commit.

Sure, I will create a new commit (something like 'introduce GetPhyAddrBit to adapt multiple architectures') in this PR for Ia32 and X64.

leiflindholm · 2025-01-09T14:05:16Z

UefiPayloadPkg/UefiPayloadEntry/X64/SupportLib.c

@@ -0,0 +1,25 @@
+/** @file


...and merge this change with the Ia32 one.

Get you, let me introduce a new commit to fix it for both Ia32 and X64

leiflindholm · 2025-01-09T14:06:45Z

That's me done commenting - I'll leave someone else to comment on the CI aspect, but thank you very much for this rework. It greatly simplified reviewing.

AjanZhong force-pushed the upstream-arm64 branch 7 times, most recently from 01d072a to f06afd7 Compare December 19, 2024 04:43

AjanZhong force-pushed the upstream-arm64 branch 5 times, most recently from 75210b2 to c9a715a Compare December 19, 2024 12:07

AjanZhong changed the title ~~UefiPayloadPkg/UefiCpuPkg: Add AARCH64 support~~ UefiPayloadPkg: Add AARCH64 support Dec 20, 2024

AjanZhong marked this pull request as ready for review December 20, 2024 09:29

tianocore-assign-reviewers bot requested review from ardbiesheuvel, benjamindoron, gdong1, gguo11837463, jameslu8, leiflindholm, LinusvPelt, samimujawar and Sean-StarLabs December 20, 2024 09:46

LinusvPelt reviewed Dec 20, 2024

View reviewed changes

UefiPayloadPkg/Library/PlatformHookLib/PlatformHookLib.c Show resolved Hide resolved

AjanZhong force-pushed the upstream-arm64 branch 5 times, most recently from a505283 to b52c670 Compare December 20, 2024 14:01

AjanZhong reopened this Dec 22, 2024

AjanZhong force-pushed the upstream-arm64 branch from 13bc27f to 15d6e39 Compare December 22, 2024 13:00

tianocore-assign-reviewers bot requested review from jiaxinwu, kraxel, LiuZhiguang001, niruiyu, rahul1-kumar and td36 December 22, 2024 13:29

AjanZhong force-pushed the upstream-arm64 branch from c2e331e to 15d6e39 Compare December 23, 2024 03:17

AjanZhong force-pushed the upstream-arm64 branch from 666c68b to 5263c81 Compare January 8, 2025 07:11

amosbu and others added 4 commits January 9, 2025 18:42

UefiCpuPkg: Add AARCH64 support

5a92a60

AARCH64 CpuDxe takes charge of constructing Translation Tables with memory map information provided by bootloader, and enabling MMU, setting EOImode to perform both priority drop and deactivation. Signed-off-by: Ajan Zhong <[email protected]>

UefiPayloadPkg: Enable CpuDxeAArch64 DXE driver

05b28f3

Enable CpuDxeAArch64 in UefiPayloadPkg for AARCH64 architecture. Signed-off-by: Ajan Zhong <[email protected]>

AjanZhong force-pushed the upstream-arm64 branch from 5263c81 to fa0e801 Compare January 9, 2025 13:30

tianocore-assign-reviewers bot requested review from lgao4, mdkinney and spbrogan January 9, 2025 13:30

leiflindholm reviewed Jan 9, 2025

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

UefiPayloadPkg: Add AARCH64 support #6545

UefiPayloadPkg: Add AARCH64 support #6545

AjanZhong commented Dec 17, 2024 •

edited

Loading

mergify bot commented Dec 19, 2024

AjanZhong commented Dec 22, 2024 •

edited

Loading

leiflindholm commented Jan 7, 2025

leiflindholm commented Jan 7, 2025

AjanZhong commented Jan 8, 2025

AjanZhong commented Jan 8, 2025 •

edited

Loading

tianocore-assign-reviewers bot commented Jan 9, 2025

leiflindholm Jan 9, 2025

AjanZhong Jan 10, 2025

leiflindholm Jan 11, 2025

leiflindholm Jan 9, 2025

AjanZhong Jan 10, 2025

leiflindholm Jan 9, 2025

AjanZhong Jan 10, 2025

leiflindholm Jan 9, 2025

AjanZhong Jan 10, 2025

leiflindholm Jan 9, 2025

AjanZhong Jan 10, 2025

leiflindholm commented Jan 9, 2025

UefiPayloadPkg: Add AARCH64 support #6545

Are you sure you want to change the base?

UefiPayloadPkg: Add AARCH64 support #6545

Conversation

AjanZhong commented Dec 17, 2024 • edited Loading

Description

How This Was Tested

Integration Instructions

mergify bot commented Dec 19, 2024

AjanZhong commented Dec 22, 2024 • edited Loading

leiflindholm commented Jan 7, 2025

leiflindholm commented Jan 7, 2025

AjanZhong commented Jan 8, 2025

AjanZhong commented Jan 8, 2025 • edited Loading

tianocore-assign-reviewers bot commented Jan 9, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

leiflindholm commented Jan 9, 2025

AjanZhong commented Dec 17, 2024 •

edited

Loading

AjanZhong commented Dec 22, 2024 •

edited

Loading

AjanZhong commented Jan 8, 2025 •

edited

Loading