Skip to content

Index

Understanding hardware enablement for AutoSD

As a silicon manufacturer, you can join the hardware enablement program to work with platform and application developers, so you can develop your hardware to support intelligent, connected vehicle applications.

Driving your hardware to production using open source innovation

The hardware enablement program empowers you with an efficient process to integrate your hardware into the Red Hat ecosystem through AutoSD:

  • You can use the Automotive Stream Distribution (AutoSD) to innovate independently.
  • You can partner with Red Hat to enable and certify your safety-compliant hardware to run the safety-certified, production-ready Red Hat In-Vehicle Operating System (OS).

The CentOS Stream Automotive Special Interest Group (SIG) hosts this hardware enablement program as part of a Red Hat open source community where anyone can benefit from and contribute to automotive software.

Experimental upstream, certified downstream

Important

AutoSD is not ISO 26262 certified, although it has features that might support functionally safe automotive Linux.

Out-of-context functional safety certification applies only to Red Hat In-Vehicle OS. Hardware vendors are responsible for the out-of-context certification of their hardware. Automakers are responsible for the in-context ISO 26262 certification of their implementation of the in-vehicle OS on their target hardware, with or without support from software and hardware vendors, depending on their contractual agreements.

AutoSD is the upstream binary distribution that serves as the public, in-development preview of Red Hat In-Vehicle OS. This is similar to how CentOS Stream operates as the upstream to Red Hat Enterprise Linux (RHEL). AutoSD derives from CentOS Stream, with a few divergences, such as an automotive-specific kernel rather than CentOS Stream's kernel package. Red Hat In-Vehicle OS is the downstream, RHEL-based, safety-certified, software-defined vehicle (SDV) OS currently in development by Red Hat.

Diagram shows code flow from open source projects, such as the Linux mainline kernel from kernel.org, to Fedora, Fedora Enterprise Linux Next (ELN), to CentOS Stream. CentOS Stream receives contributions from many CentOS SIGs, which then flow to both RHEL and AutoSD. The Automotive SIG contributes AutoSD code back to various open source projects. Finally, RHEL and AutoSD code converges to form Red Hat In-Vehicle OS.

About hardware enablement program tracks

To meet your hardware prototyping needs, Red Hat has two tracks you can work on sequentially or concurrently, depending on where you are in your hardware development cycle:

Experimental

: As a silicon vendor who prefers to evaluate AutoSD independently, participate in the experimental track to test your hardware compatibility with AutoSD, so you can get insights and make adjustments. By joining the experimental track, you work independently to enable hardware to work with Linux mainline, Fedora Always Ready Kernel (ARK), or CentOS AutoSD kernel-automotive.

Production : As a silicon vendor who wants to release your hardware to automakers, the production track partners you with Red Hat to certify your hardware to run Red Hat In-Vehicle OS. By joining the production track, you participate in a rigorous hardware certification process that ensures your hardware meets the stringent stability, reliability, and security requirements that the automotive industry expects. After certification, Red Hat adds your hardware platform to the official list of supported devices available to Red Hat automotive customers.

Is your hardware experimental or ready for production? If your hardware is ready for production, the preferred process is to submit your merge request to first to Linux mainline, then to Fedora Always Ready Kernel, or ARK, then to CentOS. Prepare one or more patches and submit them as merge requests. Get reviews from the Linux mainline, Fedora, or CentOS maintainers. Were the merge requests accepted? If yes, coordinate with the maintainers to integrate your patches into the Linux mainline, Fedora ARK, and CentOS trees. If patches were not accepted, make adjustments based on the feedback and resubmit. If your hardware is experimental but you prefer not to use the preferred process, you can skip Linux mainline development, and prepare a merge request to submit to Fedora ARK or CentOS maintainers instead. After your CentOS Stream maintainers accept your changes to the AutoSD kernel, confirm your board works with the Linux mainline, Fedora ARK, and CentOS AutoSD, and then submit your board to Red Hat. Red Hat verifies that your board works with Linux mainline, Fedora ARK, and CentOS AutoSD, and then Red Hat builds a new automotive kernel and releases a new version of Red Hat In-Vehicle OS. You run the Red Hat automotive test suite and submit the results to Red Hat. Red Hat reviews the test results, updates the list of certified boards, and issues your hardware certification.

For instance, you might validate a proof of concept on the experimental track while coordinating with upstream maintainers to accept your drivers to start the production track. You can use this parallel approach to explore different avenues and tailor your journey to best suit your unique requirements. Even on the experimental track, Red Hat recommends that you upstream your drivers into the Linux mainline kernel, maintained by Linus Torvalds, so you can benefit from the stabilizing work done there and in its downstream repositories.

Moving from the experimental to the production track

When you and Red Hat agree to move your work with AutoSD forward on the production track, Red Hat expects that your drivers are already accepted upstream. Red Hat can then backport them in the next possible Red Hat In-Vehicle OS kernel-automotive release. The Red Hat In-Vehicle OS development team must trace code changes between the downstream kernel-automotive to the upstream Linux mainline kernel. This traceability lets Red Hat validate automotive functional safety, support the long maintenance cycles necessary for software in the automotive industry, and accelerate the integration of your hardware in production.

Red Hat provides you with a hardware test suite that has procedures to certify your hardware to run Red Hat software. The test suite includes a guide that has the following information:

  • Certification process
  • Test methods
  • Results evaluation
  • Instructions for how to set up the certification environment, test the systems or components you intend to certify, and submit the results to Red Hat for verification

After Red Hat reviews and approves these test results, Red Hat lists your hardware in the Red Hat Ecosystem Catalog.

Hardware requirements

For better collaboration, consider these criteria during the experimental track. When you move to the production track, these criteria become requirements. To request an exception, contact Red Hat.

  1. To ensure seamless integration and compatibility within our software ecosystem, silicon vendors must meet the hardware driver standards set by Red Hat for the AutoSD stack.
  2. To reduce complexity, enhance interoperability, and ease efficient integration, silicon vendors must use current Red Hat build environment technology, such as Red Hat Package Manager (RPM) and OSTree.
  3. To enable the advanced virtualization capabilities necessary for intelligent, connected vehicle applications, your hardware platform must support EL2 privileges for the aarch64 architecture or "ring-1" for the x86 architecture to integrate with KVM, so you can launch virtual machines.
  4. To meet a broad range of automotive use cases that require a richer vehicle operator experience, your hardware must include an upstream-approved GPU that supports graphics-intensive applications.
  5. To ensure software interoperability and enhance the system's reliability, robustness, and compatibility with industry standards, your aarch64 architecture hardware must support one of the standard ARM SystemReady profiles, such as SystemReady-IR or SystemReady-ES.
Out-of-tree driver modules

The CentOS Automotive SIG permits hardware drivers that you decide to keep out-of-tree. Out-of-tree means you do not submit your driver for review and integration into the Linux mainline kernel or any of its downstream distributions. However, AutoSD does not include out-of-tree drivers in its distributions or sample images. AutoSD does not include proprietary code or code not approved by upstream maintainers to enable out-of-tree drivers. To work with AutoSD, your out-of-tree driver must compile against an AutoSD binary build, which means it must work without kernel recompilation.

Next steps

To enable your hardware on AutoSD so you can start collaborating in the open source automotive ecosystem, see the Upstreaming drivers procedure.

Additional resources