[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: device tree not the answer in the ARM world



Mark Morgan Lloyd wrote:

I wonder if the device tree is the answer here. If the box comes with
a DT or one is available on the web then the installer could read it and
know what to install. That and the armmp kernel should solve the problem.

 you'd think so, and it's a very good question, to which the answer
could have been and was predicted to be "not a snowbal in hell's
chance", even before work started on device tree, and turns out to
*be* "not a snowball in hell's chance" which i believe people are now
beginning to learn, based on the ultra-low adoption rate of device
tree in the ARM world (side-note: [*0]).

[Grimace] DeviceTree works up to a point on SPARC and PPC Macs, where there is a limited number of peripheral device types and (in general) they're described by published data. Part of that success though is because these machines also expose a standardised UI (OpenPROM or whatever you want to call it) which developers can use for manual enumeration and debugging and which the kernel can use provided that it gets the calling convention right (I've seen a firmware change on SPARC break the kernel).

Leaving aside the more esoteric peripherals (sending morse using a camera flash LED or whatever :-) there are at least t^Hfour problems:

i)   There's no standardised interface to get at the configuration.

ii) It's not self-describing, particularly in the case of GPIO-attached peripherals.

iii) It's no replacement for enumerating PCI-attached peripherals.

iv)  It's no replacement for enumerating chips on a JTAG loop.

Put another way, Cory Doctorow's "InstallParty" software isn't even science fiction: it's pure fantasy, and is likely to stay that way.

Apologies for commenting to a fairly old thread, but I've been taking a bit of flak elsewhere about that uncompromising assertion and would appreciate being able to set the record straight.

I don't think it's possible to make a USB (etc.) connection to an arbitrary board, and to do a full enumeration of all chips and attached peripherals. I don't think that will /ever/ be possible, unless USB gains standardised gateways to JTAG, PCI configuration and so on that operate without firmware cooperation. So in that context "devicetree is not the answer".

On the other hand, if a board already had a copy of OpenFirmware etc. and expected to talk to a USB/serial terminal as a console during boot, and if it had a competent devicetree and full support for all CPU facilities including debugging etc., then it should be possible to probe and control it in the same way that 1970s development boards could be controlled and loaded from an attached ASR-33.

Provided that the devicetree proponents are also pushing OpenFirmware, then it might be possible for an attached computer to implement some sort of "installparty" functionality. So Doctorow might not have been as wide of the mark as he first appeared.

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]


Reply to: