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

Re: device tree not the answer in the ARM world



Luke Kenneth Casson Leighton wrote:
mark, thank for this.  i'm bringing lkml back in [my decision] but
just this once as i believe the point's now been made.  i'm also
leaving it below [top-post style] as it's background, as well as
standing on its own merit.

i was under the impression that device tree had been declared
successful on power-pc [and wasn't aware of SPARC], so a reality check
is much appreciated.  in effect what you're saying is that the
standardisation through things *other* than device tree - i.e. there
wasn't so much of a problem of diversity in the first place [*1], and
this in turn means that device tree could be declared "more"
successful.

I have to declare my position here: I'm not a seasoned kernel developer, what knowledge I have is from trying to run multiple architectures: mostly Debian, and largely to allow me to check out FPC on real hardware on occasion.

My understanding- and I admit freely that it's based on cursory research and could be entirely wrong- is that DeviceTree is a derivative or at least a spin-off of a group of projects which include IEEE 1275 aka OpenFirmware. If that is the case, I feel on somewhat firmer ground adding that OpenFirmware was originally written by Mitch Bradley for Sun and known as OpenPROM; a fork is currently being developed as OpenBIOS targeting multiple platforms for e.g. the case where firmware is needed to allow an OS to run on Qemu. My understanding is that Mitch and OpenFirmware have significant involvement in OLPC, which could explain how DeviceTree has become a topic of discussion.

If I am correct with the above, and I'm still being cautious in case people think I'm barking (up the wrong tree or otherwise), then as well as having experience with the standard UI on SPARC and Apple PPC systems I've used it as a second-stage loader on PCs: and have found it extremely useful since it has enough debugging facilities to e.g. allow the content of a partitioned CD to be explored. Ask Mitch very nicely and you might even get hold of one which boots over the LAN.

So at the risk of incurring the wrath of the Great And Good, I think that as it stands it's a long way short of being able to describe arbitrary peripherals and means of attachment. But it might have real value as a second-stage loader, even if usually used with a connection akin to ADB rather than being probed by the kernel.

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

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


Reply to: