hubris
sidecar release
Hubrisは、信頼性要件を備えた深く包埋されたシステム用に設計されたマイクロコントローラー動作環境です。その設計は当初RFD41で提案されていましたが、それ以来かなり進化しています。
開発者のドキュメントは、 doc/ DirectoryのAsciidocにあります。 GitHubページを介してレンダリングされ、https：//oxidecomputer.github.io/hubrisで入手できます。
レポは次のようにレイアウトされています。
app/は、アプリケーション用のトップレベルのバイナリクレートがライブである場所です。たとえばapp/gimletにはGimlet用のファームウェアクレートが含まれています。一般的に言えば、何かのために画像を作成したい場合は、こちらをご覧ください。
build/含まれているビルドシステムとサポートクレート。
chip/含まれているのは、個々のマイクロコントローラーの周辺定義とデバッグサポートファイルを含んでいます。
doc/ conming developerドキュメント。
drv/は、シンプルなドライバーLIBクレートと本格的なサーバービンクレートのミックスであるドライバーが含まれています。現在の慣習では、 drv/SYSTEM-DEVICEがSYSTEM上のDEVICEのドライバー（ SYSTEMは通常SOC名）であるのに対し、 drv/SYSTEM-DEVICE-serverはサーバービンクレートです。
idl/アイドルで記述されたインターフェイス定義を含みます
lib/私たちが書いた各種のユーティリティライブラリが含まれています。他のディレクトリの1つに収まらない再利用可能な木枠を作成する必要がある場合は、おそらくここに属します。
stage0/ 、主にLPC55用のブートローダー/低侵害者です。
support/含まれているのは、偽の証明書やプログラマーファームウェア画像などのインターフェイスおよびプログラミングサポートファイルです。
sys/には、hub慢の「システム」ビット、すなわちカーネル（ sys/kern ）、ABI（ sys/abi ）を定義する共有クレート、およびタスクで使用されるユーザーライブラリ（ sys/userlib ）が含まれています。
task/ドライバーではない再利用可能なタスクが含まれます。 taskとdrv/something-serverに住んでいるものの区別はファジーです。あなたの判断を使用してください。
test/さまざまなボード用に構築するためのテストフレームワークとバイナリクレートが含まれています。
website/ Hubris Webサイトのソースコードが含まれています
現在、LinuxとWindowsは第一段階のプラットフォームとしてサポートしています。 MacOSは酸化物の従業員によって毎日使用されますが、CIではテストされていません。ビルドはおそらくイルモスでも機能します。イルモスまたはマコーのサポートと継続的なビルドを維持するためにステップアップしたい場合は、私たちは助けが大好きです。
レビューの変更を送信するには、フォーク内のブランチに押し込み、そのブランチをmasterにマージするためのプルリクエストを送信します。詳細については、 CONTRIBUTING.md参照してください。
必要になります：
rustupベースのツールチェーンインストール。 rustup最初に構築しようとするときに、ピン留めのツールチェーンバージョンとクロスコンパイルターゲットを自動的にインストールします。
openocd （理想的には0.11）または（LPC55を使用している場合） pyocd （0.27以降）。 OpenOCDの0.10リリースは、STLINK V3よりも前のものであることに注意してください。人々は、システムパッケージマネージャーが提供する0.10以降、0.11以前のさまざまなポストを使用していますが、ある程度の成功を収めていますが、システムが0.11をまだパッケージ化していない場合は、それらを悩ませています。 MacOSでHomeBrewを使用してOpenOCDをインストールする場合は、 brew install --head openocd使用して、最新のバイナリリリースを使用するのではなく、メインブランチの先端を構築する必要があります。ソースからビルドする必要がある場合は、OpenOCD V0.11.0をこちらから見つけることができます。 ./configureを実行するときは、 ST-Link Programmerが有効になっていることを確認してください（デフォルトである必要があります）。
Libusbは、通常、システムのパッケージマネージャーからlibusb-1.0.0または同様として発見されました。
libfdti1、 libftdi1-devまたは同様として見つかります。
GDBを実行する場合は、 arm-none-eabi-gdbインストールする必要があります。これは通常、 arm-none-eabi-gdbやgdb-multiarchなどのパッケージ名を持つシステムのパッケージマネージャーからのものです。 MacOSユーザーはbrew install --cask gcc-arm-embedded公式のアームバイナリをインストールします。
hub慢なデバッガー、謙虚さ。 cargo installこのリポジトリのルートに存在するrust-toolchain.tomlファイルと奇妙に相互作用することに注意してください。次のコマンドverbatimを実行して謙虚さをインストールする場合は、別のディレクトリからそうしてください。
cargo install --git https://github.com/oxidecomputer/humility.git --locked humilitycargo-readme必要です： cargo install cargo-readmeOpenOCDをインストールする3つの代替方法があります。
openocdのソースを取得するか、非公式のバイナリを取得することについては、こちらをご覧ください。
または、チョコレートでインストールすることもできます。
> choco install openocd最後に、Scoopでopenocdインストールできます。
> scoop bucket add extras
> scoop install openocd注： scoop経由でインストールされたopenocd 、一部のユーザーにとって問題があることが証明されています。問題が発生した場合は、 chocoまたはソースからインストールしてみてください（上記を参照）。
ST-Linkプログラマーを使用するには、おそらくこのドライバーをインストールする必要があります。
hubrisを構築して実行する必要はありませんが、シリアルリンクを介して通信したい場合（端末ではサポートされていません）、Puttyを使用する必要があります。このガイドは、その方法を説明するのに良い仕事をしています。
cargo buildやcargo runはありません。複雑なマルチアーキテクチャビルドがありますが、これは少し超えています。
代わりに、リポジトリには、カスタムビルドコマンドを名前を付けるxtaskと呼ばれる貨物拡張機能が含まれています。
cargo xtask dist TOMLFILE TOMLファイルによって説明されているアプリケーションの配布画像を構築します。
cargo xtask dist app/demo-stm32f4-discovery/app.toml -stm32f4-discoverycargo xtask dist app/demo-stm32f4-discovery/app-f3.toml -STM32F3-DISCOVERYcargo xtask dist app/lpc55xpresso/app.toml -lpcxpresso55s69cargo xtask dist app/demo-stm32g0-nucleo/app-g031.toml -STM32G031-NUCLEOcargo xtask dist app/demo-stm32g0-nucleo/app-g070.toml -STM32G070-NUCLEOcargo xtask dist app/demo-stm32h7-nucleo/app-h743.toml -NUCLEO-IH743ZI2cargo xtask dist app/demo-stm32h7-nucleo/app-h753.toml -NUCLEO-IH753ZIcargo xtask dist app/gemini-bu/app.toml -gemini bringupボード完全な画像ビルドには10秒以上かかる可能性があるため、変更したものに応じて、タスクやカーネルを反復しているときに、おそらく個別にビルドする必要があります。これがcargo xtask buildの目的です。
たとえば、画像の1つに組み込まれているようにtask-ping構築するには、残りのデモを構築せずに実行してください。
$ cargo xtask build app/gimletlet/app.toml ping clippy実行していますcargo xtask clippy Subcommandを使用して、特定の画像のコンテキストで1つ以上のタスクに対してclippy実行できます。
$ cargo xtask clippy app/gimletlet/app.toml ping pong rust-analyzerとの統合hubrisビルドシステムは、箱から出しているrust-analyzerとは動作しません。
ただし、 cargo xtask lspここに役立ちます。それはその議論として錆びファイルを取り、 rust-analyzerセットアップする方法のためにJSONエンコードされた構成を返します。
このデータを使用するには、一部のエディター構成が必要です！
（私たちはまだプラグインを作成していませんが、確かに可能でしょう）
Neovimとrust-tools使用して、ここに構成の例を示します。
-- monkeypatch rust-tools to correctly detect our custom rust-analyzer
require ' rust-tools.utils.utils ' . is_ra_server = function ( client )
local name = client . name
local target = " rust_analyzer "
return string.sub ( client . name , 1 , string.len ( target )) == target
or client . name == " rust_analyzer-standalone "
end
-- Configure LSP through rust-tools.nvim plugin, with lots of bonus
-- content for Hubris compatibility
local cache = {}
local clients = {}
require ' rust-tools ' . setup {
tools = { -- rust-tools options
autoSetHints = true ,
inlay_hints = {
show_parameter_hints = false ,
parameter_hints_prefix = " " ,
other_hints_prefix = " " ,
-- do other configuration here as desired
},
},
server = {
on_new_config = function ( new_config , new_root_dir )
local bufnr = vim . api . nvim_get_current_buf ()
local bufname = vim . api . nvim_buf_get_name ( bufnr )
local dir = new_config . root_dir ()
if string.find ( dir , " hubris " ) then
-- Run `xtask lsp` for the target file, which gives us a JSON
-- dictionary with bonus configuration.
local prev_cwd = vim . fn . getcwd ()
vim . cmd ( " cd " .. dir )
local cmd = dir .. " /target/debug/xtask lsp "
-- Notify `xtask lsp` of existing clients in the CLI invocation,
-- so it can check against them first (which would mean a faster
-- attach)
for _ , v in pairs ( clients ) do
local c = vim . fn . escape ( vim . json . encode ( v ), ' " ' )
cmd = cmd .. ' -c" ' .. c .. ' " '
end
local handle = io.popen ( cmd .. bufname )
handle : flush ()
local result = handle : read ( " *a " )
handle : close ()
vim . cmd ( " cd " .. prev_cwd )
-- If `xtask` doesn't know about `lsp`, then it will print an error to
-- stderr and return nothing on stdout.
if result == " " then
vim . notify ( " recompile `xtask` for `lsp` support " , vim . log . levels . WARN )
end
-- If the given file should be handled with special care, then
-- we give the rust-analyzer client a custom name (to prevent
-- multiple buffers from attaching to it), then cache the JSON in
-- a local variable for use in `on_attach`
local json = vim . json . decode ( result )
if json [ " Ok " ] ~= nil then
new_config . name = " rust_analyzer_ " .. json . Ok . hash
cache [ bufnr ] = json
table.insert ( clients , { toml = json . Ok . app , task = json . Ok . task })
else
-- TODO:
-- vim.notify(vim.inspect(json.Err), vim.log.levels.ERROR)
end
end
end ,
on_attach = function ( client , bufnr )
local json = cache [ bufnr ]
if json ~= nil then
local config = vim . deepcopy ( client . config )
local ra = config . settings [ " rust-analyzer " ]
-- Do rust-analyzer builds in a separate folder to avoid blocking
-- the main build with a file lock.
table.insert ( json . Ok . buildOverrideCommand , " --target-dir " )
table.insert ( json . Ok . buildOverrideCommand , " target/rust-analyzer " )
ra . cargo = {
extraEnv = json . Ok . extraEnv ,
features = json . Ok . features ,
noDefaultFeatures = true ,
target = json . Ok . target ,
buildScripts = {
overrideCommand = json . Ok . buildOverrideCommand ,
},
}
ra . check = {
overrideCommand = json . Ok . buildOverrideCommand ,
}
config . lspinfo = function ()
return { " Hubris app: " .. json . Ok . app ,
" Hubris task: " .. json . Ok . task }
end
client . config = config
end
end ,
settings = {
[ " rust-analyzer " ] = {
-- enable clippy on save
checkOnSave = {
command = " clippy " ,
extraArgs = { ' --target-dir ' , ' target/rust-analyzer ' },
},
diagnostics = {
disabled = { " inactive-code " },
},
}
}
},
}
end新しいLSP構成が作成されたら（ on_new_config ）、ターゲットファイルでcargo xtask lsp実行します。 JSON構成には、構成のハッシュが含まれています。そのハッシュを使用して、 rust_analyzerからrust_analyzer_$HASHにクライアントの名前を変更します。これにより、NeoVIMは既存のクライアントを再利用しようとすることを防ぎます。既存のクライアントは、通常、クライアント名とWorkspaceのルートディレクトリによって重複します。 Hubrisでは、同じワークスペースルートと共存する複数のクライアントが必要なので、異なる名前が必要です。次に、構成の残りをローカル変数（ cache ）に隠し、 clientsにこのクライアントの存在を記録します。
LSPに接続するときは、 cacheから構成を引き出しようとします。存在する場合、hub慢バッファーを扱っていることがわかります。構成の関連部分をコピーします。
これはあなたのためにxtaskコンパイルしないことに注意してください。 target/debug/xtaskに既に存在すると仮定しています。これは、定期的にhubrisを使用している場合に当てはまり、新しいファイルを開くときにかなりの時間を節約できます。
独自のタスクを作成するために、最も簡単な方法は次のとおりです。
task/template新しい名前にコピーします。Cargo.toml編集します。Cargo.tomlのワークスペースメンバーのリストに追加します。app.tomlファイルを編集して、システムイメージに追加します。cargo xtask build実行してコンパイルします。メモリマップされた周辺機器を使用しない小さなタスクのための典型的なapp.tomlエントリ
[ tasks . name_for_task_in_this_image ]
name = " my-task-target-name "
priority = 1
requires = { flash = 1024 , ram = 1024 }
start = true さまざまなタスクとその優先順位の関係を示すグラフを生成できます。結果のファイルはGraphVizのdot形式です。 Dotソースは、Asciidoctorソースに含めるか、さまざまな形式にレンダリングできます。
UbuntuのgimletletのSVGグラフを作成および表示するには、 graphvizパッケージがインストールされていることを確認してください。次に、グラフを生成します。
$ cargo xtask graph -o gimletlet.dot app/gimletlet/app.toml
$ dot -Tsvg gimletlet.dot > gimletlet.svg
$ xdg-open gimletlet.svgすべてのグラフを生成するためのbashコマンド：
APPS=( $(find app -name '*.toml' ! -name Cargo.toml) )
for app in "${APPS[@]}"
do
out=$(basename ${app////_} .toml).dot
svg=$(basename $out .dot).svg
cargo xtask graph -o $out $app
dot -Tsvg $out > $svg
done
first="${APPS[0]}"
out="$(basename ${first////_} .toml).dot"
svg="$(basename $out .dot).svg"
xdg-open "${svg}" eogデフォルトの視聴者である場合、ディレクトリで最初のSVGを開くことで、同じウィンドウを使用して利用可能なすべてのグラフを循環させることができます。
Hubrisは、デバッガーである謙虚さにしっかりと結合されています。これは、以下のコマンドに暗黙的に（ cargo xtask flash ）または明示的に（ cargo xtask humility ）に使用されます。
humilityバイナリが$PATHで使用できない場合、 HUBRIS_HUMILITY_PATH環境変数を使用してバイナリへのパスを提供できます。
Hubrisアーカイブ内の画像はcargo xtask flashを実行し、適切なTOMLファイルを指定することにより、ターゲットボードに直接フラッシュできます。これにより、 cargo xtask distを実行し、結果として得られたビルドアーカイブをhumility flashに渡します。 humility OpenOCDまたはPYOCDのいずれかを呼び出して画像をフラッシュします。正確な呼び出しはボードに依存し、ビルドアーカイブにエンコードされています。
cargo xtask flash app/lpc55xpresso/app.tomlcargo xtask flash app/demo-stm32f4-discovery/app.tomlcargo xtask flash app/demo-stm32h7-nucleo/app-h743.tomlcargo xtask flash app/demo-stm32h7-nucleo/app-h753.tomlcargo xtask flash app/gemini-bu/app.toml 謙ilityは、直接接続されたボードでアーカイブを指定することにより、またはダンプを指定することにより死後を指定することにより現場で実行されます。開発の便利さとして、STM32F4ディスカバリーボードが直接接続されているマシンで、適切なTOMLを指定することにより、謙虚さを現場で実行することもできます。
$ cargo xtask humility app/demo-stm32f4-discovery/app.toml -- tasks
Finished dev [optimized + debuginfo] target(s) in 0.17s
Running `target/debug/xtask humility demo/app.toml -- tasks`
humility: attached via ST-Link
ID ADDR TASK GEN STATE
0 20000108 jefe 0 Healthy(InRecv(None))
1 20000178 rcc_driver 0 Healthy(InRecv(None))
2 200001e8 usart_driver 0 Healthy(InRecv(None))
3 20000258 user_leds 0 Healthy(Runnable) <-
4 200002c8 ping 48 Healthy(Runnable)
5 20000338 pong 0 Healthy(InRecv(None))
6 200003a8 idle 0 Healthy(Runnable) humilityにはopenocd arm-none-eabi-gdb使用してランニングシステムに接続するgdbサブコマンドが含まれます。
便利なため、適切なビルドアーカイブでhumility呼び出すcargo xtask gdbファサードもあります。
$ cargo xtask gdb app/demo-stm32f4-discovery/app.toml -- --run-openocd
# ... lots of output elided ...
task_idle::main () at task/idle/src/main.rs:14
14 loop {
Breakpoint 1 at 0x800434c: file /crates.io/cortex-m-rt-0.6.15/src/lib.rs, line 560.
Note: automatically using hardware breakpoints for read-only addresses.
semihosting is enabled
semihosting is enabled
(gdb) cargo xtask gdb （デフォルトでは） distとflashも実行して、チップ上の画像が最新であることを確認することに注意してください。 -n / --noflashオプションはこれらの手順をスキップします。
Hubris Kernelは、テストランナー、アシスタント、テストスイートを含む専用のテスト画像でテストされています。テスト画像は、ITMを介して結果を発します。これらの結果は手動で解釈できますが、 humility testこれを自動化します。 humility test自体は、 cargo xtask dist 、 cargo xtask flash 、 cargo xtask humility testに相当するcargo xtask testを介して最も簡単に実行されます。正確な呼び出しはボードによって異なります：
cargo xtask test test/tests-lpc55xpresso/app.tomlcargo xtask test test/tests-stm32fx/app-f3.tomlcargo xtask test test/tests-stm32fx/app.tomlcargo xtask test test/tests-stm32h7/app-h743.tomlcargo xtask test test/tests-stm32h7/app-h753.toml注： cargo xtask humility testデバイスに接続するためにOpenOCDを実行します。テストを実行する前に、デバイスに接続したOpenOCDの他のインスタンスを終了する必要があります。
テスト結果の詳細については、 humility testのドキュメントを参照してください。
テストからの出力は、 humility testによってキャプチャされます。 sys_log!()テストへの呼び出しを追加してから、 humility testダンプでキャプチャできます。それ以外の場合は通過しているテストからダンプをキャプチャするには、 cargo xtask humility直接使用し、 -dフラグを渡します。
$ cargo xtask humility test/tests-stm32fx/app.toml -- test -d
...
humility: attached via ST-Link
humility: TPIU sync packet found at offset 1
humility: ITM synchronization packet found at offset 12
humility: expecting 22 cases
humility: running test_send ... ok
...
humility: running test_timer_notify ... ok
humility: running test_timer_notify_past ... ok
humility: tests completed: pass
humility: test output dumped to hubris.testout.2 GDBとテストスイートの両方を実行する必要がある場合は、テストイメージのTOMLと適切なGDBファイルを使用してcargo xtask gdb使用してから、関心のあるテストでブレークポイントを配置します。
Gemini Bringup Getting Docsをご覧ください（内部酸化物リポジトリ）
STM32F3ディスカバリーボードの場合、SB10はITMを機能させるためにはんだ付けする必要があります！このはんだブリッジはデフォルトで開いているため、SWOが切断されます。概略図と詳細については、STM32F3 Discoveryユーザーマニュアル（UM1570）を参照してください。
LPCXPresso55S69を使用するには、バージョン0.27.0以降のPyocdが必要です。
LPCXPresso55S69は、ビルトオンオンチップデバッガーLPC-Link2がSWO/SWVを正しくサポートしていないため、やや混乱しています。
株式LPC-Link2をお持ちの場合、 pyocd listを介してこのように報告します。
$ pyocd list
# Probe Unique ID
-----------------------------------------------------------------
0 NXP Semiconductors LPC-LINK2 CMSIS-DAP V5.361 JSAQCQIQまた、Segger J-Linkファームウェアを持っている可能性もあります。これにより、 pyocd list実行するたびにライセンス条件を受け入れるように求めているといういやらしい存在感があります。
$ pyocd list
# Probe Unique ID
-----------------------------------------------------------------------------
0 Segger J-Link LPCXpresso V2 compiled Apr 4 2019 16:54:03 726424936これらのケースのいずれかで、1回限りのステップとして、LPC-Link2に新しいファームウェアをインストールする必要があります。新しいファームウェアは、（オープンソース）Daplinkのビルドであり、それをすべて構築することができたエンジニアにちなんでRicklinkと呼ばれます。小さな偉業はありません！
必要な2つのファイルがあり、どちらもhubrisリポジトリに含まれています。
さらに、NXPからLPCScryptプログラムが必要になります。
リックリンクをインストールする手順は次のとおりです。
DFUジャンパーをインストールします。これは、ボードの左側にあるSWDヘッダーの隣にあります。 「DFU」とラベル付けされています。
インストールされているLPCScryptソフトウェアからscripts/boot_lpcscryptを実行します。
$ /usr/local/lpcscrypt/scripts/boot_lpcscrypt
Looking for DFU devices with VID 1fc9 PID 000c ...
dfu-util -d 1fc9:000c -c 1 -i 0 -t 2048 -R -D /usr/local/lpcscrypt/scripts/../bin/LPCScrypt_228.bin.hdr
Booted LPCScrypt target (1fc9:000c) with /usr/local/lpcscrypt/scripts/../bin/LPCScrypt_228.bin.hdr
$lpcscrypt clockslow実行します： $ /usr/local/lpcscrypt/bin/lpcscrypt clockslow
$lpcscrypt program +w1 0x0 BankA実行して、既存のファームウェアを上書きする$ /usr/local/lpcscrypt/bin/lpcscrypt program +w1 0x0 BankA
................
Programmed 524288 bytes to 0x1a000000 in 2.610s (196.165KB/sec)
$lpcscrypt program +c <path-to-lpc4322_bl_crc.bin> BankA ： $ /usr/local/lpcscrypt/bin/lpcscrypt program +c ~ /hubris/support/lpc4322_bl_crc.bin BankA
..
Programmed 57344 bytes to 0x1a000000 in 0.827s (67.717KB/sec)
$成功していると仮定すると、DFUジャンパーを削除してUSBを切断/再接続します
MAINTENANCEという名前のUSB大容量貯蔵装置があるはずです
# fdisk -l
Disk /dev/nvme0n1: 477 GiB, 512110190592 bytes, 1000215216 sectors
Disk model: Micron 2200S NVMe 512GB
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: A8653F99-39AB-4F67-A9C9-524A2864856E
Device Start End Sectors Size Type
/dev/nvme0n1p1 2048 1050623 1048576 512M EFI System
/dev/nvme0n1p2 1050624 967393279 966342656 460.8G Linux filesystem
/dev/nvme0n1p3 967393280 1000214527 32821248 15.7G Linux swap
Disk /dev/sda: 64.1 MiB, 67174400 bytes, 131200 sectors
Disk model: VFS
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000
# mount /dev/sda /mnt
# ls /mnt
DETAILS.TXT PRODINFO.HTM
# cat /mnt/DETAILS.TXT
# DAPLink Firmware - see https://mbed.com/daplink
Unique ID: 02360b000d96e4fc00000000000000000000000097969905
HIC ID: 97969905
Auto Reset: 1
Automation allowed: 1
Overflow detection: 1
Daplink Mode: Interface
Interface Version: 0254
Bootloader Version: 0254
Git SHA: f499eb6ec4a847a2b78831fe1acc856fd8eb2f28
Local Mods: 1
USB Interfaces: MSD, CDC, HID, WebUSB
Bootloader CRC: 0x09974fb3
Interface CRC: 0x7174ab4c
Remount count: 0
URL: https://os.mbed.com/platforms/LPCXpresso55S69/lpc4322_lpc55s69xpresso_if_rla_swo_hacks.binにUSBドライブにコピーします$ sudo cp ~ /hubris/support/lpc4322_lpc55s69xpresso_if_rla_swo_hacks.bin /mnt
$# umount /mnt
# pyocd list実行して、新しいファームウェアにいることを確認してください。
$ pyocd list
# Probe Unique ID
-------------------------------------------------------------------------------------
0 LPCXpresso55S69 [lpc55s69] 02360b000d96e4fc00000000000000000000000097969905 LPCXPresso55S69で実行されているRicklinkは、GeminiキャリアボードのLPC55S28のデバッガーとしても使用できることに注意してください。これを行うには、最初に、上記のすべての指示に従って、ricklinkをlpcxpresso55S69に導きます。それから：
はんだ鉄を使用して、J5に2ピンヘッダーをはんだ付けします。 J5は、P1の左側と「デバッガー」ジャンパー（J3）の下にあります。
新しいヘッダーにジャンパーを置きます
「デバッガー」ジャンパー（J3）を「ext」に移動します。
SWDケーブル（10ピン2x5 1.27mmピッチケーブル）を使用して、LPCXPresso55S69のSWDをGemini（J202）のキャリアボードの下のSWDに接続します
（Ricklinkが再びローカルLPC55S69をデバッグできるようにするには、J5のジャンパーを削除してJ3を「loc」に移動します。）
複数のプローブが添付されている場合、ツールは適切なタイミングで適切なプローを見つけるのに苦労する場合があります。特に、OpenOCDは最初に見つけたものを選択します。 OpenOCDに特定のプローブを選択するように強制するには、プローブのシリアル番号（ humility probeなど）を確認し、次のことを追加して、対応するopenocd.cfgのシリアル番号を指定できます。
interface hla
hla_serial 271828182845904523536028
（ 271828182845904523536028はプローブのシリアル番号です。）
ドングルのデバッグ、およびNucleoシリーズのような埋め込みデバッグハードウェアを備えた開発ボードは、古いファームウェアで配信されることがよくあります。
時代遅れのSTリンクファームウェアでは、屈辱を使用することはできません。謙虚さは、 humility test使用しようとするときなど、これが当てはまることを教えてくれます。
...
Warn : Adding extra erase range, 0x08020060 .. 0x0803ffff
** Programming Finished **
** Verify Started **
** Verified OK **
** Resetting Target **
humility: test failed: The firmware on the probe is outdated
Error: test failed
この「ST-Linkファームウェアアップグレード」リンクに従って、現在のファームウェアをインストールするために必要なソフトウェアと指示を見つけてください。
