Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
@@ -0,0 +1,62 @@
---
title: Migrate applications between ARM platforms with AI assistance

minutes_to_complete: 60

who_is_this_for: This learning path is for developers migrating applications between ARM platforms using Kiro's ARM SoC Migration Power. Learn the workflow through a practical example migrating from AWS Graviton to Raspberry Pi 5.

learning_objectives:
- Install and configure Kiro's ARM SoC Migration Power for any ARM SoC migration
- Understand the migration workflow applicable to various ARM platforms
- Use AI-guided migration to identify platform-specific code
- Create Hardware Abstraction Layers with power assistance
- Validate migrations with automated analysis

prerequisites:
- Access to source and target ARM platforms (example uses AWS Graviton and Raspberry Pi 5)
- Basic understanding of C programming
- Familiarity with embedded systems or cloud computing concepts

author: Daniel Schleicher

### Tags
skilllevels: Advanced
subjects: Migration to Arm
armips:
- Neoverse-V1
- Cortex-A76
operatingsystems:
- Linux
tools_software_languages:
- Kiro
- AWS EC2
- GCC
- C
- CMake

further_reading:
- resource:
title: Kiro ARM SoC Migration Power Documentation
link: https://kiro.dev/powers/arm-soc-migration
type: documentation
- resource:
title: AWS Graviton Technical Guide
link: https://aws.amazon.com/ec2/graviton/
type: documentation
- resource:
title: Raspberry Pi 5 Documentation
link: https://www.raspberrypi.com/documentation/
type: documentation
- resource:
title: Arm Architecture Reference
link: https://developer.arm.com/documentation
type: documentation
- resource:
title: BCM2712 Peripherals Datasheet
link: https://datasheets.raspberrypi.com/bcm2712/bcm2712-peripherals.pdf
type: documentation

### FIXED, DO NOT MODIFY
weight: 1
layout: learningpathall
---
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should just be a stub file created by hugo, it shouldn't have any actual content and minimal formatting, like this:

---
# ================================================================================
#       FIXED, DO NOT MODIFY THIS FILE
# ================================================================================
weight: 21                  # Set to always be larger than the content in this path to be at the end of the navigation.
title: "Next Steps"         # Always the same, html page title.
layout: "learningpathall"   # All files under learning paths have this same wrapper for Hugo processing.
---

Original file line number Diff line number Diff line change
@@ -0,0 +1,8 @@
---
# ================================================================================
# FIXED, DO NOT MODIFY THIS FILE
# ================================================================================
weight: 21 # Set to always be larger than the content in this path to be at the end of the navigation.
title: "Next Steps" # Always the same, html page title.
layout: "learningpathall" # All files under learning paths have this same wrapper for Hugo processing.
---
Original file line number Diff line number Diff line change
@@ -0,0 +1,84 @@
---
title: Develop on source platform
weight: 3

### FIXED, DO NOT MODIFY
layout: learningpathall
---

## Develop application on source ARM platform

This section demonstrates developing an application on your source ARM platform. The example uses AWS Graviton as the source platform, but the principles apply to any ARM SoC migration (e.g., from Raspberry Pi 4 to Pi 5, from i.MX8 to Jetson, etc.).

The workflow keeps your development environment (Kiro IDE) local while using the Graviton instance as a test platform. This mirrors real-world scenarios where you develop locally and deploy to remote ARM systems.

### Download Application on Local Machine

Download the sensor-monitor application to your local machine where Kiro IDE is running. This allows you to inspect the code and use Kiro's migration tools.

```bash
wget https://github.com/ArmDeveloperEcosystem/arm-learning-paths/raw/main/content/learning-paths/servers-and-cloud-computing/arm-soc-migration-learning-path/projects/sensor-monitor.tar.gz
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it be possible to put this code into a dedicated public repo? Ideally we don't want zip files in this repo even if they're small, given the current size of the learning path repo.

tar -xzf sensor-monitor.tar.gz
cd sensor-monitor
```

The package includes complete source code, Makefile, and platform-specific implementations.

### Upload to Graviton Instance for Testing

Transfer the application to your Graviton instance to verify it works on the source ARM platform before migration.

Upload the application to your Graviton instance:

