欧美性猛交xxxx免费看_牛牛在线视频国产免费_天堂草原电视剧在线观看免费_国产粉嫩高清在线观看_国产欧美日本亚洲精品一5区

0
  • 聊天消息
  • 系統(tǒng)消息
  • 評論與回復(fù)
登錄后你可以
  • 下載海量資料
  • 學(xué)習(xí)在線課程
  • 觀看技術(shù)視頻
  • 寫文章/發(fā)帖/加入社區(qū)
會員中心
創(chuàng)作中心

完善資料讓更多小伙伴認(rèn)識你,還能領(lǐng)取20積分哦,立即完善>

3天內(nèi)不再提示

基于ARM架構(gòu)的PSCI接口規(guī)范

jf_0tjVfeJz ? 來源:嵌入式ARM和Linux ? 作者:嵌入式ARM和Linux ? 2022-11-07 10:48 ? 次閱讀

1 介紹

本文主要是在ARM架構(gòu)的不同異常等級上工作的軟件之間,提供一個(gè)標(biāo)準(zhǔn)的電源管理接口。這些軟件,比如Linux、Hypervisor、安全Firmware和可信OS之間必須能夠?qū)崿F(xiàn)互相操作。而這些軟件可能由不同廠商提供,本標(biāo)準(zhǔn)就是為這些軟件的集成提供便利。

這些PSCI接口有利于電源管理代碼通用化、模塊化:

CPU核的空閑管理

CPU核的動態(tài)添加、刪除,以及輔核引導(dǎo)

系統(tǒng)關(guān)機(jī)和復(fù)位

該接口規(guī)范不會包含動態(tài)電壓頻率調(diào)節(jié)(DVFS)或設(shè)備電源管理(比如,GPU等外設(shè)的管理).

該接口規(guī)范設(shè)計(jì)用來與硬件探測技術(shù)(如ACPI和FDT)等配合使用,并不是要取代ACPI或FDT。

本文描述了PSCI版本1.1,1.0和0.2。對于0.2,還提供了一個(gè)勘誤更新。

本文包含以下內(nèi)容:

第1章 提供介紹和文檔引用

第2-4章 提供背景知識,包括:

PSCI的設(shè)計(jì)目的

電源狀態(tài)術(shù)語的定義

發(fā)送PSCI請求的方法

ARM架構(gòu)知識

第5章 提供PSCI功能的主要描述

第6章 提供PSCI功能的實(shí)現(xiàn)細(xì)節(jié)

第7-8章 提供PSCI規(guī)范的修訂歷史和術(shù)語表

1.1 ARM官方文檔

下面這些文檔包含與本文檔相關(guān)的信息

[1] ARM Architecture Reference Manual ARMv7-A and ARMv7-R edition (ARM DDI 0406).

[2] Embedded Trace Macrocell Architecture Specification (ARM IHI 0014).

[3] Program Flow Trace Architecture Specification (ARM IHI 0035).

[4] SMC調(diào)用約定(ARM DEN 0028).

[5] ARM Architecture Reference Manual ARMv8, for ARMv8-A architecture profile (ARM DDI 0487).

[6] ACPI規(guī)范.

[7] PSCI設(shè)備樹定義.

[8] ARM可信固件(ATF).

[9] Power Control System Architecture Specification (ARM DEN 0050).

2 背景知識

支持電源管理的操作系統(tǒng),能夠動態(tài)改變CPU核的電源狀態(tài),根據(jù)進(jìn)行負(fù)載均衡,努力降低功耗。電源管理技術(shù)主要分為兩類:

空閑管理:當(dāng)在某個(gè)核上,OS的內(nèi)核沒有線程可以調(diào)度時(shí),可以將該核置于clock-gated、retention、power-gated狀態(tài)。但是,該核對于OS而言還是可用的。

Hotplug熱插拔:根據(jù)對算力的需求變化,而將CPU核置于離線、在線。離線時(shí),OS負(fù)責(zé)將所有中斷和線程從核上遷移走;當(dāng)在線時(shí),OS負(fù)責(zé)重新進(jìn)行負(fù)載均衡。

盡管由單個(gè)供應(yīng)商提供嵌入式系統(tǒng)的軟件可能更簡單,但事實(shí)并非如此。為了安全,ARM將硬件架構(gòu)劃分為4個(gè)不同的異常級(EL)以及2個(gè)安全狀態(tài),以便支持不同特權(quán)的軟件分區(qū)。

下表是基于ARM架構(gòu)的硬件平臺上的軟件劃分:

AArch32 AArch64 軟件和供應(yīng)商
NS_EL0 (PL0) NS_EL0 非特權(quán)應(yīng)用,如APP
NS_EL1 (PL1) NS_EL1 富操作系統(tǒng)內(nèi)核,如Linux、Windows、iOS
NS_EL2 (PL2) NS_EL2 Hypervisor(Citrix、VMWare、OK-Labs)
S_EL0 (PL0) S_EL0 可信OS的應(yīng)用
S_EL3 (PL1) S_EL1 可信OS的內(nèi)核(Trustonic)
S_EL3 (PL1) S_EL3 安全Monitor,執(zhí)行安全固件(ATF)

AArch32是ARMv8架構(gòu)的32位執(zhí)行狀態(tài),在ARMv8架構(gòu)之前采用的執(zhí)行狀態(tài)。在ARMv7處理器中,異常級的概念是隱含的,相關(guān)文檔也并未說明。那時(shí)候,虛擬化擴(kuò)展提供EL2功能,安全擴(kuò)展提供EL3功能,安全狀態(tài)由特權(quán)級(PL-Privilege Level)標(biāo)識異常的層次結(jié)構(gòu)。更多信息,參考第3.2節(jié)。

因?yàn)椴煌?yīng)商的不同操作系統(tǒng)都可運(yùn)行在ARM系統(tǒng)上,電源管理就需要一個(gè)協(xié)作的方法??紤]到運(yùn)行在EL1上的類OS軟件或運(yùn)行在EL2上的hypervisor軟件,一般處于非安全狀態(tài),如果想要進(jìn)入idle狀態(tài)、給一個(gè)核上電或掉電、或復(fù)位或關(guān)閉系統(tǒng),更高異常級的監(jiān)控軟件必須能夠響應(yīng)這種電源狀態(tài)變化的請求。

同樣,如果某個(gè)wakeup事件改變了核的電源狀態(tài),那么這些監(jiān)管軟件需要執(zhí)行諸如恢復(fù)上下文之類的操作。PSCI提供了不同監(jiān)管軟件之間互操作和集成的標(biāo)準(zhǔn)接口定義。本文檔會詳細(xì)描述這類接口,以及在idle、hotplug、shutdown和reset情況下如何使用它們。

3 假設(shè)和建議

本文檔定義了在不同監(jiān)管軟件之間協(xié)調(diào)電源管理的API。這種API允許監(jiān)管軟件請求給核上電、掉電,安全上下文的核間遷移(可信OS需要)。本文中,假設(shè)EL2和EL3都已經(jīng)實(shí)現(xiàn)。

3.1 PSCI用途

PSCI具有下面的用途:

提供給監(jiān)控程序通用接口,可以在下列情況時(shí),管理功耗:

CPU核的空閑管理;

系統(tǒng)中的CPU核動態(tài)添加和刪除,也稱之為hotplug熱插拔;

其它輔核的啟動;

將受信任的操作系統(tǒng)上下文從一個(gè)核遷移到另一個(gè)核;

系統(tǒng)關(guān)機(jī)和復(fù)位。

提供給監(jiān)控管理程序通用接口,結(jié)合FDT和ACPI描述去支持電源管理代碼的泛化。

PSCI不包括:外設(shè)電源管理 和 動態(tài)電壓和頻率調(diào)節(jié)(DVFS)。

PSCI不提供給監(jiān)控軟件電源狀態(tài)表示。但是,可以和ACPI或FDT等硬件描述技術(shù)結(jié)合使用。

3.2 異常級別、ARMv7特權(quán)級別和最高特權(quán)級別

ARMv8架構(gòu)明確提出了EL的概念,也定義了安全狀態(tài)下軟件執(zhí)行特權(quán)的層次結(jié)構(gòu)。

ARMv7架構(gòu)中,EL概念是隱含在架構(gòu)體系中的:

虛擬化擴(kuò)展提供了EL2的功能(只存在非安全狀態(tài)下)。

安全擴(kuò)展提供了EL3功能,包含對兩種安全狀態(tài)的支持??刂剖窃贛onitor模式下完成的,該模式也只存在于安全狀態(tài)下。

ARMv7使用PL(特權(quán)級)的概念描述軟件執(zhí)行的特權(quán)層級結(jié)構(gòu)。因?yàn)镸onitor模式的存在,ARMv7的非安全狀態(tài)和安全狀態(tài)是非對稱的,如下所述:

非安全狀態(tài),特權(quán)層次結(jié)構(gòu)是:

PL0, 非特權(quán),適用于User模式

PL1, OS級特權(quán),適用于System, FIQ, IRQ, Supervisor, Abort和Undefined模式

