Skip to content

Development Workflows Building and Flashing

Alex J Lennon edited this page Oct 10, 2025 · 2 revisions

Building and Flashing - Core Development Workflow

⏱️ Time Required: 30-90 minutes (first build), 5-15 minutes (incremental)
Prerequisites: Development environment from Quick-Start-03-Development-Environment-Setup

🚀 Quick Build & Flash (Most Common Workflow)

1. One-Command Build & Program (5 minutes)

cd meta-dynamicdevices

# Build and program in one command (replace with your board)
KAS_MACHINE=imx8mm-jaguar-sentai ./scripts/kas-build-and-program.sh

# OR for E-Ink board
KAS_MACHINE=imx93-jaguar-eink ./scripts/kas-build-and-program.sh

2. Using Pre-Built Images from Foundries.io (2 minutes)

# Program latest Foundries.io build (fastest option)
./scripts/fio-program-board.sh --machine imx8mm-jaguar-sentai --program

# Program specific target number
./scripts/fio-program-board.sh --machine imx8mm-jaguar-sentai 1234 --program

# Continuous programming (multiple boards)
./scripts/fio-program-board.sh --machine imx8mm-jaguar-sentai --continuous

🔨 Detailed Build Process

1. Local Development Build (30-90 minutes first time)

cd meta-dynamicdevices

# Set target machine
export KAS_MACHINE=imx8mm-jaguar-sentai  # or imx93-jaguar-eink

# Full clean build (first time or major changes)
kas build kas/lmp-dynamicdevices.yml

# Incremental build (after changes)
kas shell kas/lmp-dynamicdevices.yml -c "bitbake lmp-factory-image"

2. Build Specific Components

# Build just the kernel
kas shell kas/lmp-dynamicdevices.yml -c "bitbake virtual/kernel"

# Build specific recipe
kas shell kas/lmp-dynamicdevices.yml -c "bitbake [recipe-name]"

# Clean and rebuild specific recipe
kas shell kas/lmp-dynamicdevices.yml -c "bitbake -c cleanall [recipe-name] && bitbake [recipe-name]"

3. Build Artifacts Location

# Built images location
ls build/tmp/deploy/images/${KAS_MACHINE}/

# Key files:
# - lmp-factory-image-${KAS_MACHINE}.wic.gz  (Main system image)
# - imx-boot-${KAS_MACHINE}                  (Bootloader)
# - fitImage-${KAS_MACHINE}                  (Kernel + DTB)

📱 Board Programming Methods

Method 1: Automated Script (Recommended)

# Using local build
./scripts/program-local-build.sh --machine ${KAS_MACHINE}

# Using Foundries.io build  
./scripts/fio-program-board.sh --machine ${KAS_MACHINE} --program

# Using custom boot firmware files (local build)
./scripts/program-local-build.sh --machine ${KAS_MACHINE} --mfgfolder ./custom-boot-files

# Using custom boot firmware files (Foundries.io build)
./scripts/fio-program-board.sh --machine ${KAS_MACHINE} --program --mfgfolder ./custom-boot-files

Custom Boot Firmware Support (--mfgfolder)

Both programming scripts support the --mfgfolder option for using custom boot firmware files. This is useful for:

  • Board-specific optimizations: Custom bootloader configurations
  • Development testing: Testing new bootloader versions
  • Recovery scenarios: Using known-good bootloader files
  • Hardware bring-up: Custom firmware for new board revisions

Required files in custom folder:

  • imx-boot-mfgtool - Manufacturing/recovery bootloader
  • u-boot-mfgtool.itb - Manufacturing U-Boot image

Example setup:

# Create custom boot files directory
mkdir -p custom-boot-files

# Copy your custom files (replace with actual custom files)
cp /path/to/your/imx-boot-mfgtool custom-boot-files/
cp /path/to/your/u-boot-mfgtool.itb custom-boot-files/

# Program with custom boot files
./scripts/program-local-build.sh --machine ${KAS_MACHINE} --mfgfolder custom-boot-files

How it works:

  • Local builds: Creates temporary symbolic links and modified UUU script
  • Foundries.io builds: Copies custom files to override defaults in mfgtool package
  • Both methods: Preserve original UUU scripts and system images
  • Clean operation: No permanent modifications to original files

Method 2: Manual UUU Programming

# Put board in programming mode:
# 1. Hold BOOT button (if present)
# 2. Connect USB-C cable
# 3. Power on board
# 4. Release BOOT button

# Check board detected
lsusb | grep -i "NXP\|Freescale"

