[Clang] (1) How to Compile EDKII Based BIOS Source using Clang?

How to Compile EDKII Based BIOS Source using Clang (https://en.wikipedia.org/wiki/Clang)?

1. Files to be modified:

1.1. MSFT_DEF.txt = Microsoft Tool Chain Definition

--> This is main Tool Chain file

1.2. MSFT_DEF.txt, GCC_DEF.txt, ... 

MYTOOLS_DEF.txt --->

!include MSFT_DEF.txt
*_MYTOOLS_*_*_FAMILY = MSFT

VS2015_DEF.txt --->

!include MSFT_DEF.txt
*_VS2015_*_*_FAMILY = MSFT
DEBUG_VS2015_IA32_CC_FLAGS = DEF(DEBUG_CC_FLAGS) DEF(COMMON_CC_FLAGS) /arch:IA32
RELEASE_VS2015_IA32_CC_FLAGS = DEF(COMMON_CC_FLAGS) /arch:IA32

Since MYTOOLS_DEF.txt and VS2015_DEF.txt are sharing the usage of MSFT_DEF.txt, we need to list the difference between them. (MyTools as Default)

1.3. The usage of MYTOOLS_DEF.txt is selected in target.txt 

This file is generated in main.mak

target.txt --->

ACTIVE_PLATFORM    =  Build/Platform.dsc

TARGET = RELEASE

TOOL_CHAIN_CONF    = AmiPkg/Configuration/MYTOOLS_DEF.txt

TOOL_CHAIN_TAG = MYTOOLS

MAX_CONCURRENT_THREAD_NUMBER = 8

BUILD_RULE_CONF = AmiPkg/Configuration/build_rule.txt

The make command in main.mak as follows:

# Create Conf/target.txt, based on SDL tokens
Conf/target.txt : $(TOKEN_MAK) $(MAIN_MAK) Conf
@$(ECHO) \
"ACTIVE_PLATFORM    = $(subst \,/, $(ACTIVE_PLATFORM))\
$(EOL)\
$(EOL)TARGET = $(TARGET)\
$(EOL)\
$(EOL)TOOL_CHAIN_CONF    = $(TOOL_DEFINITION_FILE)\
$(EOL)\
$(EOL)TOOL_CHAIN_TAG = $(TOOL_CHAIN_TAG)\
$(EOL)\
$(EOL)MAX_CONCURRENT_THREAD_NUMBER = $(NUMBER_OF_BUILD_PROCESS_THREADS)\
$(EOL)\
$(EOL)BUILD_RULE_CONF = $(BUILD_RULE_FILE)" > Conf/target.txt

-----------------------------------------------------------------

TOKEN
Name  = "TOOL_DEFINITION_FILE"
Value  = "$(CONFIGURATION_DIR)$(TOOL_CHAIN_TAG)_DEF.txt"
Help  = "Name of the tool definition file.\This value goes to to auto-generated Conf/target.txt."
TokenType = Expression
TargetMAK = Yes
End

--------------------------------------------------------------

Conf/target.txt : $(TOKEN_MAK) $(MAIN_MAK) Conf
@$(ECHO) \
"ACTIVE_PLATFORM    = $(subst \,/, $(ACTIVE_PLATFORM))\
$(EOL)\
$(EOL)TARGET = $(TARGET)\
$(EOL)\
$(EOL)TOOL_CHAIN_CONF    = $(TOOL_DEFINITION_FILE)\
$(EOL)\
$(EOL)TOOL_CHAIN_TAG = $(TOOL_CHAIN_TAG)\
$(EOL)\
$(EOL)MAX_CONCURRENT_THREAD_NUMBER = $(NUMBER_OF_BUILD_PROCESS_THREADS)\
$(EOL)\
$(EOL)BUILD_RULE_CONF = $(BUILD_RULE_FILE)" > Conf/target.txt

---------------------------------------------------------------

1.4. Search "Clang Support" for building on Mac OS X (in EDK2_Build_Spec.pdf), where the full sample of Clang_DEF.txt 

1.5. Complete Flow:

1.5.1. Veb Calls Tools (make.exe) -> makefile

1.5.2. makefile gives the control to main.mak

1.5.3. main.mak in charge of including all makefiles came from module.mak

1.5.4. Based on definition of toolchain, main.mak will generate target.txt

1.5.5. main.mak calls EDK2 build.exe

1.5.6. Compile Example of a EDKII "Driver"

Control Tool:   C:\WinDDK\7600.16385.1\bin\x86\amd64\cl.exe
Generated File: v3_lib.obj
Source File:    v3_lib.c

---------------------------------------------------------------

2. target.txt

# Platform.dsc:

ACTIVE_PLATFORM    =  Build/Platform.dsc

TARGET = RELEASE

TOOL_CHAIN_CONF    = AmiPkg/Configuration/MYTOOLS_DEF.txt

TOOL_CHAIN_TAG = MYTOOLS

MAX_CONCURRENT_THREAD_NUMBER = 8

BUILD_RULE_CONF = AmiPkg/Configuration/build_rule.txt

[x86] (9) PFAT aka. BIOS Guard and its flaw

Back to x86 again everyone, for responsible to curious feedback from 王御多, here's some little explain for PFAT aka. BIOS Guard.



Alright, I know some might feel it's too short for explaining the PFAT, however, it's really necessary to understand the basis of RSA first. If you do familiar with RSA, the only mist of PFAT to you is "Use HW solution to replace SMI method".

Using SMI method to verify and update BIOS package is okay in traditional way since in early days, people aren't so familiar with SMI. However, now days we have various software tools and spec. help us to catch and hijack the SMI.

So here's the PFAT (HW solution), the main idea is extremely simple, doing the verify and update in the hideout, block the interrupt and fetch the package data from HW-specified memory part. See, it's really simple so say so, PFAT is doing the exactly same thing except it's hiding in specified HW place.

Well, it's pretty nice, isn't?

However, someone just forgot a little thing about compatibility with BIOS recovery...what? how they get messed up since BIOS recovery is so conventional? Well, they did forget it. You may seem BIOS recovery as another kind BIOS update package only difference is the package itself is previously stored in BIOS ROM and it runs in PEI phase. Sounds fine...but PFAT module only runs in DXE phase....WTF?! BIOS recovery module could never pass the verify phase!

Anyway, I'm pretty sure it's just a little flaw had been fixed by now, just to share the experience that even the mighty one would make such funny issue.

Please leave me any comments or questions, I'd be thankful and response as soon as possible! Thanks!

[x86] (4) Security Features Diagram

End of the Friday already? Great, let's give a sneaky shot on old x86 based security features. I'll explain those stuffs later and let you guys have great weekend first.

Leave me any questions, suggestions and comments as you need, thanks!

[x86] (3) UEFI BIOS Dynamic and Static Analyzer

Alright everyone, I believe you guys might pass out or fall into some kinds of coma for visiting old x86 museum yesterday (2) Post Mortem: ACPI/ SCI/ Q Event) since that slide is actually the compilation of few insight reports either written in English and Mandarin. Thanks to old great guys and hope my material could be as open minded as they do.

