Monday, November 17, 2014

Porting to a new architecture

Part of the excitement of working with system firmware includes programming on bare metal. I recall taking an NT Driver class back in 1998 led by some Ex-DEC engineers. The engineer said "programming kernel mode drivers is tricky, but the real magic entails the work of the firmware guys." As an embedded guy working in this area since 1992, all I could say is 'Yes.'

The news about the RISC-V port of coreboot reminded me of some of the thrills in porting firmware to a new CPU architecture. A possible UEFI port for RISC-V is even mentioned during the technical discussion of this new instruction set architecture

Some of my favorite work includes bring-up for EFI on new CPU's. We started the EFI journey in 1998 working on Itanium and IA32. The Itanium port built upon SAL-A/B as the PI equivalent code, such as memory and CPU initialization  Simarly, for IA32 we originally booted upon a PC/AT BIOS using techniques like DUET

Over time we moved to native code for the platform initialization as the Framework specifications evolved. These Framework specifications became the UEFI Platform Initialization (PI) specifications, and the code base evolved from EDK to EDKII

In those early 2000's some fun path-finding was a port to XScale I mention that work a bit in the above article and also discuss the port in chapter 7 of  the first edition of Beyond BIOS since Intel was still delivering XScale-based products, although EFI wasn't an official requirement. Instead, I used the XScale port to show the cross-architecture flexibility and scaling of both the specifications and the associated code bases. In the second edition, I removed that content and replaced it with Intel IA32 SOC examples.

Ironic to think that I was possibly the first person to do an EFI port to 32-bit ARM, albeit EDK-based and it had a faked-PEI but full DXE.

After that the next excitement occurred with Intel64/EM64T/AMD64/X86_64, or as is now known in the UEFI binding, x64.  See chapter 2 of the UEFI2.4 specification at There the challenge was having to enable paging. Itanium also needed paging but we used software TLB handlers and had simple logic to program the TR registers in our SAL, then DXE CPU driver. For x64, we kept PEI to 32-bit since page tables in ROM and / or temporary RAM were tricky and ported DXE, our EFI/UEFI core, to 64-bits.

The crafting of .s/.asm files for a new architecture and getting through the first boot is more exciting than a platform port within a given architecture since there is a sense of pioneering with these foundation components.

Since this pioneering, the ARM community has done the EDKII ports to ARM32 and Aarch64 and they are first class citizens in the standards, including UEFI & PI, and the codebase, such as EDKII.

And although there isn't an official MIPS UEFI binding, there is a port to MIPS 32 at

I look forward to seeing more ports to UEFI, including the presently non-UEFI Power8 firmware such as

Like the RISC-V work and ARM ports, I'll have to watch the latter efforts from the sidelines. My day job and extra-credit/after hours budget have enough Intel-architecture based efforts and opportunities to pursue.  Although I have to admit I miss some of the excitement of the port to ISA.Next.

Post a Comment