Hey there, let’s break down why you’re running into UEFI protocol support issues on your Up Board, and how to troubleshoot it!

1. Your Up Board’s UEFI firmware is a stripped-down implementation #

Most embedded/SoC platforms (like the Up Board’s Intel Atom-based system) use lightweight UEFI stacks (often built on Coreboot + Tianocore EDK2) that don’t include the full UEFI spec protocol suite. Many desktop-focused protocols, or even some basic filesystem-related extensions, get trimmed to save space or reduce complexity.

• First, check the official Up Board firmware documentation to see the list of explicitly supported UEFI protocols.
• Boot a standard UEFI Shell from a USB drive, then run commands like protocols or dmpstore to list all active protocols on the system. This will confirm whether the missing protocols are truly unsupported by the firmware, or if there’s an issue with your code.

2. gnu-efi compilation configuration mismatches #

gnu-efi’s default setup targets general-purpose desktop UEFI environments, which might not align with the Up Board’s embedded requirements:

• Ensure you’re using the correct cross-compilation toolchain (if building from a non-x86_64 host) — use x86_64-elf-gcc instead of a standard system gcc.
• Verify your compile flags include mandatory EFI-specific parameters like -mno-red-zone, -ffreestanding, and -fshort-wchar to generate a binary compatible with the platform’s UEFI runtime.
• Double-check the linker script: gnu-efi’s default script may need minor tweaks for the Up Board’s memory layout, especially if the firmware uses non-standard memory regions.

3. EFI program loading context restrictions #

You’ve confirmed LOADED_IMAGE_PROTOCOL works, so your binary is being loaded correctly — but other protocols might require specific context:

• For filesystem protocols, make sure your EFI executable is loaded from a UEFI-recognized filesystem (almost always FAT32; some embedded platforms reject NTFS or exFAT entirely).
• Try manually loading your EFI program from a UEFI Shell instead of a custom boot entry. Custom entries sometimes run with restricted permissions that block access to certain protocols.
• Audit your protocol lookup code: Ensure you’re using the correct GUIDs (e.g., EFI_FILE_SYSTEM_PROTOCOL_GUID for filesystem access) and passing valid pointers to gBS->LocateProtocol. Add error handling to log the result of gBS->GetLastError() when a lookup fails — this will tell you if the protocol is truly missing or if there’s a different issue (like invalid parameters).

4. Example code needs platform-specific adaptation #

The mjg59 example you’re using assumes a full-featured UEFI environment, which doesn’t match the Up Board’s capabilities:

• Strip down your code to test basic protocol access first (e.g., EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL for printing to the screen). Build up incrementally to identify exactly which protocols work and which don’t.
• For BIOS updates: If the Up Board supports UEFI Capsule Update, use that mechanism instead of rolling your own — it’s far more reliable and leverages firmware-native functionality.
• For PXE automation: Check if the firmware has PXE enabled in its settings. If EFI_PXE_BASE_CODE_PROTOCOL is missing, you might need to use UEFI Shell’s built-in PXE commands as a fallback.

内容的提问来源于stack exchange，提问作者SirDifferential