.mexファイル内の警告ファイル （自動生成された）.mexファイル内プロジェクト用のファイルでは、各ペリフェラルは次のような内容です: 1.0.0 「説明」属性の文言に注目してください。他のペリフェラルについては状況が異なりますが、ほとんどの場合、警告やエラーメッセージのようなものです。プロジェクトは正常にコンパイルされ、実行されます。 関連して、『ペリフェラルビュー』から新しいソフトウェアコンポーネントを追加しようとすると、現在選択されていないペリフェラルが黄色い感嘆符でマークされています。添付のスクリーンショットをご覧ください。マウスカーソルをそれらの上に重ねると、「description」属性に表示されているのと同じメッセージが表示されます。しかし、私は問題なくそれらを追加できます。 これらの警告は何に関するものですか？ Re: Warning in the .mex file こんにちは、 @durga_choudhuryさん この警告はプロジェクトには影響しません。対応するドライバーがプロジェクトに追加または設定されていないことを示すだけです。したがって、お客様の現在の実装に機能的な影響は想定されません。 BR、VaneB

Makefile execution generated by MCUxpresso IDE Hi team, We have used MCUxpresso IDE and imported a sample SDK example for imxrt1170 eval board and built the project file. The MCUxpresso IDE itself has auto generated a makefile. So my query is how to execute this make file in my windows system without using MCUxpresso,like by using make all, make clean and make commands to generate the binary (.axf file here for MCUxpresso). I have even attached the Makefile also just for reference below. Re: Makefile execution generated by MCUxpresso IDE Hello, Windows user here. Using MCUXpresso's makefiles is all a matter of %PATH% variable. I found that the easiest way to run "make"  commands from the command line is to Ctrl-click on the project name in the bottom right-hand corner of the MCUXpresso IDE: This will open a terminal window in your project directory with  %PATH% properly set, so you can enter "make clean" and "make -j8 all" and similar commands. Of course, you can close the IDE and the terminal window stays open. You can also inspect the %PATH% variable. Set this path in any other terminal window and you can run make commands there as well.  Hope you can put this to good use. Best regards, Daniel Re: Makefile execution generated by MCUxpresso IDE The auto-generated make file (managed make) in Eclipse is not portable. You could use the make file in the SDK (non-IDE), or better, use CMake to have a portable build system. I'm using the approach described in https://mcuoneclipse.com/2023/04/19/building-a-triumvirate-from-eclipse-cdt-to-cmake-cmd-and-visual-studio-code/ to have both IDE, make and CMake for the builds. Re: Makefile execution generated by MCUxpresso IDE Hi @Jeevan ,   I think you can refer to the gcc project to build it in the SDK, as that also use the makefile without the IDE.  About the gcc build method, you can refer to the sdk document: SDK_2_14_0_MIMXRT1170-EVK\docs\Getting Started with MCUXpresso SDK for MIMXRT1170-EVK.pdf chapter 6 Run a demo using Arm® GCC You also can refer to my ubuntu build method document: https://community.nxp.com/t5/i-MX-RT-Knowledge-Base/RT-Linux-SDK-build-based-on-Ubuntu/ta-p/1690185 Wish it helps you! If you still have question about it, please kindly let me know. Best Regards, Kerry

MCUxpresso IDEによって生成されるMakefile実行 チームの皆さん、こんにちは。 MCUxpresso IDEを使い、imxrt1170評価ボードのサンプルSDKをインポートしてプロジェクトファイルを作成しました。 MCUxpresso IDE自体は自動でメイクファイルを生成しています。そこで質問ですが、MCUxpressoを使わずにWindowsシステムでこのmakeファイルをどう実行するか、例えばmake all、makeクリーン、そしてコマンドを作成してバイナリ(MCUxpresso用の.axfファイル)を生成する方法です。 参考までに、Makefileも以下に添付しました。 Re: Makefile execution generated by MCUxpresso IDE こんにちは、 Windowsユーザーです。MCUXpressoのmakeファイルの使い方は%PATH%マターです。 コマンドラインから「make」コマンドを実行する最も簡単な方法は、MCUXpresso IDEの右下にあるプロジェクト名をCtrlでクリックすることです。 これでプロジェクトディレクトリにターミナルウィンドウが開き、%PATH% が正しく設定されているので、「make clean」や「make -j8 all」などのコマンドを入力できます。 もちろん、IDEを閉じてもターミナルウィンドウは開いたままです。また、 %PATH% 変数も検査できます。このパスを他のターミナルウィンドウに設定すれば、そこでも「メイクコマンド」を実行できます。 この情報を有効に活用できることを願っています。 よろしくお願いします、 ダニエル Re: Makefile execution generated by MCUxpresso IDE Eclipseの自動生成メイクファイル(マネージドメイク)はポータブルではありません。SDKのmakeファイル(非IDE)を使うか、もっと良いのはCMakeを使ってポータブルビルドシステムを作る方法です。https://mcuoneclipse.com/2023/04/19/building-a-triumvirate-from-eclipse-cdt-to-cmake-cmd-and-visual-studio-code/ で説明したIDE、make、CMakeの両方をビルドに使う方法を使っています。 Re: Makefile execution generated by MCUxpresso IDE こんにちは、 @Jeevan さん。 SDKで構築するにはgccプロジェクトを参照できると思います。そちらもIDEなしでmakefileを使うからです。 gccビルド方法については、SDKのドキュメントを参照してください。 SDK_2_14_0_MIMXRT1170-EVK\docs\MCUXpresso SDK for MIMXRT1170-EVK.pdf 第6章 Arm® GCCを使ってデモを実行 また、私のUbuntuビルド方法のドキュメントも参照してください: https://community.nxp.com/t5/i-MX-RT-Knowledge-Base/RT-Linux-SDK-build-based-on-Ubuntu/ta-p/1690185 お役に立てれば幸いです！ ご不明な点がございましたら、お気軽にお問い合わせください。 よろしくお願いいたします。 kerry

