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

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
4
down vote

favorite
2












When booting a kernel in an embedded device, you need to supply a device tree to the Linux kernel, while booting a kernel on a regular x86 pc doesn't require a device tree -- why?



As I understand, on an x86 pc the kernel "probes" for hardware (correct me if I'm wrong), so why can't the kernel probe for hardware in and embedded system?







share|improve this question


























    up vote
    4
    down vote

    favorite
    2












    When booting a kernel in an embedded device, you need to supply a device tree to the Linux kernel, while booting a kernel on a regular x86 pc doesn't require a device tree -- why?



    As I understand, on an x86 pc the kernel "probes" for hardware (correct me if I'm wrong), so why can't the kernel probe for hardware in and embedded system?







    share|improve this question
























      up vote
      4
      down vote

      favorite
      2









      up vote
      4
      down vote

      favorite
      2






      2





      When booting a kernel in an embedded device, you need to supply a device tree to the Linux kernel, while booting a kernel on a regular x86 pc doesn't require a device tree -- why?



      As I understand, on an x86 pc the kernel "probes" for hardware (correct me if I'm wrong), so why can't the kernel probe for hardware in and embedded system?







      share|improve this question














      When booting a kernel in an embedded device, you need to supply a device tree to the Linux kernel, while booting a kernel on a regular x86 pc doesn't require a device tree -- why?



      As I understand, on an x86 pc the kernel "probes" for hardware (correct me if I'm wrong), so why can't the kernel probe for hardware in and embedded system?









      share|improve this question













      share|improve this question




      share|improve this question








      edited Jan 4 at 10:48









      Jeff Schaller

      32.1k849109




      32.1k849109










      asked Oct 21 '17 at 22:16









      MOHAMMAD RASIM

      587




      587




















          2 Answers
          2






          active

          oldest

          votes

















          up vote
          10
          down vote



          accepted










          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.






          share|improve this answer



























            up vote
            4
            down vote













            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





            share|improve this answer




















              Your Answer







              StackExchange.ready(function()
              var channelOptions =
              tags: "".split(" "),
              id: "106"
              ;
              initTagRenderer("".split(" "), "".split(" "), channelOptions);

              StackExchange.using("externalEditor", function()
              // Have to fire editor after snippets, if snippets enabled
              if (StackExchange.settings.snippets.snippetsEnabled)
              StackExchange.using("snippets", function()
              createEditor();
              );

              else
              createEditor();

              );

              function createEditor()
              StackExchange.prepareEditor(
              heartbeatType: 'answer',
              convertImagesToLinks: false,
              noModals: false,
              showLowRepImageUploadWarning: true,
              reputationToPostImages: null,
              bindNavPrevention: true,
              postfix: "",
              onDemand: true,
              discardSelector: ".discard-answer"
              ,immediatelyShowMarkdownHelp:true
              );



              );













               

              draft saved


              draft discarded


















              StackExchange.ready(
              function ()
              StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f399619%2fwhy-do-embedded-systems-need-device-tree-while-pcs-dont%23new-answer', 'question_page');

              );

              Post as a guest






























              2 Answers
              2






              active

              oldest

              votes








              2 Answers
              2






              active

              oldest

              votes









              active

              oldest

              votes






              active

              oldest

              votes








              up vote
              10
              down vote



              accepted










              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.






              share|improve this answer
























                up vote
                10
                down vote



                accepted










                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.






                share|improve this answer






















                  up vote
                  10
                  down vote



                  accepted







                  up vote
                  10
                  down vote



                  accepted






                  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.






                  share|improve this answer












                  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.







                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered Oct 21 '17 at 22:51









                  Gilles

                  508k12010031533




                  508k12010031533






















                      up vote
                      4
                      down vote













                      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





                      share|improve this answer
























                        up vote
                        4
                        down vote













                        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





                        share|improve this answer






















                          up vote
                          4
                          down vote










                          up vote
                          4
                          down vote









                          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





                          share|improve this answer












                          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






                          share|improve this answer












                          share|improve this answer



                          share|improve this answer










                          answered Oct 22 '17 at 12:03









                          JdeBP

                          29.1k459135




                          29.1k459135



























                               

                              draft saved


                              draft discarded















































                               


                              draft saved


                              draft discarded














                              StackExchange.ready(
                              function ()
                              StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f399619%2fwhy-do-embedded-systems-need-device-tree-while-pcs-dont%23new-answer', 'question_page');

                              );

                              Post as a guest













































































                              Popular posts from this blog

                              How to check contact read email or not when send email to Individual?

                              Displaying single band from multi-band raster using QGIS

                              How many registers does an x86_64 CPU actually have?