PL2, hypervisor特權(quán),適用于Hyp模式

安全狀態(tài),特權(quán)層次結(jié)構(gòu)是:

Secure PL0, 非特權(quán),僅適用于User模式

Secure PL1, 可信OS和Monitor級特權(quán),適用于System, FIQ, IRQ, Supervisor, Abort, Undefined和Monitor模式

AArch32執(zhí)行狀態(tài)下,異常級和之前的運(yùn)行模式對應(yīng)關(guān)系如下:

非安全狀態(tài):

EL0: User 模式

EL1: System, FIQ, IRQ, Supervisor, Abort和Undefined模式

EL2: Hyp模式

安全狀態(tài):

Secure EL0: User 模式

EL3: System, FIQ, IRQ, Supervisor, Abort, Undefined和Monitor模式

本文檔中如果不特殊聲明,則使用異常級別(EL)的術(shù)語:

通常情況下,提及的EL1和EL0就是指非安全EL1和EL0,除非有特殊說明;

3.3 ARM架構(gòu)上的軟件棧

ARM設(shè)備上可能有的軟件棧,如下所示:

ffae332e-5dcb-11ed-a3b6-dac502259ad0.png

如圖所示,非安全空間中的擁有特權(quán)的代碼:

Rich-OS內(nèi)核:比如,Linux或Windows,運(yùn)行在非安全EL1。如果運(yùn)行在Hypervisor之上,則Rich-OS內(nèi)核作為hypervisor的一個(gè)客戶機(jī)運(yùn)行。

Hypervisor:運(yùn)行在EL2,只有非安全狀態(tài)(新ARMv8架構(gòu)中,已經(jīng)存在安全狀態(tài)的hypervisor)。

安全空間中擁有特權(quán)的代碼:

安全平臺固件(SPF):

芯片或OEM廠商提供。也是系統(tǒng)啟動階段,運(yùn)行的第一段程序。它提供的服務(wù)有,平臺初始化、可信OS的安裝、SMC調(diào)用的調(diào)度執(zhí)行。有些調(diào)用的目標(biāo)可能是SPF,另一些則可能是可信OS。SPF可以運(yùn)行在EL3,也可以運(yùn)行在安全EL1(但是,條件是EL3運(yùn)行在AArch64狀態(tài))。ARM提供了一個(gè)開源的可信固件代碼。

可信OS:

為normal空間提供安全服務(wù),即為安全應(yīng)用提供一個(gè)運(yùn)行時(shí)環(huán)境。在AArch32狀態(tài)下,可信OS運(yùn)行在安全EL3,如果是AArch64狀態(tài),運(yùn)行在EL1。

PSCI規(guī)范主要關(guān)注安全、非安全世界之間的電源管理接口。它提供了發(fā)送電源管理請求的方法。所以,為了處理這些請求,SPF必須包含PSCI實(shí)現(xiàn)。

另外,PSCI實(shí)現(xiàn)也可能需要在SPF和可信OS之間建立通信。當(dāng)然,它們之間的處理根據(jù)廠商不同而有所不同。

盡管,PSCI主要關(guān)注安全和非安全世界之間的電源管理請求,但是,也可以在Rich OS和hypervisor之間使用。

3.4 通道

在不同的異常級別之間提供可以傳送消息的通道(一般使用SMC異常指令實(shí)現(xiàn)),這樣才能提供相同的PSCI電源管理接口。具體參考SMCCC。

3.5 安全軟件和電源管理

許多可信OS不支持SMP。即使在多核平臺上,也是運(yùn)行在某個(gè)指定的核上。所以,期望發(fā)起SMC調(diào)用的核與可信OS運(yùn)行的核是同一個(gè)。不支持多核,可以保證可信OS小而美,容易通過功能安全認(rèn)證。

基于ARM架構(gòu)的系統(tǒng)通常會包含一個(gè)電源控制器,或者電源管理電路,以便管理CPU核的電源。它會提供許多電源管理功能,比如將核、簇或者集群轉(zhuǎn)變?yōu)榈凸臓顟B(tài)。在低功耗狀態(tài),核可以完全關(guān)掉,也可以不執(zhí)行代碼而處于靜默狀態(tài)。ARM 強(qiáng)烈推薦由安全空間控制電源狀態(tài)的變化。否則,在進(jìn)入低功耗狀態(tài)之前,不能清除安全狀態(tài)(包括安全cache的清零)。其它的電源管理,比如動態(tài)電源性能管理(通過調(diào)節(jié)電壓和頻率實(shí)現(xiàn))不在本接口規(guī)范的范圍內(nèi)。

3.6 虛擬化和CPU核電源管理策略

虛擬機(jī)可以分為兩種類型

Type-1: 有時(shí)候稱為 native 或 bare metal。通俗理解的話,就是hypervisor代碼直接接管硬件,對上提供統(tǒng)一的虛擬隔離空間。所以,Guest OS看到的都是虛擬設(shè)備。

Type-2: 有時(shí)候稱為hosted,或者托管類型hypervisor。這類虛擬程序需要依賴一個(gè)主機(jī)OS,作為宿主。該Host OS看到的是真實(shí)硬件,但是Guest OS看到的是虛擬設(shè)備。

這是一個(gè)泛泛的分類,可能會有許多變種。ARMv8架構(gòu)允許在EL1或EL2運(yùn)行一個(gè)Type-2類型的hypervisor,這更加模糊了類型-1和類型-2的差異。但是,對于電源管理來說,不論哪種類型的hypervisor,都需要捕獲這種PSCI調(diào)用。

從電源管理和虛擬化的角度來看的話,有兩種類型的OSPM:

物理OSPM: 這個(gè)概念包含管理物理電源狀態(tài)的軟件。

虛擬OSPM: 這是存在于虛擬機(jī)的Guest OS中的OSPM,它管理的是虛擬的,而不是物理電源狀態(tài)。

對于type-2 hypervisor,物理OSPM存在于主機(jī)OS中。電源管理策略由運(yùn)行在EL1的Rich OS負(fù)責(zé)管理。物理OSPM就包含在這種Rich OS中。在該層,直接擁有物理核的視角。下圖的左邊部分就是示例。

ffdc6fd2-5dcb-11ed-a3b6-dac502259ad0.png

對于本文涉及的電源管理,type-2 hypervisor的行為取決于調(diào)用者。如果調(diào)用者是Host OS,hypervisor允許調(diào)用直接穿透到安全平臺固件(SPF)。在這種情況下,hypervisor只需執(zhí)行必要的操作,比如保存powerdown時(shí)的狀態(tài)。然后,使用調(diào)用者傳遞過來的參數(shù)調(diào)用SPF。如果沒有特殊操作,hypervisor甚至不會捕獲來自Host OS的調(diào)用,直接將其路由給SPF。Guest OS使用虛擬OSPM,也是通過PSCI API發(fā)出電源管理請求,但是發(fā)送的目標(biāo)是虛擬核和虛擬電源狀態(tài)。hypervisor會捕獲這些請求,然后將其發(fā)送到物理OSPM。然后,由物理OSPM決定是否請求真實(shí)的物理電源管理。對于虛擬機(jī)來說,電源管理到hypervisor就結(jié)束了。

對于type-1 hypervisor,電源管理策略通常是hypervisor自身管理的。如上圖右半部分所示。hypervisor實(shí)現(xiàn)物理OSPM模塊。這種情況下,虛擬機(jī)擁有的是虛擬核。由hypervisor決定虛擬機(jī)的虛擬電源狀態(tài)是否請求物理電源控制,如果需要,則使用PSCI API調(diào)用安全平臺固件SPF。同樣,Guest OS也使用PSCI API接口將虛擬電源管理請求發(fā)送給hypervisor。對于虛擬機(jī)來說,電源管理到hypervisor就結(jié)束了。

在某些情況下,type-1 hypervisor委托一個(gè)特權(quán)Guest OS管理電源。這種情況下,物理OSPM在特權(quán)Guest OS中實(shí)現(xiàn)。大概的電源管理方法與type-2 hypervisor類似。

4 PSCI使用場景和要求

4.1 空閑管理

當(dāng)一個(gè)核處于idle狀態(tài)時(shí),OSPM將其置于低功耗狀態(tài)。通常,選擇進(jìn)入不同的電源狀態(tài),會有不同的entry和exit延遲,也會有不同的功耗。想要進(jìn)入哪種電源狀態(tài),依賴于核重新工作的時(shí)間。除了核之外,電源狀態(tài)也可能依賴于SoC中的其它組件的活動。每種狀態(tài)都由一組組件的狀態(tài)共同決定,進(jìn)入該狀態(tài)時(shí),這些組件通過時(shí)鐘控制(clock-gated)或電源控制(power-gated)。這些狀態(tài)有時(shí)候也描述為淺睡眠或深度睡眠。通常,文獻(xiàn)描述使用X標(biāo)識深度睡眠,Y標(biāo)識淺睡眠:

X狀態(tài)應(yīng)該是Y狀態(tài)的超集。

X狀態(tài)比Y狀態(tài)更省電。

