Skip to content

Development

Jump to bottom Edit New page
Charles Crossan edited this page Jan 2, 2025 · 55 revisions

Buildroot

Thingino is an external tree of the Buildroot tool. So the best possible documentation is available here.

Thingino uses a slightly modified version of Buildroot, allowing it to create better symlinks for a truly relocatable toolchain.

Thingino uses its own Makefile to do most of the pre-build configuration. It then passes the build command to Buildroot.

Buildroot's native make directives are accessible from firmware using the br- prefix, e.g. make br-help will show help output from the Buildroot Makefile, while make help will only show help from the Thingino Makefile.

Building a Package

Prefixed Buildroot make directives to work with a package at different stages:

  • br-[pkgname] - Build and install [pkgname] and all its dependencies
  • br-[pkgname]-source - Only download the source files for [pkgname]
  • br-[pkgname]-extract - Extract [pkgname] sources
  • br-[pkgname]-patch - Apply patches to [pkgname]
  • br-[pkgname]-depends - Build [pkgname]'s dependencies
  • br-[pkgname]-configure - Build [pkgname] up to the configure step
  • br-[pkgname]-build - Build [pkgname] up to the build step
  • br-[pkgname]-dirclean - Remove [pkgname] build directory
  • br-[pkgname]-reconfigure - Restart the build from the configure step
  • br-[pkgname]-rebuild - Restart the build from the build step
  • br-[pkgname]-reinstall - Restart the build from the install step
  • br-[pkgname]-show-info - Generate info about [pkgname], as a JSON blurb
  • br-[pkgname]-show-depends - List packages on which [pkgname] depends
  • br-[pkgname]-show-rdepends - List packages which have [pkgname] as a dependency
  • br-[pkgname]-show-recursive-depends - Recursively list packages on which [pkgname] depends
  • br-[pkgname]-show-recursive-rdepends - Recursively list packages which have [pkgname] as a dependency
  • br-[pkgname]-graph-depends - Generate a graph of [pkgname]'s dependencies
  • br-[pkgname]-graph-rdepends - Generate a graph of [pkgname]'s reverse dependencies
  • br-menuconfig - Run Buildroot menuconfig
  • br-savedefconfig - Save board defconfig
  • br-busybox-menuconfig - Run BusyBox menuconfig
  • br-linux-menuconfig - Run Linux kernel menuconfig
  • br-linux-savedefconfig - Run Linux kernel savedefconfig
  • br-linux-update-defconfig - Save the Linux configuration to the path specified by BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE
  • br-list-defconfigs - List all defconfigs (pre-configured minimal systems)
  • br-source - Download all sources needed for offline-build
  • br-external-deps - List external packages used
  • br-legal-info - Generate info about license compliance
  • br-show-info - Generate info about packages, as a JSON blurb
  • br-pkg-stats - Generate info about packages as JSON and HTML
  • br-printvars - Dump internal variables selected with VARS=...
  • br-make V=0|1 - 0 => quiet build (default), 1 => verbose build

Thingino adds a few shortcut directives of its own:

  • bootstrap - Install prerequisites
  • clean - Remove target directory and .config file for the given board
  • distclean - Remove all building files for the given board
  • rebuild-[pkgname] - Combine dirclean and rebuild
  • pack_full - Download a corresponding bootloader and create a full firmware file
  • pack_update - Create a firmware update file without a bootloader
  • update_ota IP=192.168.1.10 - Upload and install firmware update, leave bootloader and most settings
  • upgrade_ota IP=192.168.1.10 - Upload and install full firmware including bootloader

Toolchains

Available Toolchains for XBurst Development

These toolchains are designed to support various Ingenic SoC targets and leverage different versions of GCC (GNU Compiler Collection) and libc implementations (GNU and musl).

The following precompiled toolchains are available for development:

  • GNU GCC Toolchains for XBurst1:
    • toolchain_xburst1_gnu_gcc12
    • toolchain_xburst1_gnu_gcc13
    • toolchain_xburst1_gnu_gcc14
  • Musl GCC Toolchains for XBurst1:
    • toolchain_xburst1_musl_gcc12
    • toolchain_xburst1_musl_gcc13
    • toolchain_xburst1_musl_gcc14
  • Musl GCC Toolchains for XBurst1 (Kernel 4.4):
    • toolchain_xburst1_musl_4_4_gcc13
    • toolchain_xburst1_musl_4_4_gcc14

Target SoCs

  • XBurst1 Targets:
    • T10/T20/T21/T23/T30/T31 SoCs
  • XBurst2 Targets:
    • A1/T40/T41 SoCs

GCC Versions

The toolchains are based on multiple versions of the GCC compiler:

  • GCC 12
  • GCC 13
  • GCC 14

These versions ensure compatibility with a wide range of software, offering developers the flexibility to choose a toolchain that best suits their project's requirements.

Choosing a Toolchain

When selecting a toolchain for your project, consider the following:

Important

Precompiled toolchains are currently supported only on x86_64 platforms.

  • Target Architecture: Ensure the toolchain supports your SoC (XBurst1 vs. XBurst2).
  • Libc Implementation: Decide between GNU libc and musl libc based on your project's needs. Musl libc is designed for static linking and simplicity, while GNU libc offers extensive features and dynamic linking support.
  • Musl is the default recommended toolchain for Thingino development.
  • GCC Version: Newer versions of GCC may offer better optimizations and more features. However, compatibility with your codebase should be verified.

Getting Started

Up to date Toolchains releases are always available on the releases page. Toolchains are updated weekly.

Containers

Overview

Are you interested in building or developing with Thingino but concerned about cluttering your system with additional software or needing to upgrade your operating system? Container technologies provide a streamlined solution to maintain a clean and efficient workspace. Whether you're building firmware or developing extensively, containers like Docker and LXC offer isolated environments tailored to your needs.

Docker for Firmware Building

Docker provides a lightweight environment ideal for users focusing on firmware compilation without altering their system setup. It offers:

  • A Debian-based container that ensures consistency across different systems.
  • Minimal setup time with immediate readiness for firmware configuration.
  • A simple interface to facilitate the build process.

LXC for Comprehensive Development

For a more in-depth development experience, LXC (Linux Containers) offers a robust environment:

  • Closer-to-metal operations that provide enhanced control over the workspace.
  • Traditional VM-like behavior suitable for detailed testing and debugging.
  • Provides an environment that can handle not only firmware compilation but also detailed testing and debugging.
  • An ideal choice for developers requiring a full Debian system setup.

Both technologies ensure that your development does not interfere with your primary system, enhancing both security and efficiency.

Quick Start Guides

Docker Setup

To start with Docker, clone the Docker environment repository and run the setup script:

git clone https://github.com/themactep/docker-worker.git ~/docker-worker
cd ~/docker-worker
./run.sh thingino

LXC Setup

LXC provides a Debian-like experience and is straightforward for users familiar with Debian systems. Here’s how to set it up:

git clone https://github.com/gtxaspec/thingino-lxc && cd thingino-lxc
sudo bash setup_thingino_lxc.sh

This script creates an LXC container named 'thingino-development', installs all necessary tools, and attaches you directly to the container for immediate development.

Accessing Your LXC Environment

To access your dedicated Thingino LXC environment:

  1. Open your terminal.
  2. Run attach-thingino to enter your development container.

Exiting the Container: Type exit to return to your host system. Your container retains its state, allowing seamless continuation of your work.

LXC Installation Demo

For a visual guide, view our setup demonstration:

output.mp4

Benefits of Containerized Development

  • Isolation: Keeps your main system pristine.
  • Reproducible: Easy to replicate or remove environments without residual impacts.
  • Resource Efficiency: Containers use fewer resources than full virtual machines, maintaining system performance.

Now, you're all set to enjoy hassle-free development with Thingino in a clean, organized environment!

Remote Debugging

Build Thingino using development packages and gdb.

Add two lines to the /path/to/thingino/local.fragment file:

BR2_THINGINO_DEV_PACKAGES=y
BR2_PACKAGE_GDB=y

Recompile the firmware and flash the camera.

Login to the camera Linux and run gdbserver --multi :1234.

On your workstation, execute

~/output/cameraprofile/host/bin/mipsel-linux-gdb \
	-ex 'target extended-remote 192.168.1.10:1234' \
	-ex 'set remote exec-file /bin/prudynt'

To stop gdbserver, run monitor exit in the client, then exit the client with exit or quit.

  • Replace cameraprofile, 192.168.1.10, /bin/prudynt with actual data relevant to your use case.

Development Workflows

When making changes to source file or configuration files for a camera / module / fragment, it's likely that you'll want to test lots of changes relatively quickly.

Changes to Camera files

Camera configuration files will usually start with the following header:

# NAME: <whatever>
# MODULE: <whatever>

The # MODULE line is interpreted to include the contents of a file with the name specified from configs\modules. For example, # MODULE t31l_sc3338_atbm6032 will include the contents of the file at configs/modules/t31l_sc3338_atbm6032.

Modules are a definition of the SoC/CPU, the WiFi chipset and the Imaging sensor, and are often shared amongst multiple different camera models.

For help identifying the image sensor, see this

When changing a camera to use a different module, it's generally recommended to run make cleanbuild.

When modifying a camera configuration, it's generally sufficient to run make fast (for a multi-threaded build) or make all (for a single-threaded)

Changes to environment files

The camera config file being built should contain a U_BOOT_ENV_TXT value which points to a file in the environment directory.

Properties defined within this file are described in Camera Configuration.

Amongst other values, GPIO pins for the specific camera model are defined in the uenv.txt file. For help identifying GPIO pins, see this

When making changes to the committed <camera-name>.uenv.txt file, it's necessary to rebuild the U-Boot package in order for the changes to be included in a new firmware build.

make rebuild-uboot
make clean all

Tip

Include debug=1 when you intend to iterate rapidly on firmware build changes. This removes the requirement to set root credentials on the device after each flash. It's also possible to set wlanssid and wlanpass here so you don't need to manually configure WiFi credentials with each flash.

Flashing new builds

Once you have a shiny new .bin file, you'll want to flash it onto the camera to actually run and test:

  • Directly flash the chip using SNANDer / CH341a
  • Flash the chip over IP
    • U-Boot and Thingino: make upgrade_ota IP=192.168.1.100
    • No U-Boot: make update_ota IP=192.168.1.100

Source Code Repositories

Thingino is a powerful, open-source solution that integrates multiple systems and programs to transform your camera into a versatile, feature-rich device. With a range of source code repositories contributing to its functionality, Thingino provides a collaborative platform for developers eager to contribute to an open-source camera ecosystem.

If you're interested in helping out, dive into the sources below and explore the components that make up Thingino!

Core Repositories

Here are the primary repositories that form the core of Thingino:

Additional Useful Repositories

These repositories contain supplementary resources and tools beneficial to Thingino development:

  • Vendor Precompiled Kernel Module Archive: Contains precompiled kernel modules.

  • Ingenic SDK Headers: Essential headers for Ingenic SDK development.

  • Ingenic SDK Samples for Musl: Sample projects and examples for the Musl-based SDK.

Add a custom footer
Add a custom sidebar
Clone this wiki locally