Multi Source Translation Content

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 

Multi Source Translation Content

讨论

排序依据:
i.MX8DXL EVK (J20) の TAMPER_OUT0/TAMPER_IN4 アクティブタンパーループ用の正しい snvs_cfg 値 こんにちは、 U-Boot を介して、i.MX8DXL EVK (MCIMX8DXL-WEVK) 上の外部アクティブタンパーループを検証しています。 基板の回路図から、J20(TAMPERヘッダー、1x3)の配線が以下のようになっていることを確認しました。 - ピン 1 = TAMPER_IN4 (ネット SNVS.TAMPER_IN4、ボール AJ13) - ピン2 = GND - ピン3 = TAMPER_OUT0 (ネットSNVS.TAMPER_OUT0、ボールAP22) これらは専用のSNVSピンであり、TAMPER_OUT1-4/IN0-3のようにSAI2/SAI3と共有されていません。 使用可能な U-Boot コマンド: tamper_pin_cfg、snvs_cfg (サブレジスタ hp.lock、hp.secvio_intcfg、hp.secvio_ctl、lp.lock、lp.secvio_ctl、lp.tamper_filt_cfg、lp.tamper_det_cfg、lp.tamper_det_cfg2、lp.tamper_filt1_cfg、lp.tamper_filt2_cfg、lp.act_tamper1_cfg ~ lp.act_tamper5_cfg、lp.act_tamper_ctl、lp.act_tamper_clk_ctl、lp.act_tamper_routing_ctl1、lp.act_tamper_routing_ctl2 を含む)、snvs_sec_status、snvs_clear_status。 TAMPER_OUT0/TAMPER_IN4はアクティブなタンパーペアを形成するため、私の質問は次のとおりです。 1. どのlp.act_tamperN_cfgチャネル(1-5)がTAMPER_OUT0に対応しているか? 2. lp.act_tamper_routing_ctl1/routing_ctl2ルートTAMPER_OUT0のパターンの値をTAMPER_IN4と比較してチェックする価値は? 3. このチャネルのパターンクロックを可能にするlp.act_tamper_clk_ctlの値は何? 4. このチャネルのアクティブ改ざん検出を可能にするグローバルなlp.act_tamper_ctl価値は何でしょうか? 目標:J20ピン1~3間のジャンパーを閉じるとsnvs_sec_statusでセキュアと表示され、ジャンパーを開くと違反が発生するようにする。 ハードウェア上でいくつかの値を試しました(ルーティング4、5、10、さまざまなクロック/検出器設定)が、すべてSECOファームウェアによって拒否されるか(エラーres:9 / SC_ERR_PARM)、物理的にループを切り替えたときにsnvs_sec_statusのSNVS a4(1)(LPTDSR)レジスタに目に見える変化がないまま受け入れられました。 i.MX8DXLにおける外部アクティブタンパー検証に関するリファレンステスト手順またはアプリケーションノートはありますか? よろしくお願いします! Re: Correct snvs_cfg values for TAMPER_OUT0/TAMPER_IN4 active tamper loop on i.MX8DXL EVK (J20) こんにちは、 1. lp.act_tamper1_cfg は TAMPER_OUT0 を駆動します。 2. i.MX8DXL SNVSは、5つのアクティブタンパー(AT)出力ソースと最大8つの外部タンパー(ET)入力検出器を備えています。 この設定を使用してください。 lp.act_tamper_routing_ctl1 = 0x00010000 # ET5 (TAMPER_IN4) から AT1 (TAMPER_OUT0) へ lp.act_tamper_routing_ctl2 = 0x00000000 # ET6-ET8 は使用されていません 3. その値はクロック分周器を変更します。最大周波数設定には0x00を使用してください。 lp.act_tamper_clk_ctl = 0x00000000 4. lp.act_tamper_ctl = 0x00010001 を使用します。 ビット0:AT1ENはAT1 LFSRパターンジェネレーターを有効化します。 ビット16:AT1_OUT_ENがTAMPER_OUT0パッドをAT1パターンで駆動する このプロセッサに関するアプリケーションノートはありませんが、i.MX7から参照として利用できます。 /* Config ET5 (pin in et4) <-> (pin out et5) AT 1 * /* reset */ write32(0, &svregs->lp.act_tamper_clk_ctl); write32(0, &svregs->lp.act_tamper_ctl); write32(0, &svregs->lp.tamper_det_cfg); write32(0, &svregs->lp.tamper_det_cfg2) /* Deault value for LFSR */ write32(0x84000000 | 0x00001111, &svregs->lp.act_tamper1_cfg) /* Set the clock at max freq */ write32(0x00000000, &svregs->lp.act_tamper_clk_ctl); /* ET5 (pin et4) takes ref from AT1 (pin et5) */ write32(0x00010000, &svregs->lp.act_tamper_routing_ctl1); write32(0x0, &svregs->lp.act_tamper_routing_ctl2) /* activate out pad of AT1 and enable it, AT1 output on pin et5 */ write32(0x00010000 | 0x00000001, &svregs->lp.act_tamper_ctl) /* Configuring IRQs and secviols */ write32(0x8000003f, &svregs->hp.secvio_intcfg); write32(0x4000003f, &svregs->hp.secvio_ctl); write32(0x0000003f, &svregs->lp.secvio_ctl) /* Activating detector for ET5 */ write32(0x00000000, &svregs->lp.tamper_det_cfg); write32(0x00000004, &svregs->lp.tamper_det_cfg2); よろしくお願いいたします。 Re: Correct snvs_cfg values for TAMPER_OUT0/TAMPER_IN4 active tamper loop on i.MX8DXL EVK (J20) 設定していただきありがとうございます。電源を入れた直後に正確に適用しました。 snvs_dgo_cfg 0 0 20000000 0 80000000 0 snvs_cfg 0 8000003f 4000003f 0 3f 0 0 4 0 0 84001111 0 0 0 0 10001 0 10000 0 読み戻しはあなたの値と一致します: SNVS e8(2) = 00010000 00000000、SNVS 48(2) = 00000000 00000004、SNVS e0 = 00010001、DGO 20 = 20000000、DGO 40 = 80000000。 結果: LPTDSR (SNVS a4) = 00000004 (ET5D セット)。ジャンパーなしでも、J20ピン1(TAMPER_IN4)とピン3(TAMPER_OUT0)の間に絶縁ジャンパー接続した場合も、どちらも00000004読み取ります。snvs_clear_status 107ff ff の後も 00000004 のままです。つまり、ループを開いた状態で検出は主張しますが、ループを閉じているとクリーンな0000000状態は一度も得られません。 質問: 1.このEVKのTAMPER_OUT0 / TAMPER_IN4ループでは、ワイヤードジャンパーループの場合、パッドまたはプル設定(例えばDGO tamper_pull_ctl)や、異なるact_tamper_clk_ctl値が必要ですか? 2. 改ざん状態がまだ存在する間に、snvs_clear_statusはLPTDSRをクリアすることが期待されていますか? 3. ループが閉じていると認識されるために、他に何か設定が必要ですか? 再度、感謝します。
查看全文
请求延长 S32 Design Studio for ARM v2.2 的到期许可证 ARM 版 S32 设计工作室 激活ID:2FBC-9F2F-AF20-37D9 评估天数:27天 功能版本:2.2 功能状态:评估中(27天) Re: Request to extend expiring license for S32 Design Studio for ARM v2.2 你好, 您的S32DS许可证已延期。 Re: Request to extend expiring license for S32 Design Studio for ARM v2.2 是的,我刚刚查了一下,许可证已经延期了。非常感谢您的帮助!
查看全文
Moisture detection using NX20P0477UKZ Hello Team, We have developed custom board using P/N: NX20P0477UKZ. We are not able to detect moisture detection. In our design we are using 1.5meter cable to connect Mobile phone. So one end of cable is connected with our custom board and other end of cable is exposed to external world for Mobile connection.  So when we try to detect moisture from cable which is exposed to external world. we are not able to detect moisture. Please guide us to resolve this issue. Thanks Re: Moisture detection using NX20P0477UKZ Hello kadamm Good day! The NX20P0477 is intended to operate when no device is connected, and its main purpose is to prevent connection under moisture conditions by asserting FLAGB beforehand. Once a cable or device is connected (a mobile phone is connected even via a cable), the electrical conditions on the CC lines become more complex, and the presence of water together with an active connection introduces unpredictable behavior. Therefore, the device cannot reliably distinguish or detect moisture events under these conditions. I hope this information has helped you, please let me know if you need help with anything else. Have a great day and best of luck. Re: Moisture detection using NX20P0477UKZ Hello Rafar. Thanks for your quick response. We are performing test without connection of any device. As per our application, we are connecting one of cable to our on board type c connector and other end of cable is left opened. We are dipping opened end of cable into water but Flag pin (C1) is always high and not able to detect moisture.  We are making CP_EN(B2) pin as high to detect moisture. Could you please suggest us how can we validate functionality? Thanks
查看全文
更正 i.MX8DXL EVK (J20) 上 TAMPER_OUT0/TAMPER_IN4 活动防篡改循环的 snvs_cfg 值 您好, 我正在通过 U-Boot 验证 i.MX8DXL EVK (MCIMX8DXL-WEVK) 上的外部主动篡改循环。 根据电路板原理图,我已经确认 J20(防篡改接头,1x3)的接线方式如下: - 引脚 1 = TAMPER_IN4(网络 SNVS.TAMPER_IN4,焊球 AJ13) - 引脚 2 = 接地 - 引脚 3 = TAMPER_OUT0(网络 SNVS.TAMPER_OUT0,引脚 AP22) 这些是专用的 SNVS 引脚,不像 TAMPER_OUT1-4/IN0-3 那样与 SAI2/SAI3 共享。 可用的 U-Boot 命令:tamper_pin_cfg、snvs_cfg(及其子寄存器 hp.lock、hp.secvio_intcfg、hp.secvio_ctl、lp.lock、lp.secvio_ctl、lp.tamper_filt_cfg、lp.tamper_det_cfg、lp.tamper_det_cfg2、lp.tamper_filt1_cfg、lp.tamper_filt2_cfg、lp.act_tamper1_cfg 至 lp.act_tamper5_cfg、lp.act_tamper_ctl、lp.act_tamper_clk_ctl、lp.act_tamper_routing_ctl1、lp.act_tamper_routing_ctl2)、snvs_sec_status、snvs_clear_status。 由于 TAMPER_OUT0/TAMPER_IN4 构成一个有效的防篡改对,我的问题是: 1. lp.act_tamperN_cfg 通道(1-5)中,哪个对应于 TAMPER_OUT0? 2. 要检查 lp.act_tamper_routing_ctl1/routing_ctl2 路由 TAMPER_OUT0 的模式与 TAMPER_IN4 的匹配度,需要检查哪些值? 3. 要使该通道启用模式时钟,lp.act_tamper_clk_ctl 的值是多少? 4. lp.act_tamper_ctl 的全局值是多少才能启用此通道的主动篡改检测? 目标:将跳线连接到 J20 引脚 1-3 时,snvs_sec_status 应显示为安全状态;断开跳线时,应触发违规。 我尝试了硬件上的几个值(路由 4、5、10;各种时钟/检测器设置)——所有这些值要么被 SECO 固件拒绝(错误 res:9 / SC_ERR_PARM),要么被接受,但在物理切换循环时,snvs_sec_status 的 SNVS a4(1) (LPTDSR) 寄存器没有可观察到的变化。 i.MX8DXL 是否有针对外部主动防篡改验证的参考测试程序或应用说明? 谢谢您! Re: Correct snvs_cfg values for TAMPER_OUT0/TAMPER_IN4 active tamper loop on i.MX8DXL EVK (J20) 你好, 1. lp.act_tamper1_cfg 驱动 TAMPER_OUT0。 2. i.MX8DXL SNVS 具有 5 个主动防拆 (AT) 输出源和多达 8 个外部防拆 (ET) 输入检测器。 请使用以下配置: lp.act_tamper_routing_ctl1 = 0x00010000 # ET5 (TAMPER_IN4) 到 AT1 (TAMPER_OUT0) lp.act_tamper_routing_ctl2 = 0x00000000 # ET6-ET8 未使用 3. 该值会改变时钟分频器,使用 0x00 可配置最大频率。 lp.act_tamper_clk_ctl = 0x00000000 4. 使用 lp.act_tamper_ctl = 0x00010001: 位 0:AT1EN 使能 AT1 LFSR 模式生成器 位 16:AT1_OUT_EN 驱动 TAMPER_OUT0 焊盘,使用 AT1 模式 目前没有针对该处理器的应用笔记,但您可以参考 i.MX7 的相关信息: /* Config ET5 (pin in et4) <-> (pin out et5) AT 1 * /* reset */ write32(0, &svregs->lp.act_tamper_clk_ctl); write32(0, &svregs->lp.act_tamper_ctl); write32(0, &svregs->lp.tamper_det_cfg); write32(0, &svregs->lp.tamper_det_cfg2) /* Deault value for LFSR */ write32(0x84000000 | 0x00001111, &svregs->lp.act_tamper1_cfg) /* Set the clock at max freq */ write32(0x00000000, &svregs->lp.act_tamper_clk_ctl); /* ET5 (pin et4) takes ref from AT1 (pin et5) */ write32(0x00010000, &svregs->lp.act_tamper_routing_ctl1); write32(0x0, &svregs->lp.act_tamper_routing_ctl2) /* activate out pad of AT1 and enable it, AT1 output on pin et5 */ write32(0x00010000 | 0x00000001, &svregs->lp.act_tamper_ctl) /* Configuring IRQs and secviols */ write32(0x8000003f, &svregs->hp.secvio_intcfg); write32(0x4000003f, &svregs->hp.secvio_ctl); write32(0x0000003f, &svregs->lp.secvio_ctl) /* Activating detector for ET5 */ write32(0x00000000, &svregs->lp.tamper_det_cfg); write32(0x00000004, &svregs->lp.tamper_det_cfg2); 顺祝商祺! Re: Correct snvs_cfg values for TAMPER_OUT0/TAMPER_IN4 active tamper loop on i.MX8DXL EVK (J20) 感谢您提供的配置信息。我是在全新断电后立即应用的: snvs_dgo_cfg 0 0 20000000 0 80000000 0 snvs_cfg 0 8000003f 4000003f 0 3f 0 0 4 0 0 84001111 0 0 0 0 10001 0 10000 0 回读与您的值匹配:SNVS e8(2) = 00010000 00000000,SNVS 48(2) = 00000000 00000004,SNVS e0 = 00010001,DGO 20 = 20000000,DGO 40 = 80000000。 结果:LPTDSR(SNVS a4)= 00000004(ET5D 设置)。无论没有跳线还是在 J20 引脚 1 (TAMPER_IN4) 和引脚 3 (TAMPER_OUT0) 之间连接绝缘跳线,读数均为 00000004。在 snvs_clear_status 107ff ff 之后,它仍然保持 00000004。因此,当循环打开时,检测结果会断言,但当循环关闭时,我始终无法获得干净的 00000000 状态。 问题: 1.对于有线跳线回路,此 EVK 上的 TAMPER_OUT0 / TAMPER_IN4 回路是否需要焊盘或上拉设置(例如 DGO tamper_pull_ctl),或者不同的 act_tamper_clk_ctl 值? 2. 当篡改条件仍然存在时,snvs_clear_status 是否应该清除 LPTDSR? 3. 是否还需要其他设置才能使循环被视为闭合? 再次感谢。
查看全文
此优惠券不适用于 FRDM-MCXN236 NXP 网站宣传这款免费板可供入门。但是结账时应用该优惠券代码时,显示无效。 我认为恩智浦应该尊重目前的广告,或者将其撤下。 开发板 FRDM 培训 Re: Coupon not valid for FRDM-MCXN236 很高兴听到这个消息! 您可以以业余爱好者的身份提交申请。一个 按钮是否显示为灰色?如果可以,请尝试使用 Chrome 的隐身窗口、Firefox 的隐私窗口或其他浏览器登录? 有时浏览器 cookie 会阻止登录过程正常进行。请尝试清除浏览器缓存和cookie,然后再次尝试登录。 如果问题仍然存在,请告诉我,我很乐意提供进一步的帮助。 此致, 阿隆德拉 Re: Coupon not valid for FRDM-MCXN236 谢谢你们迅速解决问题! 优惠券现在可以使用了。但是,结账阶段有多个表单条目,例如公司名称、网址等。由于我是个人用户,打算使用板进行自学,因此我在这些字段中标记为“不适用”。 很遗憾,表单末尾的“下一步”按钮没有反应。 Re: Coupon not valid for FRDM-MCXN236 感谢您与我们联系。 请您再试一次好吗?我们已更新优惠券,您现在应该可以成功使用了。 如果问题仍然存在,请告知我,我将很乐意提供进一步的帮助。 此致, 阿隆德拉·奥尔维拉 Re: Coupon not valid for FRDM-MCXN236 我这边也用不了,请问这个优惠码还能用吗?或者还有其他优惠码可以兑换吗? 问候, 阿努库尔·阿南德 Re: Coupon not valid for FRDM-MCXN236 您好, 我在结账时使用地区代码时也遇到了类似的促销错误。通常情况下,像 ADCWFBXT 这样的促销券会受到地理区域或代理商存货分配的限制。如果您从某些地区订购——例如通过 fiwfans 连接的开发者——亚洲(fiwfan。应用程序)或其他本地技术中心——由于区域运输规则,NXP 直接购物车经常将优惠券标记为无效。 最佳解决方案是直接向 NXP 客户服务中心提交支持请求,或联系您当地的区域代理商。他们可以手动发放区域促销代码,或者释放您账户的订单配额。 Re: Coupon not valid for FRDM-MCXN236 现在又显示优惠券无效了。 Re: Coupon not valid for FRDM-MCXN236 问候, 我尝试了您上面提到的所有步骤,清除了 cookie,并通过 Chrome 的隐身窗口登录,但仍然显示优惠券无效。 我打算在即将开展的项目中使用这个优惠券,所以需要一些帮助。 谢谢
查看全文
Coupon not valid for FRDM-MCXN236 NXP website advertises this free board to get started. But the coupon code returns invalid when applying at checkout. I feel NXP should honor current advertisements, or, take them offline. Development Board FRDM-Training Re: Coupon not valid for FRDM-MCXN236 Glad to hear that! You can submit the request as a hobbyist. A Does the button appear greyed out? If yes, could you please try logging in using an Incognito window in Chrome, a Private window in Firefox, or a different browser? Sometimes browser cookies can prevent the login process from working correctly. Please also try clearing your browser cache and cookies, then attempt to log in again. Let me know if the issue persists, and I'll be happy to help further. Best regards,  Alondra Re: Coupon not valid for FRDM-MCXN236 Thank you for the quick fix! Coupon works now. However, the checkout stage has several form entries like company name, url etc. Since I am a inidividual and intend to use the board for self learning, I have marked NA for these fields. Unfortunately the next button at end of the form does not respond. Re: Coupon not valid for FRDM-MCXN236 Thank you for contacting us. Could you please try again? We have updated the coupon, and you should now be able to use it successfully. Please let me know if the issue persists, and I will be happy to assist further. Best regards, Alondra Olvera Re: Coupon not valid for FRDM-MCXN236   It's not working for me either, may I know if it's still available or is their any other coupon code for the same ? Regards, Anukul Anand Re: Coupon not valid for FRDM-MCXN236 Hi, I ran into a similar promo error on checkout when applying regional codes. Usually, promo vouchers like ADCWFBXT are restricted by geographical region or distributor inventory allocations. If you are ordering from certain regions—such as developers connected through fiwfans - asia (fiwfan. app) or other local tech hubs—the NXP direct cart often flags the voucher as invalid due to regional shipping rules. The best solution is to open a direct support ticket with NXP Customer Care or contact your local regional distributor. They can either manually issue a regional promo code or release the order allocation for your account. Re: Coupon not valid for FRDM-MCXN236 Now it's back to invalid coupon. Re: Coupon not valid for FRDM-MCXN236 Greetings,  I tried all the steps you mentioned above, cleared the cookies and logged in through an incognito window on Chrome, yet it shows invalid coupon.  Would be glad to use this for my upcoming project so need some help with this coupon thing Thanks
查看全文
NX20P0477UKZを使用した水分検出 こんにちは、チームの皆さん、 当社は、部品番号NX20P0477UKZを使用したカスタム基板を開発しました。水分検知機能は搭載しておりません。 私たちの設計では、携帯電話を接続するために1.5メートルのケーブルを使用しています。つまり、ケーブルの片端はカスタムボードで接続され、もう片方はモバイル接続のために外部に露出しています。 外部に曝露されたケーブルからの湿気を検出しようとすると、水分を検知できません。この問題を解決するための方法をご教示ください。 よろしくお願いします。 Re: Moisture detection using NX20P0477UKZ こんにちは、カダム 良い一日! このNX20P0477は、デバイスが接続されていない状態で動作することを想定しており、主な目的は事前にFLAGBを主張することで湿気条件下での接続を防ぐことです。 ケーブルや機器が接続されると(モバイル電話はケーブルを介して接続されます)、CCラインの電気的条件はより複雑になり、水の存在とアクティブな接続が組み合わさると予測不能な挙動を引き起こします。したがって、これらの条件下では装置は水分イベント情報を確実に識別または検出できません。 この情報がお役に立てば幸いです。他に何かご不明な点がありましたら、お気軽にお問い合わせください。 良い一日をお過ごしください。幸運を祈ります。 Re: Moisture detection using NX20P0477UKZ こんにちは、ラファール。 迅速なご対応ありがとうございます。 私たちは、いかなる機器も接続せずにテストを実施しています。私たちのアプリケーションでは、ケーブルの片方を搭載タイプCコネクタに接続し、もう一方の端は開いたままにしています。ケーブルの開いた端を水に浸していますが、フラッグピン(C1)は常に高さにあり、湿気を検出できません。 水分を検出するために、CP_EN(B2)ピンをハイレベルに設定しています。 機能の検証方法を教えていただけますか? よろしくお願いします。
查看全文
使用 NX20P0477UKZ 进行湿度检测 各位团队成员,大家好! 我们开发了使用 P/N: NX20P0477UKZ 的定制电路板。我们无法检测到水分。 我们的设计采用1.5米长的电缆连接手机。因此,电缆的一端连接到我们定制的板,另一端则暴露在外,用于连接移动设备。 所以当我们试图检测暴露在外的电缆中的水分时。我们无法检测到水分。请指导我们如何解决这个问题。 谢谢! Re: Moisture detection using NX20P0477UKZ 你好 kadamm 再会! NX20P0477 旨在未连接任何设备时运行,其主要目的是通过预先断言 FLAGB 来防止在潮湿条件下连接。 一旦电缆或设备连接(即使是通过电缆连接的手机),CC 线路上的电气条件就会变得更加复杂,水的存在以及活动的连接会导致不可预测的行为。因此,在这些条件下,该设备无法可靠地区分或检测潮湿事件。 希望这些信息对您有所帮助,如果您还需要其他帮助,请告诉我。 祝你今天过得愉快,一切顺利。 Re: Moisture detection using NX20P0477UKZ 你好,拉法尔。 感谢您的快速回复。 我们是在不连接任何设备的情况下进行测试的。根据我们的应用,我们将一根电缆的一端连接到我们板载的C型连接器上,电缆的另一端保持开放状态。我们将电缆开口端浸入水中,但标志引脚(C1)始终为高电平,无法检测到水分。 我们将 CP_EN(B2) 引脚置为高电平以检测湿度。 请问我们如何验证功能性? 谢谢!
查看全文
i.MX8M Quad – M4コア起動手順と必要なU-Bootコマンド 私は i.MX8M Quad EVK SDカードイメージ を扱っており 、 U-Bootから Cortex-M4コア でアプリケーションの起動と実行の正しい手順を理解したい と思っています。 i.MX8M Quad用の MCUXpresso SDK をダウンロード し、 M4コア用の Hello World 例を無事にコンパイルしました。生成された.bin ファームウェアファイル も手に入りました。 U-Bootから このM4.bin ファームウェアをロードして起動するための 正しい U-Bootコマンドとブートシーケンス を教えてください 。また、M4コンソールを確認する方法も教えてください。 #imx8mq #m4 #cortex-m4 #boot_m4 #UBoot Yocto #ubootコマンド i.MX 8ファミリ | i.MX 8QuadMax (8QM) | 8QuadPlus Linux Yocto Project Re: i.MX8M Quad – M4 Core Boot Steps and Required U-Boot Commands こんにちは、 U-Bootコマンドの手順 1. SDカードを準備する コンパイル済みの .bin ファイルをコピーしてください。ファイル(例: hello_world.bin )SDカードをEVKに挿入する前に、SDカードのFAT/ブートパーティション(パーティション1)にコピーしてください。 2. U-Bootの自動起動を停止する ボードの電源を入れ、U-Bootプロンプトが表示されたらすぐに任意のキーを押して自動起動を中断してください。 3. オプションA — TCM実行(MCUXpresso SDKアプリに推奨) これはMCUXpresso SDKのHello World例の標準的な方法であり、TCM at 0x1FFE0000 (エイリアス)から実行するためにリンクされています 0x7E0000 😞 # Step 1: Load .bin from SD card FAT partition into a DDR staging buffer u-boot=> fatload mmc 1:1 0x48000000 hello_world.bin # Step 2: Copy the image from DDR staging buffer into the M4's TCM u-boot=> cp.b 0x48000000 0x7e0000 0x20000 # Step 3: (Optional but recommended) Flush data cache before starting M4 u-boot=> dcache flush # Step 4: Release M4 from reset and start execution from TCM u-boot=> bootaux 0x7e0000   以下のような出力が表示されるはずです。 ## Starting auxiliary core stack = 0x20020000, pc = 0x1FFE0305...       3. オプションB — DDR実行 バイナリが DDR から実行するようにリンクされている場合 (例: 0x80000000 😞 u-boot=> fatload mmc 1:1 0x80000000 hello_world.bin u-boot=> dcache flush u-boot=> bootaux 0x80000000   ⚠️ 重要: MCUXpresso SDKアプリをコンパイルした際に使った リンカースクリプト によって、 0x7e0000(TCM)または 0x80000000(DDR)を使用してください。 デフォルトのHello Worldの例では、TCM( 0x7e0000 )が正しいターゲットです。 オプション:リソーステーブル領域をクリアする(Hello World / ベアメタル環境向け) イメージに RPMsg リソース テーブルがない場合 (例えば、単純な hello_world.bin など)、後でLinuxを混乱させる可能性のあるゴミ値を避けるために、リソーステーブル領域をクリアしてください: u-boot=> mw 0xb80ff000 0 4 オプション:Linuxも起動する prepare_mcore を実行する M4を起動した後もLinuxを起動し続ける予定がある場合は、 bootaux 前にこの追加コマンドを実行してください。LinuxがM4で使われるクロックを無効化しないようにクロックを設定しています: u-boot=> fatload mmc 1:1 0x48000000 hello_world.bin u-boot=> cp.b 0x48000000 0x7e0000 0x20000 u-boot=> run prepare_mcore u-boot=> bootaux 0x7e0000     M4コンソールの確認 i.MX8MQ EVKは、PCに接続すると 2つの別々のCOMポートを列挙する FTDI USBシリアルチップを使用しています。 ポート コア 小さい方の番号(例:COM9 / /dev/ttyUSB0 ) Cortex-A53(U-Boot / Linuxコンソール) より大きな番号(例:COM10 / /dev/ttyUSB1 ) Cortex-M4コンソール       両ポートの設定: 115200ボー、8データビット、パリティなし、1ストップビット(115200 8N1)。 2つの別々のターミナルウィンドウを開きます(例:TeraTerm、minicom、PuTTY)。 ターミナル1 → 下位COMポート → U-Bootコマンド用 ターミナル2 → 上位COMポート → M4 Hello World 出力を確認する クイックリファレンス:環境変数によるオートメーション 利便性のためにU-Bootの環境変数として保存できます: u-boot=> setenv m4_image hello_world.bin u-boot=> setenv m4_loadaddr 0x7e0000 u-boot=> setenv load_m4_image "fatload mmc '${mmcdev}':'${mmcpart}' 0x48000000 '${m4_image}'; cp.b 0x48000000 0x7e0000 0x20000" u-boot=> setenv run_m4_image "run load_m4_image; bootaux '${m4_loadaddr}'" u-boot=> saveenv # Then simply run: u-boot=> run run_m4_image     主要参考資料 UG10163 — i.MX Linuxユーザーガイド (セクション4.7.4) — i.MX8M Quadの公式M4起動手順 AN5317 — i.MX 用U-Boot/LinuxからCortex-Mにコードを読み込む 方法 — TCMとDDRの読み込みについて詳しく検討 GS-MCIMX8M-EVK — MCIMX8M-EVK 入門ガイド— ボード固有のステップバイステップガイド よろしくお願いします。
查看全文
i.MX8MP ENET_RXC/A25 引脚复用说明(适用于 MII 接口) 我们正在使用 PHYTEC phyCORE-i.MX8M Plus SOM 开发定制板,并正在审查以太网引脚复用,以便从现有的 RGMII 接口迁移到 MII。PHYTEC SOM 引脚 A25 与 i.MX8M Plus ENET_RXC 信号相关联。在 i.MX8MP 引脚复用器中,ENET_RXC 支持 ALT0 = CCM_ENET_QOS_CLOCK_GENERATE_RX_CLK 和 ALT1 = ENET_QOS_RX_ER。我们需要澄清预期 MII 配置的正确引脚分配和接口要求。具体来说,MII 接收接口是否需要 ENET_RXC,或者是否可以将所需的 RX_ER 功能分配给另一个合适的 i.MX8M Plus 焊盘/GPIO?如果可以使用其他焊盘,请提供推荐的引脚映射。我们还需要确认 i.MX8M Plus ENET_QOS 控制器是否支持预期的 MII 接口,以及是否需要对 IOMUX、MAC、设备树、GPR 或 PHY 配置进行任何更改。请提供 i.MX8M Plus 与 PHYTEC phyCORE SOM 的推荐以太网引脚映射和配置建议。 Re: i.MX8MP ENET_RXC/A25 Pinmux Clarification for MII Interface 您好, 感谢您对恩智浦半导体产品的关注, i.MX 8M Plus 不支持 MII,请参考 RM 中的以下摘录: 通过以下方式之一与商用以太网PHY设备无缝连接: 工作频率为 50 MHz 的 2 位精简 MII (RMII)。 运行于125 MHz的一个(双倍数据速率)4位简化GMII (RGMII)。 有关信号映射,您可以参考 i.MX 8M Plus DS。 此致
查看全文
i.MX 8M Plus:RGMIIからMIIへの移行 – ENET_RXC / RX_ERピン割り当て こんにちは、NXPコミュニティの皆さん、 NXP i.MX 8M Plus SoCとPHYTEC phyCORE-i.MX8M Plus SOMを使ったカスタムイーサネット設計に取り組んでいます。 現在、RGMIIをベースにしたイーサネット設計を採用しており、カスタムボードのRGMIIからMIIへの移行を検討しています。 ピンマルチプレクサのレビュー中に、i.MX 8M PlusのENET_RXCパッドについて以下の機能を発見しました。 ALT0: CCM_ENET_QOS_CLOCK_GENERATE_RX_CLK ALT1: ENET_QOS_RX_ER ALT5: GPIO1_IO25 当社のPHYTEC SOM割り当てでは、この信号はSOMピンA25に関連付けられています。 私の懸念は、RGMIIからMIIへの移行に関するものです。必要なイーサネット信号はRGMIIとMIIで異なります。 以下の点について明確にしておきたいと思います。 1. i.MX 8M Plus ENET_QOS MACはRGMIIやRMIIに加えて、真のMIIインターフェースをサポートしていますか? 2. 真のMIIがサポートされている場合、MII_RX_CLK、MII_RX_DV、MII_RX_ER、MII_RXD0~MII_RXD3、MII_TX_CLK、MII_TX_EN、およびMII_TXD0~MII_TXD3の正しいi.MX 8M Plusピンマッピングは何ですか? 3. ENET_RXCパッドの場合、ALT0、CCM_ENET_QOS_CLOCK_GENERATE_RX_CLKはRGMII専用ですか?それともこの機能はMIIの受信クロックとして使えますか? 4. RGMIIからMIIへの移行中、MIIインターフェースのENET_RXCパッドにENET_QOS_RX_ERが必要ですか? 5. MII_RX_ERが必要な場合、IOMUXを通じて他の利用可能な i.MX 8M Plusパッドに割り当てられますか?それともこの信号は内部的にそのENET_RXCパッドに紐づいているのでしょうか? 6. PHYTEC phyCORE-i.MX8M Plus SOMを使用している場合、MIIインターフェースの実装に伴い考慮すべきSOMルーティングの制限はありますか? 7. もしMIIがサポートされている場合、i.MX 8M Plus MIIのMAC-to-PHYピン構成およびデバイスツリー構成の正しい例や参考文献を誰か教えていただけますか? この説明の理由は、現在ボッシュ社製カスタムキャリアボードのピン配置図と回路図を作成しているためです。SOMとキャリアボードのピン配置を変更する前に、MII信号のマッピングが正しいことを確認したい。 当社のBSPからの関連するピンマルチプレクサ情報は以下のとおりです。 ENET_RXC ALT0: CCM_ENET_QOS_CLOCK_GENERATE_RX_CLK ALT1: ENET_QOS_RX_ER ALT5: GPIO1_IO25 i.MX 8M Plus ENET_QOS MACで真のRGMIIからMIIへの移行がサポートされているのか、もしサポートされているなら、どのように扱うべきENET_RXCやRX_ERを扱うべきか、誰か確認していただけますか? よろしくお願いします。 Re: i.MX 8M Plus: RGMII to MII Migration – ENET_RXC / RX_ER Pin Assignment こんにちは、 NXP Semiconductors製品にご関心いただきありがとうございます。 この問題は このトピックに関連しています。 このThreadでENET_QOS詳細を追加します。以前は聞かれていなかったので。 ENETもENET_QOS/EQOSもMIIをサポートしていません。以下のEQOSのRM情報を参照してください。 RMII(10/100Mbps)、RGMII(10/100/1000Mbps) DSより: 1.8V/3.3V RMII動作、1.8V RGMII動作 この投稿では、ENET信号がEQOS信号とインターフェースしていることについて言及しています。NET信号はNETモジュールに対応し、ENET_QOSはEQOSモジュールに対応します。PHYTEC SOM内の利用可能な信号が希望する機能にマッピングできるか必ず確認してください。pinfunc.hをベースに設定できます。  または設定ツール。 i.MX用設定ツールはこちらからダウンロードしてください。 よろしくお願いします。
查看全文
imx93 lvds,内核版本 6.12 我正在尝试让 LVDS 显示屏在 imx93 定制板上工作。我遇到了这个错误: imx-lcdif 4ae30000.lcd-controller: probe with driver imx-lcdif failed with error -2 添加一些跟踪信息后,发现这是驱动程序中的这一行代码(在函数 lcdif_load 中)。 lcdif->clk_axi = devm_clk_get(drm->dev, "axi"); if (IS_ERR(lcdif->clk_axi)) return PTR_ERR(lcdif->clk_axi); 所以,它似乎找不到“axi”时钟。 我使用的是内核中的设备树,即 imx93.dtsi。作为基础,其中包括以下几行: clock-names = "pix", "disp-axi", "disp-apb"; assigned-clocks = <&clk IMX93_CLK_VIDEO_PLL>, <&clk IMX93_CLK_MEDIA_DISP_PIX>, <&clk IMX93_CLK_MEDIA_AXI>, <&clk IMX93_CLK_MEDIA_APB>; 所以这里设备树和驱动程序之间存在一些不一致之处。问题是我不知道这些时钟是否正确,也不知道我应该使用哪个。 我尝试查看 6.18 分支的内容,但是这部分(lcdif 控制器)已从 imx93.dtsi 文件中完全消失了。 有什么提示吗? Re: imx93 lvds with kernel 6.12 好的,找到一个原因了,这是因为使用了错误的驱动程序。现在,使用 lcdif_v3 驱动程序,不存在时钟问题。 另一方面,我仍然会遇到这个问题。 imx93-ldb ldb-display-controller:无法与 4ae30000.lcd-controller 创建设备链接 (0x180)。 有什么提示吗? Re: imx93 lvds with kernel 6.12 你好@julienblanc 希望你一切都好。 你的问题仍然存在吗? 顺祝商祺! 萨拉斯。 Re: imx93 lvds with kernel 6.12 很遗憾,不行。 我一直遇到同样的错误。以下是我尝试的配置方法: backlight_lvds: backlight-lvds { compatible = "pwm-backlight"; status = "okay"; power-supply = <&display_power_12v>; brightness-levels = < 0 5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 80 85 90 95 100>; default-brightness-level = <30>; pwms = <&pwm_backlight 0 1000000 0>; }; pwm_backlight: pwm_gpio { compatible = "pwm-gpio"; #pwm-cells = <3>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_clko4_gpio>; gpios = <&gpio4 29 GPIO_ACTIVE_HIGH>; // gpio controller &gpio4, pin 29 status = "okay"; }; panel { compatible = "panel-lvds"; width-mm = <224>; height-mm = <126>; backlight = <&backlight_lvds>; status = "okay"; port { panel_in: endpoint { remote-endpoint = <&lvds_ldb_out>; }; }; panel-timing { clock-frequency = <72400000>; hactive = <1280>; vactive = <800>; hfront-porch = <72>; hback-porch = <88>; hsync-len = <20>; vfront-porch = <15>; vback-porch = <23>; vsync-len = <10>; de-active = <1>; pixelclk-active = <1>; }; }; &ldb { status = "okay"; lvds-channel@0 { #address-cells = <1>; #size-cells = <0>; status = "okay"; port@1 { reg = <1>; lvds_ldb_out: endpoint { remote-endpoint = <&panel_in>; }; }; }; &ldb_phy { status = "okay"; }; display_power 在 exander 上占用大量 GPIO: display_power_12v: gpio_regulator { gpio-hog; gpios = <12 GPIO_ACTIVE_HIGH>; output-high; label = "DISPLAY12V"; }; 这主要取材于设备树中的一些示例。我搞不清楚哪里出了问题,也不知道为什么显示屏无法启动,甚至连背光都打不开。我知道我应该使用 TPM 而不是软件 GPIO,但这需要硬件修复,目前我只能暂时这样处理,但我认为这并不是问题的根源。 感谢您的支持! 此致, 朱利安
查看全文
カーネル6.12を使用したimx93 lvds imx93カスタムボード上でLVDSディスプレイを動作させようとしています。このエラーで困っています。 imx-lcdif 4ae30000.lcd-controller: probe with driver imx-lcdif failed with error -2 トレースを追加すると、これはドライバのこのライン(関数lcdif_load)から来ます lcdif->clk_axi = devm_clk_get(drm->dev, "axi"); if (IS_ERR(lcdif->clk_axi)) return PTR_ERR(lcdif->clk_axi); つまり、「axi」クロックが見つからないようです。 私はカーネルのデバイスツリー、imx93.dtsiを使用しています。ベースとして、以下の行が含まれます。 clock-names = "pix", "disp-axi", "disp-apb"; assigned-clocks = <&clk IMX93_CLK_VIDEO_PLL>, <&clk IMX93_CLK_MEDIA_DISP_PIX>, <&clk IMX93_CLK_MEDIA_AXI>, <&clk IMX93_CLK_MEDIA_APB>; つまり、デバイスツリーとドライバの間には多少の矛盾があります。問題は、時計が正確かどうか、どの時計を使うべきか分からないことです。 6.18のブランチに何があるか確認しようとしましたが、この部分(LCDIFコントローラー)はIMX93.dtsiファイルから完全に消えてしまいました。 何かヒントはありますか? Re: imx93 lvds with kernel 6.12 わかりました。原因が一つ分かりました。これは間違ったドライバを使っていたことです。今はlcdif_v3ドライバなのでクロックの問題はありません。 一方で、この問題はまだあります IMX93-LDB LDB-Display-Controller: 4ae30000.lcd-controllerとデバイスリンク(0x180)を作成できません 何かヒントはありますか? Re: imx93 lvds with kernel 6.12 こんにちは、 @julienblanc お元気でお過ごしのことと思います。 まだ問題は解決していませんか? よろしくお願いいたします。 サラス。 Re: imx93 lvds with kernel 6.12 残念ながら、いいえ。 同じエラーが繰り返し発生します。私が試した設定方法は以下のとおりです。 backlight_lvds: backlight-lvds { compatible = "pwm-backlight"; status = "okay"; power-supply = <&display_power_12v>; brightness-levels = < 0 5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 80 85 90 95 100>; default-brightness-level = <30>; pwms = <&pwm_backlight 0 1000000 0>; }; pwm_backlight: pwm_gpio { compatible = "pwm-gpio"; #pwm-cells = <3>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_clko4_gpio>; gpios = <&gpio4 29 GPIO_ACTIVE_HIGH>; // gpio controller &gpio4, pin 29 status = "okay"; }; panel { compatible = "panel-lvds"; width-mm = <224>; height-mm = <126>; backlight = <&backlight_lvds>; status = "okay"; port { panel_in: endpoint { remote-endpoint = <&lvds_ldb_out>; }; }; panel-timing { clock-frequency = <72400000>; hactive = <1280>; vactive = <800>; hfront-porch = <72>; hback-porch = <88>; hsync-len = <20>; vfront-porch = <15>; vback-porch = <23>; vsync-len = <10>; de-active = <1>; pixelclk-active = <1>; }; }; &ldb { status = "okay"; lvds-channel@0 { #address-cells = <1>; #size-cells = <0>; status = "okay"; port@1 { reg = <1>; lvds_ldb_out: endpoint { remote-endpoint = <&panel_in>; }; }; }; &ldb_phy { status = "okay"; }; display_powerはExander上でGPIOを大量に消費します。 display_power_12v: gpio_regulator { gpio-hog; gpios = <12 GPIO_ACTIVE_HIGH>; output-high; label = "DISPLAY12V"; }; これは主にデバイスツリー内のいくつかの例から引用したものです。何が問題なのか、なぜディスプレイが表示されず、バックライトも表示されないのか分かりません。ソフトウェアGPIOではなくTPMを使うべきだと分かっていますが、それはハードウェアの修正が必要で、今は対応していて、それが問題だとは思いません。 ご支援ありがとうございます。 よろしくお願いいたします。 ジュリアン
查看全文
i.MX 8M Plus:RGMII 到 MII 的迁移 – ENET_RXC / RX_ER 引脚分配 NXP社区的各位朋友,大家好! 我正在使用 NXP i.MX 8M Plus SoC 和 PHYTEC phyCORE-i.MX8M Plus SOM 开发定制以太网设计。 我们目前有一个基于 RGMII 的以太网设计,我们正在评估将我们的定制板从 RGMII 迁移到 MII 的可能性。 在引脚复用审查过程中,我发现 i.MX 8M Plus ENET_RXC 引脚具有以下功能: ALT0:CCM_ENET_QOS_CLOCK_GENERATE_RX_CLK ALT1:ENET_QOS_RX_ER ALT5:GPIO1_IO25 在我们的 PHYTEC SOM 分配中,该信号与 SOM 引脚 A25 相关联。 我担心的是 RGMII 到 MII 的迁移问题。RGMII 和 MII 所需的以太网信号不同。 我想澄清以下几点: 1. 除了 RGMII 和 RMII 之外,i.MX 8M Plus ENET_QOS MAC 是否支持真正的 MII 接口? 2. 如果支持真正的 MII,那么 i.MX 8M Plus 的 MII_RX_CLK、MII_RX_DV、MII_RX_ER、MII_RXD0 到 MII_RXD3、MII_TX_CLK、MII_TX_EN 和 MII_TXD0 到 MII_TXD3 的正确引脚映射是什么? 3. 对于 ENET_RXC 焊盘,ALT0、CCM_ENET_QOS_CLOCK_GENERATE_RX_CLK 是否仅用于 RGMII,或者该功能是否可以用作 MII 接收时钟? 4. 在 RGMII 到 MII 迁移期间,MII 接口是否需要 ENET_RXC 焊盘上的 ENET_QOS_RX_ER? 5. 如果需要 MII_RX_ER,能否通过 IOMUX 将其分配给另一个可用的 i.MX 8M Plus 焊盘,还是该信号内部与 ENET_RXC 焊盘关联? 6. 由于我们使用的是 PHYTEC phyCORE-i.MX8M Plus SOM,在实现 MII 接口时,是否需要考虑 SOM 路由方面的任何限制? 7. 如果支持 MII,能否提供 i.MX 8M Plus MII MAC 到 PHY 引脚配置和设备树配置的示例或参考资料? 之所以要进行此项澄清,是因为我们目前正在为博世定制载板准备引脚复用和原理图。在更改 SOM 和载板引脚分配之前,我们希望确认正确的 MII 信号映射。 我们的 BSP 中相关的 pinmux 信息如下: ENET_RXC ALT0:CCM_ENET_QOS_CLOCK_GENERATE_RX_CLK ALT1:ENET_QOS_RX_ER ALT5:GPIO1_IO25 请问有人可以确认 i.MX 8M Plus ENET_QOS MAC 是否支持真正的 RGMII 到 MII 迁移吗?如果支持,应该如何处理 ENET_RXC 和 RX_ER? 谢谢! Re: i.MX 8M Plus: RGMII to MII Migration – ENET_RXC / RX_ER Pin Assignment 您好, 感谢您对恩智浦半导体产品的关注, 这个问题与这个主题相关。 由于之前没有问到 ENET_QOS 的详细信息,我将在本帖中补充这些信息。 ENET 和 ENET_QOS / EQOS 均不支持 MII,请参考 EQOS RM 提供的以下信息: RMII(10/100Mbps),RGMII(10/100/1000Mbps) 来自DS: 1.8V/3.3V RMII 操作,1.8V RGMII 操作 帖子中提到了 ENET 信号与 EQOS 信号的接口。ENET 信号对应于 ENET 模块,而 ENET_QOS 对应于 EQOS 模块。请务必检查 PHYTEC SOM 中可用的信号是否可以映射到您所需的功能,您可以参考pinfunc.h文件。或配置工具。 在此处下载 i.MX 配置工具。 此致
查看全文
i.MX 8M Plus: RGMII to MII Migration – ENET_RXC / RX_ER Pin Assignment Hello NXP Community, I am working on a custom Ethernet design using the NXP i.MX 8M Plus SoC with a PHYTEC phyCORE-i.MX8M Plus SOM. We currently have an Ethernet design based on RGMII, and we are evaluating a migration from RGMII to MII for our custom board. During the pinmux review, I found the following functions for the i.MX 8M Plus ENET_RXC pad: ALT0: CCM_ENET_QOS_CLOCK_GENERATE_RX_CLK ALT1: ENET_QOS_RX_ER ALT5: GPIO1_IO25 In our PHYTEC SOM allocation, this signal is associated with SOM pin A25. My concern is related to the RGMII to MII migration. The required Ethernet signals are different between RGMII and MII. I would like to clarify the following points: 1. Does the i.MX 8M Plus ENET_QOS MAC support a true MII interface in addition to RGMII and RMII? 2. If true MII is supported, what is the correct i.MX 8M Plus pin mapping for MII_RX_CLK, MII_RX_DV, MII_RX_ER, MII_RXD0 to MII_RXD3, MII_TX_CLK, MII_TX_EN, and MII_TXD0 to MII_TXD3? 3. For the ENET_RXC pad, is ALT0, CCM_ENET_QOS_CLOCK_GENERATE_RX_CLK, intended only for RGMII, or can this function be used as the MII receive clock? 4. During an RGMII to MII migration, is ENET_QOS_RX_ER on the ENET_RXC pad required for the MII interface? 5. If MII_RX_ER is required, can it be assigned to another available i.MX 8M Plus pad through IOMUX, or is this signal internally associated with the ENET_RXC pad? 6. Since we are using a PHYTEC phyCORE-i.MX8M Plus SOM, are there any SOM routing limitations that need to be considered for implementing the MII interface? 7. If MII is supported, could someone provide an example or reference for the correct i.MX 8M Plus MII MAC-to-PHY pin configuration and device-tree configuration? The reason for this clarification is that we are currently preparing the pinmux and schematic for a Bosch custom carrier board. We want to confirm the correct MII signal mapping before changing the SOM and carrier-board pin allocation. The relevant pinmux information from our BSP is: ENET_RXC ALT0: CCM_ENET_QOS_CLOCK_GENERATE_RX_CLK ALT1: ENET_QOS_RX_ER ALT5: GPIO1_IO25 Could someone please confirm whether a true RGMII-to-MII migration is supported on the i.MX 8M Plus ENET_QOS MAC and, if so, how ENET_RXC and RX_ER should be handled? Thank you. Re: i.MX 8M Plus: RGMII to MII Migration – ENET_RXC / RX_ER Pin Assignment Hi, Thank you for your interest in NXP Semiconductor products, This issue is related to this topic. I will add in this thread the ENET_QOS details since they were not asked previously. Neither ENET nor ENET_QOS / EQOS support MII, please refer to the following information from RM of EQOS: RMII (10/100Mbps), RGMII (10/100/1000Mbps) From DS: 1.8 V/3.3 V RMII operation, 1.8 V RGMII operation Post mentions ENET signals interfacing EQOS signals. ENET signals correspond to ENET module, while ENET_QOS correspond to EQOS module, make sure to review that an available signal in PHYTEC SOM can be mapped to your desired function, you can base in pinfunc.h  or config tools. Download Config Tools for i.MX here. Regards
查看全文
imx93 lvds with kernel 6.12 I'm trying to make an LVDS display work on an imx93 custom board. I'm struggling with this error : imx-lcdif 4ae30000.lcd-controller: probe with driver imx-lcdif failed with error -2 After adding some traces, this comes from this line in the driver (in function lcdif_load) lcdif->clk_axi = devm_clk_get(drm->dev, "axi"); if (IS_ERR(lcdif->clk_axi)) return PTR_ERR(lcdif->clk_axi); So, it seems it cannot find the "axi" clock. I'm using the device tree from the kernel, imx93.dtsi, as the base, which includes the following lines: clock-names = "pix", "disp-axi", "disp-apb"; assigned-clocks = <&clk IMX93_CLK_VIDEO_PLL>, <&clk IMX93_CLK_MEDIA_DISP_PIX>, <&clk IMX93_CLK_MEDIA_AXI>, <&clk IMX93_CLK_MEDIA_APB>; So there's some inconsistency here between the device tree and the driver here. Problem is that i don't know if the clocks are correct, which ones i should use. I tried to have a look to what is in the 6.18 branch, but this part (lcdif controller) has completely disappeared from the imx93.dtsi file. Any hints? Re: imx93 lvds with kernel 6.12 Ok, found one cause, this was using the wrong driver. Now, with the lcdif_v3 driver, no clock issues. On the other hand, i still get this problem imx93-ldb ldb-display-controller: Failed to create device link (0x180) with 4ae30000.lcd-controller Any hints ? Re: imx93 lvds with kernel 6.12 Hello @julienblanc  Hope you are doing very well. Are you still having the issue? Best regards, Salas. Re: imx93 lvds with kernel 6.12 Unfortunately, no. I keep having the same error. Here's how i tried to configure things : backlight_lvds: backlight-lvds { compatible = "pwm-backlight"; status = "okay"; power-supply = <&display_power_12v>; brightness-levels = < 0 5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 80 85 90 95 100>; default-brightness-level = <30>; pwms = <&pwm_backlight 0 1000000 0>; }; pwm_backlight: pwm_gpio { compatible = "pwm-gpio"; #pwm-cells = <3>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_clko4_gpio>; gpios = <&gpio4 29 GPIO_ACTIVE_HIGH>; // gpio controller &gpio4, pin 29 status = "okay"; }; panel { compatible = "panel-lvds"; width-mm = <224>; height-mm = <126>; backlight = <&backlight_lvds>; status = "okay"; port { panel_in: endpoint { remote-endpoint = <&lvds_ldb_out>; }; }; panel-timing { clock-frequency = <72400000>; hactive = <1280>; vactive = <800>; hfront-porch = <72>; hback-porch = <88>; hsync-len = <20>; vfront-porch = <15>; vback-porch = <23>; vsync-len = <10>; de-active = <1>; pixelclk-active = <1>; }; }; &ldb { status = "okay"; lvds-channel@0 { #address-cells = <1>; #size-cells = <0>; status = "okay"; port@1 { reg = <1>; lvds_ldb_out: endpoint { remote-endpoint = <&panel_in>; }; }; }; &ldb_phy { status = "okay"; }; display_power is a gpio-hog on an exander : display_power_12v: gpio_regulator { gpio-hog; gpios = <12 GPIO_ACTIVE_HIGH>; output-high; label = "DISPLAY12V"; }; This is mostly taken from some examples in the device-trees. I can't get what's wrong, or why it won't bring the display up, even not the backlight. I know i should use a TPM instead of a software gpio, but that need a hardware fix, currently i have to deal with it and i don't think that's the problem. Thanks for your support, Regards, Julien
查看全文
i.MX8MP ENET_RXC/A25 Pinmux Clarification for MII Interface We are developing a custom board using the PHYTEC phyCORE-i.MX8M Plus SOM and are reviewing the Ethernet pinmux for migration from the existing RGMII interface to MII. The PHYTEC SOM pin A25 is associated with the i.MX8M Plus ENET_RXC signal. In the i.MX8MP pinmux, ENET_RXC supports ALT0 = CCM_ENET_QOS_CLOCK_GENERATE_RX_CLK and ALT1 = ENET_QOS_RX_ER. We need clarification regarding the correct pin assignment and interface requirements for the intended MII configuration. Specifically, is ENET_RXC required for the MII receive interface, or can the required RX_ER function be assigned to another suitable i.MX8M Plus pad/GPIO? If a different pad can be used, please provide the recommended pin mapping. We also need confirmation of whether the i.MX8M Plus ENET_QOS controller supports the intended MII interface and whether any IOMUX, MAC, device-tree, GPR, or PHY configuration changes are required. Please advise on the recommended Ethernet pin mapping and configuration for the i.MX8M Plus with the PHYTEC phyCORE SOM. Re: i.MX8MP ENET_RXC/A25 Pinmux Clarification for MII Interface Hi, Thank you for your interest in NXP Semiconductor products, i.MX 8M Plus does not support MII, please refer to the following extract from RM: Seamless interface to commercial ethernet PHY devices via one of the following: a 2-bit Reduced MII (RMII) operating at 50 MHz. a (double data rate) 4-bit Reduced GMII (RGMII) operating at 125 MHz. For signal mapping, you can refer to i.MX 8M Plus DS. Regards
查看全文
i.MX8M Quad – M4 Core Boot Steps and Required U-Boot Commands I am working with an i.MX8M Quad EVK SD card image and would like to understand the correct procedure for booting and running an application on the Cortex-M4 core from U-Boot. I have downloaded the MCUXpresso SDK for the i.MX8M Quad and successfully compiled the Hello World example for the M4 core. I now have the generated .bin firmware file. Please provide the correct U-Boot commands and boot sequence to load and start this M4 .bin firmware from U-Boot? And how to check M4 console ? #imx8mq #m4 #cortex-m4 #boot_m4 #UBoot #yocto #uboot-commands i.MX 8 Family | i.MX 8QuadMax (8QM) | 8QuadPlus Linux Yocto Project Re: i.MX8M Quad – M4 Core Boot Steps and Required U-Boot Commands Hello, Step-by-Step U-Boot Commands 1. Prepare the SD Card Copy your compiled .bin file (e.g., hello_world.bin ) to the FAT/boot partition (partition 1) of the SD card before inserting it into the EVK. 2. Stop U-Boot Autoboot Power on the board and immediately press any key to interrupt autoboot at the U-Boot prompt. 3. Option A — TCM Execution (Recommended for MCUXpresso SDK apps) This is the standard method for MCUXpresso SDK Hello World examples, which are linked to run from TCM at 0x1FFE0000 (alias 0x7E0000 😞 # Step 1: Load .bin from SD card FAT partition into a DDR staging buffer u-boot=> fatload mmc 1:1 0x48000000 hello_world.bin # Step 2: Copy the image from DDR staging buffer into the M4's TCM u-boot=> cp.b 0x48000000 0x7e0000 0x20000 # Step 3: (Optional but recommended) Flush data cache before starting M4 u-boot=> dcache flush # Step 4: Release M4 from reset and start execution from TCM u-boot=> bootaux 0x7e0000   You should see output like: ## Starting auxiliary core stack = 0x20020000, pc = 0x1FFE0305...       3. Option B — DDR Execution If your binary is linked to run from DDR (e.g., 0x80000000 😞 u-boot=> fatload mmc 1:1 0x80000000 hello_world.bin u-boot=> dcache flush u-boot=> bootaux 0x80000000   ⚠️ Important: Use 0x7e0000 (TCM) or 0x80000000 (DDR) depending on the linker script used when you compiled the MCUXpresso SDK app. For the default Hello World example, TCM ( 0x7e0000 ) is the correct target. Optional: Clear Resource Table Area (for Hello World / bare-metal) If your image does not have an RPMsg resource table (like a simple hello_world.bin ), clear the resource table area to avoid garbage values that could confuse Linux later: u-boot=> mw 0xb80ff000 0 4 Optional: Run prepare_mcore (When Linux Will Also Boot) If you plan to continue booting Linux after starting the M4, run this additional command before bootaux . It configures clocks so Linux does not disable M4-used clocks: u-boot=> fatload mmc 1:1 0x48000000 hello_world.bin u-boot=> cp.b 0x48000000 0x7e0000 0x20000 u-boot=> run prepare_mcore u-boot=> bootaux 0x7e0000     Checking the M4 Console The i.MX8MQ EVK uses an FTDI USB-serial chip that enumerates two separate COM ports when connected to the PC: Port Core Lower number (e.g., COM9 / /dev/ttyUSB0 ) Cortex-A53 (U-Boot / Linux console) Higher number (e.g., COM10 / /dev/ttyUSB1 ) Cortex-M4 console       Settings for both ports: 115200 baud, 8 data bits, No parity, 1 stop bit (115200 8N1). Open two separate terminal windows (e.g., TeraTerm, minicom, PuTTY): Terminal 1 → Lower COM port → for U-Boot commands Terminal 2 → Higher COM port → to see M4 Hello World output Quick Reference: Automation via Environment Variables You can save these as U-Boot environment variables for convenience: u-boot=> setenv m4_image hello_world.bin u-boot=> setenv m4_loadaddr 0x7e0000 u-boot=> setenv load_m4_image "fatload mmc '${mmcdev}':'${mmcpart}' 0x48000000 '${m4_image}'; cp.b 0x48000000 0x7e0000 0x20000" u-boot=> setenv run_m4_image "run load_m4_image; bootaux '${m4_loadaddr}'" u-boot=> saveenv # Then simply run: u-boot=> run run_m4_image     Key Reference Documents UG10163 — i.MX Linux User's Guide (Section 4.7.4) — Official M4 boot procedure for i.MX8M Quad AN5317 — Loading Code on Cortex-M from U-Boot/Linux for the i.MX — Deep dive on TCM vs DDR loading GS-MCIMX8M-EVK — Getting Started with the MCIMX8M-EVK — Board-specific step-by-step guide Regards
查看全文
MWCT2016 HSE 2.40.0 Secure Boot Configuration Failure- ImportPlainSymKeyReqMuChannel Environment MCU: MWCT2016S based Wireless Charging Controller Working Setup (Legacy): HSE FW Version: 2.6.0 (Application + Secure Boot) merge hex. New Setup (Failing): HSE FW Version: 2.40.0 (Application + Secure Boot) merge hex. We are migrating from HSE FW v2.6.0 to HSE FW v2.40.0 while maintaining the same Qi key provisioning and Secure Boot flow. Problem Statement With HSE FW v2.6.0, the complete provisioning sequence executes successfully: HSE installation Erase Keys S2TP key slot provisioning Qi key programming Secure Boot configuration Application boots successfully With HSE FW v2.40.0, all provisioning steps complete successfully until Secure Boot configuration is started. During Secure Boot configuration the following API fails: ImportPlainSymKeyReqMuChannel() in secure boot code.   return HSE response: 0x55A5A399 which corresponds to:  #define HSE_SRV_RSP_INVALID_PARAM ((hseSrvResponse_t)0x55A5A399UL)   After this failure, Secure Boot configuration cannot be completed, and the ECU remains stuck in the Secure Boot code.   Provisioning Sequence Working Configuration (HSE 2.6.0) 00_Blank_MWCT2016_CodeFlash_DataFlash.hex Power Reset 01_HSE_flash.srec  version 2.6.0 Power Reset 02_EraseKeysSW.hex Power Reset 03_S2TP_KeySlotsAligned.srec  S2TP SW Version: 1.1.1 Power Reset Write Qi Keys via UART Power Reset Application+SecureBoot.hex Power Reset     HSE response after merge hex flashing from UART log:  HseStatus : 2848         bit 0   : 0 RFU         bit 1   : 0 HSE_SHE_STATUS_SECURE_BOOT         bit 2   : 0 HSE_SHE_STATUS_SECURE_BOOT_INIT         bit 3   : 0 HSE_SHE_STATUS_SECURE_BOOT_FINISHED         bit 4   : 0 HSE_SHE_STATUS_SECURE_BOOT_OK         bit 5   : 1 HSE_STATUS_RNG_INIT_OK         bit 6   : 0 HSE_STATUS_HOST_DEBUGGER_ACTIVE         bit 7   : 0 HSE_STATUS_HSE_DEBUGGER_ACTIVE         bit 8   : 1 HSE_STATUS_INIT_OK         bit 9   : 1 HSE_STATUS_INSTALL_OK         bit 10  : 0 HSE_STATUS_BOOT_OK         bit 11  : 1 HSE_STATUS_CUST_SUPER_USER         bit 12  : 0 HSE_STATUS_OEM_SUPER_USER         bit 13  : 0 HSE_STATUS_FW_UPDATE_IN_PROGRESS         bit 14  : 0 RFU         bit 15  : 0 RFU  smrCoreStatus_Get :  smrCoreStatus[1] : 0 , smrCoreStatus[0] : 0  smrStatus[1] : 0 , smrStatus[0] : 0   Code debug log HSE response:  ImportPlainSymKeyReqMuChannel-hseResp: 0x55a5aa33    LoadBootMacKey-hseResp: 0x55a5aa33    Generic_ImportKeys-hseResp: 0x55a5aa33    KeyProvisioningForJTAG-status: 1    SecureBootConfiguration-hseResp: 0x55a5aa33    KeyProvisioningToHseNVM-status: 1    NON_SECURE_IVT-BLOCK1-hseResp: 0x55a5aa33    SECURE_IVT-BLOCK0-hseResp: 0x55a5aa33    writeDefaultData    Running Secure Boot CFG program  Hse-FW Version : 0.13.0.2.6.0 , full mem  using interface version : 0.13.0.2.6.0  HseStatus : 2862         bit 0   : 0 RFU         bit 1   : 1 HSE_SHE_STATUS_SECURE_BOOT         bit 2   : 1 HSE_SHE_STATUS_SECURE_BOOT_INIT         bit 3   : 1 HSE_SHE_STATUS_SECURE_BOOT_FINISHED         bit 4   : 0 HSE_SHE_STATUS_SECURE_BOOT_OK         bit 5   : 1 HSE_STATUS_RNG_INIT_OK         bit 6   : 0 HSE_STATUS_HOST_DEBUGGER_ACTIVE         bit 7   : 0 HSE_STATUS_HSE_DEBUGGER_ACTIVE         bit 8   : 1 HSE_STATUS_INIT_OK         bit 9   : 1 HSE_STATUS_INSTALL_OK         bit 10  : 0 HSE_STATUS_BOOT_OK         bit 11  : 1 HSE_STATUS_CUST_SUPER_USER         bit 12  : 0 HSE_STATUS_OEM_SUPER_USER         bit 13  : 0 HSE_STATUS_FW_UPDATE_IN_PROGRESS         bit 14  : 0 RFU         bit 15  : 0 RFU  smrCoreStatus_Get :  smrCoreStatus[1] : 0 , smrCoreStatus[0] : 0  smrStatus[1] : 1 , smrStatus[0] : 1 Failing Configuration-HSE FW 2.40.0 reports: 00_Blank_MWCT2016_CodeFlash_DataFlash.hex Power Reset 01_S32K344_HSE_FW_UPDATE_v2_40_0.srec Power Reset 02_M210WLCUMBCD00A_WSB00.31_EraseKeySW_UART_ENABLE.hex Power Reset 03_S2TP_2_1_0_KeySlotsAligned.srec Power Reset Write Qi Keys via UART Power Reset Application+SecureBoot.hex Power Reset    HseStatus : 2912         bit 0   : 0 RFU         bit 1   : 0 HSE_SHE_STATUS_SECURE_BOOT         bit 2   : 0 HSE_SHE_STATUS_SECURE_BOOT_INIT         bit 3   : 0 HSE_SHE_STATUS_SECURE_BOOT_FINISHED         bit 4   : 0 HSE_SHE_STATUS_SECURE_BOOT_OK         bit 5   : 1 HSE_STATUS_RNG_INIT_OK         bit 6   : 1 HSE_STATUS_HOST_DEBUGGER_ACTIVE         bit 7   : 0 HSE_STATUS_HSE_DEBUGGER_ACTIVE         bit 8   : 1 HSE_STATUS_INIT_OK         bit 9   : 1 HSE_STATUS_INSTALL_OK         bit 10  : 0 HSE_STATUS_BOOT_OK         bit 11  : 1 HSE_STATUS_CUST_SUPER_USER         bit 12  : 0 HSE_STATUS_OEM_SUPER_USER         bit 13  : 0 HSE_STATUS_FW_UPDATE_IN_PROGRESS         bit 14  : 0 RFU         bit 15  : 0 RFU  smrCoreStatus_Get :  smrCoreStatus[1] : 0 , smrCoreStatus[0] : 0  smrStatus[1] : 0 , smrStatus[0] : 0 ImportPlainSymKeyReqMuChannel-hseResp: 0x55A5A399   after Power reset:  UML SW Version : WSB00.3B_UART_ENABLE    Running Secure Boot CFG program  Hse-FW Version : 0.13.0.2.40.0 , full mem  using interface version : 0.13.0.2.40.0    HseStatus : 2848         bit 0   : 0 RFU         bit 1   : 0 HSE_SHE_STATUS_SECURE_BOOT         bit 2   : 0 HSE_SHE_STATUS_SECURE_BOOT_INIT         bit 3   : 0 HSE_SHE_STATUS_SECURE_BOOT_FINISHED         bit 4   : 0 HSE_SHE_STATUS_SECURE_BOOT_OK         bit 5   : 1 HSE_STATUS_RNG_INIT_OK         bit 6   : 0 HSE_STATUS_HOST_DEBUGGER_ACTIVE         bit 7   : 0 HSE_STATUS_HSE_DEBUGGER_ACTIVE         bit 8   : 1 HSE_STATUS_INIT_OK         bit 9   : 1 HSE_STATUS_INSTALL_OK         bit 10  : 0 HSE_STATUS_BOOT_OK         bit 11  : 1 HSE_STATUS_CUST_SUPER_USER         bit 12  : 0 HSE_STATUS_OEM_SUPER_USER         bit 13  : 0 HSE_STATUS_FW_UPDATE_IN_PROGRESS         bit 14  : 0 RFU         bit 15  : 0 RFU  smrCoreStatus_Get :  smrCoreStatus[1] : 0 , smrCoreStatus[0] : 0  smrStatus[1] : 0 , smrStatus[0] : 0    ImportPlainSymKeyReqMuChannel-hseResp: 0x55a5a399 ECU getting stuck in secure boot only Re: MWCT2016 HSE 2.40.0 Secure Boot Configuration Failure- ImportPlainSymKeyReqMuChannel Hi @ShrikantM  Could you please share your key catalogs as well as the parameters used in the ImportPlainSymKeyReqMuChannel() function call? The reported error indicates that one or more HSE request parameters are invalid. BR, VaneB Re: MWCT2016 HSE 2.40.0 Secure Boot Configuration Failure- ImportPlainSymKeyReqMuChannel Hi @SwapnilGawade  Thank you for sharing the information. Based on your configuration, I have the following observations: The SHE key group is configured with HSE_KEY_OWNER_CUST as the owner. However, the HSE Service API Reference Manual specifies that, for an SHE key catalog configuration, the owner of an SHE key group must be set to HSE_KEY_OWNER_ANY. This is also demonstrated in the NVM SHE Key Catalog Configuration example. The targetKeyHandle passed to ImportPlainSymKeyReqMuChannel() is defined as: #define NVM_AES128_BOOT_KEY GET_KEY_HANDLE(HSE_KEY_CATALOG_ID_NVM, 1, 1)​ However, according to your NVM key catalog configuration, the AES key group is the third group (NvmKeyGroup_2). Based on this configuration, the correct definition for NVM_AES128_BOOT_KEY should be:  GET_KEY_HANDLE(HSE_KEY_CATALOG_ID_NVM, 2, 0)​ Re: MWCT2016 HSE 2.40.0 Secure Boot Configuration Failure- ImportPlainSymKeyReqMuChannel Hi @VaneB , We are using below key catalogs: /* Table containing NVM key catalog entries */ const hseKeyGroupCfgEntry_t aHseNvmKeyCatalog[] = {     /* NvmKeyGroup_0 */     {(HSE_MU0_MASK), HSE_KEY_OWNER_CUST, HSE_KEY_TYPE_SHE, 1U, 128U, {0U, 0U}},     /* NvmKeyGroup_1 */     {(HSE_MU0_MASK), HSE_KEY_OWNER_CUST, HSE_KEY_TYPE_ECC_PAIR, 1U, 256U, {0U, 0U}},     /* NvmKeyGroup_2 */     {(HSE_MU0_MASK), HSE_KEY_OWNER_CUST, HSE_KEY_TYPE_AES, 1U, 256U, {0U, 0U}},     /* Marker to end the key catalog */     {0U, 0U, 0U, 0U, 0U, {0U, 0U}} }; /* Table containing RAM key catalog entries */ const hseKeyGroupCfgEntry_t aHseRamKeyCatalog[] = {     /* RamKeyGroup_0 */     {(HSE_MU0_MASK), HSE_KEY_OWNER_CUST, HSE_KEY_TYPE_SHE, 1U, 128U, {0U, 0U}},     /* Marker to end the key catalog */     {0U, 0U, 0U, 0U, 0U, {0U, 0U}} }; For below function we receive HSE_SRV_RSP_INVALID_PARAM hseSrvResponse_t Generic_ImportKeys(void) {     hseSrvResponse_t srvResponse = HSE_SRV_RSP_GENERAL_ERROR;     /*Import key linked with SMR#0*/     srvResponse = ImportPlainSymKeyReqMuChannel(             MU0,             1U,             NVM_AES128_BOOT_KEY,             HSE_KEY_TYPE_AES,             ( HSE_KF_USAGE_VERIFY ),             0U,             aesEcbKeyLength,             aesEcbKey,             TRUE             );     ASSERT(HSE_SRV_RSP_OK == srvResponse );     if(HSE_SRV_RSP_OK != srvResponse)             goto exit;     /* load keys for SHE secure boot */     srvResponse = LoadBootMacKey();     ASSERT(HSE_SRV_RSP_OK == srvResponse );     if(HSE_SRV_RSP_OK != srvResponse)             goto exit; exit:     return srvResponse; } Please check attached global_defs.h for more details about the parameters. Thanks and Regards, Swapnil Gawade Re: MWCT2016 HSE 2.40.0 Secure Boot Configuration Failure- ImportPlainSymKeyReqMuChannel Hi @SwapnilGawade  According to your description, I noticed that you appear to have combined the DemoApp framework with the Hse_Ip drivers. Is my understanding correct? If so, what modifications have been applied? Also, have you disabled the data cache in your project? This is a common cause of the HSE_SRV_RSP_INVALID_PARAM error. All data objects used for communication with HSE must be forced to non-cacheable memory. I also noticed that you are passing HSE_DTCM_ADDR(pHseSrvDesc) as the pHseSrvDesc parameter to the Hse_Ip_ServiceRequest() function. Please refer to the thread HSE_ReadAdkp returning HSE_SRV_RSP_INVALID_ADDR, where my colleague explains some considerations regarding the use of HSE with DTCM memory. You may also want to take a look at Hse_Ip_ToAHBAddress(), which converts a local address into an HSE host address when TCM support is enabled. It could be useful in this scenario. Re: MWCT2016 HSE 2.40.0 Secure Boot Configuration Failure- ImportPlainSymKeyReqMuChannel Hi @VaneB , As per your suggestion I have done the changes, but it also gives similar response as HSE_SRV_RSP_INVALID_PARAM (0x55a5a399). After debugging we found that it, in ImportPlainSymKeyReqMuChannel(...)->EraseKeyReq(targetKeyHandle, HSE_ERASE_NOT_USED))->HSE_Send(muIf, muChannelIdx, gSyncTxOption, pHseSrvDesc)->Hse_Ip_ServiceRequest(u8MuInstance, u8MuChannel, pHseIp_Request , HSE_DTCM_ADDR(pHseSrvDesc))->Mu_Ip_SetTxRegister(Hse_Ip_apMuBase[u8MuInstance], u8MuChannel, (uint32)pHseSrvDesc) retruns response as HSE_SRV_RSP_INVALID_PARAM (0x55a5a399). The parameters of pHseSrvDesc are added in attached Mu_Ip_SetTxRegister-pHseSrvDesc.xlsx. Thanks and Regards, Swapnil Gawade
查看全文
i.MX8M 四核 – M4 核心启动步骤和所需的 U-Boot 命令 我正在使用 i.MX8M Quad EVK SD 卡镜像 ,想了解 从 U-Boot 启动并在 Cortex-M4 内核 上运行应用程序的正确步骤。 我已经下载了 适用于 i.MX8M 四核处理器的 MCUXpresso SDK ,并成功编译了 M4 内核的 Hello World 示例程序。现在我已经得到了生成的.bin 固件文件。 请提供正确的U-Boot 命令和启动顺序,以便从 U-Boot 加载并启动此 M4 .bin固件?以及如何查看 M4 控制台? #imx8mq #m4 #cortex-m4 #boot_m4 #UBoot #yocto #uboot命令 i.MX 8 系列 | i.MX 8QuadMax (8QM) | 8QuadPlus Linux Yocto Project Re: i.MX8M Quad – M4 Core Boot Steps and Required U-Boot Commands 你好, U-Boot 命令分步指南 1. 准备 SD 卡 复制你编译好的 .bin 文件文件(例如, hello_world.bin )在将 SD 卡插入 EVK 之前,将其写入 SD 卡的FAT/启动分区(分区 1)。 2. 停止 U-Boot 自动启动 打开板电源,然后立即按任意键中断 U-Boot 提示符处的启动。 3. 选项 A — TCM 执行(推荐用于 MCUXpresso SDK 应用) 这是 MCUXpresso SDK Hello World 示例的标准方法,这些示例链接到位于 0x1FFE0000 (别名 0x7E0000 的 TCM 运行。😞 # Step 1: Load .bin from SD card FAT partition into a DDR staging buffer u-boot=> fatload mmc 1:1 0x48000000 hello_world.bin # Step 2: Copy the image from DDR staging buffer into the M4's TCM u-boot=> cp.b 0x48000000 0x7e0000 0x20000 # Step 3: (Optional but recommended) Flush data cache before starting M4 u-boot=> dcache flush # Step 4: Release M4 from reset and start execution from TCM u-boot=> bootaux 0x7e0000   你应该看到类似这样的输出: ## Starting auxiliary core stack = 0x20020000, pc = 0x1FFE0305...       3. 选项 B — DDR 执行 如果您的二进制文件链接到 DDR 运行(例如, 0x80000000 😞 u-boot=> fatload mmc 1:1 0x80000000 hello_world.bin u-boot=> dcache flush u-boot=> bootaux 0x80000000   ⚠️ 重要提示: 根据编译 MCUXpresso SDK 应用程序时使用的 链接器脚本 ,使用 0x7e0000 (TCM) 或 0x80000000 (DDR)。 对于默认的 Hello World 示例,TCM( 0x7e0000 )是正确的目标。 可选:清除资源表区域(用于 Hello World / 裸机环境) 如果你的镜像没有RPMsg 资源表(例如简单的 hello_world.bin ),清除资源表区域,以避免产生可能在以后导致 Linux 系统混乱的垃圾值: u-boot=> mw 0xb80ff000 0 4 可选:运行 prepare_mcore (当 Linux 系统也启动时) 如果您计划在启动 M4 后继续启动 Linux,请在 bootaux 之前运行此附加命令。它配置时钟,使 Linux 不会禁用 M4 使用的时钟: u-boot=> fatload mmc 1:1 0x48000000 hello_world.bin u-boot=> cp.b 0x48000000 0x7e0000 0x20000 u-boot=> run prepare_mcore u-boot=> bootaux 0x7e0000     检查M4控制台 i.MX8MQ EVK 使用 FTDI USB 转串口芯片,连接到 PC 时会枚举两个独立的 COM 端口: 端口 内核 较低的编号(例如,COM9 / /dev/ttyUSB0 ) Cortex-A53(U-Boot/Linux 控制台) 更高的数字(例如,COM10 / /dev/ttyUSB1 ) Cortex-M4 控制台       两个端口的设置: 115200 波特率,8 位数据位,无奇偶校验,1 位停止位 (115200 8N1)。 打开两个独立的终端窗口(例如,TeraTerm、minicom、PuTTY): 终端 1 → 下方 COM 端口 → 用于 U-Boot 命令 终端 2 → 更高端口的 COM 端口 → 查看 M4 Hello World 输出 快速参考:通过环境变量实现自动化 为了方便起见,您可以将这些值保存为 U-Boot 环境变量: u-boot=> setenv m4_image hello_world.bin u-boot=> setenv m4_loadaddr 0x7e0000 u-boot=> setenv load_m4_image "fatload mmc '${mmcdev}':'${mmcpart}' 0x48000000 '${m4_image}'; cp.b 0x48000000 0x7e0000 0x20000" u-boot=> setenv run_m4_image "run load_m4_image; bootaux '${m4_loadaddr}'" u-boot=> saveenv # Then simply run: u-boot=> run run_m4_image     关键参考文件 UG10163 — i.MX Linux 用户指南(4.7.4 节) — i.MX8M 四核处理器的官方 M4 启动步骤 AN5317 — 通过 U-Boot/Linux 在 i.MX 上向 Cortex-M 加载代码— TCM 与 DDR 加载深度解析 GS-MCIMX8M-EVK — MCIMX8M-EVK 入门指南 — 针对特定开发板的逐步指南 此致
查看全文