ARM SCP入門-AP與SCP通信
SoC上有很多核,ATF和Linux占據(jù)了A核,SCP占據(jù)了一個(gè)M核,當(dāng)遇到Linux沒有權(quán)限的事情的時(shí)候(SMC進(jìn)入EL3轉(zhuǎn)PSCI協(xié)議,例如電源管理),就需要給SCP打報(bào)告,SCP審批完批條子后去執(zhí)行。這其中涉及到了異構(gòu)核間通信,估計(jì)第一時(shí)間會(huì)想到mailbox,不過mailbox算是一個(gè)傳輸層,面向的是bit位數(shù)據(jù)的傳輸,可以把這些傳輸數(shù)據(jù)組織成一個(gè)協(xié)議層,在AP與SCP的核間通信中那就是SCMI。
1. SMC系統(tǒng)調(diào)用與PSCI協(xié)議
圖片
當(dāng)Linux想要關(guān)機(jī)或者休眠的時(shí)候,這涉及到整個(gè)系統(tǒng)電源狀態(tài)的變化,為了安全性Linux內(nèi)核沒有權(quán)利去直接執(zhí)行了,需要陷入到EL3等級(jí)去執(zhí)行,可以參考之前文章ARM ATF入門-安全固件軟件介紹和代碼運(yùn)行,在EL3中處理的程序是BL31,把SMC系統(tǒng)調(diào)用的參數(shù)轉(zhuǎn)化為PSCI協(xié)議去執(zhí)行,這時(shí)如果有SCP那A核就憋屈了,自己沒權(quán)利執(zhí)行需要通過SCMI協(xié)議上報(bào)給SCP了。這就是整個(gè)過程的軟件協(xié)議棧如上圖中:
- 用戶層:首先用戶發(fā)起的一些操作,通過用戶空間的各service處理,會(huì)經(jīng)過內(nèi)核提供的sysfs,操作cpu hotplug、device pm、EAS、IPA等。
- 內(nèi)核層:在linux內(nèi)核中,EAS(energy aware scheduling)通過感知到當(dāng)前的負(fù)載及相應(yīng)的功耗,經(jīng)過cpu idle、cpu dvfs及調(diào)度選擇idle等級(jí)、cpu頻率及大核或者小核上運(yùn)行。IPA(intrlligent power allocation)經(jīng)過與EAS的交互,做熱相關(guān)的管理。
- ATF層:Linux kernel中發(fā)起的操作,會(huì)經(jīng)過電源狀態(tài)協(xié)調(diào)接口(Power State Coordination Interface,簡稱PSCI),由操作系統(tǒng)無關(guān)的framework(ARM Trusted Firmware,簡稱ATF)做相關(guān)的處理后,通過系統(tǒng)控制與管理接口(System Control and Management Interface,簡稱SCMI),向系統(tǒng)控制處理器(system control processor,簡稱SCP)發(fā)起低功耗操作。
- SCP層:SCP(系統(tǒng)控制處理器system control processor)最終會(huì)控制芯片上的sensor、clock、power domain、及板級(jí)的pmic做低功耗相關(guān)的處理。
總結(jié):用戶進(jìn)程 --sysfs--> 內(nèi)核(EAS、IPA)--PSCI--> ATF --SCMI-->SCP --LPI--> 功耗輸出器件
1.1 SMC指令
上面看完有一個(gè)整體的認(rèn)識(shí),下面進(jìn)入正題,先介紹下什么是SMC指令,為什么走SMC就是安全通道,Linux直接給SCP通信就是非安全通道,這兩種通道怎么去區(qū)分?
首先看SMC規(guī)范,ARM官方文檔地址:
https://developer.arm.com/documentation/den0028/latest
《DEN0028E_SMC_Calling_Convention_1.4》本文檔定義了一種通用的調(diào)用機(jī)制,可與Armv7和Armv8架構(gòu)中的安全監(jiān)視器調(diào)用(SMC)和系統(tǒng)監(jiān)控程序調(diào)用(HVC)指令一起使用。
SMC指令用于生成一個(gè)同步異常,該異常由運(yùn)行在EL3中的安全監(jiān)視器代碼處理。參數(shù)和返回值將在寄存器中傳遞。在由安全監(jiān)視器處理之后,由指令產(chǎn)生的調(diào)用可以傳遞到受信任的操作系統(tǒng)或安全軟件堆棧中的其他實(shí)體。
HVC指令用于生成由在EL2中運(yùn)行的管理程序處理的同步異常。參數(shù)和返回值將在寄存器中傳遞。管理程序還可以捕獲由客戶操作系統(tǒng)(在EL1)發(fā)出的SMC調(diào)用,這允許適當(dāng)?shù)啬M、傳遞或拒絕調(diào)用。
本規(guī)范旨在簡化集成和減少軟件層之間的碎片化,例如操作系統(tǒng)、系統(tǒng)管理程序、受信任的操作系統(tǒng)、安全監(jiān)視器和系統(tǒng)固件。具體的各種定義可以自己看手冊,我們在Linux代碼中執(zhí)行smc調(diào)用的時(shí)候的函數(shù)例如關(guān)機(jī)為:
#define PSCI_0_2_FN_BASE 0x84000000
#define PSCI_0_2_FN(n) (PSCI_0_2_FN_BASE + (n))
#define PSCI_0_2_FN_SYSTEM_OFF PSCI_0_2_FN(8)
static void psci_sys_poweroff(void)
{
invoke_psci_fn(PSCI_0_2_FN_SYSTEM_OFF, 0, 0, 0);
}
PSCI_0_2_FN_SYSTEM_OFF的值計(jì)算為:0x84000000+8,在規(guī)范的表6-2:分配給不同服務(wù)的功能標(biāo)識(shí)符的子范圍中,
圖片
表中的各種功能就是走安全通道的,不是SMC或者HVC命令的功能就是非安全通道的,當(dāng)然也可以根據(jù)自己的需求選擇,一般PSCI協(xié)議中的功能都是走安全通道。
1.2 PSCI協(xié)議
PSCI協(xié)議官方地址:
https://developer.arm.com/documentation/den0022/d/
《Power_State_Coordination_Interface_PDD_v1_1_DEN0022D》
本文檔定義了一個(gè)電源管理的標(biāo)準(zhǔn)接口,操作系統(tǒng)供應(yīng)商可用于在ARM設(shè)備上使用不同特權(quán)級(jí)別的監(jiān)控軟件。該接口旨在在以下電源管理場景中代碼通用化:
- 內(nèi)核空閑管理。
- 動(dòng)態(tài)添加和刪除核心,以及輔助核心引導(dǎo)。
- 系統(tǒng)關(guān)閉和復(fù)位。
該接口不包括動(dòng)態(tài)電壓和頻率縮放(DVFS)或設(shè)備電源管理(例如,對圖形處理器等外設(shè)的管理)。
為什么需要PSCI?
具有電源管理感知的操作系統(tǒng)動(dòng)態(tài)地改變核心的電源狀態(tài),平衡可用的計(jì)算容量以匹配當(dāng)前的工作負(fù)載,同時(shí)努力使用最小的功率量。其中一些技術(shù)可以動(dòng)態(tài)地打開和關(guān)閉內(nèi)核,或?qū)⑺鼈冎糜陟o止?fàn)顟B(tài),在靜止?fàn)顟B(tài)下它們不再執(zhí)行計(jì)算。這意味著它們消耗的能量很少。這些技術(shù)的主要例子是:
- 空閑管理:當(dāng)操作系統(tǒng)中的內(nèi)核在核心上沒有線程可以調(diào)度時(shí),它會(huì)將該核心置于時(shí)鐘門控、保留狀態(tài),甚至是完全電源門控狀態(tài)。然而,該核心仍然可用于操作系統(tǒng)。
- 熱插拔:當(dāng)計(jì)算需求低時(shí),核心會(huì)物理關(guān)閉,當(dāng)需求增加時(shí)恢復(fù)在線。該操作系統(tǒng)將遷移所有遠(yuǎn)離離線的核心的中斷和線程,并在它們重新聯(lián)機(jī)時(shí)重新平衡負(fù)載。
具體包含那些功能,可以自己去看規(guī)范文檔,這里截圖算個(gè)記錄:
圖片
比如關(guān)機(jī)就是5.10里面的內(nèi)容。
2. SCMI協(xié)議
現(xiàn)在繼續(xù)聊SCP里面的東西,上來就是SCMI協(xié)議,同樣還是去ARM官網(wǎng)找:
《DEN0056B_System_Control_and_Management_Interface_v2_0》
這個(gè)協(xié)議在哪里用到,我們來看一個(gè)圖:
圖片
SCP會(huì)以服務(wù)的方式來支持AP參與運(yùn)行管理,這也就需要SCP和AP之間有一個(gè)通信接口。這個(gè)通信接口在硬件上可以通過共享存儲(chǔ)和MHU(Message Handling Unit)實(shí)現(xiàn);在軟件上,通過定義一組通信協(xié)議來實(shí)現(xiàn)。
主要涉及的模塊如下:
- mhu模塊:Message Handling Unit (MHU)在module/mhu/src/mod_mhu.c中實(shí)現(xiàn)
- msg_smt模塊:Shared Memory Transport 是一種用于描述系統(tǒng)內(nèi)存拓?fù)涞臄?shù)據(jù)結(jié)構(gòu)。在ARM 架構(gòu)中,SCP 固件使用 Shared Memory Transport來提供有關(guān)系統(tǒng)內(nèi)存的信息,如地址范圍、類型、屬性等。System Memory Tables 通常由系統(tǒng)固件在啟動(dòng)過程中生成,并由SCP 固件和其他系統(tǒng)組件使用。它們允許系統(tǒng)軟件了解和管理系統(tǒng)中可用的內(nèi)存資源。
- SCMI模塊:System Control & Management Interface (SCMI)
- 業(yè)務(wù)處理模塊,為scmi protocol模塊例如scmi_power_domain
SCMI抽象出協(xié)議和傳輸兩層,協(xié)議層描述能夠支持的命令,傳輸層定義了命令通過什么方式傳輸,發(fā)送命令方稱為agent。有個(gè)限制,每個(gè)agent的傳輸通道必須一個(gè)或者多個(gè),然后如果有安全需求,那安全AP必須使用安全的通道進(jìn)行傳輸數(shù)據(jù)。
圖片
協(xié)議層:
- 通道(channel)必須是分開獨(dú)立的,各個(gè)agent不能使用同一個(gè)。避免platform無法識(shí)別message對應(yīng)方
- agent必須是獨(dú)立的操作系統(tǒng)
- 通道支持雙向通訊,另外也能夠支持中斷、polling兩種方式,讓agent選擇
從agent到platform的消息分為兩種,同步和異步,為A2P通道:
- 同步(synchronous),agent返回的時(shí)候?qū)?yīng)的platform操作就已經(jīng)完成了。platform返回操作結(jié)果命令也是通過agent到platform的通道,同一個(gè)通道完成這些操作
- 異步(asynchronoous),當(dāng)platform完成后,會(huì)發(fā)送 delayed response給到agent告知對方工作完成,這是P2A通道。agent發(fā)送完消息后,立馬得到platform的返回,然后釋放通道繼續(xù)做下一次傳輸
SCMI協(xié)議的整體應(yīng)用框圖,從SCMI規(guī)范截圖如下:
圖片
scmi transport,channel,agent的對應(yīng)關(guān)系:
1. 一個(gè)scp可以有多個(gè)agent,agent是運(yùn)行在操作系統(tǒng),安全固件的軟件或者一個(gè)使用scmi協(xié)議的設(shè)備。例如juno有如下代理,0保留給平臺(tái)。
enum juno_scmi_agent_idx {
/* 0 is reserved for the platform */
JUNO_SCMI_AGENT_IDX_OSPM = 1,
JUNO_SCMI_AGENT_IDX_PSCI,
JUNO_SCMI_AGENT_IDX_COUNT,
};
2. transport定義了scmi協(xié)議如何傳輸。比如shared memory。一個(gè)agent可以有多個(gè)A2P或P2A channel,channel是雙向的,但是協(xié)議發(fā)起者(主)-接收者(從)關(guān)系是固定的。故若要使能通知功能,除了一個(gè)A2P channel外,還需要一個(gè)P2A channel分配給這個(gè)agent.
SCMI協(xié)議的message header定義如下,對應(yīng)代碼module/scmi/include/mod_scmi_std.h中定義
圖片
[protocol_id]:
圖片
[message id]:
message id是二級(jí)功能區(qū)分id算cmd,例如設(shè)置狀態(tài)、獲取狀態(tài)等具體操作。如果有新增的協(xié)議,那里面0/1/2這三個(gè)message都必須按照協(xié)議走。
圖片
[message type]:
Commands 的message type都是0。對于不支持的協(xié)議和message類型,platform都要回復(fù) NOT_SUPPORTED
Delayed responses 類型都是2
Notifications 為3
傳輸層:
傳輸層文檔也就定義了一種方式,mailbox方式(核間通訊的一種ip)。這種通訊的前提是系統(tǒng)能夠在agents和platform之間存在共享內(nèi)存(ddr和片上flash都行,最好是片上flash)。mailebox能夠完美支持前面提到的通道的需求,中斷、內(nèi)存和完成中斷等都能夠,而且是軟件可操控。比如下面流程指出的中斷和polling方式:
圖片
mailbox通訊怎么定義在flash里面的layout:
圖片
3. Agent scmi消息處理流程
這里我們以一個(gè)protocol_id為0x11的power domain控制消息為例子進(jìn)行說明:
圖片
scp中scmi消息處理時(shí)序圖
1) mhu模塊-中斷產(chǎn)生:scmi底層硬件對應(yīng)的模塊是mhu模塊,當(dāng)硬件收到agent的消息時(shí)候會(huì)產(chǎn)生中斷,中斷處理函數(shù)為mhu_isr。在該函數(shù)中通過中斷源查表獲取對應(yīng)的設(shè)備和smt channel。然后調(diào)用transport模塊的api(調(diào)用transport_channel->api->signal_message(transport_channel->id);)發(fā)送消息。
2)transport模塊-獲取通道上下文:signal_message api中通過channel id獲取channel上下文信息,檢查通道是否ready和locked,調(diào)用scmi模塊的api 處理(channel_ctx->scmi_api->signal_message(channel_ctx->scmi_service_id);)。
3) scmi模塊-產(chǎn)生處理事件:
?scmi的api函數(shù)signal_message中將該消息封裝成事件,通過fwk_put_event發(fā)送一個(gè)fwk_event_light。(事件中source_id為scmi模塊,.target_id 為上一級(jí)smt 中channel_ctx->scmi_service_id,也是scmi。所以讓該事件是自己發(fā)給自己的)。因?yàn)閑vent有隊(duì)列,中斷調(diào)用的api是實(shí)時(shí)的。在scmi的.process_event回調(diào)函數(shù)中處理上面的事件。
?首先通過scmi維護(hù)的scmi_ctx.service_ctx_table獲取transport信息找到transport_api(msg_smt模塊提供),然后讀出scmi消息的頭部(scmi_protocol_id、scmi_message_id、scmi_message_type、scmi_token)。
?然后通過get_agent_id(event->target_id, &agent_id)獲取該scmi 協(xié)議的agent_id(OSPM、PSCI等),根據(jù)agent_id獲取到agent_type(psci、ospi等)。
?最后根據(jù)scmi_protocol_id找到protocol(例如0x11是power domain處理),調(diào)用protocol->message_handler(protocol->id, event->target_id,payload, payload_size, ctx->scmi_message_id)執(zhí)行相對應(yīng)的protocol的消息處理函數(shù)。message_handler函數(shù)執(zhí)行到了scmi_power_domain模塊。
4)scmi_power_domain模塊-解析scmi消息:.message_handle函數(shù)對消息進(jìn)行檢驗(yàn),將進(jìn)行權(quán)限判斷,然后查表調(diào)用具體的消息處理函數(shù)handler_table[message_id](service_id, payload)。例如scmi_protocol_id為scmi_power_domain,scmi_message_type為MOD_SCMI_PD_POWER_STATE_SET,則處理函數(shù)為scmi_pd_power_state_set_handler。該函數(shù)中將會(huì)進(jìn)行策略判斷(大多數(shù)模塊為空),然后調(diào)用scmi_pd_ctx.pd_api->set_state(pd_id, pd_power_state)進(jìn)行power domain的set,pd_api對應(yīng)power_domain模塊中對外api函數(shù)。
5)power_domain模塊-調(diào)用driver處理:power_domain模塊的api set_state函數(shù)先組裝了一個(gè)event發(fā)給pd_id,也就是自己。pd_process_event()函數(shù)進(jìn)行處理,process_set_state_request()按照pd的樹形結(jié)構(gòu)對狀態(tài)進(jìn)行設(shè)置,然后調(diào)用initiate_power_state_transition()執(zhí)行status = pd->driver_api->set_state(pd->driver_id, state);更新pd的狀態(tài),并拿到執(zhí)行結(jié)果status 。這里driver_api是在product/juno/scp_ramfw/config_power_domain.c的struct fwk_element element_table變量中定義,可以看到為FWK_MODULE_IDX_JUNO_PPU中提供
6) juno_ppu模塊-寄存器設(shè)置:根據(jù)ppu_id拿到ppu的上下文ppu_ctx,按照傳入的state值(on或者off)執(zhí)行status = ppu_set_state_and_wait(ppu_ctx, mode);最后執(zhí)行reg->POWER_POLICY = (uint32_t)mode;進(jìn)行寄存器設(shè)置生效。
7) scmi_power_domain模塊-返回結(jié)果:最后調(diào)用scmi_pd_ctx.scmi_api->respond(service_id, &return_values,....)到scmi 模塊。
8) scmi模塊:scmi中api的respond函數(shù)將會(huì)通過service_id查表service_ctx_table獲取transport信息,然后調(diào)用ctx->respond(ctx->transport_id, payload, size),為msg_smt模塊中respond api()(注transport_id在config_scmi.c 中配置。指定transport為smt模塊+smt內(nèi)的具體channel element元素))。
9)transport模塊:msg_smt模塊中的respond api為smt_respond()函數(shù)。通過上一級(jí)傳入的transport_id/channel_id的element_idx部分,查表smt_ctx.channel_ctx_table獲取channel消息。 然后填充Shared Memory,并調(diào)用channel_ctx->driver_api->raise_interrupt(channel_ctx->driver_id)產(chǎn)生中斷,通知agent。
10.)mhu模塊產(chǎn)生中斷:raise_interrupt()函數(shù)中,根據(jù)slot_id找到設(shè)備上下文,然后對寄存器進(jìn)行設(shè)置reg->SET |= (1U << slot);。
從上面可以看到,scmi的處理流程基本是通用的,涉及到不同平臺(tái)的就是最后硬件的設(shè)置,需要新建一個(gè)juno_ppu模塊-寄存器設(shè)置,及其配置文件。
SCP中scmi協(xié)議處理:
系統(tǒng)支持兩種agent:PSCI和OSPM,發(fā)來的SCMI消息根據(jù)protocol_id進(jìn)行分類,然后根據(jù)message_id子命令找到合適的處理函數(shù),最后根據(jù)message_type決定是否進(jìn)行回復(fù)。 關(guān)于SCMI協(xié)議的一些參數(shù)定義可以參考代碼:
module/scmi/include/mod_scmi_std.h
例如上面我們介紹過0x11 power domain,其他的處理過程相似可以通過下面表速查到相關(guān)模塊,從模塊的static int (*handler_table中根據(jù)message_id下標(biāo)迅速找到處理函數(shù):
protocol_id | 描述 | 涉及模塊及處理代碼 |
0x10 | Base protocol | module/scmi/src/mod_scmi_base.c |
0x11 | Power domain management protocol | module/scmi_power_domain/src/mod_scmi_power_domain.c |
0x12 | System power management protocol | module/scmi_system_power/src/mod_scmi_system_power.c |
0x13 | Performance domain management protocol | module/scmi_perf/src/mod_scmi_perf.c |
0x14 | Clock management protocol | module/scmi_clock/src/mod_scmi_clock.c |
0x15 | Sensor management protocol | module/scmi_sensor/src/mod_scmi_sensor.c |
0x16 | Reset domain management protocol | module/scmi_reset_domain/src/mod_scmi_reset_domain.c |
0x17 | Voltage domain management protocol | module/scmi_voltage_domain/src/mod_scmi_voltage_domain.c |
0x18 | Power capping and monitoring protocol | 不支持 |
0x19 | Pin Control protocol | 不支持 |
4. PPU的電源控制
0x11 | Power domain management protocol | module/scmi_power_domain/src/mod_scmi_power_domain.c |
0x12 | System power management protocol | module/scmi_system_power/src/mod_scmi_system_power.c |
0x11 pd,0x12 system是通過power domain模塊,然后到PPU模塊進(jìn)行電源控制的。關(guān)于PPU可以去PCSA規(guī)范中查看,PPU是一個(gè)硬件模塊,SCP通過PPU去控制具體的時(shí)鐘、電源等硬件。PPU類型如下所示:
enum mod_pd_type {
MOD_PD_TYPE_CORE,
MOD_PD_TYPE_CLUSTER,
MOD_PD_TYPE_DEVICE,
MOD_PD_TYPE_DEVICE_DEBUG,
MOD_PD_TYPE_SYSTEM,
MOD_PD_TYPE_COUNT
};
這里舉例CPU COER的電源硬件控制,其他的自己看代碼。
MOD_PD_TYPE_CORE的處理api為core_pd_driver_api,如下:
static const struct mod_pd_driver_api core_pd_driver_api = {
.set_state = core_set_state,
.get_state = pd_get_state,
.reset = core_reset,
.prepare_core_for_system_suspend = core_prepare_core_for_system_suspend,
};
core_set_state:
首先根據(jù)ppu_id拿到上下文參數(shù)(config_juno_ppu.c中定義),然后根據(jù)要設(shè)置的state進(jìn)行分開處理:
static int core_set_state(fwk_id_t ppu_id, unsigned int state) {
get_ctx(ppu_id, &ppu_ctx);
dev_config = ppu_ctx->config;
mode = pd_state_to_ppu_mode[state];
switch ((enum mod_pd_state)state) {
case MOD_PD_STATE_OFF:
//設(shè)置PPU狀態(tài),并等待生效
status = ppu_set_state_and_wait(ppu_ctx, mode);
//清空這個(gè)PPU對應(yīng)的中斷消息
status = clear_pending_wakeup_irq(dev_config);
//關(guān)閉這個(gè)PPU對應(yīng)的中斷消息
status = disable_wakeup_irq(dev_config);
//關(guān)閉軟重啟中斷消息
status = fwk_interrupt_disable(dev_config->warm_reset_irq);
break;
case MOD_PD_STATE_SLEEP:
status = ppu_set_state_and_wait(ppu_ctx, mode);
status = clear_pending_wakeup_irq(dev_config);
status = enable_wakeup_irq(dev_config);
status = fwk_interrupt_disable(dev_config->warm_reset_irq);
break;
case MOD_PD_STATE_ON:
status = fwk_interrupt_clear_pending(dev_config->warm_reset_irq);
status = fwk_interrupt_enable(dev_config->warm_reset_irq);
status = ppu_set_state_and_wait(ppu_ctx, mode);
break;
default:
fwk_unexpected();
status = FWK_E_PANIC;
break;
}
//power_domain模塊中api調(diào)用,對這個(gè)pd進(jìn)行訂閱的模塊會(huì)收到電源變化通知
status = ppu_ctx->pd_api->report_power_state_transition(ppu_ctx->bound_id,
state);
return FWK_SUCCESS;
}·
ppu_set_state_and_wait(ppu_ctx, mode);中設(shè)置PPU的mode,首先mode的轉(zhuǎn)化如下:
static enum ppu_mode pd_state_to_ppu_mode[] = {
[MOD_PD_STATE_OFF] = PPU_MODE_OFF,
[MOD_PD_STATE_SLEEP] = PPU_MODE_OFF,
[MOD_PD_STATE_ON] = PPU_MODE_ON,
[MOD_SYSTEM_POWER_POWER_STATE_SLEEP0] = PPU_MODE_MEM_RET,
};
ppu_set_state_and_wait()函數(shù)中,對于mode的設(shè)置:
static int ppu_set_state_and_wait(struct ppu_ctx *ppu_ctx, enum ppu_mode mode)
{
//對寄存器進(jìn)行設(shè)置
reg = ppu_ctx->reg;
reg->POWER_POLICY = (uint32_t)mode;
//根據(jù)配置信息等待PPU設(shè)置完成
dev_config = ppu_ctx->config;
params.mode = mode;
params.reg = reg;
if (fwk_id_is_equal(dev_config->timer_id, FWK_ID_NONE)) {
/* Wait for the PPU to set */
while (!set_power_status_check(?ms)) {
continue;
}
}
對于中斷的控制通過framework/src/fwk_interrupt.c中對外函數(shù)
int fwk_interrupt_disable(unsigned int interrupt)
{
if (!initialized) {
return FWK_E_INIT;
}
return fwk_interrupt_driver->disable(interrupt);
}
fwk_interrupt_driver在arch/arm/arm-m/src/arch_nvic.c中實(shí)現(xiàn):
static int disable(unsigned int interrupt)
{
if (interrupt >= irq_count) {
return FWK_E_PARAM;
}
NVIC_DisableIRQ((enum IRQn)interrupt);
return FWK_SUCCESS;
}
__STATIC_INLINE void __NVIC_DisableIRQ(IRQn_Type IRQn)
{
if ((int32_t)(IRQn) >= 0)
{
NVIC->ICER[(((uint32_t)IRQn) >> 5UL)] = (uint32_t)(1UL << (((uint32_t)IRQn) & 0x1FUL));
__DSB();
__ISB();
}
}
對硬件寄存器進(jìn)行了設(shè)置。
其他:
SCP入門系列就算講完了,有規(guī)范有源碼,有一點(diǎn)缺陷就是沒用qmeu運(yùn)行起來,官方也沒給出,只說用ARM的Fixed Virtual Platform (FVP)能運(yùn)行,不熟悉操作起來估計(jì)有點(diǎn)費(fèi)勁對PC要求也高,這個(gè)SCP也比較小眾在大規(guī)模的SoC上才有應(yīng)用,提出的挺早但是應(yīng)用的還是不多。其實(shí)找一個(gè)qemu支持的板子,把代碼改一改應(yīng)該也能運(yùn)行起來,有興趣的可以自己嘗試下。
本文轉(zhuǎn)載自微信公眾號(hào)「OS與AUTOSAR研究」,可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請聯(lián)系公眾號(hào)。