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: mayliu1_0-1783917944104.png 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ベースボード設計に関する疑問 mrnobody_0-1784709346702.png これは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コードによると: mayliu1_0-1783917944104.png 複数のデバイスから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」コマンドを実行してください。

对 i.MX95 EVK 底板设计存在疑问 mrnobody_0-1784709346702.png 这是imx95板12V电源输入的原理图，我对这个设计有一些疑问…… 1. 为什么两个 20A 的熔丝要并联？是为了达到 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，因此使用 2 个额定电流为 20A 的小尺寸（1206）熔丝来提供更高的电流额定值是一种经济有效的好做法。 Q2.当 Q2 关闭时，其栅极引脚不会浮空，而是通过 100K 欧姆电阻 (R197) 上拉至与其源极引脚相同的电源轨，以便将其完全关闭。 Re: Doubt regarding i.MX95 EVK base board design 如果能找到额定电流为 40A 的小尺寸熔丝，就可以用它替换掉原来的 2 个 20A 熔丝。如果不需要熔丝保护，也可以将熔丝短路。

Doubt regarding i.MX95 EVK base board design mrnobody_0-1784709346702.png This is the schematic of how 12v power input is taken into the imx95 board, i have some doubts regarding this design... 1. why are 2 fuses of 20A connected in parallel, is it done for 40A current rating, is it a good practice to do so? 2. When Q2 is "on" the gate of Q2 is connected to GND, but for turning "off" Q2, the gate is just left in floating state, Is it reliable to do so? should the gate pin be pulled up to source voltage? Re: Doubt regarding i.MX95 EVK base board design why not use a 40A fuse, is it bcos of size constrains Re: Doubt regarding i.MX95 EVK base board design Q1. Since the inrush current is higher than 20A, it is a good practice to use 2 pcs of fuses with 20A rating in small size (1206) to provide higher current rating cost-effectively. Q2. When Q2 is off, its Gate pin is not left floating, but pulled up to the same power rail as its Source pin with 100KOhms resistor (R197) so that it can be turned off completely. Re: Doubt regarding i.MX95 EVK base board design If 40A rating small size fuse could be be sourced, the  2pcs 20A fuses could be replaced with it. If fuse protection is not necessary, the fuses can be shorted as well.

PN7160A 和 linux_libnfc-nci 在 Raspberry Pi 5 2026 64 位 Trixie 系统上运行 你好， 我正在尝试为工作项目启动 PN7160A，但始终无法让 linux_libnfc-nci 正常工作。该补丁已过时，lgpiod 在版本 2 中进行了全面改进。 还需要使用标志 sudo make install CFLAGS="-Wno-error=implicit-function-declaration" " 否则我就会 "demoapp/main.c:在函数“onMessageReceived”中： demoapp/main.c:451:5:错误：隐式声明函数“PrintNDEFContent” [-Wimplicit-function-declaration] 451 | PrintNDEFContent(NULL, NULL, message, length); 我找到了 2025 年关于 PN7150 的一篇旧帖子，但是当我尝试编译时，我遇到了奇怪的错误，例如“uint8_t”未在作用域中声明，请使用 。我的树莓派操作系统是最新的Trixie Debian 13.6。 需要一些帮助，谢谢。 Re: PN7160A and linux_libnfc-nci on Raspberry Pi 5 2026 64-bit Trixie 你好@paulwitulski 请将补丁作为附件应用。

NXP iMX8MP: U-Boot内のWFIベースのCPUアイドル状態が復帰しない 親愛なるNXPサポートチームへ、 私たちはi.MX8M Plusベースの製品向けにU-Bootの低消費電力待機メカニズムを調査しており、NXPからの指導を歓迎する段階に達しています。 ソフトウェアのバージョン SoC: NXP i.MX8M Plus BSP: ATF: lf_v2.10_android-15.0.0_1.2.0 U-Boot: lf_v2024.04_android-15.0.0_1.2.0 公開されているNXP BSPに基づいています（Varisciteフォークには、ATF/GICコードパスに関する重要な変更は含まれていません）。 ゴール アプリはAndroidを起動する前に、バッテリーが完全に放電された状態で数分間U-Bootに留まっている必要があります。 mdelay()に基づくビジーループは不必要な電力を消費し、追加の熱を発生させるため、ARMジェネリックタイマー(CNTP, PPI 30)を使って定期的に低消費電力のアイドル状態とウェイクに入ろうとしています。 初期実装 CNTPタイマーの設定 PPI 30を有効にする EL2から生のwfi()を実行する プロセッサはwfi()から決して起動しません。UARTの出力は、例外やクラッシュもなく、単に停止するだけです。 PSCIの実装 PSCI_VERSIONは1.1を返します。 PSCI_FEATURES(CPU_SUSPEND) は 0 を返します (サポートされています) CPU_SUSPENDを呼び出してスタンバイ電源状態を要求します これにより、ATFスタンバイ実装であるimx_cpu_standby()に到達しますが、システムは全く同じようにハングアップします。例外も発生せず、UART出力もなく、実行は再開されません。 したがって、両方とも： EL2で実行されたraw wfi() wfi() は ATF を介して PSCI で実行されます 全く同じ動作を生み出す。 既に検証済みのもの CPUとタイマー U-BootはEL2上で実行されます。 CNTPタイマーは正しくプログラムされています。 CNTP_TVAL_EL0 は正しくカウントダウンします。 CNTP_CTL_EL0 には以下が表示されます。 有効 = 1 IMASK = 0 武装直後のISTATUSは0です。 CPUインターフェース ICC_PMR_EL1は正しく設定されています。 ICC_IGRPEN1_EL1が有効になっています。 仮想化 HCR_EL2には以下が含まれます： IMO = 0 FMO = 0 したがって、EL2仮想化による割り込みルーティングは関与しません。 割り込みセキュリティ分類 ATFの情報筋から以下のことを確認しました。 すべてのPPIは、汎用GICv3ヘルパーコードによって最初にグループ1非セキュアとして設定されます。 SGI8 (およびオプションで SDEI SGI) のみがセキュアとして再構成されます。 PPI 30 はセキュア割り込みプロパティテーブルに存在しません。 したがって、Generic Timer 割り込みは予想通りグループ1非安全のままのままです。 SCR_EL3.TWE 当初、非セキュアな wfi() が SCR_EL3.TWE を介して EL3 にトラップされるのではないかと疑っていましたが、wfi() が PSCI を介して ATF 自体の中で実行された場合にも同じ動作が発生するため、これは可能性が低いと思われます。 追加調査 ATFのGIC初期化を追跡していると、gicv3_distif_init()がDistributor EnableGrpビットをクリアし、セキュア割り込みプロパティテーブルで要求されたビットのみを再有効化していることに気付きました。 ヘルパーは Group0 と Group1 の Secure プロパティのみを生成するため、EnableGrp1NS が明示的に再度有効になることはないようです。 これを検証するために、我々は以下のことを行いました。 GICD_CTLR を読み込む EnableGrp1NS = 0 を観測しました EL2からEnableGrp1NSを独自に設定しようと試みました。 意外なことに： 書き込みは問題なく完了します。 RWPは正常に動作します。 しかし、読み戻し後もEnableGrp1NSは0のままです。 また、以下の点も確認しました。 GICD_CTLR.DS == 0 GICメモリ領域に対するRDC保護は無効になっています（ENA = 0）。 RDC違反記録はゼロのままです。 したがって、RDCは書き込みを妨げていないようです。 残りの疑問 現時点で、以下の項目を除外しました。 タイマープログラミング、 CPUインターフェース構成、 割り込み優先度マスキング、 割り込みグループ分類、 SCR_EL3.TWE トラッピング、 PSCIと生のWFI実行の比較、 RDC保護。 残された説明のつかない挙動は、アーキテクチャ的に非安全な書き込み可能なディストリビュータ制御ビット(EnableGrp1NS)がこのプラットフォーム上で書き込みを受け入れていないようで、その結果、生のwfi()もPSCIもGeneric Timer割り込みで起動CPU_SUSPENDしないことです。 この動作はi.MX8M Plus Android 15 BSPで予想されるのでしょうか? 汎用タイマーPPIがwfi()からCPUを起動させるために、公開ATFソース以外でプラットフォーム固有の初期化が欠けているのでしょうか? EnableGrp1NSは、このプラットフォーム上で安全でないソフトウェアによる変更を意図的に防いでいるのでしょうか? U-Bootから定期的にウェイクアップする機能を、以下のいずれかの方法で実装することに成功した人はいますか？ 生のwfi()、または PSCI CPU_SUSPEND ARMのジェネリックタイマーで動かされているのか? 初期化シーケンスやプラットフォーム固有の動作についてのご意見をいただけると大変ありがたいです。 よろしくお願いします。 よろしくお願いいたします。 桟橋

