mcpField
J
jetson-init-target

jetson-init-target

github.com/nvidia開発3.8k1.1k 回インストール今日更新
リポジトリ

jetson-init-target について

Jetson のターゲットプラットフォーム設定を作成するスキルです。参照開発キットと任意のカスタムキャリア情報を記録する開発フロー向けで、カタログと YAML テンプレートから設定を作り、デフォルトでアクティブターゲットのポインターを更新します。

主な機能

  1. 01カタログから参照製品とフラッシュ設定を選択
  2. 02カスタムキャリア情報の任意記録
  3. 03テンプレートに基づくターゲット YAML の生成
  4. 04アクティブターゲット設定のデフォルト更新

活用シーン

  1. 01未登録の Jetson プラットフォーム設定の作成
  2. 02プラットフォーム設定へのカスタムキャリア情報の追加
  3. 03プロジェクトのアクティブターゲットの初期化

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/nvidia/skills --skill jetson-init-target

インストール後、Claude Code で/jetson-init-targetを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

BENCHMARK.md
skill-card.md
skill.oms.sig
evals/
evals.json
references/
gotchas.md
ui-samples.md

詳細

ターゲットプラットフォームを初期化する

概要

このスキルは、新しいターゲットプラットフォームのプロファイル YAML を作成します。これは、契約の書き込み側にあたります。 ../../context/target-platform-contract.md を参照してください。正規の製品/フラッシュ設定カタログとして ../../references/bsp-platforms-catalogue.md を、 フィールドスキーマとして ../../references/platform_template.yaml を使用します。

フローは直線的です。参照製品とフラッシュ設定を選び、その後、任意でカスタムキャリアの詳細を追加します。契約上の2つのケース(参照のみ、参照+カスタムキャリア)は、ユーザーがカスタムキャリアの詳細を提供するかどうかだけで区別されます。最初にモードを尋ねることはありません。

対象範囲は reference_devkit: と custom_carrier: のみです。 他のブロックは、関連するスキルが担当します。bsp_image: → jetson-init-image、source: → jetson-init-source、documents: → jetson-link-docs。

出力は、新しい target-platform/<name>.yaml と、デフォルトではそのファイルを参照するよう更新された active_target.yml です。すでに作成済みのプロファイルを切り替えるには、関連する jetson-set-target を使用してください。

呼び出すタイミング

  • ユーザーが新しいターゲットプラットフォームのプロファイルを作成、追加するよう求めた場合。
  • 下流のスキルが「有効なターゲットがない」として拒否し、かつ target-platform/ にプロファイル YAML ファイルがまだない場合(ファイルがある場合は、jetson-set-target を優先してください)。
  • ユーザーが、プロファイルがまだディスク上に存在しないターゲットを求めている場合。

手順

クイックスタートの事前入力マッピング

共通の quick_start_prefill 契約に従います。 このスキルが使用する値は次のとおりです。

  • quick_start_prefill.target.active_platform がカタログ内の製品1つに解決される場合、選択されたカタログの行として使用します。
  • quick_start_prefill.target.custom_carrier は、カスタムキャリアに関する意図として使用します。

active_platform がカタログ内の1行に解決される場合は、その行をそのまま使用します。参照製品やフラッシュ設定について再度尋ねないでください。事前入力でカタログのバリアントが指定されていない限り、その行のデフォルトのフラッシュ設定を使用します。事前入力がない、無効である、曖昧である、または未知のバリアントが指定されている場合にのみ尋ねてください。

スキルによるテンプレートの使用方法

スキルの起動時に ../../references/platform_template.yaml を一度読み込み、質問するブロックのスキーマとして扱います。各プレースホルダー値には、次の3種類のセンチネルマーカーのいずれかが付いています。

マーカー動作
<REQUIRED: description>ユーザーに尋ねます。値の入力が必要です。NA は受け付けますが、下流のスキルが拒否する可能性があることを警告します。
<OPTIONAL: description>ユーザーに尋ねます。値は省略できます(Enter または NA)。省略したフィールドは、作成されるプロファイルから除外されます(空のキーや NA のプレースホルダーは残しません)。
<DERIVED: description>bsp-platforms-catalogue.md と、「参照製品を選択する」および「フラッシュ設定を選択する」ステップでユーザーが選んだ製品/フラッシュ設定からプログラムで入力します。質問しません。

