Skip navigation

Maker Maker, on the Wall…

Posted by Geek8ive May 26, 2010

This past weekend, I had the pleasure of attending Makerfaire and, I’ve got to say, if you’re a geek that’s never gone, you really need to try to fit one in sometime.  I can honestly say, it was one of the most magical places to which I’ve ever been.  Obviously, it wasn’t the actual “place” that made it magical, but rather, that mythological creature: The Maker!


In many ways, Makers are like students from Hogwarts in that, there is nothing overwhelmingly distinctive that lets you easily distinguish between a Maker & a “nominal” human.  However, that does not mean there is no way to identify a Maker – there are these subtle clues:

  • Does the person have small finger calluses from hours of using a solder iron?
  • Can the person root a cell phone as easily as a nominal human peels a banana?
  • Can the person troubleshoot a schematic while still bouncing a child on a knee?
  • Has the person spent more time compiling programs than watching TV?
  • Does the person not only help an old lady change a tire but tune up the car too?

If you’ve spotted a person with any or all of the above characteristics, you may have found yourself a Maker!  But, unlike the classmates of Harry Potter, Makers actually exist & ACTUALLY can do some magic.  It may be some fabrication magic, such as using a 3D Printer to (oh so apropos) create the word “Make” (for example):


(some other stunning pictures of random parts & Skulls & Stellated Rhombic Dodecahedron)


Or, it may be a little more macroscopic fabrication magic, such as Richard Hilleman (Chief Creative Director of Electronic Arts) putting a small jet engine into a hybrid sports car.


(yes, images of the Batmobile Jet Engine came to my mind too!)


And still others focused on Software Magic, like our friends from MIT that made the SCRATCH Programming System.  Now, if you’ve never heard of it & have kids, you’ve just found the answer to the “what to do this summer?” question! What is it exactly?  Well, the short version is: letting children program in Java by using Flow Charts instead of typing out complicated syntax. For example, image the Java Code you’d need to get a game character to walk up a hill.  Now, here’s how you do it in Scratch:


When you press the space key, the cat will move to the right until it hits the hill.  Then it will move up a bit & start to move to the right about.  This action will continue until it gets to the edge of the screen.  It took me 3 minutes to create this.  Sure, it’s simple, but there was no “{…}” to write or semicolons to remember.  The picture of the cat (which is also the Scratch Mascot) came included & I made the simple hill with a built in paint program, but I could have made something fancier, say using Paint.NET & imported if I wanted to.  The point is, over 1 MILLION “projects” have already been uploaded to Scratch.  While some are surely simple (like the very interesting “marble motion” one) others can be quite challenging, despite a deceiving simplicity (tell me how long it takes you to solve the “revolving maze in the dark” – I gave up!).  However, no matter how simple, by sheer volume, Scratch is 5 TIMES more popular that the iTunes store – and this is with most people not really knowing about Scratch & everyone knowing about the iPhone!  Imagine what would happen if the simplicity of programming in Scratch was married to the openness & volume of the Android Operating System (which is already designed to be programmed with Java)!


And, that’s actually the key point.  Any 1 part of Makerfaire is cool – but when you walk around & see the First Lego League or “Peddle-to-Play” Video Game System or see kids that are too young to write in cursive learning to solder (courtesy of SparkFun) – that’s when it hits you: The Magic is what happens when you start adding all this together!


For example, I saw this very interesting display called the “DIY Magic Mirror.”  Wow, what a great start.  But, imagine if, kids were able to program it in Scratch? What if it ran on Android & could do both Speech-to-Text (listening) and Text-to-Speech (talking)?  What if, with a little help from Mom & Dad, they could connect it to the light in their room?  What if, instead of an old laptop, it ran on the new $150 Intel® Embedded Development Board 1-N450 (which can be followed on Twitter: @DevBoard) that has both VGA out (for the magic mirror) and a higher definition output for a monitor from which they could watch Hulu or YouTube?  Add that all together & your child has been magically transported almost 150 years into the future, around the time of Star Trek Enterprise.  You know, when people can just say: “Computer – lights” & then come on?  Except, your child could live most of that future now, with a little hard work & some Intel Embedded Magic there to help you. 


