Your Vendor's BSP Is Probably Not Built For Product Longevity - Now What?

Your Vendor's BSP Is Probably Not Built For Product Longevity - Now What?

Vendor Board Support Packages (BSPs) are the standard for bringing new silicon to market, showcasing features, and promising an “easy” start. However, for those of us building products with long-term lifecycles, these BSPs often fail to meet quality requirements. They can be overly intrusive and typically don’t separate feature showcases from the well-maintained base needed for product development. This focus on rapid demonstration frequently results in BSPs which are difficult to maintain, lack transparency, and are built on non-LTS Yocto and kernel versions, making them unsuitable for products expected to last 5, 10, or even 20 years.

This talk will take a critical look at the state of vendor BSPs from an integrator’s perspective. We will explore the common pitfalls: opaque custom tooling, automatic inclusion of demo software, reliance on unmaintained kernel forks, and the widespread avoidance of Yocto LTS releases. We’ll discuss the differing perspectives of vendors and product developers, examine both good and bad real-world examples, and make the case for why writing your own sleek BSP layer is an absolutely valid strategy. Writing your own board descriptions and leveraging the stability of mainline Yocto and Linux kernels is not as daunting as it seems and can be the key to building truly sustainable and maintainable products.

Presented at

  • Yocto Project Summit 2025.12, online
Download slides

Related Posts

Organizing My Desk as an Embedded Engineer

Organizing My Desk as an Embedded Engineer

As an embedded dev, my desk is always a mess (and I think the ones of my colleagues, too). Working with real hardware leads straight to a number of boards, additional debuggers, tools, cables and more. And of course, as the most developers, I have a number of work projects and another of private ones. Even worse, I’m working from home for a good share of my time, so both kinds contribute to the mess there. Managing this is a constant effort and fight, but rarely successful.

Read Post
Patching Unpatchable Files

Patching Unpatchable Files

In the Yocto world, the .bbappend file is a well-known and documented mechanism for altering recipe files, and an essential part of daily operations. While not common, there are instances where it becomes necessary to modify other file types, such as .inc or .bbclass, which do not offer an equivalent append mechanism. This session will summarize various strategies for effectively handling these file types when patching cannot be avoided.

In my recent presentation at the Yocto Developer Day in Vienna, I mentioned using the KAS patch mechanism for minor modifications to files like .inc or .bbclass, where the Yocto internal overwriting mechanism via .bbappend files does not apply. Initially intended as a helpful side note on how I navigated a few unique situations, this part quickly escalated into the most discussed segment of the talk. Half of the attendees I spoke with found it valuable, while the other half expressed strong objections.

Read Post
International Women's Day - Why I wear Yocto Shirts on the Embedded World Exhibition

International Women's Day - Why I wear Yocto Shirts on the Embedded World Exhibition

Today, on the occasion of International Women’s Day, I’d like to give you an insight on working in Embedded as a woman: Why I’m searching for my best Yocto shirt and the nerdiest hoodie when I’m visiting the Embedded World exhibition.

Let’s go back some years to one of my first Embedded World visits. I was still a student doing my master’s degree in Embedded Systems. EW traditionally invites embedded students from all over Germany and adjacent countries on the third day, the student’s day. Together with some of my fellow students, I joined the trip and was looking forward to seeing new trends, talking to people, but also getting an idea where to apply for a job after finishing. At the exhibition, I started exploring together with some peers. Of course, all male. When going through the exhibition and talking to the people at the booths, I quickly recognized a pattern. The staff talked rather to the boys than to me. Mostly not quite obvious and probably not even on purpose. I think it’s about internalized stereotypes. They probably do not think that much about it, but obviously I was not a technically competent conversational partner to them at first sight, even if I asked the questions. I was an addition, an accompanying person from university or marketing. Mostly it was rather subtle, and I did not recognize it that much as the problem it was in the actual moment. But at some point we reached the Intel booth. I asked a question on something I was really curious about, and the male staff member started explaining to me and the accompanying students. During his talk, he started turning more to the boys until he showed me his back. I got a bit angry and told him directly that I would really like to hear the answer to the question I asked. Ok, bad, but human. So why am I telling this, and why do I mention Intel? Because I believe particularly such large companies should sensitize their employees working on a booth.

Read Post