# AM62x SK 開發問題

PRU開發
https://community.element14.com/products/devtools/single-board-computers/next-genbeaglebone/b/blog/posts/beaglebone-pru---timer-functionality

### AM625：更改 CPU 頻率
時間：2022-09-03
CPU頻率在哪裡改？似乎在.dts中沒有。如何支持.dts 中的配置？

在 AM62x 上的 Linux 中更改 CPU 頻率將通過 Linux CPUFreq 框架。這將在下一個處理器 SDK v8.4 中得到支持。

### 讀取cpu使用頻率
root@am62xx-evm:/usr/bin# k3conf --cpuinfo

| VERSION| INFO |
|--------|------------------------------------------------------------------------|
| K3CONF | (version v0.1-54-g966a569 built Mon May 30 17:22:25 UTC 2022) |
| SoC | AM62X SR1.0 |
| SYSFW | ABI: 3.1 (firmware version 0x0008 '8.3.2--v08.03.02 (Jolly Jellyfi)') |

| Processor Name | Processor State | Processor Frequency |
|----------------|-----------------|-----------------------|
| A53SS0_CORE_0 | DEVICE_STATE_ON | 1200000000 |
| A53SS0_CORE_1 | DEVICE_STATE_ON | 1200000000 |
| A53SS0_CORE_2 | DEVICE_STATE_ON | 1200000000 |
| A53SS0_CORE_3 | DEVICE_STATE_ON | 1200000000 |
|--------------------------------------------------------|

# 研究PRU文件在：
Chapter 7 Processors and Accelerators
7.2 Device Manager Cortex R5F Subsystem (WKUP_R5FSS)
This chapter
7.3 Cortex-M4F Subsystem (MCU_M4FSS)
7.4 Programmable Real-Time Unit and Industrial Communication Subsystem

# PRU Subsystem
=============
https://software-dl.ti.com/processor-sdk-linux/esd/AM62X/08_03_00_19/exports/docs/linux/Foundational_Components_PRU_Subsystem.html

The issue is with the projectspecs. They need to be updated to use "Cortex M.AM62x.AM62x_SK_EVM". The Sitara team has been notified of this issue.

### 明確一點：目前為 AM62x 啟用的 RPMsg IPC 介於 A53 內核 (Linux) 和 M4F 內核（FreeRTOS 或 NORTOS）之間。