And that, quite simply, was my #1 takeaway from Makerfaire.  Before going, I thought I worked in the “Intel Embedded & Communications Group” but now I realize I really work in the “Intel The-Science-Fiction-of-Tomorrow-Starts-Today Group” – we just haven’t named it right yet.


But, let me know what you think?  Did you go to this Makerfaire or previous one?  Where you not able to go, but want to see more pictures?  I’ve posted many of my picture through my Twitter account (@Geek8ive) but you can also follow @Intel_Jim & @Intel_Stewart who were there with me as well.  And, while you’re at it, let us know how we can better help your Science-Fiction-of-Tomorrow projects get started a little faster today ;)

One of the reasons I started this blog is to take some of the mystery out of BIOS, which is often portrayed as arcane computing … some combination of technology and black magic. I think it’s valuable to take time in this forum to expose the type of tools available to the BIOS developer. Today’s article focuses on how an Independent BIOS Vendor (IBV) handles debugging BIOS issues.


The goal for any BIOS vendor is to deliver a product that doesn’t require extensive debugging. Of course, things don’t always go the way we plan … just like I didn’t plan to spend last weekend having my car repaired, or wait on that tow truck in the rain …


Anyway, let’s look at three different scenarios for debugging BIOS on an embedded Intel Architecture system:

  1. Debugging BIOS on a deployed system: determine where the BIOS hangs in the boot process and view extended error codes
  2. Debugging BIOS during development without source code: view verbose debug and trace messages as the BIOS executes
  3. Debugging BIOS during development with source code: analyze, stop and step-through BIOS source code on a debug target system

Deployed Systems

For this example, assume a “deployed system” is setup to work as the customer would receive it. This can be a system in the field or one submitted to quality assurance for integration testing.


Debugging BIOS on this system uses checkpoints to show progress through the boot process. BIOS checkpoints are also useful for quality assurance processes, helping to identify where the BIOS may be hanging in the boot process. Think of like the diagnostic module they attach to a car when the “check engine” light comes on (you think that light would come on before the engine starts to smoke).


The important thing about debugging BIOS in a deployed system is that it shouldn’t be too intrusive … this is a solution that has to work in the field. In the past checkpoints were viewed on a “checkpoint card” (also known as a “port 80 card” since the checkpoints go to I/O port 0x80). Adding such a card requires an open PCI slot (not common in today’s systems) or a LPC bus header (somewhat proprietary). Both require opening the case, which is tough to do on today’s systems … just look at small form factor platforms like Qseven or the Intel® Embedded Development Board 1-N450.


Some board vendors create proprietary methods for displaying BIOS checkpoints, but there are solutions that solve the “open case problem.”  AMIDebug™ Rx is one example, using the USB debug port functionality on Intel USB 2.0 controllers. This solution uses a commodity port that doesn’t require the case to be opened, and lets the USB port to operate normally when AMIDebug Rx is disconnected.


Advanced Debug Without Source Code

Development debugging without source code used to rely only on checkpoints, but that has changed with the introduction of UEFI. I discussed the user advantages of UEFI in my previous blog article, but there are numerous developer advantages as well. UEFI defines a set of debug strings, displaying verbose information about the boot flow. Debug strings are enabled when the BIOS is compiled and are routed to a secondary output (keeping them separate from the main system display).




[AmiDbg]>>> PM Registers Before GPIO Init <<<

[AmiDbg]+===================== PM Registers dump =====================+

[AmiDbg]  PM1a_EVT_BLK.PM1_STS      : Addr = 0400 => Val = 0001

[AmiDbg]  PM1a_EVT_BLK.PM1_EN        : Addr = 0402 => Val = 0000

[AmiDbg]  PM1a_CNT_BLK.PM1_CNT      : Addr = 0404 => Val = 00001C00

[AmiDbg]  PMTMR_BLK.PM1_TMR          : Addr = 0408 => Val = xx9E5F20

