Linaro keeps good hardware from growing old

A payment terminal can have plenty of working life left when the software beneath it starts running out of road. Square encountered that mismatch with Terminal and Register hardware built around Qualcomm’s SD615 processor. The chip dated from 2014 and reached end of life in 2018, according to a customer account published by Linaro. The shop counter was on one timetable; the technology supply chain was on another.

Square brought in Linaro to help establish an upstream-based route to continued support, pairing a newer Linux kernel with an updated Android release. Square’s Benjamin J. Li said the collaboration would allow another five to ten years of regular operating-system and kernel upgrades. That was an anticipated extension, not a retrospective measurement. His explanation for the choice was succinct: “upstreaming was the right path.”

Here is a useful way to understand Linaro: it works on the software decisions that determine whether hardware gets to grow old gracefully. Its engineers help manufacturers make Arm-based products run, keep them testable and maintain the code underneath them. The work rarely gets a button on the box.

Six companies, one recurring headache

Linaro emerged in 2010 with Arm, Freescale Semiconductor, IBM, Samsung, ST-Ericsson and Texas Instruments as founding members. The problem was fragmentation: companies building around related processor technology were still spending effort on separate low-level software foundations. Sharing that work could leave more engineering time for the features that distinguished their products.

The early ambitions reflected their moment. Linux platforms including MeeGo and Ubuntu appeared in the launch-era discussion. In 2012, Linaro formed an Enterprise Group focused on Arm servers. The organisation’s territory grew from the software underneath devices towards the software underneath data centres. Its central question travelled well: which difficult jobs should competitors do together?

There was real money behind the answer. Arm’s second-quarter 2010 financial filing recorded £1.2 million in Linaro-related charges and anticipated about £4.5 million over the first twelve months after launch. Those were Arm’s charges and forecast, not Linaro’s total funding. Founding members also contributed engineering time. Shared software required an actual budget, even when the resulting code could be freely available.

The patch is only the beginning

“Upstream” is software’s name for the main project from which other versions flow. A manufacturer can modify its own copy of Linux to support a board. The immediate benefit is obvious: the board works. The future obligation is less visible. Someone must keep those changes compatible as the surrounding software moves.

Linaro’s kernel service aims to move hardware support into mainline Linux, working through subsystem requirements, submissions and a maintenance strategy. That requires understanding the community’s review process as well as the device. A patch accepted into the common codebase has a different future from a patch marooned in a vendor’s private branch.

Acceptance still leaves work to do. Hardware needs testing; bugs need investigation. The practical inference for a manufacturer is to budget for that continuing relationship early. A working prototype demonstrates today’s behaviour. A maintainable product also needs a credible answer about next year’s updates.

A laboratory that remembers what it did

The testing tools make this less abstract. LAVA, the Linaro Automated Validation Architecture, provides a framework for deploying software and running tests on devices. Teams can run their own installation, including proprietary tests. SQUAD collects results and benchmarks. Tuxsuite provides on-demand APIs and tools for building and testing Linux kernels in parallel.

These are different pieces of the same daily chore: prove that a change works, then make the proof repeatable. A developer can download the supporting tools; a company can buy the hosted service and engineering help. The convenience comes from organising the repeated work around the code, compilers and hardware.

Linaro’s testing page gives a sense of the workload. It describes ClangBuiltLinux continuous integration averaging 40,000 kernel builds a month and 460 days of computation in that period. These are company-reported averages for a particular workflow. They illustrate why running tests in parallel matters: machine time accumulates much faster than calendar time.

In December 2025, Linaro transferred Tuxmake, TuxRun and TuxLava to KernelCI. Its January announcement said engineers would remain co-maintainers, the MIT licences would remain and Tuxsuite would continue operating. Giving the underlying tools a community home was compatible with keeping a commercial service around them.

Below the screen, above the silicon

For customers, the menu extends from a new board to an ageing fleet. Board support package development covers bootloaders, kernels and root filesystems for Linux and Android products. These components handle the less photogenic parts of a launch: starting the machine, recognising its hardware and giving applications a usable system.

Long-term support follows those components into service. Linaro offers kernel and firmware maintenance, security fixes, custom tests and management of changes outside the main project. Its published coverage includes arm, arm64 and x86_64. Customers request a package quote; the commercial unit is the support job they need done.

ONEBoot addresses embedded Arm firmware, with a software bill of materials, vulnerability management and lifecycle support. At Embedded World 2026, Linaro worked with AMI and ADLINK on a demonstration using ADLINK boards: AMI’s Aptio V for Windows and ONEBoot for Linux. The point was to bring different firmware paths into a managed build-and-test workflow. Linaro markets the product around security and compliance readiness.

There is also a more recognisable software product business. Forge, added from Arm in 2023, supplies DDT for debugging, MAP for profiling and Performance Reports for an overview of application performance. It spans multiple CPU and GPU architectures. For a scientific computing team, the problem may be an expensive program running badly, rather than a new device refusing to boot.

The club changes its terms

In February 2026, Linaro announced that it would become a fully commercial services provider while hosting CoreCollective, a free, Arm-backed consortium. The distinction matters to potential customers: shared industry work and an individual engineering contract now have explicitly different routes.

“As the ecosystem expands, we must scale our impact.”Li Gong · CEO · February 2026

Linaro’s own account of its evolution argues that the original foundational problems of Arm software had been addressed as the ecosystem matured. The new model broadens participation while giving product-specific work a commercial home. It is a stated strategic response to a changed market, rather than evidence of a failed customer project.

CoreCollective describes its purpose as shared tools and standards across cloud and edge systems. The opportunity is to gather businesses around common software needs before each commissions a separate answer. For participants, the useful distinction is between contributing to something reusable and hiring a team to deliver a particular product requirement.

Customers buy the work they cannot postpone

Linaro’s customers sit at several points in the technology chain: semiconductor businesses, device manufacturers, platform companies and computing teams. In January 2026, it disclosed open-source Linux development support for Valve’s Steam Frame. Gaming is a visible destination for engineering skills also used in industrial and embedded systems.

The Windows on Arm project shows another side of the business. Linaro describes collaboration with Arm, CIX Technology, Microsoft and Qualcomm on native development, testing and regression fixes. Its work includes firmware and WPerf, a performance analysis tool. Linux remains central to the company, but the commercial problem is broader: making software behave properly on Arm hardware.

The relevant alternatives depend on that problem. A manufacturer might use its own kernel team, rely on a silicon vendor’s board support or hire a specialist consultancy. Linaro’s distinguishing combination is experience in shared upstream projects and the ability to carry out customer-specific engineering. The value is greatest when a product needs both.

This is specialised work. A team whose needs are already covered by a maintained standard platform may have little reason to commission a custom engagement. A company keeping extensive private changes must still account for their maintenance. Buying expertise cannot make every architectural decision inexpensive.

Put the maintenance meeting before the launch party

The organisation’s working culture fits its dispersed subject. Its careers page says employees represent 26 countries and 90 percent work from home. It also describes flexible working and two paid volunteering days a year. Public engineering communities supply another shared workplace: a place where proposed changes must survive discussion and review.

The lesson a product team can borrow is practical. Identify which parts of its software are shared infrastructure. Plan how hardware support will enter the relevant upstream projects. Make builds and tests repeatable. Assign responsibility for updates before the device ships. Each decision gives tomorrow’s engineers less archaeology to perform.

Square’s example puts a commercial reason behind that discipline. Useful hardware and the software supplied with it can age at different speeds. Linaro sells the engineering needed to bring those timetables closer together. For the business still using the device, another reliable update can be a more valuable feature than a new box.