ls1021a eTSEC 送信タイムアウト 私はLS1021A IoTと、このCPUをベースにしたプロトタイプ基板を持っています。どちらの場合も、弊社独自のブートローダーを使用しています。 IOTボードでは完璧に動作しますが、私のボードではイーサネットポートで送信タイムアウトが発生します。数回のpingが送信され、その後送信タイムアウトが発生し、さらにpingが送信されます。このため、TFTPはほとんど利用できません。 もちろん、ハードウェアの違いはあります。私たちのMACはBCM54616Sに接続され、その後LAN9514に接続されています。自動交渉の上限は100FDです。ループバックモードでもTXタイムアウトが発生します。 データを送信するためには、ボードのTBI PHYでビットSGMII_ANビットを設定しなければなりませんでしたが、IOTでは不要でした(IOTは1000FDで交渉可能です)。 なぜTXがこんなに断続的に起こるのか分かりません。この速度制限と関係があるのでしょうか? Re: ls1021a eTSEC tx timeout こんにちは、 100FD SGMIIの場合、プロトタイプ基板上のブートローダーで以下の項目を確認してください。 LS1021AのeTSECをSGMII 100Mbpsに設定する ECNTRL[TBIM] = 1 ECNTRL[SGMIIM] = 1 ECNTRL[R100M] = 1 MACCFG2[I/F Mode] = 01 （10/100モードの場合） LS1021Aのリファレンスマニュアルには、SGMII 100Mbpsの場合、 R100M = 1 設定することが明記されています。 内部のTBI PHYをリセットしプログラムするRMは、SGMIIがTBIレジスタセットを使用していること、そしてSGMIIを含むすべてのインターフェースモードでTBIをリセットすることが重要であると述べています。 SGMII_AN ビットは設定したままにしてください。TBI の SGMII_AN ビットは「1 に設定する必要があります」と記載されています。このビットを設定した後にしか基板が送信しないのは驚くことではありません。このPHY/MACモードのブートローダー初期化が不完全であることを示唆しています。 100 Mbps での 1G スタイルの SGMII AN 動作に頼らないでください。LS1021A では、100 Mbps SGMII 動作時に「SGMII リンクが正常ではありません」というメッセージが表示されたり、リンクのサイクル後に断続的にパケットが送信されないという報告が知られていますが、1G 動作では問題ありません。それは、あなたのTXタイムアウトの正確な根本原因を証明するものではありませんが、100FD SGMIIの設定が有力な容疑者であることを示唆しています。 ループバックの結果が重要です。もし「ループバックモード」が外部PHYループバックやSGMII側ループバックであれば、100FDのSGMII/TBIセットアップは関与可能です。内部MAC/eTSECループバックの場合、外部BCM54616S/LAN9514パスはほとんど関係ないので、eTSECの初期化、ディスクリプタリングの処理、キャッシュの一貫性、およびTXの停止/エラー状態に焦点を当てます。 デバッグを行うには、タイムアウトが発生したときにeTSEC TXの停止状態を確認してください。RMは、eTSECがTxBDリングからの送信フレームを処理しなくなったときに送信停止ビットを設定すると述べています。繰り返し可能な原因には、バスエラー、無効なBD/データアドレス、修正不能なBD/データ読み取りエラー、長さ 0 の Ready = 1 などのTxBDプログラミングエラーなどがあります。また、見ているかどうかも確認してください IEVENT_BSY ;NXPの資料では、BSYはバッファ不足やソフトウェアがBDリングに十分速く対応できないことによるRXフレームのドロップと説明されており、これは純粋なSGMIIの電気的症状ではなくソフトウェア/BDリングの症状です。 推奨される分離シーケンス: 1. 必要に 応じて、 外部 PHY を 100FD に 強制し 、 銅線に対する自動ネゴシエーションを無効にします 。2. LS1021Aの MAC / eTSEC を SGMII 100Mbps に 強制的に設定する ： TBIM = 1 、 SGMIIM = 1 、 R100M = 1 、 MACCFG2 I / F モード = 10 / 100。3. SGMII モードを設定した後、 TBIを リセット / 再初期化します 。4. TBI SGMII_AN = 1 に設定します 。 5. TBI リンク / AN ステータス 、 eTSEC ECNTRL / MACCFG2 、 および PHY SGMII 側 ステータス を確認します 。6.タイムアウト時に、 IEVENT 、 TXハルトレジスタ、 DMAステータス、およびTXBDリングの内容をダンプします。 敬具 Re: ls1021a eTSEC tx timeout 言い忘れていましたが、私のポートはSGMIIモードに設定されています。 Re: ls1021a eTSEC tx timeout こんにちは、 詳細な調査結果をありがとうございます。ご指摘いただいた回避策（1ミリ秒の遅延、手動によるDMAフラッシュ、 dma-coherent 削除）の組み合わせは、キャッシュエイリアスの問題の典型的なパターンです。以下に、根本原因の説明と推奨される解決方法を示します。 根本原因：TX記述子領域上のキャッシュされた仮想エイリアス LS1021A ENET DMAはキャッシュ整合性のないバス・マスタであり、CPUキャッシュの可視性を持たずにDDRを直接読み込みます。LS1021A上のgianfarの正しい運用モデルは、非コヒーレントなソフトウェア管理モデルです。すなわち、ディスクリプタをキャッシュされていないメモリに割り当て、CPUがディスクリプタフィールドを更新するたびに明示的な dma_sync_* 呼び出しを行います。 LPAEの変更によって最も可能性が高いのは、記述子の物理アドレス範囲のページテーブルエントリに、誤ったキャッシュ属性（デバイスまたは通常のキャッシュ不可ではなく、通常のライトバック）が付与されたことです。これにより、同じ物理メモリに対して異なるキャッシュ性を持つ2つの仮想エイリアスが作成されます。割り当てパス( dma_alloc_noncoherent 経由)はキャッシュされていない状態をマッピングしますが、send関数のパケットごとのTXディスクリプタ更新パスはキャッシュされたエイリアス経由でアクセスします。CPUは更新されたディスクリプタフィールドをキャッシュラインに書き込みますが、それらはDDRに到達せず、ENET DMAは古いデータを読み取ってアンダーランを起こします。 なぜあなたの３つの回避策はすべて同じ欠陥を隠蔽しているのか 1 ms遅延/メッセージ挿入:低負荷時にCPU書き込みバッファが自然に消耗する十分なレイテンシを追加します。タイミング依存で、トラフィックや周波数の変化により故障します。 send 関数で dma_flush 手動で指定すると、DMA がディスクリプタを読み取る前に、PoC へのキャッシュのクリーンアップが強制されます。これは正しい動作ですが、領域が実際にキャッシュされていない場合は不要です。 enet デバイス ノードから dma-coherent 削除すると、カーネルは送信前に各 TX ディスクリプタに対して dma_map_single() / dma_sync_single_for_device() を呼び出し、明示的にキャッシュをクリアします。これも正しく、LS1021A-IOT が送信パスのフラッシュなしで確実に動作した理由を説明しています。 送信パスのフラッシュがないことが、欠けている要素です。LS1021A-IOTは dma-coherent 削除しても動作しました。これは、カーネルのDMAマッピングレイヤーが同期を自動的に挿入したためです。一方、プロトタイプにはそのパスがありません。LPAEの変更により、同期を再導入することなく記述子領域のキャッシュ属性が変更されたためです。 DDR3LとDDR4/周波数の違い これは根本原因ではありません。異なるDRAMの種類や周波数が書き込みレイテンシやバッファのドレインタイミングを変えるため、プロトタイプでは故障がより目立つのですが、根本的な欠陥はアーキテクチャ的なもので、十分な負荷がかかると両方の基板に存在します。 推奨される修正方法 正しく、かつ矛盾のない解決策は、以下の2つを組み合わせることです。 enetデバイスノードから dma-coherent 離しておきましょう(非コヒーレントモデル)。これにより、カーネルDMAレイヤーは、 dma_alloc_noncoherent を介して割り当てられたディスクリプタのDMA所有権が転送される前に、 dma_sync_single_for_device() 自動的に発行します。 TX 送信パスにおいて、各パケットに TX 記述子フィールド ( status 、 data_length 、 data_pointer ) が書き込まれる箇所に、明示的な dma_sync_single_for_device() 呼び出しを追加します。これは手動で追加したフラッシュですが、 TDAR を書く前に正式には dma_sync_single_for_device(dev, desc_dma_addr, sizeof(txbd), DMA_TO_DEVICE) として配置する必要があります。これにより、MMUがディスクリプタ領域をどのように属性付けしても、モデルは明示的かつ正確になります。 別途、ENET記述子に使用される物理アドレス範囲に割り当てられた AttrIndx / TEX+C+B フィールドについて、LPAE MMUライブラリの変更を監査します。ディスクリプタプールは、Device-nGnRnE（厳密な順序付け）またはNormal Non-cacheableとしてマッピングする必要があります。Normal Writebackは使用しないでください。カーネルの ptdump デバッグインターフェースで、割り当て後にディスクリプタプールの仮想アドレスを確認することで、実際に使われている属性を検証できます。 あなたが追加したDMAフラッシュは回避策ではなく、正しい仕組みです。本当の欠陥は、そもそも送信パスにそれが存在していなかったことであり、LPAEの変更によってその領域の実効的なキャッシュ可能性が変わったため、この欠陥が露呈した。   よろしくお願いします。 Re: ls1021a eTSEC tx timeout 送信機能にメッセージを追加したり、1ミリ秒の遅延を設けたりすることで、データの損失なく正しく転送することが可能になります。 送信関数内のTXディスクリプタにDMAフラッシュを追加したところ、改善されました。ただし、ディスクリプタはキャッシュされていないメモリに割り当てられるため、これは必要ないはずです。LPAEサポートを追加したMMUライブラリの欠陥かもしれません。 そういえば、ずいぶん前にenetデバイスノードのdma-coherentプロパティを削除したところ、LS1021A-IOTが動作するようになったことを思い出しました。これは、ディスクリプタ用にキャッシュされていないメモリを割り当てながら、DMAフラッシュを強制的に実行します。しかし、送信関数には、各パケットのTX記述子を更新するキャッシュフラッシュ機能がありませんでした。なぜ私のプロトタイプでは動作しないのか分かりません(周波数の違い、DDR3LとDDR4の違い,...)

