Source code (git repository) for bootloaders and firmwares


  1. I cannot find the source codes (e.g., git repositories) that are
    used for building the bootloaders at
    as well as the distros (replace boot with distro in link above;
    this site gave me an error about 2 links per post for new users
    allowed). Could you please provide the correponding links.

  2. There are serveral files for each board under above boot link. For example, for
    roc-rk3328-cc, is the bootloader to use roc-rk3328-cc-spiflash or

  3. Following this guide
    Installing Debian 11 Bullseye and Debian 12 bookworm/sid Headless - Google Slides
    to manually install a Debian GNU/Linux distro from official
    sources, is the ‘bootloader’ in 2. all that’s needed to boot into a
    distro flashed onto a attached USB? In other words, what has gone
    into github dotcom slash libre-computer-project/libretech-firmware/tree/aml-s905x-cc/v2022.04/mbruefi?
    Where is the source code (including build scripts) for building
    one’s own firmware+bootloader for the Libre.Computer boards?


It is all on GitHub.

Thank you for your reply. (Though I don’t understand the terseness. Is my question answered too many times? I searched and nothing came up. Additionally, as you may see, I have done a bit of digging and got stuck.)

  1. and 3. Is this what you’re referring to on github, GitHub - libre-computer-project/libretech-u-boot? Do you mind providing links? I cannot find any repo that involves building .xz’s for distros. Nor can I find which repo the boot CI artifacts are built from (and using which build scripts+github actions, etc.).

I’m trying to build my own custom Debian-based, “preinstalled” distro, hence the above questions.


  1. libretech-builder-simple will use libretech-u-boot repos to build binaries but we highly recommend taking it off or use libretech-flash-tool which uses it. Our build chain tooling may break since it’s undergoing testing and not pass CI. The libretech-builder-simple should not be used for production purposes. It should only be used with testing your own builds.
  2. The distribution builder is a proprietary commercial offering as it involves a lot of customer IP and integrations so it cannot be public. You can use standard distro strapping like debootstrap or mmdebstrap to build your own. The process is generic and non-specific to our boards with the exception of writing the bootloader at the right offset in the image. You can also optionally use our kernel repo at

Thanks for your reply.

  1. I checked out
    GitHub - libre-computer-project/libretech-flash-tool and
    it basically wget’s from and and dd’s to the write offset based on the
    board. I’ll try to see if it works.

  2. If Libre.Computer is using a PROPRIETARY dist builder, then the
    distributions are PROPRIETARY software and not Free/Libre Software,
    as, e.g., one cannot study or modify them. In particular, users
    could be in danger of using backdoored builds (due to the
    proprietary dist builder). Why has this decision been made?

  1. Proprietary dist builder does not make the releases proprietary.
  2. All components included on the image are open source besides linux-firmware non-free.
  3. If you want to study them, bootstrap and do a diff. We don’t make any changes to the standard distros outside of setting a few configs since we’re not distro maintainers.
  4. We maintain separate bootloader and kernel and userspace hardware tooling for our boards. All of these are open source and available on GitHub.

The distributions released by if made by a
proprietary dist builder, are proprietary software. The users
CANNOT study what has gone into those PARTICULAR distributions (the
.xz’s you distribute) to be sure the proprietary dist builder use has not added malicious code during build (and
nor can for that matter); just like RELEASES built
by a proprietary compiler are proprietary software. Reflections on
trusting trust by Ken Thompson
(Reflections on Trusting Trust : Ken Thompson : Free Download, Borrow, and Streaming : Internet Archive) comes
to mind. This is bad practice at best and malicious at worst. Why
is Libre.Computer using a proprietary distro builder?

The distributions released by if made by a proprietary dist builder, are proprietary software.

This is not true.

We’re releasing images, not binaries. You can rip open them and diff against a bootstrap to get a detailed list of the changes. How we make those changes are proprietary, but those changes are not proprietary. You can strap your own Linux, buildroot, or yocto if there’s no implicit trust. All the components we use in the final image are open source outside of the non-open-source things that the distro provides like firmware.

This is bad practice at best and malicious at worst. Whyis Libre.Computer using a proprietary distro builder?

You are entitled to your opinion. We already said why. Bother to read and use some logic instead of making inflammatory remarks.

Thanks again for your quick reply. To clarify, I appreciate the work
Libre.Computer is doing to provide the community with SBCs that work
with Free Software (apart from the non-free software that has been
forced into the ‘default’ kernel Linux upstream, which is a different
discussion). I made no inflamatory remark; I provided a spectrum “at
best and at worst”. That’s why I asked, why put the work in jeopardy
by using a proprietary builder.
I did read and re-read your reasoning, “customer IP”. I don’t
understand. If all software used in the images are Free Software, what
customer IP are you referring to? In any case, if users could use free
software to build bit-identical images to yours, then why don’t use a similar free-software distro builder?

Our builders are a propretiary service offering and offer integrations with proprietary components to generate proprietary images for our commercial customers. We just happen to also use the same infra to build the FOSS distros. Since these proprietary components are within the builder, we cannot release the builder. The FOSS distros just include config changes since it’s our policy not to modify the upstream distros. The package list not from the upstream distro is just our kernel, our userspace hardware utilities, and our bootloader. All of these are open source on GitHub. We make config changes to make the out of box experience slightly better/faster.

Due to the segmented (proper) way we do things on the FOSS side (bootloader/kernel/userspace), there’s not a lot of magic to the builder that warrants a release since it can be done via standard toolchain for bootstrapping images. The config changes can be derived from a diff.

  1. dpkg preseed
  2. grub configuration
  3. disk expansion
  4. swap setup
  5. network setup
  6. sound setup
  7. locale setup
  8. GUI/browser configuration

These are < 100 lines of configuration. Setting up the builder is fairly involved and not designed for end-users anyway since there’s other processes that goes with it. The only difference for the images for each board is the bootloader. The entire disk is the same.

why don’t use a similar free-software distro builder?

Our builder does more than images and is tailored for our products, services, and processes like testing and release. The core of the building is debootstrap.