こんにちは、
ハードウェア:
- i.MX8MQ(REV A0)、EVKデザインに基づくカスタムボード
- QSPI NOR:マイクロンMT25QL256A(32MB、3.3V、クアッドコネクテッド)
- BSP: Yocto Scarthgap、NXP BSP、U-BOOT 2024.04(u-BOOT-IMX)
目標：FlexSPI NORフラッシュからブートローダー（SPL + ATF + U-Boot）を起動する。
カーネルとルートファイルシステムはeMMC上に残ります。
効果的な点:
- U-Boot(uuu SDP/SDPV経由でRAMにロード)は問題なく動作します
- 「SFプローブ」がフラッシュを正しく検出します:MT25QL256A、32 MiB
- U-Bootはフラッシュの読み書きが安定してできる(検証
「SF Protect Unlock」後の読み返しテスト)
- 画像はIMXBOOT_TARGETS = 「flash_evk_flexspi」で構築されます
フラッシュメモリのレイアウト（チップからの読み出しで検証済み）：
0x000000: FCFB ヘッダー - 「qspihdr check」レポート
「Q(F)SPIにブート構成ヘッダーが見つかりました」
タグ = 42464346、バージョン = 56010000
0x001000: IVT - d1 00 20 41、エントリ = 0x007E1000、
boot_data = 0x007E0FE0、self = 0x007E0FC0
0x060000: U-Boot の適切な FIT (d00dfeed) が一致します
CONFIG_SYS_SPI_U_BOOT_OFFS=0x60000
問題点:
ブートスイッチをQSPI/FlexSPIに設定し、USBケーブルで起動した場合
物理的に切断されたため、ボードは起動しません。何もない
シリアルコンソールに印刷され（SPLバナーは表示されません）、
ROMはシリアルダウンロードモードに切り替わります。
uuu -lsusb
2:1 MX8MQ SDP: 0x1FC9 0x012B NXP FLASH
BT_FUSE_SELは焼損していません。ブート設定はGPIO経由で行われます。
ブートピン。
私が既に試したこと：
- 両方のヘッダー形式: scripts/qspi_header (c0ffee01 タグ) および
scripts/fspi_header (FCFBタグ)。soc.mak をSO修正した
flash_evk_flexspiオフセット0のfspi_headerを使用します。
- 変動するFCFBパラメータ:sflashA1Size、serialClkFreq(50MHz -> 20MHz)、
dataSetupTime/dataHoldTime, sflashPadType
- 「Uuu -B QSPI」(公式組み込みスクリプト)
- 「Qspihdr Update Safe」および「Qspihdr init
- フラッシュを完全に消去するのと、完全な画像を書き込むこと:
起動動作は基本的に同一です(SDPはその後に現れます)
~1.6秒対~1.8秒)を比較し、ROMが読み取っていない可能性を示唆しています
フラッシュ自体が。
質問:
1.i.MX8MQブートROMはシリアルNORからの起動をサポートしていますか?
FlexSPIでフラッシュを使うべきでしょうか?リファレンス・マニュアルのセクションは持っています
NANDフラッシュとSD/MMCをブートデバイスとしてリストアップしていますが、できませんでした
FlexSPI/QSPI NORのリストは見つかりません。i.MX8MM/8MNのドキュメントのようです
説明は難しいですが、8MQについてはよくわかりません。
2. もし対応しているなら、フラッシュの正確な予想レイアウトはどうなりますか?
FCFB の場合、IVT はオフセット 0x400 または 0x1000 にあるべきでしょうか
0x0に存在しますか？
3. 選択すべき正しいBOOT_MODE / BOOT_CFGの組み合わせは何ですか？
i.MX8MQでFlexSPI NORブートは可能ですか？
4. REV A0シリコンに関して既知の正誤表はありますか？
FlexSPIブート？
よろしくお願いします。
こんにちは、私も似たような作業に取り組んでいます。
同じ文書のいくつかのセクションでは、SPIを使用したブートオプションについて言及されています。
もう少し詳しく説明していただけますか？
こんにちは、
主にRMの情報をご参照ください。i.MX8MQはQSPIブートをサポートしていません。
よろしくお願いします、
志明
LinuxカーネルとrootファイルシステムをeMMCに残したまま、QSPI NOR Flashからi.MX8MQを起動する方法は絶対にないのでしょうか?私たちのハードウェアデザインはすでにこのアーキテクチャを中心に構築されているため、非常に重要です。
こんにちは@ayse-yilmaz @onur-goksu
第 6 章のドキュメントに関する問題
サポートされているブートデバイスについては、 6.1 システムブートを参照してください。
1.6 プライマリブートオプションについてですが、ドキュメントの残骸のように見えます。
よろしくお願いします、
志明
こんにちは、@Zhiming_Liu、@ayseイルマズさん
この問題に関連する以下のトピックを見つけました:https://community.nxp.com/t5/i-MX-Processors/Does-i-MX8M-support-boot-from-QSPI/m-p/904429#M136467
しかし、テクニカルサポートは「開発上の目的で、起動デバイスを判定するeFUSEはGPIOピン入力で上書きされる可能性がある」と述べましたが、ブートROMはそもそもサポートしていません。ちょっと混乱しています。ハードウェアはサポートしているのに、起動ROMはなぜ対応していないのでしょうか?
ハードウェアやドキュメントがあっても、ROMのせいでQuadSPIから起動するのは不可能だと思います。私の理解は合っていますか？詳しくご説明いただけますでしょうか。
よろしくお願いします
オヌール
よろしくお願いします。
NXP技術サポートチームへ、
i.MX8MQのQSPIブートサポートのドキュメントについて、深刻な懸念を提起したいと思います。
エンジニアはハードウェア設計の意思決定において、リファレンスマニュアルを主要かつ権威ある情報源として頼ります。リファレンスマニュアルにブートソースが記載またはサポートされていると示唆されている場合、開発チームがその情報をもとにボードを設計するのは全く合理的です。
これは些細な誤植ではない。ブートソースの選択は、回路設計、PCBレイアウト、部品選択、製造、ファームウェアアーキテクチャ、復旧戦略、製品検証に直接影響します。QSPIブートの性能に関する誤った記述は、重大な技術的損失、追加の試作改良、遅延スケジュール、そして多額の財政的コストをもたらす可能性があります。
特に懸念すべきは、2017年から2018年頃からNXPコミュニティでも同様の質問やフィードバックが提起されている一方で、ドキュメントは長年にわたり不明瞭または誤りのままだったことです。もしNXPがi.MX8MQブートROMがQSPIからの直接ブートをサポートしていないことを知っていたなら、この制限はリファレンスマニュアル、デバイスエラッタ、アプリケーションノート、製品ドキュメントに明確に記載されているはずです。
このような重要な曖昧さを何年も放置するのは、プロフェッショナルおよび商業用ハードウェアデザインで使用される部品として容認できません。お客様は公式リファレンス・マニュアルに記載された情報を信頼できる必要があります。
つきましては、以下の点について明確かつ正式な回答をお願いいたします。
- i.MX8MQブートROMは、電源オンリセット後にQSPI NORからの直接起動をサポートしていますか?
- もしそうでないなら、なぜQSPIがリファレンスマニュアルでサポートされているブートオプションとして提示されたり、暗示されたのでしょうか?
- NXPはこれを正式にドキュメントの誤りと分類していますか?
- この情報はどの文書改訂版で修正されますか？
- NXPは既存のドキュメントに基づいてハードウェアを設計した可能性のある顧客に警告する訂正表や製品通知を公表するのでしょうか?
- SDカードやeMMCを必要とせずに、ブートROMがQSPIから直接初期ブートイメージをロードできるようにする、公式にサポートされている回避策はありますか？
私たちは、この問題は非公式なフォーラムでの対応以上のものが必要だと強く信じています。他のエンジニアリングチームが同じ時間やファイナンシャル損失を被るのを防ぐためには、正式なドキュメント訂正と明示的な技術通知が必要です。
このマターはi.MX8MQ製品エンジニアリングおよびドキュメントチームにエスカレーションし、権威ある書面による説明をお願いいたします。