FDT vs. non-FDT: some clarification?

Hello all,
maybe i am the only one with this fundamental lack of understanding, in which case i am sorry for wasting Your time:
I always read about FDT and non-FDT, and i understand that this Flattened-device-tree is just a file(or data structure) describing a particular hardware, where are the adresses of the several devices on the internal bus(ses), amongst other things.
But can i just choose one type, or is the type i need determined by the hardware or by the kernel i am to install?
in other words, can i describe a given piece of hardware in both FDT and non-FTD ways?
If this was true, it would be a software requirement. Does one way have any advantages over the other?
Is there a "rule of thumb", which hard- or software requires which type?

I just have upgraded one of my NAS to linux 4.2, so i guess, it is all ok. i did it by following procedure 4b.
But i would like to understand what i was doing.
If this topic has been explained somewhere, could someone please redirect me there?

Dirk

2 Pieces NSA320 , u-boot 2016.05, debian 4.12.1, Several Mac and Linux boxes connected.
More into soldering than programming. Location:Hildesheim, Germany

Hi Dirk,

> If this topic has been explained somewhere, could
> someone please redirect me there?

Regarding the DTB in kernel and rootfs in the sticky thread http://forum.doozan.com/read.php?2,12096.

Step 4a and 4b achieve the same thing. 4b is used when your current u-boot does not not support booting FDT kernel (such as older u-boot by Jeff and davygravy in this forum circa 2012).

In 4b, the kernel takes care of the embedded DTB, and uses it the same way as it were a separate DTB (like 4a). So there is no different.

The current DTS (source code for DTB) specify the hardware definition for each box (that I've released in the kernel thread). Ie, they are all hard code for each box. There is a new way of modfifying the DTB while system is running, but we are not using it yet.

So the bottom line is: once the DTS has been defined for a type of box, that's it. There is no need to worry about.

Hope I've answered your questions?

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Just to try an explanantion from a different angle:
The device tree mechanism is an approach to fix "shortcomings" of the ARM architecture. In the x86 world all devices are discoverable. So the kernel can query the PCIe bus or the USB bus to know which hardware is present and loads drivers/modules accordingly.

In the ARM world it works differently: There is a huge variety between devices even though most of them are using the same basic components - just with a little bit variation. The device tree file enables the kernel to know about the present hardware (and some hardware-specific configuration, e.g. memory addresses).

Now for practical matters there is not much difference between a FDT and a "non FDT" kernel. You always need to present a device tree to the kernel but you can do that as a boot parameter (new uboot) or just "bake it into the zimage itself". The first method helps distributors such as bodhi because he can provide a single kernel image for multiple devices.

So what you choose to do is completely up to you. If you only care about one device no method is clearly superior. If you don't want to upgrade uboot, you have to use the "legacy" method.

And just for completeness:
"in other words, can i describe a given piece of hardware in both FDT and non-FTD ways?"

Sort of. Old versions of the kernel (before 3.16?) required that all device configuration was hard-coded into the C source code of drivers. Newer kernel versions require device tree files for the kirkwoord hardware.

OK,
thanks alot to both of You.
I (sort of) puzzled this out by myself, but this gives a lot clearer picture.

2 Pieces NSA320 , u-boot 2016.05, debian 4.12.1, Several Mac and Linux boxes connected.
More into soldering than programming. Location:Hildesheim, Germany