從低功耗狀態(tài)進(jìn)入運(yùn)行狀態(tài)所需要的時(shí)間稱為喚醒延遲。通常,深度睡眠狀態(tài)具有更長的喚醒延遲。

盡管空閑電源管理是由核上的線程行為引起的,但是OSPM將硬件平臺設(shè)置的狀態(tài),也可能會影響除CPU核之外的其它組件。比如,如果SoC中的最后一個(gè)核進(jìn)入idle狀態(tài),OSPM就可以考慮整個(gè)SoC的電源狀態(tài)了。此時(shí)的選擇也會受系統(tǒng)中的其它組件影響,所以,應(yīng)該在SPF、hypervisor、OS之間協(xié)調(diào)電源管理。典型的例子是,當(dāng)所有核,和其它請求者都處于空閑狀態(tài)時(shí),將系統(tǒng)置于一種狀態(tài),在這種狀態(tài)下,將上下文保存在內(nèi)存中(內(nèi)存不斷刷新中)。OSPM必須提供必要的電源管理軟件基礎(chǔ)設(shè)施,確定能夠?qū)﹄娫礌顟B(tài)作出正確的選擇。

在空閑管理中,當(dāng)一個(gè)核被置于低功耗狀態(tài),它可能隨時(shí)被喚醒事件激活,比如說中斷。

ARM架構(gòu)劃分的電源狀態(tài)有四種:

Run

CPU核上電,且可以正常運(yùn)行的狀態(tài)。

Standby

CPU核上電。通過WFI或WFE指令進(jìn)入該狀態(tài),由喚醒事件喚醒。此過程中,CPU核保持所有狀態(tài)。也就是說,從standby到run狀態(tài),不會復(fù)位CPU核。CPU核的上下文都會被保持,喚醒即可訪問這些內(nèi)容。處于該核所在電源域的外部調(diào)試器(debugger),能夠訪問debug寄存器。換句話說,standby狀態(tài)不會影響調(diào)試器的使用。

Retention

CPU核的狀態(tài),包括debug設(shè)置等,保存在低功耗的保持寄存器中,這樣允許CPU核至少可以關(guān)閉部分電源。從低功耗狀態(tài)到運(yùn)行態(tài)的轉(zhuǎn)變,不用復(fù)位CPU核。低功耗轉(zhuǎn)變到運(yùn)行態(tài)時(shí),原先保存的狀態(tài)數(shù)據(jù)從保持寄存器中恢復(fù)。所以,從OS的角度來說,Retention和Standby狀態(tài)沒有什么差別,除了恢復(fù)時(shí)的入口地址,延遲和使用上的一些限制之外。但是,對于外部debugger來說,就不一樣了,外部debug請求事件會被掛起,debug寄存器無法訪問。

Powerdown

該狀態(tài)下,CPU核會被掉電。軟件需要保存所有的核狀態(tài)數(shù)據(jù)。從掉電到恢復(fù)運(yùn)行,需要:

上電后,需要復(fù)位CPU核

恢復(fù)之前保存的核的狀態(tài)數(shù)據(jù)

Powerdown狀態(tài)對上下文是破壞性的。不僅僅是CPU核的狀態(tài)數(shù)據(jù),如果是更深的休眠狀態(tài),可能包括GIC或者平臺依賴的其它一些IP核也會掉電。所以,相關(guān)數(shù)據(jù)或狀態(tài)必須保存。根據(jù)debug和trace電源域的組織架構(gòu),其上下文內(nèi)容也有可能會丟失。所以,OS必須提供保存和恢復(fù)這些內(nèi)容的機(jī)制。

對于OS來說,standby和retention都是一樣的,除了debugger之外。所以,后面我們使用standby代表這兩種狀態(tài)。

ARM期望在具有最高特權(quán)的異常級別上,實(shí)現(xiàn)管理電源控制器的代碼(通常就是ATF)。那么就必須提供接口,以便OSPM將CPU核置于低功耗狀態(tài)的消息事件,從不同的異常級層層往下傳遞(假設(shè)越往下,異常級別越高)。而PSCI就是這樣的一種機(jī)制,將OSPM的電源請求傳遞給下一個(gè)異常級EL。

對于standby狀態(tài),直接使用WFI或WFE指令即可進(jìn)入。但是,更深層的standby或retention狀態(tài),則要求對電源控制器進(jìn)行編程,而PSCI僅提供訪問電源控制器的接口,并隱藏了與平臺相關(guān)的代碼。

對于Powerdown狀態(tài),則要求提供每一級EL下保存和恢復(fù)上下文的接口。而且,對于Powerdown狀態(tài)還要求一個(gè)return地址。這地址是被喚醒時(shí),OS期望的開始運(yùn)行的地方。對于Powerdown狀態(tài),CPU核從reset復(fù)位向量(安全狀態(tài))開始運(yùn)行。待完成初始化,則跳轉(zhuǎn)到Powerdown之前要求的那個(gè)返回地址處開始執(zhí)行。PSCI提供了傳遞返回地址和上下文的參數(shù)。

4.2 電源狀態(tài)系統(tǒng)拓?fù)?/p>

多核系統(tǒng)中,不同的電源域控制系統(tǒng)的不同部分。每一個(gè)電源域可能是一個(gè)或多個(gè)PE(CPU核、協(xié)處理器、GPU),內(nèi)存(Cache、DRAM),簇內(nèi)、簇間一致性部件等組成。

電源域中的每個(gè)組件的電源狀態(tài),都可以影響電源域中的其它組件。雖然,從物理上來說,電源域不是一個(gè)必須存在的層次結(jié)構(gòu)。但是,從軟件的角度來說,必須進(jìn)行一個(gè)邏輯上的劃分。如果想要改變電源域的電源狀態(tài),必須對其依賴項(xiàng)進(jìn)行排序。比如,共享Cache的電源域,以及使用共享Cache的CPU核的電源域,它們之間的依賴關(guān)系。在這樣一個(gè)系統(tǒng)中,為了保證數(shù)據(jù)的一致性,必須先關(guān)閉CPU核的電源,然后再關(guān)閉共享Cache的電源。

fffe3630-5dcb-11ed-a3b6-dac502259ad0.png

上圖展示了一個(gè)系統(tǒng)級的電源域的拓?fù)浣Y(jié)構(gòu)的示例。它擁有兩個(gè)子電源域,每一個(gè)包含一個(gè)cluster簇,支持一組cluster電源狀態(tài)。每一個(gè)cluster電源域,又包含兩個(gè)子電源域,每一個(gè)包含一個(gè)CPU核,并額外支持一個(gè)電源狀態(tài)。

從硬件的角度來看,一個(gè)系統(tǒng)被劃分為多個(gè)單獨(dú)或共享的電源域。每個(gè)電源域都可以表示為電源域拓?fù)錁渲械囊粋€(gè)節(jié)點(diǎn)。兄弟電源域是互斥的。父電源域由子電源域共享。樹中的各種級別(示例中的核、cluster簇和系統(tǒng))稱為電源級別。較高的級別,更接近樹的根(系統(tǒng)),較低的級別更接近樹葉(核)。

4.2.1 局部電源狀態(tài)和組合電源狀態(tài)

上面拓?fù)浣Y(jié)構(gòu)中的各個(gè)節(jié)點(diǎn)都有自己的電源狀態(tài),我們稱為局部電源狀態(tài)。當(dāng)處于空閑核上的OS請求電源狀態(tài)的改變時(shí),不僅需要請求改變CPU核的局部電源狀態(tài),還需要請求改變父節(jié)點(diǎn)的電源狀態(tài)。比如,上圖的示例中,假設(shè)核1是簇0內(nèi)最后進(jìn)入空閑狀態(tài)的,對于OS來說,就需要同時(shí)為簇0和核1請求電源狀態(tài)改變。這種組合的電源狀態(tài)我們就稱為組合電源狀態(tài)。這種組合電源狀態(tài)可不是隨意組合的,而是電源等級越高的節(jié)點(diǎn)上,其電源狀態(tài)越淺。換句話說,子節(jié)點(diǎn)進(jìn)入休眠的程度應(yīng)該大于等于父節(jié)點(diǎn)。規(guī)則如下:

電源等級高的節(jié)點(diǎn)掉電(Powerdown),電源等級低的節(jié)點(diǎn)也必須掉電;

電源等級高的節(jié)點(diǎn)保持(Retention),電源等級低的節(jié)點(diǎn)只能是保持或掉電;

電源等級高的節(jié)點(diǎn)待機(jī)(Standby),電源等級低的節(jié)點(diǎn)只能是待機(jī)、保持或掉電;

電源等級高的節(jié)點(diǎn)運(yùn)行(Run),電源等級低的節(jié)點(diǎn)可以是任意狀態(tài)。

如下表所示:

系統(tǒng)級 簇級 核級
Run Run Standby
Run Run Retention
Run Run Powerdown
Run Retention Retention
Run Retention Powerdown
Run Powerdown Powerdown
Retention Retention Retention
Retention Retention Powerdown
Retention Powerdown Powerdown
Powerdown Powerdown Powerdown

4.2.2 親和力的層次結(jié)構(gòu)

