Page 1 of 1

Seeking opinions on using device tree for I/O definitions

Posted: Sun Apr 26, 2015 7:54 am
by rdp
Hi,
I've been working ELLCC, a clang/LLVM based development tool chain targeting ARM, Mips, Microblaze, PowerPC, and x86 targets. The tool chain is pretty complete and runs on Linux, Windows, and Mac OS X. Linux target run-time support is complete using libc++, musl, and compiler-rt and now I'm working on adding bare metal library support. The first target I've been concentrating on is ARM. I've got pretty complete support for the ARM Cortex-A9 (MMU/non-MMU, virtual file system, multi-priority scheduler, file descriptor support, etc.) Most recently I've added support for LwIP and a revamped Berkeley style socket interface for it and have gotten to the point where I'll be doing more device driver work.
I'm looking at adding device tree support to make the assignment of address, interrupt vectors, etc. a bit cleaner. Does anyone here have an opinion as to whether device trees are the way to go?

-Rich
P.S. Forgive me if my formatting is messed up. This is my first post here.

Re: Seeking opinions on using device tree for I/O definition

Posted: Sun Apr 26, 2015 8:33 am
by Brendan
Hi,
rdp wrote:Does anyone here have an opinion as to whether device trees are the way to go?
It's a good way to go, and also inadequate.

Imagine hardware as a hierarchical tree. The nodes nearest the CPU are typically built into the SoC/motherboard and never change; and for these devices you need some way to detect their presence (so the OS installer can install appropriate drivers with the OS, and so the OS can load the drivers needed during boot). The best way is if the devices tell you they're present using a standardised method (e.g. PCI configuration space), but ARM mostly lacks anything sensible like that (see note). Device Tree is a good way to fill this gap (for "fixed hardware" only, on ARM only).

Note: ARM is mainly intended for embedded systems where the manufacturer that creates the hardware also creates and/or customises the software to suit. It's not intended for systems where the end user chooses the OS they want and installs the OS themselves. This is why things like (e.g.) having a generic "OS installer" (on a CD-ROM or USB flash stick or whatever) that will work on any ARM system without excessive "user unfriendliness" is virtually impossible (even though it's relatively trivial for systems like 80x86).

Nodes furtherer from the CPU are typically things like USB devices, monitors, etc. These tend to be plugged in and unplugged by the user whenever they feel like it; and therefore must identify themselves (or be configured by the end user if auto-detection can't be used to avoid "error prone end user hassle"). These devices can't be supported by something like Device Tree.


Cheers,

Brendan