Post a Comment
Welcome to the dark corner of BIOS reverse engineering, code injection and various modification techniques only deemed by those immensely curious about BIOS
Sunday, November 22, 2009
TianoCore, UEFI and Coreboot
After a short glimpse over several mainstream BIOS binaries from several different motherboards, I came to conclusion that the move to UEFI is basically a slow incremental process. I think that most mainstream BIOS binaries at least still have the "compatibility mode code", which is a code path to "legacy BIOS" code, i.e. the BIOS code used in say Award 6.00PG or early AMIBIOS 8 base code.
On the other hand TianoCore has not been much adopted outside of Intel. It's because some (if not most) relevant industry players view it as moving too fast and doesn't have stable code base. I don't think it has a stable "API" yet for others to "hook" their specific functions into it.
Coreboot is in an entirely different league. I love the structure of Coreboot, only 16 machine code instructions prior to flat Protected Mode. This explains its fast boot time compared to the competition. However, for the time being Coreboot is geared more toward computing clusters and embedded industrial boards. I haven't dig too deep into Coreboot for a better judgement. More on it later.
Post a Comment
Post a Comment
Subscribe to:
Post Comments (Atom)
4 comments:
The reason the "compatibility mode code" is provided is mainly due to the customer's need to run OSes such as legacy Windows XP that does not support UEFI. All BIOS vendors have UEFI codebases, regardless of how much TianoCore code they use. TianoCore is an open source reference code of the UEFI "framework". It is not a full production code. It is not true that TianoCore is not adopted outside of Intel. BIOS vendors chose how much they want to directly use the reference code, some use almost all of it, others use parts. Same is true for the OEMs. There are a lot of non-Intel products shipping that are based on TianoCore. A lot of differentiations also are implemented extending the current APIs. It is unlikely that the general commercial products would use Coreboot. Vendors still need to be able to differentiate and protect IP.
Thanks for the very helpful insight ;-).
I agree that Coreboot will still be in its own niche market, especially in HPC and embedded space.
BTW: UEFI works fine as a coreboot payload.
All over history, there was a thing called innovation. Like harnesses were replaced by tractors. The whole discussion about closing down a BIOS protects anyone's IP (except of Phoenix and AMI) is more than questionable. I have seen this claim quite often but never a single reason why this would be so. Maybe we should just go back claiming the earth is flat, and people will start believing it, too?
Post a Comment