PN7221 fails to detect ISO 14443-3B We ported PN7221 in accordance with the document AN14880 PN7160/PN7220 - Android 16 porting guide. During testing, ISO 14443-3B (NfcB) cards cannot be detected. Moreover, after tapping such a card, the NFC function malfunctions and fails to recognize any cards. It is necessary to toggle NFC off and on again to restore normal operation. Relevant logs are attached below for your analysis. ❯ 07-16 09:24:28.515 530 6384 D NxpTml : PN72xx - I2C Read successful..... 07-16 09:24:28.515 530 6384 D NxpNciR : len = 26 > 61051701010001FF010C0B00000000D103860500808001000000 07-16 09:24:28.515 530 6384 D NxpTml : PN72xx - Posting read message..... 07-16 09:24:28.516 530 6387 D NxpHal : read successful status = 0x0 07-16 09:24:28.516 530 6387 D NxpHal : NxpNci: RF Interface = Frame RF 07-16 09:24:28.516 530 6387 D NxpHal : NxpNci: Protocol = Unknown 07-16 09:24:28.516 530 6387 D NxpHal : NxpNci: Mode = B Passive Poll 07-16 09:24:28.516 530 6387 D NxpHal : NCI NTF: RF_DEACTIVATED len=26 type=1 07-16 09:24:28.517 530 6384 D NxpTml : PN72xx - Read requested..... 07-16 09:24:28.517 530 6384 D NxpTml : PN72xx - Invoking I2C Read..... 07-16 09:24:28.517 1599 6381 D libnfc_nci: rw_t4t_send_to_lower: conn_id sent to lower =0 07-16 09:24:28.517 530 542 I android.hardware.nfc2-service.nxp: write 07-16 09:24:28.517 530 6385 D NxpTml : PN72xx - Write requested..... 07-16 09:24:28.517 530 6385 D NxpTml : PN72xx - Invoking I2C Write..... 07-16 09:24:28.519 530 6385 D NxpNciX : len = 12 > 0000091D0000000000080100 07-16 09:24:28.519 530 6385 D NxpTml : PN72xx - I2C Write successful..... 07-16 09:24:28.519 530 6385 D NxpTml : PN72xx - Posting Fresh Write message..... 07-16 09:24:28.519 530 6385 D NxpTml : PN72xx - Tml Writer Thread Running................ 07-16 09:24:28.519 530 6387 D NxpHal : write successful status = 0x0 07-16 09:24:28.520 530 6384 D NxpTml : PN72xx - I2C Read successful..... 07-16 09:24:28.520 530 6384 D NxpNciR : len = 6 > 600603010001 07-16 09:24:28.520 530 6384 D NxpTml : PN72xx - Posting read message..... 07-16 09:24:28.521 530 6387 D NxpHal : read successful status = 0x0 07-16 09:24:28.521 530 6387 D NxpHal : NCI NTF: CORE_GENERIC_ERROR len=6 07-16 09:24:28.521 530 6384 D NxpTml : PN72xx - Read requested..... 07-16 09:24:28.521 530 6384 D NxpTml : PN72xx - Invoking I2C Read..... 07-16 09:24:28.523 530 6384 D NxpTml : PN72xx - I2C Read successful..... 07-16 09:24:28.523 530 6384 D NxpNciR : len = 5 > 0000020000 07-16 09:24:28.523 530 6384 D NxpTml : PN72xx - Posting read message..... 07-16 09:24:28.523 530 6387 D NxpHal : read successful status = 0x0 07-16 09:24:28.524 1599 6381 I libnfc_nci: rw_t3Bt_sm_get_id (): sub_state:WAIT_ENDEF_FILE_CTRL_TLV (17) 07-16 09:24:28.524 1599 6381 D libnfc_nci: rw_t4t_send_to_lower: conn_id sent to lower =0 07-16 09:24:28.524 530 542 I android.hardware.nfc2-service.nxp: write 07-16 09:24:28.524 530 6385 D NxpTml : PN72xx - Write requested..... 07-16 09:24:28.524 530 6385 D NxpTml : PN72xx - Invoking I2C Write..... 07-16 09:24:28.524 530 6384 D NxpTml : PN72xx - Read requested..... 07-16 09:24:28.524 530 6384 D NxpTml : PN72xx - Invoking I2C Read..... 07-16 09:24:28.525 530 6385 D NxpNciX : len = 8 > 0000050036000008 07-16 09:24:28.525 530 6385 D NxpTml : PN72xx - I2C Write successful..... 07-16 09:24:28.525 530 6385 D NxpTml : PN72xx - Posting Fresh Write message..... 07-16 09:24:28.525 530 6385 D NxpTml : PN72xx - Tml Writer Thread Running................ 07-16 09:24:28.525 530 6387 D NxpHal : write successful status = 0x0 07-16 09:24:28.527 530 6384 D NxpTml : PN72xx - I2C Read successful..... 07-16 09:24:28.527 530 6384 D NxpNciR : len = 6 > 600603010001 07-16 09:24:28.528 530 6384 D NxpTml : PN72xx - Posting read message..... 07-16 09:24:28.528 530 6387 D NxpHal : read successful status = 0x0 07-16 09:24:28.528 530 6387 D NxpHal : NCI NTF: CORE_GENERIC_ERROR len=6 07-16 09:24:28.530 530 6384 D NxpTml : PN72xx - Read requested..... 07-16 09:24:28.530 530 6384 D NxpTml : PN72xx - Invoking I2C Read..... 07-16 09:24:28.531 530 6384 D NxpTml : PN72xx - I2C Read successful..... 07-16 09:24:28.532 530 6384 D NxpNciR : len = 14 > 00000B21CBA4729CB97166900000 07-16 09:24:28.532 530 6384 D NxpTml : PN72xx - Posting read message..... 07-16 09:24:28.532 530 6387 D NxpHal : read successful status = 0x0 07-16 09:24:28.533 1599 6381 I libnfc_nci: rw_t3Bt_sm_get_id (): sub_state:???? UNKNOWN SUBSTATE (18) 07-16 09:24:28.533 1599 6381 I libnfc_nci: nfa_rw_update_pupi_id: 07-16 09:24:28.534 530 6384 D NxpTml : PN72xx - Read requested..... 07-16 09:24:28.534 530 6384 D NxpTml : PN72xx - Invoking I2C Read..... Re: PN7221 fails to detect ISO 14443-3B We've upgraded to version 3.2.5, but the test results remain unchanged. 07-17 01:13:52.157 533 542 D NxpHal : FW version found on the device = 0x30205 Re: PN7221 fails to detect ISO 14443-3B Hello @zhangkai  Please update to 3.2.5, you can get the FW file by going: nfc-NXPNFCC_FW/InfraFW/pn7220 at master · NXP/nfc-NXPNFCC_FW Re: PN7221 fails to detect ISO 14443-3B 06-24 10:20:33.259 390 401 D NxpHal : FW version found on the device = 0x302c4 Re: PN7221 fails to detect ISO 14443-3B Hello @zhangkai  which is the version of FW? if it low 3.2.5, please update to the newest, and test again. If still has question, please provide full log to us. Re: PN7221 fails to detect ISO 14443-3B Hello @zhangkai  Could you provide libnfc-nci.conf and libnfc-nxp.conf files? Re: PN7221 fails to detect ISO 14443-3B Hello @zhangkai This issue may be related to the changes in A16. Specifically: Prior to A15, NXP's mobile MWs relied on NFA_PROTOCOL_T3BT(80) to support ID cards, but A16 has directly included Chinese ID cards in its support scope through Google. However, the PN7xxx MWs still retain this code. Therefore, customers are trying to completely remove the T3BT logic from the PN7xxx MWs and directly use Google's native logic. KaiLi_0-1784790560099.png Re: PN7221 fails to detect ISO 14443-3B The configuration file has been uploaded.

