SFO15-201: Boot Architecture for RDK Speaker: Khem Raj Date: September 22, 2015 ★ Session Description ★ A uniform boot sequence allows RDK systems to have predictable start-up behavior. RDK would like to use a two-level boot architecture, where the primary bootloader is device specific and initializes system registers, memory controller, and hardware resources, and the secondary bootloader implements more complex boot requirements like code download, system disaster recovery and firmware validation. ★ Resources ★ Video: Presentation: http://www.slideshare.net/linaroorg/sfo15201-boot-architecture-for-rdk Etherpad: pad.linaro.org/p/sfo15-201 Pathable: https://sfo15.pathable.com/meetings/302832 ★ Event Details ★ Linaro Connect San Francisco 2015 - #SFO15 September 21-25, 2015 Hyatt Regency Hotel http://www.linaro.org http://connect.linaro.org

1. • Bootloader Goals
• Typical Firmware Makeup on RDK devices
• Startup Flow
• Secure Boot Flow
• Bootloader characteristics
• Advanced Bootloader Requirements
• Advanced Bootloader Standard UI
• System Boot Elements and functionality
• Challenges
1
AGENDA

2. • Main goals of the bootloader
– Security
– Robustness
– Performance
– Flexibility
2
BOOTLOADER GOALS

3. 3
TYPICAL FIRMWARE MAKEUP ON RDK DEVICES
STAGE-1 BOOTLOADER
STAGE-2 BOOTLOADER
BACKUP DISASTER RECOVERY
IMAGE (B-DRI)
PRIMARY DISASTER RECOVERY
IMAGE (P-DRI)
PLATFORM CODE IMAGE – 1 (PCI-1)
PLATFORM CODE IMAGE -2 (PCI-2)
DATA – certs, image data etc.
• Stage-2 Bootloader (goal flexibility & robustness) also known as the advanced
bootloader (ABL) is responsible for validating and loading the correct platform
image
• Stage-1 Bootloader is rather dumb (goal is robustness) and is mainly
responsible for booting the stage-2 bootloader.
• There are two platform code images to ensure that a platform image is readily
available as a backup in case the active image fails.

4. 4
STARTUP FLOW
• Stage-2 Bootloader – validates each image in the order
mentioned and launches the first valid image.
• If an image is valid, the stage-2 bootloader will attempt to
launch it. If launch fails, it will update a failed retry count and
continue launching till failed retry count reaches a configured
threshold, after which it will proceed to launch the next valid
image.
• The disaster recovery images have limited functionality and
will need to download new platform code images for the
device to be fully functional.
SoC
Bootstrap
Stage-1
Bootloader
Stage-2
Bootloader
(ABL)
Validate
Image
Active Image
Standby Image
Primary DRI
Backup DRI
2
1
3
4

5. 5
SECURE BOOT FLOW
• Bootloader may run image from flash or RAM
depending on device memory constraints.
SoC
Bootstrap
Stage-1
Bootloader
Stage-2
Bootloader
(ABL)
Active Image
Standby
Image
Primary DRI
Backup DRI
2
1
3
4
Device Key Store (Factory Programmed)
SoC Owned OEM Owned
OEM Owned,
Comcast built
ValidatesValidates Validates

6. • Stage-1 Bootloader
– Factory Programmed
– Can validate signatures
– Not field upgradeable
– Chain of trust leading to SoC bootstrap
– No support for firmware upgrade. Only launches the stage-2
bootloader.
• Stage-2 Bootloader
– Factory Programmed
– Field Upgradeable under special circumstances using a special
firmware image. Strongly discouraged.
– Supports Comcast Configuration Management System based
firmware upgrade usingTFTP, TR-69 and HTTP protocols.
– Support for UBI, UBIFS, JFFS2, SQUASHFS, MTD based partitions.
6
BOOTLOADER CHARACTERISTICS

7. • Bootloader is not field upgradable, there must be another mechanism to upgrade it.
– Upgrade via console ports
– Special firmware images
• Advanced Bootloader invocation
– Front Panel Key combination on device
– Software APIs
• Can work with SNMP signals to trigger update
• Return valid system descriptor
• Returns valid DHCP options
• Log transitions into advanced bootloader and initialization
7
ADVANCED BOOTLOADER REQUIREMENTS

8. 8
ADVANCED BOOTLOADER STANDARD UI

9. • Disaster Recovery Image - Backup
– Can Download Image
– PerformsValidation
– Write image to flash
– Supports IPv4
– HTTP andTFTP protocol support
– Can support DOCSIS
– Supports DHCP
9
SYSTEM BOOT ELEMENTS

10. • Disaster Recovery Image
– SupportsTFTP/HTTP/HTTPS
– IPv6/IPv4
– external storage media ( Developer mode)
– ImplementsTR-069Triggers for Code Download
– Can upgrade platform firmware as well as itself
– Works over ethernet/WiFi/MoCA
– Supports Device Initiated Firmware download
– Perform various imageValidations
– Cold Factory Reset
– Remote Control Support
– Front Panel buttons support
– Supports DHCP
10
SYSTEM BOOT ELEMENTS

11. • Device Initiated
• TR-069Triggered
• IP Download
– IP devices
– Development Devices
11
CODE DOWNLOAD PROCESS

12. • Supports multiple network topologies
• DRI bridges all available I/Fs and initializes with DHCP if available
• Support for auto-IP/Zeroconf
12
NETWORKING

13. • Screen Diagnostics viaVideo Port
• Fixed resolution 720p e.g.
• Software Update progress Bar ( OSD Screen)
13
USER INTERFACE

14. • Non-standard bootloader across devices.
– Inconsistences in extent to which they are file-system aware leading to
special filesystems on different devices.
– Inability to create a standard end-to-end reference device.
• Opensource bootloaders have stringent licensing requirements
– Would be ideal to standardize on an available OSS bootloader.
– However, bootloaders typically have OEM or SoC vendor secret sauce
related to secure boot and other mandatory security functionality. GPL
v2 and similar license interfere with their ability to protect their IP while
leveraging these opensource bootloaders.
14
CHALLENGES

15. ThankYou
15
RDK BOOTLOADER