Thursday, October 31, 2013

[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!



[x86] (2) Post Mortem: ACPI/ SCI/ Q Event

Before we back to the Future world full of mobile and smart devices, let's take a look on those old bones from yesterday world...however, as the latest news I know, there are still a huge bunch of Taiwan engineers devoted their self to the x86 based, nearly dead PC and NB markets and refuse to wake up. It's really sucks that our human nature tends to follow, not to lead. Anyway, pretend you're visiting the x86 museum....with my sarcasm introduce.

 Long long time ago, there is a power saving standard called APM, the main idea is that any devices besides the CPU might notify CPU through SMI (software or hardware wired) that CPU would run the power state modify routine written in BIOS code. SMIs can't be scheduled well since it's nothing to do with OS that the system would halt while CPU's dealing with SMIs.

Well, it sucks to be so technique. Let's do it over again, CPU is a poor cook, only dealing one customer's order at one time. However, there are a bunch of crazy supervisors, they could interrupt cooker's job in the name of SMI. So the poor cook got customer complaint and supervisor take it as their huge contribution as management level.
























Boring questions you guys must know the answers.


More boring history.


ACPI's so complicated...Really? The main idea is as simple as the poor cook example in APM.



I really like this page that I draw before, however it's too detailed on ACPI events. If anyone's interested, I would append the explanation as demand.


This is my favorite page that I update it several times! Too bad it's still detailed, but I would point one thing take-away, ACPI is like the poor cook in previously example, hires one sexy waitress (that is Operating System!) to assist the order schedule including the non-sense requests from stupid supervisors. The SMI requests mentioned previously are now replaced by SCI requests.


Huh, boring power states. Can you image that all those years go by and still the general users got confused on all those damn S3/S4/S5/S0/Hibernate/Fast-Start-Up/ Connected-Stand-By things... No one really sees what are they doing and they didn't even recognize it...wow!


More Reference...


More questions... make it stop!


Good trip of old stuff, right? I had devoted a lot time and efforts on it, but now I realize that I shouldn't only learn for the job and money, or there goes the consequences that most things you know became the yesterday's ashes. At least I wake up now, ha ha.

Any questions, suggestions or comments, please show me some support, thanks!


Wednesday, October 30, 2013

[x86] (1) Preliminary

1.5 Year as DELL Commercial NB ODM BIOS RD in Foxconn
0.5 Year as DELL Commercial NB IBV BIOS RD in American Megatrends inc
1.5 Year as NB BIOS Security Features RD Leader (see my digital signature on various projects) in worldwide PC/NB OEM

I spend my first 3.5 years career life as a full time NB BIOS RD crossing OEM/ODM/IBV, and I now feel like I shall share all my experience and knowledge that some might not do so. I hope the upcoming footprints I revealed would help others to better understand the BIOS industry and it would be my career marks as well.

Feel free to ask me any questions whatever how technical it would be, such as "What is the main purpose of Security Boot/ TPM/ HSM/ Trusted Chain/ Measure Boot/ BIOS Guard/ Boot Guard?" Any confusing security features involved in NB/ BIOS, I could give you all-you-can-eat answers full of sarcasm. :)

Anyway, it's just the official beginning of my blog life, cheers and wish me luck. I'm ready to share and learn new stuff as a pure indie engineer now.