AmberELEC: Anbernic handheld firmware and its build targets

AmberELEC is a device firmware image, not an emulator

AmberELEC is a full operating system image that people write to a microSD card and boot on a handheld console. It is the project description that says it plainly: open source firmware for the Anbernic RG351P/M/V/MP, RG552 and other compatible devices, with a website carrying the installation instructions and getting started guides.

The lineage is unusually tangled and worth spelling out, because it explains what the project is. AmberELEC was formerly known as 351ELEC, and it is a fork of EmuELEC, which is in turn based on CoreELEC, Lakka and Batocera. In practice this means the running system is a Linux distribution with an EmulationStation front end, the RetroArch and libretro core set, and the media player and applets inherited from the CoreELEC lineage.

The audience is narrow and clear. This is for someone holding an Anbernic handheld with a bare Android install, or an unsupported system, who wants a dedicated console image instead. It is not a desktop application and not a generic Linux build, and the hardware table in the project documentation is the entry point for deciding whether your unit is covered at all.

The primary language of the repository is a Makefile, which tells you how the project is organised. Nearly everything is a build script rather than application code.

The support table decides which image you flash

The device list is organised by SoC, manufacturer and model, and it is not a long one. RK3399 covers the Anbernic RG552. RK3326 covers the Anbernic RG351P, RG351M, RG351V and RG351MP, plus the PowKiddy RGB20S and Magicx XU10, the Game Station R35S and R36S, and the SZDiiER D007 Plus.

The footnotes carry the operational detail and they change what you download. The RG351M uses the RG351P image. The RG351V and RG351MP units with a v2 display require the pre-release image, and the pre-release image is described as mandatory for them. The RGB20S, the XU10, the R35S, the R36S and the D007 Plus use the RG351MP pre-release image.

So the release image is not the whole story. Pre-release builds are published from a separate AmberELEC-prerelease repository, and a user with a v2 display or one of the footnote three devices ends up on a build that has not had a stable release. The Makefile also references a RK3566 toolchain target, which indicates work on a SoC that has no entry in the support table yet.

Installation itself is documented off the repository, on the website installation page. The project documentation does not repeat the flashing steps, and there are no install commands to copy, so the SD card procedure has to be read there.

Each device has its own make target

The Makefile is the interface to the build system, and it exposes one target per device. The pattern is consistent, with the device name and the architecture passed to a build script:

git clone https://github.com/AmberELEC/AmberELEC.git AmberELEC
cd AmberELEC
make clean
make RG351P

Targets exist for RG351P, RG351V, RG351MP and RG552. Alongside them are the generic targets, `system`, `release`, `image` and `noobs`, which all call `./scripts/image` with a different argument, and a `package` target that calls `./scripts/build` with a package name so that a single component can be rebuilt without a full image.

There are also toolchain targets for RK3326, RK3399 and RK3566, and a `lib32` target that builds 32-bit ARM libraries for the RG351P, RG351V, RG351MP and RG552. A `update` target exists for the RG552 and calls `./scripts/update_packages`.

The build output lands in a `release` directory inside the checkout. The project documentation describes the make process as producing an image there, and the next step is writing that image to a microSD card using the website installation instructions.

A source build wants 16GB of RAM and 150GB of disk

The requirements are stated plainly, and they are the reason most people will not build from source. The recommendation is a minimum of four cores, 16GB of RAM and an SSD with 150GB of free space, on Ubuntu 20.04, with the caveat that the mileage may vary on other distributions.

Go 1.17 or higher is required, and on Ubuntu 20.04 that means adding an extra apt repository first:

sudo add-apt-repository ppa:longsleep/golang-backports

The dependency list is long, covering the build toolchain, SDL2 and its mixer, freeimage, freetype, curl, rapidjson, ALSA and Mesa development headers, Boost, cmake, VLC and libvlc, texinfo, premake4, golang, device-tree-compiler, u-boot-tools, rsync, p7zip, unrar, aarch64 cross tools, meson and rdfind, among others. None of that is unusual for an embedded distribution build, but it means a failed build is often a missing development package rather than a project bug.

The top level of the repository shows how the pieces are separated. `projects/` holds the individual components, `packages/` the package definitions, `distributions/` the device images, `config/` the configuration, `tools/` the toolchain, and `scripts/` the build scripts that the Makefile calls. The `licenses/` directory and a `LICENSE.md` file at the root are where the licensing story lives, and the licence is a custom one that GitHub cannot classify.

Docker removes the dependency list but not the build cost

The Dockerfile approach exists because installing that dependency list by hand is the painful part. The container is based on ubuntu:20.04 and installs the same packages inside the image, including the GCC 10 toolchain, the cross compilers, and the longsleep golang-backports repository.

FROM ubuntu:20.04

ARG DEBIAN_FRONTEND=noninteractive
SHELL ["/usr/bin/bash", "-c"]

RUN apt update \
  && apt install -y \
    gcc-10 g++-10 make git unzip wget bison flex linux-libc-dev linux-libc-dev-arm64-cross \
    xz-utils libsdl2-dev libsdl2-mixer-dev libfreeimage-dev libfreetype6-dev libcurl4-openssl-dev \
    rapidjson-dev libasound2-dev libgl1-mesa-dev build-essential libboost-all-dev cmake fonts-droid-fallback \
    libvlc-dev libvlccore-dev vlc-bin texinfo premake4 golang libssl-dev curl patchelf \
    xmlstarlet patchutils gawk gperf xfonts-utils default-jre python xsltproc libjson-perl \
    lzop libncurses5-dev device-tree-compiler u-boot-tools rsync p7zip unrar libparse-yapp-perl \
    zip binutils-aarch64-linux-gnu dos2unix p7zip-full libvpx-dev bsdmainutils bc meson rdfind software-properties-common \
  && update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-10 100 --slave /usr/bin/g++ g++ /usr/bin/g++-10 \
  && add-apt-repository ppa:longsleep/golang-backports \
  && apt update \
  && apt upgrade -y \
  && apt autoremove --purge -y \
  && apt clean -y \
  && rm -rf /var/lib/apt/lists/*

The Makefile wires Docker in by prefixing, so `make RG351V` becomes `make docker-RG351V` and `make clean` becomes `make docker-clean`:

git clone https://github.com/AmberELEC/AmberELEC.git AmberELEC
cd AmberELEC
make docker-clean
make docker-RG351P

Three extra targets handle the image itself. `make docker-image-build` rebuilds the container locally and is only needed when the Dockerfile changes, `make docker-image-pull` fetches the published image and overwrites any local changes to the Dockerfile, and `make docker-shell` opens a shell inside the container for running scripts that the Makefile does not wrap. Make itself still has to be installed on the host, and the documentation is explicit that the CPU, RAM, disk and build time requirements are unchanged. A container removes the setup, not the build.

Recent commits sit alongside a 2023 release history

The two maintenance signals point in different directions, and it is worth separating them. The repository is not archived and the last push was on 2026-10-15, so work is landing in the tree. The release list, however, shows the most recent tags as 20230203 Panda Conspiracy on 2023-02-03, 20230131 Panda Conspiracy on 2023-01-31 and 20220627 Sanshiro Tower on 2022-06-26.

Read plainly, the source tree is being worked on while the tagged stable releases on the main repository are old, and the pre-release repository is the place where current builds are published for the devices that need them. Anyone flashing a footnote-two or footnote-three device is by definition running a pre-release build, and that is the project's own arrangement rather than something a reader has to discover.

The licensing deserves its own note. The repository carries a `LICENSE.md` and a `licenses/` directory, and the licence is a custom one that GitHub cannot classify. Custom licences mean you have to read the file rather than assume a standard permissive grant, and the per-package `licenses/` directory suggests that third-party components shipped inside the images carry their own terms, which matters for anyone redistributing an AmberELEC image as part of a product.

Batocera and EmuELEC differ on how much you own

The real alternative is not another Anbernic firmware, it is the family of projects AmberELEC is descended from, and the difference is about ownership rather than features.

EmuELEC is the direct upstream, and AmberELEC's lineage also runs through CoreELEC, Lakka and Batocera.

The trade-off is the one this project keeps. AmberELEC tunes its defaults for a specific SoC and device, and it supports a fixed device list that includes the RG552 and the RK3326 handhelds. What it does not offer is an escape hatch, since the device list is closed and the build targets exist only for those devices.

So the practical question is not which firmware has more emulators. It is whether your exact unit is in the table, and whether you want a maintained image written to an SD card or a source build that takes a 150GB disk and most of an afternoon.

Editorial conclusion

AmberELEC suits an owner of one of the listed Anbernic, PowKiddy, Game Station or SZDiiER devices who wants EmulationStation and RetroArch on a device the vendor left bare. It does not suit a developer with a 16GB workstation and an afternoon, and it is the wrong choice for a device outside the support table, where a stock Android build is the only supported path. Check first which image your unit needs, since the RG351M, the v2 display variants of the RG351V and RG351MP, the RGB20S, the XU10, the R35S, the R36S and the D007 Plus all have documented exceptions to the normal release image.

Frequently asked questions

Official sources

1. AmberELEC/AmberELEC on GitHub
2. Issues
3. Project website
4. README
5. Releases