The PetaLinux plot twist: what Xilinx's shift means for companies and developers 

Introduction 

For years, PetaLinux has been the go-to tool for embedded developers working with Xilinx hardware, streamlining the process of building custom Linux distributions. Its integrated environment allowed us to move swiftly from concept to deployment, making it seem like both a prototyping and production-ready solution. However, as we step into 2024, Xilinx has thrown a curveball: PetaLinux is no longer recommended for production deployment. This unexpected shift raises pressing questions for all of us who have relied on this tool for our projects. 

Background on PetaLinux 

PetaLinux is essentially a streamlined development environment, built on top of Yocto, and specifically tailored for Xilinx hardware. It provides developers with an environment that includes everything necessary to customize, build, and deploy Embedded Linux solutions. The official AMD site describes PetaLinux as “offering everything necessary to customize, build, and deploy Embedded Linux solutions” and “tailored to accelerate design productivity”, and over the years, many of us can attest that it delivered on that promise. 

PetaLinux became a core offering from Xilinx because it allowed developers to bypass the complexities of setting up a full Yocto project. Instead, PetaLinux packaged essential tools into an integrated experience, allowing developers to move quickly from prototyping to real-world deployment. Documentation like the PetaLinux Yocto Tips has further encouraged developers to see PetaLinux as more than just a prototyping tool. 

Xilinx's sew stance 

Recently, Xilinx's messaging has changed. In their article titled “Moving from PetaLinux to Production Deployment” they clearly state that PetaLinux is intended for development purposes only, not for production. It suggests developers transition to “more robust” solutions for production use by saying that PetaLinux is primarily intended to facilitate the development phase, but users should transition to more robust production environments for deployment. 

This shift is a significant departure from how PetaLinux has been traditionally presented and perceived. It leaves many of us wondering: why the change, and what does it mean for our current and future projects? 

Challenges for embedded developers 

This sudden change poses challenges for the many developers and organizations currently using PetaLinux in their production systems. Companies that have committed to PetaLinux as part of their product strategy now find themselves in a difficult position, needing to evaluate the stability and long-term support of their systems. 

In my experience (and likely that of many other BSP and Linux developers), the claims that production systems require features like package managers or live security updates don't align with the realities of our tightly controlled, mostly immutable embedded environments. Security in embedded systems is nuanced, and the blanket statements from AMD seem disconnected from our day-to-day experiences. 

In community discussions, such as one found on the Trenz Electronic forum, users have raised concerns about this shift and its impact on their systems. These concerns are justified, considering the long-term commitment and investment that some companies have made in PetaLinux-based deployments. 

Possible motives behind the shift 

There could be several reasons I can think of behind Xilinx's sudden change in stance: 

-One is mitigation of legal liability. If any issues arise in production that could be attributed to PetaLinux, distancing themselves from such use might help limit their exposure. Possibly there’s a lawsuit involved. 

-Xilinx are encouraging users to either transition to Yocto directly or invest in more commercially supported options. This would reduce the burden on Xilinx to thoroughly maintain tools that used to be implicitly expected to meet production standards. 

-This move could also reflect a broader shift in Xilinx's priorities, perhaps aligning with industry trends or focusing resources on other offerings. 

Is PetaLinux really just a prototype tool? 

Given that PetaLinux is fundamentally based on Yocto and has been optimized for Xilinx hardware, it's hard to accept that it's only suitable for prototyping. Its automation and developer-friendly abstractions have made it seem like a ready-made solution for both development and production. 

Many of us have successfully deployed PetaLinux-based systems in production, meeting stringent requirements and passing rigorous testing. Reframing it now as a mere development tool feels like a disservice to the community that has trusted and relied on it. 

The need for clarity and developer trust 

Clear and consistent communication from hardware vendors is crucial. Developers and companies need to know the limits of their tools, not just for technical reasons but for long-term planning and resource allocation. A sudden shift from maybe an implicit “this is the complete development solution” to “this is not suitable for production” erodes trust. 

For embedded development companies, having reliable and well-supported development tools isn’t just a convenience but a necessity. The embedded systems world often deals with long product cycles, and changing gears mid-development is costly and time-consuming. A clearer and more honest communication of expectations from Xilinx would have allowed companies to make more informed decisions from the outset. 

What has changed? 

I suppose Xilinx might tell you there's nothing new in it. Indeed, “you need to ensure that you have a comprehensive software update plan in place to respond to and resolve critical vulnerabilities throughout the lifetime of your product in a timely manner.” And certainly, “PetaLinux build outputs do not provide some of the update features that are available from commercially supported Linux distributions.” But any company using PetaLinux, or any OS and toolset, is responsible for implementing its own security and update policy anyway. As far as I know, there’s no commercial product that would take legal responsibility for your SW security. This message feels like raising a red flag without offering any real tools to mitigate the issues, apart from blindly opting for commercial offerings or rebuilding your project and policies from scratch with other tools. 

With Xilinx's recent changes, it's not just about a build-time notice reminding us that PetaLinux is intended "for demonstration purposes only." Oh no, they've taken it a few steps further. Since builds are unattended and no one's watching, they've embedded this message throughout the entire process. It starts in the documentation and interactions from the moment you set up PetaLinux and continues all the way to each and every login to your system: 

$ source /opt/petalinux/settings.sh 
******************************************************************************************** 
The PetaLinux source code and images provided/generated are for demonstration purposes only. 
Please refer to https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/2741928025/Moving+from+PetaLinux+to+Production+Deployment for more details 
******************************************************************************************** 

$ cat /etc/issue 
******************************************************************************************** 
The PetaLinux source code and images provided/generated are for demonstration purposes only. 
Please refer to https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/2741928025/Moving+from+PetaLinux+to+Production+Deployment for more details. 
******************************************************************************************** 
PetaLinux 2024.1+release-S05201002 \n \l 

$ cat /etc/issue.net 
******************************************************************************************** 
The PetaLinux source code and images provided/generated are for demonstration purposes only. 
******************************************************************************************** 
PetaLinux 2024.1+release-S05201002 %h 

I love the asterisks, by the way. It wouldn't have been the same without them. I bet they consulted a UI designer just for that. Did you notice how the number of asterisks exactly matches the length of the sentence on the next line? That's art. It's 92 asterisks, in case you're wondering. But hey, what do I know about UI design anyway? 

Talking about tools, the article offers you to either “roll-your-own” based on Yocto or Buildroot, still kindly offering their patched kernel, or to commercial solutions that fit just a bunch of their customers as-is. Their legal department, as usual, marks its steps in reviewing the article, by remarking that “The user is responsible for ensuring the applicability and timeliness of any resources that are relied upon.” No kidding. 

Looking ahead 

The community now needs to adapt to this new reality. Developers and companies must discuss how to best manage the implications of this shift. Here are a few questions that come to mind: 

-Should we abandon PetaLinux in favor of a full Yocto approach? Well, yeah, that’s what we’re being told.   Can you imagine, say, a CISO seeing “for demonstration purposes only” on a production build and       saying  “Nah, that’s fine”? 

-Is there a commercially supported Linux option that aligns with just about any current hardware and   production requirements? Of course not. BSP development requires knowledge and careful consideration  of all the specifics. Probably most of Xilinx customers will have to move towards a custom solution. 

-Do you think that a company should even start investing in using a PetaLinux solution for a project   today, knowing it would need to swap to something else for production at a later stage? There’s no   straightforward answer to that, adding even more complexity. 

It’s crucial that Xilinx engages directly with the developer community to address such concerns. A clear roadmap for production-grade solutions, along with guidance for those currently using PetaLinux, would go a long way towards restoring trust and helping developers plan their next steps. 

Conclusion 

PetaLinux has played a significant role in the rapid development of embedded solutions on Xilinx hardware. While recent changes in messaging might serve Xilinx’s internal interests, whether legal or strategic, it is essential that they consider the impact on the community that has trusted this tool for production use for many years. 

I call on Xilinx to address these changes openly, offering proper and meaningful alternatives and guidance that can support the diverse needs of their hardware ecosystem, rather than sending us to commercial solutions and build-from-scratch options in a few lines of text. Developers need transparency and clear paths forward to keep delivering effective solutions, and Xilinx has an opportunity here to foster that trust and collaboration. 

Have questions or insights to share? feel free to contact us for expert help. You can also visit here to learn more about us! 🙂