SoC Kernel Support: How to Tell If Yours Has Already Lapsed

SoC kernel support is not one date, it is three independent clocks: the upstream LTS end-of-life date, the last time your vendor's BSP branch actually moved, and whether the silicon carries a public availability commitment. All three are measurable in a few minutes, and most teams never measure any of them. We maintain a public BSP tracker covering seventeen SoCs and re-verify every field weekly against the real git refs and kernel.org; the most recent refresh was 9 August 2026. Running the measurement across that dataset: two vendor branches have not received a commit in more than 300 days, one shipping platform runs a kernel series that is not an LTS at all, and for only four is a specific silicon longevity date available in the public domain at all.

Most embedded teams discover that their SoC kernel support has lapsed at the worst possible moment: when a CVE lands, a customer asks for a patched image, or a certification body asks how long the product will receive updates. The uncomfortable part is that the lapse is almost always visible months or years earlier, in public data, to anyone who thinks to look.

This article gives the method. It is deliberately reproducible: every check below is something you can run yourself against public sources in an afternoon, and every number we quote is dated so you can re-run it and see whether it has moved.

We also publish the result, because the aggregate is more instructive than any single board. TECH VEDA maintains a public BSP tracker covering seventeen SoCs, and our engineering team rechecks every field once a week against the vendors' real git refs and against kernel.org — the last refresh ran on 9 August 2026. The branch ages quoted below were re-checked directly against the GitHub API on 10 August 2026, so they can be reproduced rather than taken on trust. The living data is at kernel lifecycles and on the per-SoC pages linked throughout.

The three clocks behind SoC kernel support

"Supported" is a word that hides three different guarantees, made by different parties, that expire at different times.

1. The upstream LTS clock. The kernel.org stable team publishes an end-of-life date for each longterm series. After it, no more stable fixes are produced by anyone, for anybody.
2. The vendor branch clock. Your silicon vendor maintains a BSP branch. It has a head commit, and that commit has a date. If that date stops advancing, the vendor has stopped merging fixes into the tree you are consuming, whatever the roadmap says.
3. The silicon longevity clock. Separately from software, the vendor may commit to keeping the part orderable until a stated year. This is the one most often assumed and least often verified.

These are independent. A part can have a 2045 availability commitment and a BSP branch that has not moved in eight months. A vendor can be committing daily to a branch built on a kernel that reaches end-of-life this year. Your actual exposure is set by whichever clock expires first, not by the one the datasheet advertises.

Clock one: the upstream end-of-life date

Start here, because it is the cheapest to check and it caps everything else. Find your kernel series and read its projected end-of-life from kernel.org:

raghu@techveda.org:~$ uname -r
6.1.182-mydevice
raghu@techveda.org:~$ curl -s https://www.kernel.org/releases.json | \
    jq -r '.releases[] | select(.moniker=="longterm") | "\(.version)  EOL \(.eol // "n/a")"'

Verified against kernel.org on 10 August 2026, the six longterm series stand as follows. Two of them expire this year. We keep this table current at kernel lifecycles:

There is a trap in this step that affects more products than the EOL dates do. Not every kernel a vendor ships is a longterm series at all. If your kernel series does not appear on that list, it has no upstream longterm stable-maintenance window to plan against. That is not the same as having no maintenance: continued fixes may still arrive through the vendor's own release stream, a distribution, or another explicitly documented maintenance path. What it does mean is that you cannot rely on upstream, and the burden shifts to establishing what that documented path actually is. We found exactly this case in our own data, described below.

Key insight: Check that your kernel series is on the longterm list before you check its end-of-life date. A series that is absent is not early in its upstream support window — it is outside one, and whatever maintenance it receives has to be established from the vendor rather than assumed.

Clock two: is the vendor branch still moving

This is the measurement almost nobody runs, and it is two commands. Resolve the branch head, then ask when that commit was made:

