Shared publicly  - 
ARMv8 OS vendors like Red Hat will mandate certain #ARM SBSA platform requirements, which were a joy to assist in defining over the past few years. If you have an ARMv8 server, you have one UART, one watchdog, one SATA, one USB, etc. A few caveats exist for early designs, but next year is really rather promising. There will be no gratuitous differentiation, there will be one kernel. There will be UEFI and ACPI platforms. We have ARMv8 hardware booting with UEFI and GRUB2 at this stage, and a full reference stack will be available soon. Coupled with the hardware coming over the next 18 months and all I can say is...oh baby.
Yuhong Bao's profile photoJoshua Hoblitt's profile photoJon Masters's profile photoMåns Rullgård's profile photo
Will these have uncrippled UEFI Secure Boot? Sure would be nice to change a server's firmware root key!
I mean that the ARM-with-Windows built devices are mandated to not be able to change keys or disable Secure Boot. I'm hoping ARM-with-Linux built devices won't be that way.
+Kees Cook all of the conversations around Secure Boot have always started with me laying that down as a prereq.
+Vladimir Pantelic there will be no ARM zoo in 64-bit. One kernel indeed will rule them all. You don't build Enterprise solutions with horrible hacks, custom kernels, non-standard platforms, or I'll defined platforms that have the kernel knowing too much about the underlying platform hardware.
+Jon Masters the best way to enforce your vision is to lock down the one true kernel with secure boot then :) cant have us ordinary people messing with hardware, right?
+Vladimir Pantelic I am all for people installing their own kernels if they want to. I support aggressively defined standard platforms (not cute embedded nonsense hacks) but not locked platforms. You can keep both parts when it breaks, of course.
+Jon Masters If there's only one kernel, and the specs are locked down as they are now, then how do you allow system architects and kernel hackers you're not aware of to be more clever than you, to do more clever things than you planned for? You're looking at the negative side of things - i.e. people doing worse than you, ignoring that people may also do better than you. Basically you don't allow the ARM server platform to grow larger than the borders of your own intellect.
Sorry for me being so ad hominem. But the future of ARM servers as a whole is more important than you.
+Thilo Fromm I'm not locking anything down. I already said I am not in favor of locked down secure boot that you can't configure on your own system. What I am against is enterprise software on non standard platforms. The hardware needs to be completely standardized in order to be supportable by real enterprise software. If you have something else, enjoy whatever cute hack you like.
People always emotionally grab onto the most bizarre shit. Rather than embrace standardization, they look for some way for this to be evil - whether secure boot or whatever else. The effort is about defining a standard platform, of the kind you take for granted with your PC that "just works" today. Kees raises a good point, and I see why, so this isn't about him, but let's see the forest for the trees. ARM doesn't work in enterprise unless you standardize the hardware, which we have done. This isn't about mandating some secure boot (but sure, let's latch onto that shall we rather than worrying about the actual issues?). I have spent years advocating UEFI and ACPI because they are requirements for a supportable enterprise platform, but that is the only reason. U-Boot and Device Tree are great on embedded platforms, but they are not useful for general purpose one size fits all servers with single kernel images that need to boot in 5 years from now on new hardware without some updated binding (as opposed to a standard owned independently of the kernel and codified in thousands of pages of formalized spec, not kernel documentation files), hack to U-Boot environment, and other unsupportable nonsense. Similarly, we need PSCI and other TEE APIs to abstract various other pieces. I intend that you can buy a new 64-bit ARM server in 10 years from now and run the software you bought in 5 years from now. No kernel hacks, perhaps a few driver updates, but as boring a story as you have on x86 today. ARM is not a special magical snowflake that should be treated differently, it is a new architecture that will fit into the Enterprise fold in order to gain the kind of market penetration that it is looking to achieve. This is how enterprise software is done.
+Jon Masters well, it's your talk of "one true  only" that get's people to respond. had you just linked to the (openly available) ARM "enterprise" hardware standard, we would have said nothing and would be busy coding to it. What people will do with the hardware in 10 years from now on, I would not dare to predict. Last I heard Google did not scale their data centers with off the shelf motherboards and stock RHEL kernels....
+Vladimir Pantelic the ARM ecosystem needs a few people espousing "one true platform" stuff. There are enough others building non standard platforms to offset :)
so far, it's "one clickthrough platform", but I heard you'll kick ass and fix that, post pics
I will chat with ARM about that.
+Jon Masters You did not answer my question. How do you allow for people greater than yourself to push the platform further than you can do it yourself? For the start you will have to accept that you cannot even understand their ideas (because those are, by definition, beyond you), so you need ways to incorporate those without prior judgement, and later consider the results, in the long term. All this while not endangering the platform. 
If you don't find a way to solve this issue then the platform will forever be bound to the borders of your own intellect.
+Thilo Fromm How is this any different on x86 today? If you want to build a non-standard x86 platform, you are free to do so. You are also free to support your own kernel because the stock one may not work or be supported, and that's fine. Nobody has to conform to platform specs unless they would like to receive the benefit of supported enterprise software.
+Jon Masters But I never asked about x86... So please, no more distractions. It's really hard finding an answer to that, isn't it?
and so it continues...for so long it was only the x86-focused maintainers that continually bashed "embedded Linux" developers in general despite excellent contributions that were being made.

