API: Difference between revisions

From coreboot
Jump to navigation Jump to search
No edit summary
mNo edit summary
Line 1: Line 1:
coreboot provides a couple of means to pass information on to the OS and payloads.


= Tables =
== Tables ==
 
coreboot provides a couple of means to pass information on to the OS and payloads.


* [[#coreboot_table|coreboot table]]
* [[#coreboot_table|coreboot table]]
Line 10: Line 9:
* Legacy BIOS interrupt calls (with [[LegacyBIOS]])
* Legacy BIOS interrupt calls (with [[LegacyBIOS]])


= Code Execution =
== Code execution ==


coreboot passes control to a payload or OS in form of a self contained ELF binary.
coreboot passes control to a [[payloads|payload]] or OS in form of a self contained ELF binary.


== coreboot table ==


= coreboot table =
The one central data structure in coreboot is the '''coreboot table'''. It is an extensible data structure providing the information gathered by coreboot to payloads and operating systems.


The one central data structure in coreboot is the coreboot table. It is an extensible data structure providing the information gathered by coreboot to payloads and operating systems.
The table usually sits in memory around address '''0x500'''. FIXME: describe how to search for the table correctly.
 
The table usually sits in memory around address 0x500. FIXME: describe how to search for the table correctly.


The table header looks like this:
The table header looks like this:
Line 35: Line 33:
</source>
</source>


 
Every entry in the boot enviroment list will correspond to a boot info record. Encoding both type and size. The type is obviously so you can tell what it is. The size allows you to skip that boot enviroment record if you don't know what it easy. This allows forward compatibility with records not yet defined.
Every entry in the boot enviroment list will correspond to a boot
info record. Encoding both type and size. The type is obviously
so you can tell what it is. The size allows you to skip that
boot enviroment record if you don't know what it easy. This allows
forward compatibility with records not yet defined.


<source lang="C">
<source lang="C">
Line 49: Line 42:
</source>
</source>


Entry Types:


== Entry Types ==
<source lang="C">
<source lang="C">
#define LB_TAG_UNUSED           0x0000
#define LB_TAG_UNUSED           0x0000
#define LB_TAG_MEMORY           0x0001
#define LB_TAG_MEMORY           0x0001
#define LB_TAG_HWRPB           0x0002
#define LB_TAG_HWRPB             0x0002
#define LB_TAG_MAINBOARD       0x0003
#define LB_TAG_MAINBOARD         0x0003
#define LB_TAG_VERSION         0x0004
#define LB_TAG_VERSION           0x0004
#define LB_TAG_EXTRA_VERSION   0x0005
#define LB_TAG_EXTRA_VERSION     0x0005
#define LB_TAG_BUILD           0x0006
#define LB_TAG_BUILD             0x0006
#define LB_TAG_COMPILE_TIME     0x0007
#define LB_TAG_COMPILE_TIME     0x0007
#define LB_TAG_COMPILE_BY       0x0008
#define LB_TAG_COMPILE_BY       0x0008
#define LB_TAG_COMPILE_HOST     0x0009
#define LB_TAG_COMPILE_HOST     0x0009
#define LB_TAG_COMPILE_DOMAIN   0x000a
#define LB_TAG_COMPILE_DOMAIN   0x000a
#define LB_TAG_COMPILER         0x000b
#define LB_TAG_COMPILER         0x000b
#define LB_TAG_LINKER           0x000c
#define LB_TAG_LINKER           0x000c
#define LB_TAG_ASSEMBLER       0x000d
#define LB_TAG_ASSEMBLER         0x000d
// 0x000e is used by device tree entry?
// 0x000e is used by device tree entry?
#define LB_TAG_SERIAL           0x000f
#define LB_TAG_SERIAL           0x000f
#define LB_TAG_CONSOLE         0x0010
#define LB_TAG_CONSOLE           0x0010
#define LB_TAG_CMOS_OPTION_TABLE 200
#define LB_TAG_CMOS_OPTION_TABLE 200
 
#define LB_TAG_OPTION           201
#define LB_TAG_OPTION 201
#define LB_TAG_OPTION_ENUM       202
#define LB_TAG_OPTION_ENUM 202
#define LB_TAG_OPTION_DEFAULTS   203
#define LB_TAG_OPTION_DEFAULTS 203
#define LB_TAG_OPTION_CHECKSUM   204
#define LB_TAG_OPTION_CHECKSUM 204
</source>

Revision as of 21:46, 5 October 2008

coreboot provides a couple of means to pass information on to the OS and payloads.

Tables

Code execution

coreboot passes control to a payload or OS in form of a self contained ELF binary.

coreboot table

The one central data structure in coreboot is the coreboot table. It is an extensible data structure providing the information gathered by coreboot to payloads and operating systems.

The table usually sits in memory around address 0x500. FIXME: describe how to search for the table correctly.

The table header looks like this:

<source lang="C"> struct lb_header {

       uint8_t  signature[4]; /* LBIO */
       uint32_t header_bytes;
       uint32_t header_checksum;
       uint32_t table_bytes;
       uint32_t table_checksum;
       uint32_t table_entries;

}; </source>

Every entry in the boot enviroment list will correspond to a boot info record. Encoding both type and size. The type is obviously so you can tell what it is. The size allows you to skip that boot enviroment record if you don't know what it easy. This allows forward compatibility with records not yet defined.

<source lang="C"> struct lb_record {

       uint32_t tag;           /* tag ID */
       uint32_t size;          /* size of record (in bytes) */

}; </source>

Entry Types:

<source lang="C">

  1. define LB_TAG_UNUSED 0x0000
  2. define LB_TAG_MEMORY 0x0001
  3. define LB_TAG_HWRPB 0x0002
  4. define LB_TAG_MAINBOARD 0x0003
  5. define LB_TAG_VERSION 0x0004
  6. define LB_TAG_EXTRA_VERSION 0x0005
  7. define LB_TAG_BUILD 0x0006
  8. define LB_TAG_COMPILE_TIME 0x0007
  9. define LB_TAG_COMPILE_BY 0x0008
  10. define LB_TAG_COMPILE_HOST 0x0009
  11. define LB_TAG_COMPILE_DOMAIN 0x000a
  12. define LB_TAG_COMPILER 0x000b
  13. define LB_TAG_LINKER 0x000c
  14. define LB_TAG_ASSEMBLER 0x000d

// 0x000e is used by device tree entry?

  1. define LB_TAG_SERIAL 0x000f
  2. define LB_TAG_CONSOLE 0x0010
  3. define LB_TAG_CMOS_OPTION_TABLE 200
  4. define LB_TAG_OPTION 201
  5. define LB_TAG_OPTION_ENUM 202
  6. define LB_TAG_OPTION_DEFAULTS 203
  7. define LB_TAG_OPTION_CHECKSUM 204

</source>