碼上快樂

相關內容    簡體    繁體

OpenBMC 添加一個新的系統

本文轉載自   查看原文   2021-12-08 19:42   2812    OpenBMC/ 翻譯

添加新系統到 OpenBMC

內容: 如何添加一個新的系統到 OpenBMC 版本
受眾: 熟悉 OpenBMC 的開發者
需求: 完成了環境配置文檔
我的博客

總覽

本文檔將描述如下的內容:

  • 回顧 Yocto 與 BitBake 的歷史
  • 創建新的系統層
  • 完善這個新的層
  • 編譯新的系統並使用 QEMU 進行測試
  • 為 sensor，LED，資產 等內容添加配置

背景

OpenBMC 版本基於Yocto項目。Yocto 項目允許開發者創建定制化的 Linux 發行版本。 OpenBMC 使用 Yocto 創建自己的運行在各種設備尚的嵌入式 Linux 版本。

Yocto 具有一個層架構的概念。當你構建一個基於 Yocto 的構建版本時，你會定義關於該版本的一系列的層。OpenBMC 使用一些 Yocto 中通用的層以及自己構建的層。OpenBMC 中定義的層可以在 OpenBMC 的 GitHub項目的 meta-* 目錄中找到。

Yocto 的層是定義在這個層中的構成這個層的不同包的組合。其中一個關鍵的層是BitBake使用的食譜。

BitBake 具有自身完備的功能性。在本文檔中，我們將僅專注於添加一個新的系統過程中需要使用的 BitBake 內容。

啟動 BitBake 初始化

你需要至少100GB的存儲空間的開發環境，盡可能多的內存以及CPU核。第一次構建 OpenBMC 版本可能會消耗幾個小時。一旦初次構建完成，未來的構建將會使用第一次構建中生成的緩存數據進行構建，從而大幅加速了后續的構建過程。

首先，跟着 Github 中的項目文檔進行初次構建。

創建一個新的系統

如果上面的工作能夠順利完成，讓我們開始創建我們的新系統吧。與前面的內容相同，我們將會使用 Romulus 作為我們的參考內容。我們新的系統將稱為 romulus-prime。

在之前克隆的openbmc的倉庫中，Romulus 等位於 meta-ibm/meta-romulus/ 目錄下。 Romulus 層定義在 conf 子目錄下。在 conf 目錄中，可以看到如下的結構:

meta-ibm/meta-romulus/conf/
├── bblayers.conf.sample
├── conf-notes.txt
├── layer.conf
├── local.conf.sample
└── machine
    └── romulus.conf

為了創建我們自己的 romulus-prime 系統，首先復制當前的 romulus 層:

cp -R meta-ibm/meta-romulus meta-ibm/meta-romulus-prime

讓我們調整在新的層中需要的每個文件:

  1. meta-ibm/meta-romulus-prime/conf/bblayers.conf.sample
    這個文件定義了要引入到 meta-romulus-prime 版本中的層，你可以在這個文件中看到不同的 Yocto 層(比如 meta，meta-openembedded/meta-oe 等)。它也有 OpenBMC 的層，比如 meta-phosphor，meta-openpower，meta-ibm 以及 meta-ibm/meta-romulus。

    對這個文件要做出的唯一修改是將其中的兩個 meta-romulus 實例，修改為 meta-romulus-prime，這將允許你使用你新構建的層。

  2. meta-ibm/meta-romulus-prime/conf/conf-notes.txt
    這個文件簡單陳述你構建的新層要構建的默認目標，這個文件保留不變，因為這個文件在所有的 OpenBMC 系統都保持一致。

  3. meta-ibm/meta-romulus-prime/conf/layer.conf
    這個文件的主要目的是告訴 BitBake 去哪里查找食譜(*.bb)文件，食譜文件以 .bb 作為后綴名，包含不同層的打包邏輯。.bbappend 文件也是食譜文件，但是卻是作為 .bb 文件的補充。.bbapped 文件通常用來添加或移除相關聯的 .bb 文件中的內容。

  4. meta-ibm/meta-romulus-prime/conf/local.conf.sample
    這個文件中包含你的層中的本地配置設置信息。這個文件中的內容寫的很好，值得一讀。唯一需要改變的內容是，將 MACHINE 修改為 romulus-prime。

  5. meta-ibm/meta-romulus-prime/conf/machine/romulus.conf
    這個文件描述了你的機型的規定的內容，你定義使用的內核設備樹，你引入的覆寫特性，以及其他的系統特性。這個文件是創建新系統變動不同的內容時的好參考(內核設備樹，MRW，LED設置，資產訪問等)。
    首先，你需要將這個文件重命名為 romulus-prime.conf。
    這個配置數據的主體數據不再使用了，但是在完全移除它之前，你依然需要提供這些內容。

