Phoenix BIOS Developer Blog

HOW-TO: Change directory to source directory for a specific .EFI file.

Many times you will see a file name, such as SystemGraphicsConsoleDxe.efi. The "SystemGraphicsConsoleDxe" portion of that comes from the BASE_NAME keyword in the INF files. The following little batch file will change the directory wherever the INF is located that contains that BASE_NAME in SecureCore Tiano™. This relies on the environment being set up correctly, as described in SU.BAT.

@IF NOT "%1" == "" GOTO STEP0
@echo.
@echo Usage:
@echo   basename base-name
@echo.
@echo Options:
@echo   base-name       Base name (as specified in the module .INF).
@echo.
@echo Description:
@echo   This script changes the current directory to the directory which
@echo   contains the INF where BASE_NAME = base-name for the current project.
@echo.
@echo   The current project must already be set using su.bat
@goto exit

:STEP0
@IF NOT "%PROJECTTIP%"=="" GOTO STEP1
@echo Project not set. Please select a project tip using SU <project-name> <project-version>.
goto exit

:STEP1
@IF EXIST "%PROJECTTIP%\temp\module.list" GOTO STEP2
@echo Project %PROJECTTIP% not built.
goto exit

:STEP2
@FOR /F "tokens=1,2" %%G IN (%PROJECTTIP%\temp\module.list) DO @IF "%%G"=="%1" cd %%~pH

:exit

HOW-TO: Change directory to a specific INF for SecureCore Tiano™ 2.0

Once you have used su.bat (from the previous article), you can use this one to change to the directory that contains a specific INF file. It uses one of the files output by the build process.

inf inf-file-name

Here is the text for the batch file. It assumes that su.bat has already been used.

@IF NOT "%1" == "" GOTO STEP0
@echo.
@echo Usage:
@echo   inf inf-base-name
@echo.
@echo Options:
@echo   inf-base-name    Name of the INF file in the current project without .INF
@echo.
@echo Description:
@echo   This script changes the current directory to the directory which
@echo   contains the specified INF file for the current project.
@echo.
@echo   The current project must already be set using su.bat
@goto exit

:STEP0
@IF NOT "%PROJECTTIP%"=="" GOTO STEP1
@echo Project not set. Please select a project tip using SU <project-name> <project-version>.
goto exit

:STEP1
@IF EXIST "%PROJECTTIP%\temp\module.list" GOTO STEP2

@echo Project %PROJECTTIP% not built.
goto exit

:STEP2
@FOR /F "tokens=1,2" %%G IN (%PROJECTTIP%\temp\module.list) DO @IF "%%~nH"=="%1" cd %%~pH

:exit

[Updated to add help information]

HOW-TO: Set Up Your SecureCore Tiano™ 2.0 Build Environment

Here's a handy little batch file to set up your build environment for a specific project that I use. It is also the basis for several other useful batch files I will introduce later. It assumes that Visual Studio 2005 or Visual Studio 2008 are already in your build path and the ASL compiler is in C:\ASL.

Just go to the root directory of your SecureCore Tiano™ 2.0 source code and type:

su <project-name> [<project-version>]

If you just type 'su', it will list all projects available. If you type 'su' and a project name and there is only a single version, that will automatically be selected. If there is more than one version available, then the possible versions will be listed.

The batch file sets up two environment variables: PROJECTROOT (which is the root directory of the code) and PROJECTTIP (which is the build directory).

@if not "%1" == "" goto projectroot
@echo.
@echo Usage:
@echo   su project-name [project-version]
@echo.
@echo Options:
@echo   project-name     Name of the SecureCore Tiano(TM) project.
@echo   project-version  Version of the SecureCore Tiano(TM) project. Must be
@echo                    three numeric digits. If not specified, then 000 will
@echo                    be assumed.
@echo.
@echo Description:
@echo   This script sets up the key environment variables for building a project
@echo   for SecureCore Tiano(TM) 2.0.
@echo.
@echo   Select project-name from one of the following:
@dir /b Projects
@goto end