マーカーの説明を、プロンプト文としてそのまま使用します。YAML の解析で周囲の引用符が取り除かれた後、正規表現 ^<(REQUIRED|OPTIONAL|DERIVED):\s*(.*)>$ を使ってマーカーを照合します。

ブロック単位での包含(custom_carrier)はスキルのフローで決定し、マーカーでは決定しません。ブロック内のフィールドの追加や削除は、テンプレートのみの変更です。

現在の状態を確認する
  1. target-platform/ が存在しない場合は作成し、 ../../references/active_target_template.yaml を target-platform/active_target.yml にコピーします(拡張子は .yml です)。
  2. target-platform/active_target.yml を読み取ります。
  3. target-platform/*.yaml を一覧表示します(active_target.yml は除外します)。
状況アクション
プロファイル YAML が存在しない続行します。これは初期セットアップの場合です。「Write」ステップで新しいプロファイルが自動的に active_target に設定されます(「Confirm」ステップで有効化を確認するプロンプトは表示されません)。
プロファイルが存在し、active: NA既存のプロファイル一覧を表示し、ユーザーが新しいプロファイルを作成する(既存のプロファイルを jetson-set-target で有効化するのではなく)ことを希望しているか確認します。
プロファイルが存在し、active: に存在するファイル名が指定されているアクティブなプロファイルと全プロファイル一覧を表示します。(a)既存のプロファイルと並べて新しいプロファイルを作成するか、(b)jetson-set-target で既存のプロファイルに切り替えるかを尋ねます。(b)の場合は、停止して jetson-set-target を実行するようユーザーに伝えます。
active: に存在しないファイル名が指定されているポインターが壊れていることをユーザーに伝え、新しいプロファイルを作成してポインターを置き換えるか、ポインターを手動で修正するかを提示します。
プラットフォームカタログを読む

../../references/bsp-platforms-catalogue.md を読み取ります。 **「Product / Chip / SKU / Flash Config Mapping」**テーブルを解析します。ここが、製品名、CVM/CVB SKU、デフォルトのフラッシュ設定、バリアントのサフィックスの正確な情報源です。Linux_for_Tegra/*.conf を走査したり、conf ファイル名を解析したりしないでください。カタログですでに集約されています。

参照製品(ベースライン)を選ぶ

質問する前に、カタログ全体の一覧を表示します。行をチップファミリーごとにグループ化し、この実行中に限り安定したインデックスを各エントリーに付けます。リストは bsp-platforms-catalogue.md のみから作成し、サンプルや他のドキュメントからプラットフォームの行をコピーしないでください。

表示したリストから、各チップファミリーグループの先頭行を使って明示的なショートカットの選択肢を作成します。各ショートカットのラベルには、完全なリストのインデックスと製品名を含めます。例:Index 1 — Jetson AGX Orin 64GB。製品名をハードコードせず、解析したカタログの行からショートカットを生成します。この質問で明示的に提示する選択肢は、これらのショートカットのみです。手動でインデックスを入力する場合は、ツールに組み込まれた Type something 入力を使用します。手動入力用のカスタム選択肢を追加しないでください。

プロンプトの文面:

プラットフォームのショートカットを選ぶか、「Type something」を選択して、上に表示されたプラットフォーム一覧の数値インデックスを入力してください。ハードウェアがこれらの Jetson モジュールのいずれかを搭載したカスタムキャリアの場合は、ベースラインとして最も近い参照開発キットを選んでください。この実行をキャンセルするには cancel と入力してください。

T234 / Orin family や T264 / Thor family など、チップファミリーを選択肢として表示しないでください。Type index、Manual entry、Other platform、または手動入力用のカスタム選択肢を表示しないでください。手動入力には、ツールが提供する Type something の行のみを使用します。選択肢に Other を追加したり、プロンプトの文面で Type something を Other と言い換えたりしないでください。このステップでは製品名の部分一致を受け付けず、入力として受け付けるのは、表示した全リスト内の数値インデックスまたは cancel のみです。このスキルでは参照プラットフォームなしにターゲットプロファイルを作成できないため、skip は許可されません。

ショートカットまたは入力されたインデックスを、カタログの行1つに厳密に対応付けます。入力されたインデックスが範囲外または無効な場合は、有効なインデックスの範囲を表示して再度尋ねます。ユーザーが skip と入力した場合は、jetson-init-target には参照プラットフォームが必要であることを説明して、再度尋ねます。ユーザーが cancel と入力した場合は、プロファイルを書き込まずに停止します。

フラッシュ設定を選択する

カタログの行では、Default flash conf がオプション 1 です。Variants 列には接尾辞(オプション 2..N)が一覧表示されています。デフォルト設定ファイルのベース名に接尾辞を追加して、各バリアントの完全な設定ファイル名を組み立てます。Variants 列に (same as <other>) と記載されている行では、参照先の行のバリアント一覧をそのまま再利用します。このリストは、選択したカタログの行のみをもとに作成します。

プロンプト:

番号を選択するか、Enter キーを押してデフォルト(1)を受け入れてください。

選択した行にバリアントがない場合(カタログで — と表示されている場合)は、デフォルト設定ファイルを使用して「任意:カスタムキャリアの詳細を追加する」の手順に進みます。

エッジケース:

  • Raw 設定ファイルのバリアント(カタログでは (raw) と表示)。Orin Nano の場合、-a0-maxn (raw) → p3768-0000-p3767-0000-a0-maxn.conf です。Raw のファイル名をそのまま使用します。
  • (same as <other>) プレースホルダー。 参照先の行のバリアントをそのまま再利用します。
任意:カスタムキャリアの詳細を追加する

ベースラインとフラッシュ設定を選択した後、プロファイルにカスタムキャリアも記録するかどうかを判断します。 quick_start_prefill.target.custom_carrier が有効な具体的な意図であれば、そのまま使用します。

  • add_custom_carrier → custom_carrier: を記録し、以下のキャリアメタデータのうち不足している項目を収集します。
  • no_custom_carrier → custom_carrier: を省略して、「確認」の手順に進みます。
  • keep_existing_custom_carrier は、既存の有効なプロファイルを編集し、そのプロファイルにすでに custom_carrier: がある場合にのみ有効です。このスキルは新しいプロファイルを作成するため、曖昧な指定として扱い、以下のカスタムキャリアの意図を尋ねます。
  • skip またはプレフィル値がない場合 → 以下のカスタムキャリアの意図を尋ねます。

意図がまだ具体的に定まっていない場合は、AskUserQuestions UI を使用して、カスタムキャリアも追加するかどうかをユーザーに尋ねます。選択肢は限定し、add と skip のみを表示します。

この Jetson モジュールで使用する、顧客設計のキャリアボードの詳細を任意で追加しますか?(add / skip、デフォルトは skip)

確定した意図が skip の場合は、custom_carrier: ブロックを省略して「確認」の手順に進みます。

確定した意図が add の場合は、AskUserQuestions UI を通じて、まだ不足している custom_carrier: の値をすべて収集します。プレーンテキストのプロンプト、チャット内の質問、自由形式の要約確認、推測したデフォルト値、選択肢として提示する例の値を使用して、カスタムキャリアのメタデータを収集してはいけません。UI の質問数上限を超える場合は、複数の AskUserQuestions フォームに分けます。

最初の AskUserQuestions フォームでは、テンプレート文書の順序に従って custom_carrier.name、custom_carrier.id、custom_carrier.sku、custom_carrier.revision を尋ねます。これら4つのフィールドでは、ユーザーに表示する選択可能な入力方法として、ツールに組み込まれた Type something の行のみを表示します。例の値、「Other」、推測したボード ID、推測した SKU、一般的なリビジョン文字列、明示的なドメイン別の選択肢を追加してはいけません。これらは顧客提供のメタデータです。入力された値をそのまま保持し、命名規則、プレフィックス、大文字・小文字、文字種、桁数、SKU の形式について、要求や検証を行ってはいけません。必須フィールドが空でないことのみを検証します。ただし、ユーザーが明示的に NA を入力した場合は空でない値として扱います。必須フィールドに NA を指定することは契約上認められます。後続のスキルで必須フィールドが不足していると拒否される可能性があることを警告してください。

custom_carrier.name がわかった後、custom_carrier.flash_config がまだ未設定であれば、2つ目の AskUserQuestions フォームを通じて収集します。提案するデフォルト値のみを明示的な選択肢として表示し、カスタムの .conf ファイル名を入力できるように、組み込みの Type something の行を使用できるようにします。.conf で終わる空でないファイル名を必須とし、ボード ID、SKU、または推測した規則から導出してはいけません。

フィールド固有の動作(マーカーだけでは表現できないデフォルト/提案値):

  • custom_carrier.flash_config — kebab-case の custom_carrier.name + ".conf" をデフォルトとして提案します (例:「Acme Vision X1」→ acme-vision-x1.conf)。
  • custom_carrier.name — プロンプト:「記録したい顧客向けのカスタムキャリアまたは製品名を、正確に入力してください。形式の指定はありません。」Type something のみを使用します。
  • custom_carrier.id — プロンプト:「記録したいカスタムキャリアボード ID またはプロジェクト ID を、正確に入力してください。形式の指定はありません。」 Type something のみを使用します。
  • custom_carrier.sku — プロンプト:「記録したいカスタムキャリアの SKU またはバリアント識別子を、正確に入力してください。形式の指定はありません。」 Type something のみを使用します。数値のように見える値や先頭のゼロが保持されるよう、YAML に記述する際は引用符で囲みます。
  • custom_carrier.revision — プロンプト:「記録したいカスタムキャリアのリビジョンまたはビルド識別子を正確に入力するか、Enter キーを押して省略してください。形式の指定はありません。」Type something のみを使用し、省略された場合は除外します。

値がわからない場合は、起動中のターゲットで /proc/device-tree/chosen/ids を確認するよう提案します。本当に確認できない場合は、必須フィールドには NA を指定でき、任意のフィールドは省略できます。

テンプレートでは意図的に custom_carrier.module と custom_carrier.chip_family を省略しています。モジュールの識別情報は reference_devkit.module から取得します(同じ物理 Jetson モジュールを両方のキャリアに挿入するためです)。これらを追加しないでください。

確認

提案する YAML を表示します。形式は「任意:カスタムキャリアの詳細を追加」ステップでユーザーがカスタムキャリアの詳細を追加したかどうかによって異なります。**例:**リファレンスのみの場合とリファレンス+カスタムキャリアの場合の YAML の形式、およびどの関連スキルがどのブロックを追記するかについての注記は、 references/ui-samples.md を参照してください。

推奨ファイル名:

  • **リファレンスのみ:**選択したカタログ行の製品名を kebab-case にし、.yaml を追加します。例:Jetson AGX Thor T5000 → jetson-agx-thor-t5000.yaml、Jetson AGX Orin 32GB → jetson-agx-orin-32gb.yaml。ファイル名を flash_config から生成しないでください。複数の製品が同じデフォルトの conf を共有する場合があります。
  • カスタムキャリアあり:custom_carrier.name を kebab-case にします。例: 「Acme Vision X1」→ acme-vision-x1.yaml。

推奨ファイル名が一意で、選択したプラットフォーム名またはカスタムキャリア名から生成された場合は、確認を求めずにそのファイル名を使用します。ファイル名を表示して続行します。確認を求めるのは、名前が重複する場合、生成された名前が空の場合、入力が曖昧な場合、または明示的にカスタムファイル名を求められた場合のみです。次に、アクティブ化を処理します。

  • ブートストラップの場合(「現在の状態を調査」ステップの時点でプロファイル YAML が存在しなかった場合):**確認を求めないでください。**新しいプロファイルが最初のプロファイルなので、「書き込み」ステップで自動的にアクティブ化されます。自動アクティブ化が通知なしに行われないよう、ユーザーにその旨を伝えてください。
  • すでにプロファイルが存在する場合:新しいプロファイルをアクティブ化するか尋ねます(デフォルト:はい)。ユーザーが後で選べるよう複数のプロファイルを作成している場合のみ、アクティブ化を辞退します。どのプロファイルも jetson-set-target でアクティブ化できます。
書き込み(必要に応じてアクティブ化)
  1. target-platform/<filename>.yaml に書き込みます。ファイルがすでに存在する場合は、上書きする前に確認します。黙って上書きしてはいけません。

  2. 次のいずれかに該当する場合は、target-platform/active_target.yml を編集して active: <filename>.yaml に設定します。

    • 「現在の状態を調査」ステップでのブートストラップの場合(この実行の前にプロファイル YAML が存在しなかった場合)。以前のユーザー入力にかかわらず、自動的にアクティブ化します。
    • すでにプロファイルが存在し、「確認」ステップでユーザーがアクティブ化を承諾した場合。

    ヘッダーコメントブロックを保持し、active: 行のみを変更します。 すでにプロファイルが存在し、ユーザーがアクティブ化を辞退した場合は、active_target.yml を変更しません。

確認

次の内容をまとめて表示します:プロファイルのパス、アクティブなポインター(有効化が見送られた場合は「変更なし」)、Tegra ファミリー(T234 / T264)、custom_carrier: が記録されたかどうか、後続のスキルはアクティブなプロファイルを参照することのリマインダー。ユーザーが複数のプロファイルを作成し、有効化していない場合は、プロファイルを選ぶために jetson-set-target を案内します。

次のステップ(セットアップ → カスタマイズの連鎖):

  1. /jetson-init-image — BSP を展開し、bsp_image: を追加します。
  2. /jetson-init-source — 共有リポジトリをクローンします(ユーザーが source.root_path をプロファイルに書き込みたい場合は、必要に応じて <workspace>/Source を上書きします)。
  3. /jetson-link-docs (任意) — 事前にダウンロードした BSP/回路図/ピンマックスのドキュメントへのパスを、プロファイルの documents: ブロックに登録します。

次に、customize-* スキルを使う前に(カスタマイズ):

  1. /jetson-generate-kb — customize-* スキルが対象固有のファイルの場所を調べるための KB です。
  2. /jetson-derive-carrier (カスタムキャリアのみ) — 参照用の開発キットから、カスタムキャリアのフラッシュ設定と関連する DTSI を生成します。カスタムキャリアで個別の設定項目をカスタマイズする前に必須です。

この実行が後続のスキルによって開始された場合は、ユーザーに元のリクエストを再度送信するよう伝えてください。黙って再実行してはいけません。

前提条件

  • bsp-platforms-catalogue.md と platform_template.yaml に、References セクションの相対パスからアクセスできること。
  • target-platform/(有効化が要求された場合は target-platform/active_target.yml)への書き込み権限があること。
  • 「これはどのモジュール/キャリアか」を確認する場合は、起動中のデバイス上に /proc/device-tree/chosen/ids があること。

制限事項

  • 管理対象は reference_devkit:、custom_carrier:、および active_target.yml ポインターのみです。bsp_image:、source:、documents: の書き込みは拒否します。
  • SKU、モジュール ID、カスタムキャリアのメタデータ、フラッシュ設定を捏造しません。ユーザーが必須の値を把握していない場合は、NA を記録するか処理を中止します。

トラブルシューティング

  • ユーザーが作成ではなく切り替えを求めている — 要求を拒否して jetson-set-target に案内します。既存のプロファイルを作成し直してはいけません。
  • ユーザーが指定した製品がカタログにない — まず bsp-platforms-catalogue.md に行を追加します。このスキル内の製品リストを直接修正してはいけません。
  • 必須フィールドが NA のまま — 後続の customize-* スキルで拒否される場合があります。不足している値を取得し(/proc/device-tree/chosen/ids を読み取る)、再実行してください。
  • 有効化後に active_target.yml のコメントブロックが失われた — ラウンドトリップに対応していない YAML ライターが使われています。ruamel.yaml に切り替え、テンプレートから復元してください。

落とし穴の一覧(カタログとテンプレートの分離、NA の扱い、設定ファイルの衝突ルールなど)については、references/gotchas.md を参照してください。

参考資料

コメント