flex-installer「lsdk2606」バージョンを使用している「imx95-15x15-frdm」Debianで「Weston.Service」に問題が発生しました。 こんにちは、 flex-installerバージョン「 lsdk2606 」を使用してDebianイメージをインストールしました。 ネタバレ （ハイライトして読む） Sudo Flex-installer -I auto -d /dev/sdX -m imx95-15x15-frdm Sudo Flex-installer -I auto -d /dev/sdX -m imx95-15x15-frdm 私のimx95-15x15-frdmでは その後、標準の手順に従ってインストールを続行しました。 ネタバレ （ハイライトして読む） debian-post-install-pkg debian-post-install-pkg すべてのパッケージをインストールし再起動した後、起動時に以下のエラーが発生しました: ネタバレ （ハイライトして読む） [失敗] weston.service - W…nd コンポジターをシステムサービスとして起動できませんでした。 [失敗] weston.service - W…nd コンポジターをシステムサービスとして起動できませんでした。 ネタバレ （ハイライトして読む） root@imx95-15x15-frdm:~# systemctl status weston.service × weston.service - システムサービスとしてのWaylandコンポジタであるWeston ロード済み: ロード済み (/usr/lib/systemd/system/weston.service;有効; プリセット: 有効) アクティブ: 失敗 (結果: 終了コード) 2026年7月20日(月) 13:51:20 UTC以降; 19秒前 呼び出し: 67b22b0fa1484ce681d8b2acdc107add トリガー: ● weston.socket ドキュメント: man:weston(1) man:weston.ini(5) http://wayland.freedesktop.org/ プロセス: 408 ExecStart=/usr/bin/weston --log=${XDG_RUNTIME_DIR}/weston.log --modules=systemd-notify.so (code=exited, status=1/FAILURE) メインPID: 408 (コード=終了、ステータス=1/失敗) メモリピーク：3.5M CPU: 49ms 7月20日 13:51:19 imx95-15x15-frdm systemd[1]: weston.service - WaylandコンポジタであるWestonをシステムサービスとして開始します... 7月20日 13:51:19 imx95-15x15-frdm (weston)[408]: pam_unix(weston-autologin:session): user root(uid=0) by (uid=0) がセッションを開きました 7月20日 13:51:20 imx95-15x15-frdm systemd[1]: weston.service:メインプロセスが終了しました。終了コード=exited、ステータス=1/FAILURE 7月20日 13:51:20 imx95-15x15-frdm systemd[1]: weston.service:結果「exit-code」で失敗しました。 7月20日 13:51:20 imx95-15x15-frdm systemd[1]: weston.service - WaylandコンポジタであるWestonをシステムサービスとして起動できませんでした。 root@imx95-15x15-frdm:~# systemctl status weston.service×weston.service - Wayland コンポジタである Weston をシステム サービスとしてロードしました: ロード済み (/usr/lib/systemd/system/weston.service;有効; プリセット: 有効) アクティブ: 失敗 (結果: 終了コード) 2026年7月20日(月) 13:51:20 UTC以降; 19秒前 呼び出し: 67b22b0fa1484ce681d8b2acdc107add トリガー: ● weston.socketドキュメント: man:weston(1) man:weston.ini(5) http://wayland.freedesktop.org/プロセス:408 ExecStart=/usr/bin/weston --log=${XDG_RUNTIME_DIR}/weston.log --modules=systemd-notify.so (code=exited, status=1/FAILURE) メインPID: 408 (code=exited, status=1/FAILURE) メモリピーク:3.5M CPU: 49ms 7月20日 13:51:19 imx95-15x15-frdm systemd[1]: weston.service - Weston、Waylandコンポジター、システムサービスとして...7月20日 13:51:19 imx95-15x15-frdm (weston)[408]: pam_unix(weston-autologin:session): ユーザーroot(uid=0) by (uid=0) がユーザーroot(uid=0)のためにセッションを開きました by (uid=0) 7月20日 13:51:20 imx95-15x15-frdm systemd[1]: weston.service:メインプロセスが終了しました。コード=exited、ステータス=1/FAILURE 7月20日 13:51:20 imx95-15x15-frdm systemd[1]: weston.service:結果「exit-code」で失敗しました。Jul 20 13:51:20 imx95-15x15-frdm systemd[1]: weston.service - Wayland コンポジタである Weston をシステム サービスとして起動できませんでした。 ネタバレ （ハイライトして読む） root@imx95-15x15-frdm:~# cat /run/user/0/weston.log 日付: 2026年7月20日 UTC [12:34:22.150]ウェストン 14.0.2 https://wayland.freedesktop.org バグ報告先： https://gitlab.freedesktop.org/wayland/weston/issues/ ビルド: LSDK-25.12_DEBIAN-13_LF-6.12.20-168-g2ddc741+ [12:34:22.153]コマンドライン: /usr/bin/weston --log=/run/user/0/weston.log --modules=systemd-notify.so [12:34:22.153]OS: Linux、6.12.49、#5 SMP PREEMPT 2026年5月28日木曜日 13:07:26 KST、aarch64 [12:34:22.153]フライトレコーダー：有効 [12:34:22.155]設定ファイル「/etc/xdg/weston/weston.ini」を使用します。 [12:34:22.156]出力再描画ウィンドウの最大時間は16ミリ秒です。 [12:34:22.158]モジュールの読み込み '/usr/lib/libweston-14/drm-backend.so' [12:34:22.162]モジュールの読み込みに失敗:libdisplay-info.so.1:共有オブジェクトファイルを開けません:そのようなファイルやディレクトリはありません [12:34:22.162]致命的エラー: コンポジターバックエンドの作成に失敗しました root@imx95-15x15-frdm:~# cat /run/user/0/weston.logDate:2026年7月20日 UTC[12:34:22.150]weston 14.0.2https://wayland.freedesktop.orgバグは https://gitlab.freedesktop.org/wayland/weston/issues/Build に報告します。LSDK-25.12_DEBIAN-13_LF-6.12.20-168-g2ddc741+[12:34:22.153]コマンドライン: /usr/bin/weston --log=/run/user/0/weston.log --modules=systemd-notify.so[12:34:22.153]OS: Linux, 6.12.49, #5 SMP PREEMPT 2026年5月28日(木) 13:07:26 KST, aarch64[12:34:22.153]フライトレコーダー：有効[12:34:22.155]設定ファイル「/etc/xdg/weston/weston.ini」を使用しています[12:34:22.156]出力再描画ウィンドウの最大時間は16ミリ秒です。[12:34:22.158]モジュールの読み込み '/usr/lib/libweston-14/drm-backend.so'[12:34:22.162]モジュールの読み込みに失敗しました: libdisplay-info.so.1: 共有オブジェクトファイルを開けません: そのようなファイルやディレクトリはありません[12:34:22.162]致命的エラー: コンポジターバックエンドの作成に失敗しました 私も同じエラーが出ています（関連があるかどうかはわかりませんが）、でも画面には何も表示されません。 ネタバレ （ハイライトして読む） it6263 3-004c: DDC FIFOのクリアに失敗しました it6263 3-004c: EDIDの読み取りに失敗しました it6263 3-004c: DDC FIFOのクリアに失敗しました。it6263 3-004c: EDIDの読み取りに失敗しました。 Re: Issue "Weston.Service" on the "imx95-15x15-frdm" Debian using flex-installe root@imx95-15x15-frdm:~# ldd /usr/lib/libweston-14/drm-backend.so Linux-vdso.so.1 (0x0000ffffac56c000) libweston-14.so.0 => /USR/lib/libweston-14.so.0 (0x0000ffffac410000) libwayland-client.so.0 => /lib/aarch64-Linux-gnu/libwayland-client.so.0 (0x0000ffffac3e0000) libpixman-1.so.0 => /lib/aarch64-linux-gnu/libpixman-1.so.0 (0x0000ffffac330000) libwayland-server.so.0 => /lib/aarch64-linux-gnu/libwayland-server.so.0 (0x0000ffffac2f0000) libdrm.so.2 => /usr/lib/libdrm.so.2 (0x0000ffffac2b0000) libudev.so.1 => /lib/aarch64-linux-gnu/libudev.so.1 (0x0000ffffac250000) libdisplay-info.so.1 => 見つかりません libgbm.so.1 => /usr/lib/libgbm.so.1 (0x0000ffffac220000) libseat.so.1 => /lib/aarch64-linux-gnu/libseat.so.1 (0x0000ffffac1f0000) libinput.so.10 => /lib/aarch64-linux-gnu/libinput.so.10 (0x0000ffffac170000) libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000ffffabfb0000) /lib/ld-linux-aarch64.so.1 (0x0000ffffac520000) libxkbcommon.so.0 => /lib/aarch64-linux-gnu/libxkbcommon.so.0 (0x0000ffffabf40000) libffi.so.8 => /lib/aarch64-linux-gnu/libffi.so.8 (0x0000ffffabf10000) libm.so.6 => /lib/aarch64-linux-gnu/libm.so.6 (0x0000ffffabe60000) libcap.so.2 => /lib/aarch64-linux-gnu/libcap.so.2 (0x0000ffffabe30000) libsystemd.so.0 => /lib/aarch64-linux-gnu/libsystemd.so.0 (0x0000ffffabd00000) Libmtdev.so.1 => /lib/aarch64-linux-gnu/libmtdev.so.1 (0x0000ffffabcd0000) libevdev.so.2 => /lib/aarch64-linux-gnu/libevdev.so.2 (0x0000ffffabc90000) libwacom.so.9 => /lib/aarch64-linux-gnu/libwacom.so.9 (0x0000ffffabc60000) libgudev-1.0.so.0 => /lib/aarch64-linux-gnu/libgudev-1.0.so.0 (0x0000ffffabc30000) libgobject-2.0.so.0 => /lib/aarch64-linux-gnu/libgobject-2.0.so.0 (0x0000ffffabba0000) libglib-2.0.so.0 => /lib/aarch64-linux-gnu/libglib-2.0.so.0 (0x0000ffffaba10000) libatomic.so.1 => /lib/aarch64-linux-gnu/libatomic.so.1 (0x0000ffffab9e0000) libpcre2-8.so.0 => /lib/aarch64-linux-gnu/libpcre2-8.so.0 (0x0000ffffab920000) Re: Issue "Weston.Service" on the "imx95-15x15-frdm" Debian using flex-installe 以下のコマンドを実行して出力を共有してもらえますか? find /usr -name "libdisplay-info*" よろしくお願いします。 Re: Issue "Weston.Service" on the "imx95-15x15-frdm" Debian using flex-installe 最新情報のご提供ありがとうございます。 システム上にはlibdisplay-infoが存在するのがわかりますが、Westonのログはlibdisplay-info.so.1を探しており、インストール済みのライブラリはLibdisplay-info.so.2のようです。 以下のコマンドを実行して出力を共有してもらえますか? ldd /usr/lib/libweston-14/drm-backend.so これにより、ライブラリのバージョン不一致やその他の依存関係の欠落がないかを確認するのに役立ちます。 Re: Issue "Weston.Service" on the "imx95-15x15-frdm" Debian using flex-installe Hello root@imx95-15x15-frdm:~# find /usr -name "libdisplay-info*" /usr/lib/aarch64-linux-gnu/libdisplay-info.so.2 /usr/lib/aarch64-linux-gnu/libdisplay-info.so.0.2.0 /usr/share/doc/libdisplay-info2