[AmiDbg]  P_BLK.PROC_CNT            : Addr = 0410 => Val = 00000000

[AmiDbg]  GPE0_BLK.GPEO_STS          : Addr = 0428 => Val = BDFF0000

[AmiDbg]  GPE0_BLK.GPEO_EN          : Addr = 042C => Val = 00000000

[AmiDbg]+==================== SMI Registers dump =====================+


That sequence may look like nonsense to the average user, but it’s great information for debugging UEFI platforms. UEFI debug strings are the equivalent of verbose messages in the Linux kernel, more detailed than basic checkpoints and far more informative than what that so-called mechanic told me about my transmission.


[AmiDbg]Register PPI Notify: 605ea650-c65c-42e1-ba80-91a52ab618c6

[AmiDbg]PEIM 8401a046-6f70-4505-8471-7015b40355e3 was not started!!

[AmiDbg]PEIM e008b434-0e73-440c-8612-a143f6a07bcb was not started!!

[AmiDbg]PEIM 32505be8-6469-4f79-9b01-66b3f9617e7d was not started!!

[AmiDbg]PEIM a47438d5-94e9-49b3-bc31-7e6bc9363814 was not started!!


I know, it’s hard to believe any of that makes sense … just trust me.


That stream of technical nonsense doesn’t get built into a production BIOS, but developers can enable it during development for advanced debugging. These strings can be piped to a RS-232 serial port or captured by USB debug devices like AMIDebug Rx (for systems that do not include a legacy serial port).


Advanced Debug With Source Code

Development debugging with source code is the most detailed level of BIOS debugging, adding the ability to step and trace through code in real-time. It’s the best way to see “under the hood” of the BIOS while it runs, assuming the hood isn’t in flames on the side of the highway. You would think something wouldn’t burn like that in a rain storm …


Sorry, where was I? Right, source level debugging.


Compiling BIOS in debug mode generates a MAP file, used to connect the execution of BIOS on a debug target back to the exact line of source code on the debug host system. If your boss asks, tell them it’s like a GPS that understands processor instructions. The trick is connecting the two systems so the target BIOS can be controlled by an application on the host system. There are two common methods … one connects to the processor, the other connects to the BIOS.


A direct processor connection uses a JTAG port, allowing a processor emulator to be connected to the system. Companies like Arium,  market devices that connect to the Intel XDP connector, enabling direct control of the processor at the reset vector. (Arium is an Affiliate member of the Intel® Embedded Alliance).


Connectors like Intel XDP are common on development boards, but rarely seen on production platforms. For this reason, BIOS developers market alternatives that give the same level of debug control to systems without XDP or JTAG ports. Each BIOS vendor has a variation of this tool. At AMI, the AMIDebug Rx is used as a host-to-target connection enabling the AMI Debug suite to run prior to memory detection. This type of BIOS debug tool allows JTAG-style debugging on production level hardware.


Debug, Debug and Debug Some More

BIOS development isn’t as widely understood as driver or application development, but a variety of debugging methods exist. Platform developers can do everything from diagnose systems in the field to trace source code.


I wonder if my car had a USB debug port. I’ll ask the insurance company about that once the fire department gets done with my car …


Brian Richardson
Senior Technical Marketing Engineer
American Megatrends, Inc.


American Megatrends, Inc. (AMI) is an Affiliate member of the Intel® Embedded Alliance.


Got a question about BIOS? … then it’s time to Ask a BIOS Guy! Find Brian on Twitter (@askabiosguy) or leave your question in the comments. Your BIOS question may be featured in an upcoming ‘Ask a BIOS Guy’ article.

Ask a BIOS Guy: "Why UEFI"

Posted by brian_ami May 10, 2010

If you've looked at anything related to the Basic Input/Output System (BIOS) in the past few months, you’ve seen the acronym “UEFI” a lot. Not only are the major BIOS vendors offering UEFI solutions, but Intel uses UEFI for embedded development  platforms and customer reference boards.


