Device Tree

Device Tree

[Madhu K]

Hi All,

This is to understand how Device tree works in linux kernel.

If in case Device tree is not there, where and how to pass the hardware
information to the linux kernel.

Does all embedded systems contains Device tree?

Regards,
Madhu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20161025/81b42d10/attachment.html 

Device Tree

[Laurent Navet]

Hi Madhu,

Here is an introduction to device tree :

http://free-electrons.com/pub/conferences/2013/elce/petazzoni-device-tree-dummies/petazzoni-device-tree-dummies.pdf

2016-10-25 8:21 UTC+02:00, Madhu K <madhu.sk89@gmail.com>:
> Hi All,
>
> This is to understand how Device tree works in linux kernel.
>
> If in case Device tree is not there, where and how to pass the hardware
> information to the linux kernel.
>
> Does all embedded systems contains Device tree?
>
> Regards,
> Madhu
>


-- 
? On ne r?sout pas un probl?me avec les modes de pens?e qui l?ont engendr?. ?
? We cannot solve our problems with the same thinking we used when we
created them. ?

Device Tree

[Valdis.Kletnieks at vt.edu]

On Tue, 25 Oct 2016 11:51:38 +0530, Madhu K said:

> If in case Device tree is not there, where and how to pass the hardware
> information to the linux kernel.

For many types of hardware, the bus protocol provides a standard way to
find everything on the bus.  And that sort of bus scanning is how non-embedded
systems find all their devices.  If it's a laptop or a desktop or server,
there's always the possibility that the user has plugged in a new graphics
card or a different network card - so being able to scan and detect is
important there.

However, in an embedded system, the configuration is fixed - all the parts are
soldered in place, and there's no place to add new devices.  So the hardware
designers save the US$0.08 per chip by picking stripped down chips that don't
have full function (for instance, leave off the PCI config circuitry and just
provide a hardwired "this device will live at this address permanently")

And yes, if you're building microwave ovens, and selling 10 million of them,
suddenly saving 8 cents US per chip adds up to some major profits...

> Does all embedded systems contains Device tree?

No, only embedded systems that have I/O devices that cannot be
enumerated by the hardware.  So for instance, usually a PCI device
or a USB device can be detected by a bus scan.  So if that's all you
have, you don't need device tree - the system can find all the hardware
resources.

But if you have GPIO pins, or an audio or ethernet card that's hard-wired in
some non-scannable way, or weird clock chips, or anything like that, you'll
need device tree.

And it's certainly possible to do *both* - let the kernel scan for PCI and
USB devices, *and* provide a device tree for non-scannable resources.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 484 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20161025/3ca3e1e6/attachment.bin 

Device Tree

[Joel]

> On Oct 25, 2016, at 12:39 AM, Valdis.Kletnieks at vt.edu wrote:
> 
> On Tue, 25 Oct 2016 11:51:38 +0530, Madhu K said:
> 
>> If in case Device tree is not there, where and how to pass the hardware
>> information to the linux kernel.
> 
> For many types of hardware, the bus protocol provides a standard way to
> find everything on the bus.  And that sort of bus scanning is how non-embedded
> systems find all their devices.  If it's a laptop or a desktop or server,
> there's always the possibility that the user has plugged in a new graphics
> card or a different network card - so being able to scan and detect is
> important there.
> 
> However, in an embedded system, the configuration is fixed - all the parts are
> soldered in place, and there's no place to add new devices.  So the hardware
> designers save the US$0.08 per chip by picking stripped down chips that don't
> have full function (for instance, leave off the PCI config circuitry and just
> provide a hardwired "this device will live at this address permanently")
> 
> And yes, if you're building microwave ovens, and selling 10 million of them,
> suddenly saving 8 cents US per chip adds up to some major profits...
> 
>> Does all embedded systems contains Device tree?
> 
> No, only embedded systems that have I/O devices that cannot be
> enumerated by the hardware.  So for instance, usually a PCI device
> or a USB device can be detected by a bus scan.  So if that's all you
> have, you don't need device tree - the system can find all the hardware
> resources.
> 
> But if you have GPIO pins, or an audio or ethernet card that's hard-wired in
> some non-scannable way, or weird clock chips, or anything like that, you'll
> need device tree.
> 
> And it's certainly possible to do *both* - let the kernel scan for PCI and
> USB devices, *and* provide a device tree for non-scannable resources.

This is not entirely true, usually things like the CPU and machine information can?t be auto detected and DT provides this info.

It is also used to communicate things like bootargs to the kernel [1]
[1] http://lxr.free-electrons.com/source/drivers/of/fdt.c#L1081

DT is not the only way to do these things. But I just wanted to highlight that DT is used as a vehicle for more than just solving ?bus scanning? issues so you?ve to either use it or use other alternate methods to have such meta-data communicated from firmware.

- Joel

Device Tree

[Madhu K]

Hi Valdis,

You mean In non embedded system( laptop, desktop and server ) DT is not at
all required?

Regards,
Madhu

On Tue, Oct 25, 2016 at 1:09 PM, <Valdis.Kletnieks@vt.edu> wrote:

> On Tue, 25 Oct 2016 11:51:38 +0530, Madhu K said:
>
> > If in case Device tree is not there, where and how to pass the hardware
> > information to the linux kernel.
>
> For many types of hardware, the bus protocol provides a standard way to
> find everything on the bus.  And that sort of bus scanning is how
> non-embedded
> systems find all their devices.  If it's a laptop or a desktop or server,
> there's always the possibility that the user has plugged in a new graphics
> card or a different network card - so being able to scan and detect is
> important there.
>
> However, in an embedded system, the configuration is fixed - all the parts
> are
> soldered in place, and there's no place to add new devices.  So the
> hardware
> designers save the US$0.08 per chip by picking stripped down chips that
> don't
> have full function (for instance, leave off the PCI config circuitry and
> just
> provide a hardwired "this device will live at this address permanently")
>
> And yes, if you're building microwave ovens, and selling 10 million of
> them,
> suddenly saving 8 cents US per chip adds up to some major profits...
>
> > Does all embedded systems contains Device tree?
>
> No, only embedded systems that have I/O devices that cannot be
> enumerated by the hardware.  So for instance, usually a PCI device
> or a USB device can be detected by a bus scan.  So if that's all you
> have, you don't need device tree - the system can find all the hardware
> resources.
>
> But if you have GPIO pins, or an audio or ethernet card that's hard-wired
> in
> some non-scannable way, or weird clock chips, or anything like that, you'll
> need device tree.
>
> And it's certainly possible to do *both* - let the kernel scan for PCI and
> USB devices, *and* provide a device tree for non-scannable resources.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20161025/b41b9786/attachment.html 

Device Tree

[Valdis.Kletnieks at vt.edu]

On Tue, 25 Oct 2016 15:46:05 +0530, Madhu K said:

> You mean In non embedded system( laptop, desktop and server ) DT is not at
> all required?

Basically, that's correct.  Those types of systems have already evolved
ways (boot loaders, ACPI, and so on) to do things so there's no real need
to use DT on those systems.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 484 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20161025/cc9daff7/attachment.bin