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 http://riscv.org/ port of coreboot http://review.coreboot.org/#/c/7065/ 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 https://www.youtube.com/watch?v=vB0FC1DZqUM&feature=youtu.be.
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 http://www.amazon.com/IA-64-Linux-Kernel-Design-Implementation/dp/0130610143. Simarly, for IA32 we originally booted upon a PC/AT BIOS using techniques like DUET https://github.com/tianocore/edk2/tree/master/DuetPkg.
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 http://tianocore.sourceforge.net/wiki/EDK to EDKII http://tianocore.sourceforge.net/wiki/EDK2.
In those early 2000's some fun path-finding was a port to XScale http://en.wikipedia.org/wiki/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 http://www.amazon.com/Beyond-BIOS-Implementing-Extensible-Interface/dp/0974364908 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 http://www.amazon.com/Beyond-BIOS-Developing-Extensible-Interface/dp/1934053295/, 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 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.
And although there isn't an official MIPS UEFI binding, there is a port to MIPS 32 at http://sourceforge.net/projects/efi-mips/.
I look forward to seeing more ports to UEFI, including the presently non-UEFI Power8 firmware such as https://github.com/open-power/skiboot.
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.
The news about the RISC-V http://riscv.org/ port of coreboot http://review.coreboot.org/#/c/7065/ 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 https://www.youtube.com/watch?v=vB0FC1DZqUM&feature=youtu.be.
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 http://www.amazon.com/IA-64-Linux-Kernel-Design-Implementation/dp/0130610143. Simarly, for IA32 we originally booted upon a PC/AT BIOS using techniques like DUET https://github.com/tianocore/edk2/tree/master/DuetPkg.
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 http://tianocore.sourceforge.net/wiki/EDK to EDKII http://tianocore.sourceforge.net/wiki/EDK2.
In those early 2000's some fun path-finding was a port to XScale http://en.wikipedia.org/wiki/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 http://www.amazon.com/Beyond-BIOS-Implementing-Extensible-Interface/dp/0974364908 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 http://www.amazon.com/Beyond-BIOS-Developing-Extensible-Interface/dp/1934053295/, 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 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.
And although there isn't an official MIPS UEFI binding, there is a port to MIPS 32 at http://sourceforge.net/projects/efi-mips/.
I look forward to seeing more ports to UEFI, including the presently non-UEFI Power8 firmware such as https://github.com/open-power/skiboot.
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.