PN5190B1最初のRFフィールドONで反応しなくなります 皆さんこんにちは、もうアイデアが尽きてしまったので助けていただけると嬉しいです... PN5190B1HN/C121E(ホスト:CC1352 MCU over SPI)を搭載したカスタムボードを持っています。新生産ロット(約100台)では、約75%の故障率が示されています。RFフィールドが初めてオンになった瞬間にSPIで応答しなくなり、VENリセット後にのみ回復します。前のロットのユニット(プロトタイプ5個)は同じデザインとBOMで正常に動作します。測定結果から、アンテナ/マッチング、送信機のショート、静的電源、SYS3Vの電圧低下、チップのファームウェア、シリコンロットの問題は除外しました。我々は、確認済みの根本原因、考えられるシリコンの不具合、または見落としている可能性のあるEEPROM/電源構成を探しています。 ハードウェア NFCフロントエンド：PN5190B1HN/C121E — GetVersionレポートによると、HW=0x52、ROM=0x02、FW=0x0201です。 TX電源＝内部TX_LDO。VUP_TX（ピン6）= 3.3V（LDO入力）。VDDPA（ピン9）＝TX_LDO出力（GNDのみにデカップリング）。VBAT / VBATPWR = 3.3 V。内部DC-DCコンバータは使用されていません（BOOST_LXインダクタは取り付けられていません）。 メインレールSYS3V = TPS62840降圧コンバータ（最大0.7A）からの3.3V。 27.12 MHz水晶発振子（村田製作所製 XRCGB27M120F3M00R0）。 DPCは無効になっています。ULPCD（超低消費電力カード検出）を使用。VDDPAを最小値に設定（TX_LDO_VDDPA_HIGH/LOW、EE 0x06/0x07 = 0x00）。 差動アンテナTX1/TX2、EMCフィルタ（L = 160 nH）+整合回路。測定された共振周波数は約12.56MHz（最終的な金属環境なし）（良品と不良品で同一）。 症状（詳細な特徴） フィールドONの前にフルSPIが動作します：SWITCH_MODE_NORMAL、GetVersion、GetDieId、EEPROMの読み書きはすべてSUCCESS（ステータス0x0000）を返します。 最初のFieldOn(RF_ON)では、ホストがフィールドオンイベントを待つためにタイムアウトします。その直後、すべてのSPIレジスタの読み取りがタイムアウトします（CLIF_STATUS、SYSTEM_CONFIG、GetDieIdの読み取りはすべてHAL IOタイムアウトを返します）。VENリセットを行うまで、このチップはSPIに対して全く反応しません。 VENリセット後、チップは再び正常になります（GetVersion OK）。その後、FieldOnが再びチップを破損させ、無限リトライループが発生します。 RFフィールドは放射されません(NFCテストLEDは点灯しません)。基板は約20mAの電流を消費し、低電力状態に戻ることはありません。 良品と不良品は、ファームウェア（0x0201）、DIEIDロット、EEPROM構成、アンテナ（VNA）、およびDC抵抗において同一である。唯一の違いは、FieldOnでは不良ユニットが破損してしまう点です。 ホストMCUはハング中も生き続けます(I²Cキーパッドエキスパンダーが応答し続けます)。つまり、故障するのは基板全体ではなくPN5190側です。 正常ユニットと不良ユニットの電流消費量は約2.7秒までは同一ですが、約2.7秒で正常ユニットは処理を完了して低電力に低下し、不良ユニットは約20mAのままになります。 除外された項目（それぞれ直感ではなく、測定に基づいて） 仮説 除外された経緯 アンテナ／マッチング／チューニング miniVNAを4つの良品ユニットと4つの不良品ユニットで測定したところ、両者は区別がつかなかった。共振周波数は良品12.565MHz、不良品12.593MHz、RL ≈ −9dB、|Z| ≈ 24.7Ω、SWR ≈ 2.08（いずれも同じ値）。 TX短絡/過電流 直流抵抗 TX1–TX2 ≈ 1.2 kΩ、TX1–GND ≈ TX2–GND ≈ 1.15 kΩ、良品と不良品で同一 静電気による電源漏れ／デカップリング 電流消費量は、約2.7秒までは正常と異常で同じである。 SYS3V電圧低下 3.3Vで安定して測定。3.3Vレールすべてに47μFのバルクコンデンサを追加→変化なし、依然として故障。 チップFW ユニットを最新のPN5190ファームウェアにアップデートしましたが、依然として失敗し、同じ動作を示します。（未処理の良品と不良品の両方で、ファームウェアコード0x0201が報告される。） シリコンロット DIEID 正常 00000000 0DD0945E 5B38BDDC 892C0810 対 不良 00000000 0DD095A6 6938BDDC 892C0E64 — 同じプレフィックス/ロット構造 TXドライバ振幅 FieldOn前のCLIF_SS_TX1/2_RMCFG CW振幅の減少 → 変更なし TX_LDO過電流保護 TX_LDO_CONFIGビット11（0xAE → 0xA6）で無効化しましたが、変化はありませんでした。 TX_LDO出力コンデンサ VDDPA出力コンデンサ（4.7 µF + 100 pF）を取り外した → 変化なし EEPROM構成（良品と不良品で同一） DCDC_PWR_CONFIG (0x00) = 0x21 (DC-DCオフ、VUP = VBATPWR、ULPCD有効) TX_LDO_CONFIG (0x02 / 0x03) = 0xA7 / 0xAE (デフォルト) TX_LDO_VDDPA_HIGH / LOW (0x06 / 0x07) = 0x00 (最小値、約 1.5 V) DPCが無効になっています 質問 これは報告された「最初の起動時/最初のRFフィールドオン時にPN5190チップ破損」と一致します。根本原因と最終的な解決策を確認できますか?(注:最新のPN5190ファームウェアをフラッシュしても解決しませんでした — 同じ失敗です。) このロット／日付コードに対応するシリコンに関する訂正情報はありますか？完全なDIEIDとチップの刻印の写真も提供できます。 当社のトポロジー（内部TX_LDO、VUP_TX = 3.3 V、VDDPA = LDO出力、DC-DCオフ、DPCオフ、ULPCD、VDDPA最小1.5 V）において、この構成は有効でしょうか？VDDPAを最低限の電圧で動作させることは問題でしょうか？また、比較対象となる正しいEEPROM電源構成（PNEV5190Bとの比較）は何でしょうか？ 電源投入順序に関する要件（VENとサプライランプのどちらを優先するかなど）があり、それが満たされない場合にこのような問題が発生するのでしょうか？注:前の(動作中の)ロットと比べて、VENはI²Cエクスパンダ出力から直接MCU GPIOに移し、VENプルアップはDNPなので、ホスト起動時にVENは浮動します。 ブラウンアウト、過電流、FW、シリコン、アンテナがすべて測定で除外されている中で、VENリセットまでチップがSPIに応答しなくなるRF_ON経路の他に何があるのでしょうか? よろしくお願いいたします。   イグナシオ Re: PN5190B1 becomes unresponsive on first RF field ON お世話になります。 RF Fiel ONコマンドがICをハングさせる既知の問題は公表されていません。 ファームウェアの更新とEEPROMの内容をクローンした後、すべての影響を受けたPN5190デバイスで問題が解決したのか、教えていただけますか?この情報は、問題の範囲をよりよく理解するのに役立つだろう。 一部の端末で問題が継続する場合、正常に動作する端末と不具合のある端末との間でA/B比較テストを実施する機会はありましたか？このような検査は、根本原因がIC自体に関連しているのか、それともシステムの他の要素に関連しているのかを判断するのに役立ちます。 ロット追跡についてですが、代理店に製造ロットや影響を受けた部品の製造履歴について追加情報を提供できるか確認していただけますか? Re: PN5190B1 becomes unresponsive on first RF field ON 不可解な点は、正常に動作するユニットと故障するユニットが、同じファームウェアバージョン（v2.01）、同じシリコンリビジョン（B1）、同じハードウェア、同じアンテナチューニング、そしてクローン作成後には同じEEPROMの内容を持っていることだ。しかし、うまくいくものもあれば、ほとんどはうまくいかない。 PN5190のファームウェアをv2.0Dにアップグレードすることで、不具合のあるユニットの問題が解決します。その理由と、v2.01に既知の問題があるかどうかを知りたいです。   1. 症状: 故障したユニットについて： 起動と初期化は正常に完了します。 最初のRFフィールドオン時には、チップは意味のある電流を引きず、RFフィールドを発生させません(NFC電源のLEDテストカードで確認済みで点灯しません)、SPIでは完全に反応しなくなります。 ホストがIO_TIMEOUTを報告しました。ソフトリセットも失敗します（SPI応答が必要です）。 チップを復旧させるには、ハードウェアリセットまたは電源の再投入のみが必要です。その後は次のRFフィールドオンまで正常に動作しますが、そこでまたフリーズします。完全に再現可能。 電源電圧（3.3V）は終始安定しており、電圧低下は発生しません。 ボードの寿命で初めての電源アップ時に、一度きりの~600 mA(北欧PPK2で測定した0.62A)のイベントが観測されますが、その後のパワーアップでは二度と発生しません。 故障したユニットのNFCコックピットからのログ： INFO:RFProtocolTuningService_PN5190:プロトコルをロード: RM_A_106 INFO:TypeACardViewModel:RM_A_106 プロトコルが正常にロードされました。 情報:RfFieldControlService:RFオン 警告:代表:PIN_IRQが高くなるのを待っていた。タイムアウトしました。 エラー:RfFieldControlService:フィールドオン中にエラー240、IO_TIMEOUTが発生しました。 正常に動作しているユニット（ファームウェア、設定は同じ）からのログ： INFO:RFProtocolTuningService_PN5190:プロトコルをロード: RM_A_106 INFO:TypeACardViewModel:RM_A_106 プロトコルが正常にロードされました。 情報:RfFieldControlService:RFオン 情報:RfFieldControlService:RF Off(RF オフ) ATQA 04 00 / SAK 0x08 / UID 04 8D12 33 2. テストセットアップ 自社のホストファームウェアを除外するため、NXPのナレッジベース記事「 外部PN5190を評価ボードPNEV5190BPに接続 する方法」(R5/R7設置、R6開)に従い、本番ボードをUSB↔SPIブリッジとして使うPNEV5190BPに直接接続しました。R20入賞;VBAT/VBAT_PWR/VUPジャンパーは撤去されました。SPI_CLK、SPI_MOSI、SPI_MISO、SPI_CS、NFC_IRQ、NFC_VEN、GND、外部ボードに配線)。 NFC Cockpit v9.0.0 PNEV5190BP with MCU FW NNC_uC_VCOM_04.00.00 外部基板はNordic PPK2から3.3Vで給電される（電流測定が可能）。 この故障はNXPホストとNXPソフトウェアの両方で再現されているため、ホストファームウェアが原因ではありません。 3．除外した項目（測定値付き）： 仮説 どのようにして除外されたのか 供給崩壊／停電 3.3Vレールは全体を通して安定して測定されました 送信機の短絡 良品と不良品の直流抵抗値（TX1-TX2間、TX1-GND間、TX2-GND間）は同一（数kΩ） PAデカップリングにおけるリーク 現場投入の瞬間までは、電流消費量は同じで、良い場合も悪い場合もある。 アンテナの同調ずれ／マッチング VNA測定、良品4台＋不良品4台 — 下記参照 ICへの物理的損傷 チップはハードウェアリセットで復旧するが、その後再び再現可能な形で故障する。 ホストファームウェア NFC Cockpit + PNEV5190BPを使用して再現 PN5190ファームウェアバージョン 良品と不良品の両方がv2.01、Hw B1にあります ユーザーEEPROMコンテンツ 正常なユニットのEEPROM全体を不良ユニットにクローンしたが、それでも失敗する。 差：約29kHz（0.2％）、測定ノイズの範囲内。8つの掲示板で確認済み。アンテナは区別がつかない。 4. EEPROMの比較 - 1バイト 良いユニットと悪いユニットの両方のユーザーEEPROMを完全にFW v2.01でダンプし、それらをファレンジしました。 648個のパラメータのうち、正確に1つだけ異なる。 地域: DPC_SETTINGS パラメータ: DPC_CONFIG オフセット: 0x76 良品ユニット: 0x77 不良ユニット: 0x76 それ以外の部分はすべてバイト単位で同一です。 これは答えのように思えた。特にRN00003の注意書きを考慮すると尚更だ。 「対称」アンテナに接続されたIC(例:カスタマー開発ボードアンテナ)では、DPCを無効化せずRFフィールドを有効化しないでください。長期間にわたる過電流による送信機ドライバーの損傷が起こる可能性があります。 当社のアンテナは対称型(差動TX1/TX2)で、最初の電源を入れた時の一度きりの~600 mAの現象は過電流状態と一致しています。 しかし、バイトをコピーしてもユニットは修復されません テスト 結果 不良ユニットにDPC_CONFIG = 0x77を書き込み（v2.01）、読み出し結果を確認し、電源を再投入する。 それでも失敗する 正常ユニットの完全なEEPROMダンプを不良ユニットにロードし（v2.01）、電源を再投入する それでも失敗する 良好なユニット、未改造、v2.01 完璧に動作します つまり、DPC_CONFIG合格・不合格と関連していますが、原因ではありません。本当の違いが何であれ、それはユーザーのEEPROM領域には含まれていません。 5. 解決策：ファームウェアをV2.0Dに安全にアップグレードする   PN5190Firmware_2.0D.esfwu （LEDLフォルダ、B0/B1用レガシーダウンロード）を使用してセキュアファームウェアアップグレードを実行すると、不具合のあるユニットが正常に動作するようになります。 アイドル時：約33mA RFフィールドオン:~240 mA持続、安定、LED点灯 Layer3 をアクティブにすると、ATQA 04 00、SAK 0x08、UID 04 8D 12 33 が返されます。 自社製品ファームウェアで動作を確認しました これまでに2ユニットがこの方法で回収されており、どちらも完全に機能しています。 副作用：PwrConfigが上書きされ、過熱を引き起こす。 アップグレード後、EEPROMオフセット0x0000 （ PwrConfig ）は0x21から0xE4に変更されます。0xE4の場合： PwrConfig 0xE4 PwrConfig 0x21 (復元済み) アイドル電流 約290mA 約33mA ダイ温度（ PMU_TEMP_REG@0x5B ） 100℃ 40 °C アイドル時は290 mAでRFフィールドなし、内部温度センサーは100°C(最大Tjは125°C)を読み取ります。アップグレード後には毎回PwrConfigを0x21に復元します。 0xE4は、v2.0DにおけるPwrConfigのデフォルト値として意図されているのでしょうか？これは他のユーザーにとっても問題になりそうです。 アップグレードによって変更された16個のEEPROMパラメータ パラメータ オフセット 以前のバージョン（v2.01） (v2.0D) 後 PwrConfig 0x00 0x21 0xE4 DPC_CONFIG 0x76 0x76 0x77 DPC_GUARD_TIME 0x87 0x64 0xFF DPLL_CONTROL 0x2AE 0x00000C03 0x00000C63 DpllPhaseRfON 0x2D2 0x012C 0x00A0 DpllPhaseCeA 0x2D4 0x012C 0x00A0 RssiCtrl_00_AB 0x2DE 0x09 0x0C rssi_no_samples 0x4CA 0x02 0x00 極性 0x4CC 0x00 0x01 LpcdExtDcdcDelayToOn 0xCE1 0x00 0x64 LpcdExtDcdcDelayToOff 0xCE2 0x00 0x64 ClifRXFrameLen 0xCE4 0x00000000 0x00EF0003 RxGuardTO_Multiple 0xCE8 0x00 0x01 デジタルTBシグナルインデックス 0xCE9 0x00 0x9B デジタルTB信号ビット 0xCEA 0x00 0x04 AnalogTBSignal 0xCEB 0x00 0x78 良いユニットの完全なEEPROMを不良ユニットにクローンしても直らないため、この16バイトだけでは解決できず、ファームウェアコード自体に何かが関与しているはずです。 6. ダイID 全てのユニットは、受領時の状態のままハードウェアB1、ファームウェアv2.01です。 不良品 #1: 00 00 00 00 0D D0 94 5A 5F 38 BD DC 89 2C 04 22 不良品 #2: 00 00 00 00 0D D0 95 A6 69 38 BD DC 89 2C 0E 64 不良品 #3: 00 00 00 00 0D D0 95 62 5F 38 BD DC 89 2C 08 10 良品 #1: 00 00 00 00 0D D0 95 0E 5D 38 BD DC 89 2C 08 10 7. 質問 FW v2.01で、RF Field ONがフィールドもSPI応答もないままICがハングしてしまう既知の問題はありますか?DPC_CONFIGレジスタはv02.03で初めて導入された（RN00003による）こと、そしてv02.07→v02.08とv02.08→v02.09の両方にDPC制御の修正が含まれていることに注意してください。 ファームウェア、シリコンリビジョン、ハードウェア、EEPROMがすべて同じであるにもかかわらず、なぜ約25%のユニットは正常に動作し、約75%は動作しないのでしょうか？ユーザーEEPROMの範囲外(工場出荷時のトリムや内部状態)で、同じロットのユニット間で異なるものはありますか? 上記のダイIDは異なる生産ロットやウェハーバッチに特定できますか? v2.0Dにアップグレードした後、PwrConfig = 0xE4という値は意図された値ですか？その結果、当社の設計ではアイドル消費量~290 mA、ダイ温度100°Cとなります。 PN5190デバイスは特定のファームウェアバージョンを事前にプログラムした状態で注文できますか?ツール自体がバージョン2.01が旧バージョンであることを警告しているにもかかわらず、バージョン2.01で出荷したため、生産バッチ全体が無駄になってしまいました。 残りの80~0ユニットの未使用ユニットに対して、一度きりの600 mAイベントを完全に回避するために、最初の電源アップ前にv2.0Dにアップグレードすることが推奨される緩和策でしょうか? アドバイスをいただければ幸いです。