# Program using UUU (Universal Update Utility)
cd program/
sudo ./uuu -b emmc_all imx-boot-${KAS_MACHINE} lmp-factory-image-${KAS_MACHINE}.wic.gz

# Expected output:
# uuu (Universal Update Utility) for nxp imx chips -- lib1.4.xx
# Success 1    Failure 0

Method 3: SD Card Programming (Development)

# Write image to SD card (replace /dev/sdX with your SD card)
sudo bmaptool copy build/tmp/deploy/images/${KAS_MACHINE}/lmp-factory-image-${KAS_MACHINE}.wic.gz /dev/sdX

# OR using dd (slower)
gunzip -c build/tmp/deploy/images/${KAS_MACHINE}/lmp-factory-image-${KAS_MACHINE}.wic.gz | sudo dd of=/dev/sdX bs=1M status=progress

🔄 Development Iteration Workflow

Typical Development Cycle

# 1. Make code changes (device tree, kernel config, recipes, etc.)

# 2. Incremental build (5-15 minutes)
kas shell kas/lmp-dynamicdevices.yml -c "bitbake lmp-factory-image"

# 3. Quick program (2-5 minutes)
./scripts/program-local-build.sh --machine ${KAS_MACHINE}

# 4. Test on board

# 5. Repeat

Fast Iteration Tips

# For kernel/device tree changes only:
kas shell kas/lmp-dynamicdevices.yml -c "bitbake virtual/kernel && bitbake lmp-factory-image"

# For recipe changes only:
kas shell kas/lmp-dynamicdevices.yml -c "bitbake [changed-recipe] && bitbake lmp-factory-image"

# Use ccache for faster builds (set in local.conf):
echo 'INHERIT += "ccache"' >> build/conf/local.conf

🐛 Build Troubleshooting

Common Build Issues

# Issue: Disk space full
df -h build/  # Check available space
# Solution: Clean old builds or increase disk space

# Issue: Network fetch failures  
# Solution: Check internet connection, try again
kas shell kas/lmp-dynamicdevices.yml -c "bitbake -c cleanall [failed-recipe] && bitbake [failed-recipe]"

# Issue: Signature mismatch
# Solution: Clean sstate cache
rm -rf build/sstate-cache/

Build Performance Optimization

# Use multiple CPU cores (add to build/conf/local.conf)
echo 'BB_NUMBER_THREADS = "8"' >> build/conf/local.conf
echo 'PARALLEL_MAKE = "-j 8"' >> build/conf/local.conf

# Enable shared state cache
echo 'SSTATE_DIR = "/opt/yocto-sstate"' >> build/conf/local.conf

# Use tmpfs for builds (if enough RAM)
echo 'TMPDIR = "/tmp/yocto-build"' >> build/conf/local.conf

📋 Programming Troubleshooting

Board Not Detected

# Check USB connection
lsusb | grep -i "NXP\|Freescale"

# If not found:
# 1. Try different USB cable/port
# 2. Check board power (LED indicators)
# 3. Verify boot mode (BOOT button procedure)
# 4. Check dmesg for USB errors: dmesg | tail -20

Programming Failures

# UUU timeout errors
# Solution: Check power supply (needs 5V 2A), try slower programming

# Permission denied
# Solution: Run with sudo or add udev rules
sudo ./uuu -b emmc_all [bootloader] [image]

# Image too large
# Solution: Check available eMMC space, use correct image variant

Boot Failures After Programming

# Board doesn't boot after programming
# Check: Serial console for error messages
screen /dev/ttyUSB0 115200

# Common issues:
# - Wrong device tree (check machine name)
# - Corrupted image (re-program)
# - Hardware failure (try known-good image)

✅ Build & Flash Checklist

Before Building:

  • Correct machine - KAS_MACHINE set properly
  • Clean workspace - No conflicting local changes
  • Disk space - At least 50GB free for full build
  • Network access - Internet connection for downloads

Before Programming:

  • Board in programming mode - BOOT button procedure
  • USB connection - Board detected by lsusb
  • Power supply - Stable 5V 2A minimum
  • Backup - Save current working image if needed

After Programming:

  • Boot test - Board boots to login prompt
  • Basic functionality - Network, GPIO, sensors working
  • Performance - Boot time reasonable (<30s)
  • Version check - Correct image version deployed

🔄 Next Steps

Build successful? → Test with Testing-And-Validation

Need debugging? → See Development-Workflows-Debugging-and-Troubleshooting

Want to customize? → Check Feature-Guides-Audio-Development for specific modifications


💡 Pro Tip: Set up a dedicated build machine with fast SSD and lots of RAM - Yocto builds are I/O and CPU intensive!

Clone this wiki locally