ARM系統(tǒng)通常是多核、或多簇的處理器。本文檔使用親和力的層次結(jié)構(gòu)描述CPU核和簇的架構(gòu)關(guān)系。親和力層次結(jié)構(gòu)往往直接對應(yīng)系統(tǒng)的電源拓?fù)?,但這也不是絕對的。

4.2.3 電源狀態(tài)協(xié)調(diào)

高層的節(jié)點(diǎn)進(jìn)入某種局部電源狀態(tài),必須與子節(jié)點(diǎn)的電源狀態(tài)進(jìn)行協(xié)調(diào)。比如說,想要使一個(gè)簇(cluster)進(jìn)入Powerdown狀態(tài),那么該簇內(nèi)所有的核也必須進(jìn)入Powerdown狀態(tài)。實(shí)現(xiàn)方式就是,其它核都進(jìn)入Powerdown狀態(tài),最后一個(gè)核再把自己和簇置于Powerdown狀態(tài)。

對于這種對子節(jié)點(diǎn)的電源狀態(tài)進(jìn)行協(xié)調(diào)的方式,PSCI支持兩種:平臺協(xié)調(diào)模式、OS發(fā)起模式。

平臺協(xié)調(diào)模式

這是默認(rèn)的電源協(xié)調(diào)模式。在該模式下,PSCI實(shí)現(xiàn)者(如ATF等)負(fù)責(zé)協(xié)調(diào)電源狀態(tài)。當(dāng)某個(gè)核上沒有任務(wù)時(shí),OSPM為該核、以及所在簇請求允許范圍內(nèi)的最深休眠狀態(tài)。因?yàn)樵摵说碾娫礌顟B(tài)改變請求,可能影響其父節(jié)點(diǎn),所以,PSCI實(shí)現(xiàn)者得根據(jù)簇內(nèi)所有節(jié)點(diǎn)的情況選擇最深的休眠狀態(tài)。實(shí)際上,電源狀態(tài)請求表達(dá)了兩種限制:

PSCI實(shí)現(xiàn)就會根據(jù)這兩個(gè)限制,為指定的節(jié)點(diǎn)內(nèi)所有核,選擇一個(gè)最深的電源狀態(tài)。下表展示了OSPM請求不同的電源組合狀態(tài),而PSCI最終能夠響應(yīng)的狀態(tài)。假設(shè)簇1一直處于掉電狀態(tài)中。

001c3374-5dcc-11ed-a3b6-dac502259ad0.png

通常情況下,電源狀態(tài)越深,喚醒延遲越長。所以,我們假設(shè)保持狀態(tài)比掉電狀態(tài)具有更短的喚醒延遲。但是,事實(shí)并非如此。根據(jù)第2個(gè)限制,PSCI實(shí)現(xiàn)者必須滿足每個(gè)核喚醒時(shí)間的請求。假設(shè)雙核系統(tǒng),具有3層系統(tǒng)狀態(tài),狀態(tài)A、B、C,電源休眠程度A < B < C,而喚醒延遲則是A < C < B。如果核0選擇狀態(tài)B,而核1選擇狀態(tài)C,系統(tǒng)將會進(jìn)入狀態(tài)A。狀態(tài)B和C,不能同時(shí)滿足2個(gè)核的要求。

PSCI 1.0之前的版本只支持平臺協(xié)調(diào)模式。

調(diào)用者請求的電源狀態(tài)已經(jīng)是最深休眠狀態(tài)了;

調(diào)用者請求的電源狀態(tài)的喚醒延遲不能比這更長了;

OS協(xié)調(diào)模式

PSCI 1.0引入,這種模式將電源協(xié)調(diào)的權(quán)利交給了OS。這種模式下,只有節(jié)點(diǎn)內(nèi)的最后一個(gè)核進(jìn)入空閑狀態(tài),OSPM才會為該節(jié)點(diǎn)申請空閑狀態(tài)。

相比平臺協(xié)調(diào)方式,OS協(xié)調(diào)方式則是將怎么選擇最合適的休眠節(jié)點(diǎn)交給了OS,PSCI實(shí)現(xiàn)者只需實(shí)現(xiàn),給我什么請求,我就響應(yīng)什么動作即可。示例如下表所示:

005b2912-5dcc-11ed-a3b6-dac502259ad0.png

如表所示,我們可以看到OS視角和PSCI實(shí)現(xiàn)的視角有些不同的地方(紅色標(biāo)記)。這是因?yàn)镺S雖然請求了,但是PSCI實(shí)現(xiàn)還未響應(yīng)導(dǎo)致的。在上電的時(shí)候也會發(fā)生,因?yàn)镻SCI實(shí)現(xiàn)會比OS更早看到CPU核。為了實(shí)現(xiàn)OS協(xié)調(diào)方式,必須解決競爭問題。

PSCI實(shí)現(xiàn)必須懷疑與自己視角不一樣的電源狀態(tài)請求;

OS必須指明哪個(gè)核是最后一個(gè),而且還要指明該核處于哪一級電源中,如,是簇內(nèi)的最后一個(gè)核,還是系統(tǒng)內(nèi)最后的一個(gè)核。

4.3 CPU熱插拔和輔核啟動

CPU熱插拔的概念不需要再重復(fù)。但是,CPU熱插拔和空閑管理中的powerdown還是有一些差異:

當(dāng)核被拔出時(shí),監(jiān)控軟件會停止在中斷和線程處理中對該核的所有使用。調(diào)用監(jiān)控軟件認(rèn)為核不再可用。

想要使用該核,必須發(fā)送命令將核再插入。

喚醒事件不會喚醒被拔出的核。

操作系統(tǒng)通常在主核上完成內(nèi)核的引導(dǎo)過程,然后再啟動輔核。所以,對于支持熱插拔的系統(tǒng)來說,輔核的啟動和hotplug的操作是相同的,可以提供一套接口。

對于運(yùn)行在單核上的可信OS,移除該核可能不可行,除非把可信OS遷移到其它核上。

PSCI提供具有下列屬性的接口:

監(jiān)控軟件可以請求給一個(gè)核上電。監(jiān)控軟件還必須提供一個(gè)啟動地址,作為它從安全固件退出時(shí),繼續(xù)執(zhí)行的地方。通過提供一個(gè)入口地址,監(jiān)控軟件可以直接在自己的地址空間中干一些特殊的事情。為此,監(jiān)控軟件還必須使用內(nèi)部的per-CPU數(shù)據(jù)結(jié)構(gòu)保存這些值。

監(jiān)控軟件可以請求給一個(gè)核掉電。并且還能通知更高異常級別上的軟件。

監(jiān)控軟件還能請求將可信OS遷移到另一個(gè)核上。

監(jiān)控軟件,狹義上理解為操作系統(tǒng)的內(nèi)核。

4.4 系統(tǒng)級的shutdown、reset和suspend

PSCI提供了接口,允許OS請求系統(tǒng)system shutdown、system reset和system suspend(suspend-to-RAM)。芯片供應(yīng)商應(yīng)該提供這些函數(shù)的統(tǒng)一實(shí)現(xiàn),它們與監(jiān)控軟件是獨(dú)立的。沒有提供suspend-to-disk,這是因?yàn)樗窍到y(tǒng)關(guān)機(jī)的一種特殊情況。

這兒,system的意思是從整臺機(jī)器的視角看待問題。也就是說,不是單一關(guān)閉某個(gè)核或者簇那么簡單。當(dāng)然,運(yùn)行在虛擬機(jī)中的客戶機(jī)OS,如果調(diào)用這些接口不會發(fā)生物理狀態(tài)的變化。

但是,如果沒有hypervisor,或者調(diào)用者是hypervisor,則會導(dǎo)致電源狀態(tài)的物理變化。即使調(diào)用者在物理機(jī)器上運(yùn)行,術(shù)語系統(tǒng)可能也不是指整個(gè)物理機(jī)器。例如,假設(shè)一個(gè)高級服務(wù)器系統(tǒng)由多個(gè)單板組成,每個(gè)單板具有一個(gè)BMC (board management controller),每個(gè)單板包含多個(gè)SoC。這樣的系統(tǒng)可以在每個(gè)SoC上運(yùn)行一個(gè)OS實(shí)例。在本例中,用于關(guān)閉系統(tǒng)的PSCI命令應(yīng)用于單個(gè)SoC,而關(guān)閉整個(gè)單板需要通過管理接口訪問BMC,而這個(gè)管理接口是調(diào)用操作系統(tǒng)或PSCI實(shí)現(xiàn)無法訪問的。在本文檔中,術(shù)語系統(tǒng)僅指對操作系統(tǒng)可見的機(jī)器視圖。反映到本文檔中,就是指一個(gè)SOC。

5 函數(shù)接口描述

功能接口描述。這些API描述不包含底層的SMC或HVC調(diào)用。但是,這些函數(shù)卻都遵守SMCCC調(diào)用規(guī)約。如果實(shí)現(xiàn)了EL2卻沒有實(shí)現(xiàn)EL3,則hypervisor使用HVC為運(yùn)行在EL1的Guest OS提供調(diào)用支持。調(diào)用格式都是一樣的。PSCI函數(shù)只能由非安全空間發(fā)起調(diào)用(EL1或EL2)。

