萬子長文和你一起探索Arm調(diào)試架構(gòu)

這是一篇關(guān)于Coresight很重磅的文章。

相信會(huì)解決你在學(xué)習(xí)Coresight過程中的一些的困惑，同時(shí)也會(huì)讓你對調(diào)試有一個(gè)更深入的了解。

【芯片DFX】萬字長文帶你搞懂JTAG的門門道道

【芯片DFX】ARM：CoreSight、ETM、PTM、ITM、HTM、ETB等常用術(shù)語解析

【芯片DFX】Coresight架構(gòu)——原名：來跟著前輩看看coresight

【芯片DFX】Coresight的寄存器

【芯片DFX】Coresight-APB，ATB總線

【芯片DFX】Coresight-Power requestor

【芯片DFX】Coresight-channel interface

【芯片DFX】Coresight-coresight的兩大功能

【芯片DFX】Coresight-Rom Table

【芯片DFX】Coresight-Soc 400套件

排版真的也是個(gè)麻煩事，不吐槽了，那么上車吧！

Glossary

Term	Meaning
ADI	Arm Debug Interface
AON	Always-ON
AP	Access Port
ARM	Architectural Reference Manual
BPU	BreakPoint Unit
CTI	Cross Trigger Interface
DAP	Debug Access Port
DP	Debug Port
DWT	Data Watchpoint and Trace
ED	External Debug
ETM	Embedded Trace Macrocell
ETE	Embedded Trace Extension
PPU	Power Policy Unit
SCP	System Control Processor
TRM	Technical Reference Manual

Perface

Arm對debug架構(gòu)的定義分散在三個(gè)文檔中：

Arm ARM[1]作為指令集手冊，對處理器內(nèi)部的debug/trace功能進(jìn)行了定義，這也是debug調(diào)試架構(gòu)的基石

Coresight[2] 架構(gòu)定義了與Arm處理器相兼容的debug/trace行為，本質(zhì)上是Arm架構(gòu)中debug feature的外延

ADI[3]架構(gòu)定義了Arm-based SoC與外部的物理連接（JTAG/SWD）規(guī)范

ADI—Arm Debug Interface

Coresight這個(gè)名字的含義意在給用戶提供一種對內(nèi)核的可見性（visibility）。

包括Arm自己的舊版設(shè)計(jì)套件RealView，以及RISC-V陣營的Sifive Insight都表達(dá)了同樣的含義

熟悉這三個(gè)文檔的讀者會(huì)覺得這三者看起來分工明確，能夠很好地達(dá)成在SoC中構(gòu)建一個(gè)統(tǒng)一的Arm-style debug infrastructure的目的。

然而站在一個(gè)初學(xué)者的角度，這種分散的架構(gòu)可能讓人摸不著頭腦。

特別是，在制訂一個(gè)獨(dú)立于Arm ARM的debug文檔的前提下，Arm提出了兩個(gè)而不是一個(gè)統(tǒng)一的文檔在直覺上令人費(fèi)解。

再考慮到Coresight與ADI的架構(gòu)文檔有著一定篇幅的重復(fù)，以及兩者混亂的兼容關(guān)系，

這種費(fèi)解只會(huì)進(jìn)一步加深。這個(gè)局面在一定程度上是由于Coresight與ADI的在歷史上的出現(xiàn)順序決定的。

要明確的一點(diǎn)是，Coresight的出現(xiàn)是為了解決首先在ARM11被引入的多核架構(gòu)調(diào)試的問題。

在此之前，由Arm架構(gòu)定義的debug feature已經(jīng)足夠應(yīng)付單核調(diào)試場景，屆時(shí)的debug interface是完全基于JTAG scan chain的做法。也就是說，ADI在Coresight沒有問世之前就已經(jīng)存在。

當(dāng)Coresight出現(xiàn)之后，Arm為了做到使ADI做到向前兼容，沒有將其簡單地合并進(jìn)Coresight。

這樣一來，ADI在架構(gòu)上就兼容了新興的多核Coresight架構(gòu)與ARM7, ARM9那些所謂的legacy scan chain-based（非Coresight）架構(gòu)。

前者使用ADI中的MEM-AP訪問，后者則使用JTAG-AP訪問，這也ADI文檔中AP拓?fù)浣Y(jié)構(gòu)圖的含義之一。

Figure 0-1 DAP topology in ADI

原來是這個(gè)原因！

反過來，Coresight架構(gòu)的范疇是包含了一個(gè)符合ADI架構(gòu)的DAP實(shí)現(xiàn)在內(nèi)的。

即，Coresight架構(gòu)規(guī)定必須使用ADI complaint的port對其組件進(jìn)行調(diào)試，而ADI架構(gòu)則表明ADI架構(gòu)的實(shí)現(xiàn)不一定是用來調(diào)試Coresight組件。

下面以一個(gè)簡化SoC中的debug function框圖來表明Arm ARM/Coresight/ADI這三種架構(gòu)在一個(gè)真實(shí)系統(tǒng)中的所負(fù)責(zé)的范圍，以及它們之間的關(guān)系。

Figure 0-2 Debug architecture in a real system

橙色是AD define

如圖注所示，這張示意圖中的三種主要顏色分別代表了三種架構(gòu)定義的實(shí)現(xiàn)。

Core內(nèi)的debug/trace unit function是由Arm ARM定義的，如debug breakpoint/watchpoint或是ETM/ETE的實(shí)現(xiàn)，但它們在圖中的特殊標(biāo)記表明它們**具備Coresight所定義的一系列寄存器（PIDx/CIDx）**來支持Coresight系統(tǒng)的topology detection。

另一類用拼接色來表示的則是表明兩種架構(gòu)中都對該部件有相關(guān)的描述。

對于CTI在不同的地方有不同的著色方案，我想表達(dá)的是，CTI本身雖然是一種模塊化、可復(fù)用的設(shè)計(jì)，但具體的使用方法卻是與被部署的設(shè)計(jì)息息相關(guān)的。

例如在A Core中，它一般會(huì)被配置為debug request/restart等幾個(gè)固定的事件。

而在非Arm架構(gòu)的Processing Unit中，則需要設(shè)計(jì)者自行將感興趣的信號與其連接。