:projectroot
@if not "%PROJECTROOT%" == "" goto projectrev
@set PROJECTROOT=%CD%
@path=%PROJECTROOT%\tools;%path%

:projectrev
@set PROJECTTIPREV=%2
@if not "%PROJECTTIPREV%" == "" goto project
@if not exist "%PROJECTROOT%\Projects\%1\001\project.def" goto defaultprojectrev
@echo More than one project revision present at %PROJECTROOT%\Projects\%1.
@echo Please choose with su %1 xxx (where xxx is the revision) from the following:
@dir /b %PROJECTROOT%\Projects\%1
@goto end

:defaultprojectrev
@set PROJECTTIPREV=000

:project
@if exist "%PROJECTROOT%\Projects\%1\%PROJECTTIPREV%\project.def" goto projecttip
@echo Could not find project file at %PROJECTROOT%\Projects\%1\%PROJECTTIPREV%.
@goto end

:projecttip
@set PROJECTTIP=%PROJECTROOT%\Projects\%1\%PROJECTTIPREV%

:end

BIOS Mysteries: 64-Bits & General-Purpose Registers

Have you ever seen code like this?

mov ecx, 1
push rcx

What is going on here? It appears that the code is pushing a 64-bit value and the upper 32-bits are uninitialized.  No further clues arise from scouring through the  instruction set reference for MOV in Volume 2B of the Intel® 64 and IA-32 Architectures Software Developer’s Manual, where it says, "Both operands must be the same size, which can be a byte, a word, a doubleword, or a quadword." (page 3-641).

Is this a compiler bug? Well, I posed that question to the Microsoft Visual C++ gurus a while back and they pointed me to another part of the devref, this time section 3.4.1.1 of Volume 1, where it says:

When in 64-bit mode, operand size determines the number of valid bits in the destination general-purpose register:

• 64-bit operands generate a 64-bit result in the destination general-purpose register.
• 32-bit operands generate a 32-bit result, zero-extended to a 64-bit result in the destination general-purpose register.
• 8-bit and 16-bit operands generate an 8-bit or 16-bit result. The upper 56 bits or 48 bits (respectively) of the destination general-purpose register are not be modified by the operation. If the result of an 8-bit or 16-bit operation is intended for 64-bit address calculation, explicitly sign-extend the register to the full 64-bits.

Notice that in 64-bit mode, when the destination is a 32-bit general-purpose register, the upper 32-bits of the same register are zeroed!

Well, I didn't quite believe it, so I went to my handy American Arium and set up a test case. First, I initialized RCX to a known value. Then I stepped over an instruction which reloaded RCX with another value. Then I stepped over an instruction that just did a MOV ECX.  See the pictures below.

Sure enough! The upper 32-bits are zeroed and a mystery is solved.

HOW-TO: Add a raw binary file to your BIOS (Part 1)

Ever wonder how to get a raw binary file into your SecureCore Tiano™ so that there is just the file header, followed by your data? Well, create a new directory for your binary component. Copy your binary file there. Then create an INF file like the one below. Add the directory and file name of the INF into your DSC file.

If your want to have a binary file that has no header at all, it cannot sit in a firmware volume and must be using a different technique. Next time...

Tim

[defines]
  BASE_NAME = YourBinaryFile
  FILE_GUID = a5f54b78-64e6-40a2-88d2-1d941094c46e
  COMPONENT_TYPE = CONFIG
  FFS_EXT = .raw

#  The sources.common section below provides a list of source files to
#  be included in the MAKEFILE generated by ProcessDsc for this component.

[sources.common]
  $(BUILD_DIR)\YourBinaryFile.bin

[nmake.common]

 

HOW-TO: Decipher #include directory problems.

Having a problem with an #include file, but can’t tell where the error is coming from. Here’s what to do:

In the INF file for your component, go to [nmake.common] and add:

C_FLAGS = $(C_FLAGS) /showIncludes

Make sure you add a # BUGBUG so that you remember to come back and remove it later before you release!

 

SecureCore Tiano(TM) 2.0.