[Buildroot] Tesla is using Buildroot

Olof Johansson olof at lixom.net
Sat May 12 18:16:57 UTC 2018

On Fri, May 11, 2018 at 6:42 PM, Carlos Santos <casantos at datacom.ind.br> wrote:
>> From: "ratbert90" <aduskett at gmail.com>
>> To: anisse at astier.eu, "Thomas Petazzoni" <thomas.petazzoni at bootlin.com>
>> Cc: "Olof Johansson" <olof at lixom.net>, buildroot at uclibc.org
>> Sent: Friday, May 11, 2018 10:22:49 PM
>> Subject: Re: [Buildroot] Tesla is using Buildroot
>> This is pretty neat! The main website should really have a prominent list of
>> companies that use Buildroot.
>> Google/Tesla/GoPro etc etc. It would be good advertisement!
>> Adam
>> From: buildroot <buildroot-bounces at busybox.net> on behalf of anisse at astier.eu
>> <anisse at astier.eu>
>> Sent: Friday, May 11, 2018 5:55:08 PM
>> To: Thomas Petazzoni
>> Cc: Olof Johansson; buildroot at uclibc.org
>> Subject: Re: [Buildroot] Tesla is using Buildroot
>> Hi,
>> On Fri, May 11, 2018 at 05:23:14PM +0200, Thomas Petazzoni wrote:
>> > Hello,
>> > I met a few engineers from Tesla at the Embedded Linux Conference in
>> > March, who told me they are using Buildroot. Now that their tree is
>> > publicly available online, I can share this information.
>> > Their Buildroot tree is at:
>>> [ https://github.com/teslamotors/buildroot |
>> > https://github.com/teslamotors/buildroot ]
>> > Unfortunately, it looks a bit ugly in terms of commit history: just
>> > a few huge comments that mix tons of changes together. I was told the
>> > autopilot configurations are there for now, but infotainment
>> > configurations should be added in the near future.
>> > It's of course very nice to see Buildroot being used on board of those
>> > vehicles!
>> > Best regards,
>> > Thomas
>> > --
>> > Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
>> > Embedded Linux and Kernel engineering
>> > [ https://bootlin.com/ | https://bootlin.com ]
>> I've had a quick look at what's inside. Here is what I found:
>> - it seems based on buildroot 2016.05, with backports from more recent
>> versions; but at its core it's still a 2016.05
>> - there are a few packages tesla-{findutils, grep, bash, gzip, which, rsync}
>> that are here with old versions to work around GPLv3
> ... which highlights the need for some mechanism to blacklist licenses
> and warn the user in the configuration menu that a package cannot be
> selected because of license restrictions.

I think Kconfig could solve this quite nicely. Make a selection menu
such that you can choose what licenses you're willing to accept, and
then make the respective packages depend on the license config
(depends on LICENSE_GPLV3 etc)

>> - there's a tesla-verity package which seems to be a custom init that
>> checks the validity of the verity metadata and interacts with
>> firmware to check soc lock status before calling dmsetup.
>> - there are a few packages that look like backports: python-dateutil,
>> nanomsg, python-pytz, python-jsonschema
>> - tesla-binutils is a "real" host binutils (non-cross)
>> - there's tesla-libsystemd stub that builds a libsystemd with stubbed
>> functions
> Makes me wonder why they don't use a BR2_EXTERNAL.

BR2_EXTERNAL is used but by splitting the contents between the
buildroot repo and external, and keeping only things you don't want to
share in the external one (proprietary apps, experimental work, random
internal stuff that won't ship to the outside world and work on
unreleased stuff) works well. The way the (separate but corresponding)
configuration that's published is generated, the reference to
BR2_EXTERNAL doesn't show up.

>> - it has its own parallel building infrastructure, using the loglinear
>> tool, first introduced in google fiber's buildroot implementation
>> [ https://gfiber.googlesource.com/buildroot/ |
>> https://gfiber.googlesource.com/buildroot/ ]
>> - many packages are patched to modify behaviour, customize build
>> options: business as usual
>> - probably many things I've missed

One thing that I'm not sure has been used all that much elsewhere is
that there's a recursive invocation to generate the initramfs, and
then build that into the kernel. Could maybe have been done as two
separate toplevel builds with postprocessing, but this worked quite


More information about the buildroot mailing list