這也是為什么圖中Heterogeneous Cluster的CTI與Arm ARM無關(guān)。剛剛有講到，上圖中的部件均是架構(gòu)的具體實(shí)現(xiàn)。

對應(yīng)Arm的產(chǎn)品線，我們可以認(rèn)為Coresight架構(gòu)的實(shí)現(xiàn)是Coresight SoC系列IP，而ADI架構(gòu)的實(shí)現(xiàn)則是DP/AP（也被包含在Coresight SoC中）。

也就是圖中虛線框起來的部分，都屬于Coresight SoC組件的范疇，這個(gè)package往往與core一起license給客戶——對應(yīng)地，core是Arm架構(gòu)的實(shí)現(xiàn)。

Arm架構(gòu)中的debug feature與處理器無論在結(jié)構(gòu)還是行為上都有著耦合關(guān)系，而Coresight & ADI更像是從一個(gè)個(gè)給定的function unit逆向出來的架構(gòu)。

本文接下來分別在Arm debug feature以及Coresight & ADI這兩個(gè)層面中來討論一些我覺得值得注意的或是曾經(jīng)困擾過我的問題。

1 Arm Debug Feature

1.1 debug register interface

各種形式的debug的最終目的都是獲取core的狀態(tài)，控制core的行為。

這都是通過對core內(nèi)的debug register進(jìn)行讀寫來實(shí)現(xiàn)的。

因此首先討論debug register interface，主要回答兩個(gè)問題：

這些register是如何被訪問的？

可以被誰訪問？

對于硬件工程師來說，直覺上首先會(huì)想到core內(nèi)的相關(guān)寄存器需要能夠被外部調(diào)試器訪問，Arm稱之為external debug interface，這是通過調(diào)試器控制DAP向core發(fā)起APB transfer來實(shí)現(xiàn)的。

由于調(diào)試器此時(shí)訪問的并不是內(nèi)存區(qū)域，因此需要一個(gè)機(jī)制來獲取debug register的地址，這個(gè)機(jī)制就是ROM Table。

ROM Table存放組件地址的字段是一組只讀的寄存器堆，每個(gè)entry保存著一個(gè)[x:12]的地址用以指向某一個(gè)組件。

即每一個(gè)組件占用4KB的地址空間，這個(gè)地址空間是用來存放這個(gè)組件的寄存器的。

core內(nèi)每一個(gè)具有 external debug interface 的unit，如debug/trace/pmu等，都分別作為一個(gè)組件被索引。

下面以訪問一個(gè)DynamIQ Cluster內(nèi)的Cortex-A core為例來說明這種機(jī)制：

Figure 1-1 Debug components in DynamIQ Cluster

圖中，與DP相連接的ROM Table稱為DP ROM，它一般處于地址0x0的位置，用以發(fā)現(xiàn)系統(tǒng)中的MEM-APs。

針對訪問Cluster的這條通路（對于A core一般使用APB-AP），會(huì)另有一個(gè)Cluster level ROM Table，它的地址等于它所在的APB-AP基地址+0 offset，用以發(fā)現(xiàn)這個(gè)APB-AP子系統(tǒng)內(nèi)的debug資源。

上圖是一個(gè)簡化的示意，在實(shí)際的A core SoC中，從DP ROM到最終的Cluster level ROM Table中可能有更多的嵌套，下圖是一個(gè)來自Arm Corstone SSE-710 Subsystem[4]的例子：

Figure 1-2 ROM table structure of SSE-710

我將圖1-1中DP ROM，APB-AP和Cluster level ROM Table所對應(yīng)的位置在上中進(jìn)行了標(biāo)注。

SSE-710中的"Host"代指AP (Application Processor)。從DP到Host CPU這條通路上，與圖1-1相比，多出Host ROM和EXTDBGROM。

Host ROM在指向Cluster level ROM Table之外，還可以指向AP subsystem中的Coresight組件（大致是圖0-2虛線框中的綠色部分）；

EXTDBGROM則是在DP ROM和MEM-APs中間插了一級，使DP ROM除了可以指向MEM-APs之外，還可以指向GPIO或APBCOM（與secure debug相關(guān)，下文介紹）。

Arm core的TRM中會(huì)給出external debug memory map。以A53[5]為例，它在MPcore配置下最多有4個(gè)core：

Figure 1-3 Cortex-A53 external debug memory map

接下來討論debug register的另一種接口。考慮對圖1-1做一個(gè)簡單的補(bǔ)充：從interconnect出一個(gè)APB口繞回APB-AP所訪問的子系統(tǒng)的入口，如下圖。

Figure 1-4 Debug components in DynamIQ Cluster

這種路由為core提供了對某個(gè)子系（也可以擴(kuò)展到整個(gè)SoC）內(nèi)debug資源的可見性，Arm稱之為 memory-mapped interface。

本質(zhì)上這種接口只是復(fù)用了external debug interface，對于debug register本身并沒有增加額外的接口。

通過將external debug memory map映射到系統(tǒng)的memory map中，core可以在不依賴外部調(diào)試器的情況下訪問這些debug register。

觀察集成了A53的Juno SoC[6]的memory map，可以看到從0x2300_0000地址開始與A53的external debug memory map是對的上的，一點(diǎn)小區(qū)別是Juno SoC在A53 reserve區(qū)域插了一些Coresight組件進(jìn)去。

Figure 1-5 Arm Juno SoC memory map

external debug memory map在硬件層面對on-chip debug提供了支持，而在實(shí)際的on-chip debug中，Arm更強(qiáng)調(diào)（區(qū)別于external debug的）另一種調(diào)試模型，即self-hosted debug。

這個(gè)模型在下一小節(jié)將進(jìn)行單獨(dú)討論，此處闡述它對debug register interface產(chǎn)生的影響——引入了第三種接口，一般稱為 system register interface，即系統(tǒng)寄存器接口。

系統(tǒng)寄存器是提供Arm架構(gòu)功能的具象實(shí)體，通過專用指令進(jìn)行訪問。system register interface 為software debugger訪問debug資源提供了更便捷的路徑，考慮到debug register的敏感性，大部分具備系統(tǒng)寄存器接口的debug register都要求EL1及其以上的特權(quán)級別。

因此此處的"software debugger"一般也代指內(nèi)核層面的debug agent，如linux gdb.

1.2 self-hosted debug

