LS1046Aカスタムボード：eMMC、SDカード、QSPIからのコールドブートが失敗。CodeWarrior RCW適用によりU-Bootが有効化される。 こんにちは、 LS1046ARDBデザインに基づくカスタムLS1046Aボードを導入します。自律コールドブートは失敗していますが、CodeWarriorやQCVSの介入によりプロセッサはBL2、BL31、U-Bootコンソールに到達できます。eMMC、SDカード、QSPI NORでコールドブートの失敗を観察しているので、共通のリセット/クロック/PBL経路の分離方法についてのアドバイスをいただけるとありがたいです。 プラットフォームとLS1046ARDBとの違い 項目 カスタムボード構成 プロセッサ LS1046AE Rev. 1.0; U-BootはSVRを報告します 0x87070010 電源/リセット制御 CPLDなし。STM32 BMC、PCA9539 I/Oエキスパンダ、レベルトランスレータ、およびディスクリートリセット回路が、シーケンス処理とSD/eMMCの選択を実装します。 DDR 4 GiB、シングルランク、64ビット非ECC DDR4、初期化済み 1600 MT/秒。これは、RDB比較で使用した8GiB ECC構成とは異なります。アシストブート後、DDRの初期化は成功しました。ただし、完全なメモリマージン認定はまだ保留中です。 クロック 100MHzのプライマリ基準。動作支援構成では、シングルエンドSYSCLK選択を使用します。DDRは差動参照パスを使用する。U-BootはCPUが1800 MHz、プラットフォームが600 MHz、FManが700 MHzと報告しています。 EMMC マクロニックス MX52LM08A11XVIは、RDBデバイスとは異なります。U-Bootは製造元、名称 0xc2 M08A11、MMC 5.1、約7.3 GiBのユーザー容量 識別します。 SD/eMMCインターフェース BMC制御による選択とEVDD：eMMCの場合は1.8V、SDの場合は3.3V。 QSPI NOR S25FS512S、デバイスあたり64MiB。この基板ではNOR検出に成功しました。 他のプリフェラル カスタムイーサネット/PHYルーティングおよびSerDes構成;PCIeデバイスは使用されません。 ソフトウェア A1固有のボード/デバイスツリーの変更、TF-A v2.12.0に基づく lf-6.12.49-2.2.0、U-Boot 2025.04。U-Bootのウォッチドッグは起動時には無効になっています。 リセットネットワークもこの調査中に再構築され、競合するプロセッサ-PORドライバブランチが分離され、BMCからTRSTへの直接ドライブが切断され、ハードウェアPOR/TRST結合パスが取り付けられました。BMCによるHRETセンサーは接続されたままです。 最新のネイティブコールドブーツ観察結果 BMCシーケンスにおいて、意図せず早期にSoCリセットが発生していたことを発見し、修正しました。続いて、CodeWarriorやQCVSの操作を一切行わずに完全に電源をオフにした状態から取得したスコープキャプチャは以下のとおりです。 - BMCがプロセッサリセットを解除するとPORESET_Bが上昇します。 - eMMCのCLKおよびCMDアクティビティは、そのエッジの後に開始されます。 - 通常のBL2/U-Bootコンソール出力は表示されません。以前の試みでは、無効なUART文字しか得られなかった。 - HRESET_Bとラベル付けされたトレースはHIGH(約1.8 V)のままです。キャプチャされたeMMC活動の前後にLOWの主張は観測されません。BMC HRESET入力も繰り返しHIGHを読み取る。 CodeWarrior/QCVSの動作 コールドブートストール中、CodeWarrior InspectはJTAGチェーンに「CortexA72#0」が見つからないことを報告し、RCWの確認やRCWオーバーライドの有効化を推奨します。 しかし、RCW適用を有効にしてデバッグをクリックするか、QCVS経由でRCWを適用すると、ブートが進行します。UARTがU-Bootに到達しているにもかかわらず、Debugが「コアがデバッグモードではありません」と報告することがあります。他の試行では、ターゲットが停止し、「continue」によってブートが完了する。 初期化スクリプトを以下のように簡略化しました。 from cw.dbg import ta def run_init_file(): target = ta.create() target.rcw.set_source(0x40) target.rcw.set_data({13:0x00004504}) target.rcw.apply() 物理ストラップはSD/eMMCソース「0x40」に設定されました。入力されたワード13は、eMMCに既に保存されている値と同一です。この簡略化されたスクリプトにより、アシストブートも可能になった。同じ単語を使用して「set_source(0x9E)」を個別にテストしたところ、こちらも成功しました。 この簡略化されたスクリプトには、DDR初期化、BRR、PC、SCTLR、または再開操作は明示的に含まれていません。「rcw.apply()」とデバッガ起動フレームワークは内部リセットや実行制御操作を依然として実行できることを認識しています。これは受動的なアタッチではありません。 支援を受けて、16語すべてのRCWSR語が意図されたメディアRCWと一致しました。BL2はOCRAM内に存在し、計測されたブートチェーンはDDR初期化、eMMC/FIPロード、BL31およびU-Bootを完了した。介入後の「RSTRQPBLSR」の読み取り数はゼロでしたが、これらは元の低温障害状態を捉えたものとは考えていません。 既に実施されたテスト テスト観察 eMMCからのネイティブブート 自律的なコンソール起動は行われず、デバッガ支援によるリカバリによってU-Bootに到達する。 SDカードからのネイティブブート BMCがSDを検出/選択したにもかかわらず、同様のコールドブート失敗が発生した。アシストブートは可能だった。 QSPI NORからのネイティブブート 最新のテストでは、コールドブートの不具合も確認された。三つのメディアが同じ内部段階で止まることはまだ確立されていません。 スタンドアロンのハードコードされたソースストラップ 0x9E そして 0x9F その後のテストでは、期待されていたスタンドアロンリセットの進行状況は得られなかった。ハードコードされたRCWだけでは完全なU-Bootイメージにはならないことは理解しています。 安全なRCWを有効にした標準RDB初期化 回復は可能でしたが、DDRやCPUの状態、ペリフェラルも変更するため、これは単発のテストではありませんでした。 上記の最小限の適用専用スクリプト ソースリクエストを使用すれば、ワード13が保存値と等しい場合でも復旧可能です。 0x9E そして 0x40。 QCVS RCWテスト/リードバック テストは合格し、介入後の読み出し結果は意図した構成と一致した。ネイティブフェッチは未検証です。 3つのPCIe PBIアクセスを削除しました ネイティブコールドブートに改善は見られなかった。 SerDes2を無効にした後、両方のSerDesブロックを無効にします。 改善は見られない。アシストされたU-Bootログにより、変更されたRCWワードが確認された。 DDR診断 SPDの読み取りと4GiBの初期化は、支援を受けた後、1600MT/sで成功しました。ただし、完全なマージンテストではありません。 BL2/BL31/U-Bootのマイルストーンログ機能を追加しました。 補助付きブートはすべての段階を完了します。ネイティブ障害は最初のBL2マイルストーンを示さず、これらのログはハードウェアPBL自体を追跡できません。 eMMC RCWとイメージ配置 SerDesを両方有効にしたeMMCのベースラインは以下のとおりです。 0c100012 0e000000 00000000 00000000 13335a06 40400012 60040000 c1000000 00000000 00000000 00000000 0001c83e 00004504 24001002 00000096 00000001 SerDesを両方とも無効にした実験では、以下の単語のみが変更されました。 RCW05 = 00000000 RCW06 = 00f00012 eMMCユーザーエリアでは、512バイトセクタを使った: コンポーネント開始LBAバイトオフセット RCW + PBI + BL2コンテナ (bl2_emmc.pbl) 0x8 0x1000 BL31とU-Bootを含むFIP 0x800 0x100000 FManマイクロコード 0x4800 0x900000 書き込まれたPBL/BL2領域とFIP領域を読み戻したところ、それらのSHA-256値は、これらのテストのために転送されたファイルと一致した。PBIストリームはデコードされ、CRCチェックが行われた。OCRAMのブート場所を設定し、継承されたNXPインターコネクト/USB準備およびPBL同期操作を実行し、BL2をOCRAMにコピーします。PCIeレジスタアクセスを削除してもストールは解決しませんでした。DDRの初期化は、後ほどBL2によって実行されます。 また、eMMCの`EXT_CSD[162] = 0x00`および`EXT_CSD[179] = 0x00`を読み取りましたが、これらの設定に不可逆的な変更は加えていません。 指導を要請 1. HRESETのタイミング：LS1046Aは、PORESET_B、有効なリファレンスクロック、および初期eMMCトランザクションに対して、正確にどの時点でHRESET_BをLOWにすべきでしょうか？プロセッサ側のプローブでLOWアサートが確認できない場合、リセット、クロック、パワードメイン、ストラップ、テストモードのどれを最初に確認すべきでしょうか? 2. 介入前のキャプチャ:A72コアが発見される前に、停止したPBL/DCFG/eSDHCの状態をリセットやRCWオーバーライドなしで読み取るための、サポートされているCodeWarrior/CCSシステムアクセスポート手順はありますか?必要なアクセスコンテキスト、コマンド、そして最も有用なステータス/エラーレジスタを提供してください。 3. RCWの適用セマンティクス：`rcw.apply()`は具体的に何を行うのかソース `0x40` または `0x9E` を使用し、指定されたワードが 1 つだけの場合、どうしますか？どのリセット／デバッグ制御が実行され、未指定のRCWワードはどのように取得されるのか？入力された単語によって結果として得られるRCWが変更されない場合に、回復を可能にするアクションを特定したいと考えています。 4. RCW/PBI のレビュー: 上記の eMMC RCW と配置に何か問題はありますか?このカスタム構成に関して、追加の必須PBI操作や関連するシリコンエラータはありますか？ 5. 次の決定的な測定: eMMC、SD、QSPI 全体にわたる症状を考慮すると、リセット/クロック/ストラップの問題をブートメディアの初期化、RCW の取得、または後続の PBI の実行から最も適切に分離できる測定または非侵襲的なレジスタキャプチャは何ですか? Re: LS1046A custom board: cold boot fails from eMMC, SD and QSPI; CodeWarrior RCW apply enables U-Bo @Hiran_E_H
波形にHRESET_Bがアサートされていないが、これは想定外である。
AN12081のセクション5.1（SDカードを使用した起動プロセス）を参照してください。この文書ではSPL/U-Bootの起動フローについて説明していますが、現在のBL2/BL31の起動フローも非常によく似たハードウェア起動シーケンスに従っています。波形を図3と比較してください。
現在の観察結果に基づくと、リセット関連部品のハードウェアに問題がある可能性が高い。また、リセット設計をCPLDを使わないFRWY-LS1046Aと比較するのも有益かもしれません。
さらに、ASLEEP信号は起動プロセスにおいて重要な信号ですので、必ず確認してください。
ありがとうございます。 Re: LS1046A custom board: cold boot fails from eMMC, SD and QSPI; CodeWarrior RCW apply enables U-Bo テスト中のシーケンスキャプチャ Re: LS1046A custom board: cold boot fails from eMMC, SD and QSPI; CodeWarrior RCW apply enables U-Bo ASLEEPは常に高く、コネクテッドLEDは常に点灯しています。 ハードウェアの再作業なしで2枚目のボードを使い、同じRCWでSDカードから起動しようとしましたが、電圧選択が変わったところ、HRESET_Bが低くなっているのが観察され、PORESET_Bを低から高に解放しました。 HRESET_B の急上昇は、PMIC PG と SoC が HRESET_B をローに駆動し始めた後の 1.8V プルアップによるものと予想されます。 現在、eMMC/SDのCMD、DATA、CLKを調べて、何らかのトランザクションが発生しているかどうかを確認しています。SoCがHRESET_Bをリリースするために満たすべき条件を教えていただけますか？ 好奇心から、同じSDカードをls1046a_rdbボードに挿入して電源を入れてみたところ、ubootコンソールまで到達しました。 Re: LS1046A custom board: cold boot fails from eMMC, SD and QSPI; CodeWarrior RCW apply enables U-Bo @Hiran_E_H
参照マニュアル LS1046A 4.4.1 電源オンリセットシーケンス
ステップ5とステップ15の間に問題がある可能性があります。
HRESET_Bの出発点が明確に特定できないため、ステップ1から4までも確認する必要があります。
よろしくお願いします。 Re: LS1046A custom board: cold boot fails from eMMC, SD and QSPI; CodeWarrior RCW apply enables U-Bo こんにちは、 LS1046A リファレンス・マニュアルのセクション4.4.1を教えていただきありがとうございます。ステップ1～4とステップ5～15を確認し、測定値をAN12081のセクション5.1/図3～4と比較しています。 以下は、9月29日に実施したテストの最新情報と、QCVSで生成されたSD候補に関する9月30日のフォローアップです。確認のため、PORESET_B、HRESET_B、SD CMD、およびRESET_REQ_Bのオシロスコープ波形を添付いたします。 HRESET観測結果の更新 2台目のA1カスタム基板では、初期の基板のリセットなしにテストされ、PORESET_Bがリリースされる前にHRESET_Bが低くなるのが観察できます。これは、HRESET_Bが継続的にHIGHであった以前のキャプチャとは異なります。私たちは、その以前の波形をこの基板の代表的な波形として扱っていません。 現在の差動クロックSDテストの場合： スタンドアロンのコールドスタートアップ中、HRESET_BはPORESET_Bが上昇する前にLOWになり、その後もLOWのままです。BL2のコンソール出力は表示されません。 CodeWarriorのDebug/RCW適用後、HRESET_BがHIGHになります。 デバッガーは最初にPC=0で停止します。「続行」をクリックすると、BL2 → BL31 → U-Boot が実行されます。 添付のキャプチャデータ（SD CMDおよびRESET_REQ_Bアクティビティを含む）を、想定されるシーケンスと照らし合わせて解釈するお手伝いをお願いします。 下の写真ではSDカードを挿入しておらず、リセットリクエストが低くなっているのが確認できました。 （注：一部の画像では、誤ってsdコマンドではなくemmcコマンドと記載されています。） SDカード挿入でキャプチャ - スイッチはemmc/sdカードモードにストラップされています。 Captured with with poreset_b, hreset_b, reset_request, vcc1v8 with SD card insertedCaptured with with poreset_b, hreset_b, reset_request, vcc1v8 with SD card insertedCaptured with with poreset_b, hreset_b, reset_request, vcc1v8 with SD card insertedSDカードを挿入した状態で、poreset_b、hreset_b、reset_request、vcc1v8を使用してキャプチャしました。 Captured with with poreset_b, hreset_b, reset_request, sd_cmdCaptured with with poreset_b, hreset_b, reset_request, sd_cmdCaptured with with poreset_b, hreset_b, reset_request, sd_cmdporeset_b、hreset_b、reset_request、sd_cmdを使用してキャプチャしました Captured with with poreset_b, hreset_b, sd_cmd, trst_b(jtag reset)Captured with with poreset_b, hreset_b, sd_cmd, trst_b(jtag reset)Captured with with poreset_b, hreset_b, sd_cmd, trst_b(jtag reset)poreset_b、hreset_b、sd_cmd、trst_b（JTAGリセット）を使用してキャプチャしました Captured after entering debug mode after cold start stallCaptured after entering debug mode after cold start stallCaptured after entering debug mode after cold start stallコールドスタートで停止した後、デバッグモードに入った後にキャプチャされた 新しいSD RCWテスト 外部SD/MMCブートを選択した状態（cfg_rcw_src=0x40）で、両方のSerDesブロックを無効にした新しいSDイメージを生成しました。100 MHz 差動プライマリ基準を選択し、ハードコードされたアクティブクロック比を採用しました。 0x9F 例えば、A1ピンマルチプレクサとSDブート/PBI構成を維持したまま。 これは ハードコードされたブートではない：完全なRCWとPBIはSDから取得する必要がある。メディア取得やPLLロックを回避するわけではありません。 設定値 一次資料 DIFF_SYSCLK/B、公称100MHz。 cfg_eng_use0=0 A1スイッチの位置 SW5 pole2 ON(差動クロック選択);SW8 poles1–8 0010 0000 (1=ON)(ブートソーススイッチストラップ) SYS_PLL_RAT 4→プラットフォーム 400 MHz CGA_PLL1_RAT 13 → CPU 1300 MHz CGA_PLL2_RAT 10 → PLL2 1000 MHz、FMan 500 MHz MEM_PLL_RAT 16 → DDR 1600 MT/s DDR_REFCLK_SEL / DDR_FDBK_MULT 1/2; 差動DDRリファレンス SRDS_PRTCL_S1 / SRDS_PRTCL_S2 0 / 0 SRDS_PLL_PD_S1 / SRDS_PLL_PD_S2 3/3; 各SerDesブロックで両方のPLLがダウン PBI_SRC / ブートホー 6 / 0 EVDD_VSEL 2. SD 3.3V構成 DIMM 4 GiB、単一ランク、64ビット非ECC DDR4;トレーニングシードはマージン適格ではありません このテスト済みイメージで使用されている完全なRCWは、デバッガーによる介入後にも確認されており、以下のとおりです。 RCW01–04: 0810000d 0a000000 00000000 00000000
RCW05–08: 00000000 00f00012 60040000 c1000000
RCW09–12: 00000000 00000000 00000000 0001c83e
RCW13–16: 00004504 24001102 00000096 00000001 結果： 地元の防寒ブーツ販売店はそのまま残っていた。デバッガ支援の後、U-BootはCPUが1300 MHz、プラットフォームが400 MHz、DDR 1600 MT/s、FManが500 MHzと報告し、意図された比率と一致しました。SDの初期化とFIPのロードに成功しました。 デバッガーの正確な介入と結果として生じる状態 初期化コールバックは、以下のRCW API操作のみを呼び出します。 from cw.dbg import ta
def run_init_file():
target = ta.create()
target.rcw.set_source(0x40)
target.rcw.set_data({13: 0x00004504})
target.rcw.apply() ワード13は、SDカードに既に保存されている値と同一です。このスクリプトには、明示的なDDR初期化、BRR/PC書き込み、またはContinueコマンドは含まれていません。 apply() デバッガ起動が内部的にリセット/デバッグ状態を変えることは認識しています。 デバッグ後、続行前に、以下を読みます。 PC = 00000000
PORSR1 @ 01ee0000 = 205b7fff
RSTRQPBLSR @ 01ee00b4 = 00000000
RSTRQMR1 @ 01ee00c0 = 00004000
RSTRQSR1 @ 01ee00c8 = 00000000
BRR @ 01ee00e4 = 00000000
SCFG_SCRATCHRW0/1 = 00000000 / 10000000
DDR SDRAM_CFG = 07000000 (MEM_EN clear) 16個のRCWSR単語すべてが、テスト対象のSD画像と一致した。OCRAMの最初の64バイト 0x10000000 BL2のエントリーコードと一致しました。したがって、PC=0 で UART 出力がないことは、ハードウェア PBL が進行していないことを意味するものではありません。BL2/BL31/U-Bootを実行するには、Continueのみで十分でした。この実行では、BRRへの手動書き込みは使用していません。 これらは 介入後の測定値であり、元の停滞状態は維持されていない。我々は、それらのゼロエラー値を用いて、最初のコールド試行にPBL/クロック/リセットエラーがなかったと結論付けるつもりはない。 画像配置と正確なPBI設定 当社のSDパッケージとeMMCパッケージの両方で512バイトセクタを使用しています: RCW/PBI/BL2 .pbl: LBA 0x8、バイトオフセット 0x1000。 fip_uboot.bin BL31とU-Bootを含む：LBA 0x800、バイトオフセット 0x100000。 eMMCの場合、これらはユーザーエリアのオフセットであり、boot0/boot1ではありません。SDカードの全ディスクイメージは、これらのオフセット位置でバイト単位でチェックされています。また、以前のeMMCへの書き込みも、読み出し時のSHA-256検証に合格しています。 テスト対象のSD PBLにおける正確なセットアップストリームは以下のとおりです。各行は シリアル化された PBI コマンド ワードとそのデータ ワードがストリーム順で続きます。これらはデバッガのメモリ書き込みコマンドではありません。 09570600 00000000
09570604 10000000
09570178 0000e010
09180000 00000008
09570418 0000009e
0957041c 0000009e
09570420 0000009e
09570158 00001000
09610000 00000000
096100c0 000fffff
09570604 10000000
09570158 00001000
096100c0 000fffff これには、スクラッチブートポインタ、継承された相互接続/USB設定、フラッシュおよび同期操作が含まれます。繰り返し行われる操作は保持されます。PCIeセットアップ書き込みはありません。その後、ストリームにはOCRAMへの844回のACS64転送が含まれます。これは、53,953バイトのBL2と63バイトのゼロパディングで構成されます。テストされたPBLは、 08610040 6d8bdebf （END/CRC）であり、合計サイズは57,576バイトです。 また、本日、QCVSを使用して独自にPBLを生成しました。解析とCRC検証の結果、そのPBI操作とBL2ペイロードはテスト対象のイメージと同一であることが判明した。私たちは意図的にRCW12を変更しました 0001c83e に 0001a8fe (睡眠=0、 RTC=1、 IRQ_BASE=63); そのワードとCRCだけが異なります。そのSHA-256ハッシュ値は以下のとおりです。 2d3389fce4ead088957caf6251022b5526be8565e812a8aab8fce21bd8923277 9月30日更新： 新たに生成されたQCVSのSD候補をテストしたところ、再びネイティブコールドブートの停止が発生しました。したがって、PBLを実際のQCVSエクスポートに置き換えても、症状は解消されませんでした。PBIおよびBL2のペイロードは前の画像と同一のままであるため、共有設定の問題を否定したり、原因がハードウェアにあることを否定するものではありません。 上記の詳細なHRESET/レジスタ読み取り値と確認済みのアシスト成功シーケンスは、以前のRCW12=0001c83eを参照しています。 走る。最新のRCW12=0001a8feのデバッガリカバリ結果と詳細な波形 このアップデートには、まだ実行機能が追加されていません。 指導を要請 PORリリース前にHRESET_Bアサートされ、その後はLOWのままの場合、RCWフェッチ/検証の失敗とPLLロック、またはステップ11〜14でのプラットフォームクロック切り替えを区別する最良の測定値は何でしょうか?ステップ1～4では、電源、時計、ストラップの初期状態についても引き続き確認していきます。 ステップ15はSoCのHREETドライブを解放し、ステップ17はPBIを実行するため、外部HREETドライバーや短いリリース・再アサーションを除外した場合、初期段階を優先するのは合理的でしょうか?上記のRCWおよびPBIも、未構成や誤った設定がないか確認してください。 CCS/SAPは、RHETが低のままの状態で、RCW適用や再度リセットせずにネイティブリセット/PBLステータスや文書化されたPLL-ロック状態にアクセスできるのでしょうか?アクセスの正確なコンテキスト、コマンド、レジスタ/ビットの定義を教えてください。Ordinary Inspectはこれまで、この状態のCortexA72#0を検出できませんでした。 具体的に何が set_source(0x40) さらに、対応する単語13のオーバーライドと 適用する（） リセット、TRST、デバッグコントロールを実行するにはどうすればいいですか？最終的なRCWの内容を変更せずに起動を可能にする動作を特定したいと考えています。 生成されたPBL、完全なUART/デバッガーログ、追加のスコープキャプチャも提供可能です。自動冷却起動ではブリングアップがブロックされているので、次の識別テストについてのアドバイスをいただけると大変ありがたいです。 また、自己テストとして、SD カードや空の eMMC がない状態で 0x9e または 0x9f をストラップすると、POREST_B が 0 から 1 に解放されたときに HRESET_B が低から高に変化することが確認できると教えられました。RDBボードでこれをキャプチャしようと試み、これを観察することができました。では、カスタムボード上で同じことをしても同じ挙動が観察されるということですか? よろしくお願いします。 Re: LS1046A custom board: cold boot fails from eMMC, SD and QSPI; CodeWarrior RCW apply enables U-Bo こんにちは、 @Hiran_E_H さん。
1.現在の情報からはRCWの負荷問題とPLLロックの問題を明確に区別するのは難しいです。しかし、CCSがデバイスに正常にアクセスでき、PLL関連の波形が正常に見える場合、PLLの問題の可能性は低くなる可能性があります。 スタンドアロンのコールドブートとCCS支援ブートのSDコマンド波形を比較することをお勧めします。特に、波形の長さと順序を比較して、RCWロード中に異常がないか判断してください。 また、SDカードのクロックが起動プロセス中の予想される周波数遷移を反映しているかを確認するために、リファレンス・マニュアル表4-8の「RCW状態タイミング」を参照することもできます。これらの遷移は、RCWの読み込みが成功し、適切なPLLロックが行われていることに依存します。
2.はい、あなたのやり方に賛成です。入手可能な情報に基づくと、まずはステップ1から15、特に初期の電源、クロック、リセット、ブートソース関連の段階に焦点を当てるのが妥当でしょう。
3. 以下のCCSコマンドを試して、デバイスがこの状態のままではLS1046Aにアクセスできるか確認できます。例えば、RCWSRレジスタの読み取りを試みることができます:
(bin) 1%すべて削除
(bin) 2 % config cc cwtap
（バイナリ）3％表示cc
(bin) 4 % ccs::config_chain {ls1043a dap sap2}
(bin) 5% 表示 ::ccs::get_config_chain
(bin) 6 % ccs::display_mem 32 0x01ee0000 4 0 100
もっと行を表示
4. リファレンス・マニュアルの表4-8「RCW状態タイミング」を参照し、SDカードのクロックがRCWプロセッシング中の予想される周波数変化を反映しているかどうかを確認できます。
起動シーケンス中に、関連する波形を確認することをお勧めします。 実際には、初期デバッグ段階では通常、ハードコードモードを使用します。さらに、ボードをハードコーディングされたRCWで設定し、観測波形が図4-1「電源オンリセットシーケンス」に記載されている順序に従っているかを検証することもできます。波形が期待される挙動に合致していれば、リセット関連のハードウェア設計は一般的に正しく動作している可能性が高いです。
私は1週間以上OoOのままでいるので、この期間中は私の方からの更新はありません。
もしこの問題が緊急の場合は、別のチームメンバーがサポートできるように新しいスレッドを作成してください。
よろしくお願いします。 Re: LS1046A custom board: cold boot fails from eMMC, SD and QSPI; CodeWarrior RCW apply enables U-Bo こんにちは、 ccsコンソールから読み取ろうとしましたが、コールドブート中に以下の応答が返ってきました。 (bin) 7 % ccs::display_mem 2 0x01ee0000 4 0 1 スキャンタイムアウト ASLEEP信号に関してキャプチャを試みたところ、以下の観測結果が得られました。 SD CLKが約200kHzから約20kHzに低下する（フォールバックの可能性あり） SD DATA0は200kHzの間は常にハイレベルであり、クロックが20kHzに低下する直前にいくつかのトランザクションが発生します。
記事全体を表示
