TizenRT: a small RTOS for constrained IoT boards

A small RTOS aimed at constrained devices

TizenRT is described as a lightweight RTOS-based platform to support low-end IoT devices. The project details live in the wiki, and the documentation page there is the place the README points you to.

The audience is embedded engineers, and the word that sets the scope is low-end. This is firmware for a microcontroller class device, not for a phone, a set-top box or a server. Everything in the build system follows from that: the toolchain runs inside a container, the configuration is a defconfig plus a Make.defs pair per board and configuration set, the build output is a set of binaries that get flashed to a partition.

The repository layout shows the whole shape of the system. There is os/ for the operating system core, apps/ and loadable_apps/ for applications, framework/ for the framework layer, lib/ for libraries, external/ for third-party sources pulled in as submodules, build/ for configurations and output, tools/ for the build scripts, resource/ for resources, and docs/ for the build environment documentation. The .gitmodules file is present, which is how the external dependencies arrive.

The licence is Apache 2.0, with the licence file at the repository root and a badge in the README, which for a vendor RTOS is a reasonable choice for a company that ships in commercial products.

The repository is not archived, and the last push was on 2026-10-19, two days before the present date. That is worth pairing with the release history, though. The tagged releases are 3.0_GBM from 2019-12-11, 2.0_Public_M2 from 2019-01-23 and 1.1_Public_Release from 2017-11-09. So the code is being touched, but the public release tags have not moved in years.

Docker as the whole toolchain, and the Windows CRLF trap

The environment setup section makes a strong claim about the build environment. TizenRT provides the easiest way to build with the use of Docker, and there is no need to install the required libraries and toolchains since the provided Docker container already includes everything required for TizenRT development. The image is on Docker Hub at tizenrt/tizenrt, and the README links a page describing which libraries it contains.

There is an escape hatch for systems that cannot run the container. In that case all libraries and toolchains should be manually installed, and the Manual Setup Build Environment document at docs/HowToSetEnv.md covers it.

The clone step has a wrinkle that costs people an afternoon. If you are building TizenRT on a Windows environment, you need to first configure CRLF as shown below:

git config --global core.autocrlf input

Now clone the source code as shown below:

git clone https://github.com/Samsung/TizenRT.git
cd TizenRT
TIZENRT_BASEDIR="$PWD"

The reason is that the build system is make driven, and makefiles with CRLF line endings break in ways that produce confusing errors far from the cause. The global autocrlf setting is a machine-wide change, which is not ideal, but it is what the project documents.

The TIZENRT_BASEDIR variable is set once and then used throughout the build scripts, and the documentation refers to it as the location of the built binaries under build/output/bin.

The README also notes that to contribute you need to create a fork and clone the forked private repository instead of the main repository, following the GitHub working-with-forks guide.

dbuild.sh menu, and the three-stage selection

TizenRT gives you two ways to build, and the interactive one is the friendlier starting point. The interactive tool is dbuild.sh, where you are prompted to select an option among multiple choices, and according to your selection it consecutively provides the next-step options.

You start in the os directory:

cd os
./dbuild.sh menu

The first prompt lists the supported boards, and the documentation shows the shape of it, with artik053 and cy4390x among the entries and an x. EXIT option. After the board selection you are prompted for the configuration of that board, with the artik053 example offering hello and tc among the choices.

Then comes the build option menu, and this list is the operational vocabulary of the project:

======================================================
  "Select build Option"
======================================================
  "1. Build with Current Configuration"
  "2. Re-configure"
  "3. Modify Current Configuration"
  "4. Clean Build"
  "5. Clean Build and Re-Configure"
  "6. Build SmartFS Image"
  "d. Download"
  "t. Build Test"
  "x. Exit"
======================================================

Two of those deserve comment. Build SmartFS Image points at a filesystem feature of the platform, and Build Test is a test build target. The menu loops until you remove the configuration with the Re-configure or Build Dist-Clean option.

One operational detail is stated as a note: as the build script is running based on Docker, it requires sudo for root permission, and the documentation links the Docker post-install instructions for running without sudo.

Non-interactive builds, menuconfig and the two kinds of clean

Once you know the build system, the README says you may use dbuild.sh with a specific build option instead of the menu. The configuration step takes a board and a configuration set:

cd os
./tools/configure.sh <board>/<configuration_set>

That retrieves the pre-configured defconfig and Make.defs files for the pair, and the configuration is sticky, so you can skip it next time unless you want to change it. The collection of all configuration files lives in the build/configs directory, and ./tools/configure.sh --help lists every pre-defined configuration.

Individual configuration values can then be edited with menuconfig, invoked through dbuild.sh:

./dbuild.sh menuconfig

The note is important and easy to miss. In a Docker environment, the make menuconfig command from other README files should be replaced with this command, and make menuconfig applies only in a manual setup build environment. In other words, there are two different environments with two different ways to open the same configuration editor, and using the wrong one leaves you stuck.

The clean commands come in two flavours, and the difference matters. The clean option removes built files including objects, libraries, .depend and Make.dep, and it is required after modifying configuration with menuconfig. The distclean option includes clean and additionally removes configured files including .config, Make.defs and linked folders and files, and it is required before changing the basic configuration with configure.sh:

./dbuild.sh clean

./dbuild.sh distclean

The separation is a Kconfig convention that TizenRT follows, and getting it wrong produces a build that silently uses stale configuration.

Flashing a board and chaining verbs

Programming a board is the download command:

./dbuild.sh download [OPTION]

The option designates which flash partitions are flashed, and for example ALL means programming all of the binaries, which also depends on each board. You might be required to set up a USB driver, and the README points at the supported board and emulator section for that.

The advanced feature is that dbuild.sh accepts multiple options and executes them sequentially, so a full cycle from scratch to a flashed board is one line:

./dbuild.sh distclean configure artik053 hello build download all

The README spells out what that does. It executes distclean, configures with artik053/hello, builds, and then programs all of the binaries. The example uses artik053 with the hello configuration, which is the smallest configuration set in the menu and the natural starting point for a first bring-up.

The supported hardware section is where the README ends mid-sentence, so the board list and the emulator support details are not visible in the copy available here. What is stated is that TizenRT supports multiple boards as well as QEMU, and the menu output gives a hint of the range, since artik053 and cy4390x are the Samsung and Cypress platforms respectively.

QEMU support matters more than it first appears, because it means you can build and run the firmware without hardware at all, which is how you get a CI job or a developer's first build working before a board is on the desk.

What a maintained repository without new releases means

The repository is not archived, and the last push was on 2026-10-19. The tagged releases, however, are 3.0_GBM from 2019-12-11, 2.0_Public_M2 from 2019-01-23 and 1.1_Public_Release from 2017-11-09.

Those two facts have to be read together rather than separately. Something is being committed, and the commits are recent, but no public release tag has been cut since 2019. For a firmware platform that means there is no published artifact to pin against, no release note describing what changed, and no versioned SDK that a product team can name in a bill of materials.

For an embedded product this is a genuine problem, and it is different from the problem a library version gap creates. A web team can patch a dependency; a firmware team shipping a device that will be in the field for five years needs to know which upstream fixes are in their build, and a repository with no release stream makes that hard to state.

The naming of the tags is also worth reading closely. 2.0_Public_M2 carries a milestone label, and 3.0_GBM carries a platform codename rather than a plain version number. This is the pattern of a project whose public releases are selective, where the 3.0_GBM tag is a specific internal variant rather than a general availability release. Anyone evaluating should work out which of these tags corresponds to the code they actually intend to ship, rather than assuming the highest number is the general one.

The wiki is where the project details are, and the documentation page inside it is the canonical source. The README itself is a build guide, and the project is candid about that by saying please find project details at the wiki.

Editorial conclusion

TizenRT fits an embedded team that has picked a board from the supported list and wants a small RTOS with a reproducible Docker based build, since dbuild.sh with a sequence of verbs covers configure, build, clean, download and test in one place. It is the wrong choice for a new product that needs a maintained vendor with a current SDK and security updates, because the newest tagged release in the repository dates from 2019. Before adopting it, check the supported board and emulator list for your hardware, read the wiki documentation page rather than relying on the README alone, and confirm that the last push on 2026-10-19 is the kind of maintenance you want to depend on rather than a release train you can pin.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. Samsung/TizenRT on GitHub