如上文所述，self-hosted debug是Arm架構(gòu)定義的兩種調(diào)試模型之一。

這兩種模型并不是面對同一需求可以互相替換的不同選擇，它們一般被認(rèn)為使用在不同的場景中：

1-external debug

external debug 主要被使用在bare metal的調(diào)試場景中，用于硬件debug或是軟件的bring-up。

使用external debug需要將芯片通過IO連接到一個(gè)debug probe(JLink/DSTREAM)，進(jìn)而連接到一臺Host主機(jī)，以運(yùn)行在主機(jī)上的開發(fā)環(huán)境作為debugger。

"Bare metal"的調(diào)試場景通常指的是一種無虛擬化或無操作系統(tǒng)的調(diào)試環(huán)境。在這種環(huán)境中，調(diào)試工具可以直接訪問硬件資源，如內(nèi)存、處理器和輸入/輸出設(shè)備等，以進(jìn)行更接近實(shí)際的調(diào)試。

在Bare metal調(diào)試場景中，調(diào)試器可以直接與硬件交互，無需通過虛擬化層或操作系統(tǒng)進(jìn)行轉(zhuǎn)換。這使得調(diào)試過程更加高效，并且可以更好地模擬實(shí)際運(yùn)行環(huán)境中的硬件行為。

Bare metal調(diào)試通常用于嵌入式系統(tǒng)開發(fā)、低級硬件調(diào)試、驅(qū)動(dòng)程序開發(fā)等領(lǐng)域。在這種環(huán)境中，開發(fā)人員可以直接訪問硬件資源，對系統(tǒng)進(jìn)行底層調(diào)試和優(yōu)化，以確保系統(tǒng)在真實(shí)環(huán)境中的穩(wěn)定性和性能。

需要注意的是，Bare metal調(diào)試需要特殊的硬件和軟件工具，如JTAG調(diào)試器、串口調(diào)試器等，以便訪問和控制硬件資源。同時(shí)，由于Bare metal調(diào)試需要直接與硬件交互，因此需要一定的技術(shù)知識和經(jīng)驗(yàn)，以避免不正確的操作導(dǎo)致硬件損壞或系統(tǒng)不穩(wěn)定。

2-self-hosted deug

self-hosted deug 主要被使用在已經(jīng)部署OS的系統(tǒng)中，用于軟件debug。使用self-hosted deug無需構(gòu)建芯片與外部的連接，以內(nèi)核/exception handler作為debugger。

包括我在內(nèi)的硬件工程師普遍對前者更熟悉一些，因?yàn)槲覀冊谝豢钚酒拈_發(fā)周期中處于比較「靠左」的位置。

當(dāng)SoC被OEM集成時(shí)，極有可能不會(huì)留出JTAG接口（有些開發(fā)板甚至都沒有），因此使軟件開發(fā)者在不借助debug probe的情況下進(jìn)行on-chip debug是必要的。

需要注意這里所說的on-chip debug并不代表不需要借助任何外部設(shè)備。Arm在介紹self-hosted debug時(shí)常以基于gdb的remote debug為例[7]，如下圖。

Figure 1-6 Self-hosted debug model

在這種情況下，除了被調(diào)試的debug target外，還需要一臺額外的host主機(jī)來協(xié)助調(diào)試工作。

兩種調(diào)試模型最本質(zhì)的差異在于debug event（如一次breakpoint match）觸發(fā)后的不同行為：

在external debug模型下，core會(huì)進(jìn)入halt狀態(tài)，將控制權(quán)交給external debugger，后者此時(shí)可以通過DCC寄存器獲取core的內(nèi)部狀態(tài)；

通過DCC寄存器進(jìn)行調(diào)試，可以修改架構(gòu)寄存器的狀態(tài)、讀寫memory等。DCC是調(diào)試通信通道（debug communication channel）的簡稱，它允許PE（處理器單元）與外部調(diào)試器進(jìn)行通信。在調(diào)試狀態(tài)下，調(diào)試器使用ITR（指令傳遞寄存器）通過外部調(diào)試接口將指令傳遞給PE，使其執(zhí)行指令。使用通過ITR執(zhí)行的指令，調(diào)試器可以讀寫架構(gòu)寄存器，例如通用目的寄存器、系統(tǒng)寄存器和浮點(diǎn)寄存器，也可以讀寫memory。

而在self-hosted deug模型下，core會(huì)上報(bào)異常并陷入對應(yīng)的EL級別進(jìn)行異常處理。

在debug exception routing上，Arm定義了多種細(xì)分模型：

Application debugging：EL0 exception trap to EL1 debugger

Kernel debugging：EL0/EL1 exception trap to EL1 debugger

OS debugging：EL0/EL1 exception trap to EL2 debugger

Hypervisor debugging：EL0/EL1/EL2 exception trap to EL2 debugger

據(jù)我所知，基于gdb的兩種remote調(diào)試方法，即host gdb+target gdbserver（如圖1-6）和host gdb+target kgdb可以分別對應(yīng)上Application debugging和Kernel debugging這兩種模型。

其中，gdbserver作為用戶態(tài)程序，通過內(nèi)核的ptrace接口陷入內(nèi)核；而kgdb本身運(yùn)行在內(nèi)核態(tài)，具備直接調(diào)試內(nèi)核代碼的能力。

kgdb在2.6.25之后被合并進(jìn)內(nèi)核，并且需要架構(gòu)的支持。

我們以self-hosted debug模型下的單步調(diào)試機(jī)制為例，簡單追溯一下kgdb與Arm架構(gòu)代碼之間的層次關(guān)系。

與external debug類似，Arm ARM中也給self-hosted debug的單步調(diào)試畫了一張狀態(tài)機(jī)的圖，即下面的圖1-7。

MDSCR_EL1.SS是單步調(diào)試的全局使能，而PSTATE.SS是一個(gè)狀態(tài)位。從圖中可以看出的是，當(dāng)core正在處于（由一個(gè)debug event，比如breakpoint，觸發(fā)的）debug exception中時(shí)，可以通過設(shè)置MDSCR_EL1.SS和PSTATE.SS都為1來讓core在退出exception時(shí)進(jìn)入單步調(diào)試，并在執(zhí)行完一條指令后并重新觸發(fā)debug exception，這就完成了一次單步調(diào)試。

