Monday, November 17, 2014

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.'

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 www.uefi.org. 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.

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.