5.1 PSCI_VERSION

功能描述

返回PSCI實(shí)現(xiàn)的版本號。

參數(shù)

uint32 Function ID: 0x8400 0000

返回值

uint32:

位[31:16]-主版本號;

位[15:0]-次版本號;

注意

對于沒有實(shí)現(xiàn)的PSCI函數(shù),返回NOT_SUPPORTED。

5.2 CPU_SUSPEND

功能描述

掛起CPU核或它之上的更高拓?fù)浣Y(jié)構(gòu)中的節(jié)點(diǎn)。用于空閑狀態(tài)管理,期望CPU核喚醒時(shí)從之前的執(zhí)行位置繼續(xù)執(zhí)行。

參數(shù)

對于powerdown請求,調(diào)用者必須保存復(fù)位重新運(yùn)行時(shí)所需要的狀態(tài)。也就是說保存的上下文必須是調(diào)用者在發(fā)生powerdown調(diào)用之前power_state參數(shù)所指示的電源級別(power_level字段)下所有可見的狀態(tài)。(就是調(diào)用者自己保存自己的狀態(tài),被調(diào)用者不管)

對于掉電請求,調(diào)用者無需執(zhí)行Cache或一致性操作。PSCI實(shí)現(xiàn)者完成(PSCI實(shí)現(xiàn)側(cè)負(fù)責(zé)內(nèi)存一致性)。

調(diào)用者不能假設(shè)powerdown請求使用指定的entry point地址返回。因?yàn)?,powerdown可能不能完成,比如因?yàn)橹袛鄴炱?。也有可能因?yàn)榕c其它核的協(xié)調(diào),真正進(jìn)入的是淺睡眠模式(相比請求的休眠模式)。因此,PSCI實(shí)現(xiàn)可能將請求的powerdown狀態(tài)降為standby狀態(tài)。如果降為standby狀態(tài),PSCI實(shí)現(xiàn)返回到PSCI調(diào)用之后的指令,而不是指定的entry_point入口地址。此時(shí),返回碼也是成功的。如果發(fā)生比較早的wakeup事件,實(shí)現(xiàn)也是返回下一條指令,返回碼也是成功的,也有可能成功的在指定的entry point地址處返回。

正確的喚醒事件必須能夠保證恢復(fù)到之前的狀態(tài)。

CPU_SUSPEND調(diào)用傳遞的入口地址必須是調(diào)用者視角下的物理地址。

上下文標(biāo)識符只對調(diào)用者有意義。PSCI實(shí)現(xiàn)者保存,喚醒時(shí)在返回的異常級別下,再傳遞給CPU核,通過該值,恢復(fù)掉電前的上下文。

INVALID_PARAMETERS:如果發(fā)生下面的情況,就會返回該錯(cuò)誤。

INVALID_ADDRESS

如果傳遞的入口地址,PSCI實(shí)現(xiàn)者認(rèn)為是非法的,就返回該值。

PSCI 1.0之前使用INVALID_PARAMETERS代替該值。

在OS協(xié)調(diào)模式下,如果發(fā)生以下兩種情況,就會返回DENIED:

在OS協(xié)調(diào)模式下,如果系統(tǒng)的狀態(tài)和請求狀態(tài)不一致,會返回INVALID_PARAMETERS,不同之處在于:

為高于核電源級別的拓?fù)涔?jié)點(diǎn)請求低功耗電源狀態(tài)

該節(jié)點(diǎn)中至少一個(gè)子節(jié)點(diǎn)與請求的電源狀態(tài)不兼容(比如,一個(gè)核發(fā)起請求,將系統(tǒng)級節(jié)點(diǎn)置于powerdown狀態(tài),但是,該系統(tǒng)節(jié)點(diǎn)中的另一個(gè)核處于retention狀態(tài)時(shí),就會返回參數(shù)錯(cuò)誤。)

提供的power_state參數(shù)不正確。預(yù)期是與平臺固件表(如ACPI或FDT一致)

在OS協(xié)調(diào)模式下,發(fā)生以下兩種條件時(shí),也會返回參數(shù)錯(cuò)誤:

在DENIED情況中,不一致的核必須運(yùn)行中。錯(cuò)誤會出現(xiàn)在調(diào)用者和實(shí)現(xiàn)者兩側(cè)。

在INVALID_PARAMETERS情況中,不一致的節(jié)點(diǎn)必須處于低功耗狀態(tài),不一致只能通過調(diào)用者(OS)的錯(cuò)誤產(chǎn)生。

為高于核電源級別的拓?fù)涔?jié)點(diǎn)請求低功耗電源狀態(tài)

所有與請求不一致的核必須處于運(yùn)行中,而不是低功耗狀態(tài)

原始格式

PSCI 1.0之前的版本支持的形式。當(dāng)使用這種格式時(shí),PSCI_FEATURES使用CPU_SUSPEND功能ID返回的標(biāo)志字段的bit[1]位被設(shè)置為0。

各比特位的意義:

位域 描述
31:26 保留,必須是0
25:24 PowerLevel
23:17 保留,必須是0
16 StateType
15:0 StateID

擴(kuò)展StateID:

對于一個(gè)硬件平臺,支持每個(gè)核、簇或整個(gè)系統(tǒng)固定組合狀態(tài)。這些狀態(tài)產(chǎn)生了一組合法的power_state值。這些狀態(tài)應(yīng)該通過固件表(如ACPI或FDT)表示給OSPM。為此,PSCI 1.0引入了一個(gè)新的擴(kuò)展StateID格式。這種格式對于PSCI的實(shí)現(xiàn)者來說更為靈活,方便開發(fā)者實(shí)現(xiàn)PSCI,可以通過ACPI或FDT電源狀態(tài)的描述進(jìn)行改進(jìn)。這樣的情況下,原先的格式有些字段就多余了。

使用這種格式的時(shí)候,PSCI_FEATURES函數(shù)的返回標(biāo)志中的bit[1]會被設(shè)為1(傳遞CPU_SUSPEND功能ID)。

注意:一種實(shí)現(xiàn)中不可能混用這兩種格式。

下表是power_state參數(shù)的位域(擴(kuò)展StateID格式)。

位域 描述
31 保留,必須是0
30 StateType
29:28 保留,必須是0
27:0 StateID

推薦的編碼格式:參考前面。

StateID示例編碼

0084ef7c-5dcc-11ed-a3b6-dac502259ad0.png

0,表示standby或retention狀態(tài);

1,表示powerdown狀態(tài)。另外,還說明entry_point_address和context_id的值合法;

Level 0: 核

Level 1: 簇

Level 2: 系統(tǒng)

PowerLevel,定義的電源域級別,也就是表示是核,簇還是系統(tǒng)層電源請求。

PSCI 1.0之前的版本稱為AffinityLevel。

但是電源域級別的命名,卻是實(shí)現(xiàn)者定義的。一般情況下,按照如下方式命名:

StateType:狀態(tài)類型

StateID:狀態(tài)ID

對請求的組合電源狀態(tài)進(jìn)行標(biāo)識。一般是實(shí)現(xiàn)者定義的。在OS協(xié)調(diào)模式下,StateID必須能夠表示哪個(gè)核是最后一個(gè)進(jìn)入idle狀態(tài)的。

這些信息必須體現(xiàn)在FDT或ACPI固件表中,以便在請求電源狀態(tài)時(shí),將這些信息添加到StateID字段中。推薦編碼格式可以參考第6.5小節(jié)。

位域 描述
15:12 核是電源等級中的最后一個(gè)
? 0: Core Level
? 1: Cluster Level
? 2: System Level
11:8 系統(tǒng)級局部電源狀態(tài):
? 0: Run
? 2: Retention
? 3: Powerdown
7:4 簇級局部電源狀態(tài):
? 0: Run
? 2: Retention
? 3: Powerdown
3:0 核級局部電源狀態(tài):
? 0: Run
? 1: standby
? 2: Retention
? 3: Powerdown

0x8400 0001-SMC32版本

0xC400 0001-SMC64版本

uint32 Function ID:

uint32 power_state

從PSCI 1.0開始,支持兩種格式。

entry_point_address

喚醒時(shí),程序繼續(xù)執(zhí)行的起始地址??梢允荘A(物理地址)或IPA(中間物理地址)。

context_id

該參數(shù)只對調(diào)用者有用。PSCI實(shí)現(xiàn)者只需保留一下該參數(shù)的備份即可。從掉電狀態(tài)喚醒時(shí),PSCI將該值寫入到R0、W0或X0通用寄存器中,進(jìn)入異常的程序會通過該寄存器將保存的上下文內(nèi)容恢復(fù)。

調(diào)用者的責(zé)任

在發(fā)起CPU_SUSPEND調(diào)用之前,非安全空間必須遵守以下規(guī)則:

調(diào)用者必須處理可能的錯(cuò)誤碼:

PSCI實(shí)現(xiàn)者的責(zé)任:狀態(tài)協(xié)調(diào)

