Buildroot BR2_EXTERNAL for lima development
Switch branches/tags
Nothing to show
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Type Name Latest commit message Commit time
Failed to load latest commit information.


This is a BR2_EXTERNAL tree for Buildroot which contains modifications to the mesa3d package so that it supports building the mesa port of lima (OpenGL driver for ARM Mali400/450). It is intended to be used for people interested in developing or trying lima.

See lima/mesa, lima/linux and the lima wiki for more information about the driver.

The normal Buildroot development workflow can be used with this tree, so the Buildroot manual can be used.

Quick start

Here is a quick start on how to use this to cross-compile a full image containing lima. Note that this is all detailed more extensively in the Buildroot manual, these are just some copy and paste commands. These steps do not require or use any feature that is not documented in the Buildroot manual.

Clone Buildroot:

git clone git://

Clone this repository:

git clone

You will also need mesa-lima and linux-lima, so clone those too:

git clone
git clone

Now, we need to create a workspace directory to use while we use Buildroot.

First, select one of the existing defconfigs in Buildroot, which can be seen here. Some examples of defconfigs for devices with a Mali400 are, cubieboard2_defconfig, pine64_defconfig. Then create the workspace directory with:

make -C buildroot O=$PWD/output BR2_EXTERNAL=$PWD/buildroot-external-lima <defconfig>
# for example:
make -C buildroot O=$PWD/output BR2_EXTERNAL=$PWD/buildroot-external-lima cubieboard2_defconfig

This line also configures this repository as a BR2_EXTERNAL. (More details about BR2_EXTERNAL in the manual). The output directory will be called output (note: you can have multiple simultaneous output, just changing O= to point to another name).

Since we want to use our externally cloned repositories for mesa-lima and linux-lima, we need to tell Buildroot about that using a file. Copy the provided template to the output directory.

cp buildroot-external-lima/ output/

Edit output/ and adjust the MESA3D_OVERRIDE_SRCDIR and LINUX_OVERRIDE_SRCDIR variables to point to the directories where you cloned the mesa-lima and linux-lima repositories respectively.

vim output/

Finally, the default Buildroot defconfig doesn't have mesa3d or lima enabled, so enable it by using the provided config fragment:

cd output
../buildroot/support/kconfig/ .config ../buildroot-external-lima/configs/lima-config.frag

Now the build can be started with make inside the output directory:


The first build may take several minutes. After the build is done, flash images/sdcard.img to a SD card.

sudo dd if=images/sdcard.img of=/dev/YOUR_DEV

Insert the SD card into the board, connect a UART adapter or monitor, and log in to the board.

Welcome to Cubieboard2!
Cubieboard2 login: root
Password: (root)
# lsmod
Module                  Size  Used by    Not tainted
lima                   45056  0
gpu_sched              20480  1 lima
ttm                    65536  1 lima
sun4i_backend          20480  0
sun4i_drm_hdmi         20480  0
sun4i_drm              16384  0
sun4i_frontend         16384  2 sun4i_backend,sun4i_drm
sun4i_tcon             28672  1 sun4i_drm
# dmesg | grep -i sun4i-drm
[    2.870341] sun4i-drm display-engine: bound 1e60000.display-backend (ops sun4i_backend_ops [sun4i_backend])
[    2.890566] sun4i-drm display-engine: bound 1e40000.display-backend (ops sun4i_backend_ops [sun4i_backend])
[    2.900948] sun4i-drm display-engine: No panel or bridge found... RGB output disabled
[    2.908843] sun4i-drm display-engine: bound 1c0c000.lcd-controller (ops sun4i_tcon_platform_driver_exit [sun4i_tcon])
[    2.920111] sun4i-drm display-engine: No panel or bridge found... RGB output disabled
[    2.928031] sun4i-drm display-engine: bound 1c0d000.lcd-controller (ops sun4i_tcon_platform_driver_exit [sun4i_tcon])
[    3.038806] sun4i-drm display-engine: bound 1c16000.hdmi (ops sun4i_hdmi_driver_exit [sun4i_drm_hdmi])
[    3.064483] fb: switching to sun4i-drm-fb from simple
[    3.226186] sun4i-drm display-engine: fb0:  frame buffer device
[    3.233673] [drm] Initialized sun4i-drm 1.0.0 20150629 for display-engine on minor 0
# dmesg | grep -i lima
[    2.930238] lima 1c40000.gpu: bus rate = 300000000
[    2.943558] lima 1c40000.gpu: mod rate = 384000000
[    2.970024] lima 1c40000.gpu: gp - mali400 version major 1 minor 1
[    2.976392] lima 1c40000.gpu: pp0 - mali400 version major 1 minor 1
[    2.982786] lima 1c40000.gpu: pp1 - mali400 version major 1 minor 1
[    2.989216] lima 1c40000.gpu: l2 cache 64K, 4-way, 64byte cache line, 64bit external bus
[    3.035332] [drm] Initialized lima 1.0.0 20170325 for 1c40000.gpu on minor 1
# ls /dev/dri
by-path     card0       card1       renderD128
# ls /usr/lib/dri/

Try offscreen rendering with egl-color-png, which will output screenshot.png:

# cd /usr/local/mesa-test-programs/
# ./egl-color-png
# ls screenshot.png

If you have a display plugged in, you can also try egl-color-kms to render to the display:

# cd /usr/local/mesa-test-programs/
# ./egl-color-kms

kmscube is a nice well-known upstream demo (for a smoother animation without slowdowns, redirect all debug output to /dev/null):

# kmscube >/dev/null 2>&1
# kmscube -M rgba >/dev/null 2>&1

See for a more up-to-date list of working features.

Development workflow

During lima development, in order to quickly rebuild mesa3d or linux after performing code changes, we can leverage the OVERRIDE_SRCDIR feature from Buildroot.

The code can be changed directly in the directories where we clones the repositories earlier. After changing the code, rebuild the respective package with:

make mesa3d-rebuild
make linux-rebuild

This will cause Buildroot to re-sync the sources from your cloned repository, including non-committed changes, and rebuild. The newly built libraries or modules can be copyed with scp to the board from the output/target/ directory (scp target/usr/lib/dri/* root@<board ip>:/usr/lib/dri/) to avoid having to re-flash every time. This workflow can be used for any Buildroot package.

A further workflow enhancement is to use a NFS root filesystem instead of mmc, to make it even simpler to copy modifications to the target. To do this, setup nfs-server, extract output/images/rootfs.tar as root to a NFS-exported directory. Then, change the bootargs in the bootcmd file to use the nfsroot as in:

setenv bootargs $bootargs ip=dhcp root=/dev/nfs rw nfsroot=<SERVER.IP.HERE>:</EXPORTED/DIR/HERE>,nolock,tcp,nfsvers=4

After this, files can be made accessible to the embedded board by just copying them to the NFS-exported root filesystem. The Buildroot uboot package is responsible for making the boot script from boot-<board>.cmd. so when that file is modified, it is necessary to make uboot-rebuild so that the boot script in the target is updated.

When a new sdcard.img is necessary, run make or make all.


For a full reference on how to use Buildroot, check the Buildroot manual, or check the training materials from free-electrons.