[WIP] Raspberry Pi Test Plan

[WIP] Raspberry Pi Test Plan

Buildroot Metrics Test Plan

Raspberry Pi CM5 Controls Display System


Project Overview

Purpose: Create a slimmed-down Linux OS for Raspberry Pi CM5 as Controls Display
Build System: Buildroot (chosen over Yocto for simplicity)
Target Platform: Raspberry Pi Compute Module 5 (64-bit ARM)


Key Metrics to Evaluate

1. Boot Time

Target: < 10 seconds from power-on to usable display

2. Memory Footprint

Target: < 256MB RAM usage at idle

3. Memory Under Load

Target: < 512MB RAM usage during typical operations

4. Power Draw

Target: < 2.5W average power consumption


Big Picture Test Phases

Phase 1: Build & Baseline

Goal: Establish working system and collect baseline metrics

Steps:

  1. Configure minimal buildroot system

  2. Build and flash image

  3. Verify system boots successfully

  4. Collect baseline measurements

  5. Document build artifacts and sizes


Phase 2: Boot Time Optimization 🚀

Goal: Minimize boot time to target

Steps:

  1. Measure current boot time

  2. Identify boot bottlenecks

  3. Disable unnecessary services

  4. Optimize kernel configuration

  5. Test stripped-down init system

  6. Validate boot time improvements


Phase 3: Memory Optimization 🔧

Goal: Minimize memory footprint

Steps:

  1. Measure idle memory usage

  2. Identify memory-heavy components

  3. Replace heavy packages with lightweight alternatives

  4. Remove unnecessary libraries

  5. Test memory usage under load

  6. Validate functionality with reduced footprint

Duration: 0.5 workday


Phase 4: Power Optimization ⚡

Goal: Minimize power consumption

Steps:

  1. Measure baseline power draw

  2. Disable unused peripherals

  3. Optimize display power settings

  4. Test power draw under various loads

  5. Validate power savings


Phase 5: Graphics & Display 🖥️

Goal: Optimize display system for controls interface

Steps:

  1. Validate X11/Wayland performance

  2. Test graphics acceleration

  3. Measure display latency

  4. Optimize frame rate

  5. Test touch input responsiveness

  6. Validate display reliability

Duration: 2-3 days


Phase 6: Integration & Validation

Goal: Verify that the complete system meets all metrics

Steps:

  1. Run the complete executable of Photon

  2. Verify all metrics are met

  3. Perform stress testing

  4. Document final configuration

  5. Create a deployment image


Detailed Metric Measurement Plans

Metric 1: Boot Time

Measurement Method

# Add to kernel command line: initcall_debug # Analyze boot time dmesg | grep "Freeing unused kernel memory" # Use systemd-analyze (if using systemd) systemd-analyze time systemd-analyze blame # Manual timing # Start timer at power-on, stop at login prompt

Test Scenarios

  • [ ] Cold boot (power off → power on)

  • [ ] Warm boot (reboot command)

  • [ ] Boot with network enabled

  • [ ] Boot with display enabled

  • [ ] Boot to X11/Wayland

Target Breakdown

Stage

Target Time

Actual Time

Notes

Stage

Target Time

Actual Time

Notes

Firmware

< 2s

 

 

Kernel

< 3s

 

 

Init

< 2s

 

 

Services

< 3s

 

 

Total

< 10s

 

 

Optimization Strategies

  • [ ] Use compressed kernel image

  • [ ] Minimize kernel modules

  • [ ] Use simple init system (BusyBox)

  • [ ] Parallel service startup

  • [ ] Disable unnecessary services

  • [ ] Optimize device tree

  • [ ] Use initramfs for fast boot


💾 Metric 2: Memory Footprint (Idle)

Measurement Method

# After boot, measure memory free -h # Detailed memory breakdown cat /proc/meminfo # Per-process memory ps aux --sort=-%mem | head -20 # Shared library memory cat /proc/*/maps | grep '\.so' | sort -u

