Skip to main content
It is an English word meaning “precious stone”. The product family is named Gemstone, and each product is given the name of a precious stone.
It is the name of the first development board (product code: T3 Gemstone O1), referring to a sharp, glass-like stone formed from cooled volcanic lava. It was used in prehistoric times for making cutting and piercing tools.
All software and hardware projects are developed by volunteer teams and the community within the T3 Foundation.
Software Development Kit. It refers to the tool that compiles and creates all core software and images for Gemstone development boards.
Operating systems like Debian or Ubuntu use Linux as their kernel/core but contain different software, versions, packages, or package installation methods. Each operating system like Debian, Ubuntu, Fedora, Pardus is called a Distro/Distribution.
It is the website from which software is downloaded when you run commands like sudo apt install in Linux.
In operating systems like Linux, a Device Tree is a “map” that describes the hardware components connected to the processor (for example, sensors, GPIO, I2C, SPI, LEDs, UART, etc.). In other words, it answers the question: “What hardware exists on this device, which pins are they connected to, and how do they operate?” These descriptions are typically stored in files with extensions like .dts (device tree source) or .dtb (compiled binary form). When the kernel starts, it uses this file to understand how to access each hardware component and which driver to initialize, allowing the system to boot properly.
On embedded development boards (for example: Gemstone, Raspberry Pi, BeagleBone etc.), the operating system cannot automatically detect the hardware. That’s why a “Device Tree” (hardware map) file exists. This file tells the OS things like: “Use GPIO pin 2 as UART, GPIO 17 is connected to an LED, I2C-1 is located here,” essentially describing what each pin does.Sometimes, you may want to modify or extend these definitions. However, rewriting the entire hardware map from scratch would be inefficient. That’s where a Device Tree Overlay (DTO) comes in. “Overlay” means “to layer on top of” or “temporarily modify.” For instance, suppose GPIO pin 2 is configured as UART, but you want to use that pin as an LED output instead. You can load a new Device Tree Overlay that says, “GPIO 2 is now an LED output.” This overlay changes only that specific pin — all other settings remain intact.In short, DTOs (Device Tree Overlays) allow you to modify pin functions or hardware behavior, or to add new devices like sensors, motors, or displays — all while preserving the main system configuration files.
To become a Volunteer Developer, you need to read all the necessary documentation, examine the projects on GitHub, and choose a topic from the Roadmap section to work on. Visit the community forum for your questions.
Various development standards are specified below for those who want to contribute to open-source projects by joining the Gemstone community.
  • The first and fundamental principle in all work should be based on simplicity and understandability. Overly complex code patterns should be avoided.
  • There should be no commented-out or unused code or functions in the code of software projects.
  • To ensure integrity in the documents, the Light Theme should be used in all window screenshots provided. If taking a screenshot of the website, the Microsoft Edge browser should be used, and the resolution should not exceed 1280x720.
  • Grammar and spelling rules should be paid attention to when writing anywhere, including the forum, GitHub, Documents, etc.
  • When adding photos or images to projects or documentation, the resolution of the visuals should not be too high, and the file size of the added image should not exceed 1 MB. Examples can be taken by looking at other photos in the ecosystem. Click here for tips on writing documentation.
  • In all works (Development, Documentation, etc.), when writing descriptions, the "Why", "What", "How" principle should be followed; meaning “Why was this work done, what was done, how was it done?”. For example, when examining the work at this link, it explains “that challenge exists, what that challenge was solved, and what was done to solve it”. Similarly, when preparing a README file for a new project, why the project was created (define the problem) should come first, followed by what was done (what was done for the solution), and finally, an explanation of what the work does (or how to use it if it is an application).