在平臺協(xié)調(diào)者模式中,調(diào)用者通過power_state參數(shù)傳遞的指定進(jìn)入的電源狀態(tài),在語義上不是強(qiáng)制的。相反,它代表的是調(diào)用者容忍的最深的電源狀態(tài)。此種情況下,是通過PSCI實(shí)現(xiàn)真正進(jìn)入的電源狀態(tài)。為此,如果一個(gè)核沒有調(diào)用CPU_ON而上電,或者調(diào)用了CPU_OFF而關(guān)閉的情況下,假定該核進(jìn)入了最深的電源狀態(tài)。

而在OS協(xié)調(diào)模式中,調(diào)用者顯式請求某個(gè)特定的電源狀態(tài),而不是讓PSCI實(shí)現(xiàn)決定。實(shí)現(xiàn)必須遵循請求,除非與實(shí)現(xiàn)當(dāng)前的狀態(tài)不一致。

PSCI實(shí)現(xiàn)者的責(zé)任:與可信OS或PF進(jìn)行交互

PSCI實(shí)現(xiàn)必須能夠與可信OS或SP進(jìn)行通信。交互方法請參考ARMv8-A的Firmware Framework。

因?yàn)槟承┰?,可信OS或SP可能不兼容某種特殊的狀態(tài)。這種情況下,ARM建議:可信OS或SP使用自定義的機(jī)制與非安全空間通信,保證它的限制可以被非安全空間的代碼考慮。

PSCI實(shí)現(xiàn)者的責(zé)任:Cache和內(nèi)存一致性管理

Powerdown狀態(tài)要求清除Cache。PSCI實(shí)現(xiàn)者必須在掉電一個(gè)節(jié)點(diǎn)之前,為該節(jié)點(diǎn)中所有的Cache和正在最后關(guān)閉的那個(gè)核執(zhí)行清除操作。另外,PSCI實(shí)現(xiàn)還需要在啟動階段執(zhí)行對Cache的失效操作,除非這是硬件能夠自動完成的。在相關(guān)處理器和互連IP的技術(shù)參考手冊中可以看到,上電或掉電應(yīng)該遵守的順序。

PSCI實(shí)現(xiàn)者的責(zé)任:返回狀態(tài)

當(dāng)從standby狀態(tài)返回時(shí),對于調(diào)用者來說,CPU核的狀態(tài)應(yīng)該沒有變化,除了定時(shí)器和由于喚醒中斷造成的CPU interface的變化之外。對于核來說,standby狀態(tài)和使用WFI指令沒有什么不同。唯一的不同就是,調(diào)用SMC指令造成的寄存器變化。R0或W0返回的值是錯(cuò)誤碼。對于standby狀態(tài),成功時(shí)返回SUCCESS。對于powerdown狀態(tài),如果成功不會返回,因?yàn)閱拘褧r(shí),從傳遞的入口地址處開始執(zhí)行。如果不成功,返回錯(cuò)誤碼,表明錯(cuò)誤原因。

返回值

int32:

SUCCESS;

INVALID_PARAMETERS;

INVALID_ADDRESS;

DENIED;

注意

對于沒有實(shí)現(xiàn)的PSCI函數(shù),返回NOT_SUPPORTED。

5.3 CPU_OFF

功能描述

關(guān)閉核。用于hotplug。只能使用CPU_ON調(diào)用重新開啟一個(gè)核。

參數(shù)

0x8400 0002

uint32 Function ID:

返回值

int32:成功不會返回;否則返回DENIED。

5.4 CPU_ON

功能描述

啟動一個(gè)核。有兩種情況:(1)啟動階段時(shí)調(diào)用;(2)該核之前被CPU_OFF關(guān)閉。

參數(shù)

[24:31]: 必須是0

[16:23]: 匹配MPIDR.Aff2位域

[8:15]: 匹配MPIDR.Aff1位域

[0:7]: 匹配MPIDR.Aff0位域

[40:63]: 必須是0

[32:39]: 匹配MPIDR.Aff3位域

[24:31]: 必須是0

[16:23]: 匹配MPIDR.Aff2位域

[8:15]: 匹配MPIDR.Aff1位域

[0:7]: 匹配MPIDR.Aff0位域

0x8400 0003-SMC32版本

0xC400 0003-SMC64版本

uint32 Function ID: 功能ID

uint32/uint64 target_cpu:目標(biāo)核

MPIDR寄存器的備份。如果是AArch32:

如果是AArch64:

uint32/uint64 entry_point_address:入口地址

當(dāng)核返回到非安全異常級時(shí)必須執(zhí)行的地址。SMC64版本時(shí),是64位的物理地址或中間物理地址;SMC32版本時(shí),是32位的物理地址或中間物理地址;

uint32/uint64 context_id:上下文地址

當(dāng)核返回到非安全異常級時(shí):SMC64版本時(shí),該值必須保存在X0寄存器;SMC32版本時(shí),該值必須保存在R0寄存器。需要把該地址的上下文內(nèi)容恢復(fù)(堆棧、執(zhí)行狀態(tài)、中斷狀態(tài)等)。

返回值

int32:

SUCCESS,成功則返回該值;

INVALID_PARAMETERS,描述了一個(gè)無效的MPIDR;

INVALID_ADDRESS,ATF認(rèn)為傳遞進(jìn)來的入口地址非法;

ALREADY_ON,ATF認(rèn)為該核已經(jīng)啟動;

ON_PENDING,已經(jīng)發(fā)起了CPU_ON請求,ATF還未處理;

INTERNAL_FAILURE,因?yàn)槲锢碓?,不能啟動CPU核。

5.5 AFFINITY_INFO

功能描述

請求某個(gè)親和力等級上的信息。

參數(shù)

0:target_affinity中的所有位域都是有效的。在不支持硬件線程化的處理器系統(tǒng)中,target_affinity將會表示單個(gè)核。

1:表示target_affinity中,忽略Aff0位域。target_affinity表示親和力等級為1的處理單元。

2:表示target_affinity中,忽略Aff0和Aff1位域。target_affinity表示親和力等級為2的處理單元。

3:表示target_affinity中,忽略Aff0、Aff1和Aff2位域。target_affinity表示親和力等級為3的處理單元。

0x8400 0004-SMC32版本

0xC400 0004-SMC64版本

uint32 Function ID:

target_affinity

同CPU_ON的target_cpu參數(shù)格式一樣。(SMC32或SMC64)

lowest_affinity_level

表示target_affinity參數(shù)中有效的最低親和力級別。該參數(shù)允許AFFINITY_INFO調(diào)用者請求大于0的親和力等級的信息。

可能的值:

從PSCI 1.0版本開始,AFFINITY_INFO不再需要支持高于0的親和級別。

返回值

int32:

2 ON_PENDING,親和力對象正在轉(zhuǎn)換為ON狀態(tài)的過程中;

1 OFF,親和力對象中,所有核都關(guān)閉;

0 ON,親和力對象中,至少有一個(gè)核開啟;

INVALID_PARAMETERS(PSCI 1.0以上,請求親和力值大于0的請求會返回該值);

DISABLED,由于物理原因禁止。

5.6 MIGRATE

功能描述

(可選的)請求將可信OS遷移到另一個(gè)核上。

參數(shù)

0x8400 0005-SMC32版本

0xC400 0005-SMC64版本

uint32 Function ID:

target_cpu

同CPU_ON調(diào)用的target_cpu參數(shù)一樣。

返回值

int32:

SUCCESS,成功則返回該值;

NOT_SUPPORTED,不支持該功能,或不需要遷移;

INVALID_PARAMETERS,描述了一個(gè)無效的MPIDR;

DENIED,可信OS啟動,但是不可遷移;

INTERNAL_FAILURE,因?yàn)槲锢碓?,不能遷移;

NOT_PRESENT,可信OS不在請求的核上。

5.7 MIGRATE_INFO_TYPE

功能描述

(可選的)請求可信OS支持多核的情況。

參數(shù)

0x8400 0006

uint32 Function ID:

返回值

int32:

0 支持單核遷移的可信OS??尚臤S只能運(yùn)行在一個(gè)核上??尚臤S支持遷移功能,可以被遷移到任意一個(gè)核上。如果嘗試對運(yùn)行可信OS的核調(diào)用CPU_OFF,請求會被拒絕(DENIED)。

1 不支持單核遷移的可信OS??尚臤S只能運(yùn)行在一個(gè)核上??尚臤S不支持遷移功能。調(diào)用MIGRATE會被拒絕。

2 可信OS既不存在、也不需要遷移。這類系統(tǒng)不要求調(diào)用者使用MIGRATE功能。如果硬要調(diào)用,返回NOT_SUPPORTED。

NOT_SUPPORTED 調(diào)用操作系統(tǒng)可以認(rèn)為等價(jià)于返回值為2的情況。

5.8 MIGRATE_INFO_UP_CPU

功能描述

(可選的)返回單核可信OS所在的核。

參數(shù)

0x8400 0007-SMC32版本

0xC400 0007-SMC64版本

uint32 Function ID:

返回值

可能是32位或64位:

