Automation for Device Tree Handler [Updated GSOC 2026 project]

Programs Google Summer of Code
1

Hey RTEMS Community,

I just wrapped up my semester exams and am excited to be back in the flow. I have updated my GSoC project to #5136.

Introduction

DTS (Device Tree Source) and DTB (Device Tree Blob) are primarily used in ARM and RISC-V based architectures. So what do they represent?

DTS defines the properties of hardware components of that architecture, and DTB is a data structure used to represent those properties in binary.

Overview

In our current issue, the FDT (in RTEMS DTB is referred to as FDT) it is being manually mapped from array after externally converting DTS to FDT.
This causes some major errors such as naming ,formatting alignment which are seen in some of the issues like #5137.

Thus, automation of this procedure is the project.

Process Flow

  • DTS files are converted into FDT binary using the DTC.
  • The FDT is manually mapped in the form of an array; and linked into BSPs
  • BSP startup code provides a pointer to this array via rtems_fdt_set()
  • Then libfdt is used to query the data for drivers.

Representation of Array

  • The parsing of the elements is of 4-byte offset.
  • Each represents fields such as magic number, size of block, structure block offset, string block offset, etc.

Primary Implementations

  1. Integrating the DTS files into RTEMS.
  2. Building the DTS to FDT.
  3. Converting the FDT to an array.

Doubts

  1. What should be the origin of the DTS file vendor or Linux? Are we creating a standard for this?
  2. I did not come across any document for mapping of the array from RTEMS. Should we add it?
  3. I might be just foreseeing or could be wrong, but when adding the DTS file, should there be a review-like system for maintainers to verify it, or would that be done on GitLab itself?
  4. What are the things the automation pipeline should have and tests to be included ?
  5. What are initial tasks I need to do get started for this project.?

Looking forward for guidance form mentors and community members.

2
  1. DTS files handled by RTEMS in this way are typically stripped down minimal device trees that contain only what is necessary for the desired features to function. They are hosted in the RTEMS source tree. There is no need to consider external device trees as those are typically pre-compiled and their address provided in a register by the bootloader on startup.
  2. There is a utility in rtems-tools that can generate the C array from a binary file called rtems-bin2c.
  3. The DTS will be reviewed as part of the standard code review process. GitLab will eventually run RTEMS builds in its pipeline. No action is necessary on your part for these.
  4. A test that uses the new DTS/FDT functionality and verifies expected fields in the converted device tree would be appropriate. Other tests that fail in expected ways might also be appropriate, but RTEMS does not yet have good functionality for verifying tests that intentionally create build errors.
  5. You should familiarize yourself with dtc and rtems-bin2c. You will likely be writing a new kind of file handler for the build system, so familiarity with wscript in the root of the RTEMS tree would also be helpful.
1 Like
3

Thank you @opticron Okay first I will get a good understanding about dtc and rtmes-bin2c . And as task , I can create a DTS->DTB-> array flow for a specific DTS and compare it with the existing array of it.?