Add AArch64 UEFI support (NVIDIA Jetson Orin)#818
Draft
dgarske wants to merge 1 commit into
Draft
Conversation
Contributor
There was a problem hiding this comment.
Pull request overview
This pull request adds a new aarch64_efi target so wolfBoot can run as an AArch64 UEFI application (validated on NVIDIA Jetson Orin), loading/verifying kernel.img/update.img from the ESP and booting via UEFI LoadImage/StartImage.
Changes:
- Add a new AArch64 UEFI HAL (
hal/aarch64_efi.c) plus boot glue (src/boot_aarch64_efi.c) and linker-script stub. - Extend the build system to support an AArch64 PE/COFF
wolfboot.efioutput and a new example config. - Add helper scripts and documentation for building gnu-efi for AArch64 and running under QEMU/Jetson deployment.
Reviewed changes
Copilot reviewed 10 out of 11 changed files in this pull request and generated 6 comments.
Show a summary per file
| File | Description |
|---|---|
| tools/scripts/build-gnu-efi-aarch64.sh | Helper to clone/build/install gnu-efi (AArch64) into the repo tree |
| tools/scripts/aarch64-efi-qemu.sh | Convenience runner for wolfboot.efi under QEMU + AAVMF |
| tools/keytools/keygen.c | Extends keystore section handling for the new UEFI target macro |
| src/boot_aarch64_efi.c | Adds UEFI-target do_boot() glue for AArch64 |
| Makefile | Makes the wolfboot.efi objcopy output format configurable per target |
| hal/aarch64_efi.ld | Empty placeholder linker script (gnu-efi script used instead) |
| hal/aarch64_efi.c | New AArch64 UEFI HAL: ESP file loading, verification, LoadImage/StartImage handoff |
| docs/Targets.md | Adds aarch64_efi target documentation (Jetson Orin + QEMU workflow) |
| config/examples/aarch64_efi.config | Example configuration for aarch64_efi |
| arch.mk | Adds aarch64_efi target build flags, gnu-efi paths, and linking rules |
| .gitignore | Ignores gnu-efi build artifacts and staging dirs for the new target |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Comment on lines
+119
to
+120
| uint32_t *size; | ||
| uint8_t* manifest = ((uint8_t*)boot_addr) - IMAGE_HEADER_SIZE; |
Comment on lines
+127
to
+133
| size = (uint32_t *)(manifest + 4); | ||
|
|
||
| mem_path_device->Header.Type = EFI_DEVICE_PATH_PROTOCOL_HW_TYPE; | ||
| mem_path_device->Header.SubType = EFI_DEVICE_PATH_PROTOCOL_MEM_SUBTYPE; | ||
| mem_path_device->MemoryType = EfiLoaderData; | ||
| mem_path_device->StartingAddress = (EFI_PHYSICAL_ADDRESS)boot_addr; | ||
| mem_path_device->EndingAddress = (EFI_PHYSICAL_ADDRESS)((uint8_t*)boot_addr+*size); |
Comment on lines
+251
to
+252
| *sz = FileSize(file); | ||
| wolfBoot_printf("Opening file: %s, size: %u\n", filename, *sz); |
Comment on lines
+74
to
+77
| int RAMFUNCTION hal_flash_write(uintptr_t address, const uint8_t *data, int len) | ||
| { | ||
| return 0; | ||
| } |
Comment on lines
+87
to
+90
| int RAMFUNCTION hal_flash_erase(uintptr_t address, int len) | ||
| { | ||
| return 0; | ||
| } |
Comment on lines
+251
to
+257
| *sz = FileSize(file); | ||
| wolfBoot_printf("Opening file: %s, size: %u\n", filename, *sz); | ||
| status = uefi_call_wrapper(BS->AllocatePages, | ||
| 4, | ||
| AllocateAnyPages, | ||
| EfiLoaderData, | ||
| (*sz/PAGE_SIZE) + 1, _addr); |
| if (status != EFI_SUCCESS) { | ||
| wolfBoot_printf("can't get memory at specified address %d\n", status); | ||
| uefi_call_wrapper(file->Close, 1, file); | ||
| return status; |
Comment on lines
+148
to
+151
| if (status != EFI_SUCCESS) { | ||
| wolfBoot_printf("can't load kernel image from memory\n"); | ||
| panic(); | ||
| } |
Comment on lines
+168
to
+174
| status = uefi_call_wrapper(gSystemTable->BootServices->StartImage, | ||
| 3, | ||
| kernelImageHandle, 0, NULL); | ||
| if (status != EFI_SUCCESS) { | ||
| wolfBoot_printf("can't load kernel image from memory\n"); | ||
| panic(); | ||
| } |
Comment on lines
+42
to
+47
| extern void RAMFUNCTION aarch64_efi_do_boot(uint32_t *boot_addr); | ||
|
|
||
| void RAMFUNCTION do_boot(const uint32_t *app_offset) | ||
| { | ||
| aarch64_efi_do_boot((uint32_t *)app_offset); | ||
| } |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds a generic AArch64 UEFI-application target to wolfBoot -- the direct sibling of the existing
x86_64_efitarget. wolfBoot builds aswolfboot.efi(a PE/COFF EFI application), is launched by platform UEFI firmware, cryptographically verifies the next-stage image, and boots it through UEFILoadImage/StartImage. Validated end-to-end on the NVIDIA Jetson Orin Nano, booting all the way to an Ubuntu 22.04 login prompt.Features
aarch64_efitarget -- the AArch64 counterpart ofx86_64_efi. It uses only UEFI Boot Services (no SoC-specific registers), so a singlewolfboot.efiruns on any AArch64 UEFI platform rather than being tied to one board.SIGN/HASHoptions apply), and hands control to it viaLoadImage/StartImage. A/B image selection uses the RAM updater.pei-aarch64-littlePE output, gnu-efi CRT0 entry, and EFI consolePrintfor log output. A helper script builds the AArch64 gnu-efi runtime from source (tools/scripts/build-gnu-efi-aarch64.sh), pinned to a released gnu-efi tag (4.0.4) so the runtime CRT0/linker-script/libs are reproducible and auditable.tools/scripts/aarch64-efi-qemu.shrunswolfboot.efiunder QEMU + AAVMF, including a--gdbmode for source-level debugging.aarch64_efi_testjob builds the AArch64 gnu-efi runtime and thenwolfboot.efion every push, mirroring the existingx86_64_efijob.\EFI\BOOT\BOOTAA64.EFI), verifies the ED25519 signature, and boots the payload through to Linux userspace.Notable fix
For a UEFI-application target the keystore must not be placed in the dedicated
.keystorelinker section: the gnu-efi PE does not load that section, soPubKeysreads back as zeros and key lookup fails (and faults on stricter firmware).keygen.cnow emits the keystore as plainconstdata foraarch64_efi, matching howx86_64_efialready handles it.Files
New:
hal/aarch64_efi.c,hal/aarch64_efi.ld,src/boot_aarch64_efi.c,config/examples/aarch64_efi.config,tools/scripts/build-gnu-efi-aarch64.sh,tools/scripts/aarch64-efi-qemu.sh. Edits:arch.mk,Makefile,tools/keytools/keygen.c,docs/Targets.md,.gitignore,.github/workflows/test-configs.yml,.github/workflows/test-build.yml.Build and run
See
docs/Targets.md(NVIDIA Jetson Orin section) for the full validated L4T recipe.Validation
kernel.img-> ED25519 verify PASS ->LoadImage/StartImage-> the real L4T kernel EFI stub runs.Verifying signature...done-> boots the signed L4T kernel -> mounts the SD rootfs -> Ubuntu 22.04.5 login prompt, auto-launched from the SD.