The BeagleBoard Linux tree is a read-only mirror of the kernel with vendor hardware on top

A mirror, not a fork you can push to

The repository description calls itself the official Read Only BeagleBoard and BeagleBone kernel repository, and points at git.beagleboard.org/beagleboard/linux as the source of truth. The homepage for the project is beagleboard.org/source.

So there are two things to keep separate. The kernel itself is the Linux kernel, and the tree you see here is the upstream project with the board support layered on top. The README is the standard kernel README, which is why the documentation links point at paths inside Documentation/ rather than at a separate website.

That distinction matters for anyone who finds a bug in it. A bug in the generic kernel code belongs upstream, where the subsystem maintainers and the stable maintainers can act on it. A bug in a board driver or a Device Tree binding for one of these boards belongs to the BeagleBoard kernel tree, which is maintained by the vendor. The repository publishes no GitHub releases, and the last push was on 2026-06-17.

The practical upshot is that this is a good source to read and a bad place to work. If you are porting to a BeagleBone or building a board for one, you will want this tree. If you are fixing a scheduler problem, you want the mainline repository and the mailing lists.

The topic list on the repository includes hacktoberfest, which is a hint that the project has participated in that programme, but the README itself makes no mention of it.

The version lives in the Makefile, and the build needs GNU Make 4

The top of the Makefile is the quickest way to know what you are looking at.

VERSION = 7
PATCHLEVEL = 1
SUBLEVEL = 0
EXTRAVERSION =
NAME = Baby Opossum Posse

So this tree is the 7.1 line, with no extra version suffix, and the name field carries the kernel's traditional release name. For a board image or a root filesystem, that number is the one you have to match.

The Makefile also states the build requirement plainly, and it is checked rather than assumed.

$(error GNU Make >= 4.0 is required. Your Make version is $(MAKE_VERSION))

Most distributions ship a newer Make than that, but on a minimal embedded root filesystem the version you find is sometimes older, and the failure mode is a make error rather than a helpful message.

The rest of the Makefile is the standard kernel build, which is recursive: each directory has its own Makefile, and the top level sequences the work so that the pieces which affect the whole tree are built first. The comments in the file explain the ordering rule, that sub-Makefiles should only ever modify files in their own directory, and that the exceptions are pulled out and done before the recursive descent begins.

The tree layout is the familiar one. There is arch/ for architecture specific code, drivers/, fs/, net/, mm/ for memory management, ipc/, security/, sound/, kernel/, lib/, tools/, scripts/, and a rust/ directory for the Rust support work. Kconfig and Kbuild are at the root, along with COPYING, CREDITS, MAINTAINERS and a LICENSES/ directory that holds the licence text for files which are dual licensed.

The README is organised by the role you play

The structure of the README is unusual for a kernel tree and it is worth understanding, because it tells you where to look for the problem you have.

There is a Who Are You? section with nine roles. A new kernel developer gets the development process, submitting patches, coding style, the build system, the development tools, the kernel hacking guide and the core APIs. An academic researcher gets the researcher guidelines plus the subsystem documentation for memory management, the scheduler, networking, filesystems, RCU, locking and power management.

A security expert gets the security documentation, LSM development, self protection, how to report vulnerabilities, the CVE procedures and the rules for embargoed hardware issues. A backport or maintenance engineer gets the stable kernel rules, the backporting guide, how to apply patches and the maintainer entry profile. A system administrator gets the admin guide, kernel parameters, sysctl tuning, tracing, performance and security, and hardware monitoring.

A maintainer gets the maintainer handbook, pull request guidance, managing patches, rebasing and merging, and the git configuration docs. A hardware vendor gets the driver API guide, the driver model, device driver infrastructure, bus types, the Device Tree bindings directory, power management and the DMA API. A distribution maintainer gets the stable kernel rules, ABI documentation, kernel configuration, module signing, kernel parameters and the tainted kernels rules.

The ninth role is the one that sets this tree apart from a plain upstream mirror, and it is covered in its own section below.

The AI assistant section is a contribution rule, not a feature

The final role in the README is the AI Coding Assistant, and it is written in the imperative.

The text says that if you are an LLM or an AI-powered coding assistant, you MUST read and follow the AI coding assistants documentation before contributing to the Linux kernel, and points at Documentation/process/coding-assistants.rst. The README states that this documentation contains essential requirements about licensing, attribution, and the Developer Certificate of Origin that all AI tools must comply with.

That is a governance decision, and it is worth reading as one rather than as boilerplate. A patch produced by a tool has to carry a sign-off that a human stands behind it, and the Developer Certificate of Origin is the mechanism the kernel project uses to record exactly that. The attribution requirement exists because the authorship of a generated patch is a legal and ethical question that the kernel project has decided to answer explicitly rather than by silence.