Test Scenarios

  • [ ] Idle at console

  • [ ] Idle with X11 running

  • [ ] Idle with display manager

  • [ ] Idle with network active

Target Breakdown

Component

Target

Actual

Notes

Component

Target

Actual

Notes

Kernel

< 50MB

 

 

Init System

< 10MB

 

 

Display Server

< 80MB

 

 

Base Services

< 50MB

 

 

Free RAM

> 180MB

 

 

Total Usage

< 256MB

 

 

Optimization Strategies

  • [ ] Use musl instead of glibc (smaller)

  • [ ] Minimize kernel modules

  • [ ] Use lightweight display server

  • [ ] Disable unnecessary services

  • [ ] Strip binaries and libraries

  • [ ] Use shared libraries efficiently

  • [ ] Consider Wayland instead of X11


📈 Metric 3: Memory Under Load

Measurement Method

# Monitor memory during operations watch -n 1 free -h # Stress test stress-ng --vm 2 --vm-bytes 50M --timeout 60s # Monitor specific application ps aux | grep [application_name]

Test Scenarios

  • [ ] Running display application

  • [ ] Multiple applications open

  • [ ] Network activity

  • [ ] File operations

  • [ ] Graphics rendering

  • [ ] Peak usage scenario

Target Breakdown

Scenario

Target

Actual

Notes

Scenario

Target

Actual

Notes

Display App

< 150MB

 

 

Network

< 30MB

 

 

Background

< 50MB

 

 

Peak

< 280MB

 

 

Total

< 512MB

 

 

Optimization Strategies

  • [ ] Monitor memory leaks

  • [ ] Optimize application memory

  • [ ] Use memory-efficient data structures

  • [ ] Implement proper cleanup

  • [ ] Consider zram/swap if needed

  • [ ] Profile hot paths


⚡ Metric 4: Power Draw

Measurement Method

# Using hardware power meter (most accurate) # Measure at 5V input # Software estimation (less accurate) vcgencmd measure_volts vcgencmd measure_clock arm vcgencmd measure_temp # CPU frequency cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq

Test Scenarios

  • [ ] Idle (no display)

  • [ ] Idle (display on)

  • [ ] Light load (UI interaction)

  • [ ] Medium load (graphics rendering)

  • [ ] Heavy load (CPU intensive)

  • [ ] Sleep/suspend mode

Target Breakdown

State

Target Power

Actual

Notes

State

Target Power

Actual

Notes

Idle (display off)

< 1.5W

 

 

Idle (display on)

< 2.5W

 

 

Light Load

< 3.5W

 

 

Medium Load

< 4.5W

 

 

Peak

< 6.0W

 

 

Optimization Strategies

  • [ ] Use conservative CPU governor

  • [ ] Reduce GPU memory allocation

  • [ ] Disable unused peripherals (WiFi, BT, USB ports)

  • [ ] Optimize display brightness

  • [ ] Enable CPU frequency scaling

  • [ ] Implement power management

  • [ ] Use hardware sleep modes


Test Execution Workflow

Pre-Test Setup

# 1. Build the system cd buildroot make raspberrypi_cm5_defconfig # Or custom defconfig make menuconfig # Adjust as needed make -j$(nproc) # 2. Flash to storage sudo dd if=output/images/sdcard.img of=/dev/sdX bs=4M status=progress # 3. Boot and configure # Connect serial console for accurate measurements # Connect power meter # Connect display

Test Execution

# Create test log directory mkdir -p test_results/$(date +%Y%m%d) cd test_results/$(date +%Y%m%d) # Run automated test suite ./run_metrics_tests.sh > test_output.log # Manual verification # Record observations in test_notes.txt

Data Collection Template

Test Run: [Date/Time] Configuration: [Brief description] Hardware: [Pi model, peripherals] Boot Time: - Cold boot: _____ seconds - Warm boot: _____ seconds Memory (Idle): - Total: _____ MB - Free: _____ MB - Cached: _____ MB Memory (Load): - Peak: _____ MB - Application: _____ MB Power: - Idle: _____ W - Load: _____ W - Peak: _____ W Notes: [Additional observations]

