Development Environment Setup

Development Environment Setup

This guide covers setting up the development environment for rapid iteration on applications, kernel modules, and boot-level components.

Overview

The meta-dynamicdevices project supports two distinct build configurations:

1. Production Builds (kas/lmp-dynamicdevices.yml) - Full Foundries.io builds with secure boot signing
2. Development Builds (kas/lmp-dynamicdevices-dev.yml) - Local development without signing requirements

Development Configuration

Key Features

The development configuration (kas/lmp-dynamicdevices-dev.yml) provides:

• ✅ No factory keys required - Signing explicitly disabled
• ✅ Fast devtool workflows - Perfect for application development
• ✅ Clean environment - No dummy keys or signing infrastructure
• ✅ Same layers - Identical to production except signing disabled

Critical Settings

# Explicitly disable all signing for development
UBOOT_SIGN_ENABLE = "0"
TF_A_SIGN_ENABLE = "0" 
OPTEE_TA_SIGN_ENABLE = "0"
MODSIGN = "0"

# Point signing variables to existing file (signing disabled anyway)
SIGNING_UBOOT_SIGN_KEY = "${TOPDIR}/bitbake.lock"
SIGNING_MODSIGN_PRIVKEY = "${TOPDIR}/bitbake.lock"
# ... (all signing variables use bitbake.lock)

# Development optimizations
INHERIT:remove = "sign_rpm"
SSTATE_MIRRORS = ""
BB_HASHSERVE = ""

Development Workflows

Application Development (devtool)

Use the kas-dev-recipe.sh script for rapid application development:

# Create workspace for existing recipe
./scripts/kas-dev-recipe.sh modify eink-power-cli

# Build modified application
./scripts/kas-dev-recipe.sh build eink-power-cli

# Deploy to target board
./scripts/kas-dev-recipe.sh deploy eink-power-cli 192.168.0.36

# Test on target
./scripts/kas-dev-recipe.sh run eink-power-cli 192.168.0.36 "/usr/bin/eink-power-cli status"

# Finalize changes back to recipe
./scripts/kas-dev-recipe.sh finish eink-power-cli

Kernel Development

Use the kas-dev-kernel.sh script for kernel development:

# Create kernel workspace
./scripts/kas-dev-kernel.sh modify

# Build kernel after making changes
./scripts/kas-dev-kernel.sh build

# Deploy to running target
./scripts/kas-dev-kernel.sh deploy 192.168.0.36
./scripts/kas-dev-kernel.sh reboot 192.168.0.36

Boot-Level Development

Use the kas-dev-boot.sh script for U-Boot and device tree work:

# Build U-Boot
./scripts/kas-dev-boot.sh build-uboot

# Build device trees
./scripts/kas-dev-boot.sh build-dt

# Program board (requires programming mode)
./scripts/kas-dev-boot.sh program

# Monitor boot process
./scripts/kas-dev-boot.sh monitor-boot

Factory Keys Solution

The Problem (SOLVED)

Initially, local development builds failed with errors like:

ERROR: SIGNING_MODSIGN_PRIVKEY=/build/conf/factory-keys/privkey_modsign.pem is not a file.

The Solution

Key Insight: Local development builds should NOT require factory keys!

The solution was creating a dedicated development kas configuration that:

1. Explicitly disables signing with UBOOT_SIGN_ENABLE="0", etc.
2. Points signing variables to existing file (bitbake.lock) to satisfy recipes that check file existence
3. Removes signing-related inherit classes like sign_rpm

What Was Removed

• ❌ conf/factory-keys/ directory (dummy keys)
• ❌ scripts/generate-dummy-keys.sh (dummy key generation)
• ❌ Complex key mounting into containers

Clean Architecture

Production: kas/lmp-dynamicdevices.yml     → Foundries.io signing
Development: kas/lmp-dynamicdevices-dev.yml → No signing, no keys

Configuration Files

Development Scripts

All development scripts automatically use the development kas configuration:

• scripts/kas-dev-recipe.sh - Application/recipe development
• scripts/kas-dev-kernel.sh - Kernel development
• scripts/kas-dev-boot.sh - Boot-level development
• scripts/devtool-demo.sh - Complete devtool demonstration

IP Address Configuration

All scripts support consistent IP address and port configuration:

• -t, --target IP - Target board IP address
• -p, --port PORT - Debug port configuration
• -d, --device DEVICE - Serial device for boot-level work

Environment variables are also supported:

• TARGET_IP - Default target IP
• DEBUG_PORT - Default debug port
• SERIAL_DEVICE - Default serial device

Performance Optimizations

First Build

The first development build takes longer as it builds the complete toolchain including:

• Native tools (binutils, gcc, clang, etc.)
• Cross-compilation toolchain
• All dependencies

Subsequent builds are much faster due to sstate cache reuse.

Build Performance

• Sstate cache: Shared between builds for faster rebuilds
• Parallel builds: Configured for optimal performance
• Network disabled: For most tasks (enabled only when needed like Cargo downloads)

Troubleshooting

Common Issues

1. "Recipe not compatible with machine"

   • Check COMPATIBLE_MACHINE in recipe
   • Ensure correct machine set in kas config

2. "Command not found" for development scripts

   • Ensure scripts are executable: chmod +x scripts/kas-dev-*.sh
   • Run from project root directory

3. SSH connection issues

   • Verify target board IP address
   • Check SSH access: ssh root@192.168.0.36
   • Ensure board is running and accessible

Debug Information

All development scripts provide verbose output including:

• 🎯 Configuration being used
• 📦 Recipe being processed
• 🎛️ Target machine
• 🔧 Current operation status

Next Steps

1. Test complete workflows - Verify all development scripts work end-to-end
2. Document SSH setup - Configure target boards for development access
3. Performance tuning - Optimize build times and deployment speed
4. Integration testing - Test workflows on multiple board types

This development environment provides a solid foundation for rapid embedded Linux development! 🚀