13

We can declare platform device information in dts file, rather than hard coding every data into operating system. Taking "arm" architecture as example. it supports dts and we will take dts from arch/arm/boot/dts/xx.dts. Convert this xx.dts into xx.dtb and loaded with kernel Image. I recently came across ACPI, when i came across x86 architecture, from the documents, what i understood is ACPI is similar to device tree. We can declare platform device information information in ACPI tables, my doubt is where exactly these ACPI tables present. How can i load this info to linux. What is the advantage of using ACPI over dts. Please correct me if i am wrong. Thanks in advance

anikhan
  • 964
  • 2
  • 13
  • 35
  • 2
    ACPI tables are located in the firmware. In particular you are interested in DSDT one. You may also override them (see http://stackoverflow.com/questions/32177990/iommu-initialization-without-bios-support). – 0andriy Aug 31 '15 at 15:07
  • Thanks Andy for your comment, I want to add platform device information in Linux while compiling for (intel atom x86 based board), in linux where exactly i can add this information. Similar to arm, where i am adding in arch/arm/boot/xx.dts. – anikhan Sep 01 '15 at 08:40
  • @anikhan, on ARM you don't just put something in xx.dts, you tell the firmware to load the compiled dtb file and pass a pointer to it to the loaded kernel. On x86 the kernel takes all the platform information from ACPI tables that are provided by the firmware (which is usually called BIOS for x86). You can't put arbitrary platform info there. If anything is missing, that means your BIOS is not good enough - it either doesn't detect a pluggable device, or it doesn't provide information about a hard-wired/soldered part of the platform. Fix the firmware, not Linux. – Alexander Amelkin Jun 07 '17 at 15:18
  • First of all, don't forget to add a nickname of the person (starts with **@**) you are commenting to, otherwise will be blast from the past. – 0andriy Jan 10 '20 at 08:02

3 Answers3

5

Breathe with lungs or gills? Depends on where you live.

A rough classification of architectures is 

x86 - Server/PC - ACPI table 
ARM - embedded systems - Device Tree

On server/PC motherboards, the ACPI table is a part of the UEFI firmware, which resides on the flash chip. The OS would be installed later somewhere else (hard drive or so). The OS parses the ACPI table, but OS developers don't control what is already written in the firmware; or they don't even know the internal design of the board. The board vendor (firmware provider) needs to support whatever OS to be installed, not only Linux, so they have to follow standards (UEFI), instead of focusing on a Linux thing, such as device tree.

On embedded systems, OS and everything else are programmed once by the vendor and never again by the user. The OS is part of the firmware. So no need to worry about the OS support matrix, and just have a 1-to-1 relationship between the board and your OS image. U-Boot, kernel, initramfs, device tree blob reside on the same flash storage (i.e. NAND). So developers have access and control to what to be deployed as the device tree (must match real hardware though).

Hardware designers should be able to provide both an ACPI table and a device tree. Depending on the receiver, one will be preferred.

References:

lqu
  • 491
  • 6
  • 12
4

Not completely correct:

  • ACPI started as an interface between firmware (formerly BIOS) and OS for things like power management, but also things like platform device probing
  • DT was always (even long before ACPI existed) about declarative platform device descriptions (probing and configuration), so the OS can properly initialize all drivers, configure operation points, etc, etc.

ACPI was always very limited in scope and depends on firmware, while DT stands on its own (just requires the bootloader to pass the right dtb to the kernel).

ACPI is the unprofessional, hackish attempt of bios and board vendors to solve a small subset of the problems that DT already solved long ago. A major pro argument for those gallows-wearing folks probably is that ACPI/BIOS hides lots of low level configuration stuff (up to runtime device programming, eg. for power management) in the firmware blob, thus preventing the OS kernel to have full control over the machine. (which finally leads to things like broken machines by broken BIOS, etc). We, the kernel developers, often have to work around crappy BIOSes.

My strong advice: get of ACPI when you can.

Enrico 'nekrad' Weigelt
  • 557
  • 1
  • 4
  • 4
  • Look at this: https://events.static.linuxfound.org/sites/events/files/slides/unified_properties_API_0.pdf – 0andriy Jan 10 '20 at 08:04
2

IMHO

ACPI and DT are used for similar purposes, but they have their unique functionalities. Nowadays the effort of defining ACPI configs in DT.

ACPI and DT are used to solve different issues:

  1. ACPI's purpose was to improve power efficiency.
  2. DT's purpose was to remove platform files outside the kernel.

Device tree is mostly passed to the linux kernel before it boots up. ACPI is usually loaded while linux kernel is booting (check Documentation/acpi/enumeration.txt for more info)

for any other thing just comment.

Grzegorz
  • 4,388
  • 1
  • 22
  • 45
Devidas
  • 2,146
  • 7
  • 22
  • https://events.static.linuxfound.org/sites/events/files/slides/unified_properties_API_0.pdf (in particular slide 12) – 0andriy Jan 23 '18 at 21:31