MetalLB is a Kubernetes-native load balancer for bare-metal clusters. Two cooperating workloads implement the system: a cluster-scoped controller that allocates IP addresses from CRD-defined IPAddressPools and writes Service status updates, and a DaemonSet of speaker pods on each node that announce assigned IPs to the physical network. Announcement is either BGP (via a from-scratch native Go BGP stack, a deprecated FRR sidecar mode, or the newer FRR-K8s API that generates FRRConfiguration CRs) or Layer2 (ARP/NDP responders with memberlist-based fast failover detection and deterministic speaker election). All user configuration flows through CRDs — IPAddressPool, BGPPeer, BGPAdvertisement, L2Advertisement, Community, BFDProfile, and ConfigurationState — validated by admission webhooks, with a configmaptocrs tool migrating legacy ConfigMap configuration to the CRD model. The controller/speaker split, a listener abstraction that delivers config changes to protocol handlers, and a common bgp.Session interface across backends give the architecture a clean, modular shape.
This is a bare-metal (no_std) hardware abstraction layer (HAL) for Espressif ESP32 microcontrollers, supporting RISC-V and Xtensa cores. It provides low-level drivers for GPIO, SPI, I2C, UART, ADC, DAC, PWM, timer, USB, Ethernet, Wi-Fi, BLE, IEEE 802.15.4, and many other peripherals across a dozen+ chip families (ESP32, ESP32-C2/C3/C5/C6/C61, ESP32-H2/H4, ESP32-P4, ESP32-S2/S3/S31). The repository is a monorepo containing multiple independently versioned crates: esp-hal (core HAL), esp-radio (wireless radio stacks), esp-alloc (heap allocator), esp-storage (flash storage), esp-backtrace, esp-println, esp-sync (synchronization primitives), esp-rom-sys (ROM function bindings), esp-rtos (lightweight RTOS with async/embassy integration), esp-lp-hal (low-power core HAL), esp-config (build-time configuration), esp-metadata (chip property code generation), xtask (build/release tooling), and bootloader/OTA support. The architecture is built on extensive use of compile-time chip selection via macros (cfg_select!, for_each_*), versioned low-level driver modules per peripheral, and type-erased patterns for unified APIs across chip variants. Async support is first-class via embassy executor integration. The codebase demonstrates high engineering quality with clear abstractions, comprehensive hardware-in-the-loop testing (hil-test, hil-test-radio), and mature CI/CD workflows.
This repository is the foundational Rust library for bare-metal development on ARM Cortex-M microcontrollers. It provides the essential runtime startup code (cortex-m-rt), low-level peripheral access (cortex-m), and debugging support (cortex-m-semihosting). The codebase implements critical safety mechanisms for embedded systems, such as preventing multiple instances of peripherals via the singleton pattern, ensuring correct stack alignment, and managing exception handling through sophisticated procedural macros. It serves as the bedrock for the Rust embedded ecosystem, enabling safe interaction with hardware registers and interrupt controllers without a standard library or operating system. The architecture is modular, separating the runtime (cortex-m-rt) from the peripheral access layer (cortex-m) and type traits (cortex-m-types). The startup code includes a robust linker script (link.x) that handles memory layout, vector table generation, and RAM initialization in assembly to guarantee correctness before Rust code executes. The repository also includes a comprehensive testsuite that runs on QEMU and physical hardware to validate interrupt handling, critical sections, and stack management across different Cortex-M variants (M0, M3, M4, M7, M33). This is a high-quality, production-grade library maintained by the Rust Embedded community. It demonstrates deep understanding of the ARM architecture, Rust's safety guarantees, and the constraints of embedded development. The code is heavily tested with compile-fail tests to ensure macro-generated code adheres to strict signatures and safety requirements.
TamaGo is a bare-metal Go framework that enables running Go programs directly on hardware without an operating system or C runtime. It provides a modified Go runtime (GOOS=tamago) and a comprehensive set of drivers for ARM, ARM64, AMD64, RISC-V, and LoongArch architectures, covering SoCs from NXP, Raspberry Pi, SiFive, Microchip, Nuvoton, and others. The framework includes low-level initialization, exception handling, MMU, cache control, timers, interrupt controllers (GIC, LAPIC), and peripheral drivers for UART, I2C, SPI, USB device, Ethernet (ENET, gVNIC), SD/MMC, DMA, and cryptographic accelerators (CAAM, DCP). It also supports confidential computing features like AMD SEV-SNP and ARM TrustZone, as well as KVM paravirtualization with VirtIO and pvclock. The architecture is library-based: the `cmd/tamago` tool manages a custom Go distribution, while the runtime hooks (ramStart, printk, nanotime) are linked into Go via `go:linkname` from board and SoC packages. Each board package provides initialization functions that configure pin muxing, clocks, and peripherals. The code is production-grade, used in real projects like GoKey (smartcard), GoTEE (TEE), and ArmoredWitness. The repo is actively maintained, with a large number of supported platforms and a focus on security and minimal attack surface.
This repository contains the source code for Comprehensive Rust, a multi-day Rust course developed by the Android team at Google. It is structured as an mdBook with slides, speaker notes, interactive code examples, and exercises. The course covers Rust fundamentals, Android and Chromium integration, bare-metal development, concurrency, async, unsafe Rust, and idiomatic patterns. The codebase includes custom mdBook preprocessors (mdbook-course for structured course scheduling, mdbook-exerciser for extracting exercise starter files), a developer automation tool (xtask), and a comprehensive CI/CD pipeline that builds the book in multiple languages, runs Rust tests via Bazel and Cargo, and performs browser-based WebDriverIO tests. While the primary output is educational content, the tooling infrastructure is well-engineered and demonstrates reusable patterns for structured documentation and exercise management. The repository is actively maintained with frequent commits, issue triage, and translation support for over 17 languages.
This repository is a bare-metal custom bootloader and graphical recovery environment for the Nintendo Switch (Tegra T210/T210B01). It boots Horizon OS, Linux4Tegra, and third-party payloads by decrypting and patching the encrypted HOS boot chain (package1, package2, package3), deriving console keys from TSEC/EKS data, and applying version-specific binary patches. It also provides emuMMC creation and migration, eMMC and SD card tools, USB gadget modes (mass storage and HID), AutoRCM, fuel gauge/thermal diagnostics, and a full hardware bring-up path including display, touch, Joy-Con input, DRAM training, and power management. The code clearly reflects the bootloader's actual production role: a user-triggered payload running from RCM on real Switch hardware, with a text TUI in the main bootloader and a separate LVGL-based graphical frontend called Nyx. Architecturally, the repo is organized into a hardware abstraction layer called BDK (Board Development Kit), the bootloader core, the Nyx GUI application, and dynamically loadable ELF modules for DRAM training and SDRAM LP0 sleep state. The BDK provides drivers for SoC peripherals, power management ICs, storage controllers, the security engine, USB, input, and display, all written as bare-metal C with direct MMIO register access and no OS dependencies. The bootloader uses an INI-based configuration system, a small graphics console, and a module loader that can load ELF shared objects from SD or eMMC. Nyx is a separate application built on a heavily customized fork of LittlevGL v5, with custom themes, fonts, resource packing, and hardware tools. The code demonstrates strong embedded systems skill: meticulous hardware register definitions, retry and error-counting logic in storage drivers, cryptographic key derivation routines updated through many firmware generations, and carefully structured patch tables for firmware signatures. The main weaknesses are the aging bundled libraries (FatFs and LVGL forks are old and diverged from upstream), duplicated graphics implementations between bootloader and sample module, and a large amount of hardcoded hardware-specific constants and addresses. This is not general-purpose software; it is tightly coupled to Tegra X1 hardware and the Nintendo Switch modding ecosystem, but the BDK driver organization, ELF loader, INI parser, list macros, and compression utilities are genuinely reusable in other low-level projects.
Trice is an embedded logging and tracing toolchain consisting of a lightweight C instrumentation library for microcontrollers and a Go-based host CLI tool. The C library provides variadic macros that emit compact binary records (ID + values) instead of format strings, drastically reducing flash and bandwidth usage. The Go tool manages Trice IDs (insert, clean, bind), decodes incoming binary streams from targets over UART, RTT, TCP/UDP, or file, and displays formatted logs with timestamps, colors, and filtering. It supports multiple buffer strategies (stack, static, double, ring), framing protocols (COBS, TCOBS), optional XTEA encryption, and local logging on the target itself. The architecture is a classic host-target split: the target runs the C library, the host runs the Go CLI. The codebase is well-tested with a large matrix of CGO test configurations and CI pipelines for multiple STM32 example projects. It is actively maintained with frequent releases and a responsive issue tracker.
This repository is a comprehensive bare-metal microcontroller programming guide, providing step-by-step examples from minimal firmware to a full embedded web server with a device dashboard. The code targets ARM Cortex-M and RISC-V microcontrollers (STM32, TI TM4C, RP2040, ESP32-C3, nRF52840, etc.) and uses only GCC, a datasheet, and the Mongoose networking library. The architecture is bare-metal, single-threaded with an event loop in the webserver step; it demonstrates direct register manipulation, interrupt handling, UART, SysTick, clock configuration, printf retargeting via newlib syscalls, CMSIS integration, and Ethernet with built-in TCP/IP (MIP). The repository also includes reusable project templates for blinky, CLI, and LittleFS filesystem. Despite being educational, the code is production-quality and follows embedded best practices such as non-blocking timers, hardware abstraction layers (hal.h), and modular startup code.
This repository is a clean-room, portable reimplementation of Apple Macintosh System 7.1, targeting bare-metal x86, ARM (Raspberry Pi), and PowerPC hardware. It is a monolithic kernel that emulates the classic Mac OS Toolbox API, including subsystems such as the Event Manager, Window Manager, Menu Manager, Dialog Manager, QuickDraw, Font Manager, File Manager (HFS), and a Finder-like desktop environment. The codebase is written in C and assembly, with a hardware abstraction layer (HAL) for platform-specific drivers (USB, storage, timers, framebuffer). It boots via GRUB2 (x86) or custom bootloaders (ARM, PPC) and includes built-in applications like SimpleText and MacPaint. The project is explicitly a reverse-engineering effort based on public documentation and ROM analysis, with many subsystems partially implemented or stubbed. It is not production-ready but demonstrates deep knowledge of Mac OS internals and provides a foundation for running classic Mac software on modern hardware.
This repository contains custom open-source firmware for Quansheng UV-K1/K5 V3 handheld ham radios, built around the PY32F071 MCU. It is a fork in the lineage DualTachyon → Egzumer → F4HWN → this project, adding features gated by compile-time flags (ENABLE_FEAT_F4HWN_*, ENABLE_NOAA, ENABLE_DTMF_CALLING, etc.). The firmware is bare-metal C (no RTOS in the application code despite CMSIS-RTOS2 RTX5 being vendored), with a main-loop architecture and an overlay app system using an app_api_t struct of function pointers. The build system uses CMake presets, per-app build.sh scripts, and a Docker wrapper (compile-firmware.sh) producing .elf/.bin/.hex artifacts. A pack_app.py script packs raw binaries into .app blobs. The repository vendors a large CMSIS_5 tree (~20k+ files), most of which is unused DSP/RTOS/validation code, bloating the repo. The README explicitly warns that flashing can brick radios, and overlay apps run with full privileges (no MPU). Notable engineering patterns include the overlay app API (function-pointer-based, placed in .text.entry section), an LL I2C driver mirroring STM32 LL conventions, and extensive conditional compilation. However, the codebase shows drift: deprecated compile-with-docker.sh retained as a forwarding shim, repetitive per-app build scripts, vendored CMSIS that may be outdated, and a license placeholder in the CMSIS bundle. Maintenance is active with recent commits, but the fork lineage and vendored dependencies create ongoing merge/upstream complexity. This is purely an embedded application repository - no datasets, ML models, or research artifacts are present.
This repository is a large collection of bare-metal firmware projects for STM32 microcontrollers (F0, F1, F3, G0, G4 families), authored by Edward V. Emelianov. It contains dozens of independent example and application projects covering USB CDC virtual serial ports, CAN bus gateways, sensor drivers (BMP280, MLX90640, DHT22, DS18B20, etc.), stepper motor control, servo control, LED displays, and more. The code is written in C with direct register access (no HAL) and uses a custom USB stack with ring-buffer-based I/O. Each project is self-contained with its own main.c, hardware initialization, and command parser, typically communicating over USB or UART with a simple text-based protocol. The architecture is monolithic per project: a main loop processes periodic tasks (ADC sampling, sensor reads, CAN message handling) and responds to commands received via USB or UART. Key entry points are the main.c files in each project directory. Data flows involve sensor acquisition (ADC, I2C, SPI), optional processing (median filtering, dew point calculation), and output via USB CDC, CAN, or UART. External dependencies are minimal: only an ARM GCC toolchain and the STM32 CMSIS-like headers provided in the inc/ folder. The repository also includes KiCad PCB designs and gerber files for many projects, indicating a full hardware+software development cycle. While the code is functional and covers a wide range of embedded use cases, it suffers from significant code duplication (ringbuffer.c, usb.c, strfunc.c are copy-pasted across many projects) and lacks a centralized library or build system. Deprecated folders and multiple versions of similar projects (e.g., chronometer_v2, chronometer_v3) add clutter. The repository is best viewed as a personal collection of working examples and prototypes rather than a polished framework. However, several components (ring buffer, string utilities, USB stack) are well-implemented and could be extracted for reuse in other STM32 projects.
This repository is a custom operating system kernel project (UtopiaKernel) targeting x86-64 with the Limine boot protocol. The kernel entry point is written in Rust (using edition 2024, which is unstable) and is compiled as a bare-metal binary. The boot process uses the Limine bootloader, whose precompiled binaries for multiple architectures (x86_64, aarch64, riscv64, loongarch64, IA-32) are included in the repository. The only substantial source code beyond the kernel entry is a C utility (`limine.c`) for installing the Limine bootloader onto disk images and the Limine protocol header. The project demonstrates a modular adapter pattern for boot protocol abstraction, but the codebase is dominated by opaque binary blobs, limiting inspectability and reusability. It appears to be in active development but carries technical drift risk from using an unstable Rust edition and vendored third-party binaries.