There’s piles of technical nonsense we can discuss here for firmware developers …  documented protocols, drivers that replace legacy Option ROMs, C programming interfaces, support for IA32 and x64 architectures. But in this jargon it’s important to understand the benefits UEFI has for system users. I believe we know them better as “customers”.


BIOS in the Intel® Ecosystem

In Intel® Architecture, BIOS provides low-level hardware initialization, software portability and easy migration to different operating systems on the same platform. This is why the motherboard you buy at the store can run everything from Microsoft Windows 7 to Ubuntu out of the box … or why a single embedded system can run everything from MeeGo to Microsoft Windows Embedded without altering the firmware. It’s a huge advantage in the Intel ecosystem.


But the legacy 16-bit BIOS architecture has limitations, which is why the industry developed the Unified Extensible Firmware Interface (UEFI). This new level of standardization opens up an architecture-independent set of interfaces, going beyond the original BIOS. Let’s look at three areas where UEFI brings clear advantages … drive size limits, pre-boot networking and pre-boot applications.


Drive Size Limits

The issue facing most customers this year is booting to a drive over two terabytes (2TB) in size. This doesn’t sound like a problem for most embedded developers, until you think about the storage requirements of digital surveillance or medical imaging systems. The master boot record (MBR) partitioning scheme uses 32-bit values to describe partition offsets and length, which limits the largest disk partition to around 2.2TB. It’s not just a BIOS limit, since the OS uses the same MBR data in the boot loader.


The UEFI alternative to MBR is the GUID Partition Table (GPT). GPT disks use 64-bit values to describe partitions, handling disk sizes up to 9.4 zettabytes (go look that up, it’s way bigger than any Wall Street bonus paid out last year). GPT also fixes other issues related to MBR (data integrity, backup tables and maximum number of partitions). The UEFI Forum has a FAQ on Drive Partition Limits with more details.


Pre-Boot Networking

Next is networking and the coming day when our various connected devices use up every IP address on the planet. My IT manager insists this is a big deal, making it sound like the plot to one of those end-of-the-world disaster films. But before you go building an ark or stocking up on canned goods, you should know the industry has already been working on a solution.


The IPv6 specification has been in development for years, overcoming the limitations of the current IPv4 specification (to be fair, four billion IP addresses sounded like a lot in the 1980’s). UEFI incorporates IPv6 as well, so network booting and remote management capabilities integrate seamlessly as the industry migrates to this new networking standard.


Pre-Boot Applications

Finally we look at pre-boot applications … programs designed to run in between the end of the BIOS but prior to the operating system. These applications have been around for years, usually embedded in the flash part with the system BIOS or tucked away on a hidden disk partition.

The problem with most pre-boot applications is making them platform independent. UEFI’s documented interfaces for boot and runtime services give developers a clean method of accessing essential routines without the need for an OS kernel or driver stack. Even graphical interfaces are possible, relying on the new UEFI Graphics Output Protocol (GOP) instead of older VESA VGA interfaces.


One real-world example is Dell’s Unified Server Configurator (USC), designed by Dell and AMI to simplify server deployment. This UEFI graphical application eliminates the need for the “system DVD” and has been shown to speed up bare-metal provisioning. It’s just one example of using native UEFI applications to provide value-add services. Embedded diagnostics, network-based BIOS update utilities and system recovery can be part of a COTS platform, no matter what OS the customer deploys.


More to UEFI Than Meets The Eye

Since I’m a “BIOS Guy” I could ramble on for pages about UEFI … but the important thing to understand is that the benefits aren’t just for BIOS developers. UEFI enables features that trickle down to a better customer experience, and are already being seen in today’s platforms. If you need BIOS for an upcoming Intel platform, it’s best to learn more about UEFI.


Brian Richardson
Senior Technical Marketing Engineer
American Megatrends, Inc.


American Megatrends, Inc. (AMI) is an Affiliate member of the Intel® Embedded Alliance.


Got a question about BIOS? … then it’s time to Ask a BIOS Guy! Find Brian on Twitter (@askabiosguy) or leave your question in the comments. Your BIOS question may be featured in an upcoming ‘Ask a BIOS Guy’ article.

Filter Blog

By date: By tag: