The Future of the Embedded Linux Market
December 21st, 2009
By Eric Carmes – 6WIND Founder and CEO
You may consider this post is not really in the scope of the Forum as it doesn’t really address a multicore topic but I think Linux is a technology that a very large number of multicore users are familiar with.
As you certainly know, the embedded Linux market has recently changed significantly after the acquisition of Wind River by Intel and MontaVista by Cavium Networks. Both acquirers have made similar communications to the market: nothing is going to change as both Wind River and MontaVista will keep their own businesses and continue to support multiple processor architectures. However, having two major embedded Linux providers acquired by processor companies leads to several strategic questions for the whole ecosystem.
I don’t want to comment on the strategy of two companies that are both very successful. My focus is the Linux market itself. First of all, the current market situation seems quite paradoxical. Linux is an Open Source technology so in principle available to everybody, while the market is concerned about acquisitions of commercial Linux companies.
The embedded Linux business is not simple. As opposed to the server & PC markets that are dominated by a single architecture, there are many different platforms to support in the embedded world and a generic solution does not fit all. The embedded world requires more customisation and a lot of customers do not want to manage Linux support and integration by themselves. However, for companies providing Linux services for the embedded world, business is challenging as the return on investment is lower due to the amount of platform-specific work that is required. It can be noted that a lot of Linux companies also have a proprietary software business (Wind River, ENEA, Mentor Graphics…).
What is the appropriate business model around Linux? There are several players. Processor companies distribute their own Linux. For multicore processors, Cavium has its SDK, Netlogic its RMIOS, Freescale its LTIB, etc. Their primary goal is to provide an environment that enables their customers to develop applications, accelerating the customers’ time-to-market and their own processor sales. These distributions are the first to be available. Commercial distributions are available for a large range of processors but are typically released several months after the processor companies’ own versions. Software service companies can customise existing distributions for customers. End customers may decide to maintain their own distributions using either internal R&D or outsourcing companies.
The final decision obviously belongs to the end customer or OEM. Recent acquisitions have the potential to change the business model and support model for commercial distributions. Will OEM customers change their provider because they consider there is a risk to use distributions that in future may no longer be supported on the processor architecture that they have selected? Will there be new major independent players? Will the embedded market be attractive to Linux providers who currently focus on distributions for servers? Will OEM customers decide to maintain their own distributions?
Posted in 
Tags:
The problem is not only to support a particular multicore processor as an ISA, but to support in Linux the entire SoC with core interconnect, hardware offload engines, etc. This was the problem even before these acquisitions, and will become even bigger problem after. Let us assume the best case scenario when both Intel and Cavium continue to support other processor architectures. We still have two issues to be solved:
1) Will these two vendors provide full support for competing solutions with the same priority as their own, or the support for other processors will become a background task, running when there are extra cycles available from their own CPU support?
2) Will other vendors (for example, Freescale) provide their competitors Intel and Cavium with potentially sensitive information about their new upcoming processors?
My biggest concern would actually be the second question, because it requires strict internal firewall inside Intel and Cavium to make sure that there is no sensitive information transfer within their organizations.
Alex,
I do not believe a CPU vendor has to release all details of a chipset to a Linux distribution provider. What we are hoping from an ideal solution is that Linux vendors are providing a generic compilation and packaging solution which can be easily *customized* and cross compiled. Kernel and cross compilers should also be part of the combinations.
Right now, most embedded Linux distributions are not made of “innovations”. There is more innovation on Dekstop/Server Linux distributions (Redhat-Fedora-Mandriva-etc vs Ubuntu-Debian-etc): SPICE from Redhat, KVM with its userland management tools, GUIs, etc.
The embedded innovations are mainly from the CPU vendors (debuggers, gcc upgrades, Kernel optimizations, BSP optimizations, etc.).
Maybe, an ideal embedded solution from an embedded Linux vendor would mean:
– to be able to use any toolchain, which is best optimized by the CPU vendors. So, typically for a same target, two tool chains would be useable with a same embedded Linux distribution: a default one from the Linux vendor and a CPU vendor one.
– to be able to use any Linux kernel version within a range of kernels. It does not make sense to link a kernel version with a Linux distribution. For instance, most userland packages (apache for instance) can work with any Linux kernels. Some cannot work, but only for compilation issues! Once any Linux kernel can be used, some kernels can be from the CPU vendors with the most optimized BSPs and some kernels can be from the Linux vendors.
– to provide profiling (oprofile, papi, etc.), coverage tools, debuggers that are closed to the CPU’s capabilities.
– to push forward Linux optimizations into the main Linux’s git trees (RCU optimisations, system call latency, SMP locking, 32/64 bits ABIs with any combinations); it means to become a visible actor of key Open Source components (glibc, gcc, Kernel).
Vincent,
I am not sure you are right.
For example, would Cavium be willing to provide a few years ago all their crypto additional instructions to the competition? Will Tilera be willing to provide to their competition the exact implementation of their distributed cache coherency mechanism? Would any vendor be willing to provide even the information about adding a particular hardware offload engines to their competition, less details on how it works?
Let us say that a vendor quadrupled their TLB size, will they be willing to give that fact out to their competition ahead of time? Etc, etc.
Chip vendors work on their next generation chip for very long time, and they definitely don’t want for the competition to know about planned features, some of them deeply affecting Linux modules.
The only way I see it working is that chip vendors would work only on their proprietary distribution or a snapshot of a standard distribution, and will provide all the information only when the chip is out (and even that is the question mark). That would mean delay of software availability to board designers and system integrators.