UNDEFINED:如果 MIGRATE_INFO_TYPE調(diào)用返回2或NOT_SUPPORTED;

基于MPIDR的值:格式與CPU_ON調(diào)用中的target_cpu參數(shù)一樣。

5.9 SYSTEM_OFF

功能描述

關(guān)閉系統(tǒng)。

SYSTEM_OFF提供了一個(gè)系統(tǒng)關(guān)閉的接口。在調(diào)用該接口之前,調(diào)用者必須將所有的核置于已知狀態(tài)。調(diào)用也只能是由非安全空間發(fā)起。一旦發(fā)起該調(diào)用,PSCI實(shí)現(xiàn)將會完全關(guān)閉最高等級的電源(也就是系統(tǒng)電源)。

啟動必須是冷啟動。

參數(shù)

0x8400 0008

uint32 Function ID:

返回值

不需要返回。

5.10 SYSTEM_RESET

功能描述

提供系統(tǒng)冷復(fù)位的方法。

參數(shù)

0x8400 0009

uint32 Function ID:

返回值

不需要返回。

5.11 SYSTEM_RESET2

功能描述

(可選)對SYSTEM_RESET的擴(kuò)展,PSCI 1.1引入。提供:

架構(gòu)相關(guān)的reset方法

供應(yīng)商提供的reset方法

參數(shù)

Bit[31],保留的話就必須為0.

Bits[30:0]

設(shè)為1,則使用供應(yīng)商提供的reset方法;

設(shè)為0,則為架構(gòu)提供的reset方法;

0x0 SYSTEM_WARM_RESET.

其它值保留.

對于供應(yīng)商提供的reset方法,這些位的意義由供應(yīng)商定義。

對于架構(gòu)提供的reset方法,定義如下:

0x8400 0012-SMC32版本

0xC400 0012-SMC64版本

uint32 Function ID:

reset_type

32位值,被分為兩部分:

cookie

32位或64位值。用來傳遞額外的reset信息。

返回值

int32:

SUCCESS,成功不返回

NOT_SUPPORTED;

INVALID_PARAMETERS;

5.12 MEM_PROTECT

功能描述

(可選)通過在將內(nèi)存移交給操作系統(tǒng)加載程序之前,重寫這段內(nèi)存,來提供針對冷重啟攻擊的保護(hù)。PSCI 1.1引入。

參數(shù)

0x8400 0013

uint32 Function ID:

enable

32位值,非0值表示內(nèi)存保護(hù)被啟動。0值表示禁止保護(hù)功能。

返回值

int32:

成功,則返回之前的使能狀態(tài):0,表示之前是被禁止的;1,表示之前是使能的。

失敗,則返回NOT_SUPPORTED。

5.13 MEM_PROTECT_CHECK_RANGE

功能描述

(可選)可以檢查某段內(nèi)存是否被MEM_PROTECT保護(hù)。PSCI 1.1引入。

參數(shù)

0x8400 0014-SMC32版本

0xC400 0014-SMC64版本

uint32 Function ID:

uint32/64 base

要檢查的內(nèi)存的基地址;

uint32/64 length

要檢查的內(nèi)存的長度;

返回值

int32:

SUCCESS

DENIED

NOT_SUPPORTED

5.14 PSCI_FEATURES

功能描述

查詢SMCCC_VERSION或者某個(gè)PSCI功能是否被實(shí)現(xiàn)。PSCI 1.0引入。

參數(shù)

0x8400 000A

uint32 Function ID:

psci_func_id

功能ID:PSCI或SMCCC_VERSION

返回值

如果功能實(shí)現(xiàn),則意義如下:

psci_func_id 標(biāo)志位 描述
CPU_SUSPEND功能ID [31:2] 保留,等于0
[1] 0,power_state使用原始格式(PSCI 2.0)
1,power_state新的擴(kuò)展StateID格式
[0] 0,不支持OS協(xié)調(diào)方式
1,支持OS協(xié)調(diào)方式
其它功能ID [31:0] 保留都是0

5.15 CPU_FREEZE

功能描述

(可選)將核置于供應(yīng)商自定義的低功耗狀態(tài)中。與CPU_OFF不同,中斷仍然可以傳遞給該核。但是,該核一直會處于低功耗狀態(tài)中,直到CPU_ON調(diào)用將其啟動。PSCI 1.0引入。

參數(shù)

0x8400 000B

uint32 Function ID:

返回值

int32:

成功,不返回。

失敗,則返回NOT_SUPPORTED或DENIED。

5.16 CPU_DEFAULT_SUSPEND

功能描述

(可選)將核置于供應(yīng)商自定義的低功耗狀態(tài)中。與CPU_SUSPEND不同的是,不需要指定power_state參數(shù)。PSCI 1.0引入。

參數(shù)

0x8400 000C-SMC32版本

0xC400 000C-SMC64版本

uint32 Function ID:

entry_point_address

參考CPU_SUSPEND;

context_id

參考CPU_SUSPEND;

返回值

int32:

SUCCESS

INVALID_ADDRESS

5.17 NODE_HW_STATE

功能描述

(可選)返回系統(tǒng)的電源域拓?fù)浣Y(jié)構(gòu)中一個(gè)節(jié)點(diǎn)的硬件狀態(tài)。PSCI 1.0引入。

參數(shù)

0x8400 000D-SMC32版本

0xC400 000D-SMC64版本

uint32 Function ID:

target_cpu

參考CPU_ON;

power_level

表示想要請求的節(jié)點(diǎn),在電源域拓?fù)浣Y(jié)構(gòu)的層級。這是供應(yīng)商自定義的,但是0保留給CPU核。

返回值

int32:

2 HW_STANDBY:返回2,表示處于standby或retention電源狀態(tài);

1 HW_OFF:返回1,表示處于powerdown狀態(tài);

0 HW_ON:返回0,表示處于run狀態(tài);

NOT_SUPPORTED

INVALID_PARAMETERS

5.18 SYSTEM_SUSPEND

功能描述

語義等價(jià)于CPU_SUSPEND,將系統(tǒng)置于最低功耗狀態(tài)。該調(diào)用是實(shí)現(xiàn)system suspend-to-RAM的基礎(chǔ)(ACPI規(guī)范中描述的S2和S3狀態(tài))。值得注意的是,系統(tǒng)進(jìn)入S2或S3狀態(tài),需要幾個(gè)前提條件。系統(tǒng)中所有設(shè)備必須與進(jìn)入該系統(tǒng)掛起狀態(tài)兼容,可能需要在調(diào)用之前,優(yōu)雅地處理各個(gè)外設(shè)。這些前提條件不在本文的討論范圍內(nèi)。SYSTEM_SUSPEND僅限于提供進(jìn)入S2或S3狀態(tài)的機(jī)制,所有必要的條件都由調(diào)用OS滿足。盡管ACPI將suspend-to-RAM功能分為S2或S3兩種狀態(tài),但是PSCI只提供了一個(gè)API。

同SYSTEM_SHUTDOWN和SYSTEM_RESET一樣,該函數(shù)適用于調(diào)用OS的機(jī)器視角。

為了使用該函數(shù)調(diào)用,調(diào)用者必須使用CPU_OFF關(guān)閉所有的核,但保留一個(gè)核。剩下的這個(gè)核調(diào)用SYSTEM_SUSPEND,傳遞entry_point_address和context_id參數(shù)(喚醒時(shí)用),進(jìn)入掛起狀態(tài)。調(diào)用者(OS)可以在調(diào)用SYSTEM_SUSPEND之前,使用AFFINITY_INFO函數(shù)保證所有其它核都已關(guān)閉。

參數(shù)

0x8400 000E-SMC32版本

0xC400 000E-SMC64版本

uint32 Function ID:

entry_point_address:參考CPU_SUSPEND

context_id:參考CPU_SUSPEND

返回值

返回32位值。

NOT_SUPPORTED

INVALID_ADDRESS

ALREADY_ON

成功不會返回;

失敗則返回:

5.19 PSCI_SET_SUSPEND_MODE

功能描述

(可選)設(shè)置電源狀態(tài)協(xié)調(diào)方式。PSCI 1.0引入。

參數(shù)

0: 平臺協(xié)調(diào)方式

1: OS協(xié)調(diào)方式

0x8400 000F

uint32 Function ID:

mode

返回值

int32

SUCCESS

NOT_SUPPORTED

INVALID_PARAMETERS

DENIED

5.20 PSCI_STAT_RESIDENCY

功能描述

(可選)返回冷啟動之后,在某種狀態(tài)下的度過時(shí)間。PSCI 1.0引入。

參數(shù)

0x8400 0010-SMC32版本

0xC400 0010-SMC64版本

uint32 Function ID:

target_cpu

格式與CPU_ON調(diào)用相同;

power_state

指定的電源狀態(tài)。

返回值

可能是32位或64位。返回處于指定電源狀態(tài)的時(shí)間。

5.21 PSCI_STAT_COUNT

功能描述

(可選)返回冷啟動之后,進(jìn)入某種狀態(tài)下的次數(shù)。PSCI 1.0引入。

參數(shù)

0x8400 0010-SMC32版本

