Engineering services for embedded Linux and edge-AI products
Beyond training, TECH VEDA partners with product teams on the hard parts of embedded Linux — board bring-up, kernel and driver work, Yocto build systems, long-term BSP maintenance, and deploying AI on the edge. Two decades of kernel-level expertise, applied to your hardware and your roadmap.
How we engage
Engineering teams that have worked with us
What we do
Embedded Linux & edge-AI engineering, end to end
From first board bring-up to a hardened, production-ready system — we work at the kernel level so your team can focus on the product.
Board bring-up & BSP
U-Boot, bootloaders and board support packages for new hardware — SBCs, custom carrier boards and production silicon. We get Linux booting reliably on your platform.
Kernel & device drivers
Custom and upstream-aligned drivers, device-tree work, and kernel subsystem integration for sensors, displays, connectivity and accelerators — written, debugged and maintained.
Yocto & build systems
Reproducible Yocto/OpenEmbedded layers, custom images and SDKs, plus CI for embedded builds — a maintainable foundation your team can own long-term.
Edge-AI deployment
Getting AI models running efficiently on edge hardware — accelerator integration, runtime optimisation and the embedded Linux plumbing around inference on real devices.
Debug & performance
Crash-dump analysis, tracing, latency and boot-time optimisation, power tuning — the deep kernel debugging that turns a flaky prototype into a dependable product.
Prototyping & advisory
Rapid hardware/software prototyping on SBCs, platform selection guidance, and architecture reviews to de-risk decisions before you commit to silicon.
BSP lifecycle
The kernel in your product has an end-of-life date
A vendor BSP is pinned to one kernel version, and every kernel version has a date after which upstream stops publishing security fixes. After that date, maintaining it is your team’s job. This is the work we do most.
BSP and branch audit
Which branch your vendor actually maintains — often not the highest version number — the kernel it pins, and the date upstream fixes for that kernel stop. Your Yocto layer is checked the same way: what it declares, and which release branches exist behind the claim.
Kernel maintenance and CVE backporting
Once the kernel under your product reaches end of life, upstream sends nothing. We triage each CVE against your tree, backport the fixes that apply to it, and test them on your board, for as long as the product ships.
Moving to a newer vendor BSP
The second bring-up: a new kernel base, your patches forward-ported, drivers re-validated, the product re-tested. Scoped honestly, because this is the option teams under-estimate most.
Mainline migration
A block-by-block gap analysis of your SoC — GPU, video decode, video encode, NPU, ISP. What mainline supports today, what has to be written or upstreamed, and what the move costs. It is the only option that does not have to be repeated for the next vendor kernel.
Secure boot and field updates
Whether you can safely replace the bootloader on a device already with a customer, what your anti-rollback budget allows, and how re-signing works on fuse-locked silicon. Teams usually discover these limits during an emergency.
Upstreaming
Getting your drivers and device-tree work into mainline, in mainline’s style, through review. It is the only way to stop carrying a patch forever, and it is a skill, not a formality.
Where we come in
Before the schematic is frozen
You are choosing silicon. We tell you which BSP branch is real, when its fixes stop, and what mainline does and does not carry on each candidate — while the decision is still reversible.
Mid bring-up, and stuck
The board boots but something does not: a driver, a display pipeline, an accelerator, a boot time nobody can get under budget. We come in on the specific problem and leave when it is solved.
The cliff is coming
Your BSP kernel has twelve or eighteen months of upstream fixes left. This is the cheapest moment to act, and the one teams most often let pass.
It is already past end of life
The most common call we get. It becomes triage: what is exposed, what is worth backporting, and whether jumping BSPs or going mainline costs less than carrying this tree another year.
How long we commit, and what you are buying
As long as the product ships
Maintenance runs on a fixed, renewable term set against your product’s support period — not a calendar year, because that is not the horizon the obligation has. Audits and migrations are fixed-scope and end when they end.
A team, not one contractor
A lead who owns your tree and is the person you speak to, engineers across the subsystems the product leans on — kernel, bootloader, drivers, Yocto, secure boot — and a reviewer on every patch. One person being unavailable never stops the work.
You can leave, and still ship
The tree we hold is yours: patches in upstream format with real commit messages, a documented branch, a build your team can run without us. Leave at renewal and you leave with a maintainable kernel, not a dependency.
Not a dashboard. Not a certificate.
We publish the underlying data. The BSP Tracker follows 17 SoCs — the branch each vendor really maintains, the kernel it pins, the date fixes stop — free, and re-checked weekly. Look up your silicon on the BSP status table first, and the conversation starts from your date rather than from a pitch.
Talk to us about your BSPQuestions teams ask before they engage
We already have kernel engineers. What do you actually add?
Usually one of two things. Either a specific piece of work nobody on the team has done before — a mainline migration, an upstream submission, a subsystem nobody wants to open — or capacity, because your kernel people are on the product and the maintenance keeps slipping. What arrives is a team rather than a lone contractor: a lead who owns your tree, engineers across the subsystems it depends on, and review before anything reaches your build. We are not trying to replace your engineers. If the honest answer is that you can do this in-house, we will say so.
How long do you commit for?
A maintenance engagement runs on a fixed term, renewable, and is normally set against your product’s support period rather than a calendar year, because that is the horizon the obligation actually has. An audit or a migration is fixed-scope and ends when it ends. We would rather agree a term you can leave than one you cannot.
Are we locked in?
No, and the deliverables are designed to make that true. The tree we hold is your tree: patches in upstream format with real commit messages, a documented branch, and a build your team can run without us. If you leave at renewal, you leave with a maintainable kernel, not with a dependency.
Who actually does the work? Is it one person?
A team. A lead engineer owns your tree and is the person you speak to, with engineers across the subsystems your product depends on — kernel, bootloader, drivers, Yocto, secure boot — and a reviewer on every patch. Nobody carries the whole product in their head, and nobody being unavailable stops the work. That continuity is the point of hiring a team rather than a contractor.
Do you work on our hardware, or a reference board?
Yours. Reachability, boot time, driver behaviour and update paths are properties of your board and your build, not of an evaluation kit. Where a board cannot leave your site, we work on your infrastructure.
Our BSP kernel is already past end of life. Is it too late?
No, and this is the most common situation we are called into. It changes the question from prevention to triage: what is exposed, what can be backported at reasonable cost, whether a jump to the vendor’s newer BSP is cheaper than carrying this one, and whether mainline is open to you at all. That assessment is the first engagement, and it is usually short.
What does a BSP audit produce?
A written record with dates and sources: the branch your vendor actually maintains, the kernel it pins, the date upstream fixes stop, which blocks mainline supports on your SoC and which it does not, what your Yocto layer really has branches for, and a costed comparison of the three options open to you. It is the same method behind our public BSP Tracker, run against your specific silicon and build.
Expert consulting
Sometimes you do not need a project. You need an answer.
Not every problem is a delivery engagement. Some are one decision, one review, or one week of somebody who has been here before — and they are usually the cheapest hours a product ever buys, because they are spent before the mistake, not after it.
Architecture and platform review
Your board, your BSP, your build system, reviewed by someone who has seen how this ends. Delivered as a written opinion with the risks named, not a slide deck.
Silicon selection
Before the schematic freezes: what each candidate SoC really has upstream, what its BSP is pinned to, when the fixes stop, and which module vendors will still sell you the part in five years.
Code and patch review
Driver and kernel patches reviewed the way a maintainer would review them — locking, lifetimes, error paths, device-tree bindings — before they reach a mailing list or a product.
A second opinion on a hard bug
A crash nobody can reproduce, a latency spike nobody can explain, a board that fails one in fifty boots. Sometimes the fastest route is an outside pair of eyes for a day.
Expert on call
A standing block of time each month for your team to use: design questions, review, debugging, or a conversation before a decision rather than after it.
Mentoring inside the team
Not a course. Your engineers, your codebase, working through the real problem alongside someone who has done it — which is how this skill has always actually transferred.
Engagements start at a single day. If a day is all you need, we will say so and stop there — and if the honest answer is that your own team can do this, we will say that too. Twenty years of teaching this work means we would rather be trusted than booked.
Ask an expertVulnerability response & the Cyber Resilience Act
A disclosure lands on a Friday. What happens next?
From 11 September 2026, a manufacturer selling into the EU must report an actively exploited vulnerability within 24 hours, file a fuller notification within 72, and report again within 14 days of a fix being available. The rest of the CRA follows on 11 December 2027. Those are engineering clocks, not paperwork clocks: nobody can answer them without already knowing what they ship and whether they can update it.
CRA readiness review
A fixed-scope engagement, before anything goes wrong.
- A bill of materials for the software you actually ship — kernel, U-Boot, libraries, every component inside the vendor BSP, with versions
- The end-of-life date for each of them, joined against upstream
- The update path, tested on real hardware: can you replace the kernel, and can you replace the bootloader
- Your anti-rollback and re-signing budget, established before you need it
- A written gap list, in the language your compliance team has to answer in
Disclosure response
On call for the week an advisory lands.
- A reachability verdict: does the vulnerable code run in your build, on input an attacker controls
- The backport, adapted to your vendor fork rather than to mainline
- A re-signed, tested image, and the vendor pressed with specifics when the tree is theirs
- The technical text of the advisory you owe your customers, with the advisory IDs and commits cited
- A dated record of what was known when — which is what a 24-hour clock ultimately demands
Ongoing maintenance
For teams with no kernel engineer to spare.
- We hold the tree: your BSP, your patches, your branch
- Monthly CVE triage against the kernel you actually run, not against a generic list
- Patch sets you can build and ship, tested on your board
- A maintained evidence log, so the reporting duty is a lookup rather than a scramble
- Your engineers stay on the loop, not out of it — the work is visible, not hidden behind a support contract
What you are buying
Four questions arrive with the clock. You are buying the ability to answer them that day, rather than begin investigating them.
What is in this product?
Answered by a bill of materials you keep current, so the component can be looked up rather than searched for inside a vendor BSP while an incident is running.
Is the flaw reachable in our build?
Answered by checking your kernel configuration and how the data reaches the vulnerable code. Often the answer is no, and that alone turns an emergency into scheduled work.
Who writes the patch, and by when?
Answered by a team that already holds your tree, and by asking your silicon vendor a specific question with a date attached rather than opening a support ticket.
Can we get it onto devices in the field?
Answered before the disclosure arrives, by testing the update path and the anti-rollback budget on real hardware.
What we do not do. We are engineers, not your legal counsel. We do not file with a CSIRT or ENISA on your behalf, and we will not tell you where you sit in the regulation. We produce the technical evidence your legal and compliance teams cannot produce themselves — so their filing is a transcription, not an investigation.
Not hypothetical. In July 2026, six flaws were disclosed in U-Boot’s verified boot, all in the image parser that runs before the signature check. We published the reachability analysis, the four hops a fix must travel, and the anti-rollback constraint that decides whether you can ship it: the U-Boot analysis · what the CRA requires.
Questions teams ask us about the CRA
Does the CRA actually apply to us?
If you place a product with digital elements on the EU market, it very likely does, whoever wrote the software inside it. Buying a board, an SoC or a vendor BSP does not move the duty: you are the manufacturer of the finished product. We are not your legal counsel and will not tell you where you sit in the regulation — we tell you what is technically true about your product, which is the input your legal and compliance people need before they can answer that question at all.
We use our silicon vendor’s BSP. Is this not their problem?
Their kernel, your product. The CRA expects a manufacturer to exercise due diligence over the third-party components it integrates, and a customer or a regulator will ask you, not your SoC vendor. In practice the vendor decides the schedule and you carry the obligation, which is exactly why the first thing we do is establish what their tree really contains and when its fixes stop.
What is actually due on 11 September 2026?
From that date, an actively exploited vulnerability or a severe incident has to be reported: an early warning within 24 hours, a fuller notification within 72, and a final report within 14 days of a corrective measure being available. The remaining obligations — secure-by-design, technical documentation, structured vulnerability handling — apply from 11 December 2027. The 24-hour clock is the one that catches teams, because it starts before anyone has read the code.
There is no CVE. Do we still owe anyone anything?
Yes. The six U-Boot flaws disclosed in July 2026 carry no CVE identifiers, which means no scanner will flag them for your customers and no NVD entry exists to point at. The duty to handle a known vulnerability does not depend on someone having assigned it a number. We write the advisory around the vendor advisory IDs and the upstream commits instead.
How quickly can you tell us whether a disclosure affects us?
For a product whose build we already hold, usually the same week: reachability is a configuration and data-flow question, not a research project. For a first engagement it takes longer, because the first job is establishing what you actually ship — which is the argument for doing that work before a disclosure, not during one.
What if we cannot update the bootloader in the field?
Then that is the finding, and it outranks the vulnerability. An architecture that structurally cannot deliver a security fix through the support period does not meet the CRA bar, and no amount of patching upstream changes that. We test the update path and the anti-rollback budget on real hardware and tell you plainly whether the fleet is recoverable.
Do you file the reports for us?
No. Reporting to a CSIRT and ENISA is your legal team’s act, not ours. We supply what they cannot produce themselves: the bill of materials, the reachability verdict, the patch, the tested update, and the technical wording of the advisory — with dates and sources attached, so the filing is a transcription rather than an investigation.
How we engage
A clear path from idea to a system you can ship
Engagements are scoped to your needs — a focused advisory sprint, a defined deliverable, or ongoing engineering support alongside your team.
Scope
We review your platform, goals and constraints, then propose a clear plan with deliverables, timeline and the right engagement model.
Build
Hands-on engineering — bring-up, drivers, Yocto, edge-AI integration — with regular checkpoints and visibility into progress.
Harden
We debug, optimise and stabilise: boot time, latency, power and reliability — until it behaves like a product, not a prototype.
Hand over
Documentation, knowledge transfer and optional training so your team can own and extend the system with confidence.
Why TECH VEDA
Kernel-deep expertise, applied to your product
Two decades at the kernel level
The same depth that powers our training drives our engineering — internals, drivers and subsystems most teams rarely touch. More about us →
Built around your hardware
Every engagement is shaped by your platform, timeline and goals — from SBC prototypes to production silicon. Discuss your project →
Hands-on, not slideware
We deliver working systems — debugged, optimised and documented — and transfer the know-how so your team isn't left dependent.
Trusted by serious teams
We've worked with engineering organisations including Mercedes-Benz, AMD, NXP, Qualcomm, Siemens and Stryker. See our clients →
Project enquiry
Tell us what you're building
Share your platform, goals and timeline. We'll come back with the right engagement model, a clear scope and next steps — usually within one business day.
- ✓ Board bring-up, kernel, drivers, Yocto, edge-AI & BSP maintenance
- ✓ Flexible models — advisory, fixed-scope or ongoing
- ✓ Vulnerability response and CRA evidence — SBOM, reachability, advisory
- ✓ Response within 1 business day · info@techveda.org