-
Notifications
You must be signed in to change notification settings - Fork 263
Add new learning path: Arm SoC migration #2817
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
e43f90b
369f150
352ad7a
3955b7e
ed58fcd
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| 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 | ||
| --- |
| 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 | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. |
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. |
There was a problem hiding this comment.
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: