2. 程式人生 > 其它 >OpenBMC 新增一個新的系統

OpenBMC 新增一個新的系統

阿新 • • 發佈：2021-12-08

新增新系統到 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](https://lists.ozlabs.org/pipermail/openbmc/2018-September/013260.html) 是這個過程的例子。在本文件中，我們只簡單的使用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 訪問。

  • [email protected] 定義了 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

  • [email protected] 定義了風扇以及配置於上面類似，不同點是，它建立 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
[email protected]
    預設情況下，它監測 GPIO 引腳 74，如果它觸發，將告知 systemd 啟動 [email protected]。
    對於使用不同 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 按鈕按下後，不要退出，繼續工作

相關推薦

OpenBMC 新增一個新的系統

新增新系統到 OpenBMC 內容: 如何新增一個新的系統到 OpenBMC 版本 受眾: 熟悉 OpenBMC 的開發者

不要為了測試寫一個新系統

　　前幾天聽到了這樣的問題： 　　“你們做自動化測試的時候，是怎麼把預期結果算出來的？”。——按照我的經驗，都是手工或Excel算出來的。

在centos7中新增一個新使用者，並授權

前言 筆記本裝了一個centos，想要讓別人也可以登入訪問，用自己的賬號確實不太好，於是準備新建一個使用者給他。

新增新系統到 OpenBMC 模擬實踐

新增新系統到 OpenBMC 實踐 首先構建新的 romulus-prime 元檔案 按照 新增新系統到 OpenBMC 文件 中介紹的 建立新系統 小節構建自己的新系統。

xenomai核心解析--雙核系統呼叫(三)--如何為xenomai新增一個系統呼叫

版權宣告：本文為本文為博主原創文章，轉載請註明出處。如有錯誤，歡迎指正。

為什麼現代系統需要一個新的程式設計模型

akka版本2.6.9 版權宣告：本文為博主原創文章，未經博主允許不得轉載。  actor模型是Carl Hewitt在幾十年前提出的，作為在高效能網路中並行處理的一種方法(當時還沒有這種環境)。今天，硬體和基礎設施的

Ubuntu-部署一個新的系統需要做的事

# 背景 因為需要部署一些機器用於生產環境， 然後又需要後期好維護， 再這之前，我需要在電腦上做一些操作，

向陣列的末尾新增一個或多個元素，並返回新的長度

需求：向陣列的末尾新增一個或多個元素，並返回新的長度 letidListStr=[] _selection.forEach((item,index)=>{//迴圈

讓角色既優雅又實用《艾爾登法環攻略》PC版新MOD增加了一個變形系統

《艾爾登法環》（Elden Ring）的一個新的PC mod為遊戲增加了一個眾望所歸的元素：變身系統。這使得玩家可以穿上他們喜歡的任何盔甲，而不必擔心諸如屬性變更之類的小事。

【九圖流】從零開始設計一個登入系統（初中級）

說明： 無任何程式碼，只有設計思路。 範疇等級：初級開發、中級開發。 場景：中小型專案，內部專案。

教程|教你如何給你的頭像新增一個好看的國旗

今天朋友圈又火了，聽說原因是 @騰訊官網 就能得到一頂綠色的帽子，啊呸，是一個好看的國慶節頭像，可是聽說沒一會就502了，那麼我們自己動手實現一個吧

caddy（3） 為 caddy 新增一個 反向代理外掛

caddy-grpc 為 caddy 新增一個 反向代理外掛 專案地址：github.com/yhyddr/cadd… 前言 上一次我們學習瞭如何在 Caddy 中擴充套件自己想要的外掛。部落格中只提供了大致框架。這一次，我們來根據具體外掛 caddy-g

用Linq從一個集合選取幾列得到一個新的集合(可改列名)

用Linq從一個集合選取幾列得到一個新的集合-可改列名 以上就是本文的全部內容，希望對大家的學習有所幫助，也希望大家多多支援我們。

將tensorflow.Variable中的某些元素取出組成一個新的矩陣示例

在神經網路計算過程中，經常會遇到需要將矩陣中的某些元素取出並且單獨進行計算的步驟（例如MLE，Attention等操作）。那麼在 tensorflow 的 Variable 型別中如何做到這一點呢？

pycharm實現在子類中新增一個父類沒有的屬性

我就廢話不多說了，還是直接看程式碼吧！ class Car(): \"\"\"一次模擬汽車的簡單嘗試\"\"\"

Win Server 2008 R2 IIS 預設只能新增一個 443 HTTPS 埠，更換證書

1、問題： 解決方案： 方法一： 然後在：C:\\Windows\\system32\\inetsrv\\config\\applicationHost.config

合併兩個有序連結串列，將兩個升序連結串列合併為一個新的升序連結串列並返回。 新連結串列是通過拼接給定的兩個連結串列的所有節點組成的。 例如：輸入 1->2->4,1->3->4->5,輸出：1->1->2->3->4->4->5

/*合併兩個有序連結串列，將兩個升序連結串列合併為一個新的升序連結串列並返回。

Hexo快速構建個人小站-Fulid主題下新增Valine評論系統(三)

Hexo目錄： Hexo快速構建個人小站-Hexo初始化和將專案託管在Github(一) Hexo快速構建個人小站-自定義域名和自定義主題(二)

h5寫的一個簽到系統

html頁面 <!DOCTYPE html> <html lang=\"en\"> <head> <meta charset=\"UTF-8\"> <title>簽到</title>

win10新增舊版系統的windows照片檢視器

本文出處：https://jingyan.baidu.com/article/e75aca857b4860142edac6f5.html 1. 桌面建立1.txt檔案，輸入以下內容