Multi Source Translation Content

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

Multi Source Translation Content

ディスカッション

ソート順:
Application commands Dear All I see that freeMASTER Application Commands are not available in NODE RED nodes. Is it possibile to invoke them in some way ? Regards Paolo Re: Application commands Hi @pberna67, Unfortunately, application commands were not added to FreeMASTER;s Node-RED nodes. Currently, the only way you could add them is by extending `node-red-contrib-freemaster` Node.js module available in `FreeMASTER Node.js Modules` and then install them manually by running: npm i path_to_the_updated_node-red-contrib-freemaster from Node-RED's home folder ($HOME/.node-red). Kind regards, Iulian Re: Application commands Dear Iulian It is a pity 😞 ! need command  1) Are freeMASTER / FreeMaster lite still under development ? 2) Any plan to integrate Application commands in  the next release ?   I'm try approaching  FreeMaster (not lite) version which has the Application command, however here Node Red is not supported 😞 ! Paolo Re: Application commands Hi Paolo, FreeMASTER is actively developed and enhanced, whereas FreeMASTER Lite is primarily maintained through bug fixes and critical updates. The Application Commands feature has been available for many years. While it is still maintained and tested in FreeMASTER, there are currently no plans for further enhancements. Where possible, we recommend using alternative mechanisms to control the application (ex: using flag variables).   Iulian  
記事全体を表示
How to trigger different reset events on S32K3 for verification Is there a recommended way to trigger each reset source on the evaluation board for verification purposes? For example: DEBUG_DEST SW_DEST HSE_SNVS_RST ...... I want to know all bits corresponding to the register DES & FES Re: How to trigger different reset events on S32K3 for verification It is a bit tricky question. There is no direct injection mechanism for these reset events, and we do not have any dedicated testing code or scripts we could provide — with the exception of the SAF/eMCEM API covering the FCCU portions. That said, I looked into the possible options and the following are the sketched methods that should work in practice. Reset events on S32K3 fall into two categories based on how they can be triggered for verification — software-injectable and hardware-only — split across the two MC_RGM status registers, DES and FES. Software-injectable resets can be triggered directly from code: Direct SW commands — write MC_ME.MODE_CONF with DEST_RST or FUNC_RST and trigger MODE_UPD, maps to DES[SW_DEST] or FES[SW_FUNC] respectively Watchdog expiry — stop the SWT service loop to trigger a functional reset on each timeout, incrementing FREC; once FREC reaches FRET the next reset escalates to destructive and sets DES[MC_RGM_FRE] FCCU fault injection — use eMcem_InjectFault() or the FNCFC fake fault register to trigger functional or destructive reactions depending on NCF channel configuration; injecting a fault not in the configured NCF set specifically triggers the FOSU destructive reset path CMU threshold manipulation — write CMU_FC_x.LTCR/HTCR outside the actual running frequency to produce a CMU frequency fault reset, with reaction type (functional or destructive) controlled through DCM configuration Hardware-only resets require physical stimulation and have no software injection path: STCU_URF requires a PLL loss-of-lock to occur during a live LBIST or MBIST sequence HSE_TMPR_RST and HSE_SNVS_RST are security tamper events — intentionally not injectable via software as they protect cryptographic material FXOSC_FAIL, PLL_LOL, and the LVD flags require disturbing the crystal, PLL dividers, or supply rails at the hardware level Re: How to trigger different reset events on S32K3 for verification Hi David:         OK. Thank you!         We'll conduct a thorough study.
記事全体を表示
2026年版、最高の個人データ削除サービス:独立機関によるテストと比較 ⚡簡単な評決 6ヶ月間の実地独立テストを経て、 インコグニが1位にランクイン 完全自動化された除去とクラス最高の価値を約 月額約6.49ドル。 ⚡シークレットモード — 今すぐアクセス ➤➤   DeleteMeは2位にランクイン 人間中心のコンシェルジュ型サービスと、750名以上のブローカーを擁する業界トップクラスのネットワークが評価されています。どちらのサービスにも継続的な再監視機能が含まれており、これは2026年に注目すべき最も重要な機能の一つです。 ⚡DELETEME — 今すぐアクセス ➤➤   クイック比較表:2026年版おすすめデータ削除サービス 以下の表は、最も重要な指標であるオートメーションレベル、ブローカーデータベースの規模、年間請求における月額概算費用、および6か月間の実地テスト後の総合スコアに基づいて、5つのサービスすべてをランク付けしたものです。 # 月額料金で最適なサービス オートメーションブローカー対象 当社のスコア 🥇1 シークレットモード — 今すぐアクセス ➤➤ 編集者のおすすめ オートメーションと価値 約6.49ドル ✔ 満杯 180歳以上 ★★★★★ 5.0 🥈2 DELETEME — 今すぐアクセス ➤➤ 最高評価のサポート 人間による除去 約10.75ドル ✔ ハイブリッド 750以上 ★★★★★ 4.8 3 オプトリー 最も透明性の高い 削除の証明 約3.99ドル ✔ 満杯 200以上 ★★★★½ 4.5 4 オーラ オールインワン プライバシー保護+ウイルス対策+VPNバンドル 約12.00ドル ✔ 満杯 100+ ★★★★ 4.0 5 プライバシービー パワーユーザー きめ細かな制御と深度 約14.99ドル ✔ 満杯 150以上 ★★★★ 4.0 ※表示価格は、年間プランにおける月額概算料金です。2026年5月に検証済み。 2026年にデータ削除がもはや選択肢ではなくなる理由 2026年のデジタルプライバシーを取り巻く状況は、わずか5年前と比べても劇的に異なっているように見える。あなたの個人情報(自宅住所、電話番号、家族構成など)は、かつては迷惑メールの温床となる厄介な存在だったが、今やAIを活用した詐欺行為にとって不可欠なインフラストラクチャへと進化を遂げている。これは未来の脅威ではなく、まさに今起こっていることだ。 ターゲット広告からAIによるなりすましまで 10年前なら、データブローカーがあなたのプロフィールを使ってできる最悪のことは、それをテレマーケターに売ることだった。今日では、高度な生成型AIが広く利用可能になったことで、同じプロファイルが音声クローンやディープフェイクによるなりすましの設計図となってしまう。悪意のある人物が人物検索サイトからあなたの個人情報を入手した場合、あなたの知人から送られてきた本物のメッセージと見分けがつかないほど高度にパーソナライズされたフィッシングキャンペーンを作成する可能性があります。2026年には、 プライバシーは個人の安全の直接的な前提条件である ―単なる好みではない。 「再露出ライフサイクル」:削除依頼が一度だけでは不十分な理由 プライバシーの世界で最も危険な誤解の一つは、オプトアウトのリクエストを一度送信すれば問題が完全に解決するという考え方だろう。データブローカープラットフォームは、公開されている記録を継続的に再収集するように設計されている。削除が成功した後でも、彼らの自動クローラーは60日から90日以内にあなたのデータを再び取得することがよくあります。このサイクルは、 再曝露ライフサイクル ― だからこそ、IncogniやDeleteMeのようなサービスは 継続的な自動監視 単発的な掃討作戦ではなく。継続的な抑圧こそが、実際に有効な唯一の防御策である。 各サービスをどのようにテストし、ランク付けしたか このガイドに掲載されているすべてのランキングは、プレスリリースや検証されていないユーザーレビューではなく、6ヶ月間にわたる独立したテストに基づいています。実際に測定した内容は以下のとおりです。 📊 長期抑制 削除されたプロフィールが6ヶ月間を通して削除されたままだったかどうかを追跡し、新たな削除サイクルをトリガーすることなくデータが再び表示されることを許容したサービスにはペナルティを課しました。 🔍 スキャン周波数 ほぼリアルタイムまたは週ごとの監視を提供するサービスは、四半期ごとまたは月ごとのスキャンを実行するサービスよりもはるかに高い評価を得ており、2026年には不十分な頻度とみなされるだろう。 📁 ブローカーデータベースのカバー範囲 私たちは、掲載されているデータブローカーの数と質の双方を監査し、アクセス数の多い人物検索サイトやマーケティングデータアグリゲーターを、リスクの低い無名の情報源よりも優先しました。 💻 UXと透明性 私たちは、ダッシュボードの分かりやすさ、レポートの詳細さ、そして何よりも重要な点として、各サービスが実際に削除作業が完了したことを検証可能な文書による証拠を提供しているかどうかを評価しました。 INCOGNI — 今すぐアクセス ➤➤ 2026年レビュー:総合的に見て最高のデータ削除サービス 🥇 インコグニ - 総合ランキング1位 編集者のおすすめ 2026 ★★★★★ 5.0 / 5.0 月額約6.49ドル(年間請求) 🏚Surfsharkによる🌎 グローバルな適用範囲(GDPR + CCPA)📋 180名以上のブローカー🔄 継続的なモニタリング インコグニは2026年の私たちの明確なナンバーワン候補であり、 総合的に見て最高の個人データ削除サービス マーケットに出回っている。Surfshark VPNを開発したのと同じチームによって作成されたこのサービスは、GDPRとCCPAの両方の枠組みの下で、データ消去権を行使する法的プロセスを自動化するために特別に設計されています。設定は数分で完了します。Incogniに代理で行動する権限を与えると、プラットフォームは法的拘束力のあるオプトアウト要求を180以上のデータブローカーに送信し、データが再び出現した場合は自動的に監視して再送信します。 インコグニの決定的な強みは、 価格、オートメーション、そして国際的な展開力。年間プランで月額約6.49ドルという価格設定は、私たちがテストしたどの競合サービスよりも、費用対効果に優れている。ダッシュボードはすっきりとして直感的で、進捗状況レポートは理解しやすく、継続的な再監視ループにより、最初のスキャン後も決して無防備な状態になることはありません。これは、再暴露ライフサイクルを断ち切るために必要なまさにその防御策です。 こんな方に最適です: 完全自動化された、手間のかからないプライバシー保護ソリューションを、世界規模の法的補償付きで、最も競争力のある価格で手に入れたい方に最適です。 ✅長所 マーケット最安値(月額約6.49ドル) 100%自動化 - 手作業は一切不要 GDPRに完全準拠した180社以上のブローカーデータベース 継続的な再監視と自動再削除 リアルタイムの進捗状況を表示する、すっきりとした直感的なダッシュボード 定評のあるサーフシャークブランドに支えられています ❌短所 極めて複雑なCASEに対する人的サポートは提供されません。 DeleteMeよりもブローカー数が少ない(180社に対し750社以上) 手動カスタマイズオプションは限られています DELETEME — 今すぐアクセス ➤➤ レビュー2026:人間主導のサポートに最適 🥈 DeleteMe — 総合ランキング2位 最高の人間主導型サービス ★★★★★ 4.8 / 5.0 月額約10.75ドル(年間請求) 🏚アビネ著🇺🇸 米国中心+国際📋 750人以上のブローカー👥 人間と自動化システムのハイブリッド DeleteMeは、純粋な自動化では不十分な部分をうまく処理することで、第2位の地位を獲得しました。業界をリードするデータベースを備えた 750社以上のデータブローカーを擁し、当社がテストしたどのサービスよりも幅広い範囲をカバーしています。さらに重要なのは、DeleteMeは自動化システムの上に人間の専門知識を重ね合わせている点です。プライバシーの専門家からなる専任チームが、自動化されたオプトアウトを日常的に無視または拒否する頑固なブローカーからの削除リクエストに対応します。 状況が複雑な場合(非常に一般的な名前、複数の住所の履歴、あるいはあまり知られていない地域のディレクトリにデータが掲載されている場合など)、DeleteMeのコンシェルジュスタイルのアプローチにより、何も見落とされることはありません。詳細な四半期報告書は高いレベルの透明性を文書化しており、ファミリプランの選択肢は各家庭にとって実用的である。より高い価格(約10.75ドル/月)これは、人的労力が投入されていることを反映しており、プロレベルの監視を必要とするユーザーにとっては十分に正当化される。 こんな方に最適です: 複雑なプライバシー保護ニーズを持つユーザーで、可能な限り幅広いブローカーのサービス範囲と、削除作業を積極的に管理する専門家による安心感を求めているユーザー。 ✅長所 業界最大のブローカーデータベース:750以上のサイト 人間のプライバシー専門家は、困難な例外的なケースに対処する 詳細な四半期報告書と実績 長年の実績(2010年設立) ファミリプランオプションで一人当たりの費用を削減 ❌短所 Incogniよりも月額料金が高い(約10.75ドル/月) リアルタイムではなく、四半期ごとのサイクルで報告する インターフェースはIncogniのダッシュボードほど洗練されていない。 その他の推奨サービス:Optery、Aura、Privacy Bee Optery ― 透明性において最高(第3位) Opteryは、他に類を見ない検証基準により、第3位の地位を獲得しました。そのダッシュボードは、公開されたプロフィールへの直接リンクをユーザーに提供する。 前に 削除リクエストが送信され、テストしたサービスの中で唯一 スクリーンショットに基づく証明 個々の撤去作業がすべて完了したことを確認する。月額約3.99ドルからという価格設定は、このリストの中で最も手頃な選択肢であり、透明性を鵜呑みにしない予算重視のユーザーにとって魅力的な選択肢となる。主な制約は、そのチーム体制とフォローアップの積極性が、IncogniやDeleteMeにまだ及ばない点である。 Aura — 最高のオールインワンセキュリティスイート(第4位) Auraは、デジタルセキュリティ対策全体を単一のサブスクリプションに統合したいユーザーにとって最適なソリューションです。月額約12ドルで、自動データ削除機能、ウイルス対策、VPN、信用情報監視機能を1つの統合プラットフォームにまとめているため、特にファミリに適しています。削除ツール自体は完全に自動化されていて効果的ですが、100以上のサイトを登録しているブローカーデータベースは、上位2つのツールと比べて明らかに規模が小さいです。 Privacy Bee ― パワーユーザーに最適(ランキング5位) Privacy Beeは、デジタルフットプリントをきめ細かく、精密に制御したいと考える、プライバシーにこだわるユーザー向けに作られています。月額約14.99ドルと、このリストの中で最も高額なオプションですが、最も詳細なカスタマイズオプションを提供します。特定のブローカーカテゴリを優先したり、特定のデータタイプをターゲットにしたり、削除スケジュールを精密に設定したりできます。その複雑さゆえに、何も考えずに問題を解決したいだけの一般ユーザーにはあまり適していない。 IncogniとDeleteMe:どちらを選ぶべきか? これは個人データ削除に関して最もよく寄せられる質問なので、簡潔かつ率直な回答を以下に示します。 選ぶ 匿名 最高の価格、完全なエンドツーエンドのオートメーション、グローバルなGDPRおよびCCPAへの対応、そして継続的な作業が一切不要なダッシュボードをお求めなら。これは大多数のユーザーにとって最適な選択です。 選ぶ 削除 もしあなたが本当に複雑なプライバシー問題を抱えている場合、可能な限り広範なブローカーデータベース(750以上)を希望する場合、またはあなたのCASEを積極的に管理・検証する専門家による安心感が必要な場合。 どちらのサービスにも継続的な再監視が含まれており、これは2026年においては譲れない条件となる。どちらの方法も、手作業による除去や何もしないよりも、はるかに優れた長期的な保護効果をもたらします。 データ削除を超えて:包括的なプライバシー戦略の構築 ダークウェブ監視と信用情報追跡 データ削除は、重大な情報漏洩経路の一つに対処するものですが、それだけでは完全なセキュリティ対策にはなりません。ダークウェブの監視は、重要な第二の層を追加します。情報漏洩であなたの認証情報が流出した場合、発見が遅れるのではなく、即座に警告を受ける必要があるからです。それに加えて、信用情報監視サービスも利用すれば、誰かがあなたの名義で口座を開設したり、取引を行ったりしようとした場合に、即座に通知を受け取ることができます。 パスワード管理と多要素認証 パスワードが漏洩すると、プライバシー保護のためにこれまで行ってきたあらゆる対策が無駄になってしまう可能性があります。専用のパスワードマネージャーを使用することで、すべてのサービスで固有かつ複雑な認証情報を維持でき、単一のパスワードによるセキュリティ侵害のリスクを排除できます。利用可能な場所では必ず多要素認証を有効にし、可能な限りSMSではなく認証アプリを使用してください。SMSベースの多要素認証はSIMスワッピング攻撃に対して脆弱ですが、適切な認証アプリを使用すればこれを防止できます。 デバイスレベルのセキュリティ:ウイルス対策と指紋認証ブロッカー ローカルデバイスが最終的な境界線となります。2026年において、強力なウイルス対策ソフトウェアはもはや選択肢ではなく必須となる。現代のマルウェアは、ファイル、認証情報、行動データを密かに収集するように設計されているからだ。さらに、サードパーティのトラッカーを積極的にブロックし、フィンガープリンティング(データブローカーがCookieを一切使用せずに、ブラウザの設定や閲覧パターンに基づいてユーザーの詳細なプロファイルを作成する手法)に抵抗するブラウザ拡張機能を併用することをお勧めします。 2026年におけるあなたの法的権利:CCPA、GDPR、そしてサービス提供者によるそれらの権利の利用方法 CCPAと拡大する米国のプライバシーフレームワーク カリフォルニア州消費者プライバシー法およびその後の改正により、米国の消費者は、データブローカーに対し、自身の個人情報の削除を要求する法的権利を有する。2026年現在、法令遵守違反に対する罰則はより明確になり、オプトアウトのインフラストラクチャも成熟している。次のようなサービス 匿名 そして 削除 彼らはあなたの代理として法的代理人として機能し、あなたの消費者権利に基づいて拘束力のあるオプトアウト要求を提出し、規制上の罰則をちらつかせてブローカーにあなたの記録を削除するよう強制します。 GDPR:グローバルデータ権利基準 EUまたは英国に拠点を置くユーザーにとって、一般データ保護規則(GDPR)は依然として最も強力なプライバシー保護手段である。GDPRの消去権は、EU居住者のデータを扱うあらゆる組織に厳格な義務を課している。Surfsharkを開発したヨーロッパのチームによって開発されたIncogniは、GDPRへの準拠を念頭に置いて特別に設計されており、世界中のブローカーに対して強制力のある削除要求を提出できるため、国際的なユーザーにとって特に価値のあるツールとなっている。 DIYアプローチ:有料サービスを利用せずにデータを削除する方法 手作業によるデータ削除は予算ゼロでも可能ですが、相当な時間と継続的な規律が求められます。基本的なプロセス: 氏名、居住都市、州を主要な人物検索サイト(Spokeo、Whitepages、BeenVerified、Intelius、MyLifeなど)で検索してみましょう。これらが最優先で始めるべきサイトです。 各サイトのオプトアウトページ、または「個人情報の販売を拒否する」ページを探してください。通常、サイトのフッターにあるプライバシーポリシーの下に隠れています。 各オプトアウト手順を完了し、確認メールを証拠として保存してください。 定期的に再スクレイピングを行うと削除したデータが元に戻ってしまうため、3~4か月ごとにこのプロセス全体を繰り返すようにカレンダーにリマインダーを設定してください。 ほとんどの人にとって、手作業による除去にかかる時間コストを考えると、次のようなサービスを利用する方が得策だ。 Incogniは月額約6.49ドル 経済的に見て、明白な選択である。とはいえ、リスク許容度が本当に低く、体系的なプロセスに取り組む忍耐力があるなら、自動化に投資する前に、まずは手作業から始めるアプローチが有用な基盤となり得る。 インターネットから個人データを削除する準備はできていますか? デジタル上の足跡を晒すのはやめましょう。まずは当社の最高評価のサービスをご利用いただき、今日からあなたの個人情報の管理権を取り戻しましょう。 ↑ 上記のすべてのサービスを比較する よくある質問 2026年において、最も優れたデータ削除サービスは何ですか? 匿名 は、2026年のデータ削除サービスの中で最高ランクに位置付けられています。完全オートメーション、グローバルな法的適用範囲、そしてプレミアムプランにおける最低価格(月額約6.49ドル)の組み合わせにより、総合ランキング1位を獲得しました。 削除 ランキング2位であり、複雑な状況を抱え、専門家によるCASEを希望するユーザーにとってより良い選択肢です。   2026年におけるIncogniの価格はいくらですか? Incogni の費用は約 月額6.49ドル 年間プランの場合(約77.88ドル、年1回請求)。月払いオプションもご利用いただけますが、料金は高くなります。これにより、現在マーケットに出回っているプレミアムデータ削除サービスの中で、最も費用対効果の高いサービスとなっています。   DeleteMeの料金は2026年にはいくらになりますか? DeleteMe の費用は約 月額10.75ドル 年間プラン(年間約129ドル)の場合。ファミリプランも用意されており、複数の世帯員をカバーすることで、一人当たりの費用を大幅に削減できます。   データ削除サービスは本当に効果があるのか? はい、ただし継続的な再監視が含まれている場合に限ります。データブローカーは60日から90日ごとに公的記録を再収集するため、一度限りの削除依頼は効果がない。IncogniやDeleteMeのようなサービスは、GDPRやCCPAの枠組みを利用して、継続的にデータを削除するなど、プロセス全体を自動化します。6ヶ月間のテストの結果、上位にランクインしたすべてのサービスにおいて、曝露量の測定可能かつ持続的な減少が確認されました。   IncogniはDeleteMeより優れていますか? ほとんどのユーザーにとって、答えはイエスです。Incogniは、完全自動化、低価格、そしてグローバルな法的対応力という、優れた価値提案を提供します。DeleteMeは、本当に複雑なケースを抱えているユーザー、可能な限り幅広いブローカーデータベース(750以上対180以上)を必要とするユーザー、またはオートメーションだけに頼るのではなく、人間の専門家による削除確認を特に必要とするユーザーにとって、より優れた選択肢です。   データブローカーから自分のデータを無料で削除することはできますか? はい、ほとんどのデータブローカーは無料のオプトアウトページを提供しており、手動での削除も無料で可能です。その代償は大きい。このプロセスは時間がかかり、数か月ごとに繰り返す必要があり、数十もの個々のブローカーを追跡しなければならない。継続的な自動保護のために、 Incogniは、ほとんどの人にとって実用的なアップグレードです。DIY方式は、リスクが低く予算が限られている個人にとって、無料の出発点として最適です。   デジタルフットプリントのコントロールを取り戻そう 2026年のデータブローカー経済は容赦ない。あなたの個人情報は絶えず収集、パッケージ化、販売されており、悪意のある者の手に渡れば、AIを利用した詐欺、ソーシャルエンジニアリング、なりすましなどの悪用材料となる。待つことは中立的な選択ではなく、危険にさらされ続けるという決断である。 6ヶ月にわたる厳格な独立テストの後、 匿名 最高のコストパフォーマンス、最もスムーズなオートメーション、そして真のグローバル展開力を備えているため、文句なしの最高評価を獲得しました。 削除 最も幅広いブローカーサービスと、専門知識を持つ人材によるサポートが必要な場合、最適な選択肢となります。どちらのサービスも、一度限りの除去作業が数か月以内に無意味になってしまう再曝露ライフサイクルに直接対抗するものです。 どのサービスから始めるにしても、それを基盤として構築していくことが重要です。強力で固有のパスワード、多要素認証、そしてデバイスレベルのセキュリティは、2026年に求められる包括的な多層防御アプローチを構成します。プライバシーは一度設定すれば済むものではなく、継続的に維持していくべきものです。今日から始めましょう。 Re: Best Personal Data Removal Services of 2026: Independently Tested and Compared @Mentorstgf簡単な判断 6か月間の実践形式の独立テストの結果、 Incogniは完全自動除去と約 月額6.49ドルで#1位 クラス最高の価値を獲得しました。 インコグニー — 今すぐアクセス ††   DeleteMeは2位にランクイン 人間中心のコンシェルジュ型サービスと、750名以上のブローカーを擁する業界トップクラスのネットワークが評価されています。どちらのサービスにも継続的な再監視機能が含まれており、これは2026年に注目すべき最も重要な機能の一つです。 DELETEME — 今すぐアクセス ††   クイック比較表:2026年版おすすめデータ削除サービス 以下の表は、最も重要な指標であるオートメーションレベル、ブローカーデータベースの規模、年間請求における月額概算費用、および6か月間の実地テスト後の総合スコアに基づいて、5つのサービスすべてをランク付けしたものです。 オンライン上の足跡を減らしたいと考えている人にとって、これは非常に役立つ比較です。特に、一度限りのオプトアウトに頼るのではなく、継続的な監視と再削除に重点を置いている点が重要です。6ヶ月間のテスト期間を設けることで、自動化されたサービスと人間が主導するサービスの違いをより理解しやすくなる。
記事全体を表示
デバイス統合(ソフトウェア)MFRC531 01T用 NXP Mifareリーダー(crypto1)MFRC531 01Tと統合する必要があり、SIDのポーリング、認証、ブロック/セクターの読み取りを行うためのRS232経由の関連プロトコルコマンドについてサポートが必要です。 Re: Device Integration (Software) for MFRC531 01T こんにちは@Menspa 残念ながら、NXPはMFRC531に基づくデモ例を提供していません。したがって、MFRC531データシート(標準ISO/IEC 14443 A/BリーダーソリューションMFRC531を参照し、NXPのライブラリNxpNfcRdLibを使用してカード読み書きアプリケーションを開発する必要があります。
記事全体を表示
S32K312: NMI は Reset_Handler の実行前にトリガーされ、特定の機能 (SW) リセット後にのみトリガーされます デバイス: S32K312 ツールチェーン:Green Hills ELXR(コンパイラ) HSEファームウェア:s32k312_hse_fw_0.13.0_2.55.0_pb250129.bin デバッガ:Lauterbach TRACE32 ソフトウェア:AUTOSAR RTDベースのブートローダー(FBL)+アプリケーション(APP)、2イメージ構造 問題の概要 一部の生産ユニットでは、機能処理の直後にCPUがハングします (ソフトウェア)リセット。同じユニットは破壊的 (電源投入)リセット。このフリーズは、当社の基準品/正常品では再現しません。 NMIがアプリケーションコード実行前に発生している証拠 1) ハングポイントでキャプチャされるCPUコンテキスト(自動スタックされた例外フレーム): - R0-R3 = 0x00000000、R12 = 0x00000000 - LR = 0xFFFFFFFF(デフォルトリセット -> まだBLが実行されていない) - PC = 0x00416904(Reset_Handlerの最初の命令アドレス) - xPSR = 0x01000000 2) SCB->ICSR = 0x00000802 Chibeom_3-1785136456875.pngChibeom_3-1785136456875.pngChibeom_3-1785136456875.pngChibeom_3-1785136456875.pngChibeom_3-1785136456875.pngChibeom_3-1785136456875.png - VECTACTIVE[8:0] = 2 -> NMI は現在アクティブな例外です - RETTOBASE = 1 これは、CPUが現在NMIハンドラ内で実行されていることを確認するものです。 3) NMIオフセットのベクトルテーブルエントリが自分のオフセットを正しく指している デフォルトの例外ハンドラなので、これはベクターではなく本物のNMIイベントです テーブルの破損。 レジスタはすべて同じハング状態(すべてクリーン/非アクティブと読み取られる)でチェックされました。 - MC_RGM_DES = 0x00000000(破壊的なリセットではない) - MC_RGM_FES = 0x20000000(ビット29のみ)(「ソフトウェア機能リセット」のみ) フラグセット、他の関数なし リセットソースフラグが設定されています) - FCCU:STAT、N2AF_STATUS、A2FF_STATUS、N2FF_STATUS、NCF_S0、IRQ_STAT all = 1 0x00000000 - CMU_FCインスタンス0、3、4:SR = 0x00000000(高低周波数フォルトなし) - PMC LVSC = 0x00000000(LVD/HVDフラグなし、ラッチまたはライブ) - ERM(0x4025C000):良好または故障したユニットで読み取れませんでした (おそらく私たちの設定ではクロックゲートされているため)、ERMの状態は未確認です。 質問 1. FCCU / CMU_FC / PMC / MC_RGM以外にNMIの情報源はありますか? アプリケーションのReset_Handlerが実行する前に、 最初の指示? 2. HSEサブシステムはアプリケーションコアとは独立して動作するため、 アプリケーションコアの機能リセットが可能である(ただし、 リセットHSE)を起動して状態の不一致を作り、NMIをトリガーします。 アプリケーションコア? 3. この症状に一致するS32K312の既知の訂正表はありますか?(NMIのみ) 機能/ソフトウェアのリセットで、電源オン時のリセットは一切ありません)。 追加のレジスターの確認や、ドキュメントについての指針はありますか? FCCU/ERM/CMU_FC/PMC以外のNMIの情報源があれば大変ありがたいです。 Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci こんにちは、 @Chibeom さん。 ハング状態のレジスタMU_0.MUB CSSR0とMU_1.MUB CSSR0を読み取り、ビット0(NMIC)がどちらかに設定されているか確認していただけますか? よろしくお願い申し上げます。 Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci こんにちは、 @danielmartynek さん、 MU_0.MUB / MU_1.MUB CSSR0 をご指摘いただきありがとうございます。 MU_0.MUBとMU_1.MUBの両方のCSSR0(ビット0、NMIC)0x00000000は ハング状態で故障したユニット、したがってMU->NMIリクエストパス(CCR0[NMI] / CSSR0[NMIC])は保留中ではないようです。 しかし、既知の良品ユニットと 故障したユニット(両方とも同じハング状態のアドレス範囲でキャプチャされました)、 一貫した違いが見られました。                                  良好なユニット 不良ユニット MU_0.MUB VER 0x0300000F 0x0300000F (同一) MU_0.MUB PAR 0x20200404 0x20200404 (同一) MU_0.MUB CR 0x00000000 0x00000000 (同一) MU_0.MUB SR 0x00000000 0x00000002 <- MURIP セット MU_1.MUB VER/PAR/CR: 正常ユニットと故障ユニットで同一 MU_1.MUB SR 0x00000000 0x00000002 <- MURIP セット SO、両方のMUインスタンスで、SRビット1(MURIP)は故障した 部分のみに設定されています。一貫して。リファレンス・マニュアルによると、MURIPは次のように示しています。 「プロセッサA」はMUリセットを発行しており、クリアできるのは システムリセット(多数ユニットリセットによるものではありません)。 CPUはNMIハンドラー内でフリーズし、実行前に何も実行しません アプリケーションコード自体がこのフラグをクリアできなかったはずなので、 この起動シーケンスの前またはその一部として設定されている必要があります。 以下の点についてご意見をお聞かせいただければ幸いです。 1.MU_0.MUBおよびMU_1.MUBの場合、どのプロセッサが「プロセッサA」(すなわち MURIPは誰が設定しているのでしょうか?ヘッダーは「MUB」レジスタブロックのみを公開します。 アプリケーションコアアクセス可能なアドレスは、 アプリケーションコアは常に「プロセッサB」、HSEは常に「プロセッサA」となります こういう場合に? 2. 「システムリセット」(MURIPをクリアするために必要)には機能型/ソフトウェアが含まれますか? アプリケーションコアのリセット、それとも破壊的/PORリセットだけ?もし MURIPは機能リセットによってクリアされないため、 電源投入後はクリアされるが、ソフトウェアリセット後も設定は維持される。 3. NMI の問題とは関係なく、MURIP フラグ自体がセット/スタック状態になっているか。 通常運転中に想定される、あるいは異常とみなされる事象か? 4. CSSR0[NMIC] が現在0を読み取っているため、ハードウェアは NMI例外エントリ時にNMICを車載クリアするのか、それとも以下でのみクリアされるのか 明示的なソフトウェア書き込み(この場合、NMIC=0はMU->NMIチャネルはそもそもアサートされていませんでした)? 改めて、これまでのご助力に感謝します。 Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci こんにちは、 @Chibeom さん。 遅れて申し訳ありません。私は2日間オフィスを不在にしていました。 1. はい、HSE_BコアはMU_0とMU_1のMUAインターフェースを制御します。 2. システムリセットはMURIPをリセットする。 3. これは例外的なことだと考えています。私自身はあまり情報を持っていません。 4. これはW1Cレジスタであるため、明示的な書き込みが必要です。 機能リセットがトリガーされた時点でHSE_Bが非アクティブであることを確認できますか? また、アプリケーションがNMIハンドラーに閉じ込められている間、どのような状態HSE_Bですか? MU_0 B面の標準HSE GPR(0x4039_C028)、FSR、GSRレジスタを読めますか? アプリケーションでNMIピンを使っていますか? よろしくお願いいたします。 ダニエル Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci こんにちは、ダニエルさん。 添付されている3つの結合レジスタダンプのスクリーンショットをご覧ください。 皆様からのご質問に基づいて整理した調査結果です。 -------------------------------------------------------- 添付ファイル -------------------------------------------------------- 添付資料1:正常なユニット(セキュアデバッグ有効、正常に動作中) Chibeom_3-1785730814252.pngChibeom_3-1785730814252.pngChibeom_3-1785730814252.pngChibeom_3-1785730814252.pngChibeom_3-1785730814252.pngChibeom_3-1785730814252.png 添付資料2:機能リセット直前の故障ユニット トリガーされました(通常動作) Chibeom_4-1785730831377.pngChibeom_4-1785730831377.pngChibeom_4-1785730831377.pngChibeom_4-1785730831377.pngChibeom_4-1785730831377.pngChibeom_4-1785730831377.png 添付資料3:機能リセット後、故障したユニットが NMIハンドラ(ハング状態) Chibeom_5-1785730838688.pngChibeom_5-1785730838688.pngChibeom_5-1785730838688.pngChibeom_5-1785730838688.pngChibeom_5-1785730838688.pngChibeom_5-1785730838688.png -------------------------------------------------------- 調査結果 1) 機能リセットがトリガーされた時点での HSE_B アクティビティ、 2) NMIハンドラで停止している間のHSE_Bの状態: 添付ファイル2(リセット前)と添付ファイル3(リセット後)を比較すると、 故障したユニットでは、ハング状態)で、チェックしたすべてのレジスタが読み取られます。 リセット前とリセット後、全く同じ状態: - MU_0.MUB / MU_1.MUB TSR = 0x0000000F、RSR = 0x00000000(保留なし) 送信/受信チャネル上のメッセージはリセットによって変更されませんでした) - MU_0.MUB GSR = 0x00000000(変更なし) - MU_0.MUB FSR = 0x03600000(変更なし) - HSE GPR(0x4039C028)= 0x000001C1(変更なし) - MU_0.MUB / MU_1.MUB SR ビット1(MURIP)= 0x00000002 -- すでに設定済み リセットがトリガーされる前、そして設定されたまま、変更されず、その後も リセット SO、このリセットサイクルの前にすでにMURIPが設定されており、 機能リセット自体はこれらのHSE関連のいずれも変えません レジスター。 参考までに、同じセキュアデバッグ機能を備えた良質なユニットでは 構成(添付ファイル1)では、MURIPは両方とも0x00000000を読み取ります MU_0.MUBとMU_1.MUBは、HSE GPRとWKPU NCRは同じ内容です。 故障したユニットとしての値。 3) セット/スタックしたMURIPが異常かどうかについて: 承知いたしました。ご確認いただきありがとうございます。 4) NMIピンの使用: WKPUルーティング済みのNMIパスは使っていません(WKPU_IP_USEDは有効ではありません。 WKPUのドライバーコードはブートローダーにコンパイルされていません。 アプリケーション画像)。WKPU NCR (0x402B4008) = 0x60000000 全く同じ 3つの添付ファイルすべてにおいて。NSR = すべての場合において0x00000000。以来 これはすべてのユニットと条件で変更されていません。 外部/WKPU経由のNMIソースが関与しています。 これまでの調査結果の概要 MURIP (MU_0.MUB および MU_1.MUB SR ビット 1) は既に障害発生時に設定されています 機能リセットがトリガーされる前のユニットであり、 吊り下げ期間中、変化はなかった。同じ仕様の良品では0と表示されます セキュアなデバッグ構成。これが唯一一貫して再現可能な方法です 比較したすべてのレジスタ(FCCU、 CMU_FC、PMC、WKPU、MU CSSR0/GSR/TSR/RSR/GPR/FSR)を担当しています。 MURIPは「プロセッサA」(HSE_B)によって設定されており、クリアされるべきです。 あなたの回答によれば「任意のシステムリセット」と呼ばれ、すでに設定されているので 機能リセットがトリガーされます(リセット自体は表示されません) 変更するために)、これはHSE_B以前にMUリセットを発行したことを示唆しています HSE_Bが認識した「システムリセット」で解除されなかったポイントです。 質問 1. HSE側から、何が原因になるのかを判断する方法はありますか? そもそも(プロセッサA)はMUリセットをHSE_Bするのでしょうか?私たちは MURIPがそもそも設定される理由を理解したい。 2. リセットをトリガーする推奨方法はありますかHSE_B アプリケーションから「システムリセット」(MURIPをクリアするため)として認識します ソフトウェア、フル電源サイクル以外は? 3. アプリケーションコア側で詰まったMURIPフラグは、 観測しているNMIでしょうか、それともこれらはより独立している可能性が高いのでしょうか 以前の同じイベント情報の症状? この件に関して引き続きご協力いただき、改めて感謝申し上げます。 Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci こんにちは、 @danielmartynek さん、 最新情報のご提供、そしてMURIP/NMIパスのエスカレーションに感謝いたします。 社内の安全衛生チームに質問してください。感謝します、そして待ちます 彼らの意見。 その間に、関連性のある追加のデータポイントを発見しました。 だから待つのではなく、今のうちに共有したいと思いました。 UTEST Flash領域のOTPフィールドを良品と比較すると また、故障したユニットでは、ライフサイクル スロットに違いが見られました。 CUST_DEL (0x1B000220-22F) と OEM_PROD (0x1B000230-23F) は同一です 良品ユニットと 故障したユニット。 違いはIN_FIELDスロット(0x1B000240-24F)にあります。 - 正常ユニット:プログラミングが開始される Chibeom_2-1786069927793.pngChibeom_2-1786069927793.pngChibeom_2-1786069927793.pngChibeom_2-1786069927793.pngChibeom_2-1786069927793.pngChibeom_2-1786069927793.png - ユニットの不具合: プログラムされていない (0xFFFFFFFF) と読み取られます Chibeom_1-1786069910918.pngChibeom_1-1786069910918.pngChibeom_1-1786069910918.pngChibeom_1-1786069910918.pngChibeom_1-1786069910918.pngChibeom_1-1786069910918.png IN_FIELD内の正確なバイトパターンを現在も再確認中です。 我々の側のスロットだが、このスロットでの良し悪しの差は 一貫性のある。 もう少し詳しく教えていただけますか: 1.これは故障したユニットの構成が 移行の途中で破損または不完全になった IN_FIELD? 2. 未完成または欠落したライフサイクルの進展がIN_FIELD この件で調べているNMI/ハングの挙動について説明してください Thread? 3. このライフサイクル進行を安全に確認または完了する方法はありますか? 故障しているユニットに対して、完全な生産リフローなしで? ご協力ありがとうございました。 Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci こんにちは、 @Chibeom さん。 メモリビューに基づくと、OEM_PROD = 非アクティブ、IN_FIELD = 消去済みとなります。 まずDCMの登録簿を読んでいただけますか:RM、rev.12、セクション 39.3.1 DCM メモリ マップ。 セクション38.2.3 破壊的リセット時の読み取り専用GPR 3 (DCMROD3) はどうでしょうか? HSE_FW APIを使ってLC属性を取得することもできますよね? よろしくお願い申し上げます。 Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci こんにちは、 @Chibeom さん。 詳細なレジスタダンプをありがとうございます。MURIPの動作と、HSE_BとCM7_0間の潜在的なNMI経路に関する疑問点について、社内のHSEチームに報告しました。これは文書化されていないようです。彼らからの意見が届き次第、改めてご連絡いたします。 Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci こんにちは、 @danielmartynek さん、 DCMメモリマップとDCMROD3について教えていただき、ありがとうございます。両方のユニットでDCMSTAT(0h)、DCMLCS(8h)、DCMLCS_2(80h)、およびDCMROD3(208h)をキャプチャし、RM rev.9に対してデコードしました。 ---------------------------------------------------- 捕捉された価値 ---------------------------------------------------- 良いユニット: Chibeom_0-1786500129171.pngChibeom_0-1786500129171.pngChibeom_0-1786500129171.pngChibeom_0-1786500129171.pngChibeom_0-1786500129171.pngChibeom_0-1786500129171.png - DCMSTAT (0h) = 0x00000E11 - DCMLCS (8h) = 0x00000000 - DCMLCS_2 (80h) = 0x00000000 - DCMROD3 (208h) = 0x00000000 不具合のあるユニット: Chibeom_1-1786500144600.pngChibeom_1-1786500144600.pngChibeom_1-1786500144600.pngChibeom_1-1786500144600.pngChibeom_1-1786500144600.pngChibeom_1-1786500144600.png - DCMSTAT (0h) = 0x00000E03 - DCMLCS (8h) = 0x06184104 - DCMLCS_2 (80h) = 0x00000006 - DCMROD3 (208h) = 0x00400000 ---------------------------------------------------- デコードされたフィールド(正常なユニットはすべてゼロを読み取るため、故障したユニットのみ) ---------------------------------------------------- DCMSTAT: - bit1 DCMERR = 1 (DCMがエラーで完了) -- 正常なユニットではこのビットは0です - bit4 DCMLCST = 0 (LCスキャン状態が「正常に完了」していない) -- 正常なユニットではこのビットは1になります DCMLCS: - ビット 21-19 DCMLCC4 (IN_FIELD マーキング) = 011b = "領域は消去済み/未使用です" - ビット 15-13 DCMLCC3 (OEM_PROD マーキング) = 010b = "非アクティブとしてマークされています" - ビット 27-25 DCMLCC5 (Pre-FA マーキング) = 011b = "消去済み/未使用" - 関連するすべての *_ECE/*_CFE/*_CSS ビット = 0。 DCMLCS_2: - ビット 3-1 DCMLCC6 (FA マーキング) = 011b = "消去済み/未使用" DCMROD3: - bit22 LC_ERR = 1 ("ライフサイクルスキャン中にエラーが発生しました") これは、以前共有したUTEST OTPダンプと一致しています。故障したユニットのIN_FIELDスロットは、消去済み/未使用と読み取られます。 ---------------------------------------------------- 障害発生ユニットにおけるHSE_FW APIの結果(HseReadLifecycle) ---------------------------------------------------- HseReadLifecycle() は 0x10 = HSE_LC_IN_FIELD を返します。したがって、HSEファームウェアの観点から見ると、現在のライフサイクルはすでに十分IN_FIELDです。 これは上記の DCM/OTP データと矛盾しているようです。DCM の DCMLCC4 フィールドは IN_FIELD として「消去済み/未使用」と表示され、UTEST OTP の IN_FIELD スロット (0x1B000240h 以降) は未プログラム (0xFFFFFFFF) と表示されますが、HSE API はライフサイクルが IN_FIELD として確認されていると報告しています。 HSEがDCMフラッシュマーキングとは独立した別の安全なストレージを通じてライフサイクルを追跡しているのか、あるいはこれがマーキング自体に問題があることを示しているのかが不明なため、結論を出すのではなく、現状のまま共有することにしました。 よろしくお願いいたします。 チボム Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci こんにちは、 @Chibeom さん。 データ提供ありがとうございます。 IN_FIELDスロットがまだ消去された状態なので、属性をもう一度設定して進めてみることはできますか? 先ほども述べた通り、この事件は現在内部で議論中です。 新しい情報が入り次第、このThreadを更新します。 Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci こんにちは、 @Chibeom さん。 おそらく、ライフサイクル(LC)の推進を担当するHSEサービスが中断されたため、LCがこのような状態に陥ったのだろう。 LCおよびLC制御(DCMLCC)レジスタはHSE_FWと同様に0x77(IN_FIELD)を報告するが、UTEST領域は正しくプログラムされていない。理論上は、デバッガを使ってUTEST IN_FIELDスロットをプログラムでき、DCMエラーをクリアできるはずです。 よろしくお願いいたします。 ダニエル Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci こんにちは、 @danielmartynek さん。 ご提案いただいたとおり、不具合が発生しているユニットでIN_FIELD属性を再度設定してみました。 結果: HSE_SRV_RSP_NOT_ALLOWED (0xAA55A21C) よろしくお願いいたします。 チボム Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci こんにちは、 @danielmartynek さん。 UTEST IN_FIELDスロットをデバッガを使ってプログラムするというご提案、ありがとうございます。 社内OTPフィールド参照テーブルを確認したところ、IN_FIELDライフサイクルスロット(1B00_0240-024F)は、LC > MCU_PROD(OEM_PROD)以降、HSEを除くすべてのマスタに対して書き込み保護されていると記載されています。このユニットの HseReadLifecycle() は既に IN_FIELD を報告しているため、この LC 条件は既に満たされているようです。 この保護ルールの下で、このスロットにデバッガを書き込むとどのようにして成功することが期待されるのか、説明していただけますか?この場合、デバッガが許可されたマスターとして扱われるには、特定の手続き、モード、認証ステップが必要ですか? それとは別に、LCからIN_FIELDへの昇格がそもそもこのような不完全な状態のまま放置された理由について、何か調査結果は出ていますか?可能であれば、復旧手順だけでなく、根本原因についても理解したいと考えています。 ありがとう、 チボム Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci こんにちは、 @Chibeom さん。 情報ありがとうございます。 現時点ではMCUを復元する選択肢はないようです。 考えられる可能性の一つは、LCを進めるためのHSE設定属性サービス要求がシステムリセットによって中断されたことです(IVT内のLCWを使用してLCが進められなかったことは理解しています)。 HSEからのサービスリクエストに対する回答を読みましたか?エラーが発生したかどうかをログに記録していますか? サービスをトリガーする前に、HSE_STATUS_INIT_OKが設定されていることを確認していますか? この問題の影響を受ける基板/MCUの数はいくつですか?ごく一部の端末に限られる現象ですか、それともより多くの端末で確認されていますか? ありがとうございました。 ダニエル Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci こんにちは、 @Chibeom さん。 何か最新情報はありますか? よろしくお願い申し上げます。 Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci こんにちは、 @danielmartynek さん。 返信が遅くなり申し訳ありません。ご質問いただきありがとうございました。以下が私たちの回答です。 1.LC アドバンス シーケンスでは、HSE サービス応答 (DebugAuth、AdvanceLifecycle、および ReadLifecycle 呼び出しから) を読み取り、それらを使用して全体的な成功/失敗ステータスを判断します。どの呼び出しが失敗したか、あるいは個々のエラーコードはログに記録されません。全体的なOK/FAILの結果のみが存在し、それはどこにも保存されません。したがって、これらのユニットで最初のLCの進階時に何が起こったかの記録はありません。 2. 当社のLC更新機能もその呼び出し元も、AdvanceLifecycleサービスをトリガーする前にHSE_STATUS_INIT_OKを明示的にチェックしません。ダウンロードフローの開始時に、MU_0.MUB FSRレジスタ(0x4038C104)を読み取り、そこからhseStatus_tを導出することによって、HSE_STATUS_INIT_OKを一度チェックします(Hse_Ip_GetHseStatusで行われるように、FSRビット16~31をマスク/シフトします)。このチェックは、フローの後半にあるライフサイクル進行ステップの前には繰り返されません。 追加の参考として、故障したユニットの本番機器ログは以下の順を示しています:FSRチェック完了(OK) -> App Download -> Secure Debug Enable -> FAIL なお、機器ログの「Secure Debug Enable」はLCの進行を含む全手順(DebugAuth、AdvanceLifecycle、ReadLifecycleを合わせて)を指します。単一のパス/フェイルステップとして記録されているため、どのサブステップが実際に失敗したかはこのログから判断できません。 当社のデバッグ機器(TRACE32)は、既存のデバッグフローの一部としてHSE_STATUS_INIT_OKをチェックしていますが、ダウンロード/プログラミング機器(生産ライン)は、LCの進行がトリガーされるシーケンスの時点でこれを一貫してチェックしていない可能性があります。 影響を受けるユニット数について:現在、この問題が発生しているボード/MCUは2台です。 さらに、2つの追加質問があります。 - FSRレジスタを読み取ってそこからhseStatus_tを導出する方法は、HSE_STATUS_INIT_OKを確認するための有効な/推奨される方法でしょうか? - 現在、ダウンロードフローの開始時に、このレジスタ読み取りを介して HSE_STATUS_INIT_OK を一度チェックしています。ライフサイクルの進行を開始する前に、具体的にチェックする必要があるでしょうか? チボムさん、ありがとうございます。 Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci こんにちは、 @danielmartynek さん。 お元気でお過ごしでしょうか。このスレッドに何か進展があるか確認したくて投稿しました。 機会があれば、どんなアドバイスでも教えていただけるとありがたいです。 ありがとう、 チボム Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci こんにちは、 @Chibeom さん。 遅れて申し訳ありません。HSEチームからのフィードバックを待っていましたが、NMIに関する明確な説明はまだ得られていません。 DCMROD3のLC_ERRフラグ:FCCU NCF 3がNMIを生成するように設定されている場合にのみ、NMIをトリガーできます。 ご質問にお答えします。 はい、その通りです。 システムのリセット後には、HSE_STATUS_INIT_OKフラグを確認する必要があります。アプリケーションはこのフラグを待ってからシステムクロックを変更したり、HSEサービスを利用したりする必要があります。一度設定すると、そのまま維持されます。さらに、アプリケーションはHSE_Bコア(PRTN0_CORE2_STAT[WFI])のWFIフラグをポーリングし、HSE_Bが忙しいかアイドルかを判断できます。 断続的なLC進行についてですが、もう一つ調査すべき根本原因が考えられます。ライフサイクルを変更するとUTESTフラッシュの内容が変更され、UTESTフラッシュはCode Flash Block 0と同じRWW(Read-While-Write)パーティションに存在します。UTEST書き込み中にBlock 0からコードが実行されている場合、RWWエラーが発生し、ライフサイクル変更が成功裏に完了しなくなることがあります。これを防ぐために、申請はLC昇進サービス中にブロック0への同時アクセスがないことを保証しなければなりません。キャッシュはほとんどの場合この問題を隠すことがありますが、特に同期されていないイベント情報を使う場合、キャッシュミスが発生し問題が目に見える場合もあります。 よろしくお願いいたします。 ダニエル Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci こんにちは、 @Chibeom さん。 UTESTは確かにブロック0にあります。 RMを参照してください。 表103。フラッシュブロック構成 S32K3xx_Memory_map.xlsx また、AN13388(S32K3 メモリーガイド)第3章。フラッシュメモリの状態: 「最大で5ブロック、最小で2ブロックです。」 ブロック0~4、UTESTはブロック0にあります。 よろしくお願いいたします。 ダニエル Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci こんにちは、 @danielmartynek さん。 HSE_STATUS_INIT_OKに関する2点をご確認いただき、ありがとうございます。 前回の返信でご説明いただいたUTESTとコードフラッシュブロック0に関するRWWメカニズムについて、さらに詳しくお伺いしたいと思います。AN13388(S32K3メモリガイド)の表3を参考にさらに調査したところ、正確な競合メカニズムについて疑問が生じました。 AN13388の表3によると、当社のデバイス(S32K312)の場合: - コードフラッシュブロック0: 0x0040_0000 - 0x004F_FFFF (1 MB) - コードフラッシュブロック1:0x0050_0000 - 0x005F_FFFF(1MB) - UTEST: 0x1B00_0000 - 0x1B00_1FFF (8 KB) UTESTは、コードフラッシュブロック0/1とは別の、独自のブロックとしてリストされています。この文書の一般的なRWWの説明には、同時読み書きは「操作が異なるブロックで行われる場合にのみ適用される」と記載されています。これは、読み書きが同じブロックを対象とする場合にのみ競合が発生するという意味だと理解しています。 UTESTとCode Flash Block 0はこのアドレスマップによって物理的に別々のブロックであることを踏まえ、ライフサイクル進行中のUTESTへの書き込みが、ブロック0から実行されるコードとRWWの競合をどのように生じるのか、説明していただけますか?具体的には: 1. UTESTとCode Flash Block 0は、異なるアドレス範囲を持っていても、RWW目的で内部フラッシュコントローラのリソース(例:プログラム/消去状態マシンやセマフォ)を共有しているのでしょうか? 2. リファレンス・マニュアルに記載されている、より具体的なパーティショングルーピング(AN13388のブロックテーブル以外に)があるのでしょうか? 私たちのアプリケーションコードはCode Flash Block 0から動作するため、修正を決定する前に正確な仕組みを理解したいと考えています。 改めて、皆様の継続的なサポートに感謝いたします。 最高、 チボム
記事全体を表示
secure_provisioning 工具烧写 sb格式 加密签名文件后无法用mcu link debug After flashing an SB-format encrypted and signed file with the Secure Provisioning tool, debugging via MCU-Link is no longer possible. justdomyself_0-1790073326861.png justdomyself_1-1790073357176.png when  I  use    mcuexpress  debug my code , error happended: justdomyself_2-1790073419631.png Can my this  board  recover to it's old state to  use zhe  debug function? Re: secure_provisioning 工具烧写 sb格式 加密签名文件后无法用mcu link debug Hi @justdomyself  > So, can I use the Secure Provising tool to make a new lisence, to cmobine a new signed and encrypted sb format file to write to the chip? Yes, Secure Provisioning tool is designed to provision chip, i.e. install secure assets (keys), build signed or encrypted application bootable image and install into the flash. Re: secure_provisioning 工具烧写 sb格式 加密签名文件后无法用mcu link debug @liborukropec   Thanks a lot.  I have resolve my question。 justdomyself_0-1790128360736.png I  have another question : As above picture,  This  erase operation has  erased  ful of the memory chip . So,   can  I  use  the Secure Provising tool to make a new  lisence, to cmobine a new  signed  and encrypted  sb format file  to write to the chip? Re: secure_provisioning 工具烧写 sb格式 加密签名文件后无法用mcu link debug Hi, if you configure ROM to execute only signed images and then you write application from VSCode (or other IDE) unsigned image, ROM refuses from running. Also, if you advance the Life Cycle, then the debugger can be opened only via Debug Authentication (see documentation). In case you did not advance life cycle (on the tool bar), you should be able to erase CMPA. Simplest should be using debug probe and on the Write tab use the "Erase whole chip..." button. liborukropec_0-1790086908628.png After power cycle you should be able to debug again. Regards, Libor
記事全体を表示
IMX8ulpにおけるファルコンモード起動の問題 チームの皆さん、こんにちは。 Falconモード でボードを起動する際に問題が発生しています 。 meta-imx-fastboot レイヤーをYoctoのソースディレクトリに クローンしました 。 構築中に imx-boot やデバイスツリー に関する問題に直面しました 。カスタムDTSを使っていて、それをボードに読み込む必要があるからです。これに対処するために、machine.confのFalcon Mode引数を 次のように 設定しました: FALCON_KERNEL_DEVICETREE = "imx8ulp-custom" この設定後、 Falcon Modeの手順で説明されているとおり、 imx8ulp_no_ubootローダーを生成することができました。 fitImageを使用しています KERNEL_IMAGETYPE = "fitImage" KERNEL_CLASSES:append = " kernel-fitimage" IMAGE_BOOT_FILES = "fitImage" 次に、以下のコマンドを使用してボードにファームウェアを書き込みました。 sudo uuu -b emmc_all *.wic sudo uuu -b emmc ファームウェアの書き込み後、ボードを起動すると、起動に失敗し、以下のエラーが発生します。 U-Boot SPL 2025.04-gb9f705c183f0(2025年6月4日 09:48:20 +0000) 通常起動 ELEファームウェアバージョン2.0.2-85b63cb9 upower_apd_inst_isr: エントリ upower_init: soc_id=48 upower_init: バージョン:11.11.13 upower_init: uPower RAMサービスを開始します user_upwr_rdy_callb: soc=b user_upwr_rdy_callb: RAMバージョン:12.18 スイッチを入れる... スイッチを入れてみて、OK 記憶を起動する... メモリーをオンにして DDRの保持をクリアします... DDRの保持はクリアです 第0節:RNGのインスタンス化 MMC1からの起動を試みています パーティション1がデバイス0で無効 spl_register_fat_device:ファットレジスター err - -1 パーティション1がデバイス0で無効 spl_register_fat_device:ファットレジスター err - -1 spl_load_image_fat: error reading image u-boot-atf-container.img, err - -1 誤差:-2 SPL:すべての起動デバイスから起動に失敗 ### ERROR ### ボードをリセットしてください### このエラーの原因を理解し、Falcon Modeの起動問題を解決する方法を教えていただけませんか? Re: Falcon Mode Boot Issue in IMX8ulp こんにちは@elgin_1950  もしDTSコンテンツとdefconfigをFalconがデフォルトでサポートしているEVKコードに同期した場合、問題は起きるのでしょうか? よろしくお願いします、 志明
記事全体を表示
Falcon Mode Boot Issue in IMX8ulp Hi Team, I am facing an issue while booting the board in Falcon Mode. I cloned the meta-imx-fastboot layer into my Yocto source directory. While building, I encountered some issues related to imx-boot and the device tree because I am using a custom DTS that needs to be loaded onto our board. To address this, I configured the Falcon Mode arguments in my machine.conf as follows: FALCON_KERNEL_DEVICETREE = "imx8ulp-custom" After this configuration, I was able to generate the imx8ulp_no_uboot loader as described in the Falcon Mode steps. I am using fitImage KERNEL_IMAGETYPE = "fitImage" KERNEL_CLASSES:append = " kernel-fitimage" IMAGE_BOOT_FILES = "fitImage" I then flashed the board using the following commands: sudo uuu -b emmc_all *.wic sudo uuu -b emmc After flashing, when I boot the board, it fails to boot and generates the following error: U-Boot SPL 2025.04-gb9f705c183f0 (Jun 04 2025 - 09:48:20 +0000) Normal Boot ELE firmware version 2.0.2-85b63cb9 upower_apd_inst_isr: entry upower_init: soc_id=48 upower_init: version:11.11.13 upower_init: start uPower RAM service user_upwr_rdy_callb: soc=b user_upwr_rdy_callb: RAM version:12.18 Turning on switches... Turn on switches ok Turning on memories... Turn on memories ok Clearing DDR retention... Clear DDR retention ok SEC0: RNG instantiated Trying to boot from MMC1 Partition 1 invalid on device 0 spl_register_fat_device: fat register err - -1 Partition 1 invalid on device 0 spl_register_fat_device: fat register err - -1 spl_load_image_fat: error reading image u-boot-atf-container.img, err - -1 Error: -2 SPL: failed to boot from all boot devices ### ERROR ### Please RESET the board ### Could you please help me understand the cause of this error and suggest how I can resolve the Falcon Mode boot issue? Re: Falcon Mode Boot Issue in IMX8ulp Hi @elgin_1950  If you sync your DTS content and defconfig to the EVK code that Falcon supports by default, will there still be any issues? Best Regards, Zhiming
記事全体を表示
S32K3で異なるリセットイベントを認証のためにトリガーする方法 検証目的で評価ボード上の各リセットソースをトリガーする推奨方法はありますか? 例: デバッグ宛先 SW_DEST HSE_SNVS_RST ...... レジスタDESとFESに対応するすべてのビットを知りたい Re: How to trigger different reset events on S32K3 for verification それは少し難しい質問ですね。これらのリセットイベントに直接注入する仕組みはなく、FCCU部分をカバーするSAF/eMCEMのAPIを除き、提供できる専用のテストコードやスクリプトもありません。とはいえ、可能な選択肢を調べたところ、以下は実際にうまくいくはずのスケッチされた方法です。 S32K3のリセットイベントは、検証のためにトリガーされる方法によって2つのカテゴリーに分かれます。ソフトウェアインジェクト可能とハードウェアのみで、DESとFESの2つのMC_RGMステータスレジスタに分かれています。 ソフトウェアインジェクタブルリセットはコードから直接トリガーできます: 直接SWコマンド — MC_ME.MODE_CONFにDEST_RSTまたはFUNC_RSTを書き込み、MODE_UPDをトリガーします。それぞれDES[SW_DEST]またはFES[SW_FUNC]にマッピングされます。 ウォッチドッグの有効期限切れ — SWT サービス ループを停止して、タイムアウトごとに機能リセットをトリガーし、FREC をインクリメントします。FREC が FRET に達すると、次のリセットは破壊的になり、DES[MC_RGM_FRE] が設定されます。 FCCUフォールト注入 — eMcem_InjectFault()またはFNCFCフェイクフォールトレジスタを使用して、NCFチャネル構成に応じて機能的または破壊的反応をトリガーします。設定されたNCFセットに含まれていないフォールトを注入すると、FOSUの破壊的リセットパスが特定にトリガーされます CMUしきい値操作 — CMU_FC_x.LTCR/HTCRを実際の動作周波数外に書き込むことで、CMU周波数障害リセットが発生し、反応タイプ(機能的または破壊的)はDCM構成によって制御されます。 ハードウェアのみのリセットは物理的な刺激を必要とし、ソフトウェアによる注入経路はありません: STCU_URFでは、ライブLBISTまたはMBISTシーケンス中にPLLのロック喪失が発生する必要がある。 HSE_TMPR_RSTとHSE_SNVS_RSTはセキュリティ改ざんイベントであり、暗号資料を保護するため、意図的にソフトウェアを通じて注入できないものです FXOSC_FAIL、PLL_LOL、およびLVDフラグは、ハードウェアレベルで水晶発振器、PLL分周器、または電源レールを乱すことを必要とします。 Re: How to trigger different reset events on S32K3 for verification こんにちは、デイビッド: わかりました。ありがとう! 徹底的な調査を実施します。
記事全体を表示
Step-by-Step Process to Buy a Ready 4 Bed Apartment in Emaar Beachfront Emaar Beachfront has quickly become one of Dubai's most sought-after waterfront destinations, and demand for a 4 bed apartment for sale ready to move Emaar Beachfront continues to grow among families and investors alike. If you are considering purchasing a spacious, move-in-ready home in this island community, understanding the buying process from start to finish will help you avoid delays and make confident decisions. This guide walks you through every stage of buying a ready 4 bedroom apartment in Emaar Beachfront, with practical insights from Takween AlDar, a trusted real estate company in Dubai. Why Emaar Beachfront Appeals to Buyers of Ready 4 Bed Apartments Emaar Beachfront sits between Dubai Marina and Palm Jumeirah, offering private beach access, resort-style facilities, and skyline views. A ready 4 bed apartment here suits larger families who want more living space without waiting years for construction to finish. Since the unit is already built and handed over, buyers can inspect the actual property, move in quickly, and start generating rental income sooner if they choose to lease it out. Step 1: Define Your Budget and Financing Options Before browsing listings, work out how much you can realistically spend. A 4 bedroom apartment in Emaar Beachfront is a premium purchase, so factor in the full cost picture, not just the listing price. Consider the following: Down payment requirements, typically 20 to 25 percent for expats Mortgage pre-approval from a UAE bank if financing is needed Dubai Land Department transfer fee, generally 4 percent of the purchase price Agency commission, usually 2 percent Ongoing service charges tied to the building and community Getting mortgage pre-approval early gives you a clear budget ceiling and strengthens your position when negotiating with sellers. Step 2: Shortlist Ready Units in Emaar Beachfront Once your budget is set, start identifying ready 4 bed apartments that match your needs. Since Emaar Beachfront includes several towers such as Beach Vista, Sunrise Bay, and Beach Isle, availability and layouts can vary significantly between buildings. Working with a knowledgeable agency like Takween AlDar helps narrow down options based on floor level, view, layout efficiency, and proximity to amenities, rather than relying only on online listings that may not reflect current inventory. Step 3: Schedule Property Viewings Unlike off plan purchases, a ready apartment allows you to physically walk through the unit before committing. Use viewings to check: Actual room sizes and layout flow Quality of finishes and fittings Natural light and view orientation Condition of common areas, elevators, and parking If the unit was previously occupied, ask about maintenance history and any recent repairs. Step 4: Verify Ownership and Property Documents Before making an offer, confirm the seller's ownership through the Dubai Land Department and request the title deed. Your agent should also check for any outstanding mortgages, service charge arrears, or legal disputes tied to the property. This verification step protects you from complications later in the transaction. Step 5: Negotiate and Sign the Memorandum of Understanding Once you are satisfied with the property and its documentation, submit an offer. If accepted, both parties sign a Memorandum of Understanding, commonly known as Form F, through the Dubai Land Department's Trakheesi system. At this stage, you typically pay a deposit, often around 10 percent of the purchase price, which is held until the transfer is finalized. Step 6: Obtain the No Objection Certificate The seller must request a No Objection Certificate from the developer, in this case Emaar. This certificate confirms there are no outstanding payments or restrictions on the property and clears the way for ownership transfer. Processing usually takes a few working days and involves a fee paid to the developer. Step 7: Complete the Transfer at the Dubai Land Department With the No Objection Certificate in hand, both buyer and seller attend the Dubai Land Department office, or a registered trustee center, to finalize the transfer. At this appointment, you pay the remaining balance, the transfer fee, and any applicable charges. Once complete, the title deed is issued in your name, officially making you the owner of the apartment. Step 8: Set Up Utilities and Move In After the transfer, register with DEWA for electricity and water, and activate any community services tied to the building. Since the apartment is ready and move-in ready, you can begin the handover process, collect keys, and plan your move without waiting for construction completion. How Takween AlDar Supports Your Purchase Buying a 4 bed apartment for sale ready to move Emaar Beachfront involves multiple steps, and having an experienced partner reduces stress and risk. Takween AlDar guides buyers through property selection, document verification, negotiation, and transfer, ensuring a transparent and well-managed process from first viewing to final handover.  FAQ Q: How long does it take to buy a ready apartment in Emaar Beachfront? A: The process typically takes two to four weeks from signing the Memorandum of Understanding to completing the title deed transfer, assuming financing and documentation are in order. Q: Can foreigners buy a 4 bedroom apartment in Emaar Beachfront? A: Yes, Emaar Beachfront is located in a freehold area, allowing full foreign ownership for buyers from any nationality. Q: Do I need a mortgage pre-approval before viewing properties? A: It is not mandatory, but having pre-approval helps you understand your budget and makes your offer more credible to sellers. Q: What fees should I budget for beyond the purchase price? A: Expect to pay a 4 percent Dubai Land Department transfer fee, a 2 percent agency commission, and possible NOC processing fees from the developer. Q: Is a ready apartment a better option than an off plan unit in Emaar Beachfront? A: A ready apartment allows immediate move-in and physical inspection before purchase, while off plan units may offer lower entry prices but require waiting for handover. Conclusion Purchasing a ready 4 bed apartment in Emaar Beachfront is a structured process that rewards careful planning, from setting a realistic budget to verifying documents and completing the transfer at the Dubai Land Department. With the right guidance, buyers can move through each step confidently and settle into their new waterfront home without unnecessary delays. Takween AlDar is available to support you at every stage of this journey, from your first property search to the final handover.
記事全体を表示
Best Personal Data Removal Services of 2026: Independently Tested and Compared ⚡Quick verdict After six months of hands-on independent testing, Incogni ranks #1 for fully automated removals and best-in-class value at approximately ~$6.49/month. ⚡INCOGNI — Access Now ➤➤   DeleteMe ranks #2 for its human-led concierge approach and industry-leading coverage of 750+ brokers. Both services include continuous re-monitoring — the single most critical feature to look for in 2026. ⚡DELETEME — Access Now ➤➤   Quick Comparison Table: Best Data Removal Services 2026 The table below ranks all five services against the metrics that matter most: automation level, broker database size, approximate monthly cost on annual billing, and our overall score after six months of real-world testing. # Service Best for Price/month Automation Brokers covered Our score 🥇1 INCOGNI — Access Now ➤➤ Editor's choice Automation & value ~$6.49 ✔ Full 180+ ★★★★★ 5.0 🥈2 DELETEME — Access Now ➤➤ Top-rated support Human-led removal ~$10.75 ✔ Hybrid 750+ ★★★★★ 4.8 3 Optery Most transparent Verified proof of removal ~$3.99 ✔ Full 200+ ★★★★½ 4.5 4 Aura All-in-one Privacy + AV + VPN bundle ~$12.00 ✔ Full 100+ ★★★★ 4.0 5 Privacy Bee Power users Granular control & depth ~$14.99 ✔ Full 150+ ★★★★ 4.0 *Prices reflect approximate monthly cost on annual plans. Verified May 2026. Why Data Removal Is No Longer Optional in 2026 The digital privacy landscape of 2026 looks radically different from even five years ago. Your personal information — home addresses, phone numbers, family details — has evolved from a nuisance that fueled spam mail into critical infrastructure for AI-powered fraud. This is not a future threat; it is happening right now. From Targeted Ads to AI-Powered Impersonation A decade ago, the worst thing a data broker could do with your profile was sell it to a telemarketer. Today, with advanced generative AI widely accessible, the same profile becomes a blueprint for voice cloning and deepfake identity theft. A bad actor who sources your biographical details from a people-finder site can construct hyper-personalized phishing campaigns indistinguishable from real communications sent by people you know. In 2026, privacy is a direct prerequisite for personal security — not just a preference. The "Re-exposure Lifecycle": Why a Single Removal Request Is Never Enough Perhaps the most dangerous myth in the privacy world is that submitting one opt-out request solves the problem permanently. Data broker platforms are architected to continuously re-scrape public records. Even after a successful removal, their automated crawlers frequently pull your data back within 60 to 90 days. This cycle — which we call the Re-exposure Lifecycle — is precisely why services like Incogni and DeleteMe focus on ongoing automated monitoring rather than one-time sweeps. Continuous suppression is the only defense that actually holds. How We Tested and Ranked Each Service Every ranking in this guide is grounded in six months of independent testing, not press releases or unverified user reviews. Here is exactly what we measured: 📊 Long-term suppression We tracked whether removed profiles stayed removed across the full six-month period, penalizing any service that allowed data to reappear without triggering a new removal cycle. 🔍 Scan frequency Services offering near-real-time or weekly monitoring ranked significantly higher than those running quarterly or monthly scans — inadequate cadences in 2026. 📁 Broker database coverage We audited both the number and quality of data brokers included, prioritizing high-traffic people-finder sites and marketing data aggregators over obscure low-risk sources. 💻 UX & transparency We evaluated dashboard clarity, reporting detail, and crucially whether each service provided verifiable, documented proof that removals had actually been completed. INCOGNI — Access Now ➤➤ Review 2026: Best Overall Data Removal Service 🥇 Incogni — Ranked #1 Overall Editor's Choice 2026 ★★★★★ 5.0 / 5.0 ~$6.49/month (annual billing) 🏚By Surfshark🌎 Global coverage (GDPR + CCPA)📋 180+ brokers🔄 Continuous monitoring Incogni is our clear #1 pick for 2026 and the best overall personal data removal service on the market. Created by the same team behind Surfshark VPN, it is purpose-built to automate the legal process of exercising your right to erasure under both GDPR and CCPA frameworks. The setup takes minutes: you authorize Incogni to act on your behalf, and the platform dispatches legally binding opt-out requests to more than 180 data brokers — then monitors and re-submits automatically whenever your data resurfaces. Incogni's defining advantage is the combination of price, automation depth, and international reach. At approximately $6.49 per month on an annual plan, it delivers more value per dollar than any competing service we tested. The dashboard is clean and intuitive, progress reports are easy to interpret, and the continuous re-monitoring loop means you are never left unprotected after the initial sweep — the exact defense needed to break the Re-exposure Lifecycle. Ideal for: Anyone who wants a fully automated, hands-off privacy solution with global legal coverage at the most competitive price point available. ✅Pros Best price on the market (~$6.49/mo) 100% automated — zero manual effort required 180+ broker database with full GDPR global reach Continuous re-monitoring and automatic re-removal Clean, intuitive dashboard with real-time progress Backed by the established, reputable Surfshark brand ❌Cons No human-led support for unusually complex cases Smaller broker count than DeleteMe (180 vs 750+) Limited manual customization options DELETEME — Access Now ➤➤ Review 2026: Best for Human-Led Support 🥈 DeleteMe — Ranked #2 Overall Best Human-Led Service ★★★★★ 4.8 / 5.0 ~$10.75/month (annual billing) 🏚By Abine🇺🇸 US-focused + international📋 750+ brokers👥 Human + automated hybrid DeleteMe claims the #2 position by excelling where pure automation falls short. With an industry-leading database of 750+ data brokers, it offers the broadest coverage of any service we tested. More importantly, DeleteMe layers human expertise on top of its automated systems — a dedicated team of privacy professionals handles removal requests for stubborn brokers that routinely ignore or reject automated opt-outs. If your situation is complicated — a very common name, a history of multiple addresses, or data surfacing on obscure regional directories — DeleteMe's concierge-style approach ensures nothing is overlooked. Their detailed quarterly reports provide a high level of documented transparency, and a family plan option makes it practical for households. The higher price (~$10.75/month) reflects the human labor involved and is well justified for users who need professional-grade oversight. Ideal for: Users with complex privacy needs who want the widest possible broker coverage and the assurance of human experts actively managing their removals. ✅Pros Largest broker database in the industry: 750+ sites Human privacy experts manage difficult edge cases Detailed quarterly reports with documented results Long, proven track record (founded 2010) Family plan options reduce per-person cost ❌Cons Higher monthly cost than Incogni (~$10.75/mo) Reporting on a quarterly cycle, not real-time Interface is less streamlined than Incogni's dashboard Other Recommended Services: Optery, Aura & Privacy Bee Optery — Best for Transparency (Ranked #3) Optery earns the #3 position through unmatched verification standards. Its dashboard gives users direct links to their exposed profiles before removal requests are submitted, and it is the only service we tested that provides screenshot-based proof that each individual removal has been completed. Starting at approximately $3.99/month, it is also the most affordable option on this list — a compelling choice for budget-focused users who refuse to take transparency on faith. The primary limitation is that its team and follow-up aggressiveness do not yet match Incogni or DeleteMe. Aura — Best All-in-One Security Suite (Ranked #4) Aura is the right answer for users who want to consolidate their entire digital security stack into a single subscription. At approximately $12/month, it bundles automated data removal with antivirus protection, a VPN, and credit monitoring into one unified platform — making it particularly well-suited for families. The removal tool itself is fully automated and effective, though its broker database of 100+ sites is noticeably smaller than our top two picks. Privacy Bee — Best for Power Users (Ranked #5) Privacy Bee is built for the privacy-obsessed user who wants granular, surgical control over their digital footprint. At ~$14.99/month, it is the most expensive option on this list, but it delivers the deepest customization options available — you can prioritize specific broker categories, target particular data types, and configure removal schedules with precision. That same complexity makes it less suitable for casual users who simply want a problem solved without thinking about it. Incogni vs DeleteMe: Which Should You Choose? This is the most frequently asked question in personal data removal, so here is a direct, no-fluff answer: Choose Incogni if you want the best price, full end-to-end automation, global GDPR and CCPA reach, and a dashboard that requires zero ongoing effort. This is the right choice for the vast majority of users. Choose DeleteMe if you have a genuinely complex privacy situation, want the widest possible broker database (750+), or need the confidence of human professionals actively managing and verifying your case. Both services include continuous re-monitoring — which is non-negotiable in 2026. Either will deliver dramatically better long-term protection than manual removal or inaction. Beyond Data Removal: Building a Complete Privacy Strategy Dark Web Monitoring and Credit Tracking Data removal addresses one critical exposure vector, but it is not a complete security solution on its own. Dark web monitoring adds a vital second layer: if your credentials surface in a breach, you need an immediate alert rather than a delayed discovery. Pair that with credit monitoring, so you are notified instantly if someone attempts to open accounts or make transactions in your name. Password Management and Multi-Factor Authentication A compromised password can unravel everything else you have done to protect your privacy. A dedicated password manager ensures you maintain unique, complex credentials across every service — eliminating the single-password-failure risk. Enable multi-factor authentication everywhere it is available, and use an authenticator app rather than SMS wherever possible; SMS-based MFA is vulnerable to SIM-swapping attacks that a proper authenticator app prevents. Device-Level Security: Antivirus and Fingerprint Blockers Your local device is the final perimeter. Robust antivirus software in 2026 is not optional — modern malware is designed to silently harvest files, credentials, and behavioral data. Complement it with browser extensions that actively block third-party trackers and resist fingerprinting, a technique through which data brokers build detailed profiles of you based on browser configuration and browsing patterns, entirely without cookies. Your Legal Rights in 2026: CCPA, GDPR, and How Services Use Them CCPA and the Expanding US Privacy Framework The California Consumer Privacy Act and its subsequent amendments give US consumers a legally enforceable right to demand that data brokers delete their personal information. As of 2026, penalties for non-compliance have become more concrete, and the opt-out infrastructure has matured. Services like Incogni and DeleteMe function as legal agents acting on your behalf — they submit binding opt-out requests using your consumer rights, compelling brokers to scrub your records under threat of regulatory penalty. GDPR: Global Data Rights Standard For users based in the EU or UK, the General Data Protection Regulation remains the most powerful privacy instrument available. GDPR's Right to Erasure imposes strict obligations on any organization handling data of EU residents. Incogni, developed by the European team behind Surfshark, is specifically architected around GDPR compliance — enabling it to file enforceable deletion requests against brokers globally, making it particularly valuable for international users. The DIY Approach: How to Remove Your Data Without a Paid Service Manual data removal is possible on a zero budget, but it demands a serious time commitment and ongoing discipline. The basic process: Search your full name, city, and state on major people-finder sites: Spokeo, Whitepages, BeenVerified, Intelius, and MyLife are the highest-priority starting points. Locate each site's opt-out or "Do Not Sell My Personal Information" page — typically buried in the site footer under Privacy Policy. Complete each opt-out workflow and save confirmation emails as documented evidence. Schedule calendar reminders to repeat the entire process every three to four months, since re-scraping will undo your removals on a regular cycle. For most people, the time cost of manual removal makes a service like Incogni at ~$6.49/month  an obvious economic choice. That said, if your risk profile is genuinely low and you have the patience for a systematic process, a manual-first approach can serve as a useful foundation before investing in automation. Ready to Remove Your Personal Data from the Internet? Stop leaving your digital footprint exposed. Start with our top-ranked services and reclaim control of your personal information today. ↑ Compare All Services Above Frequently Asked Questions What is the best data removal service in 2026? Incogni is our top-ranked data removal service for 2026 — #1 overall for its combination of full automation, global legal reach, and the lowest price in the premium tier (~$6.49/month). DeleteMe ranks #2 and is the better choice for users with complex situations who want human professionals managing their case.   How much does Incogni cost in 2026? Incogni costs approximately $6.49 per month on an annual plan (~$77.88 billed once per year). A month-to-month option is available at a higher rate. This makes it the most cost-effective premium data removal service currently on the market.   How much does DeleteMe cost in 2026? DeleteMe costs approximately $10.75 per month on an annual plan (~$129 per year). Family plans are available and significantly reduce the per-person cost when covering multiple household members.   Do data removal services actually work? Yes — but only when they include continuous re-monitoring. Data brokers re-scrape public records every 60 to 90 days, making one-time removal requests ineffective. Services like Incogni and DeleteMe automate the entire cycle, using GDPR and CCPA frameworks to suppress your data on an ongoing basis. Our six-month testing confirmed measurable and sustained reductions in exposure across all top-ranked services.   Is Incogni better than DeleteMe? For most users, yes — Incogni delivers a superior value proposition: full automation, lower price, and global legal reach. DeleteMe is the stronger choice for users with genuinely complex cases, those who want the widest possible broker database (750+ vs 180+), or those who specifically want human professionals verifying their removals rather than relying on automation alone.   Can I remove my data from data brokers for free? Yes, most data brokers provide free opt-out pages, and manual removal is possible at no cost. The trade-off is significant: the process is time-consuming, must be repeated every few months, and requires tracking dozens of individual brokers. For ongoing automated protection, Incogni a practical upgrade for most people. The DIY approach works best as a free starting point for low-risk individuals on a tight budget.   Take Back Control of Your Digital Footprint The data broker economy of 2026 is relentless. Your personal information is continuously harvested, packaged, and sold — and in the wrong hands, it is raw material for AI-powered fraud, social engineering, and identity theft. Waiting is not a neutral choice; it is a decision to remain exposed. After six months of rigorous independent testing, Incogni  earns our unqualified top recommendation: the best value, the most seamless automation, and genuine global reach. DeleteMe  is the right call when you need the broadest broker coverage available and the assurance of human expertise. Both services directly counter the Re-exposure Lifecycle that makes every one-time removal effort obsolete within months. Whichever service you start with, build on it: strong unique passwords, multi-factor authentication, and device-level security form the complete defense-in-depth approach that 2026 demands. Your privacy is not a setting you configure once — it is an ongoing practice. Begin today. Re: Best Personal Data Removal Services of 2026: Independently Tested and Compared @Mentorstgf Quick verdict After six months of hands-on independent testing, Incogni ranks #1 for fully automated removals and best-in-class value at approximately ~$6.49/month. INCOGNI — Access Now ➤➤   DeleteMe ranks #2 for its human-led concierge approach and industry-leading coverage of 750+ brokers. Both services include continuous re-monitoring — the single most critical feature to look for in 2026. DELETEME — Access Now ➤➤   Quick Comparison Table: Best Data Removal Services 2026 The table below ranks all five services against the metrics that matter most: automation level, broker database size, approximate monthly cost on annual billing, and our overall score after six months of real-world testing. A useful comparison for anyone looking to reduce their online footprint—especially the focus on continuous monitoring and re-removal rather than relying on a one-time opt-out. The six-month testing approach also makes the differences between automated and human-led services easier to understand.
記事全体を表示
在 Emaar Beachfront 购买一套现房四卧公寓的详细步骤 Emaar Beachfront 已迅速成为迪拜最受欢迎的海滨目的地之一,无论是家庭还是投资者,对 Emaar Beachfront 现房出售的 4 居室公寓的需求都在持续增长。如果您正在考虑在这个岛屿社区购买一套宽敞、拎包入住的房屋,了解从头到尾的购买流程将有助于您避免延误并做出自信的决定。 本指南将带您了解在 Emaar Beachfront 购买一套现房四居室公寓的每一个步骤,并提供来自迪拜值得信赖的房地产公司 Takween AlDar 的实用见解。 伊玛尔海滨公寓为何吸引四卧现房买家 Emaar Beachfront 位于迪拜码头和棕榈岛之间,提供私人海滩通道、度假村式设施和天际线景观。这里一套现成的四居室公寓适合想要更多居住空间的大家庭,无需等待数年才能完成建设。由于该单元房已经建成并交付,买家可以实地考察房产,快速入住,如果选择出租,还可以更快地开始产生租金收入。 第一步:确定预算和融资方案 在浏览房源之前,先确定自己实际能负担得起的金额。Emaar Beachfront 的四居室公寓是一笔高端投资,因此要考虑全部成本,而不仅仅是挂牌价格。 考虑以下内容: 首付要求,外籍人士通常为20%至25%。 如果需要融资,需获得阿联酋银行的抵押贷款预批函。 迪拜土地局过户费,通常为购买价格的4%。 代理佣金,通常为2%。 与建筑物和社区相关的持续服务费 尽早获得抵押贷款预批可以让你明确预算上限,并在与卖家谈判时增强你的地位。 第二步:筛选伊玛尔海滨公寓的现成单元 确定预算后,就可以开始寻找符合您需求的现成四居室公寓了。由于 Emaar Beachfront 包括 Beach Vista、Sunrise Bay 和 Beach Isle 等多个塔楼,因此不同建筑物的可用性和布局可能存在很大差异。 与像 Takween AlDar 这样知识渊博的代理机构合作,可以根据楼层、景观、布局效率和便利设施的距离来缩小选择范围,而不是仅仅依赖于可能无法反映当前存货的在线列表。 步骤三:安排房产看房 与期房购买不同,现房公寓允许您在做出决定前亲自参观房屋。利用实地考察来确认: 实际房间尺寸和布局流程 饰面和配件的质量 自然光线和视野方向 公共区域、电梯和停车场的状况 如果该单元之前有人居住,请询问维修记录和最近的维修情况。 第四步:核实所有权和房产文件 在出价之前,请通过迪拜土地局确认卖方的所有权,并索取产权证。您的经纪人还应检查该房产是否存在未偿还的抵押贷款、服务费欠款或法律纠纷。此验证步骤可保护您免受后续交易中可能出现的问题的影响。 第五步:协商并签署谅解备忘录 如果您对房产及其相关文件感到满意,即可提交报价。如果接受,双方将通过迪拜土地局的 Trakheesi 系统签署谅解备忘录(通常称为 F 表格)。在这个阶段,您通常需要支付一笔定金,通常约为购买价格的 10%,这笔定金将被保留到过户完成为止。 第六步:取得无异议证明 卖方必须向开发商(在本例中为 Emaar)索取无异议证明。该证明确认该房产没有任何未付清的款项或限制,并为所有权转移扫清了障碍。处理通常需要几个工作日,并且需要向开发商支付费用。 第七步:在迪拜土地局完成过户手续 买方和卖方在拿到无异议证明后,前往迪拜土地局办公室或注册信托中心完成产权过户手续。在本次预约中,您需要支付剩余款项、转账费以及任何适用的费用。一旦完成,产权证将以您的名义颁发,您正式成为该公寓的所有者。 第 8 步:开通水电煤气等公用设施并搬入 过户后,向迪拜水电局 (DEWA) 登记开通水电,并激活与该建筑物相关的任何社区服务。由于公寓已经准备就绪,可以立即入住,您可以开始办理交房手续、领取钥匙并计划搬家,无需等待施工完成。 Takween AlDar 如何支持您的购买 购买一套可拎包入住的 Emaar Beachfront 四居室公寓涉及多个步骤,而拥有经验丰富的合作伙伴可以减少压力和风险。Takween AlDar 为买家提供房产选择、文件核实、谈判和过户方面的指导,确保从首次看房到最终交房的整个过程透明且管理有序。 常见问题解答 问:在Emaar Beachfront购买一套现房公寓需要多长时间? 答:从签署谅解备忘录到完成产权过户,通常需要两到四周时间,前提是融资和文件齐全。 问:外国人可以在Emaar Beachfront购买四居室公寓吗? 答:是的,Emaar Beachfront 位于永久产权区域,允许任何国籍的买家拥有完全的外国所有权。 问:看房前我需要获得贷款预批吗? 答:虽然不是强制性的,但事先获得批准可以帮助您了解自己的预算,并使您的报价对卖家更具可信度。 问:除了购买价格之外,我还应该预留哪些费用预算? 答:预计需支付 4% 的迪拜土地局过户费、2% 的代理佣金,以及开发商可能收取的无异议证明 (NOC) 处理费。 问:在 Emaar Beachfront,现房公寓是否比期房公寓更好? 答:现房公寓允许立即入住,并在购买前进行实地考察,而期房单元可能提供较低的入门价格,但需要等待交房。 结束语 在 Emaar Beachfront 购买一套现成的 4 居室公寓是一个结构化的过程,需要周密的计划,从制定合理的预算到核实文件,再到在迪拜土地局完成过户。在正确的指导下,买家可以自信地完成每一步,顺利入住他们的新海滨住宅,避免不必要的延误。从您开始寻找房产到最终交房,Takween AlDar 将全程为您提供支持。
記事全体を表示
如何触发 S32K3 上的不同复位事件以进行验证 为了验证目的,是否有推荐的方法来触发评估板上的每个复位源? 例如: 调试目标 SW_DEST HSE_SNVS_RST ...... 我想知道与 DES 和 FES 寄存器对应的所有位。 Re: How to trigger different reset events on S32K3 for verification 这是一个有点棘手的问题。对于这些重置事件,没有直接的注入机制,我们也没有任何专用的测试代码或脚本可以提供——除了涵盖 FCCU 部分的 SAF/eMCEM API。也就是说,我研究了各种可能的选择,以下是初步设想的、在实践中应该可行的几种方法。 S32K3 上的复位事件根据其触发验证的方式分为两类——软件注入和仅硬件——分别分布在两个 MC_RGM 状态寄存器 DES 和 FES 上。 软件注入式复位可以直接从代码中触发: 直接软件命令——写入 MC_ME.MODE_CONF,参数为 DEST_RST 或 FUNC_RST,并触发 MODE_UPD,分别映射到 DES[SW_DEST] 或 FES[SW_FUNC]。 看门狗过期 — 停止 SWT 服务循环,在每次超时时触发功能重置,递增 FREC;一旦 FREC 达到 FRET,下一次重置将升级为破坏性重置,并设置 DES[MC_RGM_FRE] FCCU故障注入——使用eMcem_InjectFault()或FNCFC伪故障寄存器,根据NCF通道配置触发功能性或破坏性反应;注入不在已配置NCF集中的故障会触发FOSU破坏性复位路径。 CMU阈值操作——将CMU_FC_x.LTCR/HTCR写入实际运行频率之外,以产生CMU频率故障复位,其反应类型(功能性或破坏性)通过DCM配置控制。 纯硬件重置需要物理刺激,没有软件注入途径: STCU_URF 要求在实时 LBIST 或 MBIST 序列期间发生 PLL 失锁。 HSE_TMPR_RST 和 HSE_SNVS_RST 是安全篡改事件——有意设计为无法通过软件注入,因为它们保护加密材料。 FXOSC_FAIL、PLL_LOL 和 低压检测 标志表示硬件层面的晶振、PLL 分频器或电源轨存在故障。 Re: How to trigger different reset events on S32K3 for verification 嗨,大卫: 好的。谢谢你! 我们将进行全面调查。
記事全体を表示
IMX8ulp 中的猎鹰模式启动问题 大家好, 我在以 Falcon 模式 启动主板时遇到问题 。 我将meta-imx-fastboot层克隆到我的 Yocto 源代码目录中。 在构建过程中,我遇到了一些与 imx-boot 和设备树 相关的问题 ,因为我使用的是需要加载到我们开发板上的自定义 DTS。为了解决这个问题,我在 machine.conf 文件中配置了 Falcon 模式参数, 如下所示: FALCON_KERNEL_DEVICETREE = "imx8ulp-custom" 完成此配置后,我能够按照 Falcon 模式步骤中所述生成imx8ulp_no_uboot加载器。 我正在使用 fitImage KERNEL_IMAGETYPE = "fitImage" KERNEL_CLASSES:append = " kernel-fitimage" IMAGE_BOOT_FILES = "fitImage" 然后我使用以下命令对开发板进行了烧录: sudo uuu -b emmc_all *.wic sudo uuu -b emmc 刷写固件后,启动开发板时,启动失败并出现以下错误: U-Boot SPL 2025.04-gb9f705c183f0(2025年6月4日 - 09:48:20 +0000) 正常启动 ELE固件版本2.0.2-85b63cb9 upower_apd_inst_isr:入口 upower_init: soc_id=48 upower_init:版本:11.11.13 upower_init:启动 uPower RAM 服务 user_upwr_rdy_callb: soc=b user_upwr_rdy_callb:内存版本:12.18 打开开关…… 打开开关,没问题 唤醒记忆…… 打开记忆功能 清除DDR数据保留... 清除DDR数据保留正常 SEC0:RNG 实例化 尝试从 MMC1 启动 设备 0 上的分区 1 无效 spl_register_fat_device:fat 设备寄存器错误 -1 设备 0 上的分区 1 无效 spl_register_fat_device:fat 设备寄存器错误 -1 spl_load_image_fat:读取镜像 u-boot-atf-container.img 时出错,错误代码 -1 错误:-2 SPL:无法从所有引导设备启动 # ## ERROR ## # 请 RESET 该板 ### 请问您能否帮我了解一下这个错误的原因,并建议一下如何解决 Falcon 模式启动问题? Re: Falcon Mode Boot Issue in IMX8ulp 你好@elgin_1950 如果将 DTS 内容和 defconfig 同步到 Falcon 默认支持的 EVK 代码,是否还会出现任何问题? 此致, 志明
記事全体を表示
S32 Design Studio for Power Architecture、バージョン2.1ライセンス S32 Design Studio for Power Architecture バージョン2.1のライセンスが切れています。更新や新しい申請を手伝ってもらえますか? F379-CD5D-DAD1-7708 Re: S32 Design Studio for Power Architecture, version 2.1 license こんにちは、 お客様のS32DSライセンスが延長されました。以前のコードを使用して、S32DSを再度有効化してください。 Re: S32 Design Studio for Power Architecture, version 2.1 license こんにちは、 更新を申請しました。 よろしくお願いいたします。 ピーター
記事全体を表示
iMX8qm Boot Core A72_0 Hello NXP Forum, on iMX8qm, can we have the bootup done from A72 core? Does SCUFW permit that. Thanks Re: iMX8qm Boot Core A72_0 Proceed with the existing flash_ca72 target first; do not replace u-boot-atf.bin with u-boot-atf-a72.bin unless you are intentionally using the cockpit / multi-AP image flow. The evidence points to this distinction: flash_ca72 is described as the same basic boot image as the normal A-core boot target, but loaded to the A72 instead of the A53. u-boot-atf.bin is the combined ATF + U-Boot image: bl31.bin plus u-boot.bin / u-boot-hash.bin . u-boot-atf-a72.bin appears in the flash_cockpit target, where the image contains two AP payloads : one for A53 and a separate one for A72: -ap u-boot-atf.bin a53 0x80000000 ... -ap u-boot-atf-a72.bin a72 0xC0000000 ... . So the important selector is not only the filename; it is the imx-mkimage -ap ... a72 ... argument in the target. For a single A72 boot image, flash_ca72 using u-boot-atf.bin is consistent with the documented intent: the payload is loaded to A72 by the target rule, even if the filename is not suffixed -a72 . Recommended path: Build the standard A72-only image using the existing target: make SOC=iMX8QM flash_ca72 Use the CA72 device tree / configuration on the Linux side. NXP documentation notes that the i.MX8QM MEK CA72 DTB supports the two Cortex-A72 cores only and requires the special boot image built with flash_ca72 . Reserve u-boot-atf-a72.bin for flows that explicitly package a second A72 AP image, such as flash_cockpit , unless your BSP’s soc.mak comments or release notes say otherwise. Validate at boot that the image is actually entering the A72 path: check the imx-mkimage command emitted by make V=1 SOC=iMX8QM flash_ca72 or inspect iMX8QM/soc.mak and confirm the AP line uses a72 . Takeaway: treat the current flash_ca72 reference to u-boot-atf.bin as intentional; u-boot-atf-a72.bin is for the separate A72 payload used in cockpit/multi-partition style images, not automatically the replacement for flash_ca72 . Re: iMX8qm Boot Core A72_0 There is a small point we would like to clarify/validate: the `flash_ca72` target currently references `u-boot-atf.bin`, while a separate `u-boot-atf-a72.bin` is also available in the same configuration. How do we proceed Re: iMX8qm Boot Core A72_0 Yes — on i.MX8QM, the application-processor boot image can be targeted to the Cortex-A72 instead of the Cortex-A53, and SCFW permits that flow. NXP’s imx-mkimage has a flash_ca72 target described as the A72 variant of the normal A53 boot image, intended to bring up the A72 as early as possible for boot-time optimization . The important distinction is: First code after reset: not the A72. The device boot flow still starts through ROM/SCU/SCFW. AP-side bootloader / OS bring-up: yes, this can be done on the A72. SCFW initializes DDR, loads Cortex-A images, then boots the cores and sets their start addresses. Configuration mechanism: the boot container can specify an AP image for a72 , e.g. examples show -ap ... a72 ... in imx-mkimage usage. So the answer is: SCFW does allow booting the AP software path from A72, but A72 is not the reset/ROM boot master; it is started by SCFW according to the boot container configuration. Re: iMX8qm Boot Core A72_0 Hello, I have followed the following steps to build bootloader, but the bootloader fails without any logs. Could you please validate attached steps. Thanks mkdir Scarthgap_New cd Scarthgap_New   1. Get the Security Controller Binaries mkdir SECO cd SECO wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/imx-seco-5.9.4.1-0333596.bin chmod +x imx-seco-5.9.4.1-0333596.bin ./imx-seco-5.9.4.1-0333596.bin   mkashyap@cse-dev02:~/iMX8/Scarthgap_New/SECO/imx-seco-5.9.4.1-0333596/firmware/seco$ ls -al total 976 drwxrwxr-x 2 mkashyap mkashyap   4096 Aug 26 22:21 . drwxrwxr-x 3 mkashyap mkashyap   4096 Aug 26 22:21 .. -rw-r--r-- 1 mkashyap mkashyap    194 Jul 29  2024 commit-id.txt -rw-r--r-- 1 mkashyap mkashyap 163840 Jul 29  2024 mx8dxla1-ahab-container.img -rw-r--r-- 1 mkashyap mkashyap 163840 Jul 29  2024 mx8dxlb0-ahab-container.img -rw-r--r-- 1 mkashyap mkashyap  76944 Jul 29  2024 mx8qmb0-ahab-container.img -rw-r--r-- 1 mkashyap mkashyap  71312 Jul 29  2024 mx8qxb0-ahab-container.img -rw-r--r-- 1 mkashyap mkashyap  78408 Jul 29  2024 mx8qxc0-ahab-container.img -rwxr-xr-x 1 mkashyap mkashyap 423875 Jul 29  2024 SECO_FW_release_note.pdf mkashyap@cse-dev02:~/iMX8/Scarthgap_New/SECO/imx-seco-5.9.4.1-0333596/firmware/seco$   we use mx8qmb0-ahab-container.img   cd ../../../..   2. Download and build ATF mkdir ATF cd ATF git clone https://github.com/varigit/imx-atf -b lf_v2.10_6.6.52-2.2.0_var01   cd imx-atf source /opt/fsl-imx-xwayland/6.6-scarthgap/environment-setup-armv8a-poky-linux unset LDFLAGS make PLAT=imx8qm bl31   mkashyap@cse-dev02:~/iMX8/Scarthgap_New/ATF/imx-atf/build/imx8qm/release$ ls -al total 76 drwxrwxr-x 7 mkashyap mkashyap  4096 Aug 26 22:37 . drwxrwxr-x 3 mkashyap mkashyap  4096 Aug 26 22:36 .. drwxrwxr-x 3 mkashyap mkashyap  4096 Aug 26 22:37 bl31 -rwxrwxr-x 1 mkashyap mkashyap 45213 Aug 26 22:37 bl31.bin drwxrwxr-x 2 mkashyap mkashyap  4096 Aug 26 22:37 lib drwxrwxr-x 2 mkashyap mkashyap  4096 Aug 26 22:37 libc drwxrwxr-x 2 mkashyap mkashyap  4096 Aug 26 22:37 libwrapper drwxrwxr-x 2 mkashyap mkashyap  4096 Aug 26 22:37 romlib   cd ../../../../../   3. Download and build SCFW    mkdir SCFW    cd SCFW        wget https://developer.arm.com/-/media/Files/downloads/gnu-rm/8-2018q4/gcc-arm-none-eabi-8-2018-q4-major-linux.tar.bz    sudo tar xf gcc-arm-none-eabi-8-2018-q4-major-linux.tar.bz -C ./opt        git clone https://github.com/varigit/imx-sc-firmware.git -b 1.17.0    cd imx-sc-firmware/src/scfw_export_mx8qm_b0        export TOOLS=/home/mkashyap/iMX8/Scarthgap_New/SCFW/Opt    make clean-qm    make qm R=B0 B=var_som V=1        mkashyap@cse-dev02:~/iMX8/Scarthgap_New/SCFW/imx-sc-firmware/src/scfw_export_mx8qm_b0/build_mx8qm_b0$ ls -al    total 3384    drwxrwxr-x 11 mkashyap mkashyap    4096 Aug 26 22:47 .    drwxrwxr-x  6 mkashyap mkashyap    4096 Aug 26 22:47 ..    drwxrwxr-x  3 mkashyap mkashyap    4096 Aug 26 22:47 board    drwxrwxr-x  3 mkashyap mkashyap    4096 Aug 26 22:44 devices    drwxrwxr-x 25 mkashyap mkashyap    4096 Aug 26 22:47 drivers    drwxrwxr-x  2 mkashyap mkashyap    4096 Aug 26 22:44 main    -rwxrwxr-x  1 mkashyap mkashyap  184448 Aug 26 22:47 scfw_tcm.bin    -rwxrwxr-x  1 mkashyap mkashyap 2787784 Aug 26 22:47 scfw_tcm.elf    -rw-rw-r--  1 mkashyap mkashyap  513123 Aug 26 22:47 scfw_tcm.map    drwxrwxr-x  4 mkashyap mkashyap    4096 Aug 26 22:44 soc    drwxrwxr-x 26 mkashyap mkashyap    4096 Aug 26 22:44 ss    drwxrwxr-x  9 mkashyap mkashyap    4096 Aug 26 22:47 svc    drwxrwxr-x 10 mkashyap mkashyap    4096 Aug 26 22:44 test    drwxrwxr-x  2 mkashyap mkashyap    4096 Aug 26 22:44 utilities        cd ../../../../../     4. Build u-boot    mkdir u-boot    cd u-boot        git clone https://github.com/varigit/uboot-imx.git -b lf_v2024.04_6.6.52-2.2.0_var01    cd uboot-imx        cp ../../SECO/imx-seco-5.9.4.1-0333596/firmware/seco/mx8qmb0-ahab-container.img ./mx8qm-ahab-container.img    cp ../../SCFW/imx-sc-firmware/src/scfw_export_mx8qm_b0/build_mx8qm_b0/scfw_tcm.bin ./mx8qm-mek-scfw-tcm.bin    make mrproper    make imx8qm_var_som_defconfig    make -j8        cd ../../     5. Make Image     mkdir MkImage    cd MkImage        git clone https://github.com/varigit/imx-mkimage -b lf-6.6.52_2.2.0_var01    cd imx-mkimage        cp ../../SECO/imx-seco-5.9.4.1-0333596/firmware/seco/mx8qmb0-ahab-container.img ./iMX8QM/    cp ../../SCFW/imx-sc-firmware/src/scfw_export_mx8qm_b0/build_mx8qm_b0/scfw_tcm.bin ./iMX8QM/    cp ../../u-boot/uboot-imx/u-boot.bin ./iMX8QM/    cp ../../u-boot/uboot-imx/spl/u-boot-spl.bin ./iMX8QM/    cp ../../ATF/imx-atf/build/imx8qm/release/bl31.bin ./iMX8QM/        make SOC=iMX8QM flash_ca72        cd iMX8QM    make -f soc.mak SOC=iMX8QM MKIMG=../mkimage_imx8 PAD_IMAGE=./pad_image.sh flash_ca72        mkashyap@cse-dev02:~/iMX8/Scarthgap_New/MkImage/imx-mkimage/iMX8QM$ ls -al    total 6792    drwxrwxr-x  3 mkashyap mkashyap    4096 Aug 26 23:08 .    drwxrwxr-x 13 mkashyap mkashyap    4096 Aug 26 23:06 ..    -rwxrwxr-x  1 mkashyap mkashyap   45213 Aug 26 23:06 bl31.bin    -rwxrwxr-x  1 mkashyap mkashyap    2564 Aug 26 22:59 expand_c_define.sh    -rw-rw-r--  1 mkashyap mkashyap 1895424 Aug 26 23:08 flash.bin    -rw-rw-r--  1 mkashyap mkashyap       9 Aug 26 23:06 head.hash    -rwxrwxr-x  1 mkashyap mkashyap    2078 Aug 26 22:59 mkimage_fit_atf.sh    -rw-r--r--  1 mkashyap mkashyap   76944 Aug 26 23:02 mx8qmb0-ahab-container.img    -rwxrwxr-x  1 mkashyap mkashyap  184448 Aug 26 23:03 scfw_tcm.bin    drwxrwxr-x  2 mkashyap mkashyap    4096 Aug 26 22:59 scripts    -rwxrwxr-x  1 mkashyap mkashyap   13271 Aug 26 22:59 soc.mak    -rwxrwxr-x  1 mkashyap mkashyap 1631521 Aug 26 23:06 u-boot-atf.bin    -rw-rw-r--  1 mkashyap mkashyap 1500440 Aug 26 23:04 u-boot.bin    -rw-rw-r--  1 mkashyap mkashyap 1500449 Aug 26 23:06 u-boot-hash.bin    -rw-rw-r--  1 mkashyap mkashyap  139387 Aug 26 23:04 u-boot-spl.bin     The generated flash.bin was used as an bootloader image Re: iMX8qm Boot Core A72_0 For your specific procedure, the important point is this: make SOC=iMX8QM flash_ca72 is the correct target conceptually if your intent is to load the bootloader to the A72 instead of the A53 . NXP community guidance describes flash_ca72 as similar to the basic flash_b0 image, but loaded to the A72 rather than the A53 . The “no logs” symptom does not automatically mean SCFW rejected A72 boot . A known gotcha is that A53 and A72 do not use the same log terminal , so if you monitor the usual A-core/A53 UART you may see nothing even though the A72 image is running or failing later on a different console path. Validation of your steps: Area Assessment SECO container mx8qmb0-ahab-container.img is the right class of container for i.MX8QM B0. ATF make PLAT=imx8qm bl31 is reasonable for i.MX8QM. SCFW Building make qm R=B0 B=var_som V=1 is consistent with an i.MX8QM B0 Variscite target. U-Boot imx8qm_var_som_defconfig is the key item to confirm: it must be compatible with the A72 boot path and console configuration. mkimage target flash_ca72 is the right target only for A72 boot. For normal Linux BSP boot, the documented i.MX8QM command is make SOC=iMX8QM flash . SPL copy u-boot-spl.bin is likely irrelevant for flash_ca72 ; that target is not the SPL-based flow. Duplicate image build Running both top-level make SOC=iMX8QM flash_ca72 and then manually running make -f soc.mak ... flash_ca72 is unnecessary. Use one clean top-level command. I would correct/clean the image-generation part to: cd ~/iMX8/Scarthgap_New/MkImage/imx-mkimage cp ../../SECO/imx-seco-5.9.4.1-0333596/firmware/seco/mx8qmb0-ahab-container.img ./iMX8QM/ cp ../../SCFW/imx-sc-firmware/src/scfw_export_mx8qm_b0/build_mx8qm_b0/scfw_tcm.bin ./iMX8QM/ cp ../../u-boot/uboot-imx/u-boot.bin ./iMX8QM/ cp ../../ATF/imx-atf/build/imx8qm/release/bl31.bin ./iMX8QM/ make clean make SOC=iMX8QM flash_ca72 Then use: iMX8QM/flash.bin Also fix/check this SCFW path: export TOOLS=/home/mkashyap/iMX8/Scarthgap_New/SCFW/Opt You extracted into ./opt , but exported .../SCFW/Opt . Linux paths are case-sensitive. Since you did produce scfw_tcm.bin , your actual shell may have had a valid tool path, but this line should be verified. Recommended debug sequence: First build and boot the standard image: make SOC=iMX8QM flash This checks that SECO + SCFW + ATF + U-Boot + board DDR/console are basically correct. The Linux User’s Guide documents this standard i.MX8QM flash.bin generation path. Then rebuild with: make SOC=iMX8QM flash_ca72 Monitor the A72 console/UART , not only the normal A53 console. The A53 and A72 log terminals differ. If still silent, compare the generated flash.bin size/layout between flash and flash_ca72 , and confirm that the Variscite U-Boot config actually enables the console used by the A72 boot target. So the direct answer is: SCFW does permit starting the Cortex-A side on A72 through the flash_ca72 image flow, but SCFW still owns the initial boot orchestration. Your procedure is mostly valid for A72 boot, but remove the duplicate soc.mak invocation, verify the SCFW tool path, and most importantly check the A72 UART/console. Takeaway: A72 boot on i.MX8QM is supported via flash_ca72 ; a silent boot is more likely an image/config/console issue than SCFW simply refusing to start A72. Re: iMX8qm Boot Core A72_0 Where can we get SCFW reference manual or design manual to make modification to SCFW firmware Re: iMX8qm Boot Core A72_0 You can start here: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/System-Controller-Firmware-101/ta-p/1124236 https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/System-Controller-Firmware-101-Getting-started/ta-p/1121153 The SCFW reference/porting documentation is supplied inside the NXP SCFW Porting Kit , rather than as a separate public reference manual. Download the kit from the NXP i.MX Software and Development page. Select the release corresponding to your i.MX BSP; NXP requires the matching porting kit to maintain compatibility with its supplied binaries. Accept the license and run the included .bin installer. Look under: doc/pdf/sc_fw_port.pdf — detailed SCFW Porting Guide doc/pdf/ — SCFW API User Guide, release notes, and related documentation src/ — SoC-specific SCFW export archives The kit contains a mixture of source and object code. Board-dependent customization is performed in the exported board sources—typically under platform/board/mx8 _ / , including files such as board.c ; much of the core SCFW remains object-only and cannot be modified through the public kit. The general i.MX Porting Guide, UG10165 , also has a “Porting System Controller Firmware” chapter and explains integration with the BSP and meta-imx-scfw.
記事全体を表示
iMX8qm ブートコア A72_0 こんにちは、NXPフォーラムの皆様、 iMX8qmで、A72コアから起動できますか?SCUFWはそれを許可していますか? よろしくお願いします。 Re: iMX8qm Boot Core A72_0 まず既存の flash_ca72 ターゲットで処理を進めてください。u-boot-atf.bin は置き換えないでください。u-boot-atf-a72.bin を使用コックピット/マルチAPイメージフローを意図的に使用しない限り。 証拠はこの違いを示している。 flash_ca72は、通常のAコアブートターゲットと同じ基本ブートイメージですが、A53ではなくA72にロードされるものとして説明されています。 u-boot-atf.bin は、ATF と U-Boot を組み合わせたイメージです: bl31.bin加えて u-boot.bin/ u-boot-hash.bin . u-boot-atf-a72.binflash_cockpitターゲットに表示され、イメージには2つのAPペイロードが含まれています。1つはA53用、もう1つはA72用です。 -ap u-boot-atf.bin a53 0x80000000 ... -ap u-boot-atf-a72.bin a72 0xC0000000 ... 。 したがって、重要なセレクタは単なるファイル名ではありません。それはIMX-MKIMAGE -APです...A72 ...ターゲットの議論。単一の A72 ブート イメージの場合、u-boot-atf.bin を使用する flash_ca72 は、文書化された意図と一致しています。ファイル名に -a72 が付加されていなくても、ターゲット ルールによってペイロードが A72 にロードされます。 推奨パス: 既存のターゲットを使用して、標準のA72専用イメージを作成します。 SOC=iMX8QM flash_ca72 を作成します Linux側ではCA72デバイスツリー/設定を使いましょう。NXPのドキュメントによると、i.MX8QM MEK CA72 DTBは2つのCortex-A72コアのみをサポートし、flash_ca72で構築された特別なブートイメージが必要です。 u-boot-atf-a72.bin を予約するflash_cockpitのように、2つ目のA72 APイメージを明示的にパッケージ化するフローの場合、ただしBSPのsoc.makが使わない限りコメントやリリースノートには、それとは異なる記載がある。 起動時にイメージが実際にA72パスに入っていることを確認します。make V=1 SOC=iMX8QM flash_ca72によって生成されるimx-mkimageコマンドを確認するか、iMX8QM/soc.makを調べます。AP ラインが a72 を使用していることを確認してください。 要点:現在の flash_ca72 参照を u-boot-atf.bin として扱う。意図的なものです。u-boot-atf-a72.bin は、コックピット/マルチパーティション スタイルのイメージで使用される個別の A72 ペイロード用であり、flash_ca72 の自動的な代替ではありません。 Re: iMX8qm Boot Core A72_0 明確に/検証したい小さな点があります: `flash_ca72` ターゲットは現在 `u-boot-atf.bin` を参照しています。同じ構成で、別の `u-boot-atf-a72.bin` も利用可能です。 どのように進めていくべきか Re: iMX8qm Boot Core A72_0 はい、i.MX8QMではアプリケーションプロセッサのブートイメージをCortex-A53ではなくCortex-A72にターゲットに設定でき、SCFWはその流れを許可しています。NXPのimx-mkimageには、通常のA53ブートイメージのA72バリアントとして説明されているflash_ca72ターゲットがあり、ブート時間の最適化のためにA72をできるだけ早く起動することを目的としています。 重要な違いは次のとおりです。 リセット後の最初のコード: A72ではない。デバイスの起動フローは、引き続きROM/SCU/SCFWを経由して開始されます。 AP側ブートローダー/OSの起動:はい、A72で可能です。SCFWはDDRを初期化し、Cortex-Aイメージを読み込み、コアを起動して開始アドレスを設定します。 設定機構:ブートコンテナはa72用のAPイメージを指定することができます。例:例として、imx-mkimage の使用例で -ap ... a72 ... が示されています。 つまり答えはこうです:SCFWはA72からAPソフトウェアパスを起動できますが、A72はリセットやROMのブートマスターではなく、SCFWによってブートコンテナの設定に従って起動されます。 Re: iMX8qm Boot Core A72_0 あなたの具体的な手順に関して、重要な点は以下のとおりです。 SOC=iMX8QM flash_ca72 を作成します ブートローダーをA53ではなくA72にロードすることが目的であれば、概念的にはこれが正しいターゲットです。NXPコミュニティのガイダンスでは、flash_ca72は基本flash_b0イメージに似ていますが、A53ではなくA72に読み込まれています。 「ログなし」という症状は、必ずしもSCFWがA72ブートを拒否したことを意味するものではありません。よく知られている落とし穴として、A53とA72は同じログターミナルを使っていないため、通常のAコア/A53 UARTを監視しても、A72イメージが別のコンソールパスで動作しているか、後で失敗しても何も見つからないことがあります。 手順の検証: エリア 評価 SECOコンテナ mx8qmb0-ahab-container.img は i.MX8QM B0 に適したコンテナのクラスです。 ATF make PLAT=imx8qm bl31 は i.MX8QM に対して妥当です。 SCFW qm=B0 B=var_som V=1の構築はi.MX8QM B0 Varisciteターゲットと一致します。 U-Boot imx8qm_var_som_defconfig は確認すべき重要な項目です。A72 のブートパスおよびコンソール構成と互換性がある必要があります。 mkimageターゲット flash_ca72 は A72 ブートの場合にのみ適切なターゲットです。通常のLinux BSP起動では、文書化されたi.MX8QMコマンドがmake SOC=iMX8QM flashです。 SPLコピー u-boot-spl.bin は flash_ca72 にはおそらく関係ありません。そのターゲットは SPL ベースのフローではありません。 イメージの複製 トップレベルの make SOC=iMX8QM flash_ca72 を実行してから、手動で make -f soc.mak ... flash_ca72 を実行する必要はありません。簡潔なトップレベルコマンドを1つだけ使用してください。 画像生成部分を以下のように修正・整理します。 cd ~/iMX8/Scarthgap_New/MkImage/imx-mkimage cp ../../SECO/imx-seco-5.9.4.1-0333596/firmware/seco/mx8qmb0-ahab-container.img ./iMX8QM/ cp ../../SCFW/imx-sc-firmware/src/scfw_export_mx8qm_b0/build_mx8qm_b0/scfw_tcm.bin ./iMX8QM/ cp ../../u-boot/uboot-imx/u-boot.bin ./iMX8QM/ cp ../../ATF/imx-atf/build/imx8qm/release/bl31.bin ./iMX8QM/ make clean SOC=iMX8QM flash_ca72 を作成します 次に以下を使用します。 iMX8QM/flash.bin また、このSCFWパスも修正/確認してください。 export TOOLS=/home/mkashyap/iMX8/Scarthgap_New/SCFW/Opt ./opt に展開しました、ただしエクスポートされた…/SCFW/Opt。Linuxのパスは大文字を区別しています。scfw_tcm.bin を生成したので実際のシェルには有効なツールパスが設定されていたかもしれませんが、この行を確認する必要があります。 推奨デバッグ手順: まず、標準イメージをビルドして起動します。 make SOC=iMX8QM flash これは、SECO + SCFW + ATF + U-Boot + ボードのDDR/コンソールが基本的に正しいことを確認するものです。Linuxユーザーガイドにはこの標準i.MX8QMが記載されていますflash.bin生成パス。 次に、以下のコマンドで再構築します。 SOC=iMX8QM flash_ca72 を作成します 通常のA53コンソールだけでなく、 A72コンソール/UARTも監視してください。A53とA72のログ端末は異なります。 それでも音がしない場合は、生成された flash.bin を比較してください。flash と flash_ca72 間のサイズ/レイアウトを確認し、Variscite U-Boot の設定が実際に A72 ブートターゲットで使用されるコンソールを有効にしていることを確認します。 つまり、直接的な答えはこうです:SCFWはflash_ca72イメージフローを通じてA72のCortex-A側を起動することを許可していますが、SCFWは初期のブートオーケストレーションを所有しています。あなたの手順はA72ブートにはほぼ有効ですが、重複したsoc.mak呼び出しを削除し、SCFWツールパスを確認し、そして何よりもA72のUART/コンソールを確認してください。 要点:i.MX8QM での A72 ブートは flash_ca72 を介してサポートされています。サイレントブートは、SCFW が単に A72 の起動を拒否しているというよりも、イメージ/設定/コンソールの問題である可能性が高いです。 Re: iMX8qm Boot Core A72_0 こんにちは、 以下の手順に従ってブートローダーを構築しましたが、ログも出力されずにブートローダーが失敗します。 添付された手順を検証していただけますか? よろしくお願いします。 mkdir Scarthgap_New cd Scarthgap_New   1. セキュリティ・コントローラバイナリーを入手する mkdir SECO CDセコ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/imx-seco-5.9.4.1-0333596.bin chmod +x imx-seco-5.9.4.1-0333596.bin ./imx-seco-5.9.4.1-0333596.bin   mkashyap@cse-dev02:~/iMX8/Scarthgap_New/SECO/imx-seco-5.9.4.1-0333596/firmware/seco$ ls -al 合計976 drwxrwxr-x 2 mkashyap mkashyap   4096 8月26日 22:21 . drwxrwxr-x 3 mkashyap mkashyap   4096 8月 26 22:21 .. -rw-r--r-- 1 mkashyap mkashyap    194 7月29日  2024 commit-id.txt -rw-r--r-- 1 mkashyap mkashyap 163840 2024年7月29日 mx8dxla1-ahab-container.img -rw-r--r-- 1 mkashyap mkashyap 163840 2024年7月29日 mx8dxlb0-ahab-container.img -rw-r--r-- 1 mkashyap mkashyap 76944 Jul 29 2024 mx8qmb0-ahab-container.img -rw-r--r-- 1 mkashyap mkashyap  71312 7月29日  2024 mx8qxb0-ahab-container.img -rw-r--r-- 1 mkashyap mkashyap  78408 7月29日  2024 mx8qxc0-ahab-container.img -rwxr-xr-x 1 mkashyap mkashyap 423875 Jul 29 2024 SECO_FW_release_note.pdf mkashyap@cse-dev02:~/iMX8/Scarthgap_New/SECO/imx-seco-5.9.4.1-0333596/firmware/seco$   私たちはmx8qmb0-ahab-container.imgを使用します   CD ../../../..   2. ATFをダウンロードしてビルドする mkdir ATF cd ATF git clone https://github.com/varigit/imx-atf-b lf_v2.10_6.6.52-2.2.0_var01   cd imx-atf 出典 /opt/FSL-IMX-Xwayland/6.6-scarthgap/environment-setup-armv8a-poky-linux LDFLAGSを解除します PLAT=imx8qm bl31 を作成します   mkashyap@cse-dev02:~/iMX8/Scarthgap_New/ATF/imx-atf/build/imx8qm/release$ ls -al 合計76 drwxrwxr-x 7 mkashyap mkashyap  4096 8月26日 22:37 . drwxrwxr-x 3 mkashyap mkashyap  4096 8月 26 22:36 .. drwxrwxr-x 3 mkashyap mkashyap  4096 8月26日 22:37 bl31 -rwxrwxr-x 1 mkashyap mkashyap 45213 8月26日 22:37 bl31.bin drwxrwxr-x 2 mkashyap mkashyap 4096 8 月 26 日 22:37 ライブラリ drwxrwxr-x 2 mkashyap mkashyap 4096 8月26日 22:37 libc drwxrwxr-x 2 mkashyap mkashyap 4096 8 月 26 日 22:37 libwrapper drwxrwxr-x 2 mkashyap mkashyap 4096 8月26日 22:37 romlib   CD ../../../../../   3. SCFWをダウンロードしてビルドする    mkdir SCFW    cd SCFW     wget https://developer.arm.com/-/media/Files/downloads/gnu-rm/8-2018q4/gcc-arm-none-eabi-8-2018-q4-major-linux.tar.bz sudo tar xf gcc-arm-none-eabi-8-2018-q4-major-linux.tar.bz -C ./opt     git clone https://github.com/varigit/imx-sc-firmware.git -b 1.17.0 cd imx-sc-firmware/src/scfw_export_mx8qm_b0     export TOOLS=/home/mkashyap/iMX8/Scarthgap_New/SCFW/Opt clean-qm を作成する    qm R=B0 B=var_som V=1 にする     mkashyap@cse-dev02:~/iMX8/Scarthgap_New/SCFW/imx-sc-firmware/src/scfw_export_mx8qm_b0/build_mx8qm_b0$ ls -al 合計 3384    drwxrwxr-x 11 mkashyap mkashyap    4096 8月26日 22:47 .    drwxrwxr-x  6 mkashyap mkashyap    4096 8月26日 22:47 ..    drwxrwxr-x  3 mkashyap mkashyap    4096 8月26日 22:47 掲示板    drwxrwxr-x  3 mkashyap mkashyap    4096 8月26日 22:44 デバイス    drwxrwxr-x 25 mkashyap mkashyap    4096 Aug 26 22:47 ドライバ    drwxrwxr-x  2 mkashyap mkashyap    4096 8月26日 22:44 main    -rwxrwxr-x 1 mkashyap mkashyap 184448 8 月 26 日 22:47 scfw_tcm.bin -rwxrwxr-x 1 mkashyap mkashyap 2787784 8月26日 22:47 scfw_tcm.elf    -rw-rw-r-- 1 mkashyap mkashyap 513123 8 月 26 日 22:47 scfw_tcm.map    drwxrwxr-x  4 mkashyap mkashyap    4096 8月26日 22:44 soc    drwxrwxr-x 26 mkashyap mkashyap    4096 8月26日 22:44 ss    drwxrwxr-x  9 mkashyap mkashyap    4096 8月26日 22:47 svc    drwxrwxr-x 10 mkashyap mkashyap    4096 8月26日 22:44 test    drwxrwxr-x  2 mkashyap mkashyap    4096 8月26日 22:44 utilities     CD ../../../../../     4. u-bootをビルドする    mkdir u-boot    cd u-boot     git clone https://github.com/varigit/uboot-imx.git -b lf_v2024.04_6.6.52-2.2.0_var01 cd uboot-imx        cp ../../SECO/imx-seco-5.9.4.1-0333596/firmware/seco/mx8qmb0-ahab-container.img ./mx8qm-ahab-container.img    cp ../../SCFW/imx-sc-firmware/src/scfw_export_mx8qm_b0/build_mx8qm_b0/scfw_tcm.bin ./mx8qm-mek-scfw-tcm.bin mrproper を作る    imx8qm_var_som_defconfig を作成する    make -j8     CD ../../     5. 画像を作成する mkdir MkImage cd MkImage     git clone https://github.com/varigit/imx-mkimage-b lf-6.6.52_2.2.0_var01 cd imx-mkimage        cp ../../SECO/imx-seco-5.9.4.1-0333596/firmware/seco/mx8qmb0-ahab-container.img ./iMX8QM/    cp ../../SCFW/imx-sc-firmware/src/scfw_export_mx8qm_b0/build_mx8qm_b0/scfw_tcm.bin ./iMX8QM/    cp ../../u-boot/uboot-imx/u-boot.bin ./iMX8QM/    cp ../../u-boot/uboot-imx/spl/u-boot-spl.bin ./iMX8QM/    cp ../../ATF/imx-atf/build/imx8qm/release/bl31.bin ./iMX8QM/     SOC=iMX8QM flash_ca72 を作成します     cd iMX8QM    make -f soc.mak SOC=iMX8QM MKIMG=../mkimage_imx8 PAD_IMAGE=./pad_image.sh flash_ca72        mkashyap@cse-dev02:~/iMX8/Scarthgap_New/MkImage/imx-mkimage/iMX8QM$ ls -al 合計6792    drwxrwxr-x  3 mkashyap mkashyap    4096 8月26日 23:08 .    drwxrwxr-x 13 mkashyap mkashyap    4096 8月 26 23:06 ..    -rwxrwxr-x  1 mkashyap mkashyap   45213 8月26日 23:06 bl31.bin    -rwxrwxr-x  1 mkashyap mkashyap    2564 8月 26 22:59 expand_c_define.sh    -rw-rw-r-- 1 mkashyap mkashyap 1895424 8 月 26 日 23:08 flash.bin    -rw-rw-r--  1 mkashyap mkashyap       9 Aug 26 23:06 head.hash    -rwxrwxr-x  1 mkashyap mkashyap    2078 Aug 26 22:59 mkimage_fit_atf.sh    -rw-r--r-- 1 mkashyap mkashyap 76944 8 月 26 日 23:02 mx8qmb0-ahab-container.img    -rwxrwxr-x 1 mkashyap mkashyap 184448 8 月 26 日 23:03 scfw_tcm.bin    drwxrwxr-x  2 mkashyap mkashyap    4096 8月26日 22:59 scripts    -rwxrwxr-x 1 mkashyap mkashyap 13271 8 月 26 日 22:59 soc.mak    -rwxrwxr-x 1 mkashyap mkashyap 1631521 8 月 26 日 23:06 u-boot-atf.bin    -rw-rw-r-- 1 mkashyap mkashyap 1500440 8 月 26 日 23:04 u-boot.bin    -rw-rw-r-- 1 mkashyap mkashyap 1500449 8 月 26 日 23:06 u-boot-hash.bin    -rw-rw-r-- 1 mkashyap mkashyap 139387 8 月 26 日 23:04 u-boot-spl.bin     生成された flash.bin はブートローダーイメージとして使用されました Re: iMX8qm Boot Core A72_0 こちらから始められます: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/System-Controller-Firmware-101/ta-p/1124236 https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/System-Controller-Firmware-101-Getting-started/ta-p/1121153 SCFWのリファレンス/ポーティングドキュメントは、独立した公開リファレンスマニュアルではなく、NXP SCFWポーティングキット内に提供されています。 NXPの i.MX ソフトウェア&開発ページからキットをダウンロードしてください。ご使用のi.MX BSPに対応するリリースを選択してください。NXPは、提供するバイナリとの互換性を維持するために、対応するポーティングキットを必要とします。 ライセンスに同意し、付属の.binファイルを実行してください。インストーラ。 以下をご覧ください: doc/pdf/sc_fw_port.pdf — SCFW移植ガイドの詳細 doc/pdf/ — SCFW APIユーザーガイド、リリースノートおよび関連ドキュメント src/ — SoC固有のSCFWエクスポートアーカイブ このキットには、ソースコードとオブジェクトコードが混在して含まれています。基板依存のカスタマイズは、エクスポートされたボードソースで行われます。通常はplatform/board/mx8 _ /の下で、board.cなどのファイルも含まれます;SCFWのコアの多くはオブジェクトのみのままで、パブリックキットを通じて変更することはできません。 UG10165年の一般的な i.MX Porting Guideには「Porting System Controller Firmware」の章があり、BSPやmeta-imx-scfwとの統合について説明しています。 Re: iMX8qm Boot Core A72_0 SCFWファームウェアの修正を行うためのSCFWリファレンスマニュアルや設計マニュアルはどこで入手できますか?
記事全体を表示
iMX8qm 启动核心 A72_0 大家好,NXP论坛, 在 iMX8qm 上,我们能否从 A72 核心启动?SCUFW 是否支持这样做? 谢谢! Re: iMX8qm Boot Core A72_0 请先使用现有的 flash_ca72 目标;不要替换 u-boot-atf.bin 文件。使用 u-boot-atf-a72.bin除非您有意使用驾驶舱/多 AP 图像流。 证据表明存在这种区别: flash_ca72 被描述为与普通 A-core 启动目标相同的基本启动映像,但加载到 A72 而不是 A53。 u-boot-atf.bin 是 ATF 和 U-Boot 的组合镜像:bl31.bin加上 u-boot.bin/ u-boot-hash.bin。 u-boot-atf-a72.bin出现在 flash_cockpit 目标中,其中镜像包含两个 AP 有效载荷:一个用于 A53,另一个用于 A72:-ap u-boot-atf.bin a53 0x80000000 ... -ap u-boot-atf-a72.bin a72 0xC0000000 ... 。 因此,重要的选择器不仅是文件名;它还是目标中的 imx-mkimage -ap ... a72 ... 参数。对于单个 A72 启动映像,使用 u-boot-atf.bin 的 flash_ca72 与文档中所述的意图一致:即使文件名没有后缀 -a72,有效载荷也会通过目标规则加载到 A72。 推荐路径: 使用现有目标构建标准的仅限 A72 的镜像: 制作 SOC=iMX8QM flash_ca72 在 Linux 端使用 CA72 设备树/配置。NXP 文档指出,i.MX8QM MEK CA72 DTB 仅支持两个 Cortex-A72 内核,并且需要使用 flash_ca72 构建的特殊启动映像。 预留 u-boot-atf-a72.bin对于显式打包第二个 A72 AP 映像的流程(例如 flash_cockpit),除非您的 电路板支持包的 soc.mak评论或发行说明另有说法。 启动时验证镜像是否实际进入 A72 路径:检查 make V=1 SOC=iMX8QM flash_ca72 命令发出的 imx-mkimage 命令,或检查 iMX8QM/soc.mak 文件。并确认 AP 线路使用 a72。 要点:将当前 flash_ca72 引用视为对 u-boot-atf.bin 的引用这是有意为之;u-boot-atf-a72.bin 是用于驾驶舱/多分区风格镜像中单独使用的 A72 有效载荷,而不是 flash_ca72 的自动替代品。 Re: iMX8qm Boot Core A72_0 我们想澄清/确认一个小问题:`flash_ca72` 目标目前引用了 `u-boot-atf.bin`,同时,在相同的配置中,还有一个单独的 `u-boot-atf-a72.bin` 可用。 我们该如何进行? Re: iMX8qm Boot Core A72_0 是的——在 i.MX8QM 上,应用程序处理器启动映像可以面向 Cortex-A72 而不是 Cortex-A53,SCFW 允许这种流程。NXP 的 imx-mkimage 有一个 flash_ca72 目标,被描述为普通 A53 启动映像的 A72 变体,旨在尽早启动 A72 以优化启动时间。 重要的区别在于: First code after RESET: 不是 A72。设备启动流程仍然从 ROM/SCU/SCFW 开始。 AP 端引导加载程序/操作系统启动:是的,这可以在 A72 上完成。SCFW 初始化 DDR,加载 Cortex-A 映像,然后启动内核并设置其起始地址。 配置机制:启动容器可以为 a72 指定一个 AP 镜像,例如示例显示 imx-mkimage 中的 -ap ... a72 ...。 所以答案是: SCFW 确实允许从 A72 启动 AP 软件路径,但 A72 不是 RESET/ROM 启动主控;它是由 SCFW 根据启动容器配置启动的。 Re: iMX8qm Boot Core A72_0 你好, 我按照以下步骤构建引导加载程序,但引导加载程序构建失败,没有任何日志记录。 请您核对一下附件中的步骤。 谢谢! mkdir Scarthgap_New cd Scarthgap_New   1. 获取网络安全控制器二进制文件 mkdir SECO 光盘 SECO wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/imx-seco-5.9.4.1-0333596.bin chmod +x imx-seco-5.9.4.1-0333596.bin ./imx-seco-5.9.4.1-0333596.bin   mkashyap@cse-dev02:~/iMX8/Scarthgap_New/SECO/imx-seco-5.9.4.1-0333596/firmware/seco$ ls -al 总计 976 drwxrwxr-x 2 mkashyap mkashyap   4096 8月26日 22:21 . drwxrwxr-x 3 mkashyap mkashyap   4096 8月26日 22:21 .. -rw-r--r-- 1 mkashyap mkashyap    194 7月 29  2024 commit-id.txt -rw-r--r-- 1 mkashyap mkashyap 163840 2024年7月29日 mx8dxla1-ahab-container.img -rw-r--r-- 1 mkashyap mkashyap 163840 2024年7月29日 mx8dxlb0-ahab-container.img -rw-r--r-- 1 mkashyap mkashyap 76944 2024 年 7 月 29 日 mx8qmb0-ahab-container.img -rw-r--r-- 1 mkashyap mkashyap  71312 7月29日  2024 mx8qxb0-ahab-container.img -rw-r--r-- 1 mkashyap mkashyap  78408 7月29日  2024 mx8qxc0-ahab-container.img -rwxr-xr-x 1 mkashyap mkashyap 423875 2024 年 7 月 29 日 SECO_FW_release_note.pdf mkashyap@cse-dev02:~/iMX8/Scarthgap_New/SECO/imx-seco-5.9.4.1-0333596/firmware/seco$   我们使用 mx8qmb0-ahab-container.img   光盘 ../../../..   2. 下载并构建 ATF mkdir ATF 光盘 ATF git clone https://github.com/varigit/imx-atf-b lf_v2.10_6.6.52-2.2.0_var01   cd imx-atf 源 /opt/fsl-imx-xwayland/6.6-scarthgap/environment-setup-armv8a-poky-linux unset LDFLAGS 制作 PLAT=imx8qm bl31   mkashyap@cse-dev02:~/iMX8/Scarthgap_New/ATF/imx-atf/build/imx8qm/release$ ls -al 总计76 drwxrwxr-x 7 mkashyap mkashyap  4096 8月26日 22:37 . drwxrwxr-x 3 mkashyap mkashyap  4096 8月26日 22:36 .. drwxrwxr-x 3 mkashyap mkashyap  4096 8月26日 22:37 bl31 -rwxrwxr-x 1 mkashyap mkashyap 45213 8月 26日 22:37 bl31.bin drwxrwxr-x 2 mkashyap mkashyap 4096 8 月 26 日 22:37 lib drwxrwxr-x 2 mkashyap mkashyap 4096 8月26日 22:37 libc drwxrwxr-x 2 mkashyap mkashyap 4096 八月 26 22:37 libwrapper drwxrwxr-x 2 mkashyap mkashyap 4096 8月26日 22:37 romlib   光盘 ../../../../../   3. 下载并构建 SCFW mkdir SCFW    cd SCFW     wget https://developer.arm.com/-/media/Files/downloads/gnu-rm/8-2018q4/gcc-arm-none-eabi-8-2018-q4-major-linux.tar.bz sudo tar xf gcc-arm-none-eabi-8-2018-q4-major-linux.tar.bz -C ./opt     git clone https://github.com/varigit/imx-sc-firmware.git -b 1.17.0 cd imx-sc-firmware/src/scfw_export_mx8qm_b0     export TOOLS=/home/mkashyap/iMX8/Scarthgap_New/SCFW/Opt    执行 clean-qm    使 qm R=B0 B=var_som V=1     mkashyap@cse-dev02:~/iMX8/Scarthgap_New/SCFW/imx-sc-firmware/src/scfw_export_mx8qm_b0/build_mx8qm_b0$ ls -al 总计 3384 drwxrwxr-x 11 mkashyap mkashyap 4096 8月26日 22:47 . drwxrwxr-x 6 mkashyap mkashyap 4096 8月26日 22:47 .. drwxrwxr-x 3 mkashyap mkashyap 4096 8月26日 22:47 板 drwxrwxr-x 3 mkashyap mkashyap 4096 8月26日 22:44 设备 drwxrwxr-x 25 mkashyap mkashyap 4096 8月26日 22:47 司机 drwxrwxr-x 2 mkashyap mkashyap 4096 8月26日 22:44 main    -rwxrwxr-x 1 mkashyap mkashyap 184448 8 月 26 日 22:47 scfw_tcm.bin -rwxrwxr-x 1 mkashyap mkashyap 2787784 8月26日 22:47 scfw_tcm.elf    -rw-rw-r-- 1 mkashyap mkashyap 513123 8 月 26 日 22:47 scfw_tcm.map drwxrwxr-x 4 mkashyap mkashyap 4096 8月26日 22:44 soc drwxrwxr-x 26 mkashyap mkashyap 4096 8月26日 22:44 ss drwxrwxr-x 9 mkashyap mkashyap 4096 8月26日 22:47 svc drwxrwxr-x 10 mkashyap mkashyap 4096 8月26日 22:44 测试 drwxrwxr-x 2 mkashyap mkashyap 4096 8月26日 22:44 实用程序     光盘 ../../../../../     4. 构建 u-boot mkdir u-boot    cd u-boot     git clone https://github.com/varigit/uboot-imx.git -b lf_v2024.04_6.6.52-2.2.0_var01    cd uboot-imx        cp ../../SECO/imx-seco-5.9.4.1-0333596/firmware/seco/mx8qmb0-ahab-container.img ./mx8qm-ahab-container.img    cp ../../SCFW/imx-sc-firmware/src/scfw_export_mx8qm_b0/build_mx8qm_b0/scfw_tcm.bin ./mx8qm-mek-scfw-tcm.bin    让 mrproper    制作 imx8qm_var_som_defconfig make -j8     光盘 ../../     5. 制作图像 mkdir MkImage    cd MkImage     git clone https://github.com/varigit/imx-mkimage-b lf-6.6.52_2.2.0_var01    cd imx-mkimage        cp ../../SECO/imx-seco-5.9.4.1-0333596/firmware/seco/mx8qmb0-ahab-container.img ./iMX8QM/    cp ../../SCFW/imx-sc-firmware/src/scfw_export_mx8qm_b0/build_mx8qm_b0/scfw_tcm.bin ./iMX8QM/    cp ../../u-boot/uboot-imx/u-boot.bin ./iMX8QM/    cp ../../u-boot/uboot-imx/spl/u-boot-spl.bin ./iMX8QM/    cp ../../ATF/imx-atf/build/imx8qm/release/bl31.bin ./iMX8QM/        制作 SOC=iMX8QM flash_ca72        cd iMX8QM make -f soc.mak SOC=iMX8QM MKIMG=../mkimage_imx8 PAD_IMAGE=./pad_image.sh flash_ca72        mkashyap@cse-dev02:~/iMX8/Scarthgap_New/MkImage/imx-mkimage/iMX8QM$ ls -al 总计 6792 drwxrwxr-x 3 mkashyap mkashyap 4096 8月26日 23:08 . drwxrwxr-x 13 mkashyap mkashyap 4096 8月26日 23:06 .. -rwxrwxr-x 1 mkashyap mkashyap 45213 8月26日 23:06 bl31.bin -rwxrwxr-x 1 mkashyap mkashyap 2564 8月26日 22:59 expand_c_define.sh    -rw-rw-r--  1 mkashyap mkashyap 1895424 8 月 26 日 23:08 flash.bin -rw-rw-r-- 1 mkashyap mkashyap 9 Aug 26 23:06 head.hash -rwxrwxr-x 1 mkashyap mkashyap 2078 年 8 月 26 日 22:59 mkimage_fit_atf.sh    -rw-r--r-- 1 mkashyap mkashyap 76944 8 月 26 日 23:02 mx8qmb0-ahab-container.img    -rwxrwxr-x 1 mkashyap mkashyap 184448 8 月 26 日 23:03 scfw_tcm.bin drwxrwxr-x 2 mkashyap mkashyap 4096 8月26日 22:59 脚本    -rwxrwxr-x 1 mkashyap mkashyap 13271 8 月 26 日 22:59 soc.mak    -rwxrwxr-x 1 mkashyap mkashyap 1631521 8 月 26 日 23:06 u-boot-atf.bin    -rw-rw-r-- 1 mkashyap mkashyap 1500440 8 月 26 日 23:04 u-boot.bin    -rw-rw-r-- 1 mkashyap mkashyap 1500449 8 月 26 日 23:06 u-boot-hash.bin    -rw-rw-r-- 1 mkashyap mkashyap 139387 8 月 26 日 23:04 u-boot-spl.bin     生成的 flash.bin 文件被用作引导加载程序镜像。 Re: iMX8qm Boot Core A72_0 就您的具体手术而言,关键在于: 制作 SOC=iMX8QM flash_ca72 如果您打算将引导加载程序加载到 A72 而不是 A53 ,那么从概念上讲,这是正确的目标。NXP 社区指南将 flash_ca72 描述为类似于基本的 flash_b0 映像,但加载到A72而不是A53 。 “无日志”症状并不一定意味着 SCFW 拒绝了 A72 启动。一个已知的陷阱是A53 和 A72 不使用同一个日志终端,因此,如果您监测通常的 A-core/A53 UART,即使 A72 镜像正在运行或稍后在不同的控制台路径上出现故障,您可能也看不到任何东西。 验证您的步骤: 面积 评估 SECO集装箱 mx8qmb0-ahab-container.img 是 i.MX8QM B0 的正确容器类别。 ATF 使 PLAT=imx8qm bl31 对于 i.MX8QM 来说是合理的。 SCFW 构建 qm R=B0 B=var_som V=1 与 i.MX8QM B0 Variscite 目标一致。 U-Boot imx8qm_var_som_defconfig 是需要确认的关键项:它必须与 A72 启动路径和控制台配置兼容。 mkimage 目标 flash_ca72 仅适用于 A72 启动。对于正常的 Linux 电路板支持包。启动,文档中记录的 i.MX8QM 命令是 make SOC=iMX8QM flash。 SPL副本 u-boot-spl.bin 可能与 flash_ca72 无关;该目标不是基于 SPL 的流程。 重复镜像版本 同时运行顶层 make SOC=iMX8QM flash_ca72 和手动运行 make -f soc.mak ... flash_ca72 是不必要的。使用一条简洁的顶级命令。 我会修改/优化图像生成部分,使其: cd ~/iMX8/Scarthgap_New/MkImage/imx-mkimage cp ../../SECO/imx-seco-5.9.4.1-0333596/firmware/seco/mx8qmb0-ahab-container.img ./iMX8QM/ cp ../../SCFW/imx-sc-firmware/src/scfw_export_mx8qm_b0/build_mx8qm_b0/scfw_tcm.bin ./iMX8QM/ cp ../../u-boot/uboot-imx/u-boot.bin ./iMX8QM/ cp ../../ATF/imx-atf/build/imx8qm/版本/bl31.bin ./iMX8QM/ make clean 制作 SOC=iMX8QM flash_ca72 然后使用: iMX8QM/flash.bin 同时修复/检查此 SCFW 路径: export TOOLS=/home/mkashyap/iMX8/Scarthgap_New/SCFW/Opt 您已将文件提取到 ./opt 目录。但是导出了.../SCFW/Opt。Linux 路径区分大小写。既然你已经生成了scfw_tcm.bin你的 shell 可能确实有有效的工具路径,但这一行需要验证。 推荐的调试顺序: 首先构建并启动标准镜像: 让 SOC=iMX8QM 闪存 这会检查 SECO + SCFW + ATF + U-Boot + 板 DDR/控制台是否基本正确。Linux 用户指南中记录了此标准 i.MX8QM flash.bin 文件。生成路径。 然后使用以下命令重新构建: 制作 SOC=iMX8QM flash_ca72 监控A72 控制台/UART ,而不仅仅是普通的 A53 控制台。A53 和 A72 日志终端有所不同。 如果仍然没有反应,请比较生成的 flash.bin 文件。比较 flash 和 flash_ca72 之间的大小/布局,并确认 Variscite U-Boot 配置是否真正启用了 A72 启动目标使用的控制台。 所以直接的答案是: SCFW 确实允许通过 flash_ca72 镜像流程启动 A72 上的 Cortex-A 端,但 SCFW 仍然负责初始启动编排。你的步骤对 A72 启动基本有效,但需要移除重复的 soc.mak 调用,验证 SCFW 工具路径,最重要的是检查 A72 的 UART/控制台。 要点:i.MX8QM 上的 A72 启动是通过 flash_ca72 实现的;静默启动更有可能是镜像/配置/控制台问题,而不是 SCFW 拒绝启动 A72。 Re: iMX8qm Boot Core A72_0 哪里可以找到SCFW参考手册或设计手册,以便对SCFW固件进行修改? Re: iMX8qm Boot Core A72_0 您可以从这里开始: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/System-Controller-Firmware-101/ta-p/1124236 https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/System-Controller-Firmware-101-Getting-started/ta-p/1121153 SCFW 参考/移植文档包含在 NXP SCFW 移植工具包中,而不是作为单独的公开参考手册提供。 从 NXP i.MX 软件和开发页面下载工具包。选择与您的 i.MX BSP 对应的版本;NXP 需要匹配的移植工具包以保持与其提供的二进制文件的兼容性。 接受许可协议并运行包含的 .bin 文件安装程序。 请查看下方: doc/pdf/sc_fw_port.pdf — 详细的 SCFW 移植指南 doc/pdf/ — SCFW API 用户指南、版本说明及相关文档 src/ — SoC 专用 SCFW 导出归档 该工具包包含源代码和目标代码的混合体。针对特定电路板的定制是在导出的电路板源代码中进行的,通常位于 platform/board/mx8 _ / 目录下,包括 board.c 等文件。; SCFW 的核心大部分仍然是对象式的,无法通过公共工具包进行修改。 通用 i.MX 移植指南 UG10165 中也有一个“移植系统控制器固件”章节,解释了与 BSP 和 meta-imx-scfw 的集成。
記事全体を表示
S32 Power Architecture 设计工作室,版本 2.1 许可 我的 S32 Design Studio for Power Architecture 2.1 版许可证已过期。请问您能帮我续期或者申请新卡吗? F379-CD5D-DAD1-7708 Re: S32 Design Studio for Power Architecture, version 2.1 license 你好, 您的S32DS许可证已延期。请使用您之前的激活码重新激活S32DS。 Re: S32 Design Studio for Power Architecture, version 2.1 license 你好, 我已经申请续约。 顺祝商祺! Peter
記事全体を表示
S32 Design Studio for Power Architecture, version 2.1 license My license for S32 Design Studio for Power Architecture version 2.1 has expired. Could you help me renew it or apply for a new one. F379-CD5D-DAD1-7708 Re: S32 Design Studio for Power Architecture, version 2.1 license Hi,  your S32DS license has been extended. Please activate S32DS again with your old code.  Re: S32 Design Studio for Power Architecture, version 2.1 license Hello, I have asked for renewal. Best regards, Peter
記事全体を表示