raghu@techveda.org:~$ git ls-remote https://github.com/rockchip-linux/kernel develop-6.6
1ba51b059f25533c5529b7f68186190b47d6a7b3    refs/heads/develop-6.6
raghu@techveda.org:~$ curl -s https://api.github.com/repos/rockchip-linux/kernel/branches/develop-6.6 | \
    jq -r '.commit.commit.committer.date'
2025-09-01T11:22:35Z

That is the whole check. Run it against the branch you actually build from, not the branch named in the marketing material. Record the date and re-run it quarterly; the trend matters more than any single reading.

Two cautions on method. Use the committer date rather than the author date, because a patch written months earlier can be merged today and the committer date is what tells you the tree is alive. And on repositories that are not on GitHub, the equivalent is a shallow clone: git clone --depth 1 --branch <branch> <url> followed by git log -1 --format=%cI.

Treat the resulting number as an investigation trigger rather than a support verdict. A quiet branch may still be supported through periodic SDK drops or a declared rebase cadence. What a long gap does establish is that you owe yourself a documented answer. As rough review triggers — our own, not an industry standard — we treat under 90 days as unremarkable, 90 to 180 days as worth raising at the next vendor call, and beyond a year with no published cadence as something to get in writing before design lock-in.

Clock three: the silicon longevity commitment

The third clock is not about software at all. It is the vendor's public commitment to keep the part orderable until a stated year, and it matters because it bounds how long the software question is worth asking. This is the clock most often assumed from a sales conversation and least often traced to a published document.

When we tried to pin a specific date to each of the seventeen SoCs in our tracker, requiring a public source rather than a sales claim, we could verify one for four of them. AMD states 2045 for Zynq UltraScale+, Renesas 2038 for RZ/G2L, Qualcomm July 2036 for QCS6490, and NVIDIA January 2032 for Jetson Orin.

For the other thirteen, no end date for that part is available in the public domain. That is a finding about what a buyer can obtain without a sales conversation, and it is worth being precise about how it was reached: for each part we checked the vendor's public product page, its lifecycle or longevity documentation, and any published product-change or availability notice. Where none of those carried a date for that specific part, the cell reads "no public date".

It does not mean the vendor offers nothing. Several of them operate published longevity programmes: NXP runs a Product Longevity Program offering a minimum of 10 or 15 years from launch, and ST publishes a commitment spanning 7 to 20 years, with a 10-year programme covering parts in the STM32MP13 series. The gap is between the programme and the part. Enrolment is generally documented per part number rather than per SoC family, and for these thirteen the per-part answer is not published where a buyer can find it.

The practical consequence is the same either way: a commitment you cannot obtain from public documentation is one you cannot cite in a design review or pass to a customer, so ask your vendor to confirm enrolment and the end date for your exact part number in writing. A common substitute is a longevity claim from a module or system-on-module vendor; that covers the module, depends on the module vendor's own supply of the silicon, and is not interchangeable with a commitment from the chip vendor.

What seventeen SoCs actually look like

We applied all three checks across all seventeen SoCs on 10 August 2026. The full table is not reproduced here, because it would be out of date within the week and we maintain a live version instead: SBC support status for development boards, sorted by how much cover is left, and the SoC mainline support matrix for the per-IP-block picture. The shape of the result on the day we measured:

• Branch head ages spanned 6 days to 370 days. Most sat under 80 days. Two were past 300, and one SoC has no public git to measure at all.
• Kernel bases spanned 5.15 to 6.18, with one shipping platform on a series that is not on the longterm list.
• Four of the seventeen carried a silicon longevity date we could find in public documentation. For the rest the cell reads "no public date".

Three results are worth drawing out.

The Allwinner T507 line ships on 5.15, which reaches end-of-life in about five months. There is also no public git server with release branches to measure against; the SDK is distributed as a repo manifest and archive downloads. Both facts are properties of how that vendor distributes software, and both mean an integrator cannot answer "when does my support end" from public information.

Jetson Orin's current JetPack ships kernel 6.8, and 6.8 is not a longterm series. It does not appear on the kernel.org longterm list, so there is no upstream stable stream behind it and no projected end-of-life to plan against. Support for that platform flows entirely through NVIDIA's own releases, which is a coherent model, but it means the upstream clock gives you nothing and the vendor clock is the only one that exists.

For Rockchip's RK3588, the newest branch is staler than the default one. develop-6.6 last moved 343 days ago; develop-6.1, which is the repository default, last moved 227 days ago. An integrator who reasonably picks the highest kernel version on offer lands on the less maintained tree. Note also that no 6.12 or 6.18 branch exists in that repository at all, so the newest kernel available there is already two LTS generations behind current.

Key insight: The newest branch in a vendor repository is not necessarily the maintained one. Check the head date of every candidate branch before choosing, because the highest version number can be the least supported option on offer.

What a stale branch does not prove

This is the most important section in the article, because the measurement above is easy to over-read. A branch head date is a fact. What it means requires care, and there are at least five reasons a quiet branch is not evidence of an abandoned product.

• Public git is not the only channel. Several vendors deliver production BSPs under NDA, through a support portal, or as periodic SDK releases rather than as continuous commits. A quiet public mirror can sit alongside an actively maintained internal tree that you receive as a customer. What the public branch measures is what a prospective integrator can see before signing anything, which is a real and different question.
• A board vendor's fork is not the silicon vendor's tree. The 370-day figure above belongs to Khadas, not Amlogic. Amlogic publishes no public vendor tree for this part at all, so the nearest observable proxy is a board vendor's fork. That is a fair thing to report about what an integrator can inspect, and an unfair thing to characterise as Amlogic neglecting the part.
• Older branches are supposed to go quiet. NXP's lf-6.6.y and lf-6.12.y have taken no commits since November 2025 while lf-6.18.y is current. That is ordinary branch retirement after a migration, not decay. The question is only whether the branch you build from is the current one.
• Some industries deliberately pin. Automotive teams working with J721e typically track the branch matching a released Processor SDK rather than the newest branch, because the qualified configuration matters more than the freshest one. A pinned branch under a support contract is a different situation from a pinned branch by accident.
• Cadence differs legitimately. ST rebases the STM32MP branch roughly every eighteen to twenty-four months by design. Measured on any given day that looks slow next to a vendor that merges weekly, but it is a stated cadence rather than a lapse.

The honest formulation is narrow: a stale public branch tells you that you cannot verify from public sources that fixes are still flowing into the tree you build from. That is a procurement and due-diligence problem. Turning it into a claim about a vendor's intentions goes well beyond what the data supports.

Key insight: Measure what you can see, and say only what the measurement supports. "I cannot verify that this tree is receiving fixes" is defensible and actionable. "This vendor has abandoned the part" usually is not.

Why these dates matter

None of this is bookkeeping. Each SoC kernel support clock has a consequence attached, and teams usually meet them in the same order.

A vulnerability lands and there is no fix to take. While a series is in its upstream window, a CVE in a subsystem you ship arrives as a stable patch you can pull. After end-of-life, nobody produces that patch. Your options narrow to backporting it yourself from mainline, paying someone to do it, or shipping a known-vulnerable image. The first is expensive and needs a person who can read the subsystem; the third is increasingly not a choice.

Someone asks a question you cannot answer quickly. This is the one that has changed most, and it is no longer a single regulation. Four triggers now reach the same set of facts from different directions:

• EU Cyber Resilience Act. Reporting obligations for manufacturers begin on 11 September 2026: an actively exploited vulnerability in a product with digital elements must be reported within 24 hours of the manufacturer becoming aware of it. To report inside a day you must first establish whether the vulnerability is in your image, which is a question about which kernel you ship and which patches reached it.
• UK PSTI. The product security regulations require a manufacturer to publish a defined support period — in the wording of the regulations, "the minimum length of time, expressed as a period of time with an end date, for which security updates will be provided". Once published it may be extended but not shortened. You cannot responsibly publish that date without knowing the three clocks behind it, because the commitment outlives your ability to revise it.
• EU Radio Equipment Directive. The cybersecurity provisions of the delegated act became mandatory on 1 August 2025 for radio equipment placed on the EU market, which covers most connected embedded products with a wireless interface.
• Sector frameworks. Automotive programmes work to UN Regulation No. 156 on software update management systems; industrial and medical programmes reach the same questions through their own standards and regulator guidance. A customer negotiating a support term asks it in plainer language and expects a date.

The common thread is that all four ask you to state, in advance and in writing, how long a product will keep receiving security updates. That is not a policy question. It is the minimum of your three SoC kernel support clocks.

A routine uplift turns into a migration. Moving from one LTS to the next while you still have a choice is a planned engineering task. Doing it because your series died, or because a vendor branch stopped moving, means the same work with no schedule, and on a shipped product it drags re-validation and often re-certification behind it. The engineering content is similar; the cost is not, because unplanned work displaces whatever else was in the quarter.

The part stops being orderable. The longevity clock is the one that cannot be solved with software. If the silicon goes end-of-life inside your product's support window, the answer is a board respin and a new bring-up, and the lead time on that is measured in quarters.

The reason to measure early is that every one of these is cheaper as a decision than as an emergency. A stale branch found during SoC selection changes a line in a comparison table. The same fact found when a CVE is already public changes a release plan.

Key insight: Support lapse is rarely discovered by the team that caused it. It surfaces when an outside party — an attacker, a regulator, an auditor or a customer — asks a question with a deadline attached. Measuring the three clocks is how you find out on your own schedule instead.

What to do before your next SoC selection

Measuring SoC kernel support is only useful if it happens while you still have a choice of part. Five steps, in the order that saves the most time:

1. Check the kernel series is on the longterm list at all, then read its end-of-life date. If the series is absent, all support flows through the vendor and you should price that accordingly.
2. Measure the head date of every candidate branch, not just the one you were pointed at. This is the step that surfaces the newest-is-not-maintained case.
3. Ask for the longevity commitment in writing, and check whether it covers the silicon or a module. If you cannot find a public statement, that is a question for procurement rather than an assumption to carry.
4. Compare the vendor tree against mainline for your blocks. If the peripherals you depend on are upstream, a stale vendor branch is an inconvenience. If your camera, video encode or accelerator exists only in the vendor fork, that branch is your only source of fixes and its head date is your security posture.
5. Re-run all of it quarterly, and record the result where the product plan lives. A single reading tells you little; four readings tell you whether a tree is slowing down. Store the evidence, the date of the next review, and the condition that would force a migration — a kernel EOL, a branch crossing your staleness threshold, or a longevity date entering your support window. A number in someone's notebook is not a lifecycle plan.

Steps four and five are where this connects to the wider shift we wrote about in upstream-first BSPs and in architecting mainline-friendly products. The reason upstream-first lowers risk is precisely that it moves your dependency from a branch whose head date you cannot control to a tree with a published support window.

Where to find the current numbers

Every figure in this article goes stale, which is the point. Rather than ask you to trust a snapshot, we keep the underlying data live and re-verify it weekly:

• SBC support status — the three clocks applied to 29 development boards across these SoCs, sorted by how much cover is left, with a "fixes stop" date on each row. This is the fastest way to find your own board.
• SoC mainline support matrix — all seventeen SoCs against each IP block, showing which peripherals are upstream and which still need the vendor tree. This is the check in step four above.
• Kernel lifecycles — current patch level, release date and projected end-of-life for every longterm series, checked against kernel.org. This is clock one.
• Per-SoC pages carrying the BSP branch, its head date and the longevity position, including RK3588, QCS6490, Jetson Orin and T507.
• Yocto layer compatibility — whether your vendor BSP layer actually has a branch for the Yocto release you are targeting, read from each layer's own git history.