.mex 文件中的警告文件 在（自动生成的）.mex 文件中项目文件中，每个外设的内容大致如下： 1.0.0 请注意“描述”属性中的措辞。对于其他外围设备，情况各不相同，但几乎总是会显示警告或错误消息之类的信息。项目编译和运行都没问题。 另外，如果我尝试从“外围设备视图”添加新的软件组件，所有当前未选择的外围设备都会被标记为黄色感叹号，请参见附件屏幕截图。如果我将鼠标悬停在它们上面，就会得到与“描述”属性中显示的相同的消息。但我添加它们没有任何问题。 这些警告是关于什么的？ Re: Warning in the .mex file 你好@durga_choudhury 此警告不会影响您的项目。这仅表明项目中尚未添加或配置相应的驱动程序。因此，预计不会对您当前的实现造成任何功能影响。 BR，VaneB

Warning in the .mex file In the (autogenerated) .mex file for a project, each peripheral reads something like this: 1.0.0 Notice the verbiage in the "description" attribute. For other peripheral this varies, but it is almost always something like a warning or an error message. The project compiles and runs fine. Also related, if I try to add a new software component from the 'Peripherals view', all the currently unselected peripherals are marked with yellow exclamations, please see the attached screen shot. If I hover the mouse over them, I get the same message shown in the "description" attribute. Yet I am able to add them without any issues. What are those warnings about? Re: Warning in the .mex file Hi @durga_choudhury  This warning does not affect your project. It is only an indication that the corresponding driver has not been added or configured in the project. Therefore, no functional impact on your current implementation is expected. BR, VaneB

由 MCUxpresso IDE 生成的 Makefile 执行 大家好， 我们使用了 MCUxpresso IDE，导入了 imxrt1170 评估板的示例 SDK，并构建了项目文件。 MCUxpresso IDE 本身已自动生成了 Makefile 文件。所以我的问题是，如何在不使用 MCUxpresso 的情况下，在我的 Windows 系统中执行此 make 文件，例如使用 make all、make clean 和 make 命令来生成二进制文件（MCUxpresso 使用的是 .axf 文件）。 我还附上了 Makefile 文件，供您参考。 Re: Makefile execution generated by MCUxpresso IDE 你好， 我是Windows用户。使用MCUXpresso 的 makefiles 完全取决于%PATH%变量。 我发现从命令行运行“ make ”命令的最简单方法是按住Ctrl键并单击MCUXpresso IDE右下角的项目名称： 这将在您的项目目录中打开一个终端窗口，并将%PATH%正确设置，以便您可以输入“ make clean ”和“ make -j8 all ”以及类似的命令。 当然，您可以关闭 IDE，终端窗口仍会保持打开状态。您还可以检查%PATH%变量。在任何其他终端窗口中设置此路径，您也可以在那里运行 make 命令。 希望你能好好利用它。 此致， 丹尼尔 Re: Makefile execution generated by MCUxpresso IDE Eclipse 中自动生成的 make 文件（托管 make）不具备可移植性。您可以使用 SDK（非 IDE）中的 make 文件，或者更好的选择是使用 CMake 来获得一个可移植的构建系统。我正在使用https://mcuoneclipse.com/2023/04/19/building-a-triumvirate-from-eclipse-cdt-to-cmake-cmd-and-visual-studio-code/中描述的方法，以便同时使用 IDE、make 和 CMake 进行构建。 Re: Makefile execution generated by MCUxpresso IDE 嗨@Jeevan ， 我认为你可以参考 gcc 项目在 SDK 中构建它，因为它也使用 makefile，而无需 IDE。 关于gcc版本方法，您可以参考SDK文档： SDK_2_14_0_MIMXRT1170-EVK\docs\MIMXRT1170-EVK MCUXpresso SDK 入门指南.pdf 第六章 使用 Arm ® GCC 运行演示 您还可以参考我的 Ubuntu 版本方法文档： https://community.nxp.com/t5/i-MX-RT-Knowledge-Base/RT-Linux-SDK-build-based-on-Ubuntu/ta-p/1690185 希望对您有所帮助！ 如果您还有任何疑问，请随时告诉我。 顺祝商祺！ kerry

imx8mmini sai1 max sample rates hi     sai1 connect a codecs support sample rates 768khz/32bit. SAI1-RX0 connect codec_DOUT. have no data with 768khz/32bit and L/R channels to read.but SAI1-TXFS/SAI1-TXC could output 768khz/49.152Mhz. read L/R channels with 768khz/16bit and 384khz/32bit is ok.kernel version 6.1.36. thanks. Re: imx8mmini sai1 max sample rates about codecs dts as below: run arecord cmd with "-f S32_LE -r 384000 -c 2 -d 1 test.wav" or "-f S16_LE -r 786000 -c 2 -d 1 test.wav" is ok. but run with "-f S32_LE -r 768000 -c 2 -d 1 test.wav",test.wav is NULL. Re: imx8mmini sai1 max sample rates Hello, Could you please share your device tree configuration? Which CODEC are you using? Best regards. Re: imx8mmini sai1 max sample rates Hello, If you are getting errors related to the sample rate, could be caused by clock source since it is not able to generate the necessary frequency for that sample rate. Sometimes, is needed to use a dedicated clock source such as an external clock to get an specific sample rate. Best regards. Re: imx8mmini sai1 max sample rates when read with 768kHz 32bit x 2 channel,SAI1_TXFS/SAI1_TXC output is ok(768khz/49.152Mhz),The codec data output pin (connect to SAI1_RX0)has data output when checked with an oscilloscope.Is it possible that imx8mmini sdma is not worKing? Re: imx8mmini sai1 max sample rates Hello, Do you get underflow or overflow errors during testing? Best regards. Re: imx8mmini sai1 max sample rates get kernel print errors during testing as below: [ 506.336480] [858] wait_for_avail:1936: asoc-simple-card sound-pcmdev: capture write error (DMA or IRQ trouble?) Re: imx8mmini sai1 max sample rates Hello, Please share your dmesg: dmesg | grep -i -E "xrun|overrun|dma|fifo|sdma|sai" With that error log the issue could be caused by an overrun, please try to increase period and buffer size, for example: arecord -D hw:0,0 -f S32_LE -r 768000 -c 2 --buffer-size=65536 --period-size=8192 -d 5 test.wav Best regards. Re: imx8mmini sai1 max sample rates hi JorgeCas:  thanks for your reply. the same error when  increase period and buffer size. ------------------------------------ root@mx8mm:/tmp# arecord -v -D hw:0,0 -f S16_LE -r 768000 -c 2 -d 1 test.wav Recording WAVE 'test.wav' : Signed 16 bit Little Endian, Rate 768000 Hz, Stereo Hardware PCM card 0 'pcmdev-audio' device 0 subdevice 0 Its setup is: stream : CAPTURE access : RW_INTERLEAVED format : S16_LE subformat : STD channels : 2 rate : 768000 exact rate : 768000 (768000/1) msbits : 16 buffer_size : 131064 period_size : 16383 period_time : 21332 tstamp_mode : NONE tstamp_type : MONOTONIC period_step : 1 avail_min : 16383 period_event : 0 start_threshold : 1 stop_threshold : 131064 silence_threshold: 0 silence_size : 0 boundary : 9222809086901354496 appl_ptr : 0 hw_ptr : 0 root@mx8mm:/tmp# ls test.wav -la -rw-r--r-- 1 root root 3072044 Jul 22 22:09 test.wav root@mx8mm:/tmp# arecord -D hw:0,0 -f S32_LE -r 768000 -c 2 --buffer-size=65536 --period-size=8192 -d 5 test.wav Recording WAVE 'test.wav' : Signed 32 bit Little Endian, Rate 768000 Hz, Stereo arecord: pcm_read:2221: read error: Input/output error root@mx8mm:/tmp# dmesg | grep -i -E "xrun|overrun|dma|fifo|sdma|sai" [ 0.000000] OF: reserved mem: initialized node linux,cma, compatible id shared-dma-pool [ 0.000000] Reserved memory: created DMA memory pool at 0x00000000b8400000, size 1 MiB [ 0.000000] OF: reserved mem: initialized node vdevbuffer@b8400000, compatible id shared-dma-pool [ 0.000000] DMA [mem 0x0000000040000000-0x00000000bfffffff] [ 0.000000] DMA32 empty [ 0.000000] Policy zone: DMA [ 0.043871] DMA: preallocated 256 KiB GFP_KERNEL pool for atomic allocations [ 0.044176] DMA: preallocated 256 KiB GFP_KERNEL|GFP_DMA pool for atomic allocations [ 0.044364] DMA: preallocated 256 KiB GFP_KERNEL|GFP_DMA32 pool for atomic allocations [ 0.105243] iommu: DMA domain TLB invalidation policy: strict mode [ 0.195002] imx-sdma 302c0000.dma-controller: Direct firmware load for imx/sdma/sdma-imx7d.bin failed with error -2 [ 0.195018] imx-sdma 302c0000.dma-controller: Falling back to sysfs fallback for: imx/sdma/sdma-imx7d.bin [ 0.199761] mxs-dma 33000000.dma-controller: initialized [ 1.996379] mmc2: SDHCI controller on 30b60000.mmc [30b60000.mmc] using ADMA [ 2.786360] mmc1: SDHCI controller on 30b50000.mmc [30b50000.mmc] using ADMA [ 8.812860] imx-sdma 302c0000.dma-controller: firmware found. [ 8.818748] imx-sdma 30bd0000.dma-controller: firmware found. [ 8.825901] imx-sdma 30bd0000.dma-controller: loaded firmware 4.6 [ 91.326700] [857] soc_hw_sanity_check:775: 30010000.sai-pcmdevice-codec: ASoC: pcmdevice-codec <-> 30010000.sai info: [ 91.326722] [857] soc_hw_sanity_check:777: 30010000.sai-pcmdevice-codec: ASoC: rate mask 0x154c0 [ 91.326728] [857] soc_hw_sanity_check:778: 30010000.sai-pcmdevice-codec: ASoC: ch min 2 max 8 [ 91.326734] [857] soc_hw_sanity_check:780: 30010000.sai-pcmdevice-codec: ASoC: rate min 44100 max 768000 [ 91.342776] [857] fsl_sai_set_bclk:460: fsl-sai 30010000.sai: ratio 2 for freq 24576000Hz based on clock 49152000Hz [ 91.342784] [857] fsl_sai_set_bclk:481: fsl-sai 30010000.sai: best fit: clock id=1, div=2, deviation =0 [ 91.343315] [857] dapm_update_dai_unlocked:2698: fsl-sai 30010000.sai: Update DAI routes for 30010000.sai capture [ 113.965788] [861] soc_hw_sanity_check:775: 30010000.sai-pcmdevice-codec: ASoC: pcmdevice-codec <-> 30010000.sai info: [ 113.965809] [861] soc_hw_sanity_check:777: 30010000.sai-pcmdevice-codec: ASoC: rate mask 0x154c0 [ 113.965816] [861] soc_hw_sanity_check:778: 30010000.sai-pcmdevice-codec: ASoC: ch min 2 max 8 [ 113.965822] [861] soc_hw_sanity_check:780: 30010000.sai-pcmdevice-codec: ASoC: rate min 44100 max 768000 [ 113.977610] [861] fsl_sai_set_bclk:460: fsl-sai 30010000.sai: ratio 1 for freq 49152000Hz based on clock 49152000Hz [ 113.977618] [861] fsl_sai_set_bclk:481: fsl-sai 30010000.sai: best fit: clock id=1, div=1, deviation =0 [ 113.978149] [861] dapm_update_dai_unlocked:2698: fsl-sai 30010000.sai: Update DAI routes for 30010000.sai capture [ 124.127055] [861] wait_for_avail:1936: asoc-simple-card sound-pcmdev: capture write error (DMA or IRQ trouble?) root@mx8mm:/tmp# ls test.wav -la -rw-r--r-- 1 root root 44 Jul 22 22:09 test.wav root@mx8mm:/tmp#

