You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: content/learning-paths/servers-and-cloud-computing/arm-soc-migration-learning-path/_index.md
+12-15Lines changed: 12 additions & 15 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,25 +1,22 @@
1
1
---
2
-
title: Migrate applications between Arm platforms with AI assistance
3
-
4
-
draft: true
5
-
cascade:
6
-
draft: true
2
+
title: Migrate applications between Arm platforms using Kiro Arm SoC Migration Power
7
3
8
4
minutes_to_complete: 60
9
5
10
-
who_is_this_for: This learning path is for developers migrating applications between Arm platforms using using AI-assisted tooling with Kiro's ARM SoC Migration Power. You will learn a practical, repeatable migration workflow through an example that moves an application from the cloud to the edge — from AWS Graviton (Neoverse-based) to Raspberry Pi 5 (Cortex-A based).
6
+
who_is_this_for: This is an advanced topic for experienced developers who need to migrate applications between Arm-based platforms using AI-assisted tooling. You will work through a structured, repeatable migration workflow using Kiro Arm SoC Migration Power, moving an application from AWS Graviton3 (Neoverse) to Raspberry Pi 5 (Cortex-A). The techniques apply broadly to cloud-to-edge and cross-architecture migrations across the Arm ecosystem.
11
7
12
8
learning_objectives:
13
-
- Install and configure Kiro's ARM SoC Migration Power
14
-
- Understand a structured migration workflow applicable across Arm platforms
15
-
- Use AI-guided migration to identify platform-specific and hardware-dependent code
16
-
- Create Hardware Abstraction Layers with power assistance
17
-
- Validate and verify migrations with automated analysis
9
+
- Install and configure Kiro Arm SoC Migration Power
10
+
- Apply a structured migration workflow across Arm platforms
11
+
- Identify platform-specific and hardware-dependent code using AI-guided analysis
12
+
- Implement hardware abstraction layers to isolate platform-specific dependencies
13
+
- Validate and verify the migrated application using automated analysis
18
14
19
15
prerequisites:
20
-
- Access to a source and target Arm platforms (the example uses AWS Graviton3 and Raspberry Pi 5)
21
-
- Basic understanding of C programming
22
-
- Familiarity with embedded systems, Linux environments, or cloud computing concepts
16
+
- Access to both source and target Arm platforms (for example, AWS Graviton3 and Raspberry Pi 5)
17
+
- Working knowledge of C programming
18
+
- Familiarity with Linux development environments and basic embedded or cloud deployment concepts
19
+
- Experience building applications with GCC and CMake
Copy file name to clipboardExpand all lines: content/learning-paths/servers-and-cloud-computing/arm-soc-migration-learning-path/graviton-development.md
+23-23Lines changed: 23 additions & 23 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -7,25 +7,24 @@ layout: learningpathall
7
7
---
8
8
9
9
## Develop application on the source Arm platform
10
-
In this section, you will build and validate the application on the source Arm platform before performing any migration steps.
11
10
12
-
This example uses AWS Graviton3 as the source platform, however the same principles apply to any Arm-Arm migration scenario (e.g., from Raspberry Pi 4 to Pi 5, from i.MX8 to Jetson, etc.).
11
+
In this section, you will build and validate the application on the source Arm platform before performing any migration steps.
13
12
14
-
Your development environment (Kiro IDE) remains local. The Graviton instance acts as the remote Arm test platform. This mirrors real-world workflows where development occurs locally and deployment targets remote Arm systems.
13
+
This example uses AWS Graviton3 as the source platform. The same principles apply to any Arm-to-Arm migration scenario, such as Raspberry Pi 4 to Raspberry Pi 5 or i.MX8 to Jetson.
15
14
16
-
### Download the Application (Local Machine)
15
+
### Download the application (local machine)
17
16
18
-
Download the `sensor-monitor` application to your local machine (where Kiro IDE is installed).
17
+
Download the `sensor-monitor` application to your local machine (where Kiro IDE is installed). You inspect the project locally, then build and validate it on the Graviton3 instance.
The package includes the complete source code, a Makefile, and platform-specific implementations. You will analyze and migrate this code using the ARM SoC Migration Power.
25
+
The archive includes the complete source code, a Makefile, and platform-specific implementations. You will analyze and migrate this code using the Arm SoC Migration Power.
27
26
28
-
### Upload to the Graviton Instance for Testing
27
+
### Upload to the Graviton instance for testing
29
28
30
29
Before migrating, verify that the application builds and runs correctly on the source Arm platform.
31
30
@@ -35,7 +34,7 @@ Upload the archive to the Graviton instance:
If successful, the application will compile with GCC (AArch64 target) and display simulated sensor readings.
53
+
54
+
If successful, the application compiles for AArch64 using GCC and displays simulated sensor readings.
55
55
56
56
This confirms:
57
-
* The toolchain is functional
58
-
* The application builds cleanly on Arm64 Linux
59
-
60
-
This state becomes your baseline reference for migration validation.
61
57
62
-
### Application Overview
58
+
- The toolchain is functional
59
+
- The application builds cleanly on Arm64 Linux
60
+
61
+
This validated build becomes your migration baseline. Any functional differences after migration can be compared against this known-good state.
62
+
63
+
### Application overview
63
64
64
65
The `sensor-monitor` application demonstrates a common embedded/edge design pattern: business logic separated from platform-specific hardware interaction.
65
66
@@ -74,19 +75,18 @@ sensor-monitor/
74
75
└── README.md # Documentation
75
76
```
76
77
77
-
**Key Components:**
78
+
**Key components:**
78
79
79
80
`src/main.c` - Main application that reads sensor data in a loop
## Use ARM SoC Migration Power for AI-guided migration
9
+
## Use Arm SoC Migration Power for AI-guided migration
10
10
11
-
In this section you will learn how to use the ARM SoC Migration Power to migrate your application between Arm-based platforms. The example demonstrates migration from:
11
+
In this section, you use the Arm SoC Migration Power to migrate your application between Arm-based platforms. The example demonstrates migration from:
-**Target:** Raspberry Pi 5 (BCM2712, Cortex-A76, edge deployment)
15
15
16
-
However, the workflow applies to any Arm-to-Arm migration.
16
+
However, the workflow applies to any Arm-to-Arm migration. The migration process follows four phases: discovery, architecture analysis, abstraction design, and platform-specific implementation.
17
17
18
-
### Initiate Migration
18
+
For each step below, an example prompt for the Graviton-to-Pi-5 scenario is provided alongside a general pattern you can adapt for other platform pairs. Being explicit in your prompts improves the quality and precision of the Power’s architectural analysis.
19
19
20
-
Open Kiro and and describe your migration clearly using the ARM SoC Migration Power.
20
+
### Initiate migration
21
+
22
+
Open Kiro and describe your migration clearly using the Arm SoC Migration Power.
21
23
22
24
Example prompt:
23
25
```
24
-
I want to use the ARM SoC Migration Power to migrate my sensor monitoring
26
+
I want to use the Arm SoC Migration Power to migrate my sensor monitoring
25
27
application from AWS Graviton3 to Raspberry Pi 5 (BCM2712). The application
26
28
currently uses simulated sensors on Graviton and needs to work with real
27
29
GPIO and SPI hardware on the Pi 5.
28
30
```
29
31
30
-
The general pattern to use for other Arm-based platform migrations:
32
+
The general pattern for other Arm-based platform migrations:
31
33
```
32
-
I want to migrate my [application type] from [source ARM SoC] to [target ARM SoC].
34
+
I want to migrate my [application type] from [source Arm SoC] to [target Arm SoC].
33
35
The application uses [source-specific features] and needs [target-specific features].
34
36
```
35
-
Being explicit improves the quality of the Power’s architectural reasoning.
36
37
37
-
### Discovery Phase
38
+
### Discovery phase
38
39
39
-
The power will prompt you for information about your platforms:
40
+
Provide detailed information about both platforms:
40
41
41
42
**Example for Graviton → Raspberry Pi 5:**
42
43
```
@@ -46,56 +47,49 @@ Hardware Requirements: GPIO for LEDs, SPI for temperature sensor
46
47
```
47
48
Next, instruct the Power to analyze your codebase for platform dependencies:
48
49
49
-
Example Prompt:
50
+
Example prompt:
50
51
```
51
52
Scan my codebase for Graviton-specific code that needs migration to BCM2712.
52
53
Focus on sensor interfaces and any cloud-specific assumptions.
53
54
```
54
55
55
-
The general pattern to use for other Arm-based platform migrations:
56
+
The general pattern for other Arm-based platform migrations:
56
57
```
57
58
Scan my codebase for [source platform]-specific code that needs migration to [target platform].
58
59
Focus on [platform-specific features].
59
60
```
60
-
This step ensures migration is systematic rather than ad hoc.
61
+
This ensures the migration is systematic, traceable, and grounded in explicit platform assumptions.
61
62
62
63
63
-
### Architecture Analysis
64
+
### Architecture analysis
64
65
65
66
Now compare the architectural characteristics of the platforms.
66
67
67
-
Example Prompt:
68
+
Example prompt:
68
69
```
69
70
Compare Graviton3 and BCM2712 architecture capabilities. What are the key
70
71
differences I need to handle for cloud-to-edge migration?
71
72
```
72
73
73
-
**Example output for Graviton → Pi 5:**
74
-
- CPU differences (Neoverse-V1 vs Cortex-A76)
75
-
- Memory constraints (cloud 64GB+ vs edge 4-8GB)
76
-
- SIMD capabilities (SVE vs NEON)
77
-
- Peripheral requirements (none vs GPIO/SPI/I2C)
78
-
79
-
The power analyzes architecture differences for any Arm SoC pair and identifies migration challenges.
74
+
For Graviton3 to Pi 5, the Power identifies key differences such as CPU architecture (Neoverse-V1 vs Cortex-A76), available memory (cloud 64 GB+ vs edge 4–8 GB), SIMD capabilities (SVE vs NEON), and peripheral requirements (none vs GPIO/SPI/I2C). The Power analyzes these differences for any Arm SoC pair and identifies the migration challenges you need to address.
80
75
81
76
### Design the Hardware Abstraction Layer (HAL)
82
77
83
-
Now formalize a platform-independent interface. Ask the power to design a Hardware Abstraction Layer for your platforms:
78
+
Now formalize a platform-independent interface. Ask the Power to design a Hardware Abstraction Layer (HAL) for your platforms:
84
79
85
-
Example Prompt:
80
+
Example prompt:
86
81
```
87
82
Help me design a HAL layer that supports both Graviton (cloud mocks) and
88
83
BCM2712 (real hardware). I need GPIO and SPI abstraction.
89
84
```
90
85
91
-
92
-
The general pattern to use for other Arm-based platform migrations:
86
+
The general pattern for other Arm-based platform migrations:
93
87
94
88
```
95
89
Help me design a HAL layer that supports both [source platform] and [target platform].
96
90
I need [feature] abstraction.
97
91
```
98
-
The Power may propose a structured abstraction such as the example shown `hal/sensor.h`:
92
+
The Power may propose a structured abstraction such as the example shown in `hal/sensor.h`:
99
93
100
94
```c
101
95
typedefstruct {
@@ -107,22 +101,22 @@ typedef struct {
107
101
externconstsensor_hal_t *sensor_hal;
108
102
```
109
103
110
-
### Implement Target Platform Support
104
+
### Implement target platform support
111
105
112
106
Now generate or refactor platform-specific code using the Power:
113
107
114
-
Example Prompt:
108
+
Example prompt:
115
109
```
116
110
Help me refactor my sensor code for BCM2712 compatibility. Show me how to
117
111
implement real SPI sensor communication for the Pi 5.
118
112
```
119
113
120
-
The general pattern to use for other Arm-based platform migrations:
114
+
The general pattern for other Arm-based platform migrations:
121
115
```
122
116
Help me implement [feature] for [target platform]. Show me how to [specific requirement].
123
117
```
124
118
125
-
The power will provide target platform-specific code. Example for `platform/bcm2712/sensor_bcm2712.c`:
119
+
The Power will provide target platform-specific code. Example for `platform/bcm2712/sensor_bcm2712.c`:
126
120
127
121
```c
128
122
#include"hal/spi.h"
@@ -143,24 +137,25 @@ void sensor_cleanup(void) {
143
137
spi_cleanup();
144
138
}
145
139
```
140
+
Review all generated or refactored code carefully to ensure correctness, performance, and alignment with your hardware constraints.
146
141
147
-
### Update the Build System
142
+
### Update the build system
148
143
149
-
Ask the power to update your build system for multi-platform support:
144
+
Ask the Power to update your build system for multi-platform support:
150
145
151
-
Example Prompt:
146
+
Example prompt:
152
147
```
153
148
Update my build system for dual Graviton/BCM2712 support with proper
154
149
platform selection and cross-compilation.
155
150
```
156
151
157
-
The general pattern to use for other Arm-based platform migrations:
152
+
The general pattern for other Arm-based platform migrations:
158
153
```
159
154
Update my build system for [source platform]/[target platform] support with proper
160
155
platform selection and cross-compilation.
161
156
```
162
157
163
-
The power will generate a platform-aware build configuration. Example `CMakeLists.txt`:
158
+
The Power will generate a platform-aware build configuration. Example `CMakeLists.txt`:
0 commit comments