A few minutes ago, Red Hat announced Red Hat Enterprise Linux Server for ARM Development Preview 7.1. This is a 64-bit (only) Operating System targeting “AArch64″, which is the 64-bit ARM machine execution state. It’s intended to help build out the Red Hat story within the ARM server ecosystem, allowing partners to port their applications and for ISVs to engage with the same trusted Operating System stack that they’ve worked with for many years. It is not a supported Operating System – so you can’t call up for support at this time – but you can use it to port your software to run on ARM servers. And you get all of the Red Hat goodness you would expect, from installation (all of the usual automation using Kickstart and tooling built upon that), through runtime management, and diagnostics (we have a fully functional version of UEFI-based kexec/kdump working with full crashdump support).
In short, everything you would expect from a 64-bit clean, Enterprise-quality Operating System. There are no shortcuts in RHELSA DP. We build one kernel (3.19 based in this release) that boots and runs exactly as you would expect on any other architecture. And we went the extra mile to make sure all of the tools users are familiar with will “just work”, right down to the level of assisting in bringing SMBIOS 3 to the ARM Architecture and in helping to port tools such as “dmidecode” (especially working with vendors to ensure their firmware tables are populated correctly) that users and scripts widely expect to use in discovering information for systems management. Our support of industry standards – such as ECAM-based PCIe enumeration using ACPI – means that plug in adapter cards also “just work”. And we’re not done. We’re poking all of the vendors to upstream their drivers as a condition of ever getting code into anything we might do in the future. It’s part of our very ethos that ARM be about upstream code.
To learn more about what we announced today in Red Hat Enterprise Linux Server for ARM Development Preview, you can come to our session at Red Hat Summit (this Wednesday, 10:40am). It’s hosted by myself (I can now of course share publicly that I am technical lead for RHELSA DP), and my awesome colleague Yan Fisher (who leads our markeing efforts around RHELSA DP) to learn more about what we are announcing, and to see a live demo of Apache Spark doing some analytics. You can also see many other hardware platforms that are built to comply with these industry standards running our Operating System at Summit (some with fresh and shiny new firmware upgrades that will migrate them over to support these emerging ARM industry standards). Stay tuned over the next few days for some exciting news and developments!
A little more history
We didn’t get here overnight. It’s taken years of effort by many many people to port our Operating System, infrastructure, tooling, and maintainers over to the 64-bit ARM Architecture, and I am very proud of each and every one of the people who have been involved. What started out as a small skunkworks team in the “Yosemite Project” has become integrated with the whole, and now nearly everyone has more than a little ARM expertise and exposure. With that in mind, I figure I can finally share a little history behind this project and how we got from there to today’s news.
The ARM project, originally known as “Yosemite” (it’s my favorite US National Park), began life 4.5 years ago in a meeting I had with one of my execs. At the time, 32-bit ARMv7 (with hardware floating point!) was the new new shiny, and we were super excited by PandaBoards and BeagleBones (not even -xM, but the original one). It took a stretch of the imagination to go from these tiny embedded engineering boards to a full multi-blade server system, but to give my management the credit they fully deserve, they have rarely been shy about thinking to the future and to newly emerging technologies.
Yet even at the time, we knew that our real interest was in the (as yet unannounced) rumored-to-exist 64-bit ARM Architecture (which is where our interest lies as far as Enterprise focused server systems). Indeed, in my first ever email after creating our internal ARM engineering list, I said the following on the topic of 64-bit ARM:
* The 64-million-dollar question is 64-bit ARM support. I’ve heard various mumblings from contacts, and of course there has been some press on this front. We are going to reach out to ARM to see what we can find out. *If* there will be a 64-bit architecture in the medium term, this may instead become the target of interest to Red Hat (where we care mostly about ARM for things like low power server blades), while Fedora would obviously retain both ARMv5 and ARMv7 in any case. This is a high priority item in the short term to find out this information.
Needless to say, we ultimately did discover that there was, in fact a 64-bit version of the architecture under development, and therein began a beautiful friendship that has existed with the ARM Architecture team for many years (I just love those guys to pieces). We began working with the early silicon vendors from the very beginning. Over the years, I’ve personally had some wild and whacky adventures assisting in everything from silicon bringup and debug (with many vendors) to design reviews for multiple future generations that will dazzle us in the years to come. There’s some truly awesome stuff coming that will bring us lots of fun toys to play with in future years.
When we began our team, we quickly got engaged with the Fedora ARM project, helping to bootstrap the “armv7hl” 32-bit architecture. This served multiple purposes – it helped us to do the right thing (working through Fedora to get what ultimately benefits everyone) and to learn how to bootstrap a new ARM Architecture from scratch once we got to the 64-bit version we knew was in flight. That same very first email from me to our internal engineering team also contained these important words on the subject of Fedora:
* We obviously want to work with the Fedora ARM community that already exists, and not appear to come in to take over. With that in mind, there have already been discussions with Chris Tyler and Paul Whalen that most (or all) of you have been involved in. Our goal is two-fold here: to help improve the Fedora ARM experience, and to be as un-intrusive as possible in our internal efforts at Red Hat engineering. We will come up with a list of priority goals for areas we are best able to help on.
I would like to think we have done our best to live up to our own standards over the past few years as far as doing right by the communities in which we operate (and it is great to see folks like Peter Robinson and Paul Whalen continuing to drive Fedora ARM forward). Looking back on those heady days, I can also amuse and ridicule myself with a number of other thoughts I shared on ways to build ARM servers over the next 5 years:
* we will need to work on questions such as:
- Choosing a kernel tree (upstream, OMAP, Hybrid we make, etc.) and building a single, generic 32-bit ARM binary kernel image. Although ARM traditionally has various machine/platform logic, I feel that the newer stuff like Grant Likely’s Flattened Device Tree work is essential to making a supportable Enterprise kernel. We will need to work with vendors to see what they are doing on the “BIOS”/platform front, and hopefully can get behind something like FDT.
So you can see that I wasn’t always the UEFI/ACPI “fanboy” that I became. Indeed, I have never been wedded to any one technology. I have, instead, been “wedded” to the successful outcome for the overall computing industry in which ARM is a part of a vibrant range of consumer choices. After many early conversations (more than 4 years ago now) with a wide variety of industry players, it became clear to me that the way for ARM to succeed in server (in having a standard platform against which a single Enterprise quality Operating System image could be constructed, and used in such a manner that was highly familiar to those deploying on ARM) was through bringing all of the hardware vendors together and agreeing upon some common standards that could help us succeed together. Which is what we did. I think the end result is a good one for the success of the ARM partnership, which is what matters in the end.
As a result of the work that has been done over the past few years, we have now been able to build an Operating System that feels just like other Enterprise Operating Systems with which many of you are very familiar. And, indeed, many of you have been running RHELSA DP in various incarnations during development. This includes our good friends at Linaro, who have provided much of the platform engineering work required to support emerging ARM platform standards with a single OS kernel image. Linaro have been instrumental in so many ways in bringing the entire Linux-on-ARM emerging server ecosystem together and we look forward to many more wonderful years working on ARM servers together.
RHELSA DP targets industry standards that we have helped to drive for the past few years, including the ARM SBSA (Server Base System Architecture), and the ARM SBBR (Server Base Boot Requirements). These will collectively allow for a single 64-bit ARM Enterprise server Operating System image that supports the full range of compliant systems out of the box (as well as many future systems that have yet to be released through minor driver updates). This is fantastic news for both the emerging ARM server ecosystem, as well as for the Red Hat family overall. It’s only going to get more exciting over time. There are so many others whose designs we have assisted in developing over the past few years that I look forward to seeing come to market as this ecosystem matures with time.
Today I am proud to share Red Hat Enterprise Linux Server for ARM Development Preview with our many wonderful partners. I look forward to working with all of those who want to join us in building an open and standards based ecosystem of awesomeness. Now is a great time to reach out to myself and the team to learn more about how to get involved. See you at Red Hat Summit!