S32K312 上的 Fat 文件系统集成（RTD 6.0.0，非AUTOSAR、SPI SD卡驱动程序） 您好， 我已经成功地在 S32K312 EVB 上使用 RTD 6.0.0（非 AUTOSAR Lpspi_Ip 驱动程序）实现了通过 SPI 的 SD 卡驱动程序。 以下功能已实现： SD卡初始化（CMD0、CMD8、ACMD41、CMD58） 单块读取（CMD17） 单块写入（CMD24） 多块读取（CMD18） 多块写入（CMD25） 已通过向 SD 卡写入数据并成功读取数据验证了驱动程序。 现在我想添加对 FAT 文件系统的支持，以便在 PC 上创建、写入和读取文件。 我有几个问题： NXP 是否为使用 RTD 6.0.0（非 AUTOSAR）的 S32K312 提供或支持 FatFs 集成？如果没有，是否有其他 S32K3 设备的示例可供参考？ NXP是否有任何中间件软件包可以将FatFs与SD卡集成？ 如果没有官方示例，建议的方法是集成 Elm-Chan FatFs 库并实现所需的 diskio.c 函数。使用我现有的SD卡驱动程序进行接口？ 是否有任何参考项目、应用笔记或示例库演示了在 S32K3 设备上集成 FAT 文件系统？ 我有点困惑，不知道哪种方法更适合产品开发。任何指导或参考资料都将不胜感激。 谢谢！ Re: Fat Filesystem Integration on S32K312 (RTD 6.0.0, Non-AUTOSAR, SPI SD Card Driver) 嗨@parvathitp 目前 S32K312 尚不支持 FatFS 文件系统。在 S32K3 系列中，FatFS 集成仅适用于包含 uSDHC 外设的设备，该外设提供微控制器和 SD 卡之间的硬件接口。 对于这些设备，我们提供了一个 SDHC 软件栈，通过 uSDHC 驱动程序简化对 SD 总线的访问，并实现与 FatFS 的集成。 社区帖子“将 FatFs 文件系统移植到 KL26 SPI SD 卡代码”中描述的方法和概念可能对您的实现有所帮助。虽然该示例基于 KL26 设备，但正如标题所示，它描述了如何将 FatFS 文件系统移植到不包含 SDHC/uSDHC 外围设备的设备上，这与您的用例类似。 BR，VaneB

Fat Filesystem Integration on S32K312 (RTD 6.0.0, Non-AUTOSAR, SPI SD Card Driver) Hi, I have successfully implemented an SD Card driver over SPI on the S32K312 EVB using RTD 6.0.0 (Non-AUTOSAR Lpspi_Ip driver). The following functionality is already working: SD card initialization (CMD0, CMD8, ACMD41, CMD58) Single block read (CMD17) Single block write (CMD24) Multiple block read (CMD18) Multiple block write (CMD25) The driver has been verified by successfully writing data to the SD card and reading it back. Now I would like to add FAT filesystem support so that files can be created, written, and read on a PC. I have a few questions: Does NXP provide or support FatFs integration for the S32K312 using RTD 6.0.0 (Non-AUTOSAR)? If not, are there any supported examples available for other S32K3 devices that can be used as a reference? Is there any middleware package from NXP for integrating FatFs with an SD card? If there is no official example, is the recommended approach to integrate the Elm-Chan FatFs library and implement the required diskio.c interface using my existing SD card driver? Are there any reference projects, application notes, or example repositories that demonstrate FAT filesystem integration on S32K3 devices? I am a bit confused about which approach is recommended for production development. Any guidance or references would be greatly appreciated. Thank you. Re: Fat Filesystem Integration on S32K312 (RTD 6.0.0, Non-AUTOSAR, SPI SD Card Driver) Hi @parvathitp  There is currently no specific FatFS support for the S32K312. Within the S32K3 family, FatFS integration is available only for devices that include the uSDHC peripheral, which provides the hardware interface between the microcontroller and an SD card. For these devices, an SDHC software stack is provided to simplify access to the SD bus through the uSDHC driver and to enable integration with FatFS. The approach and concepts described in the community thread "Porting FatFs file system to KL26 SPI SD card code" may be a useful reference for your implementation. Although the example is based on the KL26 device, as the title suggests, it describes how to port the FatFS file system to a device that does not include an SDHC/uSDHC peripheral, which is similar to your use case. BR, VaneB

