Skip to content

Commit 58fe36b

Browse files
pareenavermapareenaverma
authored
Merge pull request #3466 from anupras-mohapatra-arm/summaries-and-faqs
Summaries and faqs for 20 'cross platform' LPs
2 parents 0467204 + 83889a4 commit 58fe36b

21 files changed

Lines changed: 984 additions & 37 deletions

File tree

‎.github/skills/writing-style-review/SKILL.md‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -19,7 +19,7 @@ Use this skill for granular prose, voice, readability, terminology, and style re
1919
## Voice and tone
2020

2121
- Use second person: `you` and `your` for Learning Path summaries, Learning Path content, install guide content, answers to FAQs, and metadata descriptions. Avoid first person for these content types.
22-
- Use first person: `I` and `we` for FAQs.
22+
- Use first person: `I` for FAQ questions only.
2323
- Use active voice.
2424
- Use present tense for descriptions.
2525
- Use imperative mood for commands.

‎content/learning-paths/cross-platform/adler32/_index.md‎

Lines changed: 50 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -12,11 +12,59 @@ learning_objectives:
1212

1313
prerequisites:
1414
- An Arm computer running Linux with the GNU compiler (gcc) installed.
15-
- Visual Studio Code with the GitHub Copilot extension installed.
15+
- Visual Studio Code with the GitHub Copilot extension installed.
16+
17+
# START generated_summary_faq
18+
generated_summary_faq:
19+
template_version: summary-faq-v3
20+
generated_at: '2026-07-02T17:11:56Z'
21+
generator: ai
22+
ai_assisted: true
23+
ai_review_required: true
24+
model: gpt-5
25+
prompt_template: summary-faq-v3
26+
source_hash: 37b19106fba70423ba8c58f82097d9251f0ae208e882c852f9c4531afcebb46c
27+
summary_generated_at: '2026-07-02T17:11:56Z'
28+
summary_source_hash: 37b19106fba70423ba8c58f82097d9251f0ae208e882c852f9c4531afcebb46c
29+
faq_generated_at: '2026-07-02T17:11:56Z'
30+
faq_source_hash: 37b19106fba70423ba8c58f82097d9251f0ae208e882c852f9c4531afcebb46c
31+
summary: >-
32+
You'll use GitHub Copilot in Visual Studio Code to set up an Adler32
33+
checksum project on an Arm Linux system, establish a C baseline, and measure results. First, you'll
34+
generate the C implementation, create a test program that validates correctness and records
35+
timing for multiple input sizes, and ask Copilot to produce a GCC-based Makefile tuned for
36+
a Neoverse N1 target. Then, you'll build and run the project, verify outputs, and
37+
collect timing data. With a working harness and repeatable measurements, you're positioned
38+
to introduce Arm Neon intrinsics for the Adler32 hot path and compare behavior against the
39+
baseline C version.
40+
faqs:
41+
- question: What files should exist before building?
42+
answer: >-
43+
You should have the C implementation (`adler32-simple.c`), a test program (`adler32-test.c`),
44+
and a Makefile generated by GitHub Copilot. If a file is missing or named differently, regenerate
45+
it using the provided prompts.
46+
- question: Which GitHub Copilot mode should I use to generate the code and Makefile?
47+
answer: >-
48+
Use the Copilot Agent session in VS Code and paste the prompts from the steps. Results vary
49+
by model, so minor differences in code or target names are expected.
50+
- question: How do I run the tests and verify correctness?
51+
answer: >-
52+
Use the Copilot-generated Makefile to build and execute the test program. The run should
53+
confirm correct checksum results for all listed data sizes before you proceed.
54+
- question: What should I check if the GCC build fails on my Arm system?
55+
answer: >-
56+
Confirm that GCC is installed and that the Makefile’s architecture-specific flags are supported.
57+
If a flag is not recognized for your CPU, adjust or remove it and rebuild.
58+
- question: What output should I expect when measuring performance?
59+
answer: >-
60+
The test program measures timing around Adler32 calls on random inputs of 1 KB, 10 KB, 100
61+
KB, 1 MB, and 10 MB. You should see per-size timings that you can reuse when evaluating
62+
a Neon-based implementation.
63+
# END generated_summary_faq
1664

1765
author: Jason Andrews
1866

19-
generate_summary_faq: true
67+
generate_summary_faq: false
2068
rerun_summary: false
2169
rerun_faqs: false
2270

