Why do embedded systems need device tree while pcs don't?

Peripherals are connected to the main processor via a bus. Some bus protocols support enumeration (also called discovery), i.e. the main processor can ask “what devices are connected to this bus?” and the devices reply with some information about their type, manufacturer, model and configuration in a standardized format. With that information, the operating system can report the list of available devices and decide which device driver to use for each of them. Some bus protocols don't support enumeration, and then the main processor has no way to find out what devices are connected other than guessing.

All modern PC buses support enumeration, in particular PCI (the original as well as its extensions and successors such as AGP and PCIe), over which most internal peripherals are connected, USB (all versions), over which most external peripherals are connected, as well as Firewire, SCSI, all modern versions of ATA/SATA, etc. Modern monitor connections also support discovery of the connected monitor (HDMI, DisplayPort, DVI, VGA with EDID). So on a PC, the operating system can discover the connected peripherals by enumerating the PCI bus, and enumerating the USB bus when it finds a USB controller on the PCI bus, etc. Note that the OS has to assume the existence of the PCI bus and the way to probe it; this is standardized on the PC architecture (“PC architecture” doesn't just mean an x86 processor: to be a (modern) PC, a computer also has to have a PCI bus and has to boot in a certain way).

Many embedded systems use less fancy buses that don't support enumeration. This was true on PC up to the mid-1990s, before PCI overtook ISA. Most ARM systems, in particular, have buses that don't support enumeration. This is also the case with some embedded x86 systems that don't follow the PC architecture. Without enumeration, the operating system has to be told what devices are present and how to access them. The device tree is a standard format to represent this information.

The main reason PC buses support discovery is that they're designed to allow a modular architecture where devices can be added and removed, e.g. adding an extension card into a PC or connecting a cable on an external port. Embedded systems typically have a fixed set of devices¹, and an operating system that's pre-loaded by the manufacturer and doesn't get replaced, so enumeration is not necessary.

¹ _{If there's an external bus such as USB, USB peripherals are auto-discovered, they wouldn't be mentioned in the device tree.}

PCs actually do need a device tree.

They just call it something else.

It is not correct to say that operating systems for the descendents of PC/AT compatibles assume the existence of things such as a PCI bus. They do not.

Nor do they probe. Probing for hardware, just poking some I/O or memory addresses to see whether they work, has not been necessary since the middle 1990s.

Rather, they enumerate a root bus.

This is a bus that is not enumerable by communicating with bus controller device hardware, as with other enumerable buses. This is a bus that exists purely as a construct of the system firmware and operating system. It is enumerated by querying the system firmware, and what is present on it is baked into the system firmware by the mainboard manufacturer, to match what is on the mainboard.

There is little difference in concept between this and a device tree. Just like a device tree, it has to be created to match the actual board. Just like a device tree, it is a list of device nodes with resource information (amongst other things) attached to them. Just like a device tree, it is exterior to the operating system and is not a list of things to probe for hardwired into the operating system's own code.

The Plug and Play BIOS Specification has the firmware provide a simple device tree in memory to an operating system, one of the nodes of which will be (for example) a PNP0A03 node designating a PCI bus, giving the I/O and memory resources that it is assigned and thus where it is to be found.

ACPI supersedes this, but the idea remains the same. In ACPI there is a table called the Differentiated System Description Table, augmented by a Secondary System Descriptor Table, which (with information from a few other ACPI tables) provide much the same thing.

(If you want to see this from the firmware developers' side, look at Coreboot for one example. It has a large body of ACPI Source Language files, a selection of which are compiled into a bytecode binary image that is incorporated into the firmware. The selection is controlled by a configuration tool that prompts one for the specific mainboard being targetted.)

On FreeBSD, for example, the Plug and Play BIOS Specification information was enumerated by a pnpbios bus driver within the kernel (that has since been removed), and (nowadays) the ACPI information is enumerated by an acpi bus driver. In Linux, there is (still) a drivers/pnp/pnpbios bus driver that reads the Plug and Play BIOS tables, and the ACPI tables are read by code scattered throughout arch/arm64/kernel/ and arch/x86/kernel/.

The enumerable root bus can, but generally does not (pace some encroachments by ACPI) overlap with things enumerable on the buses that are devices on the root bus. For example, whilst there are PNPxxxx IDs for ATA buses, system firmware will not list PCI-to-ATA bridge devices on the root bus, using them. Such devices are found by finding the PCI bus when enumerating the root bus, and then finding the PCI-to-ATA bridge when enumerating the PCI bus.

The simple fact of the matter is that on wildly divergent platforms with different names for the concepts, the same basic principle is in operation. There is a baked-in list of devices that match the otherwise non-enumerable devices in the system, and the firmware or whatever boot loader is in use provides a mechanism for the operating system to read that list and configure the devices on it, allowing the operating system to then enumerate those devices in their turns.

Further reading

• Compaq Computer Corporation, Phoenix Technologies, and Intel Corporation (1994-05-05). Plug and Play BIOS Specification. Version 1.0A. Intel corporation.
• Linkes to ACPI-related Documents. Unified Extensible Firmware Interface Forum. UEFI.
• Patrick Mochel (2002). "The Linux Kernel Device Model". Proceedings of the Ottawa Linux Symposium 2002. pp. 368–375.
• Hiten Pandya and Tom Rhodes. "Power and Resource Management". FreeBSD Handbook.
• "Legacy Drivers: Device Probing". Platform Devices and Drivers. Documentation/driver-model/platform.txt. Linux kernel.
• https://superuser.com/a/1253583/38062