构建 Yocto Linux 时出现基础文件错误 构建 Yocto 错误。当我按照 NXP 的 Yocto 指南进行版本时。如何修复此错误？ 警告：失败的 setscene 任务的日志文件位于 /home/vmc/Desktop/imx-yocto-bsp/build-wayland/tmp/work/armv8a-poky-linux/ptest-runner/2.4.5+git/temp/log.do_package_setscene.1680451 警告：场景设置任务（/home/vmc/Desktop/imx-yocto-bsp/sources/poky/meta/recipes-support/ptest-runner/ptest-runner_2.4.5.bb:do_package_setscene）执行失败，退出代码为“1”——将改为运行实际任务。 错误：base-files-3.0.14-r0 do_package：执行 exec_func_python() 自动生成的 Python 函数时出错： 导致此异常/失败的 Python 调用堆栈跟踪如下： 文件：'exec_func_python() autogenerated'，行号：2，函数： 0001： *** 0002:perform_packagecopy(d) 0003： 文件：'/home/vmc/Desktop/imx-yocto-bsp/sources/poky/meta/classes-global/package.bbclass'，行号：363，函数：perform_packagecopy 0359: rpath_replace (dvar, d) 0360:} 0361:perform_packagecopy[cleandirs] = "${PKGD} " 0362:perform_packagecopy[dirs] = "${PKGD} " *** 0363： 0364:python populate_packages() { 0365: oe.package.populate_packages(d) 0366:} 0367:populate_packages[dirs] = " ${D} " 文件：'/usr/lib/python3.10/subprocess.py'行号：421，函数：check_output 0417：否则： 0418：空 = b'' 0419: kwargs['input'] = 空 0420: *** 0421: 返回 run(*popenargs, stdout=PIPE, timeout=timeout, check=True, 0422: **kwargs).stdout 0423： 0424： 0425:class CompletedProcess(object): 文件：'/usr/lib/python3.10/subprocess.py'lineno: 526, function: run 0522: # 我们不调用 process.wait()作为。 __exit__它能帮我们做到这一点。 0523：提高 0524: retcode = process.poll() 0525：如果检查并返回代码： *** 0526: 引发 CalledProcessError(retcode, process.args, 0527: output=stdout, stderr=stderr) 0528: 返回 CompletedProcess(process.args, retcode, stdout, stderr) 0529： 0530: 异常：subprocess.CalledProcessError：命令“tar --exclude=./sysroot-only”-cf - -C /home/vmc/Desktop/imx-yocto-bsp/build-wayland/tmp/work/imx8mqevk-poky-linux/base-files/3.0.14/image -p -S .| tar -xf - -C /home/vmc/Desktop/imx-yocto-bsp/build-wayland/tmp/work/imx8mqevk-poky-linux/base-files/3.0.14/代码包，软件包' 返回非零退出状态 2。 子进程输出： 获取到未知目录的 *at() 系统调用，文件描述符为 4 fd 4 的 bin 路径未知 无法为“bin”分配绝对路径。 tar：./usr/bin：无法创建目录：地址错误 获取到未知目录的 *at() 系统调用，文件描述符为 4 文件描述符 4 的未知基本路径，路径库 无法为“lib”分配绝对路径。 tar：./usr/lib：无法创建目录：地址错误 获取到未知目录的 *at() 系统调用，文件描述符为 4 fd 4 的未知基本路径，路径游戏 无法为“games”分配绝对路径。 tar：./usr/games：无法创建目录：地址错误 获取到未知目录的 *at() 系统调用，文件描述符为 4 文件描述符 4 的未知基本路径，路径共享 无法为“share”分配绝对路径。 tar：./usr/share：无法创建目录：地址错误 获取到未知目录的 *at() 系统调用，文件描述符为 4 文件描述符 4 的未知基本路径，路径共享 无法为“share”分配绝对路径。 获取到未知目录的 *at() 系统调用，文件描述符为 4 文件描述符 4 的未知基本路径，路径共享 无法为“share”分配绝对路径。 tar：./usr/share：无法创建目录：地址错误 tar：./usr/share/dict：无法创建目录：没有该文件或目录 获取到未知目录的 *at() 系统调用，文件描述符为 4 文件描述符 4 的未知基本路径，路径共享 无法为“share”分配绝对路径。 获取到未知目录的 *at() 系统调用，文件描述符为 4 文件描述符 4 的未知基本路径，路径共享 无法为“share”分配绝对路径。 tar：./usr/share：无法创建目录：地址错误 tar: ./usr/share/man:无法创建目录：没有该文件或目录 获取到未知目录的 *at() 系统调用，文件描述符为 4 文件描述符 4 的未知基本路径，路径共享 无法为“share”分配绝对路径。 获取到未知目录的 *at() 系统调用，文件描述符为 4 文件描述符 4 的未知基本路径，路径共享 无法为“share”分配绝对路径。 tar：./usr/share：无法创建目录：地址错误 tar：./usr/share/doc：无法创建目录：没有该文件或目录 获取到未知目录的 *at() 系统调用，文件描述符为 4 文件描述符 4 的未知基本路径，路径共享 无法为“share”分配绝对路径。 获取到未知目录的 *at() 系统调用，文件描述符为 4 文件描述符 4 的未知基本路径，路径共享 无法为“share”分配绝对路径。 tar：./usr/share：无法创建目录：地址错误 焦油：./usr/share/doc/base-files-3.0.14：无法创建目录：没有该文件或目录 获取到未知目录的 *at() 系统调用，文件描述符为 4 文件描述符 4 的未知基本路径，路径共享 无法为“share”分配绝对路径。 获取到未知目录的 *at() 系统调用，文件描述符为 4 文件描述符 4 的未知基本路径，路径共享 无法为“share”分配绝对路径。 tar：./usr/share：无法创建目录：地址错误 tar：./usr/share/misc：无法创建目录：没有该文件或目录 获取到未知目录的 *at() 系统调用，文件描述符为 4 文件描述符 4 的未知基本路径，路径共享 无法为“share”分配绝对路径。 获取到未知目录的 *at() 系统调用，文件描述符为 4 文件描述符 4 的未知基本路径，路径共享 无法为“share”分配绝对路径。 tar：./usr/share：无法创建目录：地址错误 tar: ./usr/share/common-licenses:无法创建目录：没有该文件或目录 获取到未知目录的 *at() 系统调用，文件描述符为 4 文件描述符 4 的未知基本路径，路径共享 无法为“share”分配绝对路径。 获取到未知目录的 *at() 系统调用，文件描述符为 4 文件描述符 4 的未知基本路径，路径共享 无法为“share”分配绝对路径。 tar：./usr/share：无法创建目录：地址错误 tar：./usr/share/info：无法创建目录：没有该文件或目录 获取到未知目录的 *at() 系统调用，文件描述符为 4 文件描述符 4 的 sbin 路径未知 无法为“sbin”分配绝对路径。 tar：./usr/sbin：无法创建目录：地址错误 获取到未知目录的 *at() 系统调用，文件描述符为 4 文件描述符 4 的源路径未知 无法为“src”分配绝对路径。 tar：./usr/src：无法创建目录：地址错误 获取到未知目录的 *at() 系统调用，文件描述符为 4 文件描述符 4 的未知基本路径，路径包含 无法为“include”分配绝对路径。 tar：./usr/include：无法创建目录：地址错误 获取到未知目录的 *at() 系统调用，文件描述符为 4 文件描述符 4 的未知基本路径，路径 tmp 无法为“tmp”分配绝对路径。 tar：./var/tmp：无法创建指向“volatile/tmp”的符号链接：地址错误 获取到未知目录的 *at() 系统调用，文件描述符为 4 文件描述符 4 的基本路径未知，路径为本地路径 无法为“local”分配绝对路径。 tar：./var/local：无法创建目录：地址错误 获取到未知目录的 *at() 系统调用，文件描述符为 4 文件描述符 4 的未知基本路径，路径库 无法为“lib”分配绝对路径。 tar：./var/lib：无法创建目录：地址错误 获取到未知目录的 *at() 系统调用，文件描述符为 4 文件描述符 4 的未知基本路径，路径库 无法为“lib”分配绝对路径。 获取到未知目录的 *at() 系统调用，文件描述符为 4 文件描述符 4 的未知基本路径，路径库 无法为“lib”分配绝对路径。 tar：./var/lib：无法创建目录：地址错误 tar：./var/lib/misc：无法创建目录：没有该文件或目录 获取到未知目录的 *at() 系统调用，文件描述符为 4 fd 4 的未知基路径，路径易失性 无法为“volatile”分配绝对路径。 tar：./var/volatile：无法创建目录：地址错误 获取到未知目录的 *at() 系统调用，文件描述符为 4 fd 4 的未知基路径，路径易失性 无法为“volatile”分配绝对路径。 获取到未知目录的 *at() 系统调用，文件描述符为 4 fd 4 的未知基路径，路径易失性 无法为“volatile”分配绝对路径。 tar：./var/volatile：无法创建目录：地址错误 tar：./var/volatile/tmp：无法创建目录：没有该文件或目录 获取到未知目录的 *at() 系统调用，文件描述符为 4 fd 4 的未知基路径，路径易失性 无法为“volatile”分配绝对路径。 获取到未知目录的 *at() 系统调用，文件描述符为 4 fd 4 的未知基路径，路径易失性 无法为“volatile”分配绝对路径。 tar：./var/volatile：无法创建目录：地址错误 tar：./var/volatile/log：无法创建目录：没有该文件或目录 获取到未知目录的 *at() 系统调用，文件描述符为 4 文件描述符 4 的未知基本路径，路径日志 无法为“log”分配绝对路径。 tar：./var/log：无法创建指向“volatile/log”的符号链接：地址错误 获取到未知目录的 *at() 系统调用，文件描述符为 4 文件描述符 4 的基本路径未知，路径锁定 无法为“lock”分配绝对路径。 tar：./var/lock：无法打开：地址错误 获取到未知目录的 *at() 系统调用，文件描述符为 4 文件描述符 4 的未知基本路径，路径假脱机 无法为“spool”分配绝对路径。 tar：./var/spool：无法创建目录：地址错误 获取到未知目录的 *at() 系统调用，文件描述符为 4 fd 4 的未知基本路径，路径备份 无法为“备份”分配绝对路径。 tar：./var/backups：无法创建目录：地址错误 获取到未知目录的 *at() 系统调用，文件描述符为 4 fd 4 的未知基本路径，路径运行 无法为“run”分配绝对路径。 tar：./var/run：无法打开：地址错误 获取到未知目录的 *at() 系统调用，文件描述符为 4 文件描述符 4 的未知基本路径，路径为 nsswitch.conf 无法为“nsswitch.conf”分配绝对路径。 tar：./etc/nsswitch.conf：无法打开：地址错误 获取到未知目录的 *at() 系统调用，文件描述符为 4 fd 4 的未知基本路径，路径 hosts 无法为“hosts”分配绝对路径。 tar：./etc/hosts：无法打开：地址错误 获取到未知目录的 *at() 系统调用，文件描述符为 4 fd 4 的未知基本路径，路径问题.net 无法为“issue.net”分配绝对路径。 tar：./etc/issue.net：无法打开：地址错误 获取到未知目录的 *at() 系统调用，文件描述符为 4 fd 4 的未知基本路径，路径配置文件 无法为“profile”分配绝对路径。 tar：./etc/profile：无法打开：地址错误 获取到未知目录的 *at() 系统调用，文件描述符为 4 文件描述符 4 的未知基本路径，路径默认值 无法为“default”分配绝对路径。 tar：./etc/default：无法创建目录：地址错误 获取到未知目录的 *at() 系统调用，文件描述符为 4 文件描述符 4 的基本路径未知，路径问题 无法为“issue”分配绝对路径。 tar：./etc/issue：无法打开：地址错误 获取到未知目录的 *at() 系统调用，文件描述符为 4 fd 4 的未知基本路径，路径骨架 无法为“skel”分配绝对路径。 tar：./etc/skel：无法创建目录：地址错误 获取到未知目录的 *at() 系统调用，文件描述符为 4 fd 4 的未知基本路径，路径骨架 无法为“skel”分配绝对路径。 获取到未知目录的 *at() 系统调用，文件描述符为 4 fd 4 的未知基本路径，路径骨架 无法为“skel”分配绝对路径。 tar：./etc/skel：无法创建目录：地址错误 tar：./etc/skel/.profile：无法打开：没有该文件或目录 获取到未知目录的 *at() 系统调用，文件描述符为 4 fd 4 的未知基本路径，路径骨架 无法为“skel”分配绝对路径。 获取到未知目录的 *at() 系统调用，文件描述符为 4 fd 4 的未知基本路径，路径骨架 无法为“skel”分配绝对路径。 tar：./etc/skel：无法创建目录：地址错误 tar：./etc/skel/.bashrc：无法打开：没有该文件或目录 获取到未知目录的 *at() 系统调用，文件描述符为 4 文件描述符 4 的未知基本路径，路径 mtab 无法为“mtab”分配绝对路径。 tar：./etc/mtab：无法打开：地址错误 获取到未知目录的 *at() 系统调用，文件描述符为 4 文件描述符 4 的基本路径未知，路径主机名 无法为“hostname”分配绝对路径。 tar：./etc/hostname：无法打开：地址错误 获取到未知目录的 *at() 系统调用，文件描述符为 4 fd 4 的未知基本路径，路径 fstab 无法为“fstab”分配绝对路径。 tar：./etc/fstab：无法打开：地址错误 获取到未知目录的 *at() 系统调用，文件描述符为 4 fd 4 的未知基本路径，路径 shell 无法为“shells”分配绝对路径。 tar：./etc/shells：无法打开：地址错误 获取到未知目录的 *at() 系统调用，文件描述符为 4 文件描述符 4 的未知基本路径，路径 host.conf 无法为“host.conf”分配绝对路径。 tar：./etc/host.conf：无法打开：地址错误 获取到未知目录的 *at() 系统调用，文件描述符为 4 fd 4 的未知基础路径，路径 motd 无法为“motd”分配绝对路径。 tar：./etc/motd：无法打开：地址错误 tar：由于之前的错误，退出状态为失败。 错误：故障日志文件存储在：/home/vmc/Desktop/imx-yocto-bsp/build-wayland/tmp/work/imx8mqevk-poky-linux/base-files/3.0.14/temp/log.do_package.1734591 错误：任务 (/home/vmc/Desktop/imx-yocto-bsp/sources/poky/meta/recipes-core/base-files/base-files_3.0.14.bb:do_package) 执行失败，退出代码为“1” Re: base-files error when build the yocto linux 谢谢你。它已激活 Re: base-files error when build the yocto linux 在你的 Ubuntu 电脑上，运行命令“sudo apt install tar=1.34+dfsg-1build3”

如何为我们使用的 i.mx RT1062 路由器获取唯一的以太网 MAC 地址？ 你好， 我们使用MIMXRT1062DVL6B，并通过以太网实现我们的产品。 首先，我们使用 `fsl_silicon_id.c` 中的 ` SILICONID_ConvertToMacAddr`为我们的产品实现 MAC 地址，以便使用 NXP 的 OUI 和硅 ID 为每个设备获取唯一的 MAC 地址。 但是，我们通过` SILICONID_ConvertToMacAddr`获取的 MAC 地址并不唯一，它们都相同。 我有个问题。 在调用 `SILICONID_ConvertToMacAddr` 之前，我们需要做哪些设置？ 或者，`SILICONID_ConvertToMacAddr` 无法通过 NXP 设备获取唯一的 MAC 地址？ 我们在 IMXRT1060RM.pdf 的 Rev. 4, 01/2026 中找不到答案。 您能给我们答案吗？ 谢谢。 Re: How can I get unique ethernet MAC address all over the i.mx RT1062 we use? 嗨，阿布纳 感谢您的支持！ 我们了解到，我们可以使用通过SILICONID_ConvertToMacAddr 函数获取的 MAC 地址作为我们产品的 MAC 地址。但我明白 SILICONID_ConvertToMacAddr 只是一个示例，我们不能将其用于我们的大规模产品。我们必须使用我们 OUI 下的 MAC 地址。 顺祝商祺！ 茂 Re: How can I get unique ethernet MAC address all over the i.mx RT1062 we use? 嗨@shigeru-tsujita 感谢您发现这种情况。我们使用 SILICONID_ConvertToMacAddr 函数来减少 NXP MCUX SDK 示例中的 MAC 地址冲突，以用于我们的测试环境。我们在同一交换机上连接不同 SoC 的以太网接口。对于同一系列 SoC 的情况，我们可能无法涵盖。 但我不太明白的是，为什么你们要用这种方式生成产品 MAC 地址。首先，您的 OUI 应该使用您公司的 OUI。那么，我认为贵公司应该对唯一标识符有一个内部特殊定义。 Re: How can I get unique ethernet MAC address all over the i.mx RT1062 we use? 你好，梅。 我理解 SILICONID_ConvertToMacAddr 使用固定的 NXP OUI 和三个字节的硅 ID（它是 OCOTP->CFG0/1 的一部分）来生成 MAC 地址。 我观察了我们目标产品的 OCOTP->CFG0/1。 这些数值如下： - 一个 MIMXRT1062 - OCOTP->CFG0: (uint32_t)0x615c'faa4 - OCOTP->CFG1: (uint32_t)0x2a1e'61d7 - 其他 MIMXRT1062 - OCOTP->CFG0: (uint32_t)0x615c'faa4 - OCOTP->CFG1: (uint32_t)0x4922'61d7 因为 OCOTP->CFG0 的低三个字节在 SILICONID_ConvertToMacAddr 中用作 MAC 地址，所以它们的 MAC 地址相似。 因此，我们很多产品的 MAC 地址都很相似。（现在我们有几十个原型机，虽然我们不会检查所有的 MAC 地址，但我们还没有找到与 54:27:8D:A4:FA:5C 不同的 MAC 地址。） 谢谢。 Re: How can I get unique ethernet MAC address all over the i.mx RT1062 we use? 嗨@shigeru-tsujita ， 非常感谢您对我们产品的关注以及对我们社区的使用。 假设 SDK 的 silicon_id 元器件已正确集成，则在调用 MIMXRT1062 的 SILICONID_ConvertToMacAddr() 之前无需进行其他设置。 请注意，SILICONID_ConvertToMacAddr() 不使用完整的 64 位硅 ID 来生成 MAC 地址。它使用固定的 NXP OUI 作为前 3 个字节，而最后 3 个字节仅使用来自硅 ID 的 3 个字节。 根据SDK代码： 请您读取几个设备的 64 位硅唯一 ID，并检查 ID 值是否读取正确？另外，请比较 siliconId[0]、siliconId[1] 和 siliconId[2]，因为这些是用于生成 MAC 地址的字节。 如果这三个字节在各个设备上都相同，则生成的 MAC 地址也将相同。 顺祝商祺！ 5月 Re: How can I get unique ethernet MAC address all over the i.mx RT1062 we use? 这里的难点在于，由 OCOTP->CFG1 和 OCOTP->CFG0 形成的 64 位数据在芯片之间总是唯一的，但值之间可能只有几个比特的差异。所以，你必须找到一种方法将它们组合在一起，而不会丢失任何信息。我通过对 OCOTP->CFG1 和 OCOTP->CFG0 进行 CRC32 校验，然后使用该 32 位结果构建 MAC 地址，效果相当不错。 要实际生成 MAC 地址，您可以使用“本地管理”的 MAC 地址，其中包含两个常量字节和 32 位 CRC，或者使用您组织的 OUI 作为前三个字节，然后从 CRC 值中获取另外三个字节。

