The document discusses different approaches used by operating systems to detect hardware components during system boot. It describes methods like hardcoding details, using static configuration, device trees, and dynamic configuration via ACPI and bus-based detection. ACPI is covered in depth, including its components, tables, and complexity. Platform and PCI devices are also briefly explained.

1. Linux kernel TLV meetup, 21.09.2015
Kfir Gollan

2.  What is hardware probing?
 Different approaches for detecting hardware
 Probing in the linux kernel

3.  Have you ever wondered how does the OS know what
hardware components are available on a given
machine?
 Basically, someone needs to tell the OS what is
available.
 The process of detecting all the hardware components
and pairing them up with the matching drivers in the
OS is called hardware probing, or just probing for
short.

4.  Hardcode the details of the hardware into the kernel
 Static configuration
 Device trees
 Dynamic configuration
 ACPI
 Bus based detection
 PCI

6. Formal definition:
“The Device Tree is a data structure for describing
hardware.
Rather than hard coding every detail of a device into an
operating system, many aspect of the hardware can be
described in a data structure that is passed to the
operating system at boot time.”
devicetree.org

7.  Device tree source (DTS)
 Device tree bindings
 Device tree blob (DTB)
 Flattened Device Tree (FDT)
 Device tree compiler (DTC)

8. {
compatible = "nvidia,harmony", "nvidia,tegra20";
#address-cells = <1>;
#size-cells = <1>;
interrupt-parent = <&intc>;
memory {
device_type = "memory";
reg = <0x00000000 0x40000000>;
};
...
};

9. {
….
sound {
compatible = "nvidia,harmony-sound";
i2s-controller = <&i2s1>;
i2s-codec = <&wm8903>;
};
};

10. chosen {
bootargs = "console=ttyS0,115200 loglevel=8";
initrd-start = <0xc8000000>;
initrd-end = <0xc8200000>;
};

11.  Xillybus Device tree tutorial
 Device trees for Dummies!
 Documentation/devicetree/
 usage-model.txt
 booting-without-of.txt

13.  Advanced configuration and power interface
 Originally created by Intel, Toshiba & Microsoft
 Currently maintained by the UEFI forum
 Current last revision of the spec was released at May 2015
(Revision 6.0)
 Replaces APM (Advanced Power Management)
 Allows the kernel/user to control power features without
going into BIOS configuration
 It’s complex! (Revision 6.0 is 1056 pages long)

14. The fact that it takes more code to parse and interpret
ACPI than it does to route traffic on the internet
backbones should be a hint something is badly wrong
either in ACPI the spec, ACPI the implementation or
both.
Alan Cox
ACPI is a complete design disaster in every way
Linus Torvalds
Basically, it is just complex.

15.  Divided to three major components
 ACPI registers
 ACPI BIOS
 ACPI tables
 AML – ACPI Machine Language
 Requires a full-fledged interpreter to be implemented in
the kernel.

16.  Motherboard devices are described in an hierarchical
format called the ACPI namespace.
 ACPI definition blocks
 Differentiated System Description Table (DSDT)
 Secondary System Description Table (SSDT)
 The operating system is simply required to iterate over
the ACPI namespace and load the proper drivers for
each device that is listed there.

17. Device (BT)
{
Name (_HID, "TOS6205")
Method (_STA, 0, NotSerialized)
{
If (BTEN)
{
Return (0x00)
}
Else
{
Return (0x0F)
}
}
...
}

18. Device (BT)
{
…
Method (DUSB, 0, NotSerialized)
{
Store (0x00, _SB.PCI0.LPC0.EC0.BTDT)
}
…
}

19.  ACPI Component Architecture
 (OS)-independent reference implementation of the
Advanced Configuration and Power Interface
Specification (ACPI).
 www.acpica.org
 Divided into a few major components
 OS services layer
 ACPI core subsystem
 device drivers

20.  A collection of modules that implement the core logic
of ACPI.
 AML interpreter
 Execution of the AML bytecode
 ACPI table management
 Validation, parsing, installation and removal
 Resource management
 Dependencies between resources
 IRQ routing tables
 Namespace management
 Providing simple access to the full ACPI device hierarchy
 Many others

21.  Intermediate layer between the ACPI core and the rest
of the system
 Translate syscall to a matching ACPI method
 Standard set of interfaces that perform OS dependenet
functions
 Memory allocation
 Hardware access
 Threading and synchronization
 Needs to be implemented by each operating system
that wishes to use ACPICA.

23.  Platform devices
 Platform devices are devices that typically appear as
autonomous entities in the system.
 No bus initialization and management required
 Directly probe the hardware – implementing .probe
function
struct platform_driver {
int (*probe)(struct platform_device *);
int (*remove)(struct platform_device *);
...
};

24.  PCI devices
 Drivers are registered to the PCI subsystem of the
kernel.
 When a device is detected the matching drivers probe
function is invoked.
struct pci_driver {
...
int (*probe) (struct pci_dev *dev, ..);
void (*remove) (struct pci_dev *dev);
...
};