0xC400 0010-SMC64版本

uint32 Function ID:

target_cpu

格式與CPU_ON調(diào)用相同;

power_state

指定的電源狀態(tài)。

返回值

可能是32位或64位。進(jìn)入某種狀態(tài)下的次數(shù)。

5.22 錯(cuò)誤碼

定義
SUCCESS 0
NOT_SUPPORTED -1
INVALID_PARAMETERS -2
DENIED -3
ALREADY_ON -4
ON_PENDING -5
INTERNAL_FAILURE -6
NOT_PRESENT -7
DISABLED -8
INVALID_ADDRESS -9

6 其它實(shí)現(xiàn)細(xì)節(jié)

6.1 PSCI調(diào)用流程

6.1.1 CPU_SUSPEND、CPU_DEFAULT_SUSPEND和SYSTEM_SUSPEND調(diào)用流程

00ae183e-5dcc-11ed-a3b6-dac502259ad0.png

6.1.2 CPU_OFF調(diào)用流程

00df805e-5dcc-11ed-a3b6-dac502259ad0.png

6.1.3 CPU_ON調(diào)用流程

00fe858a-5dcc-11ed-a3b6-dac502259ad0.png

審核編輯:郭婷

聲明:本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點(diǎn)僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場。文章及其配圖僅供工程師學(xué)習(xí)之用,如有內(nèi)容侵權(quán)或者其他違規(guī)問題,請聯(lián)系本站處理。 舉報(bào)投訴
  • ARM
    ARM
    +關(guān)注

    關(guān)注

    134

    文章

    9180

    瀏覽量

    369464
  • 電源管理
    +關(guān)注

    關(guān)注

    115

    文章

    6193

    瀏覽量

    144988
  • Linux
    +關(guān)注

    關(guān)注

    87

    文章

    11351

    瀏覽量

    210512

原文標(biāo)題:PSCI接口規(guī)范

文章出處:【微信號:嵌入式ARM和Linux,微信公眾號:嵌入式ARM和Linux】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。

收藏 人收藏

    評論

    相關(guān)推薦

    Arm正式發(fā)布芯粒系統(tǒng)架構(gòu)首個(gè)公開規(guī)范

    近期,Arm控股有限公司宣布其芯粒系統(tǒng)架構(gòu)(CSA)正式推出了首個(gè)公開規(guī)范。這一舉措旨在進(jìn)一步推動芯粒技術(shù)的標(biāo)準(zhǔn)化進(jìn)程,并有效減少行業(yè)碎片化現(xiàn)象,為芯片設(shè)計(jì)領(lǐng)域注入新的活力。 芯粒技術(shù)作為當(dāng)前
    的頭像 發(fā)表于 02-08 15:19 ?227次閱讀

    Arm宣布其芯粒系統(tǒng)架構(gòu)正式推出首個(gè)公開規(guī)范

    Arm 控股有限公司(納斯達(dá)克股票代碼:ARM,以下簡稱“Arm”)宣布其芯粒系統(tǒng)架構(gòu) (Chiplet System Architecture, CSA) 正式推出首個(gè)公開
    的頭像 發(fā)表于 01-24 16:07 ?158次閱讀

    Arm發(fā)布芯粒系統(tǒng)架構(gòu)首個(gè)公開規(guī)范

    近日,Arm控股有限公司(納斯達(dá)克股票代碼:ARM,以下簡稱“Arm”)宣布了一項(xiàng)重要進(jìn)展,其芯粒系統(tǒng)架構(gòu)(CSA)已正式推出首個(gè)公開規(guī)范。
    的頭像 發(fā)表于 01-24 14:07 ?211次閱讀

    今日看點(diǎn)丨Arm 發(fā)布芯粒系統(tǒng)架構(gòu)首個(gè)公開規(guī)范;納芯微推出車規(guī)級D類音頻功率放大器

    1. Arm 發(fā)布芯粒系統(tǒng)架構(gòu)首個(gè)公開規(guī)范,加速芯片技術(shù)演進(jìn) ? Arm 控股有限公司宣布其芯粒系統(tǒng)架構(gòu) (CSA) 正式推出首個(gè)公開
    發(fā)表于 01-24 11:18 ?1172次閱讀

    HDMI Forum發(fā)布HDMI 2.2接口規(guī)范

    近日,HDMI Forum正式對外宣布了HDMI 2.2接口規(guī)范的推出。這一新規(guī)范將HDMI接口的帶寬翻倍提升至96 Gbps,為用戶帶來了更加卓越的音視頻體驗(yàn)。 HDMI Forum
    的頭像 發(fā)表于 01-07 10:54 ?352次閱讀

    一文詳解Arm架構(gòu)Armv9.6-A中的最新功能

    Arm CPU 是當(dāng)今人工智能 (AI) 賦能軟件的關(guān)鍵,它可解釋、處理和執(zhí)行指令。Arm 指令集架構(gòu) (ISA) 作為硬件和軟件的接口,指示處理器做什么和怎么做。
    的頭像 發(fā)表于 12-17 10:22 ?1858次閱讀
    一文詳解<b class='flag-5'>Arm</b><b class='flag-5'>架構(gòu)</b>Armv9.6-A中的最新功能

    基于高通主板的ARM架構(gòu)服務(wù)器

    一、ARM架構(gòu)服務(wù)器的崛起 (一)市場需求推動 消費(fèi)市場寒冬,全球消費(fèi)電子需求下行,服務(wù)器成半導(dǎo)體核心動力之一。Arm 加速布局服務(wù)器領(lǐng)域,如 9 月推出 Neoverse V2。長久以來,x86
    的頭像 發(fā)表于 09-11 10:53 ?645次閱讀

    什么是ARM架構(gòu)?什么是X86架構(gòu)?兩者的區(qū)別是什么?

    一、什么是ARM架構(gòu)? (一)起源與發(fā)展 ARM 架構(gòu)由英國劍橋的 Acorn 計(jì)算機(jī)公司開發(fā)。因市場無合適產(chǎn)品,Acorn 自行設(shè)計(jì)出第一款微處理器,命名為
    的頭像 發(fā)表于 09-06 10:40 ?1221次閱讀

    打開NAND Flash接口規(guī)范

    電子發(fā)燒友網(wǎng)站提供《打開NAND Flash接口規(guī)范.pdf》資料免費(fèi)下載
    發(fā)表于 08-21 12:21 ?0次下載

    龍芯CPU統(tǒng)一系統(tǒng)架構(gòu)規(guī)范及參考設(shè)計(jì)下載

    *附件:LoongArch 系統(tǒng)調(diào)用(syscall)ABI.pdf *附件:龍芯 CPU 統(tǒng)一系統(tǒng)架構(gòu)規(guī)范(適用于 LA 架構(gòu)通用 PC、服務(wù)器系列)-v4.1.0.pdf *附件:龍芯CPU統(tǒng)一
    發(fā)表于 06-20 14:42

    fpga封裝技術(shù)和arm架構(gòu)的優(yōu)缺點(diǎn)

    FPGA封裝技術(shù)和ARM架構(gòu)是兩個(gè)不同的概念,分別屬于硬件設(shè)計(jì)的不同領(lǐng)域。
    的頭像 發(fā)表于 03-26 15:51 ?1010次閱讀

    fpga封裝技術(shù)和arm架構(gòu)有什么區(qū)別

    FPGA封裝技術(shù)與ARM架構(gòu)在多個(gè)方面存在顯著的區(qū)別。
    的頭像 發(fā)表于 03-26 15:50 ?795次閱讀

    英特爾與Arm聯(lián)手助力初創(chuàng)企業(yè)開發(fā)Arm架構(gòu)SoC

    據(jù)介紹,此次合作旨在聯(lián)合推動使用Intel 18A制程工藝研發(fā)Arm架構(gòu)SoC的初創(chuàng)企業(yè)發(fā)展。英特爾和Arm將攜手提供IP和制造及相關(guān)金融支持,助力初創(chuàng)企業(yè)持續(xù)進(jìn)行創(chuàng)新和增長。這些企業(yè)將專門針對各種設(shè)備和服務(wù)器研發(fā)
    的頭像 發(fā)表于 03-25 15:34 ?481次閱讀

    蘋果M3芯片是ARM架構(gòu)

    蘋果M3芯片采用的是ARM架構(gòu)。這種架構(gòu)具有高效能和低功耗的特點(diǎn),使得M3芯片在提供出色性能的同時(shí),也能保持較低的能耗。
    的頭像 發(fā)表于 03-08 16:03 ?2292次閱讀

    Arm v9芯片新架構(gòu)揭秘

    從中長期來看,隨著單芯片 ARM 核數(shù)增加、基于 ARM 架構(gòu)芯片數(shù)量的上升以及ARM 應(yīng)用場景的增加,公司仍將保持增長。據(jù)公司公告數(shù)據(jù)顯示,2023 財(cái)年,高端芯片采用
    發(fā)表于 02-27 14:14 ?5560次閱讀
    <b class='flag-5'>Arm</b> v9芯片新<b class='flag-5'>架構(gòu)</b>揭秘