Device Tree 的 iommus、svc 與 method = "smc"Device-tree iommus, svc and method = "smc"デバイスツリーの iommus、svc と method = "smc"

0. 這份文件的範圍0. Scope of this document0. 本書の範囲

這是 smmu_rbf_load_failure_zh.html 的姊妹篇。 前一份說明「為什麼 RBF 載入會失敗」； 這一份逐項拆解在讀那份分析時自然會冒出來的基礎機制問題 — device tree 的數字到底代表什麼、誰替誰做位址轉換、 以及最後那個實際動手的問題：能不能只針對 svc 一個節點下手。 This is the companion to smmu_rbf_load_failure_zh.html. That note explains why RBF loading fails; this one works through the underlying mechanism questions that naturally arise while reading it — what the numbers in a device tree actually mean, who translates addresses for whom, and finally the practical question: can you act on the svc node alone?本稿は smmu_rbf_load_failure_zh.html の姉妹編です。あちらはなぜ RBF のロードが失敗するのかを説明し、本稿はそれを読むときに自然に浮かぶ基礎的な仕組みの疑問を一つずつ解きほぐします — デバイスツリーの数値が実際に何を表すのか、誰が誰のためにアドレス変換を行うのか、そして最後に実務的な問い：svc ノードだけを手当てできるのか。

1. iommus = <0x09 0x0a> 裡的 0x09 是什麼？1. What is the 0x09 in iommus = <0x09 0x0a>?1. iommus = <0x09 0x0a> の 0x09 とは何か？

0x09 不是位址，而是一個 phandle — 指向另一個 DT 節點的 32-bit 指標。 0x09 is not an address; it is a phandle — a 32-bit pointer to another DT node.0x09 はアドレスではない。これは phandle — 別の DT ノードを指す 32 ビットのポインタである。

iommus 遵循 DT 標準的「phandle + specifier」格式：iommus follows the standard DT “phandle + specifier” form:iommus は DT 標準の「phandle + specifier」形式に従う：

原始 .dts 裡其實不長這樣The original .dts does not look like this元の .dts はこの形をしていない

你看到的是反編譯後的結果。人寫的原始碼是 label reference：What you are looking at is the decompiled output. The human-written source uses a label reference:いま見ているのは逆コンパイルした出力である。人が書いたソースはラベル参照を使う：

/* 原始 .dts — 人寫的 *//* original .dts — as written by a human *//* 元の .dts — 人が書いたもの */
iommus = <&smmu 10>;

/* dtc 編譯後，&smmu 被換成 smmu 節點的 phandle 數值 *//* after dtc, &smmu is replaced by the smmu node's phandle value *//* dtc の処理後、&smmu は smmu ノードの phandle 値に置き換わる */
iommus = <0x09 0x0a>;

要驗證這條連結的另一端，直接找誰宣告了 phandle = <0x09>：To verify the other end of the link, just find who declares phandle = <0x09>:このリンクのもう一方の端を確かめるには、phandle = <0x09> を宣言しているのが誰かを探せばよい：

dtc -I dtb -O dts system.dtb | grep -n 'phandle = <0x09>'

2. iommu@16000000 的 16000000 是 VA 還是 PA？2. Is the 16000000 in iommu@16000000 a VA or a PA?2. iommu@16000000 の 16000000 は VA か PA か？

