DSDT: Difference between revisions
| [unchecked revision] | [unchecked revision] |
(Created a page with some basic information) |
|||
| Line 2: | Line 2: | ||
===Introduction=== |
===Introduction=== |
||
{{stub}} |
{{stub}} |
||
DSDT stands for ''Differentiated System Description Table''. It Is a major [[ACPI]] table and is used when powering down by the OS |
DSDT stands for ''Differentiated System Description Table''. It Is a major [[ACPI]] table and is used to describe what peripherals the machine has. Also holds information on PCI IRQ mappings and power management. For example when powering down by the OS, it should find the _S5 object which describes how to do that. It is pointed to by the [[FADT]] |
||
===How hardware manufacturers generate it=== |
|||
You can use an ASL (ACPI Source Language) compiler to generate DSDT AML (ACPI Machine Language) bytecode from a C-like language. To get an idea, take a glimpse on bochs source: |
|||
* bios/acpi-dsdt.dsl for human readable source |
|||
* bios/acpi-dsdt.hex for hex dump of the bytecode output |
|||
For example here's the description of the [[RTC|Real Time Clock]]: |
|||
<source lang="c"> |
|||
/* PIIX3 ISA bridge */ |
|||
Device (ISA) { |
|||
Name (_ADR, 0x00010000) |
|||
/* PIIX PCI to ISA irq remapping */ |
|||
OperationRegion (P40C, PCI_Config, 0x60, 0x04) |
|||
/* Real-time clock */ |
|||
Device (RTC) |
|||
{ |
|||
Name (_HID, EisaId ("PNP0B00")) |
|||
Name (_CRS, ResourceTemplate () |
|||
{ |
|||
IO (Decode16, 0x0070, 0x0070, 0x10, 0x02) |
|||
IRQNoFlags () {8} |
|||
IO (Decode16, 0x0072, 0x0072, 0x02, 0x06) |
|||
}) |
|||
} |
|||
</source> |
|||
and what's it became after compilation: |
|||
<pre> |
|||
0x00,0xA4,0x00,0x5B,0x82,0x42,0x23,0x49, /* 00000270 "...[.B#I" */ |
|||
0x53,0x41,0x5F,0x08,0x5F,0x41,0x44,0x52, /* 00000278 "SA_._ADR" */ |
|||
0x0C,0x00,0x00,0x01,0x00,0x5B,0x80,0x50, /* 00000280 ".....[.P" */ |
|||
0x34,0x30,0x43,0x02,0x0A,0x60,0x0A,0x04, /* 00000288 "40C..`.." */ |
|||
0x5B,0x82,0x2D,0x52,0x54,0x43,0x5F,0x08, /* 00000290 "[.-RTC_." */ |
|||
0x5F,0x48,0x49,0x44,0x0C,0x41,0xD0,0x0B, /* 00000298 "_HID.A.." */ |
|||
0x00,0x08,0x5F,0x43,0x52,0x53,0x11,0x18, /* 000002A0 ".._CRS.." */ |
|||
0x0A,0x15,0x47,0x01,0x70,0x00,0x70,0x00, /* 000002A8 "..G.p.p." */ |
|||
0x10,0x02,0x22,0x00,0x01,0x47,0x01,0x72, /* 000002B0 ".."..G.r" */ |
|||
0x00,0x72,0x00,0x02,0x06,0x79,0x00,0x5B, /* 000002B8 ".r...y.[" */ |
|||
0x82,0x44,0x04,0x4B,0x42,0x44,0x5F,0x08, /* 000002C0 ".D.KBD_." */ |
|||
</pre> |
|||
Most likely you will never generate such a binary. But it helps if you know it's source form when you came to decode. |
|||
===Purpose of DSDT=== |
|||
When your OS boots, it should parse the memory for [[ACPI]] tables. Then locate DSDT (and other tables as well, like [[FADT]]), and decode it to get the list of installed devices. If you have that list, it's rather easy to load [[device driver]] for each. |
|||
Also note that there are buggy tables, so you should always kept the possibility to load DSDT data from a user provided file instead. This file could be located in your [[initrd|initial ramdisk]], loaded with your kernel along on boot. That would solve the chicken-egg problem of loading the DSDT file from a device that's IO addresses is defined in the DSDT. |
|||
==See Also== |
==See Also== |
||
===ACPI=== |
===ACPI=== |
||
Revision as of 20:26, 7 March 2012
DSDT
Introduction
DSDT stands for Differentiated System Description Table. It Is a major ACPI table and is used to describe what peripherals the machine has. Also holds information on PCI IRQ mappings and power management. For example when powering down by the OS, it should find the _S5 object which describes how to do that. It is pointed to by the FADT
How hardware manufacturers generate it
You can use an ASL (ACPI Source Language) compiler to generate DSDT AML (ACPI Machine Language) bytecode from a C-like language. To get an idea, take a glimpse on bochs source:
- bios/acpi-dsdt.dsl for human readable source
- bios/acpi-dsdt.hex for hex dump of the bytecode output
For example here's the description of the Real Time Clock:
/* PIIX3 ISA bridge */
Device (ISA) {
Name (_ADR, 0x00010000)
/* PIIX PCI to ISA irq remapping */
OperationRegion (P40C, PCI_Config, 0x60, 0x04)
/* Real-time clock */
Device (RTC)
{
Name (_HID, EisaId ("PNP0B00"))
Name (_CRS, ResourceTemplate ()
{
IO (Decode16, 0x0070, 0x0070, 0x10, 0x02)
IRQNoFlags () {8}
IO (Decode16, 0x0072, 0x0072, 0x02, 0x06)
})
}
and what's it became after compilation:
0x00,0xA4,0x00,0x5B,0x82,0x42,0x23,0x49, /* 00000270 "...[.B#I" */
0x53,0x41,0x5F,0x08,0x5F,0x41,0x44,0x52, /* 00000278 "SA_._ADR" */
0x0C,0x00,0x00,0x01,0x00,0x5B,0x80,0x50, /* 00000280 ".....[.P" */
0x34,0x30,0x43,0x02,0x0A,0x60,0x0A,0x04, /* 00000288 "40C..`.." */
0x5B,0x82,0x2D,0x52,0x54,0x43,0x5F,0x08, /* 00000290 "[.-RTC_." */
0x5F,0x48,0x49,0x44,0x0C,0x41,0xD0,0x0B, /* 00000298 "_HID.A.." */
0x00,0x08,0x5F,0x43,0x52,0x53,0x11,0x18, /* 000002A0 ".._CRS.." */
0x0A,0x15,0x47,0x01,0x70,0x00,0x70,0x00, /* 000002A8 "..G.p.p." */
0x10,0x02,0x22,0x00,0x01,0x47,0x01,0x72, /* 000002B0 ".."..G.r" */
0x00,0x72,0x00,0x02,0x06,0x79,0x00,0x5B, /* 000002B8 ".r...y.[" */
0x82,0x44,0x04,0x4B,0x42,0x44,0x5F,0x08, /* 000002C0 ".D.KBD_." */
Most likely you will never generate such a binary. But it helps if you know it's source form when you came to decode.
Purpose of DSDT
When your OS boots, it should parse the memory for ACPI tables. Then locate DSDT (and other tables as well, like FADT), and decode it to get the list of installed devices. If you have that list, it's rather easy to load device driver for each.
Also note that there are buggy tables, so you should always kept the possibility to load DSDT data from a user provided file instead. This file could be located in your initial ramdisk, loaded with your kernel along on boot. That would solve the chicken-egg problem of loading the DSDT file from a device that's IO addresses is defined in the DSDT.