Multi Source Translation Content

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

Multi Source Translation Content

ディスカッション

ソート順:
MCU 当社は自動車メーカー向けのMCUメーカーです。自社開発のSimulink制御アルゴリズムといくつかの故障診断プログラムを開発ボードに書き込んで正常に動作させることができるかどうかを検証したいと考えています。制御アルゴリズムを提供し、開発ボードを購入してモーターの動作を確認することは可能でしょうか? Re: MCU こんにちは@wpdbl さん、 ご連絡いただきありがとうございます。 Simulinkベースの制御アルゴリズムを対応MCU開発プラットフォームに展開し、ターゲットハードウェア上で検証することが可能です。ただし、具体的なセットアップや必要なハードウェア・ソフトウェアは、使用するMCUや開発ボードによって異なります。 以下の情報を教えていただけますか? どのMCUやMCUファミリをターゲットにしていますか? どの開発ボードを使う予定ですか? 現在使用しているMATLAB/Simulinkのバージョンとツールボックスは何ですか? どのようなモーターおよびモータ制御のアプリケーションを対象としていますか? これらの詳細をもとに、お客様のユースケースをよりよく理解し、適切なガイダンスを提供できます。 よろしくお願いいたします。 ドラゴス
記事全体を表示
MCXA145 闪存安全 早上好, 我想通过固件设置 MCXA145 的闪存安全位。 在 MCXC444 上,我以前需要进入启动文件进行配置;这里是否有类似的选项,而无需使用 MCUXpresso Secure Provisioning? 在生产环境中,他们只需加载 .axf 文件即可。文件,我希望它已经包含网络安全设置,以避免他们执行第二步操作。 您能就此事给我一些建议吗? 非常感谢 此致 Re: MCXA145 flash secure Hello MCXA 中的 Flash 网络安全等效项是读取保护 [ROP_STATE] ;ROP_STATE 是存储在 IFR0 中的一个 32 位字段;ROP 功能保护芯片的网络安全,用户可以根据自己应用的需求设置不同级别的 ROP。   在客户生产过程中,客户可以通过 ROP 根据自身需求对 ISP 和调试施加一定的限制。客户可以选择 ROP 等级 1 或 ROP 等级 2。重要提示:请注意每个 ROP 等级的限制,因为某些等级可能会进入不可退货的生命周期。 您可以使用安全配置工具配置生命周期设置 ROP 级别来构建映像,然后将映像用于生产设备。使用 MCUXpresso 安全配置简化了 ROP 配置过程,这是配置 CMPA 设置的推荐方法; 我强烈推荐您阅读这篇 NXP 社区帖子,其中包含更多相关信息以及 ROP 配置说明。 MCXA153 读出保护 以及参考手册中的相关信息 MCXA145 参考手册第 20.3、20.3.4 章 [读取保护] 如果您还需要其他帮助,请告诉我。 顺祝商祺!
記事全体を表示
MCU We are an MCU manufacturer for an automotive company. We want to verify whether our self-built Simulink control algorithm and some fault diagnosis can be burned into a development board and run successfully. Can we provide the control algorithm and simply purchase your development board to run it and observe the motor's operation? Re: MCU Hello @wpdbl, Thank you for reaching out. It is possible to deploy Simulink-based control algorithms to supported MCU development platforms and validate them on the target hardware. However, the exact setup and required hardware/software depend on the MCU and development board you intend to use. Could you please provide the following information? Which MCU or MCU family are you targeting? Which development board are you planning to use? Which MATLAB/Simulink version and toolboxes are you currently using? What type of motor and motor-control application are you targeting? With these details, we can better understand your use case and provide the appropriate guidance. Best regards, Dragos
記事全体を表示
TCL - EB Tresos v29.0.0 的工具置信度文件 亲爱的恩智浦管理员,你 能不能把关于 EB Tresos 的 TCL 文件发给我们,我在 MCAL/RTD 包里找不到这个文件。 如果可能的话,你能否将功能安全手册发给我们,或者告诉我们在哪里可以在 MCAL/RTD 中找到它? 致以最崇高的敬意 莎伦 Re: TCL - Tool confidence level document for EB Tresos v29.0.0 你好,@sharonfmc93、 TCL 有一些关于 EB Tresos 的信息,但还处于保密状态。您可以输入支持票据吗? 如果可能的话,你能否也给我们发功能安全手册,或者告诉我们在哪里可以在 MCAL/RTD 中找到它? 功能安全手册(以及所有与功能安全相关的信息)位于 S32K3 产品页面文档中的 " 安全文件 " 下: 如果您没有申请安全访问权限,可以查看我们的常见问题解答:安全访问权限常见问题解答|恩智浦半导体。 致以最诚挚的问候, Julián Re: TCL - Tool confidence level document for EB Tresos v29.0.0 嗨,朱利安 我没有找到任何关于 EB tresos TCL 级别的信息,你能指出是哪个文件吗? Re: TCL - Tool confidence level document for EB Tresos v29.0.0 嗨@allenlw , 对于 EB Tresos 而言,刀具冲击为 TI2,刀具检测为 TD1。 我们有一份文件描述了 EB tresos Studio 软件工具的 ISO 26262 置信度。但是,如前所述,本文件受保密协议约束。 请提交支持案例并提供有效的保密协议编号,以便我们能够共享您请求的文件。 致以最诚挚的问候, Julián
記事全体を表示
AFT26H250W03SR6(--24SR6) テスト回路部品レイアウト DXFファイル AFT26H250W03SR6(--24SR6)テスト回路コンポーネントレイアウトDXFファイルをサポートしられますか? 私たちはそれを非常に必要としています。 よろしくお願いします。
記事全体を表示
MRF300AN 27MHz VSWR Protection and Recovery Strategy We are developing a 300W, 27MHz CW RF generator for medical aesthetic applications using the MRF300AN. The load (handpiece) can momentarily open-circuit, and we need a robust protection and recovery strategy. We are not looking for an open-load safe power level (we know the 65:1 VSWR ruggedness is pulsed). We are trying to optimize the system-level protection architecture and recovery timing to prevent CW overstress. What we have implemented so far: A three-toroid directional coupler samples forward and reflected power. The detected DC levels feed a comparator with hysteresis; when reflected power exceeds the threshold, a latch is set and a shunt FET rapidly pulls the MRF300AN gate bias toward zero. The MCU can reset the latch, and the MCU also has control over the small-signal RF input level. In other words, we have the basic detect, compare, latch, and gate-bias pull-down chain in place, and the MCU can reset the latch and adjust drive level. Our concern and the specific gaps we need help with: The current recovery sequence is essentially MCU resets the latch, gate bias returns, and drive is restored. We recognize that this is too symmetric: protection should be fast, but recovery should be deliberate. We are not sure whether our overall architecture is the right one for this application, and we are not sure how to design the recovery timing so that (1) the PA is not re-activated while the open-load condition is still present, and (2) the first re-entry attempt does not itself create a secondary overstress event. Q1: Architecture Is our comparator-latch-gate-pull-down approach the right primary protection for 27 MHz CW, or is there a better topology for this power class and application? We have seen references to several alternatives, and we would appreciate NXP's application-level judgment on which direction is most appropriate for MRF300AN at 27 MHz in a CW medical generator: - PIN-diode-based shunt or switch protection at the PA output, to present a controlled impedance or isolate the PA during fault conditions. - Circulator/isolator with a terminated load, as commonly used in MRI and other medical RF chains, accepting the cost and volume penalty. - Layered protection, where a very fast hardware path handles the sudden open-circuit event and a slower path (MCU or ALC) manages foldback and recovery. - Keeping the comparator + latch + gate-bias pull-down as the primary protection and adding a TVS clamp as a last-line voltage clamp. For MRF300AN specifically at 27 MHz CW, is there a reason to prefer or avoid any of these? We are particularly interested in whether a PIN-diode output switch would meaningfully reduce the stress on the device compared to gate-bias pull-down alone, or whether it introduces its own loss and reliability trade-offs at this frequency and power level. Q2: Recovery timing We understand that blindly resetting the latch after a fault can cause the PA to chatter at the protection threshold and repeatedly inject stress. We would like NXP's guidance on the holdoff and re-entry scheme: - Should the system enforce a fixed holdoff time after a fault before any re-entry attempt is allowed? - During re-entry, is it acceptable to use a short low-power probe (e.g., a brief low-drive burst) to check whether the load has returned to a safe VSWR, and then ramp the drive slowly rather than stepping back to full power? NXP community guidance already recommends gradual power-up rather than abrupt full drive during initial bring-up; we are trying to extend that principle to fault recovery. - Is there an NXP-recommended ramp profile or re-entry power ceiling for MRF300AN in CW operation, or should this be treated purely as a system-level state-machine design independent of the device? Q3: TVS role In the NXP 27 MHz reference design discussion, a 110 V TVS from drain to ground was discussed, with the guidance that the standoff voltage should sit above the maximum normal drain voltage. In our system, we already have active reflected-power protection. Should the TVS be treated as a last-line clamp for the brief interval before the active protection responds, or is it expected to carry more of the protection burden? At 27 MHz CW, do the junction capacitance and response speed of a TVS introduce any concern for normal RF waveform fidelity? What would be most helpful: Any application-level guidance, a recommended architecture, a pointer to an existing NXP application note on VSWR protection and recovery for LDMOS PAs, or even a brief statement of how NXP's own reference designs handle the fault-holdoff-re-entry sequence, would directly inform our design. Thank you. Re: MRF300AN 27MHz VSWR Protection and Recovery Strategy Hello @fengyuqi , Thank you for the detailed description. Your comparator, hardware latch and active gate-bias pull-down form a reasonable primary protection path. For a 300W CW application, we would recommend using this as part of a layered architecture rather than relying on a single mechanism. Where possible, the fast hardware path should inhibit the RF drive and pull down the gate bias simultaneously. The MCU should not be part of the immediate shutdown loop; it should manage the subsequent holdoff, diagnostics, controlled re-entry, and repeated-fault lockout. A PIN-diode switch could reduce stress only if it transfers the PA output to a known and adequately rated impedance. Simply disconnecting the handpiece may present another open-circuit condition. At this power level, insertion loss, diode heating, voltage rating, switching transients and the impedance presented during switching must all be considered. A circulator with a rated termination provides stronger load isolation, but with significant size, cost and loss trade-offs. For recovery, a fixed minimum holdoff followed by a low-power probe and controlled drive ramp is a reasonable system-level approach. Both forward and reflected power should be monitored during the probe because the reflected-to-forward ratio may become inaccurate near the detector noise floor. Any new fault should immediately return the system to the latched state, and repeated unsuccessful attempts should result in a longer backoff or permanent lockout. NXP does not specify a dedicated holdoff time, ramp profile, or re-entry power ceiling for the MRF300AN. These values depend on the protection-chain response, stored energy in the matching network, detector dynamic range, bias settling, thermal conditions and the expected load behavior. They must therefore be determined and validated at the system level, including testing at multiple mismatch phase angles. The drain TVS should be considered a last-line transient clamp for the interval before the active shutdown becomes effective. It should not be expected to absorb continuous reflected RF power. Its standoff voltage, clamping behavior, pulse-energy capability, junction capacitance and package/layout parasitics must all be included in the RF and transient analysis, since the device can affect the 27 MHz output matching. The published MRF300AN 27 MHz reference design does not define a qualified fault-holdoff-re-entry sequence, so the complete protection architecture remains an application-specific design responsibility. Best regards, Pavel
記事全体を表示
ノートPC交換後にS32DS v3.5ライセンスアクティベーション失敗(FNPエラー0) こんにちは、NXPサポートチームの皆さん、 以前、古いノートPCでS32 Design Studio v3.5をアクティベートしていました。 最近ノートPCを交換しましたが、古いマシンにアクセスしてライセンスを返却できません。 新しいノートPCでS32DS v3.5を有効化しようとすると、以下のエラーが表示されます: 指定された数量は、許可されている最大数量(0)を超えています。(FNPエラー0) NXPライセンスポータルには、以下の情報も表示されます。 「このライセンスの返却は許可されていません。」 以前のライセンスの有効化をリセットするか、利用可能なアクティベーション数を増やして、新しいノートPCでS32DS v3.5をアクティベートできるようにしてもらえますか? [email protected] にも連絡を試みました が、SMTP エラー 550 5.4.1 でメールが拒否されました。 必要ならライセンス情報を個人的に提供できます。 ご協力ありがとうございました。 Re: S32DS v3.5 License Activation Failed After Laptop Replacement (FNP Error 0) こんにちは、 利用可能なライセンス数が増加しました。
記事全体を表示
TCL - Tool confidence level document for EB Tresos v29.0.0 Dear NXP Admins,  Could you please send us the TCL document regarding EB Tresos , i couldn't find this within the MCAL/RTD package.  If possible could you also send us the Safety Manuals, or tell us where to find it in the MCAL/RTD ? Best regards, Sharon Re: TCL - Tool confidence level document for EB Tresos v29.0.0 Hello @sharonfmc93, There is some information for TCL regarding EB Tresos, but it is under NDA. Can you enter a support ticket instead?  If possible, could you also send us the Safety Manuals, or tell us where to find it in the MCAL/RTD? Safety Manuals (and all safety-related information) is located under "Secure Files" from the S32K3 Product Page's documentation: If you have not requested secure access rights, you can go over our FAQs: Secure Access Rights FAQs | NXP Semiconductors. Best regards, Julián Re: TCL - Tool confidence level document for EB Tresos v29.0.0 Hi @allenlw, For EB Tresos Tool Impact is TI2, and Tool Detection is TD1. We have a document describing ISO 26262 confidence in software tools for EB tresos Studio. However, as mentioned previously, this document is covered under NDA. Please open a support case and provide an active NDA number so that the requested document can be shared. Best regards, Julián Re: TCL - Tool confidence level document for EB Tresos v29.0.0 Hi,julian     I didn't see any information regarding the EB tresos TCL level , can you point out which file?
記事全体を表示
MRF300AN 27MHz VSWR保護および回復戦略 私たちはこのMRF300ANを用いて、医療美容アプリケーション向けの300W、27MHzのCW RFジェネレーターを開発しています。荷重(ハンドピース)が一時的に開回路になることがあり、堅牢な保護と回復戦略が必要です。我々は、開放負荷時の安全な電力レベルを求めているわけではありません(65:1 VSWRの堅牢性はパルス状であることがわかっています)。CWへの過負荷を防ぐため、システムレベルの保護アーキテクチャと復旧タイミングの最適化に取り組んでいます。 これまでに実施したこと: 3つのトロイド方向カプラーは、前方および電力の反射をサンプリングします。検出された直流レベルはヒステリシスを伴うコンパレータに供給されます。反射電力が閾値を超えるとラッチが設定され、シャントFETがMRF300ANゲートバイアスを急速にゼロに引き寄せます。MCUはラッチをリセットでき、また小信号のRF入力レベルも制御できます。つまり、基本的な検出、比較、ラッチ、ゲートバイアスのプルダウンチェーンが整っており、MCUはラッチをリセットしドライブレベルを調整できます。 私たちの懸念と具体的な支援が必要なギャップ: 電流回復シーケンスは、基本的にMCUがラッチをリセットし、ゲートバイアスが戻り、ドライブが復元されるというものです。これはあまりにも対称的すぎると認識しています。保護は迅速に行われるべきですが、復旧は慎重に行われるべきです。このアプリケーションに全体のアーキテクチャが適しているか確信が持てず、回復タイミングのデザイン方法も不明です。(1) 開積力状態がまだ存在している間にPAが再作動しないこと、(2) 最初の再突入試み自体が二次的な過負荷イベント情報を生じさせないよう。 Q1:建築 コンパレータ-ラッチ-ゲート-プルダウン方式は27 MHz CWに対する適切な一次保護でしょうか?それともこの電力クラスとアプリケーションに適したトポロジーがあるのでしょうか?いくつかの代替案の言及を見ており、CW医療ジェネレーターの27 MHzでのMRF300ANにどの方向が最も適切かについて、NXPのアプリケーションレベルの判断をいただけるとありがたいです。 - PA出力にPINダイオードを用いたシャントまたはスイッチ保護を施し、障害時に制御インピーダンスを提示したりPAを絶縁したりします。 - MRIやその他の医療用RFチェーンで一般的に用いられる終端負荷を持つ循環器/アイソレーター。コストと体積のペナルティを受け入れます。 - レイヤー保護:非常に高速なハードウェアパスが突然のオープンサーキットイベント情報を処理し、より遅いパス(MCUまたはALC)がフォールドバックとリカバリーを管理します。 - コンパレータ+ラッチ+ゲートバイアスプルダウンを主な保護として保持し、最終線電圧クランプとしてTVSクランプを追加すること。 MRF300ANを特に27MHz CWで使用する場合、これらのうちどれかを好む、あるいは避けるべき理由はありますか?特に、PINダイオード出力スイッチがゲートバイアスプルダウン単独と比べてデバイスの負荷を実質的に軽減できるのか、それともこの周波数と電力レベルで自身の損失と信頼性のトレードオフが生じるのかに関心があります。 Q2:回復のタイミング 故障後に無差別にラッチをリセットすると、PAが保護閾値でチャタリングし、繰り返し応力を注入する可能性があることを理解しています。NXP社による保有期間延長および再参入制度に関するガイダンスを希望します。 ・システムは、障害発生後、再突入試行を許可する前に一定の待機時間を強制すべきでしょうか? 再突入時、負荷が安全なVSWRに戻ったかどうかを確認するために、短時間の低電力プローブ(例えば、短時間の低駆動バースト)を使用し、その後、駆動を徐々に増加させてから、全電力に戻すことは許容されますか?NXPコミュニティのガイダンスでは、初期起動時に急激にフルドライブするのではなく、徐々に電源を入れることを推奨しています。私たちはこの原則を故障復旧にも拡張しようとしています。 - CW動作時のMRF300ANにはNXP推奨のランププロファイルや再突入電力上限があるのか、それともこれはデバイスに依存しないシステムレベルの状態機械設計として扱うべきか? Q3:TVSの役割 NXP 27 MHzのリファレンス・デザインの議論では、ドレインからグラウンドまでの110V TVSについて議論され、スタンドオフ電圧は最大通常のドレイン電圧を上回るべきだというガイダンスが示されていました。当社のシステムには、既に能動的な反射電力保護機能が備わっています。TVSは、アクティブ保護が作動するまでの短い期間における最終ラインの遮断装置として扱うべきなのか、それとも保護機能のより大きな役割を担うことが期待されるのか?27 MHz CWでは、TVSの接合静電容量や応答速度が通常のRF波形忠実度に何か懸念をもたらすのでしょうか? 最も役立つものは以下の通りです: アプリケーションレベルのガイダンス、推奨アーキテクチャ、LDMOS PAのVSWR保護と回復に関する既存のNXPアプリケーションノートへの指針、あるいはNXP自身のリファレンス・デザインが故障・ホールドオフ再突入シーケンスをどのように扱っているかの簡単な説明があれば、デザインに直接反映されるでしょう。 よろしくお願いします。 Re: MRF300AN 27MHz VSWR Protection and Recovery Strategy こんにちは@fengyuqiさん 詳細な説明をありがとうございました。コンパレータ、ハードウェアラッチ、アクティブゲートバイアスプルダウンが合理的な一次保護経路を形成します。300WのCWアプリケーションでは、単一のメカニズムに頼るのではなく、レイヤーアーキテクチャの一部として利用することを推奨します。 可能な限り、高速なハードウェア経路はRFドライブを抑制しつつゲートバイアスを引き下げるべきです。MCUは即時のシャットダウンループの一部であってはなりません。その後のホールドオフ、診断、制御された再突入、繰り返しの故障ロックアウトを管理するべきです。 PINダイオードスイッチは、PA出力を既知で適切に定格されたインピーダンスに転送する場合のみ、ストレスを軽減できます。ハンドピースを単に接続解除するだけでも、別の断線状態が発生する可能性があります。この電力レベルでは、挿入損失、ダイオードの発熱、定格電圧、スイッチング過渡現象、およびスイッチング時に生じるインピーダンスをすべて考慮する必要があります。定格終端を持つ循環器は負荷のアイソレータを強化しますが、サイズ、コスト、損失のトレードオフが大きいです。 回復のためには、一定の最小ホールドオフに続いて低電力プローブと制御されたドライブランプを行うというシステムレベルのアプローチが妥当である。プローブ中は、前方電力と反射電力の両方を監視する必要がある。なぜなら、検出器のノイズフロア付近では、反射電力対前方電力比が不正確になる可能性があるからである。新たな障害が発生した場合は、システムは直ちにラッチ状態に戻り、繰り返し失敗した場合は、より長いバックオフ時間、または永久的なロックアウトとなるべきである。 NXPはMRF300ANについて、専用のホールドオフ時間、ランププロファイル、または再突入電力の上限値を規定していません。これらの値は、保護回路の応答、整合回路に蓄積されたエネルギー、検出器のダイナミックレンジ、バイアスの安定化、熱条件、および想定される負荷挙動に依存します。したがって、それらはシステムレベルで決定および検証される必要があり、複数の位相不整合角でのテストも含まれる。 ドレインTVSは、アクティブシャットダウンが有効になるまでの期間における最終ラインの過渡クランプとして考えるべきである。連続反射RF パワーを吸収することは期待できません。スタンドオフ電圧、クランプ挙動、パルスエネルギー能力、接合静電容量、パッケージ/レイアウトの寄生要素はすべてRFおよび過渡分析に含めなければなりません。なぜなら、デバイスは27 MHzの出力マッチングに影響を与える可能性があるためです。 公開されたMRF300AN 27 MHzリファレンスデザインには、適格な故障ホールドオフ再突入シーケンスは定義されていないため、完全な保護アーキテクチャはアプリケーション固有の設計責任に委ねられています。 よろしくお願いいたします。 パベル
記事全体を表示
Mifare Plus EV2のフルデータシートはどこで手に入りますか? MIFARE Plus EV2の完全なデータシートはどこで見つけられますか? AuthenticateSectorSwitchコマンドの使い方について詳細な手順が必要です。 Re: Where Can I Find Mifare Plus EV2 full datasheet? こんにちは、 @YangGyu DS 522334-MF1 P(H)x2 - MIFARE Plus EV2 リクエストは [email protected] 宛にメールでお送りください。 BR ケリー Re: Where Can I Find Mifare Plus EV2 full datasheet? ご指摘のファイルが見つかりません。 追加のリクエストを提出すべきでしょうか? Re: Where Can I Find Mifare Plus EV2 full datasheet? ご指摘のファイルが見つかりません。 追加のアクセス申請を提出すべきでしょうか?  Re: Where Can I Find Mifare Plus EV2 full datasheet? こんにちは、 @YangGyu https://www.nxp.com/products/MFPEV2?ticket=ST-2765-SsyUzuME1f4C5JrCBJ3-gU5P4Gk-nxp#myDocumentにアクセスして、以下を選択してください。 BR ケリー
記事全体を表示
i.MX 93 – プリビルドのUbuntu/Debian Linuxイメージおよびカスタムキャリアボードサポート こんにちは、NXPサポートチームの皆さん、 私はEVSEアプリケーション用に i.MX 93プラットフォームを評価しているところ、EVSE-IMX93開発キットに出会いました。 利用可能なLinuxイメージと、それらが潜在的なカスタムキャリアボードデザインとの互換性について明確にしたいと思います。 私たちの意図は、MCIMX93-SOMを用いて、元のNXPキャリアボードデザインを基にした簡素化されたカスタムキャリアボードを開発することです。使用していないペリフェラルや回路を除去しつつ、SOMコネクタとピンの割り当ては同じままにします。 私は i.MX プロセッサプラットフォームとYoctoベースの開発にはまだ比較的新しいため、カスタマイズに進む前にすぐに使えるLinuxソリューションを探しています。 以下の点を明確にしていただけますか? i.MX 93用の 使いやすいUbuntuやDebian 13(Trixie)イメージ はありますか ?できれば汎用サーバーや最小限のLinuxイメージが望ましいです。 このイメージは、Yoctoビルドなしで直接microSDカードにダウンロードしてフラッシュしてボードを起動できますか? 利用可能な画像はapt、Python 3、SSH、systemd、networkingなどの標準的なLinux機能をサポートしていますか? CAN/CAN-FD(SocketCAN)、Wi-Fi、イーサネット、MQTT のサポートは含まれています か?Mosquittoのようなパッケージはaptでインストールできますか? 元のSOMコネクタと関連するハードウェア接続を保持すれば、同じプリビルドイメージを提案しているカスタムキャリアボードに使うことは可能でしょうか?デバイスツリーまたは設定の変更のみが必要となるのでしょうか? もしそのような画像があれば、直接ダウンロードリンク、対応ボードの詳細、インストール手順を共有していただけると助かります。 私たちの目標は、i.MX 93をEVerestフレームワークやその他のEVSEアプリケーションソフトウェアを動かす汎用Linuxプラットフォームとして活用しつつ、最初にYoctoビルドの保守を回避することです。 ご協力ありがとうございました。 敬具 ガネーシュ・バグワット Re: i.MX 93 – Prebuilt Ubuntu/Debian Linux Image and Custom Carrier Board Support こんにちは、 はい、i.mx93プラットフォームに対応したDebian Linux SDKがあります。Yoctoではなく「Flexbuild」の実装を通じてイメージを構築し、flexinstallerツールでイメージをフラッシュできます。ディストリビューションのサポートパッケージについてはこちらで詳しくご覧いただけます: DEBIAN-SDK Debianソフトウェアリリースノート LDLSDK_26.06
記事全体を表示
i.MX95:在定制硬件上 OP-TEE xtest 测试失败 你好, 我最近将基于 i.MX95 (B0 rev) 的自定义硬件的 BSP 从 Linux 6.12.49_2.2.0 移植到了 Linux 6.18.37_2.1.0。突然,OP-TEE 的 xtest 开始出现测试失败的情况(xtest 输出已附上)。 经过一番调查,我发现故障源于 OP-TEE 核心无法验证从文件系统加载的 TA 上的 RSA 签名;这是由于 ELE 总是对 RSA 验证请求响应 ELE_INVALID_MESSAGE 造成的。 以下是 CFG_TEE_CORE_LOG_LEVEL=2 和 CFG_TEE_TA_LOG_LEVEL=2 时 OP-TEE 输出的摘录: E/TC:? 0 imx_ele_signature_verification:391 签名验证失败 res = ffff0006 ETC:?0 do_verify:514 RSA 签名验证失败 E/LD: init_elf:494 sys_open_ta_bin(cb3e5ba0-adf1-11e0-998b-0002a5d5c51b) ETC:?0 ldelf_init_with_ldelf:152 ldelf 失败,返回值为:0xffff000f 有什么建议可以帮助我调查吗? 先感谢您 Linux 安全 Re: i.MX95: OP-TEE xtest failing on custom hardware 我找到了罪魁祸首:新的 电路板支持包。 启用了 ELE 支持的 ECC 和 RSA,但它们依赖于已加载的 ELE 运行时固件。可以通过以下方式触发负载: echo 1 > /sys/kernel/se/se_load_fw 预期的 dmesg 输出为:   fsl-se secure-enclave-0:正在加载固件 imx/ele/mx95b0runtime-ahab-container.img fsl-se secure-enclave-0:固件已成功加载   Re: i.MX95: OP-TEE xtest failing on custom hardware 你好@fvalla-MTA 是的你是对的。 版本 6.18.37 需要加载 ELE 运行时固件。 B.R
記事全体を表示
生成式人工智能的应用:通过智能创新变革企业 生成式人工智能(GenAI)正在迅速改变企业的运营方式、创新方式以及与客户互动的方式。从自动化内容创作和智能聊天机器人到高级数据分析和人工智能驱动的应用,生成式人工智能正在成为现代数字化转型的重要组成部分。 然而,成功应用人工智能不仅仅是实施新技术。它关乎识别正确的商业机会、了解组织面临的挑战以及创造可衡量的价值。 生成式人工智能的日益普及 各行各业的组织都在探索生成式人工智能,以提高生产力、降低运营成本、加快决策速度并提供个性化的客户体验。 根据安永会计师事务所发布的《2025 年印度高管调查报告》,47% 的组织表示在生产环境中拥有多个生成式人工智能用例。这标志着从最初的实验阶段转向了实际的商业实施阶段。 一些关键的采用领域包括: 业务自动化:自动化重复性任务、工作流程和运营流程。 客户体验:开发智能虚拟助手和个性化客户互动。 内容创作:创建营销内容、报告、产品描述和商业沟通材料。 数据智能:从大型数据集中提取洞见,为明智的决策提供支持。 软件开发:加速编码、测试、文档编写和应用程序开发。 人工智能应用面临的挑战 尽管生成式人工智能具有巨大潜力,但企业在采用该技术时仍面临诸多挑战。数据隐私、模型准确性、集成复杂性、基础设施成本和负责任的人工智能治理仍然是重要的考虑因素。 组织还必须确保人工智能生成的输出结果可靠、透明,并符合业务需求。人工监督和持续评估对于建立人们对人工智能系统的信任至关重要。 研究驱动的生成式人工智能应用 Enaviya 认为,成功采用生成式人工智能始于研究、业务理解和正确的技术战略。 从研究和技术的角度来看,研究新兴人工智能模型如何解决现实世界的商业问题非常重要。这包括评估大型语言模型(LLM)、探索功能域特定的 AI 应用、了解自动化机会以及评估 AI 集成的实际影响。 Enaviya 致力于通过生成式人工智能开发、LLM 集成、人工智能代理、定制人工智能应用程序和智能自动化,将这些机遇已翻译为可扩展的业务解决方案。 研究驱动的方法可以帮助组织摆脱对人工智能工具的试验,专注于能够带来可衡量的业务成果的解决方案。 请在本帖中分享您的反馈意见。 Re: Generative AI Adoption: Transforming Businesses Through Intelligent Innovation 感谢分享这份概述——关于在推出新工具之前进行调研的观点真的让我很有共鸣。根据我的经验,那些从人工智能中获益最多的团队,是在漫长的测试和文档编写过程中安排适当的休息时间,并保持基本工作的正确性,而不是试图一次性完成所有事情。短暂的休息,喝杯好咖啡,确实能帮助我更清醒地重新思考问题。如果您喜欢在家中储备充足的物资,不妨看看这个网站。
記事全体を表示
关于 SIMULATED_IN_FIELD Lifecy 中间歇性 SYS_AUTH_REQ 和 NVM 密钥导入失败的调查 你好, 我们正在运行 HSE_B FW 2.40.0 的 S32K328 设备上,使用 SIMULATED_IN_FIELD 生命周期测试 SYS_AUTH_REQ 和 NVM 密钥导入服务。 在测试过程中,我们观察到这些服务的成功或失败取决于RESET周期和服务调用的顺序。我们希望您能协助我们澄清这一行为。 1. 测试环境和配置 - MCU:S32K328 - HSE 固件:S32K358_HSE_FW_2.40.0 - 目标生命周期:IN_FIELD - 测试生命周期:现场模拟 - NVM 密钥组所有者:HSE_KEY_OWNER_OEM SYS_AUTH_REQ 配置 - 授权密钥类型:AES - 授权密钥长度:256 位 - 授权密钥所有者:HSE_KEY_OWNER_OEM - 认证算法:AES-256-CMAC - sysAuthOption = HSE_SYS_AUTH_ALL - sysRights = HSE_RIGHTS_SUPER_USER SYS_AUTH 过程按如下方式执行: 1.调用 HSE_SRV_ID_SYS_AUTH_REQ 服务以接收来自 HSE 的质询。 2. 使用授权密钥在主机上计算 AES-256-CMAC。 3.使用计算出的 CMAC 调用 HSE_SRV_ID_SYS_AUTH_RESP 服务。 4. 身份验证成功后,授予 SU(超级用户)权限。 2. 测试程序 1. ECU启动 2. 将生命周期设置为 SIMULATED_IN_FIELD 3.调用 SYS_AUTH_REQ 或 NVM 密钥导入服务 4. 如果调用了 SYS_AUTH_REQ,则执行质询-响应过程 5. 检查服务执行结果 我们在多个RESET周期内重复了上述测试。 3. 观察到的行为 在多次RESET周期中重复测试后,我们观察到以下现象。 案例 1. SYS_AUTH_REQ 之后的 NVM 密钥导入 - SYS_AUTH_REQ 服务有时会成功,有时会失败。 - 如果初始 SYS_AUTH_REQ 服务成功,则通过质询-响应过程授予 SU 权限,并且在同一 RESET 周期内紧随其后的 NVM 密钥导入服务也会成功完成。 - 如果初始 SYS_AUTH_REQ 服务失败,则返回 HSE_SRV_RSP_NOT_ALLOWED (0xAA55A21CUL)。 - 在这种情况下,在同一 RESET 周期内立即调用的 NVM 密钥导入服务总是会成功。 案例 2. 首先请求导入 NVM 密钥 - NVM密钥导入服务有时会成功,有时会失败。 - 如果 NVM 密钥导入失败,则返回 HSE_SRV_RSP_NOT_ALLOWED (0xAA55A21CUL)。在同一RESET周期内紧随其后的 SU 授权过程 (SYS_AUTH_REQ → SYS_AUTH_RESP) 总是成功的。 - 相反,如果 NVM 密钥导入成功,则在同一RESET周期内紧随其后调用的 SYS_AUTH_REQ 服务始终返回 HSE_SRV_RSP_NOT_ALLOWED (0xAA55A21CUL)。 案例 3. 获取 SU 权限并完成 NVM 密钥导入后再次调用 SYS_AUTH_REQ - 即使初始 SYS_AUTH_REQ 和 SYS_AUTH_RESP 调用成功并授予了 SU 权限,随后 NVM 密钥导入服务也成功完成,但在同一 RESET 周期内再次调用 SYS_AUTH_REQ 总是返回 HSE_SRV_RSP_NOT_ALLOWED (0xAA55A21CUL)。 补充观察 我们还进行了 MCU RESET 后的测试,以调查这种行为是否可能是由于先前 RESET 周期中保留的 SU 权限引起的。 例如,我们观察到以下序列也存在同样的现象: 1.请致电NVM密钥导入服务。 2. NVM 密钥导入失败(HSE_SRV_RSP_NOT_ALLOWED)。 3. 执行MCU RESET。 4. 调用 SYS_AUTH_REQ 服务。 5. SYS_AUTH_REQ 失败(HSE_SRV_RSP_NOT_ALLOWED)。 6.请致电NVM密钥导入服务。 7. NVM密钥导入成功。 因此,根据我们目前的测试结果,很难断定这种行为是由先前RESET周期中保留的SU权限引起的。 总体而言,两项服务的成功与否取决于RESET周期,我们观察到一种趋势,即一项服务在另一项服务失败时反而会成功。 4. 问题 1. 现场模拟生命周期 - 在 SIMULATED_IN_FIELD 生命周期和实际 IN_FIELD 生命周期中,SYS_AUTH_REQ / SYS_AUTH_RESP 和 NVM 密钥导入服务的行为是否存在任何差异? - 在 SIMULATED_IN_FIELD 生命周期中使用这些服务是否存在任何已知的限制? 2. 重复的SU授权请求 - 在已授予 SU 权限的情况下,在同一 RESET 周期内再次调用 SYS_AUTH_REQ 是否会返回 HSE_SRV_RSP_NOT_ALLOWED? - 是否允许在同一个 RESET 周期内多次执行 SU 授权程序,或者是否有推荐的使用模式? 3. 实际 IN_FIELD 生命周期中的行为 - 同样的情况是否也会发生在实际的 IN_FIELD 生命周期中,也就是我们最终的目标生命周期中? - 在实际的 IN_FIELD 环境中,是否有推荐的可靠使用 SU 授权和 NVM 密钥导入的步骤? - 如果这些服务在实际的 IN_FIELD 生命周期中可靠运行,是否也允许在同一个 RESET 周期内多次执行 SU 授权程序? 4. 授权密钥配置 - 使用 256 位 AES 密钥的 AES-256-CMAC 进行 SYS_AUTH 认证是否有效? - 当授权密钥用于 SYS_AUTH 时,对授权密钥的密钥类型、密钥长度、密钥所有者或密钥用途是否有任何限制? 鉴于此事的紧迫性,我们非常感谢您的及时回复。 感谢您的支持。 Re: Inquiry Regarding Intermittent SYS_AUTH_REQ and NVM Key Import Failures in SIMULATED_IN_FIELD Li 你好, 这纯粹是我的失误。 一切运行正常。 给您带来的不便,敬请谅解。 如果您能删除这个问题,我将不胜感激。 感谢您的帮助。 Re: Inquiry Regarding Intermittent SYS_AUTH_REQ and NVM Key Import Failures in SIMULATED_IN_FIELD Li 嗨@wodudwo 你描述的行为在我看来有些不寻常,尤其是考虑到RESET周期之间的差异。 首先,我建议消除数据缓存可能造成的任何影响。请您在项目中完全禁用数据缓存,然后重新进行测试,看看情况是否会发生变化? 我还想确认一下时钟配置,以排除这方面的问题。请将您配置工具中相关时钟设置的截图发送给我。您是否在 UTEST DCF 中修改了 HSE_CLK_MODE_AND_GSKT_CTRL? 同时,我将检查是否存在与此场景相关的已知问题,并验证您提出的问题的答案。 此致, Lukas
記事全体を表示
Inquiry Regarding Intermittent SYS_AUTH_REQ and NVM Key Import Failures in SIMULATED_IN_FIELD Lifecy Hello, We are testing the SYS_AUTH_REQ and NVM Key Import services with the SIMULATED_IN_FIELD Lifecycle on an S32K328 device running HSE_B FW 2.40.0. During testing, we observed that the success or failure of these services varies depending on the Reset Cycle and the order in which the services are called. We would appreciate your assistance in clarifying this behavior. 1. Test Environment and Configuration - MCU: S32K328 - HSE Firmware: S32K358_HSE_FW_2.40.0 - Target Lifecycle: IN_FIELD - Test Lifecycle: SIMULATED_IN_FIELD - NVM Key Group Owner: HSE_KEY_OWNER_OEM SYS_AUTH_REQ Configuration - Authorization Key Type: AES - Authorization Key Length: 256-bit - Authorization Key Owner: HSE_KEY_OWNER_OEM - Authentication Algorithm: AES-256-CMAC - sysAuthOption = HSE_SYS_AUTH_ALL - sysRights = HSE_RIGHTS_SUPER_USER The SYS_AUTH procedure is performed as follows: 1. Call the HSE_SRV_ID_SYS_AUTH_REQ service to receive a challenge from the HSE. 2. Calculate AES-256-CMAC on the Host using the Authorization Key. 3. Call the HSE_SRV_ID_SYS_AUTH_RESP service with the calculated CMAC. 4. Upon successful authentication, SU (Super User) rights are granted. 2. Test Procedure 1. ECU Boot 2. Set the Lifecycle to SIMULATED_IN_FIELD 3. Call either the SYS_AUTH_REQ or NVM Key Import service 4. If SYS_AUTH_REQ is called, perform the Challenge-Response procedure 5. Check the service execution result We repeated the above tests over multiple Reset Cycles. 3. Observed Behavior After repeating the tests over multiple Reset Cycles, we observed the following behavior. Case 1. NVM Key Import after SYS_AUTH_REQ - The SYS_AUTH_REQ service sometimes succeeds and sometimes fails. - If the initial SYS_AUTH_REQ service succeeds, SU rights are granted through the Challenge-Response procedure, and the NVM Key Import service called immediately afterward within the same Reset Cycle also completes successfully. - If the initial SYS_AUTH_REQ service fails, it returns HSE_SRV_RSP_NOT_ALLOWED (0xAA55A21CUL). - In this case, the NVM Key Import service called immediately afterward within the same Reset Cycle is always successful. Case 2. NVM Key Import requested first - The NVM Key Import service sometimes succeeds and sometimes fails. - If NVM Key Import fails, it returns HSE_SRV_RSP_NOT_ALLOWED (0xAA55A21CUL). The SU authorization procedure (SYS_AUTH_REQ → SYS_AUTH_RESP) called immediately afterward within the same Reset Cycle is always successful. - Conversely, if NVM Key Import succeeds, the SYS_AUTH_REQ service called immediately afterward within the same Reset Cycle always returns HSE_SRV_RSP_NOT_ALLOWED (0xAA55A21CUL). Case 3. Calling SYS_AUTH_REQ again after obtaining SU rights and completing NVM Key Import - Even if the initial SYS_AUTH_REQ and SYS_AUTH_RESP calls succeed and SU rights are granted, followed by successful completion of the NVM Key Import service, calling SYS_AUTH_REQ again within the same Reset Cycle always returns HSE_SRV_RSP_NOT_ALLOWED (0xAA55A21CUL). Additional Observation We also performed tests after an MCU Reset to investigate whether this behavior could be caused by SU rights retained from a previous Reset Cycle. For example, we observed the same behavior with the following sequence: 1. Call the NVM Key Import service. 2. NVM Key Import fails (HSE_SRV_RSP_NOT_ALLOWED). 3. Perform an MCU Reset. 4. Call the SYS_AUTH_REQ service. 5. SYS_AUTH_REQ fails (HSE_SRV_RSP_NOT_ALLOWED). 6. Call the NVM Key Import service. 7. NVM Key Import succeeds. Therefore, based on our test results so far, it is difficult to conclude that this behavior is caused by SU rights being retained from a previous Reset Cycle. Overall, the success and failure of the two services vary depending on the Reset Cycle, and we have observed a tendency for one service to succeed when the other service fails. 4. Questions 1. SIMULATED_IN_FIELD Lifecycle - Is there any difference in the behavior of SYS_AUTH_REQ / SYS_AUTH_RESP and the NVM Key Import service between the SIMULATED_IN_FIELD and actual IN_FIELD Lifecycles? - Are there any known restrictions on using these services in the SIMULATED_IN_FIELD Lifecycle? 2. Repeated SU Authorization Requests - Is it expected that calling SYS_AUTH_REQ again within the same Reset Cycle, after SU rights have already been granted, returns HSE_SRV_RSP_NOT_ALLOWED? - Is it permitted to perform the SU authorization procedure multiple times within the same Reset Cycle, or is there a recommended usage pattern? 3. Behavior in the Actual IN_FIELD Lifecycle - Could the same behavior occur in the actual IN_FIELD Lifecycle, which is our final target Lifecycle? - Is there a recommended procedure for reliably using SU authorization and NVM Key Import in the actual IN_FIELD environment? - If these services operate reliably in the actual IN_FIELD Lifecycle, is it also permissible to perform the SU authorization procedure multiple times within the same Reset Cycle? 4. Authorization Key Configuration - Is it valid to use AES-256-CMAC with a 256-bit AES key for SYS_AUTH? - Are there any restrictions on the Authorization Key's Key Type, Key Length, Key Owner, or Key Usage when it is used for SYS_AUTH? Given the urgency of this issue, we would greatly appreciate your prompt response. Thank you for your support. Re: Inquiry Regarding Intermittent SYS_AUTH_REQ and NVM Key Import Failures in SIMULATED_IN_FIELD Li Hello, This was simply a mistake on my part. Everything is working as expected. I apologize for the inconvenience. I would appreciate it if you could delete this question. Thank you for your help. Re: Inquiry Regarding Intermittent SYS_AUTH_REQ and NVM Key Import Failures in SIMULATED_IN_FIELD Li Hi @wodudwo  The behavior you described seems somewhat unusual to me, especially considering the variation between reset cycles. As a first step, I would recommend eliminating any possible influence of the data cache. Could you please disable the data cache completely in the project and repeat the tests to see if the behavior changes? I would also like to verify the clock configuration, just to rule out any issue there. Please send me screenshots of the relevant clock settings from your configuration tool. Did you modified HSE_CLK_MODE_AND_GSKT_CTRL in UTEST DCF? In parallel, I will check whether there are any known issues related to this scenario and verify the answers to the questions you raised. Regards, Lukas
記事全体を表示
TCL - EB Tresos v29.0.0 のツール信頼度レベルに関するドキュメント NXP管理者の皆様へ EB Tresosに関するTCL文書を送っていただけますでしょうか。MCAL/RTDパッケージの中に見当たりませんでした。 可能であれば、セーフティマニュアルも送っていただけますか?もしくは、MCAL/RTDのどこに記載されているか教えていただけますか? よろしくお願いします、 シャロン Re: TCL - Tool confidence level document for EB Tresos v29.0.0 こんにちは、 @sharonfmc93 さん、 TCL社向けにEB Tresosに関する情報がいくつか存在するが、機密保持契約(NDA)の対象となっている。代わりにサポートチケットを発行していただけますか? 可能であれば、セーフティマニュアルも送っていただけますか?もしくは、MCAL/RTDのどこに記載されているか教えていただけますか? セーフティマニュアル(およびセーフティ関連情報すべて)は、 S32K3製品ページのドキュメントにある「セキュアファイル」にあります。 セキュアアクセス権限を申請していない場合は、よくある質問(FAQ)をご覧ください:セキュアアクセス権限に関するよくある質問 | NXP Semiconductors 。 よろしくお願いします、 ジュリアン Re: TCL - Tool confidence level document for EB Tresos v29.0.0 こんにちは、 @allenlw さん。 EB Tresosの場合、ツールインパクトはTI2、ツール検出はTD1です。 EB Tresos Studioのソフトウェアツールに対するISO 26262の信頼度を説明した文書があります。ただし、前述のとおり、この文書は秘密保持契約(NDA)の対象となります。 サポートCASEを開設し、依頼された書類を共有できるよう有効なNDA番号を提供してください。 よろしくお願いします、 ジュリアン Re: TCL - Tool confidence level document for EB Tresos v29.0.0 こんにちは、ジュリアン EBのTresos TCLレベルに関する情報は見当たりませんでしたが、どのファイルを教えてもらえますか?
記事全体を表示
生成型AIの導入:インテリジェントなイノベーションを通じてビジネスを変革する 生成型AI、マシン・ラーニング(機械学習)(GenAI)は、企業の運営方法、イノベーション、お客様との関わり方を急速に変えています。自動コンテンツ作成やインテリジェントチャットボットから高度なデータ分析、AI搭載アプリケーションに至るまで、生成AIは現代のデジタルトランスフォーメーションにおいて重要な一部となりつつあります。 しかし、AIの導入を成功させるには、単に新テクノロジを導入することだけではありません。それは、適切なビジネスチャンスを見極め、組織的な課題を理解し、測定可能な価値を創造することに関わる。 生成型AIの普及拡大 業界の組織が生産性向上、運用コスト削減、意思決定の迅速化、パーソナライズされたお客様体験の提供のために生成AIを模索しています。 EYの2025年インドCスイート調査によると、47%の組織が複数の生成AIのユースCASEを本環境で抱えていると報告しています。これは、初期の実験段階から、実際のビジネスへの導入へと移行していることを示している。 導入の主な分野には以下のようなものがあります。 ビジネスオートメーション:繰り返しの作業、ワークフロー、運用プロセスの自動化。 お客様体験:インテリジェントなバーチャルアシスタントとパーソナライズされた顧客対応の開発。 コンテンツ生成:マーケティングコンテンツ、レポート、製品説明、ビジネスコミュニケーションの作成。 データインテリジェンス:大規模データセットから洞察を抽出し、情報に基づいた意思決定を支援する。 ソフトウェア開発: コーディング、テスト、ドキュメント作成、アプリケーション開発の加速。 AI導入における課題 潜在能力は高いものの、企業が生成型AIを導入する際には、いくつかの課題に直面する。データプライバシー、モデルの精度、統合の複雑さ、インフラストラクチャコスト、責任あるAIガバナンスは依然として重要な考慮事項です。 組織はまた、AIが生成する出力が信頼性が高く、透明性があり、ビジネス要件に合致していることを確保しなければならない。AI搭載システムにおける信頼構築には、人間の監督と継続的な評価が不可欠です。 研究主導型生成AIの導入 Enaviyaでは、生成AIの成功はリサーチ、ビジネス理解、そして適切なテクノロジ戦略から始まると信じています。 研究およびテクノロジの観点からは、新興のAIモデルが現実世界のビジネス課題にどのように対応できるかを研究することが重要です。これには、大規模言語モデル(LLM)の評価、ドメイン特化したAIアプリケーションの探求、オートメーションの機会の理解、AI統合の実用的影響の評価が含まれます。 Enaviyaは、生成AI開発、LLM統合、AIエージェント、カスタムAIアプリケーション、インテリジェントオートメーションを通じて、これらの機会をスケーラブルなビジネスソリューションへと転換することに注力しています。 研究主導型のアプローチは、組織がAIツールの実験段階を超え、測定可能なビジネス成果をもたらすソリューションに焦点を当てるのに役立ちます。 ぜひこのThreadでご意見をお寄せください。 Re: Generative AI Adoption: Transforming Businesses Through Intelligent Innovation この概要を共有していただきありがとうございます。新しいツールを導入する前に調査を行うべきだという点は、非常に共感できました。私の経験では、AIの恩恵を最も得ているチームは、適切な休憩を設け、長時間のテストやドキュメント作成の際に基本をしっかり守るチームであり、すべてを一度に押し切ろうとするわけではありません。美味しいコーヒーを飲みながら少し休憩すると、頭がすっきりした状態で問題に取り組むことができる。ホームで良い備蓄を常に用意しておくのが好きな方は、このウェブサイトをご覧ください
記事全体を表示
i.MX95: カスタムハードウェアでOP-TEEのテストが失敗する こんにちは、 最近、カスタムハードウェア用にi.MX95(B0バージョン)用にBSPをLinux 6.12.49_2.2.0からLinux 6.18.37_2.1.0に移植しましたそして突然、OP-TEEのxtestがテストに失敗し始めました(xtestの出力を添付します)。 調査の結果、OP-TEEコアがファイルシステムからロードされたTA上のRSA署名を検証できないことが障害の原因であることが判明しました。これは、ELEがRSA検証要求に対して常にELE_INVALID_MESSAGEという応答を返すことが原因です。 以下は、CFG_TEE_CORE_LOG_LEVEL=2 および CFG_TEE_TA_LOG_LEVEL=2 の場合の OP-TEE 出力の抜粋です。 E/TC:? 0 imx_ele_signature_verification:391 署名検証に失敗しました res = ffff0006 等:?0 do_verify:514 RSA署名検証に失敗しました E/LD: init_elf:494 sys_open_ta_bin(cb3e5ba0-adf1-11e0-998b-0002a5d5c51b) 等:?0 ldelf_init_with_ldelf:152 ldelf が res: 0xffff000f で失敗しました 何を調べればいいか、何かアイデアはありますか? よろしくお願いします Linux Security Re: i.MX95: OP-TEE xtest failing on custom hardware 原因が判明しました。新しいBSPはELEを基盤としたECCとRSAを有効にしますが、それらはELEランタイムファームウェアがロードされていることを前提としています。負荷は以下の方法でトリガーできます: echo 1 > /sys/kernel/se/se_load_fw 期待されるdmesgの出力は以下のとおりです。   FSL-se セキュア・エンクレーブ-0: loading firmware IMX/ele/MX95B0runtime-ahab-container.img FSL-SE セキュア・エンクレーブ-0:ファームウェアの正常なロード   Re: i.MX95: OP-TEE xtest failing on custom hardware こんにちは、 @fvalla-MTAさん はい、おっしゃる通りです。バージョン6.18.37では、ELEランタイムファームウェアのロードが必要です。 B.R
記事全体を表示
使用 LPC4337 控制器和 LPCUSBLIB 接口条码扫描器时出现问题 你好 , 我目前正在研究使用lpcusblib(HID键盘主机示例)将条形码扫描器与LPC4337连接。 问题:USB1 主机在成功读取几次条形码后,仅接收到扫描器的第一个字符,然后就停止工作。重新扫描后,不会再进行数据传输。 我已经启用了 USB1 中断并使用了 HID_Host_ReceiveReport(),但我怀疑我缺少正确的 IN 数据包处理或报告清除。 有人在LPC微控制器上使用lpcusblib实现过HID条形码扫描吗?任何关于处理连续数据传输的指导或代码片段都将对我非常有帮助,不胜感激。 提前谢谢! #嵌入式系统 #LPC4337 #USB主机 #HID #固件 此致, LPC43xx 外设 USB Re: Issue in interfacing Barcode scanner using LPC4337 controller with LPCUSBLIB 您好@RDGC_member 请参阅以下主题:使用 LPC4337 控制器和 LPCUSBLIB 连接条形码扫描器时遇到的问题 - NXP 社区 BR 爱丽丝 Re: Issue in interfacing Barcode scanner using LPC4337 controller with LPCUSBLIB 我正在使用 LPCUSBLIB 库将 USB 条码扫描器与 LPC4337 控制器连接起来。我想知道清除管道缓冲器的条件是什么。有时候我能正确收到完整的条形码。有时扫描第一个字符后就收不到任何数据,而且USB线还会卡住,导致之后多次扫描条形码都收不到任何数据。
記事全体を表示
Generative AI Adoption: Transforming Businesses Through Intelligent Innovation Generative Artificial Intelligence (GenAI) is rapidly changing how businesses operate, innovate, and interact with customers. From automated content creation and intelligent chatbots to advanced data analysis and AI-powered applications, Generative AI is becoming an important part of modern digital transformation. However, successful AI adoption is not simply about implementing new technology. It is about identifying the right business opportunities, understanding organizational challenges, and creating measurable value. The Growing Adoption of Generative AI Organizations across industries are exploring Generative AI to improve productivity, reduce operational costs, accelerate decision-making, and deliver personalized customer experiences. According to EY's 2025 India C-suite survey, 47% of organizations reported having multiple Generative AI use cases in production. This indicates a shift from initial experimentation towards practical business implementation. Some of the key areas of adoption include: Business Automation: Automating repetitive tasks, workflows, and operational processes. Customer Experience: Developing intelligent virtual assistants and personalized customer interactions. Content Generation: Creating marketing content, reports, product descriptions, and business communications. Data Intelligence: Extracting insights from large datasets and supporting informed decisions. Software Development: Accelerating coding, testing, documentation, and application development. The Challenges Behind AI Adoption Despite its potential, businesses face several challenges when adopting Generative AI. Data privacy, model accuracy, integration complexity, infrastructure costs, and responsible AI governance remain important considerations. Organizations must also ensure that AI-generated outputs are reliable, transparent, and aligned with business requirements. Human oversight and continuous evaluation are essential for building trust in AI-powered systems. Research-Driven Generative AI Adoption At Enaviya, we believe successful Generative AI adoption begins with research, business understanding, and the right technology strategy. From a research and technology perspective, it is important to study how emerging AI models can address real-world business problems. This includes evaluating large language models (LLMs), exploring domain-specific AI applications, understanding automation opportunities, and assessing the practical impact of AI integration. Enaviya focuses on translating these opportunities into scalable business solutions through Generative AI development, LLM integration, AI agents, custom AI applications, and intelligent automation. A research-driven approach helps organizations move beyond experimenting with AI tools and focus on solutions that deliver measurable business outcomes. Please share your feedback in this thread. Re: Generative AI Adoption: Transforming Businesses Through Intelligent Innovation Thanks for sharing this overview — the point about doing the research before rolling out new tools really resonated with me. In my experience, the teams that get the most from AI are the ones that build in proper breaks and keep the basics right during long testing and documentation sessions, rather than trying to push through everything at once. A short pause with a decent coffee genuinely helps me come back to a problem with a clearer head. For anyone who likes to keep a good supply on hand at home, have a look at this website
記事全体を表示