Arm架構(gòu)中在external debug和self-hosted debug兩種模型下都提供單步調(diào)試機(jī)制，對于一次單步調(diào)試過程，兩種機(jī)制對比如下：

對于software step：PE in exception -> 配置software step -> exception return -> 執(zhí)行一條指令 -> software step exception -> re-enty exception

對于halting step：PE in halt state -> 配置halting step -> exit halt state -> 執(zhí)行一條指令 -> halting step debug event -> re-entry halt state

Figure 1-7 Software step state machine

對應(yīng)地，來看linux kernel的實(shí)現(xiàn)。先給出一張總體關(guān)系圖：

kernel/debug 目錄下存放著不區(qū)分架構(gòu)的gdb頂層（底層？）實(shí)現(xiàn)。

kernel/debug/gdbstub.c 文件中的gdb_serial_stub()函數(shù)提供了remote gdb通信中command/packet（c for continue, s for step, etc.）的處理功能，這里的場景是調(diào)試停在某處并等待用戶在終端輸入命令，實(shí)際上對應(yīng)上段中core處于debug exception的狀態(tài)。

對s命令的處理，gdb_serial_stub() 會(huì)調(diào)用架構(gòu)定義的kgdb_arch_handle_exception() 函數(shù)，因此這個(gè)函數(shù)會(huì)來到 arch/arm/kernel 目錄下。

kgdb_arch_handle_exception() 主要做了兩件事來完成s命令：

一是利用kgdb_arch_update_addr() 嘗試從命令packet中獲取數(shù)據(jù)來更新PC，這里看注釋很容易產(chǎn)生一個(gè)誤解，PC不是在exception entry時(shí)復(fù)制到ELR嗎，怎么反過來了呢？

這是由于注釋中提到的PC指的是內(nèi)核堆棧中的處理器狀態(tài)，而不是硬件意義上的PC寄存器，這里的linux regs實(shí)際上是pt_regs這個(gè)struct。

所以此處的意圖是通過更改pt_regs.pc來更改ELR中的內(nèi)容，并在exception return時(shí)跳到ELR指定的地址，對應(yīng)了單步調(diào)試狀態(tài)機(jī)中 "Programs the ELR_ELx ..." 這一步。

但對于單步調(diào)試來說，一般情況下并不會(huì)改寫PC。

接下來來到函數(shù)的第二部分，即調(diào)用kernel_enable_single_step() 來使能單步調(diào)試。

通過單步調(diào)試狀態(tài)機(jī)可以看出，使能的過程是通過訪問system register來實(shí)現(xiàn)的，因此這一步是架構(gòu)定義的。

這個(gè)函數(shù)的實(shí)現(xiàn)在同目錄的另一個(gè)文件debug-monitors.c中。kernel_enable_single_step() 的實(shí)現(xiàn)就比較明了了，即把MDSCR.SS和PSTATE.SS（即SPSR.SS）都設(shè)為1，使得core能從一個(gè)inactive的exception中return到active-not-pending的狀態(tài)。

至于那個(gè)enable_debug_monitors() 的功能，目前看起來不明所以，這個(gè)以后研究明白再來補(bǔ)上。

1.3 debug over powerdown

有些讀者可能會(huì)對圖1-4中的拓?fù)洚a(chǎn)生疑惑，什么是DebugBlock？

它實(shí)際上是一個(gè)獨(dú)立于cpu cluster的功能單元，這種將部分debug功能從cluster中分離出去的做法隨著DynamIQ開始使用，目的是更好地支持debug over powerdown. 那么，何謂「更好地支持」？

前序版本中的debug架構(gòu)有什么題？這是這一小節(jié)主要討論的問題。

Figure 1-4 Debug components in DynamIQ Cluster

早在Arm ARM v7-A的debug章節(jié)中，就已經(jīng)出現(xiàn)對powerdown support的介紹。

它的含義并不是在core powerdown時(shí)進(jìn)行調(diào)試——這是無論如何也做不到的——而是可以支持對具備電源關(guān)斷能力的軟件（or，運(yùn)行在具備電源關(guān)斷能力的OS上的軟件）的調(diào)試。

所謂「支持」指的是保存一些關(guān)鍵debug register的內(nèi)容，如與上下電過程相關(guān)的控制位或是供外部debugger識別用的信息。

這些信息的丟失將使斷電前后的debug設(shè)置不一致，**亦或是使在斷電時(shí)使外部debugger丟失與cpu的連接，**從而打斷一個(gè)完整的調(diào)試過程。

由于OSPM對power domain所采取的行動(dòng)往往是脫離調(diào)試者的控制的，如果不具備powerdown support，難免會(huì)出現(xiàn)在未達(dá)到調(diào)試目的之前就被powerdown頻繁地打斷調(diào)試過程的情況。

并不是所有debug register都需要做powerdown的保存。對于那些不會(huì)參與到上下電流程中的信息，依賴于OS Save and Restore過程來保證不會(huì)丟失。

v7-A通過區(qū)分core power domain和debug power domain來實(shí)現(xiàn)這種支持，下圖中的Core domain Vdd和Debug domain Vdd示意了這種區(qū)分，需要保存的寄存器被放置在Debug power domain。

同時(shí)由于兩個(gè)domain可以被分別gating，容易想到可以通過debug domain請求core domain上電，三個(gè)加粗的信號與這一機(jī)制相關(guān)。

Figure 1-9 Recommended power domain split between core and debug power domains

這種解決方式看起來萬事大吉，以至于到早期的v8-A中仍在沿用，那為什么會(huì)搞出DebugBlock這個(gè)東西呢？Arm并沒有對此給出過解釋，在此我僅根據(jù)公開資料做一些推測。

Arm Community有一篇關(guān)于Juno SoC的博客[8]，第一部分講的是debugger連接不穩(wěn)定的問題。

Juno是采用A72/A57+A53的配置，屬于我所說的「早期的v8-A」，查閱它們的TRM，可以發(fā)現(xiàn)是均支持獨(dú)立的debug power domain的。那為什么還會(huì)發(fā)生這個(gè)問題呢？

這個(gè)博客提了一句，這個(gè)問題與linaro 14.10中cpuidle enable有關(guān)。cpuidle是OSPM中的一個(gè)概念，即OS將沒有任務(wù)的cpu置入低功耗狀態(tài)，對應(yīng)到硬件power control實(shí)現(xiàn)，可能有retention/powerdown等不同的處理方式。