### **PRU **
PRU 子系統中的 PRU 內核與 R5F 不同。有關 PRU 的更多詳細信息，請參閱數據表、TRM 和 Linux SDK 文檔。
如果您查看 MCU+ SDK 發行說明，您將看到 M4F 內核支持哪些功能。M4F 不支持加載和與 PRU 通信：  [https ://software-dl.ti.com/mcu-plus-sdk/esd/AM62X/08\_03\_00\_07/exports/docs/api\_guide\_am62x/RELEASE\_NOTES\_08\_03\_00\_PAGE.html](https://software-dl.ti.com/mcu-plus-sdk/esd/AM62X/08_03_00_07/exports/docs/api_guide_am62x/RELEASE_NOTES_08_03_00_PAGE.html)

#### **AM62x R5F 怎麼樣？ **
AM62x R5F 是一款專用設備和電源管理器。我們不在 AM62x 上啟用 R5F 開發。有關詳細信息，請參閱數據表。

[4\. IPC for AM62x — Processor SDK AM62x Documentation](https://software-dl.ti.com/processor-sdk-linux/esd/AM62X/08_03_00_19/exports/docs/linux/Foundational_Components_IPC62x.html)

### **Linux 內核**

Linux 是一種高級操作系統 (HLOS)。它比 RTOS 更複雜。雖然 Linux 對於許多用例（例如，人機交互 (HMI)）來說是一個很好的設計選擇，但操作系統的複雜性意味著它可能需要比 RTOS 更長的時間來完成一項任務。此外，Linux 完成一項任務所需的時間可能會有所不同（即，Linux 是不確定的）。

一般來說，我們不建議在處理鏈中使用 Linux 內核來實現循環時間較短的控制循環。例如，AM64x 電機控制應用程序可能僅在電機控制迴路中使用 PRU_ICSSG 和 R5F 內核，然後使用 Linux 在控制迴路之外更新 HMI。這是因為如果電機控制計算延遲以致系統錯過循環時間，則可能會出現故障。相比之下，如果用戶的觸摸屏延遲更新 0.5 毫秒，則不會發生任何不良情況。

但是，如果設計絕對需要一個 Linux 內核來控制循環怎麼辦？

**使用 RT Linux **

如果 Linux 內核必須在控制迴路中，請使用 RT Linux 而不是常規 Linux。RT Linux 已被修改為比常規 Linux 更實時。然而，RT Linux 並不是真正的 RTOS！流程完成所需時間比預期更長的邊緣情況將會減少，但邊緣情況可能仍然存在。RT Linux 不能保證會滿足時間要求。

客戶有責任對 RT Linux 進行嚴格測試，以確保它在長時間的測試中滿足他們的用例。這些測試可以證明邊緣情況在統計上是不可能的。然而，觀察到 RT Linux 不太可能錯過計時並不等於保證它永遠不會錯過計時。

**了解系統的中斷響應時間 **

大多數情況下，當 Linux 涉及到控制循環時，我們需要關心中斷響應時間。

當我們查看向 Linux 內核發送郵箱或中斷的延遲時，它看起來像這樣：
RTOS/Bare metal core 寫入郵箱或中斷 --> 郵箱或中斷通過處理器的信號延遲 -->中斷響應時間（Linux 收到中斷，到達當前任務的停止點，上下文切換以存儲當前任務的數據，並切換到中斷處理程序）

即使 Linux 內核定期輪詢更新而不是等待中斷，中斷響應時間也會影響系統。假設我們有一個高優先級的 Linux 應用程序，它每 250 uS 輪詢一個遠程核心以獲取數據。（例如 [https://www.ti.com/tool/TIDA-01555](https://www.ti.com/tool/TIDA-01555)。Linux 代碼位於 [https://git.ti.com/cgit/apps/tida01555/tree/ARM\_User\_Space\_App/arm\_user\_space\_app.c](https://git.ti.com/cgit/apps/tida01555/tree/ARM_User_Space_App/arm_user_space_app.c)）。輪詢之間的時間實際上略高於 250 uS。這是因為時間受到中斷響應時間的影響：
nanosleep 啟動後台定時器，應用程序休眠 --> Linux 切換到不同的線程 --> 定時器中斷在 250 uS 後關閉 --> 中斷響應時間 --> Linux 返回到用戶空間應用程序

好的，所以中斷響應時間會影響 IPC 延遲。您的系統需要計劃什麼樣的中斷響應時間？

Linux 是如此復雜，以至於無法創建預測中斷響應時間的理論模型。確定係統中斷響應時間的最佳方法是生成與您的設計類似的 Linux 構建，然後運行測試以通過實驗確定可以預期的延遲。Cyclictest 提供了一個很好的起點。例如，AM64x SDK 8.1 的開箱即用循環測試結果如下：  [https ://software-dl.ti.com/processor-sdk-linux/esd/AM64X/08\_01\_00_39/exports/docs/devices/ AM64X/RT\_Linux\_Performance_Guide.html#maximum-latency-under-different-use-cases](https://software-dl.ti.com/processor-sdk-linux/esd/AM64X/08_01_00_39/exports/docs/devices/AM64X/RT_Linux_Performance_Guide.html#maximum-latency-under-different-use-cases)  。

對於 AM64x Linux SDK 8.1，觀察到的 RT Linux 內核最壞情況中斷響應時間為 72 uS。如果我正在對系統進行原型設計並將其作為最壞情況的結果，那麼我的控制迴路設計需要考慮此中斷響應時間。

關於 cyclictest 的其他說明：
\* SDK 數字的延遲以微秒 (uS) 為單位
\* 性能指南測試使用 create_cgroup 將盡可能多的任務從 RT 核心移動到非 RT 核心。但是，有些 Linux 任務不會從一個內核轉移到另一個內核。這些任務可以繼續在最壞情況下的最大延遲中發揮作用\* 您可以在[https://e2e.ti.com/support/processors-group/processors/f/processors-forum](https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1033771/am6442-latency-in-linux-rt-is-well-above-expected-values/3835092#3835092)
找到有關運行 cyclictest 的更多討論 [/1033771/am6442-latency-in-linux-rt-is-well-above-expected-values/3835092#3835092](https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1033771/am6442-latency-in-linux-rt-is-well-above-expected-values/3835092#3835092) 
\* 不同的 Linux 版本將具有不同的線程，從而導致不同的最大延遲。一種選擇是從最小構建開始（例如，在 filesystem/ 下的 AM64x Linux SDK 中找到的微型文件系統），查看循環測試結果，然後查看延遲如何隨著您添加系統所需的其他 Linux 功能而變化。設計需要在實時任務的需求與更廣泛系統所需的系統調用和服務之間找到折衷。

**我可以繞過中斷響應時間嗎？**

以下想法是假設性的。TI 沒有對其進行測試，我們不一定推薦它們。這只是為了幫助客戶考慮他們的選擇。

如果 A53 內核不斷地從內存位置讀取，則沒有中斷響應時間。從 R5F 內核通知 Linux 內核的總延遲減少到

R5F 寫入內存位置 --> A53 Linux 從內存位置讀取延遲

那可能嗎？

一種選擇是進行兩階段通知：使用中斷、RPMsg 或更長的輪詢時間來告訴 Linux 內核何時需要開始觀察低延遲消息。一旦 Linux 知道低延遲消息即將到來，那麼 Linux 就會不斷地讀取內存位置，而不允許任何其他線程在 Linux 內核上運行，直到 R5F 寫入發生。

AM64x A53 內核是雙核。因此，另一種選擇是隔離 A53 內核，並將一個內核專門用於讀取內存位置，直到收到消息。此選項的缺點是，所有其他 Linux 應用程序的計算能力都會減半。 

但是，系統設計人員還需要牢記其他挑戰。對於兩階段通知選項，持續的內存讀取需要有一個超時機制，以確保 Linux 不會餓死所有其他線程。如果線程在低延遲通知發生之前超時怎麼辦？然後可能會出現 Linux 內核沒有及時響應 R5F 內核通知的邊緣情況。

即使我們將一個核心專門用於讀取共享內存位置，也存在問題。如果您將線程優先級設置得足夠高，則可以阻止大多數其他線程在 Linux 內核上運行……除了 archtimer（在我們有限的實驗中）。並且當archtimer 獲得控制權時，用戶空間應用程序不會讀取中斷響應時間-> archtimer 應用程序-> 上下文切換回用戶空間應用程序所需的時間。如果在 archtimer 處於控制狀態時發送通知，這是系統可能無法滿足循環時間要求的另一個極端情況。