Support Request: HD-SDI Interface Using i.MX8M Plus LVDS Output Dear Sir, We are designing a system based on the NXP i.MX8M Plus processor and would like your guidance regarding the implementation of an HD-SDI interface. Our requirement is to support three HD-SDI outputs. We are planning to use the LVDS interface of the i.MX8M Plus and convert it to HD-SDI using the following devices: LMH0340SQE/NOPB – LVDS to HD-SDI Serializer 2 × LMH0324RTWT – 1-to-3 HD-SDI Distribution Amplifiers Could you please confirm whether the LVDS interface of the i.MX8M Plus is compatible with this architecture for generating three HD-SDI outputs? If this approach is not recommended or supported, could you please suggest an alternative solution for implementing three HD-SDI interfaces while continuing to use the i.MX8M Plus processor? We would prefer to retain the i.MX8M Plus in our design, as it satisfies all of our other system requirements. We would appreciate your recommendations and any reference designs or application notes that may help us implement this interface successfully. Thank you for your support. We look forward to your guidance. Best regards, Samudralankaiah Jampani Analog(ADC|CMP|DAC|OpAmps) Board Design MCXA MCXC Re: Support Request: HD-SDI Interface Using i.MX8M Plus LVDS Output Hello, Unfortunately I'm not really used to this kind of use case, as I was investigating the part you have shared it seem that it is expected to use with an FPGA not an LVDS channel, so I'm not sure that you may use this interface for that. Maybe using a different bridge or other of the interfaces in the i.MX8MP or even another layer (FPGA) in between could be a solution. Best regards/Saludos, Aldo.