Buildroot Configuration Considerations

Minimal Configuration Checklist

  • [ ] Target: aarch64 (ARM 64-bit)

  • [ ] Toolchain: External (Bootlin) or Internal

  • [ ] Init: BusyBox (smallest) or systemd (feature-rich)

  • [ ] C Library: musl (smallest) or glibc (compatible)

  • [ ] Kernel: Latest stable with minimal modules

  • [ ] Filesystem: squashfs (read-only, compressed) or ext4

Critical Packages for Controls Display

# Core System BR2_PACKAGE_BUSYBOX=y BR2_PACKAGE_BUSYBOX_SHOW_OTHERS=y # Graphics BR2_PACKAGE_MESA3D=y BR2_PACKAGE_MESA3D_GALLIUM_DRIVER_VC4=y BR2_PACKAGE_MESA3D_OPENGL_EGL=y # Display Server (choose one) BR2_PACKAGE_XORG7=y # Or Wayland BR2_PACKAGE_WESTON=y # Input BR2_PACKAGE_LIBINPUT=y BR2_PACKAGE_EVTEST=y # Fonts BR2_PACKAGE_FREETYPE=y BR2_PACKAGE_FONTCONFIG=y

Optimization Options

# Size optimization BR2_OPTIMIZE_S=y BR2_STRIP_strip=y BR2_ENABLE_LTO=y # Boot optimization BR2_TARGET_ROOTFS_SQUASHFS=y BR2_LINUX_KERNEL_ZIMAGE=y # Memory optimization BR2_TOOLCHAIN_BUILDROOT_MUSL=y BR2_ENABLE_LOCALE_PURGE=y

Success Criteria Summary

Must Have ✅

  • [ ] Boot time < 10 seconds

  • [ ] Idle memory < 256MB

  • [ ] Load memory < 512MB

  • [ ] Power draw < 2.5W idle

  • [ ] System stable for 24+ hours

  • [ ] Display functional

  • [ ] Input responsive

Nice to Have 🎯

  • [ ] Boot time < 5 seconds

  • [ ] Idle memory < 128MB

  • [ ] Support for OTA updates

  • [ ] Remote management capability

  • [ ] Diagnostic tools included

  • [ ] Automatic recovery on failure


Deliverables

1. Metrics Report

  • Baseline measurements

  • Optimization results

  • Final metrics comparison

  • Graphs and charts

2. Build Configuration

  • Final defconfig file

  • config.txt settings

  • Custom overlays

  • Build documentation

3. Test Artifacts

  • Test scripts

  • Log files

  • Power measurements

  • Boot timing data

4. Deployment Package

  • sdcard.img file

  • Flash instructions

  • Configuration guide

  • Troubleshooting guide


Timeline Estimate

Phase

Duration

Dependencies

Phase

Duration

Dependencies

Phase 1: Build & Baseline

1-2 days

None

Phase 2: Boot Optimization

2-3 days

Phase 1

Phase 3: Memory Optimization

2-3 days

Phase 1

Phase 4: Power Optimization

1-2 days

Phase 1

Phase 5: Graphics & Display

2-3 days

Phase 1-4

Phase 6: Integration

1-2 days

Phase 1-5

Total

10-15 days

 


Notes & Recommendations

For CM5 Specifically

  • CM5 has more RAM options (2GB/4GB/8GB) - test with target variant

  • CM5 has better power management than Pi 4

  • Ensure custom carrier board compatibility

  • Test with intended display interface (DSI/HDMI)

Buildroot vs Yocto

Buildroot Advantages:

  • Simpler learning curve

  • Faster build times (30 min - 2 hours)

  • Easier to understand and modify

  • Better for embedded appliances

  • Smaller final images

Buildroot Limitations:

  • No binary package management

  • Full rebuilds often needed

  • Less flexible than Yocto

  • Smaller community/ecosystem

Recommendation: Start with Buildroot. Use Yocto if we need/want better package management or extremely complex requirements.