A field with no primary source stays empty rather than being filled in by inference, which is why some cells read "no public date" rather than carrying a number. The wording is deliberate. It records that the figure is not obtainable from public documentation, which is the thing that affects you, and it makes no claim about what a vendor will commit to privately.

If you are planning a long-lived embedded Linux product, this assessment is worth running across the whole product line rather than one board: which of your peripherals exist upstream, what a migration off a stale branch would actually cost, and where your real support cliff falls. Doing it before a CVE, a certification audit or a supply-chain event forces the question is the difference between a scheduled uplift and an unplanned migration project. That is the work our BSP and kernel engineering team does.

Key takeaways

• SoC kernel support runs on three independent clocks: upstream LTS end-of-life, the vendor branch head date, and the silicon longevity commitment. Your exposure is set by whichever expires first.
• Check that your kernel series appears on the kernel.org longterm list before checking its EOL date. Jetson Orin's current JetPack ships 6.8, which is not a longterm series.
• Measuring a vendor branch takes two commands, and the committer date of the branch head is the number that matters.
• The newest branch is not always the maintained one. Rockchip's develop-6.6 is 343 days stale while the default develop-6.1 is 227 days stale.
• A specific silicon longevity date is publicly available for only four of the seventeen SoCs we track. Several other vendors run published longevity programmes, but the per-part enrolment and end date are not published where a buyer can find them. Module-level claims are not silicon-level claims.
• The consequences are asymmetric: a stale branch found during SoC selection is a line in a comparison table, while the same fact found after a CVE is public is a release-plan problem. CRA reporting obligations from 11 September 2026 make the question harder to defer.
• A quiet public branch means you cannot verify that fixes are flowing, not that a vendor has abandoned a part. NDA channels, SDK releases and deliberate branch retirement all look identical from outside.

Frequently asked questions

How do I check when a vendor BSP branch last moved?
Resolve the branch head with git ls-remote, then read the committer date of that commit. On GitHub-hosted trees the branches API returns it directly; elsewhere a shallow clone followed by git log -1 --format=%cI gives the same answer. Use the committer date rather than the author date, because it reflects when the change entered the tree.

My kernel version is not on the kernel.org longterm list. What does that mean?
It means the series is not receiving upstream stable maintenance and has no projected end-of-life to plan against. All fixes for that platform come from the vendor, so the vendor's release cadence becomes your only support clock.

Does a stale vendor branch mean the SoC is abandoned?
No. It means you cannot verify from public sources that fixes are still reaching the tree you build from. Vendors also ship through NDA channels and periodic SDK releases, older branches are retired deliberately after a migration, and some vendors rebase on a stated eighteen to twenty-four month cadence.

Is a ten-year longevity claim from my module supplier the same as one from the chip vendor?
No. A module vendor's commitment covers the module and depends on that vendor's own supply of the silicon. Several chip vendors run published longevity programmes, but enrolment is documented per part number and for most of the parts we track that per-part date is not in the public domain. Ask for your exact part number in writing rather than assuming family-level coverage.

How often should I re-run these SoC kernel support checks?
Quarterly is enough for a product in development, and the trend matters more than any single reading. Record the head dates each time, because a tree that is slowing down is visible in a series of measurements and invisible in one.

Further reading

• Active kernel releases and projected end-of-life dates — kernel.org, the source for clock one.
• The Shorter Kernel LTS Support Window: What It Means for Embedded Products — TECH VEDA, on why clock one moves faster than it used to.
• Upstream-First BSP: Why Vendors Are Moving to Mainline — TECH VEDA.
• Architecting Mainline-Friendly Products — TECH VEDA.
• UK Product Security regulations 2023 — the source for the "defined support period" wording.
• NXP Product Longevity Program and ST Product Longevity — two examples of published vendor programmes; check enrolment for your exact part number.
• rockchip-linux/kernel branch list and khadas/linux khadas-linux-6.12.y — the two trees quoted above, so the branch dates can be re-checked directly.

— Raghu Bharadwaj

Originally published on the TECH VEDA blog.