而在2014年前后，cluster idling[9]被正式合并到linux的power management中。所謂cluster idling，就是指傳統(tǒng)cpuidle對arm big.LITTLE拓?fù)涞囊淮涡拚蛊淠軌蛟谝粋€(gè)cluster內(nèi)所有core都idle后有機(jī)會(huì)將cluster idle.

然而，對于一個(gè)包含cores+L2/3 cache+misc. (debug for example) 的cluster模型，雖然cluster內(nèi)的一些邏輯可能在硬件實(shí)現(xiàn)角度可以單獨(dú)power gating，但OSPM在調(diào)控過程中未必有與之相匹配的粒度。

對于Juno SoC而言，我認(rèn)為cluster idling可能直接導(dǎo)致了它設(shè)計(jì)在cluster內(nèi)部的debug power domain隨著cluster進(jìn)入idle一起掉電，從而導(dǎo)致了前面所說的問題。

因此DebugBlock出現(xiàn)了。它算不上是多大的改動(dòng)，因?yàn)槔锩娴臇|西還是那些，只不過在hierarchy上完全脫離cluster. 像A55 TRM中描述的：

It allows you to put the DebugBlock in a separate power domain and place it physically with other CoreSight logic in the SoC, rather than close to the cluster.

當(dāng)然，TRM中也提到：

If the DebugBlock is in the same power domain as the core, then debug over powerdown is not supported.

從這里也可以看出，Powerdown support并不是必須的。這個(gè)feature總體的思路就是v7-A中劃分power domain的那一套，當(dāng)這種劃分出了某種問題時(shí)，就變換一個(gè)方式再次使這種劃分成為可能。

2 Coresight & ADI

由于大部分Coresight & ADI的定義都能在Coresight SoC中找到對應(yīng)的實(shí)例參考，所以首先對它進(jìn)行背景介紹。

Arm目前提供兩個(gè)版本的Coresight SoC，分別是400系列和600系列。

它們分別代表對不同版本的Coresight & ADI架構(gòu)的實(shí)現(xiàn)：

SoC-400實(shí)現(xiàn)了Coresight v2以及ADI v5.2

SoC-600則實(shí)現(xiàn)了Coresight v3以及ADI v6.

Year	Coresight SoC	Coresight arch	ADI arch
2012	SoC-400 (r1p0)	v2.0	v5.2
2017	SoC-600	v3.0	v6.0

Arm core本身同樣需要兼容Coresight & ADI架構(gòu)。與SoC-600同時(shí)更新Coresight v3以及ADI v6不同，ADIv6在Arm core中的兼容會(huì)更晚些，直到v9-A時(shí)才開始。

需要注意，沒有兼容ADIv6僅僅代表這些core在設(shè)計(jì)時(shí)沒有兼容ADIv6中某些新型拓?fù)洌玈oC-600是向后兼容的，可以結(jié)合任意Arm core進(jìn)行設(shè)計(jì)。

Year	A-series core	Coresight arch	ADI arch
2016	A73	v2.0	v5.2
2017	A75/A55	v3.0	v5.2
2018	A76	v3.0	v5.2
2019	A77	v3.0	v5.2
2020	A78	v3.0	v5.2
2021	A710/510	v3.0	v6.0

2.1 DAP topology

所謂的DAP拓?fù)渲傅木褪荄P和一個(gè)或多個(gè)AP如何組成DAP，以及DAP如何接入cpu subsystem。ADIv6給DAP拓?fù)鋷砹艘恍┘?xì)微但可能影響較大的變化，本小節(jié)主要聚焦于這些變化

一些關(guān)于Coresight SoC-600的新聞稿[10]上聲稱，這個(gè)套件的發(fā)布帶來了「下一代」調(diào)試解決方案。

結(jié)合下面這張圖，我們了解到，所謂的「下一代」調(diào)試，指的是不依賴于傳統(tǒng)JTAG/SWD接口（復(fù)用functional ports如圖中的PCIe/USB）就能使debugger接入調(diào)試系統(tǒng)的能力。

Figure 2-1 Coresight SoC-600

然而，如果翻開SoC-600或是ADIv6的TRM，會(huì)發(fā)現(xiàn)找不到任何為適配新端口所設(shè)計(jì)的新組件——新架構(gòu)目前只是對DP/AP的結(jié)構(gòu)進(jìn)行了調(diào)整，為不依賴JTAG/SWD調(diào)試端口的調(diào)試提供了系統(tǒng)支持。

參考ADIv6中的這段話：

ADIv6 permits debug links other than JTAG or SWD to access the AP layer, so that multiple different links can be used to access debug functionality.

"A1.3 The debug link" 這一節(jié)對ADIv6的改進(jìn)做了概述。debug link本身是個(gè)新詞，代指不局限于DP的，更廣義的物理接口與協(xié)議層的實(shí)現(xiàn)。

A1.3的第一句話就提到，debug link提供了對AP的memory-mapped視角——這與ADIv5.2的設(shè)計(jì)不完全一致，我們首先來看ADIv5.2中DP to AP的訪問方式。

DP如何訪問AP，本質(zhì)上取決于AP的programmer's model，也就是AP寄存器的設(shè)計(jì)。通過C2.5節(jié)的這個(gè)表格我們得知，ADIv5.2中的AP（即APv1）寄存器處在一個(gè)8bit寬的地址空間中。

Figure 2-2 MEM-AP programmer's model in ADIv5.2

ADIv5.2 DP（DPv2）通過SELECT.APBANKSEL[7:4]位結(jié)合一次APACC request的A[3:2]位，對這個(gè)8bit地址空間內(nèi)的寄存器進(jìn)行尋址。

同時(shí)，SELECT寄存器的高位APSEL[31:24]用來選擇不同的AP。下圖給出了這套訪問機(jī)制的示意。圖中高亮的部分共同構(gòu)成了DP發(fā)出的地址。

Figure 2-3 Structure of an ADIv6 implementation

通過上圖可以看出，對于一個(gè)DP+多個(gè)AP的系統(tǒng)，需要一個(gè)APSEL decoder作為中間層。這個(gè)中間層在Coresight SoC-400中也有實(shí)際的ip與其對應(yīng)，即DAPBUS interconnect，下圖是它的信號連接圖。