Now we also have the ARM server folks to cast stones from their high towers. No good will come from statements such as cute embedded nonsense hacks
Point noted +Matt Porter and it's a good point. I guess I should rephrase that. However I do think ARM needs a different tack in the Enterprise to be successful. Note that I have actually supported DT on EFI for non server use cases!
luckily we did not have that clear server/nonserver split when e.g. SMP was added
Server does one size fits all. Embedded can be a special case of that but often chooses not to be, which is fine, but the result cannot necessarily be supported on an Enterprise platform. And we do (to an extent) have a difference with SMP. Look at how the boot SMP holding pen is done on 64-bit ARM with U-Boot vs. how it will be done right in the near future in an abstracted way.
The division is also cost. On server it's no big deal to require certain IP blocks be baked in. In embedded cases, this is a huge deal.
If it's anything near how SMP is done in x86 ACPI then this is not something to look forward to, and certainly not "right".
I think what everyone is forgetting is that +Jon Masters is talking about the server market only.  Of course there will be a "zoo" for all of the vendors who don't already have in-house teams of programmers from the x86-server world with drivers-in-firmware to update (nor a desire to own them).
Right! I care only about the very very tiny subset that is server. I love embedded too, but embedded "hacks" can't work for one size fits all servers.
"server" is about as ambiguous as "embedded". Please try again. :)
I look forward to future comparisons between UEFI and U-Boot, wrt arm64.  Given we've had the code for a few months, and merged for a few weeks, clearly we're on track to be even better than UEFI which has had years to get all of this "right".

Of course I think the right answer is "get out of the damn way, let the software the 'user' cares about such as Linux or a Hypervisor or whatever get going".
+Tom Rini I do work in the big iron world. Also, I do some development in virtualization. Since we use virtualization to offer live vertical scaling features I do have real life hands-on experience with ACPI/OS communication (ACPI is used to, among other things, signal CPU and RAM hot-plug actions, and hot-unplug requests). Now Jon never actually gives much detail about what he's scheming behind closed doors, however, from what he does say it can be concluded that hardly anyone in the developer world will be overwhelmed by the results, at least not in any positive way.

So there's an actual technical reason why people are worried.
Crikey.  This is why Jon is in engineering instead of sales.

The point of SBSA isn't one kernel, it's about many SoCs.  It's not about exclusion, it's about a path to implicit inclusion.  If you're semiconductor who chooses to conform to this specification it means you're much closer to a world of software is ready and waiting for you at no extra charge.  If you're writing an OS it's half the solution to having a multitude of SoCs to run on.  This is what cooperation on a grand scale looks like- it's huge, it's opt-in, and from my standpoint everybody wins.

Linux got where it is in part by individuals converting their DOS and Windows systems to boot Linux instead, same hardware.  In the future people are going to buy AArch64 hardware with an OS they don't want and in the future somebody is going to provide an alternate OS they do want.  Boot standards mean that same hardware can run a different OS.  Forget about the one-this-one-that nonsense, this is about paving the path for the many.
+Brendan Conoboy There's always a way to take a one-liner and use it out of context. I worked on embedded systems for years, so clearly anyone knows I'm not against them (somehow, as if that would be a thing?), but in the enterprise space there is no room for the kind of bespoke customization that exists in embedded. If I need to be meme, then so be, it really doesn't matter too much to me. What matters is that ARM servers succeed, which they will through the awesome standardization that is happening. This enables choice because now someone hacking for fun can build their own OS that will boot on any server they want to use, rather than a custom image for each system.
P.S. I can have some fun at my expense. The best graphic version of the "Cute Embedded Nonsense Hacks" theme (as voted by number of +1s) gets $100 from me donated to a registered charity of the author's choice. Have fun.
I have finally figured out how to explain what I do to people.
+Jon Masters Sure, the thing here is that message of one this one that sounds really bad if you're on the outside looking in.  One kernel for dozens of SoCs is fantastic, but threatening: "What if it isn't my kernel," people ask.  That's why secureboot is a natural followup question.  If you flip the message around the story is less threatening: Dozens of SoCs for any OS.  Dozens of OSes for any SoC.  This isn't about one, it's about a mesh of interoperability.  That's the power of standards, anybody can play big.  It's the first RFC for a piece of the ARM Server puzzle.  Who doesn't love a good RFC?
+Philip Balister I've known Tom for about a decade. He's a trained killer whale masquerading as Bruce Wayne.
Can't you see it? I think Tom and +Matt Porter are secretly Batman and Robin. I just don't want to say which is which.
I'm surprised at the ammount of fear in this thread.  I absolutely can not wait for ARM servers that support PXE + IPMI so that the boot device can be remotely selected.
Never underestimate the fear of the unknown.
The problem is that we do know something about ACPI, and it ain't pretty.
Add a comment...