是 PA（更精確地說：父匯流排位址空間中的位址）。 Device tree 裡永遠不會出現虛擬位址。 It is a PA (more precisely: an address in the parent bus's address space). A virtual address never appears in a device tree.PA である（より正確に言えば 親バスのアドレス空間におけるアドレス）。仮想アドレスがデバイスツリーに現れることはない。

@ 之後的部分叫做 unit address， 依 DT 規範必須等於該節點 reg 的第一個位址。 而 reg 是用父節點的位址空間表示的： The part after @ is the unit address, and per the DT specification it must equal the first address in that node's reg. And reg is expressed in the parent node's address space:@ の後ろは unit address であり、DT 仕様ではそのノードの reg の先頭アドレスと一致していなければならない。そして reg は親ノードのアドレス空間で表される：

那 VA 什麼時候才出現？So when does a VA appear?では VA はいつ現れるのか？

只在 driver probe 的那一刻，由 kernel 動態產生，而且與 0x16000000 完全無關：Only at driver probe time, generated dynamically by the kernel, and entirely unrelated to 0x16000000:ドライバの probe 時にカーネルが動的に生成するときだけであり、0x16000000 とはまったく無関係である：

3. IOMMU 是幫 CPU 把位址轉成 bus address 嗎？3. Does the IOMMU translate CPU addresses into bus addresses?3. IOMMU は CPU のアドレスをバスアドレスへ変換するのか？

不是，方向剛好相反，而且 CPU 完全不參與。 SMMU 位於裝置與記憶體之間，不是 CPU 與匯流排之間。 No — the direction is the opposite, and the CPU is not involved at all. The SMMU sits between devices and memory, not between the CPU and the bus.いいえ — 向きは逆であり、そもそも CPU は関与しません。SMMU は CPU とバスの間ではなく、デバイスとメモリの間に位置する。

裝置放上匯流排的那個位址就是 IOVA， 也就是 Linux DMA API 裡 dma_addr_t 所裝的數值。 CPU 的 load/store 從來不會經過 SMMU。 這正是為什麼節點上加了 iommus， 對「CPU 讀寫該週邊的 register」完全沒有影響。 The address a device puts on the bus is the IOVA — the value carried in dma_addr_t in the Linux DMA API. A CPU load/store never passes through the SMMU. That is exactly why adding iommus to a node has no effect whatsoever on “the CPU reading and writing that peripheral's registers”.デバイスがバス上へ出すアドレスが IOVA であり、Linux DMA API の dma_addr_t が運ぶ値そのものである。CPU のロード／ストアが SMMU を通ることはない。だからこそ、ノードに iommus を足しても「CPU がその周辺デバイスのレジスタを読み書きすること」にはまったく影響しない。

真正做「CPU ↔ bus 位址」轉換的是這兩個，但都不是 IOMMUThe two things that really do translate “CPU ↔ bus address” — neither of which is an IOMMU本当に「CPU ↔ バスアドレス」を変換する 2 つのもの — どちらも IOMMU ではない

三個位址空間 — 只有兩個有機會相等Three address spaces — only two can ever be equal3 つのアドレス空間 — 等しくなれるのは常に 2 つまで

4. svc 是一個 node 還是一個 kernel module？4. Is svc a node or a kernel module?4. svc はノードなのか、カーネルモジュールなのか？

兩者都是 — 而且是同一條繫結（binding）的兩端。 svc 這個名字是 DT 節點；stratix10-svc 是綁上去的驅動。 Both — and they are the two ends of one binding. The name svc is the DT node; stratix10-svc is the driver bound to it.その両方であり、両者は一つのバインディングの両端である。名前としての svc は DT のノードであり、stratix10-svc はそこにバインドされるドライバである。

DT 節點The DT nodeDT のノード

firmware {
    svc {
        compatible    = "intel,agilex5-svc";
        method        = "smc";
        memory-region = <&svcbuffer>;      /* svcbuffer@0，保留的 32 MiB *//* svcbuffer@0, the reserved 32 MiB *//* svcbuffer@0、予約された 32 MiB */
        iommus        = <&smmu 10>;         /* ← 造成載入失敗的那一行 *//* ← the line that causes the load failure *//* ← ロード失敗を引き起こす行 */

        fpga_mgr: fpga-mgr {
            compatible = "intel,agilex5-soc-fpga-mgr";
        };
    };
};

兩個關鍵觀察：Two key observations:重要な観察が 2 点：

• 它掛在 /firmware 底下，不是 /socIt lives under /firmware, not /soc/soc ではなく /firmware の下に置かれている
• 它沒有 reg — 因為它不是 MMIO 週邊。 它代表的是一條通往韌體的通訊管道，所以才有 method = "smc"。It has no reg — because it is not an MMIO peripheral. It represents a communication channel to firmware, which is why it has method = "smc".reg を持たない — MMIO 周辺デバイスではないからである。これはファームウェアへの通信チャネルを表しており、だからこそ method = "smc" を持つ。

驅動The driverドライバ

drivers/firmware/stratix10-svc.c， config 為 CONFIG_INTEL_STRATIX10_SERVICE（tristate，因此可以是 stratix10-svc.ko，但 Altera 的預設 config 通常是 built-in）。 它註冊成 platform driver 來 match 上面那個 compatible。 drivers/firmware/stratix10-svc.c, under CONFIG_INTEL_STRATIX10_SERVICE (tristate, so it can be stratix10-svc.ko, though Altera's default config usually builds it in). It registers as a platform driver matching the compatible above.drivers/firmware/stratix10-svc.c、CONFIG_INTEL_STRATIX10_SERVICE の下にある（tristate なので stratix10-svc.ko にもできるが、Altera の既定コンフィグでは通常ビルトインされる）。上記の compatible に一致するプラットフォームドライバとして登録される。

它提供的是一個 service layer — 給其他驅動呼叫的 in-kernel API：What it provides is a service layer — an in-kernel API for other drivers to call:提供するのはサービス層 — 他のドライバから呼び出すためのカーネル内 API である：

stratix10_svc_request_channel_byname(client, "fpga");
stratix10_svc_allocate_memory();   /* 從 svcbuffer@0 切一塊 *//* carve a piece out of svcbuffer@0 *//* svcbuffer@0 から一部を切り出す */
stratix10_svc_send();              /* → SMC → ATF → SDM */

它的 consumer 是 drivers/fpga/stratix10-soc.c（FPGA manager）與 stratix10-rsu.c。 Its consumers are drivers/fpga/stratix10-soc.c (the FPGA manager) and stratix10-rsu.c.利用者は drivers/fpga/stratix10-soc.c（FPGA マネージャ）と stratix10-rsu.c である。

所以 log 為什麼寫 firmware:svc:fpga-mgrSo why does the log say firmware:svc:fpga-mgr?では、なぜログには firmware:svc:fpga-mgr と出るのか？

因為帶有 compatible 的 DT 節點會被實例化成 platform device， 而 device 名稱就是把 DT 路徑的 / 換成 :： Because a DT node carrying a compatible is instantiated as a platform device, and the device name is the DT path with / replaced by ::compatible を持つ DT ノードはプラットフォームデバイスとして実体化され、そのデバイス名は DT のパスの / を : に置き換えたものになるからである：

在板子上驗證Verifying it on the boardボード上での確認

ls /proc/device-tree/firmware/svc/
ls -l /sys/bus/platform/devices/firmware:svc/driver
grep -i stratix10 /proc/modules      # 若是 built-in 則為空# empty if built in# ビルトインなら空

5. method = "smc" 是什麼意思？5. What does method = "smc" mean?5. method = "smc" は何を意味するのか？

它選擇 conduit — 驅動用哪一條 ARM 指令呼叫韌體。 與 PSCI 的 method 是同一個屬性、同樣只有兩種合法值。 It selects the conduit — which ARM instruction the driver uses to call firmware. It is the same property as PSCI's method, with the same two legal values.これは conduit を選ぶ — ドライバがファームウェアを呼ぶのにどの ARM 命令を使うかである。PSCI の method と同じプロパティで、取りうる値も同じ 2 つである。

你的板子上 Linux 跑在 EL1 並且直接擁有 EL3 呼叫權，所以是 "smc"。 只有當 Linux 是 guest、且 EL2 的 hypervisor 要代為攔截／轉送韌體呼叫時，才會改用 "hvc"。 On your board Linux runs at EL1 and holds the right to call EL3 directly, so it is "smc". "hvc" is used only when Linux is a guest and a hypervisor at EL2 must intercept or forward firmware calls on its behalf.このボードでは Linux は EL1 で動作し、EL3 を直接呼ぶ権利を持っているので "smc" になる。"hvc" は Linux がゲストであり、EL2 のハイパーバイザがファームウェア呼び出しを代理で横取り・転送しなければならない場合にだけ使われる。

驅動拿這個字串做什麼What the driver does with the stringドライバはこの文字列を何に使うのか

stratix10-svc.c 只是用它挑一個 function pointer：stratix10-svc.c only uses it to pick a function pointer:stratix10-svc.c はこれを関数ポインタの選択にしか使わない：

if (!strcmp(method, "smc"))
        sh->invoke_fn = svc_smccc_smc;   /* → arm_smccc_1_1_smc() */
else if (!strcmp(method, "hvc"))
        sh->invoke_fn = svc_smccc_hvc;   /* → arm_smccc_1_1_hvc() */
else
        return -EINVAL;

之後每一次請求都走 sh->invoke_fn(...)。 這個字串是兩條路徑唯一的差別 — 參數的排列方式完全相同。 Every subsequent request then goes through sh->invoke_fn(...). That string is the only difference between the two paths — the argument layout is identical.以降のリクエストはすべて sh->invoke_fn(...) を経由する。この文字列が 2 つの経路の唯一の違いであり、引数の並びは同一である。

呼叫本身（SMCCC）The call itself (SMCCC)呼び出しそのもの（SMCCC）

參數放在 x0–x7，其中 x0 是 function ID； 回傳值放在 x0–x3。 Altera 使用 SiP（Silicon Provider）廠商保留範圍： Arguments go in x0–x7, with x0 holding the function ID; return values come back in x0–x3. Altera uses the SiP (Silicon Provider) vendor-reserved range:引数は x0〜x7 に入り、x0 が関数 ID を保持する。戻り値は x0〜x3 で返る。Altera は SiP（Silicon Provider）ベンダ予約領域を使う：

INTEL_SIP_SMC_FPGA_CONFIG_START            0xC2000001
INTEL_SIP_SMC_FPGA_CONFIG_WRITE           0xC2000002
INTEL_SIP_SMC_FPGA_CONFIG_COMPLETED_WRITE
INTEL_SIP_SMC_FPGA_CONFIG_ISDONE

0xC2… 解碼為：fast call / SMC64 / owner = SiP。 0xC2… decodes as: fast call / SMC64 / owner = SiP.0xC2… は fast call / SMC64 / owner = SiP と解釈される。

所以 svc 是一個門鈴（doorbell），不是週邊 — 這也解釋了為什麼它有 method 與 memory-region，卻沒有 reg。 So svc is a doorbell, not a peripheral — which explains why it has method and memory-region but no reg.つまり svc は周辺デバイスではなく呼び鈴である。method と memory-region を持ちながら reg を持たないのはそのためである。

這一點如何連回那個 bugHow this ties back to the bugこれが不具合とどう結びつくか

6. altr,smmu_enable_quirk 是什麼？6. What is altr,smmu_enable_quirk?6. altr,smmu_enable_quirk とは何か？

Altera 自訂的 boolean（有無即代表真假） DT 屬性。 它告訴驅動「這個平台的 SMMU 是啟用的，請走 SMMU-aware 的位址路徑」。 在 Agilex 5 上它不是可選的 — 缺了它 svc 根本不會 probe 成功。 An Altera-specific boolean DT property (its mere presence means true). It tells the driver “the SMMU is enabled on this platform, so take the SMMU-aware address path”. On Agilex 5 it is not optional — without it svc will not probe successfully at all.Altera 固有のブール型 DT プロパティである（存在すること自体が true を意味する）。ドライバに対して「このプラットフォームでは SMMU が有効なので、SMMU を意識したアドレス経路を取れ」と伝える。Agilex 5 では省略可能ではない — これが無いと svc はそもそも probe に成功しない。

兩份 binding 文件都有記載，內容一字不差：Both binding documents record it, word for word:2 つのバインディング文書がどちらも、そのままの文言で記載している：

Documentation/devicetree/bindings/firmware/intel,stratix10-svc.txt:42
Documentation/devicetree/bindings/fpga/intel-stratix10-soc-fpga-mgr.txt:14

  - altr,smmu_enable_quirk: set when SMMU is enabled for the platform.

而在 arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi 裡， 它同時出現在兩個節點上（第 226 與第 230 行）： And in arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi it appears on two nodes at once (lines 226 and 230):そして arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi では2 つのノードに同時に現れる（226 行目と 230 行目）：

svc {
    compatible = "intel,agilex5-svc";
    iommus     = <&smmu 10>;
    altr,smmu_enable_quirk;                     /* :226 */

    fpga_mgr: fpga-mgr {
        compatible = "intel,agilex5-soc-fpga-mgr";
        altr,smmu_enable_quirk;                 /* :230 */
    };
};

svc 端：drivers/firmware/stratix10-svc.c:3607The svc side: drivers/firmware/stratix10-svc.c:3607svc 側：drivers/firmware/stratix10-svc.c:3607

if (of_device_is_compatible(node, "intel,agilex5-svc")) {
    if (iommu_present(&platform_bus_type) &&
        device_property_read_bool(dev, "altr,smmu_enable_quirk")) {

            controller->is_smmu_enabled     = true;
            controller->sdm_dma_addr_offset = AGILEX5_SDM_DMA_ADDR_OFFSET;  /* 0x8000_0000 */
            controller->domain = iommu_get_dma_domain(dev);
            if (!controller->domain) { ret = -ENODEV; goto err_destroy_pool; }

            iova_cache_get();
            iommu_attach_device(controller->domain, dev);
            init_iova_domain(&controller->carveout.domain, ..., IOMMU_STARTING_ADDR);  /* 0x0        */
            controller->carveout.limit = IOMMU_LIMIT_ADDR - PAGE_SIZE;                 /* 0x2000_0000 */

    } else {
            ret = -ENODEV; goto err_destroy_pool;   /* ← 沒有 non-SMMU 分支 *//* ← no non-SMMU branch *//* ← 非 SMMU の分岐は存在しない */
    }

    /* SMMU 接手轉譯，所以把 SDM 自己那顆 remapper 關掉 *//* the SMMU takes over translation, so disable the SDM's own remapper *//* SMMU がアドレス変換を引き受けるので、SDM 自身のリマッパは無効化する */
    controller->invoke_fn(INTEL_SIP_SMC_SDM_REMAPPER_CONFIG,
                          is_smmu_enabled ? DISABLE_REMAPPER : ENABLE_REMAPPER, ...);

fpga-mgr 端：drivers/fpga/stratix10-soc.cThe fpga-mgr side: drivers/fpga/stratix10-soc.cfpga-mgr 側：drivers/fpga/stratix10-soc.c

同一個屬性在子節點上決定 bitstream buffer 要不要做 DMA mapping：The same property on the child node decides whether the bitstream buffer is DMA-mapped:子ノード側の同じプロパティが、ビットストリーム用バッファを DMA マップするかどうかを決める：

/* :459 */
priv->is_smmu_enabled = device_property_read_bool(dev, "altr,smmu_enable_quirk");

/* :302 — 每個 buffer 送出前 *//* :302 — before each buffer is submitted *//* :302 — 各バッファを投入する直前 */
if (priv->is_smmu_enabled)
        priv->svc_bufs[i].dma_addr = dma_map_single(dev, svc_buf, SVC_BUF_SIZE, DMA_TO_DEVICE);

/* :139 — buffer 回收時 *//* :139 — when the buffer is reclaimed *//* :139 — バッファを回収するとき */
if (priv->is_smmu_enabled == true)
        dma_unmap_single(priv->client.dev, priv->svc_bufs[i].dma_addr, SVC_BUF_SIZE, DMA_TO_DEVICE);

然後在 svc 送出訊息時補上位移（stratix10-svc.c:3253）：The offset is then added when svc sends the message (stratix10-svc.c:3253):svc がメッセージを送る際に、このオフセットが加算される（stratix10-svc.c:3253）：

if (p_msg->command == COMMAND_RECONFIG_DATA_SUBMIT && chan->ctrl->is_smmu_enabled)
        p_data->paddr += chan->ctrl->sdm_dma_addr_offset;   /* IOVA + 0x8000_0000 → SDM */

結構體註解（:271）寫得很直白： "dma addr offset to append to the IOVA sent to SDM"。 The struct comment (:271) says it plainly: "dma addr offset to append to the IOVA sent to SDM".構造体のコメント（:271）が端的に述べている："dma addr offset to append to the IOVA sent to SDM"。

7. 可以只移除 svc 的 iommus 嗎？7. Can you remove just svc's iommus?7. svc の iommus だけを外せるか？

在 Agilex 5 上不行。 intel,agilex5-svc 的 probe 路徑沒有 non-SMMU 分支， 移除後 svc 會直接 -ENODEV 失敗。 Not on Agilex 5. The intel,agilex5-svc probe path has no non-SMMU branch, so with the property removed svc simply fails with -ENODEV.Agilex 5 では不可能である。intel,agilex5-svc の probe 経路には非 SMMU の分岐が存在しないため、プロパティを外すと svc は単に -ENODEV で失敗する。

兩種移除方式都會失敗Both ways of removing it fail外し方はどちらも失敗する

順帶訂正：StreamID 10 有真實流量An incidental correction: StreamID 10 does carry real traffic付随する訂正：StreamID 10 は実際のトラフィックを運んでいる

本文早期版本推測「firmware:svc 沒有 reg、不 master 任何東西， 所以 SID 10 上大概沒有真實流量」。這是錯的。 INTEL_SIP_SMC_SDM_REMAPPER_CONFIG 的存在本身就證明了： SDM 有一條會被 remapper 或 SMMU 轉譯的 DRAM 存取路徑， 而那條路徑對應的就是 StreamID 10。 firmware:svc 是 Linux 端代為持有並設定這個 StreamID 的 proxy device。 An earlier version of this document speculated that “firmware:svc has no reg and masters nothing, so SID 10 probably carries no real traffic”. That is wrong. The very existence of INTEL_SIP_SMC_SDM_REMAPPER_CONFIG proves it: the SDM has a DRAM access path that is translated by either the remapper or the SMMU, and that path corresponds to StreamID 10. firmware:svc is the proxy device that holds and configures this StreamID on Linux's behalf.本書の以前の版では「firmware:svc は reg を持たず何もマスタしないので、SID 10 には実トラフィックは無いだろう」と推測していた。これは誤りである。INTEL_SIP_SMC_SDM_REMAPPER_CONFIG が存在すること自体がその証拠であり、SDM にはリマッパまたは SMMU のいずれかでアドレス変換される DRAM アクセス経路があって、その経路が StreamID 10 に対応する。firmware:svc は Linux に代わってこの StreamID を保持し設定するプロキシデバイスである。

「iommus 逐節點生效」這件事仍然成立“iommus takes effect per node” is still true「iommus はノード単位で効く」は依然として正しい

第 7 節結論改變的是「該不該對 svc 動手」， 而不是 iommus 的作用範圍。 of_iommu_configure() 依然只讀該節點自己的 iommus， 所以下列理解不變： What changed in section 7 is whether you should touch svc, not the scope of iommus. of_iommu_configure() still reads only that node's own iommus, so the following remains correct:第 7 節で変わったのは svc に手を入れてよいかどうかであって、iommus の作用範囲ではない。of_iommu_configure() は今もそのノード自身の iommus しか読まないので、以下は正しいままである：

8. 那實際上該檢查什麼？8. So what should you actually check?8. では、実際に何を確認すべきか？

svc 在你的板子上是 probe 成功的（否則 fpga-mgr 不會存在、也就印不出那行 timeout），所以 SMMU 路徑本身已經起來了。 問題出在下游的 buffer／位址處理，而最可能的原因是版本不一致。 svc does probe successfully on your board (otherwise fpga-mgr would not exist and could not print that timeout line), so the SMMU path itself is up. The problem lies downstream in buffer/address handling, and the most likely cause is a version mismatch.このボードでは svc の probe は成功している（そうでなければ fpga-mgr が存在せず、あのタイムアウト行も出せない）ので、SMMU 経路そのものは立ち上がっている。問題はその先のバッファ／アドレスの扱いにあり、最も疑わしいのはバージョンの不一致である。

版本落差The version gapバージョンの隔たり

最可能的單一根因：quirk 只加在其中一個節點The single most likely root cause: the quirk added to only one node最有力の根本原因：quirk が片方のノードにしか入っていない

在板子上要跑的檢查Checks to run on the boardボード上で実行する確認

uname -r

# quirk 必須「兩個節點都有」# the quirk must be present on BOTH nodes# quirk は両方のノードに存在しなければならない
ls /proc/device-tree/firmware/svc/altr,smmu_enable_quirk
ls /proc/device-tree/firmware/svc/fpga-mgr/altr,smmu_enable_quirk

# remapper 交握是否成功# did the remapper handshake succeed?# リマッパのハンドシェイクは成功したか？
dmesg | grep -i 'remapper\|Service Layer'

建議的修正順序Suggested order for the fix修正の推奨手順