Slave port這一側(cè)dapcaddrs[15:2]的位寬剛好等于APSEL+APBANKSEL+A的寬度；master port一側(cè)dapcaddrm[7:2]的位寬則是APBANKSEL+A的寬度。

Figure 2-4 Interface of DAPBUS

接下來對照著看ADIv6的訪問方式。在同樣的章節(jié)位置，我們看到APv2的寄存器分布在一個(gè)4KB的地址空間內(nèi)。如果你繼續(xù)往下翻，會(huì)看到0xF00開始的Coresight寄存器段。

這看起來非常熟悉——在ADIv6中，AP是作為一個(gè)debug/coresight component被看待的，這就解釋了上文中「debug link提供了對AP的memory-mapped視角」的含義。

同時(shí)，本著Coresight架構(gòu)中對coresight components的發(fā)現(xiàn)原則，一個(gè)與AP所在層級并列的ROM table需要被提供，并指向這些AP。你可以在圖2-1中發(fā)現(xiàn)這個(gè)ROM table，這在ADIv5.2的系統(tǒng)中是不存在的。

Figure 2-5 MEM-AP programmer's model in ADIv6

ADIv6 DP ( DPv3 ) 將SELECT和SELECT1兩個(gè)寄存器的ADDR位拼接形成一個(gè)[63:4]的地址高位，再結(jié)合APACC request的A[3:2]位形成最終的地址，這里圖就省略了，與2-3類似。對于ADIv6兼容的系統(tǒng)，Arm提供的DAP拓?fù)涫荄P+APBIC+AP。

APBIC相比于DAPBUS的一個(gè)顯著區(qū)別是支持最多4個(gè)slave port，也就是在DP這一側(cè)允許更多的agent連接，這使得其他agent可以使用與external debug完全相同的視角來訪問所有AP。

下圖示意了兩種DAP拓?fù)涞膮^(qū)別，其中SoC-600繞回了一個(gè)interconnect的訪問端口作為另一個(gè)debug agent。

Figure 2-6 Comparison between SoC-400 Series and SoC-600

PS：使用Coresight SoC-400的系統(tǒng)同樣支持將interconnect繞回，只不過需要繞到AP下級的位置，無法訪問這個(gè)DAP中的其他AP（以及其他AP所連接的子系統(tǒng)），會(huì)比較像圖1-4中的樣子。

2.2 power control

在圖1-9中，已經(jīng)可以看到一點(diǎn)debug power control的線索，其主要實(shí)現(xiàn)方式是將DP/AP寄存器的某些位作為power request信號輸出到power controller。

除了簡單的上下電請求外，debug power control還可以指示power controller進(jìn)入emulated powerdown，這是一種通過關(guān)停時(shí)鐘或者聲明復(fù)位來代替真正電源關(guān)斷的電源模式。

總體來說，debug power control從最低限度上保證調(diào)試工作能夠獨(dú)立地正確完成，即不用借助其他請求電源的渠道。

至于為什么是最低限度，參考debug over powerdown那一小節(jié)提到的Juno errata. 從層次上看，debug power control有兩級，本文中給這兩級分別命名為 DP power control 和 Granular power control。

其中DP power control是ADI文檔中用了一定篇幅所描述的，某種程度上是「正統(tǒng)的」power control機(jī)制。

ADI在這里對系統(tǒng)的power domain作出三級劃分，即：

Always-on power domain

System power domain

Debug power domain

System/Debug power domain可以粗略地與圖1-9中的core/debug power doamain進(jìn)行對應(yīng)。

DP寄存器的CTRL/STAT[31:28]代表了兩對握手信號：

CxxxPWRUPREQ/ACK. 這兩對握手信號與直接或（通過SCP）間接地與PPU相連接，達(dá)到通過DP進(jìn)行power control的目的。

ACK信號由PPU返回，每一對信號都遵循基本的四相握手，如下圖，debugger需要結(jié)合REQ/ACK兩個(gè)信號的狀態(tài)來判斷目標(biāo)power domain的狀態(tài)。

由于DP能夠達(dá)成對System/Debug power domain的power control，可以想到，DP本身一定是處于更高級的power domain中——一般情況下擺放在AON doamin。

Figure 2-7 Powerup request and acknowledgement timing

在一個(gè)多核系統(tǒng)中，system power domain會(huì)進(jìn)一步切分，使每個(gè)核的電源可以獨(dú)立的關(guān)斷或開啟。

在這種模型下，debug power control也理應(yīng)能夠?qū)Υ诉M(jìn)行利用，這就引入了Granular power control. 在Coresight v3 & ADIv6之前，這種機(jī)制以一個(gè)獨(dú)立的power requestor的形式實(shí)現(xiàn)；在新的架構(gòu)中，Granular power control被整合進(jìn)了ROM table，下面分別進(jìn)行介紹。

在Coresight v2的附錄中，可以找到power requestor這一章節(jié)。這個(gè)power requestor作為一個(gè)coresight component，擁有一個(gè)4KB的地址空間，其中兩個(gè)32-bit的寄存器CDBGPWRUPREQ和CDBGPWRUPACK分別構(gòu)成對最多32個(gè)power domain的power req/ack。

通過寄存器名字我們就能知道，此處power control的機(jī)制與DP處的是一模一樣的，在一些手冊中甚至兩處信號的名字都完全一樣，這也是容易給人造成困惑的地方。

在SoC-400中，有一個(gè)具象的Granular Power Requester (GPR) 模塊與power requestor這個(gè)模型對應(yīng)。在拓?fù)渖希@個(gè)GPR應(yīng)該掛在MEM-AP后級。然而，據(jù)我了解，GPR在Arm的產(chǎn)品中很少出現(xiàn)，我只在一些Cortex-M core based subsystem中找到了它們。

在下圖中的SSE-200[11]是一個(gè)基于雙核M33的子系統(tǒng)，它使用位于PD_DEBUG domain的GPR產(chǎn)生用于控制兩個(gè)CPU domain的power control信號。

Figure 2-8 Power system of SSE-200

注：圖中的power domain模型與前面介紹的v7-A power domai模型存在差異。

M core的結(jié)構(gòu)比較簡單和扁平，M arch中也不存在external debug的概念，PD_CPUDBG中擺放的是BPU、DWT等unit。

