-
Overview
-
redpesk OS releases
-
Security updates
- Security CVE / errata
- CVE quick look
-
Redpesk OS Tips and Tricks
-
Application Framework Manager
-
Application Framework Binder
-
APIs & Services
-
Security manager
-
OP-TEE within redpesk
-
Trusted Boot
-
Recovery features
-
redpak
-
Minimal image
- Reduce image size
- Optimizing boot time
-
Kernel fragments description
- Introduction to Linux Kernel Configuration
- 01 Disable IPC, Timers and Audit
- 02 Disable Kconfig, Scheduler and Initrd
- 03 Disable Perf, Profiling and Errata
- 04 Disable EFI, Power Management Debug and Energy Model
- 05 Disable Schedutil, CPUFreq Governors and Virtualization
- 06 Disable Kprobes and Jump Labels
- 07 Disable GCC Plugins and Function Alignment
- 08 Disable Partition Parsers
- 09 Enable Inline Spinlocks and Kernel Operations
- 10 Disable Swap, Memory Hotplug and KSM
- 11 Disable Networking IPv4, IPv6, Netfilter
- 12 Disable SCTP, VLAN, TIPC, BATMAN
- 13 Disable Wireless, Bluetooth, CAN and RFKILL
- 14 Disable PCI and Firmware
- 15 Disable GNSS and ProcEvents
- 16 Disable Block Storage NBD and AoE
- 17 Disable EEPROM and Misc Drivers
- 18 Disable Network Device Drivers
- 19 Disable PHY Drivers
- 20 Disable PPP, WLAN Coexistence, and Failover
- 21 Disable Input Devices
- 22 Disable Serial, TTY and TPM
- 23 Disable I2C, Power and Sensor Drivers
- 24 Disable MFD, Display and Media Drivers
- 25 Disable USB, Sound, RTC and VirtIO
- 26 Disable Filesystem Encodings and Compatibility
- 27 Enable Minimal Cryptographic Core with SHA3 and XTS
- 28 Disable Hardware Cryptography, Keep DRBG and Jitter Entropy
- 29 Disable Kernel Debugging Features
- 30 Disable Filesystem Verity and SecurityFS
-
Zephyr in Redpesk
-
PERM-CHECK extension
-
Mender redpesk (OTA)
-
Hardware support
- Download images
- Image metrics
- Trusted Boot
- Boards - ARM64
- Boards - x86_64
- Boards - Virtual
- Miscs
-
Building microservices natively within SDK container
-
Building microservices and framework from sources
Reducing boot time
- General optimizations for boot time (e.g., parallel services, reducing services).
- Optimization tips for systemd and user-space tools.
Optimizing the boot time of a Linux kernel in the development cycle of an industrial product is crucial for several reasons, depending on the use case and industry requirements:
Why optimize boot time?
- User Experience: Many industrial products, such as Human-Machine Interfaces (HMIs) or consumer-facing devices, demand fast responsiveness. A lengthy boot process can frustrate users or create a perception of inefficiency.
- Operational Requirements: Some industrial systems, such as automotive control units or medical devices, require near-instantaneous startup to ensure safety and reliability. For example, a vehicle’s dashboard or a critical diagnostic tool must be operational immediately upon power-up.
- Power Constraints: Devices with frequent power cycles, like battery-operated systems or energy-sensitive industrial equipment, benefit from reduced boot times to minimize downtime and conserve power.
- Time-Sensitive Applications: Real-time systems often require specific subsystems or functionalities to be operational within strict deadlines.
- Regulatory Compliance: Certain industries have standards mandating minimal startup times for safety-critical devices, such as those in healthcare or aerospace.
- Production Line Efficiency: During manufacturing, testing, and deployment, faster boot times reduce the wait time for software loading, speeding up production and testing cycles.
When to optimize boot time?
- Early in the Development Cycle: Address boot time optimization during the initial design phase when selecting hardware and configuring the kernel. Decisions like processor choice, memory size, and storage speed significantly impact boot time.
- Prototype Stage: Once a functional prototype is available, measure the boot time to identify bottlenecks and refine the kernel and application configuration.
- Integration Phase: When integrating with other hardware or software components, ensure that subsystems critical to startup are prioritized and optimized.
- Testing Phase: During system testing, fine-tune boot performance to meet the product’s requirements and expectations.
- Before Deployment: Final optimization ensures that the product meets all performance, compliance, and user experience goals.
How to optimize boot time?
- Kernel configuration: Remove unused drivers, features, and modules. Use a minimal init system or switch to fast alternatives like systemd-analyze.
- Hardware choices: Use faster storage (e.g., eMMC or SSD) and processors with adequate clock speeds.
- Parallelization: Enable parallel initialization of drivers and services where possible.
- Custom initramfs: Optimize the initial RAM filesystem to include only essential components.
- Firmware/Bootloader: Optimize or replace the bootloader (e.g., U-Boot) for faster loading.
- Deferred initialization: Defer non-essential tasks until after the system is operational.
Optimizing boot time isn’t just about speed; it’s about aligning the product’s startup behavior with functional, user, and regulatory requirements. Addressing it early in the development cycle ensures smoother integration and avoids costly redesigns later.