Vol. 2, No. 1 (2005) http://www.CodeBreakers-Journal.com Low Cost Embedded x86 Teaching Tool MS Darmawan* * Corresponding Author Received: 19. Apr. 2005, Accepted: 23. Apr. 2005, Published: 24. Feb. 2005 Abstract The wide availability of personal computer based on the x86 architecture that conform to the PCI specification version 2.1 and Plug and Play BIOS specification version 1.0A or higher, along with the existence of free open source software development tools for this architecture, provides an opportunity to create a low cost embedded system teaching tool based on it. In this paper we will explain one of the implementation of this idea by exploiting the so called "Bootstrap Entry Vector" that exist as part of the Plug and Play BIOS. Keywords: Embedded, X86, Teaching Tool Copyright 2005 by the author and published by the CodeBreakers-Journal. Single print or electronic copies for personal use only are permitted. Reproduction and distribution without permission is prohibited. This article can be found at http://www.CodeBreakers- Journal.com. Vol. 2, No. 1 (2005), http://www.CodeBreakers-Journal.com 1. Introduction The main obstacle of teaching embedded system development in various universities is the cost of the hardware used for development and possibly the cost of the software tool. The existence of free open source software development tools for many processor architecture in recent years has solved the problem of the cost of the software tool needed. However, the cost of the hardware remains quite high for college students to afford. Especially in developing nation like in Indonesia, where cost is the main issue. From cost point of view, the PC itself is still affordable for the students, since it's used for wide variety of task, not just embedded system development. Meanwhile, buying hardware for embedded system development board can easily cost more than an entry-level PC or refurbished PC. In this paper we explore the possibility to develop a low cost tool for teaching embedded system in the x86 processor architecture based on the PCI expansion ROM. It will become a playing-ground for the students to learn embedded system development in x86 platform. The term PCI expansion ROM in this paper is the PCI firmware which is embedded in a PCI expansion card. It's also sometimes called PCI option ROM. We will use the term interchangeably. PCI expansion ROM has a broader meaning than the definition that has been mentioned above, but we are focusing on that type of expansion ROM in this paper. The reader might be aware that PCI expansion ROM can also be embedded inside the main board BIOS as a component. We are not considering the latter type of PCI expansion ROM here. We are going to demonstrate the development of a custom PCI expansion ROM that is going to be embedded in "special" PCI expansion card by using free open source software development tool. This PCI expansion ROM and it's corresponding "special" PCI expansion card is the hardware-software complex that acts as the embedded system development teaching tool. The cost of this hardware- software complex can be very low (the cost of the PC is not included), from around Rp. 25.000,00 (around US $ 2.5) to nothing at all if we can find the PCI expansion card from junk yard. 2. Prerequisite 2.1. x86 Memory Map Understanding of the x86 memory map is a must to be able to develop an embedded system based on this platform. We will start with the explanation of the booting process. An x86 CPU begins its execution at address FFFFFFF0h physical address[1]. This address is the address of the first instruction within the main board (system) bios. It's the responsibility of the main board chipset to remap this address into the system bios chip. The system bios is the very first program that the processor executes. Below is an explanation of the typical memory map of an x86 based system just after the system bios finished initialization. In the memory map above, of particular interest is the expansion ROM area. We will be dealing with this area later as we are developing the custom PCI expansion ROM. Copyright 2005 by the author and published by the CodeBreakers-Journal. Single print or electronic copies for personal use only are permitted. Reproduction and distribution without permission is prohibited. This article can be found at http://www.CodeBreakers- Journal.com. Vol. 2, No. 1 (2005), http://www.CodeBreakers-Journal.com Address Range Detailed Explanation DOS Area (00000h–9FFFFh) The DOS area is 640 KB in size and is always mapped to the main memory (RAM) by mainboard chipset Legacy VGA Ranges and/or Compatible SMRAM Address Range (A0000h– BFFFFh) The legacy 128-KB VGA memory range A0000h–BFFFFh (Frame Buffer) can be mapped to AGP or PCI Device. However, when compatible SMM space is enabled, SMM-mode processor accesses to this range are routed to physical system memory at this address. Non-SMM-mode processor accesses to this range are considered to be to the video buffer area as described above. Expansion ROM Area (C0000h–DFFFFh) This is the 128-KB ISA/PCI Expansion ROM region. The system BIOS copies PCI expansion ROM to this area (in RAM) from the corresponding PCI expansion card ROM chip and execute it from there. As for ISA expansion ROM, it only exist on system that support ISA expansion card and sometimes the expansion ROM chip of the Compatibility area corresponding card is "hardwired" certain memory range in this area. In most case, part (0_0000h - F_FFFFh) of this memory range can be assigned one of four read/write states: read only, write only, read/write, or disabled. This state assigment is controlled by the setting of certain mainboard chipset registers. The system BIOS is responsible for assigning the correct read/write state. Extended System BIOS Area (E0000h–EFFFFh) This 64-KB area is divided into four, 16-KB segments. Each segment can be assigned independent read and write attributes so it can be mapped either to main memory or to the BIOS ROM chip via the system chipset. Typically, this area is used for RAM or ROM. On systems that only supports 64KB BIOS ROM chip capacity, this memory area always mapped to RAM. System BIOS Area (F0000h–FFFFFh) This area is a single, 64-KB segment. This segment can be assigned read and write attributes. It is by default (after reset) read/write disabled and cycles are forwarded to BIOS ROM chip via the system chipset. By manipulating the read/write attributes, the system chipset can “shadow” BIOS into the main memory. When disabled, this range is not remapped to main memory by the chipset. Main system memory from 1 MB (10_0000h) to the Top of of RAM This area can have a hole i.e. an area that is not mapped to RAM but mapped to ISA devices. This hole is dependent on the mainboard chipset configuration AGP or PCI memory space from the Top of RAM to 4 GB (FFFF_FFFFh) This area has 2 specific ranges : • APIC Configuration Space from FEC0_0000h (4 GB-20 MB) to FECF_FFFFh and FEE0_0000h to FEEF_FFFFh. This is also dependent on the mainboard chipset. Some chipset doesn't support APIC, hence this mapping doesn't exist. • High BIOS area from 4 GB to 4 GB – 2 MB. This address range mapped into Extended Memory Area the BIOS ROM chip. But it's dependent on the mainboard chipset. Some (10_0000h - FFFF_FFFFh) chipset only support mapping 4 GB - (4GB-256KB) for BIOS ROM chip. However, the 4 GB - (4GB-64KB) memory area is the least common denominator for all chipsets, this area is guaranteed to map into the BIOS ROM chip. In most case, anything outside of these specific ranges but within the PCI memory space (top of RAM - 4GB) is mapped to PCI/AGP device that needs to map their "local memory" (memory local to the PCI card) to system memory space. This mapping is normally initialized by system BIOS. Access to this memory space is routed by the system chipset (memory controller). In the case of AMD Athlon64 and Opteron platform, this routing is handled by the processor itself, since the memory controller is embedded in the processor itself [2]. Copyright 2005 by the author and published by the CodeBreakers-Journal. Single print or electronic copies for personal use only are permitted. Reproduction and distribution without permission is prohibited. This article can be found at http://www.CodeBreakers- Journal.com. Vol. 2, No. 1 (2005), http://www.CodeBreakers-Journal.com 2.2. PnP BIOS Architecture In this section, we are not going to provide a complete explanation of the PnP BIOS architecture. We will only explain parts of the PnP BIOS architecture that are needed to develop our hardware-software complex. A more thorough explanation regarding the system BIOS can be found in Award BIOS Reverse Engineering Paper [3]. The parts of PnP BIOS that are important to our project are the initialization of expansion/option ROM, i.e. initialization code that resides in the expansion cards and the bootstrap process, i.e. transferring control from BIOS to operating system after the BIOS has done initializing the system. Initialization of option ROM is part of the POST (Power-On Self Test) routine in the system BIOS. The related information from the PnP BIOS Specification 1.0A [5] are provided below. 2.2.1. POST Execution flow The following steps outline a typical flow of a Plug and Play system BIOS POST. All of the standard ISA functionality has been eliminated for clarity in understanding the Plug and Play POST enhancements. Step 1 Disable all configurable devices Any configurable devices known to the system BIOS should be disabled early in the POST process. Step 2 Identify all Plug and Play ISA devices Assign Card Select Numbers (CSNs) to Plug and Play ISA devices but keep devices disabled. Also determine which devices are boot devices. Step 3 Construct an initial resource map of allocated resources Construct a resource map of resources that are statically allocated to devices in the system. If the system software has explicitly specified the system resources assigned to ISA devices in the system through the Set Statically Allocated Resource Information function, the system BIOS will create an initial resource map based on this information. If the BIOS implementation provides support for saving the last working configuration and the system software has explicitly assigned system resources to specific devices in the system, then this information will be used to construct the resource map. This information will also be used to configure the devices in the system. Step 4 Enable Input and Output Devices Select and enable the Input and Output Device. Compatibility devices in the system that are not configurable always have precedence. For example, a standard VGA adapter would become the primary output device. If configurable Input and Output Devices exists, then enable these devices at this time. If Plug and Play Input and Output Devices are being selected, then initialize the option ROM, if it exists, using the Plug and Play option ROM initialization procedure. Step 5 Perform ISA ROM scan The ISA ROM scan should be performed from C0000h to EFFFFh on every 2K boundary. Plug and Play Option ROMs are disabled at this time (except input and output boot devices) and will not be included in the ROM scan. Step 6 Configure the Initial Program Load(IPL) device If a Plug and Play device has been selected as the IPL device, then use the Plug and Play Option ROM procedure to initialize the device. If the IPL device is known to the system BIOS, then ensure that interrupt 19h is still controlled by the system BIOS. If not, recapture interrupt 19h and save the vector. Copyright 2005 by the author and published by the CodeBreakers-Journal. Single print or electronic copies for personal use only are permitted. Reproduction and distribution without permission is prohibited. This article can be found at http://www.CodeBreakers- Journal.com. Vol. 2, No. 1 (2005), http://www.CodeBreakers-Journal.com Step 7 Enable Plug and Play ISA and other Configurable Devices If a static resource allocation method is used, then enable the Plug and Play ISA cards with conflict free resource assignments. Initialize the option ROMs and pass along the defined parameters. All other configurable devices should be enabled, if possible, at this time. If a dynamic resource allocation method is used, then enable the bootable Plug and Play ISA cards with conflict free resource assignments and initialize the option ROMs. Step 8 Initiate the Interrupt 19H IPL sequence Start the bootstrap loader. If the operating system fails to load and a previous ISA option ROM had control of the interrupt 19h vector, then restore the interrupt 19h vector to the ISA option ROM and re-execute the Interrupt 19h bootstrap loader. Step 9 Operating system takes over resource management If the loaded operating system is Plug and Play compliant, then it will take over management of the system resources. It will use the runtime services of the system BIOS to determine the current allocation of these resources. It is assumed that any unconfigured Plug and Play devices will be configured by the appropriate system software or the Plug and Play operating system. 2.2.2. Option ROM Support This section outlines the Plug and Play Option ROM requirements. This Option ROM support is directed specifically towards boot devices; however, the Static Resource Information Vector permits non-Plug and Play devices which have option ROMs to take advantage of the Plug and Play Option ROM expansion header to assist a Plug and Play environment whether or not it is a boot device. A boot device is defined as any device which must be initialized prior to loading the Operating System. Strictly speaking, the only required boot device is the Initial Program Load (IPL) device upon which the operating system is stored. However, the definition of boot devices is extended to include a primary Input Device and a primary Output device. In some situations these I/O devices may be required for communication with the user. All new Plug and Play devices that support Option ROMs should support the Plug and Play Option ROM Header. In addition, all non-Plug and Play devices may be "upgraded" to support the Plug and Play Option ROM header as well. While these static ISA devices will still not have software configurable resources, the Plug and Play Option ROM Header will greatly assist a Plug and Play System BIOS in identification and selection of the primary boot devices. It is important to note that the Option ROM support outlined here is defined specifically for computing platforms based on the Intel X86 family of microprocessors and may not apply to systems based on other types of microprocessors. 2.2.2.1. Option ROM Header The Plug and Play Option ROM Header follows the format of the Generic Option ROM Header extensions . The Generic Option ROM header is a mechanism whereby the standard ISA Option ROM header may be expanded with minimal impact upon existing Option ROMs. The pointer at offset 1Ah may point to ANY type of header. Each header provides a link to the next header; thus, future Option ROM headers may use this same generic pointer and still coexist with the Plug and Play Option ROM header. Each Option ROM header is identified by a unique string. The length and checksum bytes allow the System BIOS and/or System Software to verify that the header is valid. Standard Option ROM Header: Copyright 2005 by the author and published by the CodeBreakers-Journal. Single print or electronic copies for personal use only are permitted. Reproduction and distribution without permission is prohibited. This article can be found at http://www.CodeBreakers- Journal.com. Vol. 2, No. 1 (2005), http://www.CodeBreakers-Journal.com Offset Length Value Description Type 0h 2h AA55h Signature Standard 2h 1h Varies Option ROM Length Standard 3h 4h Varies Initialization Vector Standard 7h 13h Varies Reserved Standard 1Ah 2h Varies Offset to Expansion Header Structure New for Plug and Play 1. Signature - All ISA expansion ROMs are currently required to identify themselves with a signature WORD of AA55h at offset 0. This signature is used by the System BIOS as well as other software to identify that an Option ROM is present at a given address. 2. Length - The length of the option ROM in 512 byte increments. 3. Initialization vector - The system BIOS will execute a FAR CALL to this location to initialize the Option ROM. A Plug and Play System BIOS will identify itself to a Plug and Play Option ROM by passing a pointer to a Plug and Play Identification structure when it calls the Option ROM's initialization vector. If the Option ROM determines that the System BIOS is a Plug and Play BIOS, the Option ROM should not hook the input, display, or IPL device vectors (INT 9h, 10h, or 13h) at this time. Instead, the device should wait until the System BIOS calls the Boot Connection vector before it hooks any of these vectors. Note: A Plug and Play device should never hook INT 19h or INT 18h until its Boot Connection Vector, offset 16h of the Expansion Header Structure (section 3.2), has been called by the Plug and Play system BIOS. If the Option ROM determines that it is executing under a Plug and Play system BIOS, it should return some device status parameters upon return from the initialization call. See the section on Option ROM Initialization for further details. The field is four bytes wide even though most implementations may adhere to the custom of defining a simple three byte NEAR JMP. The definition of the fourth byte may be OEM specific. 4. Reserved - This area is used by various vendors and contains OEM specific data and copyright strings. 5. Offset to Expansion Header - This location contains a pointer to a linked list of Option ROM expansion headers. Various Expansion Headers (regardless of their type) may be chained together and accessible via this pointer. The offset specified in this field is the offset from the start of the option ROM header. Copyright 2005 by the author and published by the CodeBreakers-Journal. Single print or electronic copies for personal use only are permitted. Reproduction and distribution without permission is prohibited. This article can be found at http://www.CodeBreakers- Journal.com. Vol. 2, No. 1 (2005), http://www.CodeBreakers-Journal.com 2.2.2.2. Expansion Header for Plug and Play Offset Length Value Description 4 $PnP 0h Signature Generic BYTES (ASCII) 04h BYTE Varies Structure Revision 01h 05h BYTE Varies Length (in 16 byte increments) Generic 06h WORD Varies Offset of next Header (0000h if none) Generic 08h BYTE 00h Reserved Generic 09h BYTE Varies Checksum Generic PnP 0Ah DWORD Varies Device Identifier Specific PnP 0Eh WORD Varies Pointer to Manufacturer String (Optional) Specific PnP 10h WORD Varies Pointer to Product Name String (Optional) Specific PnP 12h 3 BYTE Varies Device Type Code Specific PnP 15h BYTE Varies Device Indicators Specific PnP 16h WORD Varies Boot Connection Vector - Real/Protected mode (0000h if none) Specific PnP 18h WORD Varies Disconnect Vector - Real/Protected mode (0000h if none) Specific PnP 1Ah WORD Varies Bootstrap Entry Point - Real/Protected mode (0000h if none) Specific PnP 1Ch WORD 0000h Reserved Specific Static Resource Information Vector- Real/Protected mode (0000h PnP 1Eh WORD Varies if none) Specific Signature - All Expansion Headers will contain a unique expansion header identifier. The Plug and Play expansion header's identifier is the ASCII string "$PnP" or hex 24 50 6E 50h (Byte 0 = 24h ... Byte 3 = 50h). Structure Revision - This is an ordinal value that indicates the revision number of this structure only and does not imply a level of compliance with the Plug and Play BIOS version. Length - Length of the entire Expansion Header expressed in sixteen byte blocks. The length count starts at the Signature field. Offset of Next Header - This location contains a link to the next expansion ROM header in this Option ROM. If there are no other expansion ROM headers, then this field will have a value of 0h. The offset specified in this field is the offset from the start of the option ROM header. Reserved - Reserved for Expansion Copyright 2005 by the author and published by the CodeBreakers-Journal. Single print or electronic copies for personal use only are permitted. Reproduction and distribution without permission is prohibited. This article can be found at http://www.CodeBreakers- Journal.com. Vol. 2, No. 1 (2005), http://www.CodeBreakers-Journal.com Checksum - Each Expansion Header is checksummed individually. This allows the software which wishes to make use of an expansion header (in this case, the system BIOS) the ability to determine if the expansion header is valid. The method for validating the checksum is to add up all byte values in the Expansion Header, including the Checksum field, into an 8-bit value. A resulting sum of zero indicates a valid checksum operation. Device Identifier - This field contains the Plug and Play Device ID. Pointer to Manufacturer String (Optional) - This location contains an offset relative to the base of the Option ROM which points to an ASCIIZ representation of the board manufacturer's name. This field is optional and if the pointer is 0 (Null) then the Manufacturer String is not supported. Pointer to Product Name String (Optional) - This location contains an offset relative to the base of the Option ROM which points to an ASCIIZ representation of the product name. This field is optional and if the pointer is 0 (Null) then the Product Name String is not supported. Device Type Code - This field contains general device type information that will assist the System BIOS in prioritizing the boot devices. The Device Type code is broken down into three byte fields. The byte fields consist of a Base-Type code that indicates the general device type. The second byte is the device Sub-Type and its definition is Plug and Play BIOS Specification 1.0A Page 18 dependent upon the Base-Type code. The third byte defines the specific device programming interface, IF.-Type, based on the Base-Type and Sub-Type. Refer to Plug and Play BIOS Specification 1.0A Appendix B for a description of Device Type Codes. Device Indicators - This field contains indicator bits that identify the device as being capable of being one of the three identified boot devices: Input, Output, or Initial Program Load (IPL). Bit Description 7 A 1 indicates that this ROM supports the Device Driver Initialization Model 6 A 1 indicates that this ROM may be Shadowed in RAM 5 A 1 indicates that this ROM is Read Cacheable 4 A 1 indicates that this option ROM is only required if this device is selected as a boot device. 3 Reserved (0) 2 A 1 in this position indicates that this device is an Initial Program Load (IPL) device. 1 A 1 in this position indicates that this device is an Input device. 0 A 1 in this position indicates that this device is a Display device. Boot Connection Vector (Real/Protected mode) - This location contains an offset from the start of the option ROM header to a routine that will cause the Option ROM to hook one or more of the primary input, primary display, or Initial Program Load (IPL) device vectors (INT 9h, INT 10h, or INT 13h), depending upon the parameters passed during the call. When the system BIOS has determined that the device controlled by this Option ROM will be one of the boot devices (the Primary Input, Primary Display, or IPL device), the System ROM will execute a FAR CALL to the location pointed to by the Boot Connection Vector. The system ROM will pass the following parameters to the options ROM's Boot Connection Vector: Copyright 2005 by the author and published by the CodeBreakers-Journal. Single print or electronic copies for personal use only are permitted. Reproduction and distribution without permission is prohibited. This article can be found at http://www.CodeBreakers- Journal.com. Vol. 2, No. 1 (2005), http://www.CodeBreakers-Journal.com Reg On Description Entry Provides an indication as to which vectors should be hooked by specifying the type of boot device this device has been selected as. Bit 7..3 Reserved(0) AX Bit 2 1=Connect as IPL (INT 13h) Bit 1 1=Connect as primary Video (INT 10h) Bit 0 1=Connect as primary Input (INT 09h) ES:DI Pointer to System BIOS PnP Installation Check Structure (See section 4.4) CSN for this card, ISA PnP devices only. If not an ISA PnP device then this parameter BX will be set to FFFFh. Read Data Port, (ISA PnP devices only. If no ISA PnP devices then this parameter will DX be set to FFFFh. Disconnect Vector (Real/Protected mode) - This vector is used to perform a cleanup from an unsuccessful boot attempt on an IPL device. The system ROM will execute a FAR CALL to this location on IPL failure. Bootstrap Entry Vector (Real/Protected mode) - This vector is used primarily for RPL (Remote Program Load) support. To RPL (bootstrap), the System ROM will execute a FAR CALL to this location. The System ROM will call the Real/Protected Mode Bootstrap Entry Vector instead of INT 19h if: a) The device indicates that it may function as an IPL device, b) The device indicates that it does not support the INT 13h Block Mode interface, c) The device has a non-null Bootstrap Entry Vector, d) The Real/Protected Mode Boot Connection Vector is null. The method for supporting RPL is beyond the scope of this specification. A separate specification should define the explicit requirements for supporting RPL devices. Reserved - Reserved for Expansion Static Resource Information Vector - This vector may be used by non-Plug and Play devices to report static resource configuration information. Plug and Play devices should not support the Static Resource Information Vector for reporting their configuration information. This vector should be callable both before and/or after the option ROM has been initialized. The call interface for the Static Resource Information Vector is as follows: Copyright 2005 by the author and published by the CodeBreakers-Journal. Single print or electronic copies for personal use only are permitted. Reproduction and distribution without permission is prohibited. This article can be found at http://www.CodeBreakers- Journal.com. Vol. 2, No. 1 (2005), http://www.CodeBreakers-Journal.com Entry: Pointer to memory buffer to hold the device's static resource configuration information. The buffer ES:DI should be a minimum of 1024 bytes. This information should follow the System Device Node data structure, except that the Device node number field should always be set to 0, and the information returned should only specify the currently allocated resources (Allocated resource configuration descriptor block) and not the block of possible resources (Possible resource configuration descriptor block). The Possible resource configuration descriptor block should only contain the END_TAG resource descriptor to indicate that there are no alternative resource configuration settings for this device because the resource configuration for this device is static. Refer to the Plug and Play ISA Specification under the section labeled Plug and Play Resources for more information about the resource descriptors. This data structure has the following format: Field Size Size of the device node WORD Device node number/handle BYTE Device product identifier DWORD Device type code 3 BYTES Device node attribute bit-field WORD Allocated resource configuration descriptor block VARIABLE Possible resource configuration descriptor block - should only specify the END_TAG 2 BYTES resource descriptor Compatible device identifiers VARIABLE Refer to section 4.2 for a complete description of the elements that make up the System Device Node data structure. For example, an existing, non-Plug and Play SCSI card vendor could choose to rev the SCSI board's Option ROM to support the Plug and Play Expansion Header. While this card wouldn't gain any of the configuration benefits provided to full hardware Plug and Play cards, it would allow Plug and Play software to determine the devices configuration and thus ensure that Plug and Play cards will map around the static SCSI board's allocated resources. 2.2.2.3. Option ROM Initialization The System BIOS will determine if the Option ROM it is about to initialize supports the Plug and Play interface by verifying the Structure Revision number in the device's Plug and Play Header Structure. For all Option ROMs compliant with the 1.0 Plug and Play BIOS Specification, the System BIOS will call the device's initialization vector with the following parameters: Reg On Description Entry ES:DI Pointer to System BIOS PnP Installation Check Structure (See section 4.4) CSN for this card, ISA PnP devices only. If not an ISA PnP device then this parameter BX will be set to FFFFh Read Data Port, (ISA PnP devices only. If no ISA PnP devices then this parameter will DX be set to FFFFh. For other bus architectures refer to the appropriate specification for register parameters on entry. During initialization, a Plug and Play Option ROM may hook any vectors and update any data structures required for it to access any attached devices and perform the necessary identifications and Copyright 2005 by the author and published by the CodeBreakers-Journal. Single print or electronic copies for personal use only are permitted. Reproduction and distribution without permission is prohibited. This article can be found at http://www.CodeBreakers- Journal.com.