對于A core而言，在存在獨(dú)立的debug power domain時(shí)，對于每一個(gè)core，PD_DEBUG面對的會(huì)是一個(gè)單獨(dú)的PD_CPUCORE ( 即沒有PD_CPUDBG )

關(guān)于GPR較少出現(xiàn)的原因，我有一個(gè)猜想：GPR可能只在多核M core的系統(tǒng)中有用武之地。

這是由于對于A core而言，Arm從v7.1 debug開始，就在DBGPRCR這個(gè)debug register中添加了COREPURQ這個(gè)bit，驅(qū)動(dòng)external debug interface上的DBGPWRUPREQ信號，用以請求power。

所以，對于一個(gè)實(shí)現(xiàn)了debug power domain的A core系統(tǒng)，DBGPRCR.COREPURQ就可以用來充當(dāng)Granular power control的作用，免去了額外引入GPR的必要。

當(dāng)然，或許Arm覺得這個(gè)機(jī)制放在ED register里也不算太好，以至于它在ADIv6中采取GPR放進(jìn)了ROM table的做法，并在v8-A的EDPRCR (ED mapping of DBGPRCR) 中刪除了COREPURQ這個(gè)bit。

Figure 2-9 DBGPRCR bit field

將GPR合并進(jìn)ROM table，這里的潛臺詞是修改ROM table的格式使其能夠起到GPR的作用。這也就是我們在Coresight v3 & ADIv6中能看到兩個(gè)版本的ROM table的原因。Arm將它們分別稱為class 0x1和class 0x9。

實(shí)際上class 0x1就對應(yīng)老版本中的ROM table，單純用來做topology detection；而class 0x9就是新架構(gòu)中能夠進(jìn)行power control的ROM table。

對比兩種ROM table的entry信息如下（左0x1，右0x9，省略了一部分），可以看出0x9主要是多出了"Power and reset control"的字段，這兩部分功能實(shí)際上都是DP功能的下放。

但由于我發(fā)現(xiàn)Arm在產(chǎn)品中并沒有把reset control實(shí)現(xiàn)到ROM table中，大多還只使用DP來請求reset，所以這部分暫時(shí)按下不表。

Figure 2-10 ROM table entries of class 0x1/0x9

這里主要會(huì)用到的就是DBGPCR/DBGPSR，此處的范圍和含義是最多對32個(gè)power domain進(jìn)行g(shù)ranular power control， 一般這個(gè)N就等同于Cluster內(nèi)core的數(shù)量。

對于每一組寄存器，DBGPCR基本上就等同于GPR中的CDBGPWRUPREQ寄存器，用來驅(qū)動(dòng)同名信號，而DBGPSR與CDBGPWRUPACK卻略有差異。

根據(jù)下圖中DBGPSR.PS這個(gè)bit field的描述可以看到，Coresight提供了兩種不同的獲取目標(biāo)power domain狀態(tài)的方式，這兩種方式下的invalid state都是0b00，而valid state為0b01或0b11。

Figure 2-11 DBGPSR bit field

0b11的方式與之前通過req & ack來決定power state的方式相同（上圖時(shí)序圖中的DBGPCR.PS應(yīng)為DBGPSR.PS），這種情況下還是需要PPU返回CDBGPWRUPACK信號來驅(qū)動(dòng)PS位；

而在0b01的方式中，PS位被要求能夠獨(dú)立反映power state，所以使用CDBGPWRUPACK就不再合適，而是需要將當(dāng)前core power domain的上電情況直接反饋給PS位。

但據(jù)我能想到的實(shí)現(xiàn)這種機(jī)制的方式，反而會(huì)比0b11更復(fù)雜些，暫時(shí)沒參透Arm的意圖。

2.3 secure debug

現(xiàn)代架構(gòu)完善的debug機(jī)制提供了內(nèi)核的高度可見性，這對于開發(fā)者來說是一件利器，但同樣給惡意訪問提供了便利。

Arm架構(gòu)中提供了一組authentication信號用來對debug功能進(jìn)行限制，最初有4個(gè)，它們的簡稱與含義分別是：

DBGEN：invasive debug enable

SPIDEN：secure invasive debug enable

NIDEN：non-invasive debug enable

SPNIDEN：secure non-invasive debug enable

其中invasive debug一般就代指external debug，而non-invasive一般有trace或profiling等。

在v8.4-A及后續(xù)架構(gòu)中，Arm取消了對non-invasive debug單獨(dú)的控制，即不實(shí)現(xiàn)后兩個(gè)信號。

對于core而言，authentication信號是從頂層輸入的，Arm ARM并沒有規(guī)范這些信號的產(chǎn)生機(jī)制，只是直接拿過來用而已。

這容易讓人產(chǎn)生困惑，本以為涉及到authentication會(huì)是一套復(fù)雜的流程，結(jié)果只給出這么幾個(gè)使能位，不禁讓人追問：

這些使能的源頭是哪里呢？

是SoC中的寄存器，還是SoC的頂層？

它們該如何配置，怎樣保證配置過程是安全的？

如果可以隨意配置，那authentication的意義何在？

好在，Coresight對authentication信號的配置做了一些簡短但有意義的解釋：

它提供了三種配置信號的方法，分別是：

設(shè)置成固定值，Tied LOW/HIGH

一次性可編程，即OTP

通過"custom authentication module"來驅(qū)動(dòng)authentication 信號

OTP的方法引入了產(chǎn)品的生命周期的概念，在不同的周期中應(yīng)用不同的使能策略。Arm建議在產(chǎn)品的開發(fā)階段，可以使能所有的debug功能；在產(chǎn)品上市時(shí)，關(guān)閉secure debug。

當(dāng)然OTP本質(zhì)上與第一種方法差不多，只是固定值來的早一點(diǎn)或晚一點(diǎn)，還是會(huì)存在一些問題：Tied HIGH會(huì)使authentication信號失去意義，Tied LOW產(chǎn)生的問題在這篇論文[12]的VI.A小節(jié)中闡述的比較全面。

最后這種按需改變的方法提供了最大的靈活性，在保證配置過程的安全性的前提下應(yīng)是最優(yōu)解。

但這個(gè)"custom module"該怎么做，Coresight文檔淺嘗輒止，只是說了一句：

