That was the original dream for DT that so far hasn't been very successful.
In practice the kernel only wants to add support for DTs that conform to a reviewed and approved schema, but most/no manufacturer wants to do the effort of having every single thing on their DT schema bikeshedded to death on the device tree mailing list before the device is manufactured. So the vendor just makes up whatever kind of unapproved DT schema that only their own vendor kernel fork supports, and if mainline support is ever added it will have its own DT.
So I can't change the system's composition? Or do the ACPI/DT only show me the controller chips soldered to the motherboard, but not the devices that connected to them?
Yes, DT is mainly meant to describe non-discoverable hw blocks inside the SoC and the chips soldered to the motherboard. Discoverable devices like PCIE cards or USB devices aren't added to DT (except under very rare circumstances)
Nowadays there is also an overlay mechanism that is used for example on the Raspberry Pi expansion hats, so DT is not always limited to soldered-on things.
On PC platforms, ACPI tables are some mix of static and dynamic data. There's a table for CPU information, and you don't need to flash your firmware everytime you change your CPU, but you do sometimes. PC firmware generally does a PCI scan before booting an OS, and I think some of that ends up in ACPI tables too.
How does the kernel knows which of the many possible device trees describes my hardware? Or is the system comes with custom-compiled pre-installed Linux kernel, with the one correct DT baked into it by the manufacturer?
ARM devices almost always need custom kernels. Even if you had device tree provided to you, there isn't a lot of confidence the kernel will be able to perfectly parse it nor have all the necessary drivers. This isn't an arm specific issue but rather an ecosystem issue as no one drives standardization.
U-Boot or something else tells the kernel which DT to use, and gives its own DT to the kernel. If Linux has its own DT for the hardware, it will use that. Otherwise it falls back to what the bootloader provided.
That was the original dream for DT that so far hasn't been very successful.
In practice the kernel only wants to add support for DTs that conform to a reviewed and approved schema, but most/no manufacturer wants to do the effort of having every single thing on their DT schema bikeshedded to death on the device tree mailing list before the device is manufactured. So the vendor just makes up whatever kind of unapproved DT schema that only their own vendor kernel fork supports, and if mainline support is ever added it will have its own DT.
So I can't change the system's composition? Or do the ACPI/DT only show me the controller chips soldered to the motherboard, but not the devices that connected to them?
Yes, DT is mainly meant to describe non-discoverable hw blocks inside the SoC and the chips soldered to the motherboard. Discoverable devices like PCIE cards or USB devices aren't added to DT (except under very rare circumstances)
Nowadays there is also an overlay mechanism that is used for example on the Raspberry Pi expansion hats, so DT is not always limited to soldered-on things.
On PC platforms, ACPI tables are some mix of static and dynamic data. There's a table for CPU information, and you don't need to flash your firmware everytime you change your CPU, but you do sometimes. PC firmware generally does a PCI scan before booting an OS, and I think some of that ends up in ACPI tables too.
Usually they are shipped with the Linux kernel rather than mobo flash.
How does the kernel knows which of the many possible device trees describes my hardware? Or is the system comes with custom-compiled pre-installed Linux kernel, with the one correct DT baked into it by the manufacturer?
ARM devices almost always need custom kernels. Even if you had device tree provided to you, there isn't a lot of confidence the kernel will be able to perfectly parse it nor have all the necessary drivers. This isn't an arm specific issue but rather an ecosystem issue as no one drives standardization.
U-Boot or something else tells the kernel which DT to use, and gives its own DT to the kernel. If Linux has its own DT for the hardware, it will use that. Otherwise it falls back to what the bootloader provided.
I was expecting to read “… a stork” lol