ls1021a eTSEC tx timeout I have a LS1021A IOT and a prototype board based on this cpu. On both we use our boot loader. It works perfectly in the IOT board but on my board I get TX timeout on the Ethernet port. I get a few pings going and then tx timeout and more pings.  This makes tftp rarely possible. There are hardware difference of course. Our MAC is connected to a BCM54616S then to a LAN9514. The autonegotiation is limited to 100FD. TX timeout also happens in loopback mode. In order to transmit data, I had to set bit SGMII_AN bit in the TBI PHY on my boards while I did not have to on the IOT (IOT can negotiate at 1000FD). Not sure why the TX is so intermittent. Could it be related to this speed limitation? Re: ls1021a eTSEC tx timeout Hello, For 100FD SGMII , verify these items in your boot loader on the prototype board: Set LS1021A eTSEC for SGMII 100 Mbps ECNTRL[TBIM] = 1 ECNTRL[SGMIIM] = 1 ECNTRL[R100M] = 1 MACCFG2[I/F Mode] = 01 for 10/100 mode The LS1021A RM specifically notes setting R100M = 1 for SGMII 100 Mbps. Reset and program the internal TBI PHY The RM states that SGMII uses the TBI register set and that it is important to reset the TBI for all interface modes, including SGMII. Keep SGMII_AN set The TBI SGMII_AN bit is documented as “must be set to 1.” So the fact that your board only transmits after setting this bit is not surprising; it suggests your boot-loader initialization was incomplete for this PHY/MAC mode. Do not rely on 1G-style SGMII AN behavior at 100 Mbps There are known LS1021A reports where 100 Mbps SGMII operation shows “SGMII link is not ok” or intermittent no-packet behavior after link cycling, while 1G operation is clean. That does not prove your exact TX timeout root cause, but it makes 100FD SGMII configuration a strong suspect. The loopback result matters. If your “loopback mode” is external PHY loopback or SGMII-side loopback, the 100FD SGMII/TBI setup can still be involved. If it is internal MAC/eTSEC loopback , then the external BCM54616S/LAN9514 path is mostly out of the picture, and I would focus on eTSEC initialization, descriptor-ring handling, cache coherency, and TX halt/error status. For debugging, check the eTSEC TX halt status when the timeout occurs. The RM says the transmit halt bits are set when eTSEC is no longer processing transmit frames from a TxBD ring; repeatable causes include bus errors, invalid BD/data addresses, uncorrectable BD/data read errors, and TxBD programming errors such as Ready = 1 with length 0 . Also check whether you are seeing IEVENT_BSY ; NXP material describes BSY as dropped RX frames due to lack of buffers/software not servicing the BD ring fast enough, which is a software/BD-ring symptom rather than a pure SGMII electrical symptom. Recommended isolation sequence: 1. Force external PHY to 100FD, no autoneg toward copper if needed. 2. Force LS1021A MAC/eTSEC to SGMII 100 Mbps: TBIM=1, SGMIIM=1, R100M=1, MACCFG2 I/F mode=10/100. 3. Reset/reinitialize TBI after setting SGMII mode. 4. Set TBI SGMII_AN=1. 5. Confirm TBI link/AN status, eTSEC ECNTRL/MACCFG2, and PHY SGMII-side status. 6. On timeout, dump IEVENT, TX halt registers, DMA status, and TXBD ring contents. regards  Re: ls1021a eTSEC tx timeout Forgot to say my port is set for SGMII mode. Re: ls1021a eTSEC tx timeout Adding messages or 1ms delay in the send functions allows the correct transfer of data without loss. I added a DMA flush to the TX descriptors in the send function and this helps. Though, this should not be necessary considering the descriptors are allocated in uncached memory. It could be a defect in the MMU library to which I added LPAE support. Now I remember that a long time ago I removed the dma-coherent property in the enet device node and this was enough for the LS1021A-IOT to work. This is forcing a DMA flush while allocating uncached memory for the descriptors. But there was no cache flush in the send functions which updates the TX descriptors on each packet. Not sure why it does not work on my prototype (difference in frequency, DDR3L vs DDR4,...) Re: ls1021a eTSEC tx timeout Hi, Thank you for the detailed findings — the combination of workarounds you identified (1 ms delay, manual DMA flush, and removing dma-coherent ) is a textbook fingerprint of a cache alias problem. Here is the root cause explanation and the recommended fix path. Root cause: cached virtual alias over the TX descriptor region The LS1021A ENET DMA is a non-cache-coherent bus master — it reads DDR directly, with no visibility into the CPU cache. The correct operating model for gianfar on LS1021A is the non-coherent software-managed model: descriptors allocated in uncached memory, with explicit dma_sync_* calls whenever the CPU updates a descriptor field. What your LPAE changes most likely introduced is a page table entry for the descriptor physical address range that carries the wrong cache attribute — Normal Writeback instead of Device or Normal Non-cacheable. This creates two virtual aliases to the same physical memory with different cacheability: the allocation path (via dma_alloc_noncoherent ) maps it uncached, but the per-packet TX descriptor update path in the send function accesses it through a cached alias. The CPU writes the updated descriptor fields into the cache line, they never reach DDR, and the ENET DMA reads stale data and underruns. Why your three workarounds all mask the same defect 1 ms delay / message insertion: adds enough latency for the CPU writeback buffer to drain naturally under low load — timing-dependent, will fail under traffic or frequency change. Manual dma_flush in the send function: forces a cache clean-to-PoC before the DMA reads the descriptor — correct behaviour, but should not be necessary if the region is genuinely uncached. Removing dma-coherent from the enet device node: causes the kernel to call dma_map_single() / dma_sync_single_for_device() on each TX descriptor before submission, which explicitly cleans the cache — also correct, and explains why the LS1021A-IOT worked reliably without a send-path flush. The absence of the send-path flush is the missing piece. The LS1021A-IOT worked with dma-coherent removed because the kernel's DMA mapping layer inserted the sync automatically; your prototype does not have that path because the LPAE changes altered the descriptor region's cache attributes without re-introducing the sync. DDR3L vs DDR4 / frequency difference This is not the root cause. Different DRAM type and frequency change write latency and buffer drain timing, which is why the failure is more visible on your prototype — but the underlying defect is architectural and will be present on both boards under sufficient load. Recommended fix The correct and self-consistent fix is to combine both of the following: Keep dma-coherent removed from the enet device node (non-coherent model). This causes the kernel DMA layer to issue dma_sync_single_for_device() automatically before DMA ownership is transferred for descriptors allocated via dma_alloc_noncoherent . Add explicit dma_sync_single_for_device() calls in the TX send path at the point where TX descriptor fields ( status , data_length , data_pointer ) are written on each packet. This is the flush you added manually — but it should be formally placed as a dma_sync_single_for_device(dev, desc_dma_addr, sizeof(txbd), DMA_TO_DEVICE) before writing TDAR . This makes the model explicit and correct regardless of how the MMU attributes the descriptor region. Separately, audit the LPAE MMU library change for the AttrIndx / TEX+C+B fields assigned to the physical address range used for ENET descriptors. The descriptor pool should be mapped as Device-nGnRnE (strongly ordered) or Normal Non-cacheable — not Normal Writeback. You can verify the actual attributes in use with the kernel's ptdump debug interface by checking the virtual address of the descriptor pool after allocation. The DMA flush you added is not a workaround — it is the correct mechanism. The real defect is that it was absent from the send path in the first place, and the LPAE changes exposed this because they altered the effective cacheability of the region.   Regards