mc9s08qg8 code warrior (Classic IDE) v6.3 windows 11 I downloaded the file, but it will not install, the installer says my OS is wrong. I am using Windows 11 ? Re: mc9s08qg8 code warrior (Classic IDE) v6.3 windows 11 Hello, To use CodeWarrior in windows 11 please update to v11.1, I look for the MC9S08QG8 device and is available in this version. You can download from this link: CodeWarrior® for MCUs (Eclipse IDE)        11.1 Best Regards, Luis

SAF85xx HSE Update SMR Hi NXP,  Do we need to update SMR  when just only Signature bytes change due to code content change but code size, start address ,  key, pointer to signature ... are not changed ? Re: SAF85xx HSE Update SMR Hello, The SMR (Secure Memory Region) entry contains the metadata HSE uses to verify your application image. Even if: the size stays the same the start address stays the same the key handle stays the same the signature pointer stays the same …any modification to the code content produces a different signature, and HSE must verify the new signature. Because of this, the SMR entry that holds the signature must be rewritten with the updated signature bytes. The SMR entry is part of the authenticated boot chain; HSE cannot validate the updated binary unless its corresponding SMR entry reflects the new signature. FYI: Aptiv has direct NXP FAE, so feel free to get in touch with him for details. Best regards, Peter Re: SAF85xx HSE Update SMR Thank you for your response Re: SAF85xx HSE Update SMR Hi, How about in the case I flash new application + new signature (map with new application). in the case " code size, start address , key, pointer to signature" not change, do we need to re install SMR

Is i.MX 9 "there yet"? I started a project in a few years ago and NXP's i.MX 9 line of MPUs were beginning to be released but they were largely unobtainable so I went with a beefy i.MX 8. At this stage, it's way more power than I need and I'd like to move to a much smaller MPU. I was planning on getting the smallest i.MX 8 but the i.MX91 is the smallest cpu they have. I was wondering if I would be better off with the 91 instead of a more mature 8. Thermals are my primary concern so I would assume new is always better, but I just don't know if they are "there yet" since they are still fairly new. A more apples to apples port moving to an 8 could also be a motivator.

base-files error when build the yocto linux Build the yocto error. When i build and follow to guide of nxp by yocto. How to fix the error? WARNING: Logfile for failed setscene task is /home/vmc/Desktop/imx-yocto-bsp/build-wayland/tmp/work/armv8a-poky-linux/ptest-runner/2.4.5+git/temp/log.do_package_setscene.1680451 WARNING: Setscene task (/home/vmc/Desktop/imx-yocto-bsp/sources/poky/meta/recipes-support/ptest-runner/ptest-runner_2.4.5.bb:do_package_setscene) failed with exit code '1' - real task will be run instead ERROR: base-files-3.0.14-r0 do_package: Error executing a python function in exec_func_python() autogenerated: The stack trace of python calls that resulted in this exception/failure was: File: 'exec_func_python() autogenerated', lineno: 2, function: 0001: *** 0002:perform_packagecopy(d) 0003: File: '/home/vmc/Desktop/imx-yocto-bsp/sources/poky/meta/classes-global/package.bbclass', lineno: 363, function: perform_packagecopy 0359: rpath_replace (dvar, d) 0360:} 0361:perform_packagecopy[cleandirs] = "${PKGD}" 0362:perform_packagecopy[dirs] = "${PKGD}" *** 0363: 0364:python populate_packages () { 0365: oe.package.populate_packages(d) 0366:} 0367:populate_packages[dirs] = "${D}" File: '/usr/lib/python3.10/subprocess.py', lineno: 421, function: check_output 0417: else: 0418: empty = b'' 0419: kwargs['input'] = empty 0420: *** 0421: return run(*popenargs, stdout=PIPE, timeout=timeout, check=True, 0422: **kwargs).stdout 0423: 0424: 0425:class CompletedProcess(object): File: '/usr/lib/python3.10/subprocess.py', lineno: 526, function: run 0522: # We don't call process.wait() as .__exit__ does that for us. 0523: raise 0524: retcode = process.poll() 0525: if check and retcode: *** 0526: raise CalledProcessError(retcode, process.args, 0527: output=stdout, stderr=stderr) 0528: return CompletedProcess(process.args, retcode, stdout, stderr) 0529: 0530: Exception: subprocess.CalledProcessError: Command 'tar --exclude=./sysroot-only -cf - -C /home/vmc/Desktop/imx-yocto-bsp/build-wayland/tmp/work/imx8mqevk-poky-linux/base-files/3.0.14/image -p -S . | tar -xf - -C /home/vmc/Desktop/imx-yocto-bsp/build-wayland/tmp/work/imx8mqevk-poky-linux/base-files/3.0.14/package' returned non-zero exit status 2. Subprocess output: got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path bin couldn't allocate absolute path for 'bin'. tar: ./usr/bin: Cannot mkdir: Bad address got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path lib couldn't allocate absolute path for 'lib'. tar: ./usr/lib: Cannot mkdir: Bad address got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path games couldn't allocate absolute path for 'games'. tar: ./usr/games: Cannot mkdir: Bad address got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path share couldn't allocate absolute path for 'share'. tar: ./usr/share: Cannot mkdir: Bad address got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path share couldn't allocate absolute path for 'share'. got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path share couldn't allocate absolute path for 'share'. tar: ./usr/share: Cannot mkdir: Bad address tar: ./usr/share/dict: Cannot mkdir: No such file or directory got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path share couldn't allocate absolute path for 'share'. got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path share couldn't allocate absolute path for 'share'. tar: ./usr/share: Cannot mkdir: Bad address tar: ./usr/share/man: Cannot mkdir: No such file or directory got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path share couldn't allocate absolute path for 'share'. got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path share couldn't allocate absolute path for 'share'. tar: ./usr/share: Cannot mkdir: Bad address tar: ./usr/share/doc: Cannot mkdir: No such file or directory got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path share couldn't allocate absolute path for 'share'. got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path share couldn't allocate absolute path for 'share'. tar: ./usr/share: Cannot mkdir: Bad address tar: ./usr/share/doc/base-files-3.0.14: Cannot mkdir: No such file or directory got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path share couldn't allocate absolute path for 'share'. got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path share couldn't allocate absolute path for 'share'. tar: ./usr/share: Cannot mkdir: Bad address tar: ./usr/share/misc: Cannot mkdir: No such file or directory got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path share couldn't allocate absolute path for 'share'. got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path share couldn't allocate absolute path for 'share'. tar: ./usr/share: Cannot mkdir: Bad address tar: ./usr/share/common-licenses: Cannot mkdir: No such file or directory got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path share couldn't allocate absolute path for 'share'. got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path share couldn't allocate absolute path for 'share'. tar: ./usr/share: Cannot mkdir: Bad address tar: ./usr/share/info: Cannot mkdir: No such file or directory got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path sbin couldn't allocate absolute path for 'sbin'. tar: ./usr/sbin: Cannot mkdir: Bad address got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path src couldn't allocate absolute path for 'src'. tar: ./usr/src: Cannot mkdir: Bad address got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path include couldn't allocate absolute path for 'include'. tar: ./usr/include: Cannot mkdir: Bad address got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path tmp couldn't allocate absolute path for 'tmp'. tar: ./var/tmp: Cannot create symlink to ‘volatile/tmp’: Bad address got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path local couldn't allocate absolute path for 'local'. tar: ./var/local: Cannot mkdir: Bad address got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path lib couldn't allocate absolute path for 'lib'. tar: ./var/lib: Cannot mkdir: Bad address got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path lib couldn't allocate absolute path for 'lib'. got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path lib couldn't allocate absolute path for 'lib'. tar: ./var/lib: Cannot mkdir: Bad address tar: ./var/lib/misc: Cannot mkdir: No such file or directory got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path volatile couldn't allocate absolute path for 'volatile'. tar: ./var/volatile: Cannot mkdir: Bad address got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path volatile couldn't allocate absolute path for 'volatile'. got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path volatile couldn't allocate absolute path for 'volatile'. tar: ./var/volatile: Cannot mkdir: Bad address tar: ./var/volatile/tmp: Cannot mkdir: No such file or directory got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path volatile couldn't allocate absolute path for 'volatile'. got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path volatile couldn't allocate absolute path for 'volatile'. tar: ./var/volatile: Cannot mkdir: Bad address tar: ./var/volatile/log: Cannot mkdir: No such file or directory got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path log couldn't allocate absolute path for 'log'. tar: ./var/log: Cannot create symlink to ‘volatile/log’: Bad address got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path lock couldn't allocate absolute path for 'lock'. tar: ./var/lock: Cannot open: Bad address got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path spool couldn't allocate absolute path for 'spool'. tar: ./var/spool: Cannot mkdir: Bad address got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path backups couldn't allocate absolute path for 'backups'. tar: ./var/backups: Cannot mkdir: Bad address got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path run couldn't allocate absolute path for 'run'. tar: ./var/run: Cannot open: Bad address got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path nsswitch.conf couldn't allocate absolute path for 'nsswitch.conf'. tar: ./etc/nsswitch.conf: Cannot open: Bad address got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path hosts couldn't allocate absolute path for 'hosts'. tar: ./etc/hosts: Cannot open: Bad address got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path issue.net couldn't allocate absolute path for 'issue.net'. tar: ./etc/issue.net: Cannot open: Bad address got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path profile couldn't allocate absolute path for 'profile'. tar: ./etc/profile: Cannot open: Bad address got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path default couldn't allocate absolute path for 'default'. tar: ./etc/default: Cannot mkdir: Bad address got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path issue couldn't allocate absolute path for 'issue'. tar: ./etc/issue: Cannot open: Bad address got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path skel couldn't allocate absolute path for 'skel'. tar: ./etc/skel: Cannot mkdir: Bad address got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path skel couldn't allocate absolute path for 'skel'. got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path skel couldn't allocate absolute path for 'skel'. tar: ./etc/skel: Cannot mkdir: Bad address tar: ./etc/skel/.profile: Cannot open: No such file or directory got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path skel couldn't allocate absolute path for 'skel'. got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path skel couldn't allocate absolute path for 'skel'. tar: ./etc/skel: Cannot mkdir: Bad address tar: ./etc/skel/.bashrc: Cannot open: No such file or directory got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path mtab couldn't allocate absolute path for 'mtab'. tar: ./etc/mtab: Cannot open: Bad address got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path hostname couldn't allocate absolute path for 'hostname'. tar: ./etc/hostname: Cannot open: Bad address got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path fstab couldn't allocate absolute path for 'fstab'. tar: ./etc/fstab: Cannot open: Bad address got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path shells couldn't allocate absolute path for 'shells'. tar: ./etc/shells: Cannot open: Bad address got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path host.conf couldn't allocate absolute path for 'host.conf'. tar: ./etc/host.conf: Cannot open: Bad address got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path motd couldn't allocate absolute path for 'motd'. tar: ./etc/motd: Cannot open: Bad address tar: Exiting with failure status due to previous errors ERROR: Logfile of failure stored in: /home/vmc/Desktop/imx-yocto-bsp/build-wayland/tmp/work/imx8mqevk-poky-linux/base-files/3.0.14/temp/log.do_package.1734591 ERROR: Task (/home/vmc/Desktop/imx-yocto-bsp/sources/poky/meta/recipes-core/base-files/base-files_3.0.14.bb:do_package) failed with exit code '1' Re: base-files error when build the yocto linux Thanks u. It actived Re: base-files error when build the yocto linux On your ubuntu PC, run the command "sudo apt install tar=1.34+dfsg-1build3"