Say, let's see something new today, it's about an idea that none never support it or take it serious but me. UEFI is the BIOS standard highly promoted by Intel...and forced everyone to do so. However, BIOS is an old industry that experienced engineers tend to use traditional debug methods such as break-points. That's what I called single debug view as following diagram.

This kind of debug view is fine when you're dealing with annoying OEM customer or Project Leader urging for issue report. Yeah, just do it and attach all your records from POST code/ debug message from PCH or EC serial out/ break-point insight from IBV or Intel's online debug monitors. However, you're looking at one issue at a time. Or you're looking at two or three issues at the same time, but you're still using single debug view.

As the engineer of one project, you should be fine with single debug view. As the BIOS leader or Feature leader, you might face multiple projects ongoing in the same time and all those projects binding with second/ third source junk components (memory of worse margin, TPM initializes/ wakes up so late), and even more disasters you could possibly image.

So my idea was to create analyze view based on automatic calculation in build time and run-time. With this analyze view, you may control multiple projects at the same time without manual efforts on each project's inspection. More to that, you could create a golden template based on the vendor's reference board to control all your projects. All analyze view reports are generated automatically, no more schedule losing control.

I really love this diagram, it explains how automatic framework collecting data in build-time and run-time to create analyze view.

It's the representation example of analyze view, it's easy to gain the benefit of free and open source diagram automation generator.

See the event schedule mentioned in previously diagram? That overcomes the late initialization/ wake-up issues as well, how I love this.

How thousands of Taiwan BIOS RD still doing their jobs like this...It's not a joke, man.

How it really works and helps us from try and error.

Too shay I still have bad news about this UEFI BIOS Dynamic and Static Analyzer, which is, UEFI is not welcome to future world since x86 members (Vendors, OEM, ODM) are mainly focus on making their own money. Even UEFI is supposed to be open, people tend to doubt it and pay attention to other standards.

Finally, welcome to give me any questions, suggestions or comments, thanks!