構建新系統

上面的工作順利完成后，再繼續進行后續的操作。后面的操作過程中，可能會出現一些錯誤，但是這些錯誤可以幫助你更好的理解構建新系統的過程。

  1. 為當前的構建調整 conf
    在 shell 中，你進行了 bitbake 的初始化操作，現在需要為你新構建的系統重置 conf 文件，你可以手動的復制新文件，或只是移除它，讓 BitBake 幫助你完成:

    cd ..
rm -rf ./build/conf
export TEMPLATECONF=meta-ibm/meta-romulus-prime/conf
. openbmc-env

    運行你想運行的 bitbake 命令。

  2. 沒有 RPROVIDES 'romulus-prime-config'
    這是你在新系統中運行 bitbake obmc-phosphor-image 之后出現的第一個錯誤。
    在初始化 OpenBMC 的原型初始化時，會使用 openbmc/skeleton 倉庫，在這個倉庫中是 configs 目錄。
    既然這個倉庫與文件是這樣的情況，我們將簡單地快速解決這個問題。
    創建如下的配置文件:

    cp meta-ibm/meta-romulus-prime/recipes-phosphor/workbook/romulus-config.bb meta-ibm/meta-romulus-prime/recipes-phosphor/workbook/romulus-prime-config.bb

vi meta-ibm/meta-romulus-prime/recipes-phosphor/workbook/romulus-prime-config.bb

SUMMARY = "Romulus board wiring"
DESCRIPTION = "Board wiring information for the Romulus OpenPOWER system."
PR = "r1"

inherit config-in-skeleton

#Use Romulus config
do_make_setup() {
       cp ${S}/Romulus.py \
               ${S}/obmc_system_config.py
       cat <<EOF > ${S}/setup.py
from distutils.core import setup

setup(name='${BPN}',
   version='${PR}',
   py_modules=['obmc_system_config'],
   )
EOF
}

    重新運行你的 bitbake 命令。

  3. 提取 URL 失敗: file://romulus.cfg
    這是內核需要的一個配置文件，在這里你可以放置一些額外的內核配置參數。在我們的需求中，只需要調整 romulus-prime 來使用 romulus.cfg 文件。我們只需要添加 -prime 來擴展路徑。

    vi ./meta-ibm/meta-romulus-prime/recipes-kernel/linux/linux-aspeed_%.bbappend

