diff --git a/.wordlist.txt b/.wordlist.txt index 10571ce17..b38472514 100644 --- a/.wordlist.txt +++ b/.wordlist.txt @@ -308,7 +308,6 @@ Alibaba Altra AmazonRDS Analytics -Andoid Anonymized ArmDeveloperEcosystem ArmNN @@ -3420,4 +3419,95 @@ snortrules techmahindra unreferenced uptime -wC \ No newline at end of file +wC +ApiService +AppHost +ArmPyTorchMNISTInference +Blazor +CameraX +ComputationService +Coroutine +EOF +EVCLI +EVidence +Evcli +GC’s +GenerateMatrix +ImageCapture +InputStream +JWT +JetPack +KBS +MediaPipe's +Mongod +Multimodal +NNAPI +NPUs +NetAspire +OpenTelemetry +PIL +PerformIntensiveCalculations +ReactiveX's +ServiceDefaults +SharedFlow +Skopeo +StateFlow +TestOpenCV +TrustedFirmware +Veraison +WeatherForecast +WebGPU’s +Wiredtiger +androidml +ar +armpytorchmnistinference +codelabs +combinator +cooldown +coroutines +cryptographically +datatracker +debounce +decrypts +diagnosticDataCollectionDirectorySizeMB +eab +eth +evcli +googleblog +hanyin +honorSystemUmask +ietf +jsonviewer +keyFile +livestream +lockCodeSegmentsInMemory +matrixResult +matrixSize +maxIncomingConnections +mongod +mongosh +multimodality +multimodel +oplogSizeMB +optimizable +orchestrator +prebuild +preconfigured +relica +replSetName +rfc +serializable +setParameter +skopeo +subclasses +subproject +subproject's +subrepositories +suppressNoTLSPeerCertificateWarning +systemLog +tlsWithholdClientCertificate +unutilized +vLLM +veraison +verifier +vllm \ No newline at end of file diff --git a/content/learning-paths/cross-platform/function-multiversioning/examples2.md b/content/learning-paths/cross-platform/function-multiversioning/examples2.md index ef76e5077..2ed806dec 100644 --- a/content/learning-paths/cross-platform/function-multiversioning/examples2.md +++ b/content/learning-paths/cross-platform/function-multiversioning/examples2.md @@ -10,8 +10,6 @@ This example computes the dot product of two vectors using Arm C Language Extens The intention is to enable the compiler to use SVE instructions in the specialized case, while restricting it to use only Armv8 instructions in the default case. -More details on the default implementation can be found in [Implement dot product of two vectors](/learning-paths/smartphones-and-mobile/android_neon/dot_product_neon). - Use a text editor to create a file named `dotprod.c` with the code below: ```c diff --git a/content/learning-paths/cross-platform/remoteit/components.md b/content/learning-paths/cross-platform/remoteit/components.md index 506e529ad..6400301f1 100644 --- a/content/learning-paths/cross-platform/remoteit/components.md +++ b/content/learning-paths/cross-platform/remoteit/components.md @@ -14,7 +14,7 @@ weight: 2 | Desktop | Windows, macOS, and Linux | initiator and target | | CLI | Windows, macOS, and Linux | initiator and target | | Device package | Linux, OpenWRT, and many others | target only | -| Mobile | Andoid, iOS | initiator (Android and iOS) and target (Android only) | +| Mobile | Android, iOS | initiator (Android and iOS) and target (Android only) | Any software package marked as `initiator` can connect to other `target` devices. The target software packages can receive connections from other devices. Packages marked as both initiator and target can do both functions. diff --git a/content/learning-paths/laptops-and-desktops/_index.md b/content/learning-paths/laptops-and-desktops/_index.md index 2053f4494..5580428e8 100644 --- a/content/learning-paths/laptops-and-desktops/_index.md +++ b/content/learning-paths/laptops-and-desktops/_index.md @@ -11,9 +11,9 @@ operatingsystems_filter: - Android: 2 - Baremetal: 1 - ChromeOS: 1 -- Linux: 29 -- macOS: 7 -- Windows: 38 +- Linux: 27 +- macOS: 5 +- Windows: 36 subjects_filter: - CI-CD: 3 - Containers and Virtualization: 6 @@ -24,7 +24,7 @@ title: Laptops and Desktops tools_software_languages_filter: - .NET: 12 - Alacritty: 1 -- Android Studio: 2 +- Android Studio: 1 - Arm Development Studio: 2 - Arm64EC: 1 - assembly: 1 @@ -36,7 +36,7 @@ tools_software_languages_filter: - CCA: 1 - Clang: 10 - CMake: 2 -- Coding: 19 +- Coding: 17 - CSS: 1 - Docker: 4 - GCC: 9 @@ -68,7 +68,7 @@ tools_software_languages_filter: - Trusted Firmware: 1 - Visual Studio: 10 - Visual Studio Code: 9 -- VS Code: 2 +- VS Code: 3 - Windows Forms: 1 - Windows Performance Analyzer: 1 - Windows Presentation Foundation: 1 diff --git a/content/learning-paths/microcontrollers/yolo-on-himax/web-toolkit.md b/content/learning-paths/microcontrollers/yolo-on-himax/web-toolkit.md index 28146efb7..db5f254f0 100644 --- a/content/learning-paths/microcontrollers/yolo-on-himax/web-toolkit.md +++ b/content/learning-paths/microcontrollers/yolo-on-himax/web-toolkit.md @@ -101,9 +101,9 @@ The images below are captured images from the models run in the toolkit. ### Objection detection ![object_detection](./object_detection.jpg) -The Frames Per Second (FPS) index represents the number of ML inferences the hardware can complete per second. A higher number indicates better performance. The colored bounding boxes represent the objects identified by YOLO. The name of the object is labelled in the top left-hand corner of the box, and the number in parentheses is the confidence level as a percentage. This example shows that it can identify 9.53 frames per second with a confidence level of 64% for the 'CPU' object. +The Frames Per Second (FPS) index represents the number of ML inferences the hardware can complete per second. A higher number indicates better performance. The colored bounding boxes represent the objects identified by YOLO. The name of the object is labeled in the top left-hand corner of the box, and the number in parentheses is the confidence level as a percentage. This example shows that it can identify 9.53 frames per second with a confidence level of 64% for the 'CPU' object. ### Face detection ![object_detection](./face_detection.jpg) -Similar to the previous example, the bounding boxes identify the areas in the image that contain faces and recognize the positions of different facial features. This image shows that YOLO has identified a face with 99% confidence. It has marked the mouth with a yellow line segment and used different colours to mark the eyebrows, eyes, and nose. Within the bounding box for the eyes, it has further identified the gaze direction vector. +Similar to the previous example, the bounding boxes identify the areas in the image that contain faces and recognize the positions of different facial features. This image shows that YOLO has identified a face with 99% confidence. It has marked the mouth with a yellow line segment and used different colors to mark the eyebrows, eyes, and nose. Within the bounding box for the eyes, it has further identified the gaze direction vector. diff --git a/content/learning-paths/servers-and-cloud-computing/_index.md b/content/learning-paths/servers-and-cloud-computing/_index.md index bece087d1..7351be0c9 100644 --- a/content/learning-paths/servers-and-cloud-computing/_index.md +++ b/content/learning-paths/servers-and-cloud-computing/_index.md @@ -9,9 +9,9 @@ maintopic: true operatingsystems_filter: - Android: 2 - Baremetal: 1 -- Linux: 111 -- macOS: 9 -- Windows: 13 +- Linux: 113 +- macOS: 7 +- Windows: 12 pinned_modules: - module: name: Recommended getting started learning paths @@ -20,21 +20,21 @@ pinned_modules: - migration subjects_filter: - CI-CD: 4 -- Containers and Virtualization: 25 +- Containers and Virtualization: 26 - Databases: 15 - Libraries: 7 -- ML: 14 -- Performance and Architecture: 40 +- ML: 13 +- Performance and Architecture: 42 - Storage: 1 - Web: 10 subtitle: Optimize cloud native apps on Arm for performance and cost title: Servers and Cloud Computing tools_software_languages_filter: -- .NET: 1 +- .NET: 2 - .NET SDK: 1 - 5G: 1 - ACL: 1 -- Android Studio: 2 +- Android Studio: 1 - Ansible: 2 - Arm Development Studio: 4 - armclang: 1 @@ -52,28 +52,28 @@ tools_software_languages_filter: - BOLT: 1 - bpftool: 1 - C: 4 -- C#: 1 +- C#: 2 - C++: 3 - C/C++: 2 - Capstone: 1 -- CCA: 3 +- CCA: 5 - Clair: 1 - Clang: 10 - ClickBench: 1 - ClickHouse: 1 - CloudFormation: 1 - CMake: 1 -- Coding: 20 +- Coding: 18 - Django: 1 -- Docker: 15 +- Docker: 16 - Envoy: 2 - Flink: 1 - Fortran: 1 -- FVP: 3 -- GCC: 19 +- FVP: 4 +- GCC: 20 - gdb: 1 - Geekbench: 1 -- GenAI: 5 +- GenAI: 6 - GitHub: 3 - GitLab: 1 - Glibc: 1 @@ -92,7 +92,7 @@ tools_software_languages_filter: - Lambda: 1 - libbpf: 1 - Linaro Forge: 1 -- LLM: 3 +- LLM: 4 - llvm-mca: 1 - LSE: 1 - MariaDB: 1 @@ -108,15 +108,14 @@ tools_software_languages_filter: - PAPI: 1 - perf: 4 - PostgreSQL: 4 -- Python: 13 +- Python: 14 - PyTorch: 5 - RAG: 1 - Redis: 3 - Remote.It: 2 -- RME: 3 +- RME: 4 - Rust: 2 - snappy: 1 -- Snort: 1 - Snort3: 1 - SQL: 7 - Streamline CLI: 1 @@ -131,7 +130,10 @@ tools_software_languages_filter: - Trusted Firmware: 1 - TypeScript: 1 - Vectorscan: 1 -- Visual Studio Code: 3 +- Veraison: 1 +- Visual Studio Code: 4 +- vLLM: 1 +- VS Code: 1 - WindowsPerf: 1 - WordPress: 3 - x265: 1 diff --git a/content/learning-paths/servers-and-cloud-computing/cca-essentials/_index.md b/content/learning-paths/servers-and-cloud-computing/cca-essentials/_index.md index 6c253cd82..8fec5dc3b 100644 --- a/content/learning-paths/servers-and-cloud-computing/cca-essentials/_index.md +++ b/content/learning-paths/servers-and-cloud-computing/cca-essentials/_index.md @@ -13,7 +13,7 @@ learning_objectives: prerequisites: - An AArch64 or x86_64 computer running Linux. You can use cloud instances, see this list of [Arm cloud service providers](/learning-paths/servers-and-cloud-computing/csp/). - Completion of the [Introduction to CCA Attestation with Veraison](/learning-paths/servers-and-cloud-computing/cca-veraison) Learning Path. - - Completion of the [Run an application in a Realm using the Arm Confidential Computing Architecture (CCA)](learning-paths/servers-and-cloud-computing/cca-container/) Learning Path. + - Completion of the [Run an application in a Realm using the Arm Confidential Computing Architecture (CCA)](/learning-paths/servers-and-cloud-computing/cca-container/) Learning Path. author_primary: Arnaud de Grandmaison, Paul Howard, and Pareena Verma diff --git a/content/learning-paths/servers-and-cloud-computing/cca-essentials/cca-essentials.md b/content/learning-paths/servers-and-cloud-computing/cca-essentials/cca-essentials.md index 92dc99af5..f583ba760 100644 --- a/content/learning-paths/servers-and-cloud-computing/cca-essentials/cca-essentials.md +++ b/content/learning-paths/servers-and-cloud-computing/cca-essentials/cca-essentials.md @@ -26,7 +26,7 @@ For additional security, the KBS does not release any secrets in clear text, eve In the example in this Learning Path, you will see that the secret that is exchanged between the KBS and the realm is a small string value, which the realm decrypts and echoes to its console window once all the attestation steps have succeeded. -For convenience, both the KBS and the client software are packaged in docker containers, which you can execute on any suitable AArch64 or x86_64 development machine. Since the client software runs in a realm, it makes use of the Fixed Virtual Platform (FVP) and the reference software stack for Arm CCA. If you have not yet familiarised yourself with running applications in realms using FVP and the reference software stack, see the [Run an application in a Realm using the Arm Confidential Computing Architecture (CCA)](/learning-paths/servers-and-cloud-computing/cca-container) Learning Path. +For convenience, both the KBS and the client software are packaged in docker containers, which you can execute on any suitable AArch64 or x86_64 development machine. Since the client software runs in a realm, it makes use of the Fixed Virtual Platform (FVP) and the reference software stack for Arm CCA. If you have not yet familiarized yourself with running applications in realms using FVP and the reference software stack, see the [Run an application in a Realm using the Arm Confidential Computing Architecture (CCA)](/learning-paths/servers-and-cloud-computing/cca-container) Learning Path. The attestation verification service is hosted by Linaro, so it is not necessary for you to build or deploy this service yourself. diff --git a/content/learning-paths/servers-and-cloud-computing/cca-veraison/attestation-token.md b/content/learning-paths/servers-and-cloud-computing/cca-veraison/attestation-token.md index 95b336670..08e625f92 100644 --- a/content/learning-paths/servers-and-cloud-computing/cca-veraison/attestation-token.md +++ b/content/learning-paths/servers-and-cloud-computing/cca-veraison/attestation-token.md @@ -148,8 +148,8 @@ It is not important to understand every detail of the attestation token, but her - The platform token contains the evidence about the Arm CCA platform on which the realm is running, which includes details about the state of the hardware and firmware that compose the platform. You can think of the platform as a single server or self-contained computing device. A single platform can host many realms, which can be executing as virtual machines or containers. Therefore, many realms might produce the same platform token. - The realm token contains the evidence about the realm itself, which is running on the platform. It is the more dynamic part of the token. It includes information about the realm’s initial memory contents and boot state. - The top-level data items in each sub-token are known as claims. A claim is an individual evidence fragment that describes a specific property of the system. -- The claims of the platform token are labelled with the prefix `cca-platform-*` -- The claims of the realm token are labelled with the prefix `cca-realm-*` +- The claims of the platform token are labeled with the prefix `cca-platform-*` +- The claims of the realm token are labeled with the prefix `cca-realm-*` - Many of the claims take the form of _measurements_. A measurement is a hash (checksum) that is computed from one of the firmware or software components that are running within the realm or within the platform. Checking these measurements against known-good values is an essential step for evaluating the trustworthiness of the realm. Any mismatch could mean that the system is running some software or firmware that has been tampered with, or is at the wrong patch or version level. You might find it instructive to view the token in a formatting tool such as https://jsonviewer.stack.hu, where you can interactively expand and collapse different parts of the object tree to gain a better feel for the structure. Doing this may help you to digest the bullet points above. diff --git a/content/learning-paths/servers-and-cloud-computing/cca-veraison/evaluate-result.md b/content/learning-paths/servers-and-cloud-computing/cca-veraison/evaluate-result.md index ce1e2586f..af6ad86da 100644 --- a/content/learning-paths/servers-and-cloud-computing/cca-veraison/evaluate-result.md +++ b/content/learning-paths/servers-and-cloud-computing/cca-veraison/evaluate-result.md @@ -66,10 +66,10 @@ This part of the output shows how the verification service has compared the atte It is important to understand that an attestation result is not a simple "yes" or "no" answer to the question of whether the system is trustworthy. Instead, it is a set of data points, known as _trustworthiness vectors_. Each data point shows how a particular aspect of the system compares against the expectations set by the verification service. Each point of comparison can lead to one of the following results: -- __Affirming__. This is the most favourable result. It is given when the evidence in the attestation token shows a good match against the expectations of a trustworthy system. -- __Warning__. This is a less favourable result. It is given when the attestation token does not show a good match against the expectations of a trustworthy system. -- __None__. This is an unfavourable result, meaning that no comparison was possible, either because data was missing from the evidence in the attestation token, or because the verification service does not have any expectations to compare the evidence against, and is therefore unable to draw any conclusion. -- __Contraindicated__. This is the least favourable result. It is given when the evidence in the attestation token specifically contradicts the expectations of a trustworthy system. +- __Affirming__. This is the most favorable result. It is given when the evidence in the attestation token shows a good match against the expectations of a trustworthy system. +- __Warning__. This is a less favorable result. It is given when the attestation token does not show a good match against the expectations of a trustworthy system. +- __None__. This is an unfavorable result, meaning that no comparison was possible, either because data was missing from the evidence in the attestation token, or because the verification service does not have any expectations to compare the evidence against, and is therefore unable to draw any conclusion. +- __Contraindicated__. This is the least favorable result. It is given when the evidence in the attestation token specifically contradicts the expectations of a trustworthy system. You will also notice that the result is grouped into two sections known as submodules, and indicated with the `submod()` notation. Recall from the earlier steps that the CCA attestation token is grouped into two parts: the _realm_ token and the _platform_ token. This same grouping is therefore also reflected in the attestation result. There are separate results for each. diff --git a/content/learning-paths/servers-and-cloud-computing/mongodb/replica.md b/content/learning-paths/servers-and-cloud-computing/mongodb/replica.md index 1cbcb96ac..dd3cb518f 100644 --- a/content/learning-paths/servers-and-cloud-computing/mongodb/replica.md +++ b/content/learning-paths/servers-and-cloud-computing/mongodb/replica.md @@ -126,7 +126,7 @@ setParameter: - **port:** 27017 is the port used for replica sets - **maxIncomingConnections:** The maximum number of incoming connections supported by MongoDB -**setParameter:** Addtional options +**setParameter:** Additional options - **diagnosticDataCollectionDirectorySizeMB:** 400 is based on the docs. - **honorSystemUmask:** Sets read and write permissions only to the owner of new files - **lockCodeSegmentsInMemory:** Locks code into memory and prevents it from being swapped. diff --git a/content/learning-paths/smartphones-and-mobile/_index.md b/content/learning-paths/smartphones-and-mobile/_index.md index ace5d6e30..42d4a2214 100644 --- a/content/learning-paths/smartphones-and-mobile/_index.md +++ b/content/learning-paths/smartphones-and-mobile/_index.md @@ -10,14 +10,14 @@ key_ip: - Mali maintopic: true operatingsystems_filter: -- Android: 24 -- Linux: 22 -- macOS: 10 -- Windows: 10 +- Android: 25 +- Linux: 20 +- macOS: 8 +- Windows: 8 subjects_filter: - Gaming: 6 - Graphics: 4 -- ML: 9 +- ML: 8 - Performance and Architecture: 24 subtitle: Optimize Android apps and build faster games using cutting-edge Arm tech title: Smartphones and Mobile @@ -39,20 +39,21 @@ tools_software_languages_filter: - CCA: 1 - Clang: 9 - CMake: 1 -- Coding: 18 +- Coding: 16 - Fixed Virtual Platform: 1 - Frame Advisor: 1 - GCC: 10 - GenAI: 1 - GoogleTest: 1 - Java: 4 -- Kotlin: 4 +- Kotlin: 5 - LiteRT: 1 - llvm-mca: 1 -- MediaPipe: 1 +- MediaPipe: 2 - Memory Bug Report: 1 - Memory Tagging Extension: 1 - Mobile: 6 +- mobile: 1 - NDK: 1 - NEON: 1 - ONNX Runtime: 1 @@ -66,6 +67,7 @@ tools_software_languages_filter: - Trusted Firmware: 1 - Unity: 6 - Unreal Engine: 2 +- VS Code: 1 - Vulkan: 2 - XNNPACK: 1 weight: 3 diff --git a/content/learning-paths/smartphones-and-mobile/profiling-ml-on-arm/nn-profiling-general.md b/content/learning-paths/smartphones-and-mobile/profiling-ml-on-arm/nn-profiling-general.md index bf64ce044..a25bbb072 100644 --- a/content/learning-paths/smartphones-and-mobile/profiling-ml-on-arm/nn-profiling-general.md +++ b/content/learning-paths/smartphones-and-mobile/profiling-ml-on-arm/nn-profiling-general.md @@ -13,6 +13,6 @@ With general profilers this is hard to do, as there needs to be annotation insid Depending on the model you use, your choice of tools will vary. For example, if you are using LiteRT (formerly TensorFlow Lite), Arm provides the Arm NN delegate that you can run with the model running on Linux or Android, CPU or GPU. -Arm NN in turn provides a tool called ExecuteNetwork that can run the model and provide layer timings, amongst other useful information. +Arm NN in turn provides a tool called ExecuteNetwork that can run the model and provide layer timings. If you are using PyTorch, you will probably use ExecuTorch, which is the on-device inference runtime for your Android phone. ExecuTorch has a profiler available alongside it.