API: Difference between revisions

From coreboot
Jump to navigation Jump to search
mNo edit summary
 
(2 intermediate revisions by 2 users not shown)
Line 6: Line 6:
* [[Creating_Valid_IRQ_Tables|IRQ table]]
* [[Creating_Valid_IRQ_Tables|IRQ table]]
* [[Glossary#MPTable|MP table]]
* [[Glossary#MPTable|MP table]]
* [[ACPI_in_coreboot|ACPI tables]]
* [[ACPI|ACPI tables]]
* Legacy BIOS interrupt calls (with [[LegacyBIOS]])
* Legacy BIOS interrupt calls (with [[SeaBIOS]])


== Code execution ==
== Code execution ==
Line 33: 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 is. This allows forward compatibility with records not yet defined.


<source lang="C">
<source lang="C">
Line 62: Line 62:
#define LB_TAG_SERIAL            0x000f
#define LB_TAG_SERIAL            0x000f
#define LB_TAG_CONSOLE          0x0010
#define LB_TAG_CONSOLE          0x0010
#define LB_TAG_FORWARD          0x0011
#define LB_TAG_FRAMEBUFFER      0x0012
#define LB_TAG_CMOS_OPTION_TABLE 200
#define LB_TAG_CMOS_OPTION_TABLE 200
#define LB_TAG_OPTION            201
#define LB_TAG_OPTION            201

Latest revision as of 08:53, 18 December 2013

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 is. 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_FORWARD 0x0011
  4. define LB_TAG_FRAMEBUFFER 0x0012
  1. define LB_TAG_CMOS_OPTION_TABLE 200
  2. define LB_TAG_OPTION 201
  3. define LB_TAG_OPTION_ENUM 202
  4. define LB_TAG_OPTION_DEFAULTS 203
  5. define LB_TAG_OPTION_CHECKSUM 204

</source>