Linux boot hangs at "EFI stub: Exiting boot services" on custom RISC-V SoC (FPGA) #11570
Unanswered
kenadams68
asked this question in
Q&A
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Description
Environment
EDK2 Version: edk2-stable202505
Platform: Custom RISC-V SoC (FPGA bitstream)
Architecture: RISC-V 64-bit (rv64imafdc_zicsr_zifencei, ABI: lp64d)
RAM: 512 MB (0x80000000 - 0x9FFFFFFF)
Working Configurations: Same setup works in QEMU virt machine and with BBL (Berkeley Boot Loader)
Linux Kernel Configuration
Version: 6.6
Toolchain: riscv64-unknown-linux-gnu-gcc
Build flags: CC_PREFIX=riscv64-unknown-linux-gnu- PK_FLAGS="--with-arch=rv64imafdc_zicsr_zifencei --with-abi=lp64d"
Output: arch/riscv/boot/Image (PE32+ EFI application format, verified with file command)
CONFIG_EFI_STUB: Enabled
Initramfs Configuration
Initramfs is embedded in the firmware via FDF file:
FILE FREEFORM = b511d352-7623-4843-accc-2791a7572319 {
SECTION RAW = linux/initramfs.cpio.gz
}
Loaded in UEFI shell with:
initrd b511d352-7623-4843-accc-2791a7572319
Linux Loader
Custom UEFI application (LinuxApp.inf):
[Defines]
INF_VERSION = 0x0001001B
BASE_NAME = LinuxApp
FILE_GUID = 99999999-9999-9999-9999-999999999999
MODULE_TYPE = UEFI_APPLICATION
VERSION_STRING = 1.0
[Binaries.RISCV64]
PE32| Image
Problem Description
The system successfully boots through:
✅ OpenSBI v0.5

✅ SEC/PEI/DXE phases
✅ UEFI Shell
✅ Kernel loading (loads at 0x8E97D000)
✅ Initrd loading from GUID
✅ "EFI stub: Booting Linux Kernel..."
✅ "EFI stub: Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID device path"
✅ "EFI stub: Using DTB from configuration table"
✅ "EFI stub: Exiting boot services..."
❌ System hangs after TimerDriverSetTimerPeriod(0x0)
The kernel's earlycon parameter is passed but produces no output after ExitBootServices.
Console Setup
Serial output via custom SerialPortLib.inf
Visible through minicom on ttyUSB0
UEFI output works correctly, kernel earlycon does not engage
Observations from Boot Log
Timer driver issues: The last message is TimerDriverSetTimerPeriod(0x0), suggesting the timer is being disabled during boot services exit
Multiple image alignment warnings throughout boot:
!!!!!!!! Image Section Alignment(0x40) does not match Required Alignment (0x1000) !!!!!!!!
ProtectUefiImage failed to create image properties record
Variable storage failures:
ERROR: RamFlashWrite() failed with Status = 0x2
RAM Flash: Unable to initialize variable FV header
Error: Image at 0009FE8B000 start failed: Write Protected
Memory layout appears correct:
Kernel loads at 0x8E97D000 (within 512MB RAM range)
Boot services memory properly allocated
No obvious memory corruption
Expected Behavior
Kernel should:
Take control after ExitBootServices
Initialize earlycon output
Continue boot process with initramfs
Actual Behavior
System completely hangs with no further output after "EFI stub: Exiting boot services..." and the timer period call.
Additional Context
Same kernel and initramfs boot successfully in QEMU with identical EDK2 build
Same kernel and initramfs boot successfully with BBL on the same FPGA hardware
This suggests the issue is specific to the EDK2 → Linux handoff on physical RISC-V hardware
Questions
Could the timer disable during ExitBootServices be causing a hardware-specific hang?
Are there known issues with RISC-V ExitBootServices on non-QEMU platforms?
Could the image alignment warnings affect the boot services exit?
Should custom RISC-V platforms require specific DXE drivers or protocols for proper kernel handoff?
Is there additional debug output that can be enabled to see what happens after ExitBootServices but before kernel execution?
Debug Steps Attempted
✅ Verified kernel is valid PE32+ EFI application
✅ Confirmed initrd loads correctly
✅ Tested identical setup in QEMU (works)
✅ Tested with BBL on same hardware (works)
✅ Verified memory ranges are correct
Request
Guidance on debugging the ExitBootServices → kernel handoff on custom RISC-V hardware, or any known issues with this transition on non-virtualized RISC-V platforms.
Beta Was this translation helpful? Give feedback.
All reactions