ls1021a eTSEC 发送超时 我有一个 LS1021A 物联网芯片和一个基于该芯片的原型板。两者都使用引导加载程序。 它在物联网板上运行完美，但在我的板上，以太网端口出现TX超时错误。我发出几个 ping 请求后，发送超时，然后又发出更多 ping 请求。这使得TFTP几乎无法使用。 当然，硬件方面也存在差异。我们的 MAC 连接到 BCM54616S，然后连接到 LAN9514。自动协商的上限为 100FD。TX超时在环回模式下也会发生。 为了传输数据，我必须在我的板子上的 TBI PHY 中设置 SGMII_AN 位，而 IOT 则不需要这样做（IOT 可以协商 1000FD）。 不确定为什么TX信号如此不稳定。这是否与速度限制有关？ Re: ls1021a eTSEC tx timeout 你好， 对于 100FD SGMII，请在原型板的引导加载程序中验证以下项目： 设置 LS1021A eTSEC 用于 SGMII 100 Mbps ECNTRL[TBIM] = 1 ECNTRL[SGMIIM] = 1 ECNTRL[R100M] = 1 MACCFG2[I/F Mode] = 01 表示 10/100 模式 LS1021A RM 特别指出，对于 SGMII 100 Mbps，应将 R100M = 1 。 重置和编程内部 TBI PHY。RM 指出 SGMII 使用 TBI 寄存器集，并且对于所有接口模式（包括 SGMII）重置 TBI 非常重要。 保持 SGMII_AN 设置为 TBI SGMII_AN 位“必须设置为 1”。因此，您的电路板只有在设置此位后才会发送数据，这并不奇怪；这表明您的引导加载程序初始化对于此 PHY/MAC 模式不完整。 不要依赖 100 Mbps 下的 1G 式 SGMII AN 行为。已知 LS1021A 报告显示，100 Mbps SGMII 操作在链路循环后会出现“SGMII 链路不正常”或间歇性无数据包行为，而 1G 操作则正常。这并不能证明您的 TX 超时的确切根本原因，但这足以证明 100FD SGMII 配置是一个强烈的怀疑对象。 回环结果很重要。如果您的“环回模式”是外部 PHY 环回或 SGMII 侧环回，则 100FD SGMII/TBI 设置仍然可能参与其中。如果是内部 MAC/eTSEC 环回，那么外部 BCM54616S/LAN9514 路径基本无关紧要，我会重点关注 eTSEC 初始化、描述符环处理、缓存一致性和 TX 停止/错误状态。 为了进行调试，请检查超时发生时 eTSEC TX 停止状态。RM 表示，当 eTSEC 不再处理来自 TxBD 环的发送帧时，会设置发送停止位；可重复出现的原因包括总线错误、无效的 BD/数据地址、无法纠正的 BD/数据读取错误以及 TxBD 编程错误，例如 Ready = 1 长度为 0 。还要检查是否看到 IEVENT_BSY ；NXP 的资料将 BSY 描述为由于缓冲区不足/软件无法足够快地服务于 BD 环而导致的 RX 帧丢失，这是一种软件/BD 环的症状，而不是纯粹的 SGMII 电气症状。 推荐的分离步骤： 1.强制外部PHY为 100FD ，如果需要，不进行铜缆自动协商。2.强制LS1021A MAC / eTSEC 为SGMII 100 Mbps ： TBIM = 1 ， SGMIIM = 1 ， R100M = 1 ， MACCFG2 I / F模式= 10 / 100。3. 设置 SGMII 模式后 RESET / 重新初始化 TBI 。4.设置TBI SGMII_AN = 1。 5.确认TBI链路/ AN状态、 eTSEC ECNTRL / MACCFG2和PHY SGMII侧状态。6.超时时，转储IEVENT 、 TX停止寄存器、 DMA状态和TXBD环内容。 此致敬礼 Re: ls1021a eTSEC tx timeout 忘了说了，我的端口设置为SGMII模式。 Re: ls1021a eTSEC tx timeout 在发送函数中添加消息或 1 毫秒延迟，可以确保数据正确传输而不丢失。 我在发送函数中为 TX 描述符添加了 DMA 刷新，这很有帮助。不过，考虑到描述符是在非缓存内存中分配的，这应该不是必要的。这可能是我添加了 LPAE 支持的 MMU 库的缺陷。 现在我想起来了，很久以前我删除了 enet 设备节点中的 dma-coherent 属性，这足以让 LS1021A-IOT 工作。这样会在为描述符分配未缓存内存时强制执行 DMA 刷新。但是发送函数中没有缓存刷新，无法更新每个数据包的 TX 描述符。不确定为什么在我的原型机上不起作用（频率不同，DDR3L 与 DDR4 的区别……） Re: ls1021a eTSEC tx timeout 您好， 感谢您提供的详细调查结果——您发现的解决方法组合（1 毫秒延迟、手动 DMA 刷新和删除 dma-coherent ）是缓存别名问题的典型特征。以下是根本原因分析和推荐的修复方案。 根本原因：TX描述符区域中缓存的虚拟别名 LS1021A ENET DMA 是一个非缓存一致性总线主控器——它直接读取 DDR，无法访问 CPU 缓存。LS1021A 上 gianfar 的正确操作模型是非一致性软件管理模型：描述符分配在非缓存内存中，每当 CPU 更新描述符字段时，都会显式调用 dma_sync_* 。 您的 LPAE 更改最有可能引入的是描述符物理地址范围的页表项，该条目携带错误的缓存属性——普通写回而不是设备或普通不可缓存。这为同一物理内存创建了两个具有不同缓存性的虚拟别名：分配路径（通过 dma_alloc_noncoherent ）将其映射为未缓存，但发送函数中每个数据包的 TX 描述符更新路径通过缓存别名访问它。CPU 将更新后的描述符字段写入缓存行，这些字段永远不会到达 DDR，导致 ENET DMA 读取到过时的数据并出现欠载。 为什么你的三种变通方案都掩盖了同一个缺陷 1 毫秒延迟/消息插入：在低负载下，增加足够的延迟，使 CPU 回写缓冲区自然耗尽——与时间相关，在流量或频率变化时会失效。 发送函数中的手动 dma_flush ：强制在 DMA 读取描述符之前执行缓存清理到 PoC 的操作——这是正确的行为，但如果该区域确实没有缓存，则无需执行此操作。 从 enet 设备节点中移除 dma-coherent ：导致内核在提交之前对每个 TX 描述符调用 dma_map_single() / dma_sync_single_for_device() ，从而显式地清除缓存——这也是正确的，并解释了为什么 LS1021A-IOT 无需发送路径刷新即可可靠地工作。 缺少发送路径刷新是关键所在。LS1021A-IOT 在移除 dma-coherent 后可以正常工作，因为内核的 DMA 映射层会自动插入同步信号；你的原型没有这条路径，因为 LPAE 的更改改变了描述符区域的缓存属性，而没有重新引入同步信号。 DDR3L 与 DDR4 的频率差异 这不是根本原因。不同的动态随机存取存储器(DRAM)类型和频率会改变写入延迟和缓冲区漏电时间，这就是为什么故障在您的原型上更明显的原因——但根本缺陷是架构上的，在足够的负载下，两个板上都会出现这种缺陷。 推荐修复方案 正确且自洽的解决方案是将以下两种方法结合起来： 将 dma-coherent 从 enet 设备节点中移除（非相干模型）。这导致内核 DMA 层在通过 dma_alloc_noncoherent 分配的描述符的 DMA 所有权转移之前自动发出 dma_sync_single_for_device() 。 在 TX 发送路径中，于每个数据包上写入 TX 描述符字段（ status 、 data_length 、 data_pointer ）的位置，添加显式的 dma_sync_single_for_device() 调用。这是你手动添加的冲洗——但在编写 TDAR 之前，应该正式地将其放置为 dma_sync_single_for_device(dev, desc_dma_addr, sizeof(txbd), DMA_TO_DEVICE) 。无论 MMU 如何对描述符区域进行归属，该模型都明确且正确。 另外，审核分配给 ENET 描述符使用的物理地址范围的 AttrIndx / TEX+C+B 字段的 LPAE MMU 库更改。描述符池应映射为 Device-nGnRnE（强有序）或 Normal Non-cacheable — 而不是 Normal Writeback。您可以通过在分配后检查描述符池的虚拟地址，使用内核的 ptdump 调试接口来验证实际使用的属性。 你添加的 DMA 刷新不是一种权宜之计，而是正确的机制。真正的缺陷在于它一开始就不在发送路径中，而 LPAE 的更改暴露了这一点，因为它们改变了该区域的有效缓存性。   此致