@@ -58,4 +106,3 @@ weight: 1 # _index.md always has weight of 1 to order corr
58106
layout: "learningpathall" # All files under learning paths have this same wrapper
59107
learning_path_main_page: "yes" # This should be surfaced when looking for related content. Only set for _index.md of learning path content.
60108
---
61-

‎content/learning-paths/cross-platform/automate-mcp-with-testcontainers/_index.md‎

Lines changed: 48 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -17,9 +17,56 @@ prerequisites:
1717
- Basic familiarity with Python, PyTest, and container concepts
1818
- Familiarity with the [Model Context Protocol (MCP)](https://modelcontextprotocol.io/) specification
1919

20+
# START generated_summary_faq
21+
generated_summary_faq:
22+
template_version: summary-faq-v3
23+
generated_at: '2026-07-02T17:12:52Z'
24+
generator: ai
25+
ai_assisted: true
26+
ai_review_required: true
27+
model: gpt-5
28+
prompt_template: summary-faq-v3
29+
source_hash: 597877722e5f277e5558e29ecd33878ac2262b70a84a9769325b3c3b0ce06e58
30+
summary_generated_at: '2026-07-02T17:12:52Z'
31+
summary_source_hash: 597877722e5f277e5558e29ecd33878ac2262b70a84a9769325b3c3b0ce06e58
32+
faq_generated_at: '2026-07-02T17:12:52Z'
33+
faq_source_hash: 597877722e5f277e5558e29ecd33878ac2262b70a84a9769325b3c3b0ce06e58
34+
summary: >-
35+
You'll automate integration testing of Model Context Protocol (MCP)
36+
servers using PyTest and Testcontainers. First, you'll prepare a Python and Docker environment,
37+
verify Docker availability, and run a short Testcontainers example to start a disposable container
38+
and execute commands inside it. Then, you'll build a minimal integration test suite for
39+
the Arm MCP server, focusing on JSON-RPC 2.0 communication over standard input and output.
40+
Finally, you'll add a GitHub Actions workflow to run the tests on every push and pull request
41+
using native arm64 runners with Docker. By the end, you'll have containerized tests that validate
42+
MCP server behavior locally and in continuous integration.
43+
faqs:
44+
- question: How do I know Docker is ready before running the examples?
45+
answer: >-
46+
Run `docker info` and confirm it returns configuration details without errors. If it fails,
47+
start the Docker daemon and retry.
48+
- question: What should I expect when I run the basic Testcontainers example?
49+
answer: >-
50+
It starts a long-running container, executes a command inside it, and then cleans up when
51+
the script ends. Seeing the command output and a clean exit indicates the example worked.
52+
- question: How do the integration tests communicate with an MCP server?
53+
answer: >-
54+
MCP uses JSON-RPC 2.0 over standard input/output, so tests exchange JSON-RPC messages with
55+
the server process. When containerized, Testcontainers manages the server lifecycle during
56+
each test run.
57+
- question: Where can I find a complete reference implementation of the tests?
58+
answer: >-
59+
A full test implementation is available in the Arm MCP repository under `mcp-local/tests/`.
60+
You can consult those files while building your own suite.
61+
- question: Which events should trigger the GitHub Actions workflow, and where is it defined?
62+
answer: >-
63+
The workflow runs on `push` and `pull_request` and is defined at `.github/workflows/integration-tests.yml`.
64+
GitHub’s native Arm64 runners include Docker.
65+
# END generated_summary_faq
66+
2067
author: Neethu Elizabeth Simon
2168

22-
generate_summary_faq: true
69+
generate_summary_faq: false
2370
rerun_summary: false
2471
rerun_faqs: false
2572

@@ -70,4 +117,3 @@ weight: 1 # _index.md always has weight of 1 to order corr
70117
layout: "learningpathall" # All files under learning paths have this same wrapper
71118
learning_path_main_page: "yes" # This should be surfaced when looking for related content. Only set for _index.md of learning path content.
72119
---
73-

‎content/learning-paths/cross-platform/avh_cicd/_index.md‎

Lines changed: 47 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -14,9 +14,55 @@ learning_objectives:
1414
prerequisites:
1515
- Some familiarity with CI/CD concepts is assumed
1616

17+
# START generated_summary_faq
18+
generated_summary_faq:
19+
template_version: summary-faq-v3
20+
generated_at: '2026-07-02T17:13:33Z'
21+
generator: ai
22+
ai_assisted: true
23+
ai_review_required: true
24+
model: gpt-5
25+
prompt_template: summary-faq-v3
26+
source_hash: b6a7439a701f6ae09ce8c61f02150a61fa6ecc1151050e903492e16794999676
27+
summary_generated_at: '2026-07-02T17:13:33Z'
28+
summary_source_hash: b6a7439a701f6ae09ce8c61f02150a61fa6ecc1151050e903492e16794999676
29+
faq_generated_at: '2026-07-02T17:13:33Z'
30+
faq_source_hash: b6a7439a701f6ae09ce8c61f02150a61fa6ecc1151050e903492e16794999676
31+
summary: >-
32+
You'll connect Arm Virtual Hardware (AVH) to a GitHub Actions CI/CD
33+
workflow for embedded software. First, you'll prepare a GitHub repository by forking an example
34+
project, generate a Personal Access Token with permission to update workflow files, and set
35+
up an AVH instance using the Arm Virtual Hardware install guide. Then, you'll enable GitHub
36+
Actions on the fork and add a self-hosted runner on an AWS host, selecting a Linux image
37+
and x64 architecture to match the instance. By the end, you'll configure the repository to use
38+
an AVH-backed self-hosted runner so workflows can drive automated testing and validation for
39+
bare‑metal targets.
40+
faqs:
41+
- question: Which permission should I enable on the GitHub Personal Access Token?
42+
answer: >-
43+
Enable the token to update GitHub Action workflows. Generate it under **Settings > Developer
44+
settings > Personal access tokens** and save it locally.
45+
- question: Where do I run the self-hosted runner setup commands?
46+
answer: >-
47+
Run the commands shown after selecting **New self-hosted runner** on the machine that will host
48+
the runner. Use the AWS instance where Arm Virtual Hardware is set up.
49+
- question: Which runner image and architecture should I choose?
50+
answer: >-
51+
Set **Runner image** to **Linux** and **Architecture** to **x64**. This matches the AWS instance as specified
52+
in the steps.
53+
- question: How do I enable GitHub Actions on my fork?
54+
answer: >-
55+
Open the **Actions** tab in your fork. If workflows are disabled, click **I understand my workflows,
56+
go ahead and enable them**.
57+
- question: How do I verify that the self-hosted runner is available to the repository?
58+
answer: >-
59+
Open **Settings > Actions > Runners** in the repository and confirm the runner appears in the
60+
list. If it doesn't, re-check the setup commands on the instance.
61+
# END generated_summary_faq
62+
1763
author: Pareena Verma
1864

19-
generate_summary_faq: true
65+
generate_summary_faq: false
2066
rerun_summary: false
2167
rerun_faqs: false
2268

‎content/learning-paths/cross-platform/avh_cicd2/_index.md‎

Lines changed: 48 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -15,9 +15,56 @@ prerequisites:
1515
- This learning path builds on [Integrate Arm Virtual Hardware into CI/CD workflow 1](/learning-paths/cross-platform/avh_cicd/).
1616
- Valid AWS and GitHub accounts are required
1717

18+
# START generated_summary_faq
19+
generated_summary_faq:
20+
template_version: summary-faq-v3
21+
generated_at: '2026-07-02T17:14:08Z'
22+
generator: ai
23+
ai_assisted: true
24+
ai_review_required: true
25+
model: gpt-5
26+
prompt_template: summary-faq-v3
27+
source_hash: 251b6edf6a016f9fc73eb35216f56b2001465fbca8253bd7b6e6f9f4afcd25e6
28+
summary_generated_at: '2026-07-02T17:14:08Z'
29+
summary_source_hash: 251b6edf6a016f9fc73eb35216f56b2001465fbca8253bd7b6e6f9f4afcd25e6
30+
faq_generated_at: '2026-07-02T17:14:08Z'
31+
faq_source_hash: 251b6edf6a016f9fc73eb35216f56b2001465fbca8253bd7b6e6f9f4afcd25e6
32+
summary: >-
33+
You'll extend Arm Virtual Hardware (AVH) integration by preparing an AWS account with a CloudFormation
34+
stack and connecting it to a forked GitHub repository that runs automated build and validation
35+
on AVH. First, you'll fork the `ARM-software/AVH-GetStarted` project, deploy the
36+
included CloudFormation template, and configure GitHub Actions with repository secrets. The
37+
settings include the AWS region used by the stack and a valid VPC subnet ID obtained from
38+
the AWS console. After configuration, you'll run the workflow in GitHub Actions to drive
39+
tests on AVH, providing a clear sequence from account setup to automated
40+
validation.
41+
faqs:
42+
- question: How do I get the example project used in this workflow?
43+
answer: >-
44+
Fork the [repository](https://github.com/ARM-software/AVH-GetStarted/fork) and clone your
45+
fork. The example includes a template to help set up your AWS account and documentation
46+
for the CI workflow.
47+
- question: What do I need to complete in AWS before adding GitHub secrets?
48+
answer: >-
49+
Deploy the CloudFormation stack using the template provided in the example project. After
50+
creating the stack, proceed to define the repository secrets in GitHub.
51+
- question: Which value should I use for `AWS_DEFAULT_REGION`?
52+
answer: >-
53+
Use the same AWS Region where you created the CloudFormation stack. The region must match
54+
for the workflow to reference the correct resources.
55+
- question: How do I find the `AWS_SUBNET_ID` required by the workflow?
56+
answer: >-
57+
In the AWS console, go to **VPC > Subnets** and select any valid Subnet ID. Copy that ID into
58+
the `AWS_SUBNET_ID` repository secret.
59+
- question: Where do I add the required secrets in GitHub, and do names matter?
60+
answer: >-
61+
In your forked repository, go to **Settings > Secrets > Actions**, then choose **New repository
62+
secret**. The secret names must match exactly as specified in the Learning Path.
63+
# END generated_summary_faq
64+
1865
author: Pareena Verma
1966

20-
generate_summary_faq: true
67+
generate_summary_faq: false
2168
rerun_summary: false
2269
rerun_faqs: false
2370

‎content/learning-paths/cross-platform/aws-greengrass-pacbti-test/_index.md‎

Lines changed: 50 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -19,11 +19,60 @@ prerequisites:
1919
- An NVIDIA Jetson Thor device running JetPack 7.1 or later
2020
- Familiarity with AWS IoT Core and basic cloud concepts
2121

22+
# START generated_summary_faq
23+
generated_summary_faq:
24+
template_version: summary-faq-v3
25+
generated_at: '2026-07-02T19:01:20Z'
26+
generator: ai
27+
ai_assisted: true
28+
ai_review_required: true
29+
model: gpt-5
30+
prompt_template: summary-faq-v3
31+
source_hash: 202dcb3054a983defc04c70315a3329f88ebbb20ca21039d3f24fb44314d1e09
32+
summary_generated_at: '2026-07-02T19:01:20Z'
33+
summary_source_hash: 202dcb3054a983defc04c70315a3329f88ebbb20ca21039d3f24fb44314d1e09
34+
faq_generated_at: '2026-07-02T19:01:20Z'
35+
faq_source_hash: 202dcb3054a983defc04c70315a3329f88ebbb20ca21039d3f24fb44314d1e09
36+
summary: >-
37+
You'll configure two Arm devices as AWS IoT Greengrass
38+
core devices, build a custom component that checks Pointer Authentication (PAC) and Branch
39+
Target Identification (BTI), and deploy that component to both targets via a Greengrass
40+
thing group. You'll upload the component artifact to Amazon S3, create a Greengrass deployment
41+
in the AWS console, and use MQTT to trigger the checks. The Raspberry Pi 5 (Armv8.2-A) serves
42+
as a negative comparison for PAC/BTI, while the Jetson Thor (Armv9-A) provides a positive
43+
control. By completing the steps, you'll compare per-device results and recognize unsupported
44+
versus supported PAC/BTI behavior across Armv8 and Armv9 platforms.
45+
faqs:
46+
- question: How do I know each device is ready to receive a Greengrass deployment?
47+
answer: >-
48+
In AWS IoT Core, confirm the device is registered as a Greengrass core device and appears
49+
in the thing group you plan to deploy to. If it isn't in the group, add it before creating
50+
the deployment.
51+
- question: What result should I expect from the PAC/BTI test on Raspberry Pi 5 versus Jetson
52+
Thor?
53+
answer: >-
54+
Raspberry Pi 5 (Armv8.2-A) should report PAC and BTI as not supported. Jetson Thor (Armv9-A)
55+
should report both PAC and BTI as supported.
56+
- question: Where should I store the custom component artifact before creating the deployment?
57+
answer: >-
58+
Upload the component artifact to an Amazon S3 bucket created in the AWS console. Keep the
59+
default bucket settings for this tutorial and ensure the artifact is available for the component
60+
to use during deployment.
61+
- question: Which target should I select to deploy the component to both devices at once?
62+
answer: >-
63+
Select a Greengrass thing group (for example, My_PAC_BTI_Test_Devices) as the deployment
64+
target. This delivers the same component set to both core devices in the group.
65+
- question: How do I trigger and validate the PAC/BTI checks after deployment?
66+
answer: >-
67+
Use MQTT to trigger the checks as described in the steps, then review the results reported
68+
for each device. Expect outputs that let you interpret PAC/BTI support per platform.
69+
# END generated_summary_faq
70+
2271
author:
2372
- Varun Chari
2473
- Doug Anson
2574

26-
generate_summary_faq: true
75+
generate_summary_faq: false
2776
rerun_summary: false
2877
rerun_faqs: false
2978

‎content/learning-paths/cross-platform/build-a-reachy-robot-app-on-pi/_index.md‎

Lines changed: 48 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -22,9 +22,56 @@ prerequisites:
2222
- Basic Python and Bash terminal experience.
2323
- (Optional) [Reachy Mini](https://huggingface.co/reachy-mini)
2424

25+
# START generated_summary_faq
26+
generated_summary_faq:
27+
template_version: summary-faq-v3
28+
generated_at: '2026-07-02T19:04:59Z'
29+
generator: ai
30+
ai_assisted: true
31+
ai_review_required: true
32+
model: gpt-5
33+
prompt_template: summary-faq-v3
34+
source_hash: d021122b9217e2326e98d45aeffccb742357e77a7774f9c469d2c73285ca91a9
35+
summary_generated_at: '2026-07-02T19:04:59Z'
36+
summary_source_hash: d021122b9217e2326e98d45aeffccb742357e77a7774f9c469d2c73285ca91a9
37+
faq_generated_at: '2026-07-02T19:04:59Z'
38+
faq_source_hash: d021122b9217e2326e98d45aeffccb742357e77a7774f9c469d2c73285ca91a9
39+
summary: >-
40+
You'll build a distributed edge AI application that runs MediaPipe
41+
gesture inference on a Raspberry Pi 5 and drives a Reachy Mini robot in a MuJoCo simulation.
42+
First, you'll start the simulator on a development machine, prepare the Pi with Raspberry Pi OS and
43+
Git LFS so the gesture model downloads correctly, then run the app and open a browser dashboard
44+
to monitor the camera feed and verdicts. A thumbs-up or thumbs-down from the webcam triggers
45+
victory or defeat motions in the simulated robot. You'll also learn about the project layout
46+
so you can locate perception, app logic, motion, and dashboard components in the codebase to iterate on.
47+
faqs:
48+
- question: Which address should I open to view the dashboard?
49+
answer: >-
50+
If you use VS Code Remote SSH port forwarding, open `http://localhost:8042` on your laptop.
51+
Otherwise, browse to `http://<pi-ip-address>:8042` from any machine on the same network.
52+
- question: How do I find the Raspberry Pi IP address for the dashboard?
53+
answer: >-
54+
Run `hostname -I` on the Raspberry Pi to print its IP address. Then use that address with
55+
port `8042` in your browser.
56+
- question: How do I confirm the gesture model downloaded correctly with Git LFS?
57+
answer: >-
58+
Check that `assets/gesture_recognizer.task` exists as a real model file, not a tiny pointer
59+
file. If you cloned before enabling Git LFS, enable LFS and re-clone the repository.
60+
- question: The dashboard loads but the MuJoCo simulation doesn't move—what should I check?
61+
answer: >-
62+
Verify the MuJoCo simulation is running on your development machine and that the Pi can
63+
reach it over the network. Also review `main.py` because it contains the settings used for
64+
the distributed simulation route.
65+
- question: What result should I expect when a thumbs-up or thumbs-down is detected?
66+
answer: >-
67+
You should see the simulated Reachy Mini play a victory or defeat motion, and the web dashboard
68+
should reflect the verdict. This indicates the camera, inference, network, and simulator
69+
are connected end to end.
70+
# END generated_summary_faq
71+
2572
author: Matt Cossins
2673

27-
generate_summary_faq: true
74+
generate_summary_faq: false
2875
rerun_summary: false
2976
rerun_faqs: false
3077

0 commit comments

Comments
 (0)