```bash
scp -i graviton-migration-key.pem sensor-monitor.tar.gz ec2-user@$(aws ec2 describe-instances --filters "Name=tag:Name,Values=graviton-migration-source" "Name=instance-state-name,Values=running" --query 'Reservations[0].Instances[0].PublicIpAddress' --output text):~
```

### Build and Test on Graviton

Now verify the application builds and runs correctly on the Graviton platform. This establishes your baseline before migration.

SSH to your Graviton instance and build the application:

```bash
ssh -i graviton-migration-key.pem ec2-user@$(aws ec2 describe-instances --filters "Name=tag:Name,Values=graviton-migration-source" "Name=instance-state-name,Values=running" --query 'Reservations[0].Instances[0].PublicIpAddress' --output text)
```

On the Graviton instance:

```bash
tar -xzf sensor-monitor.tar.gz
cd sensor-monitor
make
./sensor_monitor
```

### Application Overview

The sensor-monitor application demonstrates a typical embedded/IoT pattern:

**Project Structure:**
```
sensor-monitor/
├── src/main.c # Main application logic
├── include/sensor.h # Sensor interface
├── platform/graviton/sensor_graviton.c # Graviton implementation
├── platform/rpi5/ # Target platform (created during migration)
├── Makefile # Build configuration
└── README.md # Documentation
```

**Key Components:**

`src/main.c` - Main application that reads sensor data in a loop
`include/sensor.h` - Hardware abstraction interface
`platform/graviton/sensor_graviton.c` - Simulated sensor for cloud development

## Expected Output

You should see:
- Working application on your source ARM platform (Graviton in this example)
- Simulated sensor readings
- Validated business logic

This establishes your baseline application before migration to the target platform.
Original file line number Diff line number Diff line change
@@ -0,0 +1,188 @@
---
title: Migrate using ARM SoC Migration Power
weight: 4

### FIXED, DO NOT MODIFY
layout: learningpathall
---

## Use ARM SoC Migration Power for AI-guided migration

This section demonstrates how to use the ARM SoC Migration Power to migrate your application between ARM SoCs. The example shows migration from AWS Graviton to Raspberry Pi 5, but the workflow applies to any ARM-to-ARM migration.

### Initiate Migration

Open Kiro and tell the ARM SoC Migration Power about your migration. Specify your source and target platforms:

**Example prompt:**
```
I want to use the ARM SoC Migration Power to migrate my sensor monitoring
application from AWS Graviton3 to Raspberry Pi 5 (BCM2712). The application
currently uses simulated sensors on Graviton and needs to work with real
GPIO and SPI hardware on the Pi 5.
```

**General pattern:**
```
I want to migrate my [application type] from [source ARM SoC] to [target ARM SoC].
The application uses [source-specific features] and needs [target-specific features].
```

### Discovery Phase

The power will prompt you for information about your platforms:

**Example for Graviton → Raspberry Pi 5:**
```
Source Platform: AWS Graviton3 (Neoverse-V1, cloud development)
Target Platform: Raspberry Pi 5 (BCM2712, Cortex-A76, edge deployment)
Hardware Requirements: GPIO for LEDs, SPI for temperature sensor
```

Then ask the power to scan your codebase:

**Example:**
```
Scan my codebase for Graviton-specific code that needs migration to BCM2712.
Focus on sensor interfaces and any cloud-specific assumptions.
```

**General pattern:**
```
Scan my codebase for [source platform]-specific code that needs migration to [target platform].
Focus on [platform-specific features].
```

### Architecture Analysis

Ask the power to compare your source and target platforms:

**Example:**
```
Compare Graviton3 and BCM2712 architecture capabilities. What are the key
differences I need to handle for cloud-to-edge migration?
```

**Example output for Graviton → Pi 5:**
- CPU differences (Neoverse-V1 vs Cortex-A76)
- Memory constraints (cloud 64GB+ vs edge 4-8GB)
- SIMD capabilities (SVE vs NEON)
- Peripheral requirements (none vs GPIO/SPI/I2C)

The power analyzes architecture differences for any ARM SoC pair and identifies migration challenges.

### HAL Design

Ask the power to design a Hardware Abstraction Layer for your platforms:

**Example:**
```
Help me design a HAL layer that supports both Graviton (cloud mocks) and
BCM2712 (real hardware). I need GPIO and SPI abstraction.
```

**General pattern:**
```
Help me design a HAL layer that supports both [source platform] and [target platform].
I need [feature] abstraction.
```

The power will guide you to create platform-agnostic interfaces. Example `hal/sensor.h`:

```c
typedef struct {
int (*init)(void);
float (*read_temperature)(void);
void (*cleanup)(void);
} sensor_hal_t;

extern const sensor_hal_t *sensor_hal;
```

### Implementation

Ask the power for target platform-specific implementation:

**Example:**
```
Help me refactor my sensor code for BCM2712 compatibility. Show me how to
implement real SPI sensor communication for the Pi 5.
```

**General pattern:**
```
Help me implement [feature] for [target platform]. Show me how to [specific requirement].
```

The power will provide target platform-specific code. Example for `platform/bcm2712/sensor_bcm2712.c`:

```c
#include "hal/spi.h"

int sensor_init(void) {
return spi_init(0, 1000000); // SPI bus 0, 1MHz
}

float sensor_read_temperature(void) {
uint8_t data[2];
spi_read(data, 2);
// Convert raw SPI data to temperature
int16_t raw = (data[0] << 8) | data[1];
return raw * 0.0625; // Typical temp sensor conversion
}

void sensor_cleanup(void) {
spi_cleanup();
}
```

### Build Configuration

Ask the power to update your build system for multi-platform support:

**Example:**
```
Update my build system for dual Graviton/BCM2712 support with proper
platform selection and cross-compilation.
```

**General pattern:**
```
Update my build system for [source platform]/[target platform] support with proper
platform selection and cross-compilation.
```

The power will generate a platform-aware build configuration. Example `CMakeLists.txt`:

```cmake
cmake_minimum_required(VERSION 3.16)
project(sensor_monitor)

set(TARGET_PLATFORM "GRAVITON" CACHE STRING "Target Platform")
set_property(CACHE TARGET_PLATFORM PROPERTY STRINGS "GRAVITON" "BCM2712")

# Common sources
set(COMMON_SOURCES src/main.c)

# Platform-specific sources
if(TARGET_PLATFORM STREQUAL "GRAVITON")
set(PLATFORM_SOURCES platform/graviton/sensor_graviton.c)
elseif(TARGET_PLATFORM STREQUAL "BCM2712")
set(CMAKE_C_COMPILER aarch64-linux-gnu-gcc)
set(PLATFORM_SOURCES
platform/bcm2712/sensor_bcm2712.c
platform/bcm2712/spi_bcm2712.c)
endif()

add_executable(sensor_monitor ${COMMON_SOURCES} ${PLATFORM_SOURCES})
```

## Expected Output

After this section, you should have:
- Power-analyzed architecture differences between your source and target platforms
- Power-designed HAL interfaces that abstract platform differences
- Power-generated platform-specific code for both platforms
- Power-configured build system with platform selection

This workflow applies to any ARM SoC migration, not just Graviton to Raspberry Pi 5.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ideally everything in the projects directory would go into a dedicated public repo.

Original file line number Diff line number Diff line change
@@ -0,0 +1,32 @@
# ARM SoC Migration Learning Path - Project Files

This directory contains downloadable project files for the ARM SoC Migration Learning Path.

## sensor-monitor.tar.gz

Complete sensor monitoring application for the migration tutorial.

**Contents:**
- Source code for sensor monitoring application
- Platform-specific implementations (Graviton and Raspberry Pi 5)
- Makefile for easy building
- Complete project structure

**Usage on Graviton EC2:**
```bash
wget https://github.com/ArmDeveloperEcosystem/arm-learning-paths/raw/main/content/learning-paths/servers-and-cloud-computing/arm-soc-migration-learning-path/projects/sensor-monitor.tar.gz
tar -xzf sensor-monitor.tar.gz
cd sensor-monitor
make
./sensor_monitor
```

**What's included:**
- `src/main.c` - Main application logic
- `include/sensor.h` - Sensor hardware abstraction interface
- `platform/graviton/sensor_graviton.c` - Graviton-specific implementation
- `platform/rpi5/` - Directory for Raspberry Pi 5 target (populated during migration)
- `Makefile` - Build configuration
- `README.md` - Detailed documentation

This pre-built package eliminates manual file creation and lets users focus on the migration workflow.
Binary file not shown.
Loading