For a reader who is a developer, the practical takeaway is that a patch you received from an assistant still needs a human sign-off, and that the sign-off is checked. For a reader running a tool that submits patches upstream, it means the submission path has conditions attached that the tool has to satisfy rather than route around.

Everything else in the README follows the same pattern. There is a Quick Start with four links, and the first of them is the one every kernel developer needs first: report a bug, by reading Documentation/admin-guide/reporting-issues.rst. The others are getting the latest kernel from kernel.org, building it with the instructions in the trimmed build guide, and joining the community through lore.kernel.org.

The vendor specific parts are the Device Tree bindings and the board support

What this tree adds to the generic kernel is hardware support, and the two documentation paths that describe it are aimed squarely at the vendor role.

The Device Tree bindings live under Documentation/devicetree/bindings/, and the driver side is documented through the driver API guide, the driver model document, the device driver infrastructure, the bus types, the power management API and the DMA API. That is the same documentation the mainline kernel has, which is a sign that this tree stays close to upstream in structure.

The samples directory is a good way to see what the tree expects to work. Alongside the familiar entries such as bpf, cgroup, ftrace, fprobe, fanotify, hid, hung_task, kfifo, kobject, kprobes, kmemleak and landlock, there are acrn, binderfs, check-exec, configfs, connector, coresight, damon, auxdisplay and hidraw. Several of those are the kind of sample that only matters on an embedded or virtualised target.

For a BeagleBone user, the practical question is which of these you need and which the board image already provides. The answer is usually that you take the vendor kernel because the board support and the Device Tree for that board live here, and you treat the tree as a build input rather than something to maintain.

Where the reports and the conversations actually happen

The communication section is short and it points away from the repository.

Bug reports go to bugzilla.kernel.org, and the README's own first quick start link tells you to read the reporting issues guide before filing one. Mailing lists live on lore.kernel.org, and the MAINTAINERS file in the tree lists the maintainers and the lists for each subsystem, which is the file to consult when you need to know who owns the code you are about to touch. There is an IRC channel for newcomers at #kernelnewbies on irc.oftc.net, and the email client guidance is a separate document, which is a small sign of how seriously the project takes the mechanics of contribution.

The documentation can be built locally with make htmldocs, or read online at the kernel.org documentation site, and the licensing question is answered by the COPYING file.

The code style configuration is also in the tree, which is unusual enough to mention: there is a .clang-format for C, a .rustfmt.toml and a .clippy.toml for the Rust code, a .pylintrc and a .cocciconfig for the scripting parts, plus .editorconfig, .mailmap and .get_maintainer.ignore. The .mailmap file in particular is what keeps author names stable across a tree with thousands of contributors, and .get_maintainer.ignore is what keeps the MAINTAINERS file from filling up with directories that have no real owner.

For anyone reading this tree as documentation rather than as code, those two files are worth a look, because they explain how a project with that many contributors keeps its metadata straight.

Where this mirror is the wrong place to do the work

Three situations rule it out.

The first is when you want to send a patch. The repository is read-only, and the README's development process documentation, the submit patches guide, the code of conduct and the mailing list infrastructure are all pointing to the upstream project instead. A patch that is developed here and never upstreamed is a permanent maintenance liability, because every kernel release will eventually touch the same code.

The second is when you need a general purpose kernel. If you are not on Beagle hardware, this tree is the generic kernel plus board support you will never compile, and the extra work at every upstream merge falls to you. There is a cost to running a vendor kernel, and that cost is real even when the board support is excellent.

The third is when you are looking for a stable, versioned artefact. The repository publishes no GitHub releases, so there is no tag to pin and the tree is a moving snapshot. The release channel for these boards is the vendor's own image and the kernel.org releases, and the README points at kernel.org for the latest kernel.

What the tree is for is unambiguous though. It is the reference for what the vendor has enabled on these boards, which device tree bindings exist, which drivers are compiled in, and how the board behaves, and for that purpose it is exactly the right place to look.

Editorial conclusion

This tree is the right reference for anyone bringing up a BeagleBoard or BeagleBone board, because the Device Tree bindings and the board support for those machines live here and are not in mainline. It is the wrong place to contribute, since the repository is read-only and the README points upstream for patches, bug reports and mailing lists. Before you use it, check the kernel version in the Makefile against what your board image expects, note that the last push here was on 2026-06-17, and take the vendor patches to the upstream project rather than carrying them in your own tree, since the kernel project requires the Developer Certificate of Origin and explicit attribution for anything a tool produced.

Frequently asked questions

Official sources

1. beagleboard/linux on GitHub
2. Issues
3. Project website
4. README