Device trees I: Are we having fun yet?

Posted Nov 13, 2013 6:03 UTC (Wed) by jcm (subscriber, #18262)
Parent article: Device trees I: Are we having fun yet?

There certainly will be more standardization in the ARM platform going forward, in particular in the server space. You saw the public announcement that ACPI is now part of the UEFI forum. I would be surprised if that were the last such announcement over the coming months.

Device trees I: Are we having fun yet?

Posted Nov 13, 2013 6:26 UTC (Wed) by olof (subscriber, #11729) [Link] (6 responses)

ACPI and UEFI doesn't magically solve the ARM server problems, and it's troubling that people just walk around that topic thinking it will. They just give you yet another mechanism to communicate the mess that the vendors create.

The x86 space has been more organized because Microsoft forced people to comply with the standard specs (and a product wouldn't ship, plain and simple, if it didn't boot an unmodified Windows install). That's not true for these ARM servers since Linux will be the primary target for many of them -- the same strict requirements aren't there.

On the other hand, maybe, just maybe we can avoid the mess of SMM. It's definitely a mixed blessing to have (or require) that level of under-the-covers workaround for compliance, since we all know just how messy and buggy firmware can be. On the other hand, it avoids the same mess to crawl into the kernel.

Device trees I: Are we having fun yet?

Posted Nov 13, 2013 6:57 UTC (Wed) by jcm (subscriber, #18262) [Link] (1 responses)

Olof, I agree that ACPI doesn't magically solve the problems. But what I mean is, I expect to see such platform standardization in the ARM server space. I would be /very/ surprised if there aren't movements in that regard. As far as SMM, sadly I raised this 3 years ago that I thought vendors would abuse TrustZone (and in particular create their own apps running on the TEE) to emulate SMM on AArch64, and that's roughly what I see happening. I've made recommendations to mitigate the impact, which I see being lesser because: a). You don't stop all CPUs in the system. b). Most of this crap can be handled by management cores in the designs that I have reviewed so far.

Device trees I: Are we having fun yet?

Posted Nov 13, 2013 7:39 UTC (Wed) by olof (subscriber, #11729) [Link]

Oh, I have hope that the vendors that have had enough planning to involve you in their designs will come out with something fairly sane, even though some of the recent patch sets can introduce a good amount of doubt.

My greater concern is the second-tier vendors, or the mass-market vendors that will do the bare minimum (and not quite know what they're doing, or at least not seeing the bigger picture), etc. It'll take quite a bit of education of them to sort things out right, and it only takes a few of them going to market anyway to make the kernel side of thing very interesting and possibly messy. It'll be interesting to see how it plays out.

Device trees I: Are we having fun yet?

Posted Nov 14, 2013 9:23 UTC (Thu) by deepfire (guest, #26138) [Link] (3 responses)

> The x86 space has been more organized because Microsoft forced people to
> comply with the standard specs (and a product wouldn't ship, plain and
> simple, if it didn't boot an unmodified Windows install).

I find "boot an unmodified Windows install" being a rather weak substitute for standards compliance.

Device trees I: Are we having fun yet?

Posted Nov 14, 2013 14:24 UTC (Thu) by raven667 (subscriber, #5198) [Link] (1 responses)

Well it isn't just being able to boot, MS has pushed for several device standards such as for webcams so they didn't have to deal with buggy crashy vendor drivers making them look bad.

Device trees I: Are we having fun yet?

Posted Nov 26, 2013 17:18 UTC (Tue) by nye (subscriber, #51576) [Link]

On a related note, anyone know why there's no such thing as a standardised ethernet class driver?

Device trees I: Are we having fun yet?

Posted Nov 15, 2013 17:52 UTC (Fri) by drag (guest, #31333) [Link]

> I find "boot an unmodified Windows install" being a rather weak substitute for standards compliance.

Yet it's the most effective standards compliance mechanism that has ever existed as far as hardware goes.

Device trees I: Are we having fun yet?

Posted Nov 13, 2013 13:33 UTC (Wed) by arnd (subscriber, #8866) [Link]

A lot of the arm64 "server" components that people are talking about are not really PC-style servers as we know them from x86 but rather system-on-chip designs more akin to today's embedded 32-bit products. There is no real infrastructure in the kernel to deal with these using ACPI, nor is that likely to get added any time soon.

There is a real danger of people trying to use ACPI on these systems anyway (as shown by some patches posted for X-Gene), which implies that they come up with random out-of-tree and out-of-spec hacks that they cannot rectify before shipping products to end-users. Unlike for dtb files (which can be shipped alongside a kernel), there is not really a backwards-compatible way to replace an ACPI BIOS, so a system like that is either stuck with a custom kernel (i.e. the thing we're all trying to avoid here) or with an ugly per-product workaround (i.e. a board file) in the kernel.

We found out the hard way with DT that it's not really possible to have a stable ABI while simultaneously trying to figure out how to describe things in the first place. ACPI on ARM today is in a worse position than DT on ARM was three years ago when we could sufficiently describe all PowerPC SoCs, and there is no way for ACPI to not be an ABI.