ARM recommends using a challenge-response mechanism that is based on an on-chip random number generator or a hardware key unique to that device.

然而，我們可以在Arm的一些reference design中看到它具體是怎么做的。仍以SSE-710為例，Arm在其中設(shè)計(jì)了一個(gè)secure enclave，這是一個(gè)安全子系統(tǒng)，包含一個(gè)M內(nèi)核以及一些私有的組件和外設(shè)。

這里主要討論它的Lifecycle States (LCS) 和Security Control Bits (SCB) 這兩個(gè)組件。

secure enclave的概念早在配備指紋識別的iPhone 5s的Apple A7芯片中就被提出，專門用來存放用戶的生物識別信息，與AP進(jìn)行物理隔離。enclave，飛地，指隸屬于某一行政區(qū)管轄但不與本區(qū)毗連的土地。

這個(gè)詞透露出的含義是secure信息是「secure王國」在SoC中的一塊飛地，這些信息屬于它的提供者，或是更廣義上的的authorized agent，而不是任意一個(gè)AP開發(fā)者。

SCB看起來就是一組系統(tǒng)控制寄存器，它的值直接驅(qū)動(dòng)著SSE-710中包含Host CPU在內(nèi)的authentication信號。

LCS從名字就能夠看出來是與剛剛提到的產(chǎn)品生命周期有關(guān)，SSE-710定義了4個(gè)lifecycle states，并通過一個(gè)單向的狀態(tài)機(jī)來表征系統(tǒng)當(dāng)前的lifecycle state。

這4個(gè)lifecycle states分別是：

Chip Manufacture

Device Manufacture

Secure Enable

Return Merchandise Authorization

SCB的賦值機(jī)制會(huì)受到當(dāng)當(dāng)前l(fā)ifecycle state的影響。Chip/Device Manufacture應(yīng)該分別對應(yīng)fabless/OEM的設(shè)計(jì)或制造階段，SSE-710對此期間的SCB值沒有具體規(guī)定；

Secure Enable對應(yīng)的應(yīng)該是產(chǎn)品上市階段，這時(shí)SCB的authentication輸出被規(guī)定為默認(rèn)為0，但是可以通過secure enclave進(jìn)行修改。

當(dāng)然了，修改不是任意的，正如前面提到的，Arm規(guī)定用戶必須通過一個(gè)"challenge-response"的過程來獲取控制secure enclave的權(quán)限。

這樣的機(jī)制保證了只有被授權(quán)的用戶才能通過檢查，使能debug并進(jìn)一步訪問相關(guān)資源。

最后這個(gè)RMA應(yīng)該對應(yīng)的是產(chǎn)品到了生命周期的終點(diǎn)，Arm對此期間的SCB值也沒有規(guī)定，因此不是我們討論的重點(diǎn)。

我們進(jìn)一步來具象Secure Enclave與SoC通信的模型：

「請求debug功能的agent」需要給系統(tǒng)secure enclave發(fā)送一個(gè)「身份信息」，

secure enclave通過驗(yàn)證身份信息認(rèn)定這個(gè)agent是合法的之后，允許其對secure enclave進(jìn)行正常訪問。

這實(shí)際上是一個(gè)所謂證書注入（Certificate Injection）的過程。證書即是debug agent的身份信息，這里的debug agent代指external debugger。

但到目前為止，我們還沒有談及debugger是如何與secure enclave進(jìn)行交互的，這涉及到了Arm的一個(gè)獨(dú)立ip：Coresight SDC-600。

SDC即Secure Debug Channel，它兼容現(xiàn)有的debug interface架構(gòu)，提供了從DAP到secure enclave的通路。

下面這張圖展示了大概的拓?fù)?，但有些組件的名稱與我們在SSE-710中看到的不太一樣。圖中的Cryptoisland實(shí)際上就對應(yīng)SSE-710中的secure enclave，DCU (Debug Control Unit) 就對應(yīng)SCB。

因此，下圖所描述的流程大致是：

debugger通過SDC-600將其證書注入到Cryptoisland中，

后者調(diào)用Cryptocell對證書進(jìn)行驗(yàn)證，

并在通過驗(yàn)證后使能DAP與Host system的通路，

使得debug資源能被正常訪問。

Figure 2-12 Coresight SDC-600

下面這張圖展示了SDC-600的組件應(yīng)如何接入一個(gè)SoC-600 based的系統(tǒng)。其中，Serving Agent代指一個(gè)可以檢查證書的單位，在我們討論的系統(tǒng)中它實(shí)際就是Secure Enclave。

可以看到Serving Agent發(fā)出的authentication信號送到了SoC-600的諸多組件中，這里最重要的是送給AP的幾條通路。

AP的CSW (Control Status Word) 寄存器有SDeviceEn和DeviceEn兩個(gè)bit，分別用來控制secure/non-secure下的AP使能。

那么顯然將Serving Agent發(fā)出的SPIDEN和DBGEN分別接到這兩個(gè)地方就能夠達(dá)到通過authentication信號控制debug通路開關(guān)的目的。

Figure 2-13 SDC-600 block diagram for ADIv6

最后需要說明，上圖忽略了Serving Agent將authentication信號送到core的通路，實(shí)際上這才是這一小節(jié)一開始所討論的，或者說在Arm ARM中authentication信號的來源。

3 Reference

Arm Architecture Reference Manual for A-profile architecture

Arm CoreSight Architecture Specification v3.0

Arm Debug Interface Architecture Specification ADIv6.0

Arm Corstone SSE-710 Subsystem Technical Reference Manual

Arm Cortex-A53 MPCore Processor Technical Reference Manual

Juno r2 ARM Development Platform SoC Technical Reference Manual

Learn the architecture - Before debugging on Armv8-A

Common issues using DS-5 with Juno

Linux Kernel Power Management (PM) Framework for ARM 64-bit Processors

ARM 推出 CoreSight SoC-600，實(shí)現(xiàn)下一代調(diào)試和跟蹤

Arm CoreLink SSE-200 Subsystem for Embedded Technical Reference Manual

Understanding the Security of ARM Debugging Features

無論如何，這都是一篇很不錯(cuò)的文章。后續(xù)希望有機(jī)會(huì)能研究一下Coresight的Verilog實(shí)現(xiàn)，以及怎么和ARM做IP授權(quán)形式。