How can I get unique ethernet MAC address all over the i.mx RT1062 we use? Hi,  We use MIMXRT1062DVL6B and realize our product with ethernet. First, we implement the MAC address for our product using `SILICONID_ConvertToMacAddr` on `fsl_silicon_id.c` to get unique MAC address per device with NXP's OUI and silicon ID. But the MAC address we got via `SILICONID_ConvertToMacAddr` was not unique, and they were all identical. So, I have a question. Do we have any setting before calling `SILICONID_ConvertToMacAddr`? Or, `SILICONID_ConvertToMacAddr` does not work to get unique MAC address over the NXP device? We couldn't find answer in IMXRT1060RM.pdf of Rev. 4, 01/2026. Could you give us the answer? thank you. Re: How can I get unique ethernet MAC address all over the i.mx RT1062 we use? Hi, Abner Thank you for your supporting,  We understood that we can use MAC address got via SILICONID_ConvertToMacAddr for our product. But I understand SILICONID_ConvertToMacAddr is just an example and we can't use it for our mass product. And we have to use the MAC address under our OUI. Best regards. Shigeru Re: How can I get unique ethernet MAC address all over the i.mx RT1062 we use? Hi @shigeru-tsujita  Thanks to find this situation. SILICONID_ConvertToMacAddr is used for NXP MCUX SDK example to reduce MAC address conflict in our test environment. We connect to different Socs' eth in same switch. For this same series Soc situation, we may not cover. But what I'm confused is why you use this way to generate your product MAC address. First of all, your OUI should use your company's one. Then the unique ID I think your company should have a internal special definition. Re: How can I get unique ethernet MAC address all over the i.mx RT1062 we use? Hi, May. I understand SILICONID_ConvertToMacAddr make MAC address using fixed NXP OUI and three bytes of silicon ID(it's part of OCOTP->CFG0/1). I observed the OCOTP->CFG0/1 of our target product. Those values are following: - one MIMXRT1062   - OCOTP->CFG0: (uint32_t)0x615c'faa4   - OCOTP->CFG1: (uint32_t)0x2a1e'61d7 - other MIMXRT1062   - OCOTP->CFG0: (uint32_t)0x615c'faa4   - OCOTP->CFG1: (uint32_t)0x4922'61d7 Because lower three bytes of OCOTP->CFG0 is used for MAC address in SILICONID_ConvertToMacAddr, they have similar MAC address. So, many of our product have similar MAC address. (Now we have handreds of prototype and we don't check all MAC address, but we couldn't find differnt MAC address with 54:27:8D:A4:FA:5C yet.) thank you. Re: How can I get unique ethernet MAC address all over the i.mx RT1062 we use? Hi @shigeru-tsujita, Thank you so much for your interest in our products and for using our community. Assuming the SDK silicon_id component is correctly integrated, no additional setting is required before calling SILICONID_ConvertToMacAddr() for MIMXRT1062. Please note that SILICONID_ConvertToMacAddr() does not use the full 64-bit silicon ID to generate the MAC address. It uses a fixed NXP OUI for the first 3 bytes and only 3 bytes from the silicon ID for the last 3 bytes. According to the SDK code: Could you please read the 64-bit silicon unique ID from several devices and check whether the ID values are read correctly? Please also compare siliconId[0] , siliconId[1] , and siliconId[2] , as these are the bytes used to generate the MAC address. If these three bytes are identical across devices, the generated MAC addresses will also be identical. Best Regards May Re: How can I get unique ethernet MAC address all over the i.mx RT1062 we use? The difficult part here is that the 64-bit data formed by OCOTP->CFG1 and OCOTP->CFG0 will always be unique from chip to chip, but there may only be a few bits' difference between the values. So, you have to find a way to combine them together in a way that doesn't lose any information. I have had pretty good luck with doing this by taking a CRC32 of OCOTP->CFG1 and OCOTP->CFG0, then using that 32-bit result to build the MAC address. To actually generate the MAC, you could use a "locally administered" MAC address with two constant bytes then the 32-bit CRC, or use your organization's OUI for the first three bytes, then take the other three bytes from the CRC value. 

i.MX95 EVKベースボード設計に関する疑問 これはIMX95ボードに12Vの電源入力がどのように取り込まれるかの回路図です。この設計には少し疑問があります... 1. なぜ20Aのヒューズが2本並列に接続されているのか、40Aの定格電流で行われているのか、それは良い方法なのか? 2. Q2が「オン」のとき、Q2のゲートはGNDに接続されますが、Q2を「オフ」にする際はゲートは浮遊状態のままになります。これは信頼できるのでしょうか?ゲートピンはソース電圧までプルアップすべきでしょうか？ Re: Doubt regarding i.MX95 EVK base board design 40Aのヒューズを使わないのはなぜですか？サイズ制限のためですか？ Re: Doubt regarding i.MX95 EVK base board design Q1。突入電流が20Aを超えるため、20A定格のヒューズを2枚(小型サイズ1206)で使用し、コスト効率の高い電流定格を提供するのが良い方法です。 Q2.Q2がオフのとき、そのゲートピンは浮かんだままではなく、100Khmsの抵抗(R197)でソースピンと同じ電源レールに引き上げられ、完全にオフにできます。 Re: Doubt regarding i.MX95 EVK base board design もし40A定格の小型ヒューズを調達できれば、20Aの20Aヒューズをそれに交換できるでしょう。ヒューズ保護が不要な場合は、ヒューズもショートさせることができます。

私たちが使っている i.mx RT1062全体でイーサネットMACアドレスを一意に取得するにはどうすればいいですか? こんにちは、 私たちは イーサネットでMIMXRT1062DVL6Bし、製品を実現させてください。 まず、製品のMACアドレスを「SILICONID_ConvertToMacAddr」で実装します。「fsl_silicon_id.c」上で、NXPのOUIとシリコンIDを持つデバイスごとのユニークなMACアドレスを取得するために。 でもMACアドレスは SILICONID_ConvertToMacAddrは唯一無二ではなく、すべて同一だった。 質問があります。 「SILICONID_ConvertToMacAddr」と呼ぶ前に何か設定はありますか? それとも、「SILICONID_ConvertToMacAddr」はNXPデバイス上で一意のMACアドレスを取得するために機能しませんか? 2026年1月4号のIMXRT1060RM.pdfでは答えが見つかりませんでした。 答えを教えていただけますか? ありがとうございます。 Re: How can I get unique ethernet MAC address all over the i.mx RT1062 we use? やあ、アブナー ご支援ありがとうございます。 MACアドレスを使えることは理解しましたSILICONID_ConvertToMacAddr製品に。しかし、SILICONID_ConvertToMacAddrはあくまで例であり、大量生産には使えないと理解しています。そして、OUIのMACアドレスを使わなければなりません。 よろしくお願いいたします。 茂 Re: How can I get unique ethernet MAC address all over the i.mx RT1062 we use? こんにちは、@shigeru辻田  この状況を見つけてくれてありがとうございます。SILICONID_ConvertToMacAddrはNXP MCUX SDKの例として、テスト環境でのMACアドレスの競合を減らすために使われています。同じスイッチで異なるSocsのETHに接続しています。同じシリーズのSocの状況については、ここでは触れないかもしれません。 しかし、なぜこの方法で製品のMACアドレスを生成するのかが混乱しています。まず第一に、あなたのOUIは会社のものを使うべきです。そして、ユニークIDについては、会社内に特別な定義があるはずです。 Re: How can I get unique ethernet MAC address all over the i.mx RT1062 we use? こんにちは、メイ。 SILICONID_ConvertToMacAddrは、固定のNXP OUIと3バイトのシリコンID（OCOTP->CFG0/1の一部）を使用してMACアドレスを生成すると理解しています。 ターゲット製品のOCOTP->CFG0/1を観察しました。 それらの値は以下のとおりです。 - MIMXRT1062 1個 - OCOTP->CFG0: (uint32_t)0x615c'faa4 - OCOTP->CFG1: (uint32_t)0x2a1e'61d7 - その他のMIMXRT1062 - OCOTP->CFG0: (uint32_t)0x615c'faa4 - OCOTP->CFG1: (uint32_t)0x4922'61d7 OCOTP->CFG0 の下位 3 バイトが SILICONID_ConvertToMacAddr の MAC アドレスに使用されるため、両者の MAC アドレスは類似しています。 SO、多くの製品は似たMACアドレスを持っています。（現在、数百個のプロトタイプを保有しており、すべてのMACアドレスをチェックしているわけではありませんが、54:27:8D:A4:FA:5Cとは異なるMACアドレスはまだ見つかっていません。） ありがとう。 Re: How can I get unique ethernet MAC address all over the i.mx RT1062 we use? こんにちは@shigeru-tsujitaさん 私たちの製品にご関心を寄せ、コミュニティをご利用いただき、本当にありがとうございます。 SDK silicon_idコンポーネントが正しく統合されていると仮定すれば、MIMXRT1062のためにSILICONID_ConvertToMacAddr()を呼び出す前に追加の設定は必要ありません。 SILICONID_ConvertToMacAddr() は、MAC アドレスを生成する際に、完全な 64 ビットのシリコン ID を使用しないことにご注意ください。最初の3バイトには固定のNXP OUIを使用し、最後の3バイトにはシリコンIDから3バイトのみを使用します。 SDKコードによると: 複数のデバイスから64ビットシリコンのユニークIDを読み取り、ID値が正しく読み取られているか確認してもらえますか?また、siliconId[0]、siliconId[1]、siliconId[2]も比較してください。これらはMACアドレスを生成するために使用されるバイトです。 これらの3バイトがデバイス間で同一であれば、生成されるMACアドレスも同一になります。 よろしくお願いいたします。 5月 Re: How can I get unique ethernet MAC address all over the i.mx RT1062 we use? ここで難しいのは、OCOTP->CFG1とOCOTP->CFG0によって形成される64ビットデータはチップごとに常に一意であるにもかかわらず、値の違いはわずか数ビットしかない場合があることです。だからこそ、情報を失わないようにそれらを組み合わせる方法を見つけなければなりません。私は、OCOTP->CFG1とOCOTP->CFG0のCRC32を取得し、その32ビットの結果を使用してMACアドレスを構築することで、かなりうまくいっています。 実際にMACを生成するには、「ローカル管理」MACアドレス(定数2バイトの後に32ビットCRC)を使うか、組織のOUIを最初の3バイトに使い、残りの3バイトをCRCの値から取る方法もあります。

Yocto Linuxをビルドする際のbase-filesエラー Build the Yoctoエラー。私が作ったときは、YoctoのNXPガイドに従っています。エラーを修正するにはどうすればよいですか？ 警告:失敗したセットシーンタスクのログファイルは /home/vmc/Desktop/imx-yocto-bsp/build-wayland/tmp/work/armv8a-poky-Linux/ptest-runner/2.4.5+git/temp/log.do_package_setscene.1680451 です。 警告:セットシーンタスク(/home/vmc/Desktop/imx-Yocto-bsp/sources/poky/meta/recipes-サポート/ptest-runner/ptest-runner_2.4.5.bb:do_package_setscene)が終了コード「1」で失敗しました。代わりに実際のタスクが実行されます エラー:base-files-3.0.14-r0 do_package:exec_func_python()でPython関数を実行する際にエラーが発生します。 この例外/失敗を引き起こしたPython呼び出しのスタックトレースは以下の通りです: ファイル: 'exec_func_python() autogenerated', lineno: 2, function: 0001: 0002:perform_packagecopy(d) 0003: ファイル: '/ホーム/vmc/Desktop/imx-Yocto-bsp/sources/poky/meta/classes-global/package.bbclass', lineno: 363, function: perform_packagecopy 0359: rpath_replace (dvar, d) 0360:} 0361:perform_packagecopy[cleandirs] = "${PKGD}" 0362:perform_packagecopy[指揮] = "${PKGD}" *** 0363: 0364:Python populate_パッケージs () { 0365: oe.package.populate_パッケージs(d) 0366:} 0367:populate_packages[dirs] = " ${D} " ファイル: '/usr/lib/python3.10/subprocess.py'、行番号: 421、関数: check_output 0417: それ以外の場合: 0418: 空 = b'' 0419: kwargs['input'] = 空 0420: *** 0421: return run(*popenargs, stdout=PIPE, timeout=timeout, check=True, 0422: **kwargs).stdout 0423: 0424: 0425:class CompletedProcess(object): ファイル: '/usr/lib/python3.10/subprocess.py'、行番号: 526、関数: 実行 0522: # process.wait() は呼び出しませんとして。 __exit__それは私たちのためにやってくれる。 0523: 上げる 0524: retcode = process.poll() 0525: チェックして戻りコードを取得する場合: *** 0526: raise CalledProcessError(retcode, process.args, 0527: 出力=標準出力、標準エラー=標準エラー) 0528: return CompletedProcess(process.args, retcode, stdout, stderr) 0529: 0530: 例外: subprocess.CalledProcessError: コマンド 'tar --exclude=./sysroot-only'-cf - -C /home/vmc/Desktop/imx-yocto-bsp/build-wayland/tmp/work/imx8mqevk-poky-linux/base-files/3.0.14/image -p -S .|tar -xf - -C /home/vmc/Desktop/imx-yocto-bsp/build-wayland/tmp/work/imx8mqevk-poky-linux/base-files/3.0.14/package' は終了ステータス2を返しました。 サブプロセスの出力: 不明なディレクトリ、fd 4 に対して *at() システムコールが呼び出されました fd 4 の不明なベースパス、パス bin 'bin' の絶対パスを割り当てられませんでした。 tar: ./usr/bin:Cannot mkdir: 悪いアドレス 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知の基底パス、パスライブラリ 「リベラル」に絶対的な道を割り当てることができませんでした。 tar: ./usr/lib:Cannot mkdir: 悪いアドレス 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知のベースパス、Path Games 『ゲーム』に絶対的な道を割り当てることができませんでした。 tar: ./usr/games:Cannot mkdir: 悪いアドレス 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知のベースパス、パス共有 「シェア」の絶対的な経路を割り当てることができませんでした。 tar: ./usr/share:Cannot mkdir: 悪いアドレス 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知のベースパス、パス共有 「シェア」の絶対的な経路を割り当てることができませんでした。 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知のベースパス、パス共有 「シェア」の絶対的な経路を割り当てることができませんでした。 tar: ./usr/share:Cannot mkdir: 悪いアドレス TAR: ./USR/Share/DICT:Cannot mkdir:そのようなファイルやディレクトリは存在しません 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知のベースパス、パス共有 「シェア」の絶対的な経路を割り当てることができませんでした。 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知のベースパス、パス共有 「シェア」の絶対的な経路を割り当てることができませんでした。 tar: ./usr/share:Cannot mkdir: 悪いアドレス タール:./USR/シェア/男:Cannot mkdir:そのようなファイルやディレクトリは存在しません 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知のベースパス、パス共有 「シェア」の絶対的な経路を割り当てることができませんでした。 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知のベースパス、パス共有 「シェア」の絶対的な経路を割り当てることができませんでした。 tar: ./usr/share:Cannot mkdir: 悪いアドレス tar: ./usr/share/doc:Cannot mkdir:そのようなファイルやディレクトリは存在しません 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知のベースパス、パス共有 「シェア」の絶対的な経路を割り当てることができませんでした。 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知のベースパス、パス共有 「シェア」の絶対的な経路を割り当てることができませんでした。 tar: ./usr/share:Cannot mkdir: 悪いアドレス tar: ./usr/share/doc/base-files-3.0.14:Cannot mkdir:そのようなファイルやディレクトリは存在しません 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知のベースパス、パス共有 「シェア」の絶対的な経路を割り当てることができませんでした。 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知のベースパス、パス共有 「シェア」の絶対的な経路を割り当てることができませんでした。 tar: ./usr/share:Cannot mkdir: 悪いアドレス TAR: ./USR/Share/MISC:Cannot mkdir:そのようなファイルやディレクトリは存在しません 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知のベースパス、パス共有 「シェア」の絶対的な経路を割り当てることができませんでした。 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知のベースパス、パス共有 「シェア」の絶対的な経路を割り当てることができませんでした。 tar: ./usr/share:Cannot mkdir: 悪いアドレス TAR: ./USR/share/common-licenses:Cannot mkdir:そのようなファイルやディレクトリは存在しません 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知のベースパス、パス共有 「シェア」の絶対的な経路を割り当てることができませんでした。 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知のベースパス、パス共有 「シェア」の絶対的な経路を割り当てることができませんでした。 tar: ./usr/share:Cannot mkdir: 悪いアドレス tar: ./usr/share/info:Cannot mkdir:そのようなファイルやディレクトリは存在しません 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知の基底パス、パスSBIN 「sbin」に絶対的な経路を割り当てることができませんでした。 tar: ./usr/sbin:Cannot mkdir: 悪いアドレス 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知のベースパス、パスSRC 「SRC」に絶対的な経路を割り当てることができませんでした。 tar: ./usr/src:Cannot mkdir: 悪いアドレス 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知の基線経路、経路には以下が含まれます 「インクルーク」の絶対的な経路を割り当てることができませんでした。 tar: ./usr/include:Cannot mkdir: 悪いアドレス 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知の基底経路、経路TMP 「TMP」の絶対経路を割り当てられませんでした。 tar: ./var/tmp:「volatile/tmp」へのシンプレリックリンクを作成できません:アドレスが悪い 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知のベースパス、パスローカル 「ローカル」に絶対的な経路を割り当てることができませんでした。 tar: ./var/local:Cannot mkdir: 悪いアドレス 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知の基底パス、パスライブラリ 「リベラル」に絶対的な道を割り当てることができませんでした。 tar: ./var/lib:Cannot mkdir: 悪いアドレス 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知の基底パス、パスライブラリ 「リベラル」に絶対的な道を割り当てることができませんでした。 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知の基底パス、パスライブラリ 「リベラル」に絶対的な道を割り当てることができませんでした。 tar: ./var/lib:Cannot mkdir: 悪いアドレス tar: ./var/lib/misc:Cannot mkdir:そのようなファイルやディレクトリは存在しません 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知のベースパス、パスボラタイル 「不安定」に絶対的な経路を割り当てることができなかった。 tar: ./var/volatile:Cannot mkdir: 悪いアドレス 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知のベースパス、パスボラタイル 「不安定」に絶対的な経路を割り当てることができなかった。 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知のベースパス、パスボラタイル 「不安定」に絶対的な経路を割り当てることができなかった。 tar: ./var/volatile:Cannot mkdir: 悪いアドレス TAR:./VAR/Volatile/TMP:Cannot mkdir:そのようなファイルやディレクトリは存在しません 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知のベースパス、パスボラタイル 「不安定」に絶対的な経路を割り当てることができなかった。 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知のベースパス、パスボラタイル 「不安定」に絶対的な経路を割り当てることができなかった。 tar: ./var/volatile:Cannot mkdir: 悪いアドレス タール:./VAR/揮発性/ログ:Cannot mkdir:そのようなファイルやディレクトリは存在しません 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知の基線経路、経路記録 「log」に絶対パスを割り当てることができませんでした。 tar: ./var/log:'volatile/log'へのシンモリンクを作成できません:アドレスが悪い 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知のベースパス、パスロック 「ロック」の絶対経路を割り当てることができませんでした。 tar: ./var/lock:開けられない:住所が悪い 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知の基底経路、経路スプール 「スプール」の絶対経路を割り当てられませんでした。 tar: ./var/spool:Cannot mkdir: 悪いアドレス 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知の基地経路、経路バックアップ 「バックアップ」に絶対的な経路を割り当てることができませんでした。 tar: ./var/backups:Cannot mkdir: 悪いアドレス 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知の基地経路、経路走行 「走る」ための絶対的な経路を割り当てられなかった。 tar: ./var/run:開けられない:住所が悪い 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知のベースパス、パスNSswitch.conf 'nsswitch.conf' の絶対パスを割り当てられませんでした。 tar: ./etc/nsswitch.conf:開けられない:住所が悪い 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知のベースパス、パスホスト 「ホスト」に絶対的な経路を割り当てることができませんでした。 tar: ./etc/hosts:開けられない:住所が悪い 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知の基地経路、経路 issue.net 'issue.net' の絶対パスを割り当てられませんでした。 tar: ./etc/issue.net:開けられない:住所が悪い 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知の基線パス、パスプロファイル 「プロファイル」の絶対パスを割り当てられませんでした。 tar: ./etc/profile:開けられない:住所が悪い 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知のベースパス、パスデフォルト 「デフォルト」の絶対パスを割り当てられませんでした。 tar: ./etc/default:Cannot mkdir: 悪いアドレス 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知のベースパス、パスの問題 「問題」の絶対的な経路を割り当てることができませんでした。 tar: ./etc/issue:開けられない:住所が悪い 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知のベースパス、パススケル 「スケル」に絶対的な経路を割り当てることができませんでした。 tar: ./etc/skel:Cannot mkdir: 悪いアドレス 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知のベースパス、パススケル 「スケル」に絶対的な経路を割り当てることができませんでした。 不明なディレクトリ、fd 4 に対して *at() システムコールが呼び出されました fd 4 の不明なベースパス、パススケルトン 'skel' の絶対パスを割り当てられませんでした。 tar: ./etc/skel:Cannot mkdir: 悪いアドレス tar: ./etc/skel/.profile:開けられない:そのようなファイルやディレクトリは存在しません 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知のベースパス、パススケル 「スケル」に絶対的な経路を割り当てることができませんでした。 不明なディレクトリ、fd 4 に対して *at() システムコールが呼び出されました fd 4 の不明なベースパス、パススケルトン 'skel' の絶対パスを割り当てられませんでした。 tar: ./etc/skel:Cannot mkdir: 悪いアドレス tar: ./etc/skel/.bashrc:開けられない:そのようなファイルやディレクトリは存在しません 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知のベースパス、パスMTAB 「MTAB」の絶対経路を割り当てることができませんでした。 tar: ./etc/mtab:開けられない:住所が悪い 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知のベースパス、パスホスト名 「ホスト名」に絶対パスを割り当てられませんでした。 tar: ./etc/hostname:開けられない:住所が悪い 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知のベースパス、パスFSTAB 「FSTAB」の絶対パスを割り当てることができませんでした。 tar: ./etc/fstab:開けられない:住所が悪い 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知の基底経路、パスシェル 「砲弾」に絶対経路を割り当てることができませんでした。 tar: ./etc/shells:開けられない:住所が悪い 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知のベースパス、パスhost.conf 'host.conf' の絶対パスを割り当てられませんでした。 tar: ./etc/host.conf: 開けられない: アドレスが悪い 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知の基道、パスMODT 『MODD』の絶対的な経路を割り当てることができませんでした。 tar: ./etc/motd:開けられない:住所が悪い tar:過去のエラーにより故障状態で退出 エラー:失敗ログファイルは以下のフォルダに保存されています:/home/vmc/Desktop/imx-yocto-bsp/build-wayland/tmp/work/imx8mqevk-poky-linux/base-files/3.0.14/temp/log.do_package.1734591 エラー:タスク(/ホーム/vmc/Desktop/imx-yocto-bsp/sources/poky/meta/recipes-core/base-files/base-files_3.0.14.bb:do_package)が終了コード「1」で失敗しました Re: base-files error when build the yocto linux ありがとう。起動しました Re: base-files error when build the yocto linux Ubuntu PCで、「sudo apt install tar=1.34+dfsg-1build3」コマンドを実行してください。