MPC5746C FXOSC output frequency Part: MPC5746C (Power Architecture Z4, SDK: NXP MPC57xx platform SDK). In the manual of MPC5746C, it is stated that FXOSC provides 8 -40 MHz output frequency. Please help me in finding the output frequency provided by FXOSC for the following configurations? 1. FXOSC_CTL: OSCBYP = 0 and OSCM = LCP 2. FXOSC_CTL: OSCBYP = 0 and OSCM = FSP 3. FXOSC_CTL: OSCBYP = 1 and OSCM = LCP 4. FXOSC_CTL: OSCBYP = 1 and OSCM = FSP Please consider default values for the other register fields. Thanks. Re: MPC5746C FXOSC output frequency Thanks for your response @petervlna.  How can we find the frequency provided by the crystal/resonator(OSCBYP = 0) and external clock(OSCBYP = 1)? Re: MPC5746C FXOSC output frequency Hello, The FXOSC module does not generate a specific frequency based on the OSCBYP and OSCM settings. The FXOSC output frequency is always equal to the frequency of the external source connected to FXOSC (crystal/resonator when OSCBYP=0, or external clock when OSCBYP=1), within the supported range of 8–40 MHz. Therefore, for all four configurations listed, the FXOSC output frequency is simply the external input frequency. The OSCM setting (LCP/FSP) affects the oscillator operating mode, but does not change the clock frequency. Best regards, Peter Re: MPC5746C FXOSC output frequency @petervlna please provide your support for my FXOSC query mentioned above.  Re: MPC5746C FXOSC output frequency How can we find the frequency provided by the crystal/resonator(OSCBYP = 0) and external clock(OSCBYP = 1)? Please let me know on the above question @petervlna. I want to use FXOSC as clock source for a timer. Based on the frequency it provides i can load a count value into the timer register Re: MPC5746C FXOSC output frequency Hello, The MPC5746C does not provide a way to measure or determine the FXOSC frequency from the FXOSC registers. The frequency must be known from the hardware design: OSCBYP = 0: FXOSC frequency equals the frequency of the external crystal/resonator fitted on the board. OSCBYP = 1: FXOSC frequency equals the frequency of the external clock signal applied to the FXOSC input pin. To use FXOSC as a timer clock source, the application must use the frequency specified in the board schematic or clock design (for example, 8 MHz, 16 MHz, 40 MHz, etc.) when calculating the timer count value. The OSCBYP and OSCM settings do not affect the frequency itself. Best regards, Peter

MD8LC925NR1アンプのバイアス調整方法を教えてください。 こんにちは、 現在、 MD8LC925NR1パワーアンプを使用したシステムを設計中です。適切な バイアス回路や専用の電源管理部品 をおすすめしていただけるとありがたいです。 この目的のために推奨されるリファレンス・デザイン、アプリケーションノート、または具体的な部品番号を教えていただけますか? ご協力ありがとうございました。 Re: How to bias the amp MD8LC925NR1? こんにちは、 NXPセミコンダクターズの製品にご関心をお寄せいただき、またサポートの機会をいただきありがとうございます。 記載されている部品番号に誤植があるようです。MDL8LC925NR1は、NXPの有効な注文可能部品番号ではありません。最も近い類似デバイスはMD8IC925Nです。このデバイスは現在、販売終了（EOL）となっており、サポートが終了しているため、新規購入はできませんのでご注意ください。 以下のNXP文書は、回路回路図、部品リスト、特性評価データを含む詳細な設計情報を提供しています。 MD8IC925N データシート AN1977 – RF集積回路ファミリにおける静止電流熱追尾回路 AN1987 – RF集積回路デバイスファミリ向けクイセント電流制御(両方のバイアス回路トポロジーと完全な部品リストを含む) AN1955 – RFパワーアンプの熱測定手法 残念ながら、MD8IC925Nの直接的な代替品は存在しません。さらに、 100MHzから1000MHz 帯をカバーする多くのRF製品はEOLに近づいており、現時点では新しい代替機器の発表はありません。 お客様の周波数、電力、供給電圧に関する具体的な要件に基づき、代替ソリューションの特定についてサポートが必要な場合は、お知らせください。 よろしくお願いいたします。

支持请求：使用 i.MX8M Plus LVDS 输出的 HD-SDI 接口 尊敬的先生， 我们正在设计一个基于NXP i.MX8M Plus处理器的系统，希望您能指导我们实现HD-SDI 接口。 我们的需求是支持三个 HD-SDI 输出。我们计划使用i.MX8M Plus 的LVDS 接口，并使用以下设备将其转换为 HD-SDI： LMH0340SQE/NOPB – LVDS 转 HD-SDI 串行器 2 × LMH0324RTWT – 1 对 3 HD-SDI 分配放大器 请问i.MX8M Plus的LVDS接口是否与该架构兼容，能够生成三个HD-SDI输出？ 如果此方案不被推荐或支持，能否请您提供一个替代方案，以便在继续使用i.MX8M Plus处理器的情况下实现三个 HD-SDI 接口？我们希望在设计中保留 i.MX8M Plus，因为它满足我们所有其他系统要求。 我们非常感谢您能提供任何建议以及任何可能有助于我们成功实现此接口的参考设计或应用说明。 感谢您的支持。我们期待您的指导。 顺祝商祺！ 萨穆德拉兰凯亚·詹帕尼 模拟（ADC|CMP|DAC|运算放大器） 电路板设计 MCXA MCXC Re: Support Request: HD-SDI Interface Using i.MX8M Plus LVDS Output 你好， 很遗憾，我对这种使用场景不太熟悉。我研究了您分享的那部分内容，发现它似乎是用于 FPGA 而不是 LVDS 通道，所以我不太确定您是否可以使用此接口。 或许使用不同的桥接器或 i.MX8MP 中的其他接口，甚至在中间添加另一层（FPGA）会是一个解决方案。 此致敬礼/Saludos， 阿尔多。