FILESEXTRAPATHS_prepend_romulus-prime := "${THISDIR}/${PN}:"
SRC_URI += "file://romulus.cfg"

    現在重新運行你的 `bitbake 命令。

  4. 沒有提供目標 arch/arm/boot/dts/aspeed-bmc-opp-romulus-prime.dtb.dtb文件是設備樹塊文件。這個文件在 Linux 內核基於對應的 .dts 文件編譯過程中生成的文件。當你引入一個新的 OpenBMC 系統時，你需要發送這些內核更新上游內容。鏈接郵件 thread 是這個過程的例子。在本文檔中，我們只簡單的使用 Romulus 內核配置文件:

    vi ./meta-ibm/meta-romulus-prime/conf/machine/romulus-prime.conf
# Replace the ${MACHINE} variable in the KERNEL_DEVICETREE

# Use romulus device tree
KERNEL_DEVICETREE = "${KMACHINE}-bmc-opp-romulus.dtb"

    重新運行你的 bitbake 命令。

啟動新系統

現在，你編譯了你的新的系統鏡像！有很多可以繼續定制化的內容，但在現在，我們先驗證一下我們的工作吧！
你的新鏡像在編譯完成后，它會位於相對於你的 bitbake 命令使用的目錄於:

./tmp/deploy/images/romulus-prime/obmc-phosphor-image-romulus-prime.static.mtd

復制這個鏡像到你配置的 QEMU 位置，重新運行啟動 QEMU 命令(在 dev-environment.md 中的 qemu-system-arm 命令)，並使用你的新的文件作為輸入。

一旦啟動，你將會看到如下的登錄接口:

romulus-prime login:

好了！現在，你已經成功的實現了初步的創建、啟動以及構建一個新的系統。這雖然在實際意義上並不是一個新的系統，但是你現在有了定制自己需要系統的基礎。

深度客制化

在創建一個新系統時，有很多可以定制化的內容。

修改內核

本小節介紹如何修改內核，以移植 OpenBMC 到新的設備。設備樹位於 https://github.com/openbmc/linux/tree/dev-4.13/arch/arm/boot/dts 中。比如，查看 aspeed-bmc-opp-romulus.dts 或相似的設備。完成下面的步驟來做出內核的修改:

  1. 添加新機型的設備樹
    • 描述 GPIOs，即 LED，FSI，gpio-keys 等內容。你應該可以從硬件原理圖中獲取到需要配置的信息
    • 描述 i2c 總線以及設備，通常包含不同的硬件檢測 hwmon sensor
    • 描述其他的設備，即 uarts，mac 等內容
    • 通常 flash 布局不需要改變，只需要包含 openbmc-flash-layout.dtsi
  2. 調整 Makefile 來編譯設備樹
  3. 參考 openbmc kernel doc 提交補丁到郵件列表

注意:

  • 在 dev-4.10 中，arch/arm/mach-aspeed/aspeed.c 中具有通用的以及指定設備的代碼，這個文件是用來通用的初始化，以及指定的機型的設置。在 branch dev-4.13 中，沒有這樣的初始化代碼。大多數初始化是與時鍾以及重置驅動中完成的
  • 如果設備需要特定的配置(即 uart 路由)，請發送郵件到郵件列表 the mailing list 進行討論

工作簿

在舊版的 OpenBMC 中，有一個"工作簿"描述設備的服務、傳感器以及FRU等信息。這個工作簿是一個 python 配置文件，且它被 skeleton 的其他服務使用。在最新版的 OpenBMC 中，skeleton 服務大多數被 phosphor-xxx 服務替代，因此skeleton 已經被拋棄了。但是在當前的構建中依舊需要"工作簿"。

meta-quanta是一個在 OpenBMC 樹中定義的自有的配置示例，盡管是偽造的，它不再依賴於 skeleton。

在 e0e69be 中，或在 v2.4 標簽之前，OpenPOWER 機型使用 GPIO 相關的一些配置，例如，在 Romulus.py 中，配置細節如下:

GPIO_CONFIG['BMC_POWER_UP'] = \
        {'gpio_pin': 'D1', 'direction': 'out'}
GPIO_CONFIG['SYS_PWROK_BUFF'] = \
        {'gpio_pin': 'D2', 'direction': 'in'}

GPIO_CONFIGS = {
    'power_config' : {
        'power_good_in' : 'SYS_PWROK_BUFF',
        'power_up_outs' : [
            ('BMC_POWER_UP', True),
        ],
        'reset_outs' : [
        ],
    },
}

編譯時需要 PowerUp 以及 PowerOK GPIOs ，來上電機箱並檢測上電狀態。

在這之后，GPIO 相關的配置從工作簿移除，並被 gpio_defs.json 替換，即 2a80da2 引入了對Romulus 的 GPIO json 配置。

{
    "gpio_configs": {
         "power_config": {
            "power_good_in": "SYS_PWROK_BUFF",
            "power_up_outs": [
                { "name": "SOFTWARE_PGOOD", "polarity": true},
                { "name": "BMC_POWER_UP", "polarity": true}
            ],
            "reset_outs": [
            ]
        }
    },

     "gpio_definitions": [
        {
            "name": "SOFTWARE_PGOOD",
            "pin": "R1",
            "direction": "out"
        },
        {
            "name": "BMC_POWER_UP",
            "pin": "D1",
            "direction": "out"
        },
    ...
}

每一個機型必須定義相似的 json 配置來描述 GPIO 配置。

硬件檢測傳感器

硬件檢測傳感器(hwmon sensors)包括板卡上的傳感器(即溫度傳感器、風扇)以及 OCC 傳感器。配置文件路徑以及名稱必須於設備樹中的設備匹配。

在下面的文檔中具有一些細節: doc/architecture/sensor-architecture。

現在讓我們以 Romulus 為例，配置文件為 meta-romulus/recipes-phosphor/sensors，它包含板上傳感器以及 OCC 傳感器，其中板卡上的傳感器通過 i2c 訪問，OCC 傳感器通過 FSI 訪問。

  • w83773g@4c.conf 定義了 w83773 溫度傳感器，包含三個溫度

     LABEL_temp1 = "outlet"
 ...
 LABEL_temp2 = "inlet_cpu"
 ...
 LABEL_temp3 = "inlet_io"

    這些設備定義為它的設備樹 w83773g@4c 中，當 BMC 啟動時，udev 規則將會啟動 phosphor-hwmon，它將基於 sysfs 屬性創建在如下 D-Bus 溫度傳感器對象:

    /xyz/openbmc_project/sensors/temperature/outlet
/xyz/openbmc_project/sensors/temperature/inlet_cpu
/xyz/openbmc_project/sensors/temperature/inlet_io

  • pwm-tacho-controller@1e786000.conf 定義了風扇以及配置於上面類似，不同點是，它創建 fan_tach 傳感器

  • occ-hwmon.1.conf 為主 CPU 定義了 occ 硬件檢測傳感器，這個配置有點不同，它必須告知 phosphor-hwmon 讀取標識，而不是直接獲取傳感器的索引，因為 CPU 內核以及 DIMMs 可以是動態的，即 CPU 核可以被關閉，DIMMs 可以被取出

     MODE_temp1 = "label"
 MODE_temp2 = "label"
 ...
 MODE_temp31 = "label"
 MODE_temp32 = "label"
 LABEL_temp91 = "p0_core0_temp"
 LABEL_temp92 = "p0_core1_temp"
 ...
 LABEL_temp33 = "dimm6_temp"
 LABEL_temp34 = "dimm7_temp"
 LABEL_power2 = "p0_power"
 ...
    • MODE_temp* = "label" 表示，如果要查看 tempX，必須讀取 sensor id 即 label
    • LABEL_temp* = "xxx" 表示，通過 sensor id 獲取到的 sensor name
    • 比如，如果 temp1_input 為 37000 且 temp1_label 在 sysfs 中為 91，phosphor-hwmon 直到 temp1_input 是 sensor id 為 91 的值，即 p0_core0_temp，因此它將創建 xyz/openbmc_project/sensors/temperatur/p0_core0_temp，且其值為 37000
    • 對於 Romulus 功率傳感器不需要讀取標識，因為所有的功率在系統上是可以獲取到的
    • 對於 Witherspoon，功率傳感器與溫度傳感器相似，它必須告知 hwmon 讀取 function_id 而不是直接獲取到傳感器的索引值

LED燈

一些部分涉及到了LED燈。

  1. 在內核設備樹中，必須描述 LEDs，如在 romulus dts 描述了3盞 LED 燈，故障燈、定位燈以及電源指示燈:
      leds {
    compatible = "gpio-leds";

    fault {
      gpios = <&gpio ASPEED_GPIO(N, 2) GPIO_ACTIVE_LOW>;
    };

    identify {
      gpios = <&gpio ASPEED_GPIO(N, 4) GPIO_ACTIVE_HIGH>;
    };

    power {
      gpios = <&gpio ASPEED_GPIO(R, 5) GPIO_ACTIVE_LOW>;
    };
  };
  2. 在機型層，LEDs 必須通過 yaml 進行配置，用以描述它們的功能，如在 Romulus led yaml 中:
    bmc_booted:
    power:
        Action: 'Blink'
        DutyOn: 50
        Period: 1000
        Priority: 'On'
power_on:
    power:
        Action: 'On'
        DutyOn: 50
        Period: 0
        Priority: 'On'
...
    它表示 LED 電源指示燈在 BMC 啟動后閃爍，當主機上電之后常量。
  3. 在運行時，LED 管理基於上面的 yaml 配置自動設置 LEDs 亮/滅/閃爍
  4. LED 可以通過 /xyz/openbmc_project/led/ 手動的訪問，比如:
    • 獲取定位燈狀態:
      curl -b cjar -k https://$bmc/xyz/openbmc_project/led/physical/identify
    • 設置定位燈狀態為閃爍:
      curl -b cjar -k -X PUT -H "Content-Type: application/json" -d '{"data": "xyz.openbmc_project.Led.Physical.Action.Blink" }' https://$bmc/xyz/openbmc_project/led/physical/identify/attr/State
  5. 當發生 FRU 相關的故障時，將在日志中創建一條帶有 CALLOUT 路徑的事件日志，phosphor-fru-fault-monitor 檢測日志:
    • 當帶有 CALLOUT 路徑的故障發生時，修改相關燈的狀態
    • 當日志顯式相關的事件解除或被刪除時，修改相關燈的狀態

注意: 這個 yaml 配置可以通過 phosphor-mrw-tools 的MRW自動生成，詳情查看Witherspoon example

資產信息以及其他傳感器

資產信息，其他傳感器(比如 CPU/DIMM 溫度)，以及 FRU 在 ipmi 的 yaml 配置文件中定義。
比如，meta-romulus/recipes-phosphor/ipmi

  • romulus-ipmi-inventory-map 定義了常規的資產信息，如，CPU，內存，母板等
  • phosphor-ipmi-fru-properties 定義了額外的資產信息屬性
  • phosphor-ipmi-sensor-inventory 定義了 IPMI 的傳感器
  • romulus-ipmi-inventory-sel 定義了 IPMI SEL 使用的資產

對於資產映射以及FRU屬性，它們在不同的系統下都十分相似，你可以參考這些例子，並制作自己的系統。

對於 ipmi-sensor-inventory，IPMI 中的傳感器因系統而異，因此你需要定義你自己的傳感器，比如:

0x08:
  sensorType: 0x07
  path: /org/open_power/control/occ0
  ...
0x1e:
  sensorType: 0x0C
  path: /system/chassis/motherboard/dimm0
  ...
0x22:
  sensorType: 0x07
  path: /system/chassis/motherboard/cpu0/core0

第一個值 0x08，0x1e，0x22 是 IPMI 的 sensor id，在 MRW 中定義。你應該遵從系統的 MRW 來定義上面的配置。

注意: yaml配置可以自動從它的 MRW 的 phosphor-mrw-tools 中自動生成，詳情查看 Witherspoon example

風扇

phosphor-fan-presence 管理所有的風扇有關的服務:

  • phosphor-fan-presence 檢查風扇是否在位，在資產信息中創建風扇 D-Bus對象，並更新 Present 狀態屬性
  • phosphor-fan-monitor 檢測風扇是否有效，並更新 D-Bus 對象中的 Functional 資產屬性
  • phosphor-fan-control 按照條件設置風扇速度目標(如，基於溫度)來設置風扇轉速
  • phosphor-cooling-type 通過設置 /xyz/openbmc_project/inventory/system/chassis 對象屬性，檢測並設置系統是風冷還是水冷

所有上面的服務都是可配置的，比如通過 yaml 配置，因此在移植 OpenBMC 到新的系統時，機型相關的配置必須寫入。

以 Romulus 為例，它是風冷且具有3個風扇，無 GPIO 在位檢測的。

風扇在位

Romulus 沒有 GPIO 在位檢測，因此它通過檢測風扇轉速傳感器:

- name: fan0
  path: /system/chassis/motherboard/fan0
  methods:
    - type: tach
      sensors:
        - fan0

yaml配置表示:

  • 它必須在資產中創建 /system/chassis/motherboard/fan0 對象
  • 它必須檢測 fan0 轉速傳感器 (/sensors/fan_tach/fan0) 來設置 fan0 對象的 Present 屬性

風扇監測

Romulus 風扇使用 pwm 實現風扇速度控制，pwm 范圍為 0-255，風扇速度為 0-7000。因此它需要一個一個機制將 pwm 轉換為 speed

  - inventory: /system/chassis/motherboard/fan0
    allowed_out_of_range_time: 30
    deviation: 15
    num_sensors_nonfunc_for_fan_nonfunc: 1
    sensors:
      - name: fan0
        has_target: true
        target_interface: xyz.openbmc_project.Control.FanPwm
        factor: 21
        offset: 1600

這個 yaml 配置表示:

  1. 它必須使用 FanPwm 作為轉速傳感器的目標接口
  2. 它必須以 target*21 + 1600 計算期望的風扇速度
  3. 偏差是 15$，因此如果風扇速度在期望的工作范圍外工作超過30秒，fan0 必將被設置為無效風扇

風扇控制

風扇控制服務需要4個 yaml 配置文件:

  • zone-condition 定義制冷區條件，Romulus 總是通過風冷制冷，因此配置比較簡單，定義為 air-cooled-chassis

    - name: air_cooled_chassis
  type: getProperty
  properties:
    - property: WaterCooled
      interface: xyz.openbmc_project.Inventory.Decorator.CoolingType
      path: /xyz/openbmc_project/inventory/system/chassis
      type: bool
      value: false

  • zone-config 定義制冷區，Romulus 只有一個區

    zones:
  - zone: 0
    full_speed: 255
    default_floor: 195
    increase_delay: 5
    decrease_interval: 30

    它定義了風扇的滿轉速度以及默認地板速度，因此，全速狀態下，pwm 將會設置為255；默認地板狀態下，將會設置為195

  • fan-config 定義了在哪個區需要控制哪個風扇，哪個目標接口必須使用，比如，下面的 yaml 配置中，定義了 fan0 必須在 zone0 進行控制，必須使用 FanPwm 接口:

    - inventory: /system/chassis/motherboard/fan0
  cooling_zone: 0
  sensors:
    - fan0
  target_interface: xyz.openbmc_project.Control.FanPwm
  ...

  • event-config 定義了不同的事件，及事件處理。比如，在哪個溫度必須設置哪個風扇。這個配置有一點復雜，example event yaml 提供了示例與文檔，Romulus 例子如下:

      - name: set_air_cooled_speed_boundaries_based_on_ambient
    groups:
        - name: zone0_ambient
          interface: xyz.openbmc_project.Sensor.Value
          property:
              name: Value
              type: int64_t
    matches:
        - name: propertiesChanged
    actions:
        - name: set_floor_from_average_sensor_value
          map:
              value:
                  - 27000: 85
                  - 32000: 112
                  - 37000: 126
                  - 40000: 141
              type: std::map<int64_t, uint64_t>
        - name: set_ceiling_from_average_sensor_value
          map:
              value:
                  - 25000: 175
                  - 27000: 255
              type: std::map<int64_t, uint64_t>

    在上面的 yaml 配置中，定義了在 zone0_ambient 不同溫度下的風扇的地板以及天花板速度，如
    i. 當溫度低於 27 攝氏度，地板速度為 85
    ii. 當溫度在 27-32 攝氏度之間，地板速度為 112

    注意: Romulus 風扇比較簡單，如果想看復雜的例子，可以參考 Witherspoon fan configurations，在這個例子有如下的額外配置:

    • 通過 GPIO 監測在位信息
    • 通過 GPIO 監測風冷還是水冷
    • 具有更多的傳感器及更多的事件

GPIOs

本小節主要關注於設備樹中必須監控的 GPIOs，比如:

  • 一個 GPIO 可能表示一個主機故障點信號(host checkstop)
  • 一個 GPIO 可能表示一個按鈕按下(button)
  • 一個 GPIO 可能表示設備鏈接(device attach)

有 phosphor-gpio-presense 用來監測設備在位，phosphor-gpio-monitor 用於監測一個 GPIO。

設備樹中的 GPIO

所有監測的 GPIOs 必須在設備樹中進行描述，比如:

  gpio-keys {
    compatible = "gpio-keys";
    checkstop {
      label = "checkstop";
      gpios = <&gpio ASPEED_GPIO(J, 2) GPIO_ACTIVE_LOW>;
      linux,code = <ASPEED_GPIO(J, 2)>;
    };
    id-button {
      label = "id-button";
      gpios = <&gpio ASPEED_GPIO(Q, 7) GPIO_ACTIVE_LOW>;
      linux,code = <ASPEED_GPIO(Q, 7)>;
    };
  };

如下的代碼描述兩個 GPIO 引腳，一個是 checkstop 另一個是 id-button，引腳代碼來在aspeed-gpio.h:

#define ASPEED_GPIO_PORT_A 0
#define ASPEED_GPIO_PORT_B 1
...
#define ASPEED_GPIO_PORT_Y 24
#define ASPEED_GPIO_PORT_Z 25
#define ASPEED_GPIO_PORT_AA 26
...

#define ASPEED_GPIO(port, offset) \
  ((ASPEED_GPIO_PORT_##port * 8) + offset)

GPIO 在位

Witherspoon 以及 Zaius 具有 GPIO 在位的例子:

  • Witherspoon:

    INVENTORY=/system/chassis/motherboard/powersupply0
DEVPATH=/dev/input/by-path/platform-gpio-keys-event
KEY=104
NAME=powersupply0
DRIVERS=/sys/bus/i2c/drivers/ibm-cffps,3-0069

    它監測 GPIO 引腳 104，作為 powersupply0 的在位情況，創建資產對象，並綁定或解除綁定驅動

  • Zaius:

    INVENTORY=/system/chassis/pcie_card_e2b
DEVPATH=/dev/input/by-path/platform-gpio-keys-event
KEY=39
NAME=pcie_card_e2b

    它監測 GPIO 引腳 39，作為 pcie_card_e2b 的在位情況，創建資產目標

GPIO 監測

通常的 GPIO 監測用來監測主機的故障點事件，或按鈕按下。

  • checkstop monitor 是一個 OpenPOWER 機型的常用服務
    DEVPATH=/dev/input/by-path/platform-gpio-keys-event
KEY=74
POLARITY=1
TARGET=obmc-host-crash@0.target
    默認情況下，它監測 GPIO 引腳 74，如果它觸發，將告知 systemd 啟動 obmc-host-crash@0.target。
    對於使用不同 GPIO 引腳作為故障監測點的，它簡單在 meat-machine 層指定自己的配置文件，來覆蓋原有的默認的配置即可。
    比如 Zaius's checkstop config.
    注意: 當引腳觸發，phosphor-gpio-monitor 啟動目標並退出
  • id-button monitor 是 Romulus 中的服務，用來監測定位按鈕按下
    DEVPATH=/dev/input/by-path/platform-gpio-keys-event
KEY=135
POLARITY=1
TARGET=id-button-pressed.service
EXTRA_ARGS=--continue
    它監測 GPIO 引腳 135 按鈕按下，並啟動服務 id-button-pressed.service，這個服務設置定位指示燈觸發相應的 Assert 動作
    注意: 它具有額外的參數 --continue，告知 phosphor-gpio-monitor 按鈕按下后，不要退出，繼續工作


免責聲明！

本站轉載的文章為個人學習借鑒使用，本站對版權不負任何法律責任。如果侵犯了您的隱私權益，請聯系本站郵箱yoyou2525@163.com刪除。



猜您在找 OpenBMC 添加一個新的系統 添加新系統到 OpenBMC 仿真實踐 destoon 添加一個新的模塊 yocto添加一個新的機器 machine 給kali的Metasploit下添加一個新的exploit ubuntu系統上如何添加新的根證書 js為一個對象Object添加一個新的屬性和值 linux采用模塊方法，添加一個新的設備 如何在CentOS 7中添加新磁盤而不用重啟系統 如何給MindSpore添加一個新的硬件后端？快速構建測試環境！
 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM